> Paul Raulerson wrote: > This is a funny area to compare though, since on most platforms, > C file > access is always a binary stream. The application pretty > much defines the > way the file is treated - byte by byte, > record by record, block by block, > buffer size by buffer > size, etc. To load an image for instance, it is > pretty common > to fstat() the image file to get its size, malloc() a buffer > of the > appropriate size, then do a single read() or fread() to > populate > the buffer. It is extremely efficient on most platforms, > often due to the > OS buffering.
> But it does not equate all that well to traditional > mainframe thinking. I > mean, under UNIX, if you fread() a byte > or so too much from a file, you > simply put the extra back on the file. :) C has adversely impacted the world. Most languages have modeled there I/O off of C's I/O (streams). Streams and databases are the most prevalent I/O methods in the world. C programmers are correct in that they CAN do MVS style I/O. The problem is they DON'T because it's too complicated in C style languages. If they truly understood MVS I/O, they would never say "extremely efficient on most platforms". Consider the C major innovations over 50 years: NFS (1984), block locking, and databases. Block locking has mainly been used for databases because it's too complex for the average programmer. NFS is Unix's concept of shared dasd it has the same problems as regular files. Typical C programmer reads or writes a file (nothing sophisticated). C has record locking but it requires programmer to do record processing. C programmers can update a file but most don't. Sophisticated requires using SQL and databases. Typical Cobol programmer does not even consider SQL and databases because they can do it from standard I/O. More important is the programmer does nothing different or unusual. E.g. open for update. Consider the major MVS I/O innovations due to records and blocks. There are many and it's difficult to name them all. VSAM eliminated some of the need for a database. Record locks. I/O queue management. Transactional VSAM eliminated more database requirement. There are so many innovations in MVS I/O and the programmer rarely notices anything. To start with, the innovations mentioned above. HSM (disk full). Record insert. How about creating efficient programmers. C programmers often don't plan for a record. C have several commands to write and read data from a file. C programmers often must read each field to find the start of the next record (unless they planned for it). If a cobol programmer only needs 2 bytes of a variable length record, they don't need to skip each field. Much of these innovations exist because HLASM was flexible enough to encourage their development. Anyone who doubts the significance of HLASM is very naive because nothing like these were ever developed in C. Regards, Jon.
