"File types"

On 8/29/2006 at 8:08 AM Don wrote: <OT> Okay, this is drifiting OT, but I can't let this go by unchallenged. It merely incorporates the nasty business of blocking and formatting records into a standard set of routines. They don't have to be run at the supervisory level, but convention should dictate their use. The beauty is that data interchange among applications gets easier--and you don't have the run-time library for a particular language implementing its own idea of what a file full of ASCII strings is and being compatible with nothing else. Your example of a COBOL program writing source for a FORTRAN program thus works, as long as the COBOL program doesn't use datatypes that are completely unknown to the FORTRAN world (e.g. COMP-3 numbers). Cyber Record Manager (CRM) was introduced into the CDC NOS world sometime during the 70's and it made a big difference in application code. If your program, for example, had to read a tape full of 7000 SCOPE W-type records, you could simply declare the tape (via job control statements) as containing them, instead of having to write a bunch of code to decipher them. And one application's idea of what an ISAM file was is assured to be the same as another's. For the diehards, you can always declare a medium as containing raw bits and wrestle with them in your applicaton code. But for most applications, there's no reason to do this. How many ways are there of representing variable length character strings? And how many have you run into? Off the top of my head, I've seen--on the MS-DOS/Windows platform the following: byte count+data, word count+data, data terminated by 00, data terminated by 0a, data terminated by 0d, data terminated by 1F, and probably a few others that don't occur to me right off. I'm not a big fan of the "implement whatever weird nonstandard file structure you like and hope no one loses the program that created it" school of thought. </OT> Cheers, Chuck