rang@cs.wisc.edu (Anton Rang) (11/06/90)
In article <PENA.90Nov1164830@fuug.fi> pena@fuug.fi (Olli-Matti Penttinen) writes: > The worst thing is that (at least under VMS 4.x) you really had to >know the exact file type of a *TEXT FILE* to be able to do anything >useful with it. This is an argument which comes up fairly often. It's only partly true. The C I/O model (a file is a stream of bytes) works well for an awful lot of applications. The problem is that if you have a more complex file structure, mapping it into the stream-of-bytes framework in a way that makes sense is difficult. The way that most languages under VMS do their I/O is by using the high-level RMS calls. You can $OPEN a file, and then read through it, one record at a time, using $GET. This will let you sequentially scan through file with a record structure--whether it's a variable-length record file, a stream file, a 'relative' (numbered-record) file, or an ISAM file. You can use $PUT and/or $UPDATE to change files, one record at a time. It's difficult to map this directly into a read/write/fseek model, except with stream files (which are basically identical to UNIX text files). For instance, each record in a (sequential) variable-length record file has a two-byte length field, and may include a byte of padding. If you want to treet fseek() as taking an offset which is a character count, in this file type, you don't know where to position the 'file pointer' without scanning from the start of the file. (That's why it's a "sequential file"--it's designed for sequential access, and shouldn't be used [under VMS] for random access.) An ISAM file type is even worse...if you have records with keys of 'abc', 'def', and 'ghi', they may have that logical order, but be stored physically in a different order, different parts of the record may be in different areas of the disk, and the record itself may be stored in compressed form. How could fseek() deal rationally with this? If you want an easy port of a program using the UNIX I/O facilities, it will have to deal with stream files, since that's what UNIX provides. (Unfortunately, the VMS C RTL still had some rather odd quirks last time I looked, but the latest release was supposed to improve it--I haven't used it since then.) Hopefully this isn't really controversial, but I've directed followups to alt.religion.computers just in case.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
guy@auspex.auspex.com (Guy Harris) (11/10/90)
(Dunno if "alt.religion.computers" is the right place, but it's probably better than "comp.unix.programmer" at this point....) > The best thing about RMS is it's ability to support DBMS's which >generally run circles 'round a similar one under Ultrix/BSD. Besides, >it's a little bit simpler to implement a database using a filesystem >w/ built in ISAM instead of opening a Unix partition and seeking here >and there. Does a UNIX system with, say, an XPG3-compliant ISAM library have "a filesystem w/ built in ISAM"? If not, why not? If the answer is "because that's implemented atop the file system rather than built into the file system", how is this different from VMS, which as I remember implements ISAM, just as it implements the various text file types, atop QIOs that just read and write blocks of files? If the answer is "well, RMS runs in *executive* mode rather than *user* mode", how much does this really matter? If the answer is "well, Files-11 lets you store all sorts of attributes in the file header that the low-level QIO interface doesn't interpret, but that RMS does", again, how much does this really matter?