On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote: Sorry, I don't understand this. Can you give an example of file-as-record and directory-as-record? Some of it suggests MVS, but not quite. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA

I picked up a book in the early nineties called File Structures or File Systems: I've forgotten which, because I didn't read it as much as I had intended. It covered the IBM MVS mainframe dataset file and directory structure and the Unix file and directory structure. And yes, I was referring to the MVS dataset, as much of it as I can remember from that book. (I sorry I can't recall the exact title: the book is somewhere at the bottom of a pile of other books from my last move several years ago.) Wesley Parish Quoting Greg 'groggy' Lehey <grog(a)lemis.com>: "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

On 9/8/17, Greg 'groggy' Lehey <grog(a)lemis.com> wrote: At least in the IBM world, disk drives originally didn't have their tracks formatted into fixed-length sectors as they are today. Early on in the business world, everything was record-oriented. Except for the very largest ones, computers didn't have the either the speed or the memory to do database processing as we now know it. For most business shops, there was sequential file processing, random access (where you had to know the cylinder and head position of the record you wanted), and indexed sequential access (by the value of a key field in the record). Disks in those days (pre-mid 70s) were not formatted in fixed-length sectors as they are today. Instead, records could be arbitrary length (limited by the capacity of a single disk track, of course) and had three fields: a count field containing the number of bytes in the record, a key field for indexed access, and a data field. This format was called CKD (count/key/data). On IBM disks, records were addressed by a number of the form CCCHHRR, where CCC is the cylinder, HH the head, and RR the record on the track (for the data cell drive, there was also a two digit bin number). The disk controller could also do a "seek by key" operation. This would scan the track for a record whose key field matched the given key. It was used to implement indexed sequential access. For System/360/370, the OSes for the smaller, slower systems, such as Basic Operating System (BOS) and Disk Operating System (DOS and DOS/VS) did not have an on-disk file system at all. You had to manually allocate the files on the disk and you used directives in job control language (JCL) to tell the OS where your file was and to assign it a logical unit number for the program to use (FORTRAN's I/O reflects this). The OSes for larger systems such as OS/MVS (and perhaps its predecessor, OS/MVT?) had a catalog file that could automate the process of assigning files to locations on disk. This was the closest these OSes came to a modern directory-oriented file system. In the business world this is not as grim as it might seem. Most businesses had a small number of files that didn't change very often. For example, a college has accounts payable/receivable, student academic records, alumni/charitable giving, and payroll and personnel. These get allocated once and, provided the initial disk allocation is sufficient, don't have to move. On the programming side, there wasn't either the memory capacity or processing power to implement a modern disk file system. One of the first computers I worked with was a System/360 model 25 running DOS/360. The machine had 48K of core memory, 12K of which was for the OS, leaving 36K for programs. No virtual memory. The OS had an 8K resident kernel and two 2K overlay areas: the physical transient area (for controlling hardware; the forerunners of what we now call device drivers) and the logical transient area (for the parts of program I/O that had to operate in privileged mode, and for most OS system service functions). For I/O, each program contained library routines called "access methods", which took logical file I/O operations (open, close, read, write, seek, etc.), built the appropriate I/O channel programs, and executed the EXCP (execute channel program) OS primitive. The access methods operated on logical I/O unit numbers, which as previously noted were associated with places on-disk via JCL statements before the program started execution. The access methods were SAM (Sequential Access Method; records read/written in on-disk order), DAM (Direct Access Method; allowed seeking to an arbitrary record using CCCHHRR address), and ISAM (Indexed Sequential Access Method; allowed seeking to a record by key, and then reading/writing sequentially from there). The access methods and their capabilities mirrored the CKD disk format of the time. As disk hardware became denser and faster, and computers got more memory, it became more efficient to format the disk as a set of fixed-length sectors, which could be packed more densely and accessed faster than CKD records. Record blocking and unblocking was moved to the OS or application. Indexed access could be accomplished a lot faster using B-trees in the file. UNIX took the final step in this evolution by providing exclusively byte-stream I/O in the OS, and leaving record processing up to the application. Those of us from the record-oriented world found this a pain in the butt at first (application programmers were forced to roll their own record processing, something that the access methods did for you in the OS/360 world). But by 1990 it was generally recognized that stream I/O is the more appropriate OS primitive. -Paul W.

Amen. There were a number of things that really sucked at the time. My least favorite: time sharing systems that didn’t allow type-ahead. Kids these days...

TOPS-10 allowed type-ahead, with the caveat that if a program exited with an error, it would intentionally clear the TTY buffer. Something I actually sorely miss. IIRC, the type-ahead buffer was only around 80 characters. If you exceeded it, it beeped at you ;) On 9/9/2017 9:04 AM, William Cheswick wrote:

What, you didn’t like IBM 2741 terminals that mechanically locked the keyboard?

On Sat, 9 Sep 2017, Steve Johnson wrote: Aah, well I remember the times that I felt like leaning over to hit the Big Switch on our 360/50, when the console jammed... That was the Blue Button, of course, not the Red Switch (we weren't allowed to pull that). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

below... On Sat, Sep 9, 2017 at 12:34 AM, Steve Johnson <scj(a)yaccman.com> wrote: ​Point taken and sort of...TSS/360 and MTS was not (quite) as bad (although it could be if you use the batch processing system), but Steve is right... the idea of persistence was really not something people considered as 'easy' because it usually cost them money (real or allocated from the computer center). So I suspect part of it was the economics of storage at time. On line (magnetic) storage was way more expensive than cards. Its has been pointed at the the original PDP-7 Ken used did not have a disk on it, it was custom special DEC's CSS group had splicing a PDP-15 disk to it. The disk unit itself was manufactured by someone else (as were most/many of DEC's disks for years). Clay Christensen in "*The Innovator Dilemma" *has curves that actually start a few years later when he studies the disk drive industry. But its the just part of the same effect he is talking about. The key is the what UNIX was doing was not considered practical by the mainframe folks, so people did not consider it. It was a resources to be protected (and to an extent, hoarded maybe). Moore's Law, et al, was the engine that allowed the UNIX innovation to really see light. The way the mainframes were doing things just did not make functional sense, but until it was economical to do it otherwise - we were stuck. As Steve says... it really was mind blowing for making things like this easy. Clem

On 8 Sep 2017 18:28 -0400, from usotsuki(a)buric.co (Steve Nickolas): Wasn't it MS-DOS 2 that introduced such advanced features as directories, pipes and general console I/O redirection? Of course most software that ran on top of DOS broke much of the redirection niceness by addressing the console directly via video memory access... -- Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)