VMS C & records in files

[Keith Moore]

In article <1609 at edison.GE.COM>, rja at edison.GE.COM (rja) writes:
> I'm not aware of any solution to the problem of VMS file types.  The
> problem is precisely that VMS is so record-oriented.  Even nominal 
> text files don't work like UNIX.  We find that we have to use a loop of
> successive calls to read() to fill (for example) a 512 byte buffer
> because it gives only 1 record at a time even though you asked for 512
> bytes. :-(
>   UNIX and even MS-DOS will let you read 512 bytes in a chunk so it's VMS
> that is brain-damaged in this case.

To be fair, Unix does read a record at a time when it is 
appropriate to do so (e.g. from a 1/2 inch tape drive, but NOT
from a 1/4 inch tape drive, where records are always 512 bytes).  
Certainly record-at-a-time behavior is often appropriate for VMS 
when using non-text files (there are no carraige control attributes).  
Record-at-a-time behavior is generally inappropriate for text files.
The C library should treat text files as streams by default,
flush a record when it sees a newline, and read as many bytes as you ask for.  

The VMS C library needs a convenient way to change its default behavior.
This way you could say 
"treat the file as a stream" 
	(record boundaries don't correspond with read boundaries), or
"treat the file like a 1/4 inch tape" 
	(read in as many records as will fit in the buffer), or 
"treat the file like a 1/2 inch tape"
	(read in only one record at a time).

Some of these you can do with the VMS C library, with some convoluted
and obscure arguments to open, creat, etc.  At any rate, the default 
behavior of the library i/o routines often doesn't do what you want or expect.

In article <623 at wsccs.UUCP> terry at wsccs.UUCP (Every system needs one) writes:
[...]
>	fopen( file, "r+");
>	fopen( file, "r+", "rat=var,cr");
>	fopen( file, "r+", "rat=fix", "mrs=512");
>
>	If you must use open(), then at least have the decent-C to
>read with more than on character in your buffer and write the same
>way.  Files written with either the 2nd or 3rd above can't use putc()
>at the low level, or the will (of course!) write out single records.

For the 2nd form of fopen (), the behavior is brain-damage.  For the
3rd form, it is probably correct, since you aren't creating a text
file.  Record-oriented files which aren't text files should look 
like magnetic tapes.

>A record is sort of defined (gentleman's agreement?!?) as the result
>of a single write operation.  
This is consistent with Unix behavior for record-oriented files.
For VMS, you need to be able to choose which behavior you want.

>The function fprintf() (for example)
>uses putc() at the low level and so is broken.  If you can stand the
>link warnings, write your own buffered putc().  The fprintf() can
>be fixed by using your own with sprintf() and puts() or write()...
>again, you will have to ignore the link errors, as well as the new
>compile-time warnings about varadic functions.

There's no reason why fprintf can't work right for any kind of file.
Since it's a library function, it could be taught to know about the
VMS file system.  For instance:  if you are writing to a text file,
fprintf should flush the file buffer (thus writing out a new record) 
when it sees a newline.  If the file is a fixed-length record text
file (!), pad the rest of the record with blanks.

Actually, this could all be done at the putc/flushbuf level and fprintf
would not have to be concerned with it.

I am of the opinion that the VMS C library is not very well designed.
The defaults for many of the i/o functions are poorly chosen, and it
is often difficult to work around them without circumventing C-style i/o
altogether in favor of RMS or system services.  More recent versions
of the library have attempted to address the design deficiencies, but
backward compatability considerations will keep Digital from ever fixing
the library to work well.

(Does a free or public-domain implementation of stdio exist?)
-- 
Keith Moore
UT Computer Science Dept.	Internet/CSnet: moore at utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus	BITNET: moore at utkcs1
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822