From mboxrd@z Thu Jan 1 00:00:00 1970 From: cowan@mercury.ccil.org (John Cowan) Date: Mon, 21 Mar 2016 20:48:00 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160322001337.GE86793@eureka.lemis.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <20160321120634.GK15457@mercury.ccil.org> <20160322001337.GE86793@eureka.lemis.com> Message-ID: <20160322004800.GA25603@mercury.ccil.org> Greg 'groggy' Lehey scripsit: > > Classical sequential files, however, were simply random-access files > > such that seeking to line n was just a matter of seeking to byte > > n * MAXCHARSLINE. The last time I actually used such a thing was > > on an early Tandem system when I was implementing the Software > > Tools. > > You're presumably not talking about a Tandem format here. I assumed that was the byte structure, but perhaps it wasn't. It was the format used for Fortran formatted sequential files and Cobol ORGANIZATION IS SEQUENTIAL files. So yes, a Tandem format. > Were you working with Denis Winn? I wasn't at Tandem, but at a Tandem customer, Kidder Peabody. > Presumably you *are* talking about Tandem's format here. I always > looked at it as an indication of how badly optimization attempts could > go wrong. The format limited line length to something less than 256 > bytes (exact length was content dependent). The lines were split into > groups of up to 30 bytes, 15 bytes content and up to 15 bytes trailing > spaces. And this was the reason: it was a piss-poor attempt at > efficient storage. The only way to access it was with a special > library with procedures like EDITREAD and EDITWRITE. I still have a > number of these files, and there's no easy way to convert them. Right. Our implementation of getchar for the Software Tools (Ratfor version) checked the file format and either did sequential reads or EDITREADs. As I remember, though, you could only update existing files with the library, you couldn't create new ones from scratch, which was why we needed to use both formats -- all output files were sequential. Of course, you could edit files with the Software Tools editor rather than the Tandem editor, and then they'd come out as sequential files. We also wrote a shell to complement the Software Tools, and a event-driven pipe server that kept a table of all the pipes in the system. If you opened $PIPE.#new, it would allocate a new pipe named $PIPE.Pnnnnn, and then you could open that for reading or writing. Each pipe had a one-line buffer, reads would hang if the buffer was empty and writes would hang if it was full. The shell was more or less a Bourne shell, though not 100% compatible: I remember that the standard prompt was ::, pronounced "quadpoint". -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org The first thing you learn in a lawin' family is that there ain't no definite answers to anything. --Calpurnia in To Kill A Mockingbird