Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: File handling in Fortran 77 Message-ID: <3645@goanna.cs.rmit.oz.au> Date: 31 Aug 90 01:57:24 GMT References: <46016@masscomp.ccur.com> <1990Aug29.173235.9405@ux1.cso.uiuc.edu> <1990Aug30.132335.20164@ux1.cso.uiuc.edu> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 70 In article <1990Aug30.132335.20164@ux1.cso.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > I meant that a computer that can't run C is a joke. Hmm, I used such a machine for years. It was *lovely*. Moving to UNIX/C was a *huge* step down in terms of ease of programming/debugging. > If it can run C, > it must be physically possible, and possible by some sort of OS calls. Well yes, but it doesn't have to be _easy_. Consider System 370. That can run UNIX (Amdahl's UTS, IBM's AIX, even, I've heard, SunOS 4.0). So it is physically possible for the computer to run C. Indeed, there are several C compilers (SAS/Lattice, NorCroft, Waterloo, IBM) for MVS and CMS. With files made of fixed length records, the C RTL can "fake" seeking to an arbitrary byte. With files made of variable length records, although CMS allows you to seek to an arbitrary record (nice one!) you have to know which record, which would mean having to add up the lengths of all the records in the file starting at the beginning until you found the right one. Physically possible, yes. Fast, no. The interesting thing about the reference to C is that it doesn't actually put much of a constraint on the operating system at all. There is no requirement that a C program be able to read or write every file format that the operating system supports. It is quite conceivable that C and Fortran might have no formats in common. One method that has been used by some C compilers is to make C files out of fixed length records, where the length of each record is 1. So it can be the case that an operating system may be able to support C in full conformance with the ANSI standard, and yet may have additional file formats that Fortran can use but C can't. > In other words, you are saying Primes are (were?) so deficient that > they could not even tell how long a file was? No, he said they could tell, but only in units of 16-bit words. Why is that more reprehensible than UNIX not being able to tell how long a file is in bits? > I still don't understand why not. A file IS a sequence of bits. No. A file *IS* (part of) a state of a storage device. That storage device may have special characteristics (such as IBM's old count-key-data stuff) that show up in the structure of a file. There are some bits in there, sure, but the physical structure of the device may also be relevant. > What language IS it done in? Certainly not Fortran --- C? assembly? Why _not_ Fortran? When I knew it, PR1MOS _was_ written in Fortran. > The point is that any language is joke if it is > severly limited in how it can use files. Right. So C must be a joke because it has no built in support for VSAM. C must be a joke because it cannot address files at the bit level. C must be a joke because it has no standard record locking facilities. And so on and so on. But C can call subroutines to do these things? Why, so can Fortran! > But to have it stuffed deep down inside the OS as in VMS and IBM mainframes > is a disaster. VMS supports UNIX-like Stream-LF files, also Mac-like Stream-CR files, and fixed-length and variable-length records a la IBM, and a couple more. As for IBM, their operating system was such a disaster that they've been crying their way to the bank ever since. (I loathe MVS and CMS myself. With respect to MVS, "loathe" doesn't begin to express it. But MVS is taking a remarkbly long time to disappear...) -- You can lie with statistics ... but not to a statistician.