My 2¢ from the Way Back Machine: I don't know what programmer's used before Fortran. But, all these OS/360 features (and, likely earlier IBM OS's) were accessible from Fortran, the first commercially available high-level computer language. Human input, including source code, was typically typed onto an 80-column card with a keypunch. Such text "files" were read using 80 character "fixed-length" I/O. Also, in those days, disk sectors were not fixed lengths. Think of them as tiny strips of magnetic tape. Just like tape, there is a physical record written and read by the hardware—what is now called a sector for fixed-length geometries—packed with embedded logical record(s) with a structure defined by software. Such "files" were read using "fixed-length" or "variable-length" I/O to match the desired record structure. I say "files", because I/O could be done on an IBM OS/360 to just about any device, whether it incorporated a file system (disks did) or not (labeled tapes did, unlabeled tapes and card readers and printers did not), Fortran supported text or binary I/O. Binary I/O was done using variable-length record format. Fortran imposed no limit to the size of a variable-length record. To escape the limitation of the hardware, "spanned" record format was created which splits and merges arbitrary length Fortran records into segments, which are then passed on as "normal" fixed- or variable-length records to the software layer which assembles and disassembles physical records for device I/O. The richness of file formats available in Fortran was directly mapped to the hardware capabilities.
ISAM I am sure must have come about when IBM introduced their first DBMS. As with the file formats needed/used by Fortran, the ISAM software undoubtedly made direct use of the hardware features. Recall, in those days I/O to devices like disks and tapes was done through "channels", which themselves were actually small computers. Operations requested by software that made use of these features were performed by channel programs; thus, were processed in parallel while the CPU was relieved to work on other things (in a multi-programming O/S like OS/360; not all O/S's were). I don't recall when or why fixed-sector disks began to be required, and by which O/S's. There would certainly have been a cost savings motive, both in the device electronics, and in the attachments, which could be much simpler than channel attachments. It would not surprise me if Multics was influential. A stream of blocks (sectors) or bytes are not that different, other than at the device I/O level. Ergo the need to differentiate block devices from character devices in Unix. When the device I/O was controlled by the record format of the program, as in the original Fortran, it was done by the O/S (using the appropriate channel program). When the device was only capable of delivering fixed-length blocks of data (sectors), a software layer had to perform the equivalent record formatting operations. That is where we are today. RSX, VMS, Unix all perform "file" I/O (after passing through an optional file system layer) through the operating system; they perform record I/O through user-mode libraries. The C library implements the illusion of a stream of bytes, including the notion of an "end of record" for text I/O using a metacharacter marker (\n, the newline character, which is NOT a line-feed in EBCDIC). RSX and VMS embed structure within the data blocks of a file, and encode that information in metadata fields provided by the file system. The appropriate FCS (RSX) or RMS (RSX and VMS) libraries do the work. Not all the file systems supported by VMS support all the RMS file types (record formats), such as the ISO-9660 CD-ROM file system. Absent any hints, the VMS file system layer assumes the record format is the same as the "standard" disk format, 512-byte sectors (even though a CD-ROM has 2048-byte sectors). And, that is why Brian's Unix CD-ROM was misread on VMS. The File Types available in the ISO-9660 file system metadata read like a POSIX file system specification. That is, very Unix-like. I don't know why the RMS default file attributes are not STREAM_LF. That would make more sense to me. Anyway, the default can be changed by the /UNDEFINED_FAT option in the MOUNT /MEDIA_FORMAT=CDROM command. Larry Baker US Geological Survey 650-329-5608 [email protected] > On 17 Dec 2018, at 12:06:57 PM, [email protected] wrote: > > ------------------------------ > > Message: 3 > Date: Mon, 17 Dec 2018 14:56:30 -0500 > From: Paul Koning <[email protected] <mailto:[email protected]>> > To: Phil Budne <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>, > [email protected] <mailto:[email protected]>, [email protected] > <mailto:[email protected]> > Subject: Re: [Simh] Transferring the licence file to the VAX emulator > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=us-ascii > > > >> On Dec 17, 2018, at 2:44 PM, Phil Budne <[email protected] >> <mailto:[email protected]>> wrote: >> >> Clem Cole wrote: >>> .... In the old days, the idea of 'access >>> methods' was the natural ways OS's did I/O and RMS was VMS's answer. >> >> Using RMS as the primary way to do file access was dain bramage unique >> (at DEC) to VMS, no? > > Not unique to VMS nor even to DEC. There was RMS-11 in PDP-11 operating > systems. I have the impression that predated VMS, though I may be off a bit. > RMS-11 always felt like an extension of FCS-11, the RSX file structure > library that introduced such things as file attributes and variable length > records. > > But this stuff is much older. RMS feels a lot like the various "access > methods" IBM created in OS/360. Fixed length records, variable length > records, the notion of "spanned" records (records that cross block > boundaries) and indexed files all appear in OS/360 well before VMS appeared. > > I think similar stuff existed elsewhere. CDC had record stuff in the 6000 > series mainframes, though that felt more like an add-on, one I never used. > But apart from that, they did have files with internal structure, called > "records" and "files", rather different from what OS/360 did. So the notion > of a file being a lot more than just a vector of bytes is quite old. > > One odd thing about IBM is that some of the access method mechanisms relied > on hardware capabilities. For ISAM files, you'd write the file data with key > fields in each sector, and use the search for key match feature in the disk > drives (to find the matching sector so long as you knew on which track to > look). That seems to be pretty unusual, though I've also seen it done by > Electrologica in Holland in the mid 1960s. > > paul > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
