INFO-VAX Sun, 02 Jan 2005 Volume 2005 : Issue 4 Contents: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Re: MntVerifyTimeout, (remote shadow member), clustering, volume shadowing ---------------------------------------------------------------------- Date: Sun, 2 Jan 2005 09:00:50 -0500 From: "Neil Rieck" Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Message-ID: > > CSWS V2.0 *demands* that all files are in stream-lf format. That is the > reason why many of us are still using the previous version :-). > I think this statement could be wrong. SWS-2.0 (they've dropped the "C" from the product name starting with version 2.0) only requires that TEXT files be converted to stream_lf. This because of three reasons: 1. Apache 2.x now is required to do something called content-length filtering which means a browser may indicate to the server that it can only accept, lets say, 2KB chunks. After the server sends out 2KB to the browser, the browser may say to the server, "OK send the next 500 Bytes". The server needs to be able to easily compute the starting point of byte 2001. 2. Text files in VMS are stored as a sequence of variable-length records. You cannot determine the starting position of a given character without first reading through all the variable-length records up-to the one you're looking for. 3. HP didn't want to write any special code just to deal with VMS issues (although I think they could have created a MOD_RMS for people wanting backward compatibility) The following links may help to understand content-length filtering: http://hypermail.linklord.com/new-httpd.old/2002/Aug/0374.html http://httpd.apache.org/docs-2.0/filter.html http://www.onlamp.com/pub/a/apache/2001/08/23/apache_2.html I just pulled the following quote from this news group archive at www.deja.com where I did an advanced search for the word "CSWS" from author "Rick Barry". As a few posters already guessed, the stream-lf requirement for served files was to minimize the portability (and maintenance) effort and to address the problem of quickly determining the number of data bytes in the Content-Length calculation (without having to read every byte in the file). This requirement applies mainly to textual content, such as .HTML, .SHTML, and .TXT files, that are typically represented on VMS using variable-length record format. Binary data files, such as executables, are not an issue because fixed-length record format is also acceptable. Rick Barry OpenVMS System Software Group Hewlett-Packard Company Nashua, NH Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Sun, 2 Jan 2005 09:16:17 -0500 From: "Neil Rieck" Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Message-ID: <9nTBd.476$P%3.72135@news20.bellglobal.com> "Rich Faust" wrote in message news:1104626045.060255.211490@z14g2000cwz.googlegroups.com... >I wondered about that, so before I posted my original note I took a > closer look at APACHE$COMMON:[000000]APACHE$CONVERT_STREAMLF.COM. This > tool is called by APACHE$MENU to convert a directory tree to Stream_LF. > The convert procedure references the following data file: > > # APACHE$CVT_TYPES.DAT > # > # File types that get converted by > APACHE$CONVERT_STREAMLF.COM > # > > .HTM* #All HTML files (.HTM, .HTML, .HTML.FR, etc) > .SHTML #Server-side includes > .TXT #All TXT files > > I take the contents of this file to mean that .JPG files should not be > converted to Stream_LF, so I don't believe the format of the file is > the problem. > > Rich Faust > OpenVMS Hobbyist > Richmond, TX > Your analysis is correct. The script doesn't look for anything other than VMS text files which means JPG files don't need to be converted. Have you checked your Apache error log? (You'll need to restart the server to look at it) Last resort test: I see that you are a hobbyist. Try shutting down MultiNet and installing HP's "TCPIP Services for OpenVMS". If your problem goes away then you know that there is a bug with the stack. (this is how I solved my TCPware related problem which I documented here http://www3.sympatico.ca/n.rieck/docs/csws_tips.html#intermittent-cgi ) Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Sun, 02 Jan 2005 11:38:44 -0500 From: JF Mezei Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Message-ID: <1104683349.77a610c57224570c31d1af730ab2a3c7@teranews> Neil Rieck wrote: > 2. Text files in VMS are stored as a sequence of variable-length records. > You cannot determine the starting position of a given character without > first reading through all the variable-length records up-to the one you're > looking for. One could write a wrapper IO routine that could easily handle this through caching of files (or building an index of offsets for the first record of each block (eg: offset 5016 is first byte of record located on block 10 with recrd header at byte 27 of that block) Of of the file is small enough, jus read the whole thing in. ------------------------------ Date: Sun, 2 Jan 2005 12:48:48 -0500 From: "Neil Rieck" Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images Message-ID: "JF Mezei" wrote in message news:1104683349.77a610c57224570c31d1af730ab2a3c7@teranews... > Neil Rieck wrote: >> 2. Text files in VMS are stored as a sequence of variable-length records. >> You cannot determine the starting position of a given character without >> first reading through all the variable-length records up-to the one >> you're >> looking for. > > One could write a wrapper IO routine that could easily handle this through > caching of files (or building an index of offsets for the first record of > each block > > (eg: offset 5016 is first byte of record located on block 10 with recrd > header > at byte 27 of that block) > Of of the file is small enough, jus read the whole thing in. I agree and I suggested this to the folks at HP. Put the OpenVMS-specific routines in an optional loadable Apache module called "MOD_RMS" (or whatever). For people who desire the UNIX style speed up, they would still need to run DCL script "APACHE$CONVERT_STREAMLF.COM" to convert all text files to stream format. Other people requiring backward compatibility would simply load module "MOD_RMS" into the SWS server at server startup. Then, Apache could use info in the file header to determine whether to deny the transaction or flop back to "MOD_RMS". In some private correspondence with the good folks in HP's "OpenVMS System Software Group", they hinted at the fact that they might consider some kind of fall back support if there was enough customer demand for it through the OpenVMS software customer support channel. (translation: complaints through this news group probably won't count as much with HP managemtn). Let's keep our fingers crossed for SWS-2.1 NOTE: This is slightly off topic but many months back, some kind soul published a cool work around based upon PHP. If fall-back compatibility is mandatory (like systems where stand-alone applications may be generating ASCII reports; or clients are FTPing text files into OpenVMS in ASC mode) then this PHP solution may help some people. Do an advanced search at www.deja.com looking for stream_lf and PHP in group "comp.os.vms") Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Sun, 2 Jan 2005 11:51:32 -0000 From: "Alex Daniels" Subject: Re: MntVerifyTimeout, (remote shadow member), clustering, volume shadowing Message-ID: <41d7e047$0$21329$db0fefd9@news.zen.co.uk> "Phillip Helbig---remove CLOTHES to reply" wrote in message news:cr1dsa$2rl$1@online.de... > I see my MVTIMEOUT is set at 3600 (i.e. one hour). The maximum is > 64000, i.e. almost 18 hours. 64000 is not the limit for this. You can set it to 0 (infinity). SYSGEN> SHOW MVT Parameter Name Current Default Min. Max. Unit Dynamic -------------- ------- ------- ------- ------- ---- --- ---- MVTIMEOUT 3600 3600 1 64000 Seconds D SYSGEN> DISABLE CHECKS SYSGEN> SET . 0 SYSGEN> SHOW . Parameter Name Current Default Min. Max. Unit Dynamic -------------- ------- ------- ------- ------- ---- --- ---- MVTIMEOUT 0 3600 1 64000 Seconds D SYSGEN> WRITE ACTIVE And yes, this is supported by HP. Reference : http://h18000.www1.hp.com/support/asktima/operating_systems/00973DDA-27B2C060-1C0097.html Alex ------------------------------ End of INFO-VAX 2005.004 ************************