Neil Harvey writes:
> We found that APACHE didn't like the raw "mv"ed files, so we 'cat'ed
> them instead, and Lo!, it worked. The symptom was that Apache never
> completed loading the files.
>
> #MV.HPBIN.SYS;info="-f !file3 !fullname"
> sh.hpbin.sys;info="-c '/bin/cat !file3 > !fullname'"
>
> Try doing this first before you Samba them across to the PC, or let the
> PC look at them via SAMBA.

This POSIX bytestream emulator "feature" is well known to us denizens of
POSIXland.  ;-)

Let's say you have an MPE fixed record length ASCII file of recsize X and Y
number of records.

If a web browser asks Apache to return this file, Apache first calls the POSIX
stat() function to determine the file size in bytes so a Content-length: HTTP
header can be returned to the browser to let the browser know how many bytes
of file data will follow.

For MPE fixed ASCII files, stat() will return a filesize of (X [recsize]+1) *
Y [number of records].  The +1 is to account for the POSIX newline character
that will be added by the bytestream emulator to delimit the end of each MPE
record.

So far so good.  But what causes confusion is that the POSIX bytestream
emulator will cause all trailing blanks to be removed from MPE fixed ASCII
files as they are read by POSIX I/O functions.  Thus in the web server case,
the browser was expecting Content-length: amount of bytes to be returned, but
due to blank truncation, fewer bytes than expected are returned to the browser.
Netscape's browser will appear to hang for a long while, then will eventually
time out.

The same problem may occur in a Samba environment.  Some PC programs will ask
Samba "how big is the file?" and Samba will return the stat() value discussed
above.  The PC program will then expect to read that many bytes, but when EOF
comes prematurely, weird results may happen, ranging from error messages to
GPF aborts.

Not all PC programs have trouble Samba-ing MPE fixed ASCII files.  I suspect
the programs that work OK are just reading until EOF without doing stat()
first and getting that false expectation of file size.

Neil's /bin/cat workaround is effectively doing a /bin/tobyte on the file, i.e.
converting the file to a bytestream file.  Trailing blanks have already been
removed from the resulting bytestream file, so the stat() filesize will be
accurate, and both Apache and Samba applications should be happy.

So the moral of the story is that for best results with POSIX applications,
native POSIX bytestream files are the best way to store your data.  MPE record
files may or may not work as expected.
--
Mark Bixby                      E-mail: [log in to unmask]
Coast Community College Dist.   Web: http://www.cccd.edu/~markb/
District Information Services   1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
Technical Support               Voice: +1 714 438-4647
"You can tune a file system, but you can't tune a fish." - tunefs(1M)