x'15' (21): Course notes: "Two Strange APIs" (2013)

posted Apr 29, 2014, 6:23 AM by Jeff Ogden   [ updated Jun 13, 2014, 12:09 PM ]
MTS line files were mentioned as one of "two strange APIs" in a PowerPoint slide for a lecture for Geoff Kuenning's operating systems class (CS 134) at the Harvey Mudd College Department of Computer Science, Claremont, California.

Slide #25

E-mail exchange

I exchanged some e-mail with Professor Kuenning:

From: Jeff Ogden
Subject: Michigan Terminal System
Date: April 25, 2014 12:22:49 PM EDT
To: geoff


I was a systems programmer and later Associate Director at the University of Michigan's academic Computing Center in the 1970s and 1980s. I also worked with and for the Merit Network, although that association didn't start until late 1974 or early 1975, so I don't think we would have crossed paths while you were working at the MSU Computer Laboratory.

I just stumbled on the following slide presentation that mentions the MTS file system and have some comments/clarifications about the "strange" API.

Slide 25 at http://www.cs.hmc.edu/~geoff/classes/hmc.cs134.201209/slides/class20_disks3_beamer.pdf 

Michigan Terminal System (60's)

> Files divided into variable-length “lines”   
• Even binary files made up of lines
• Each line numbered (fixed-point, 6 fractional decimal digits)   
• Could read by line number or by “next line”
• Could write by line number (inserting in middle if appropriate) or (?) just append at end
> No user access to devices   
• E.g., print by creating file, then handing to OS
• Slightly problematic when terminals introduced. . .

MTS was in use at the UofM from 1967 through 1996 and elsewhere through 1999. It is still available and runs under Hercules/390 and other emulators and who knows it might even still run on real IBM hardware, if anyone cared to try. MSU ran MTS for a time, but that was not until the mid to late 1980s or possibly even the early 1990s.

The MTS file system supported two types of files, line and sequential. The slide is talking about line files.

MTS line files used a 32-bit signed binary integer as the line number. The integers were scaled by 1000 to have three digits following the decimal point (n.nnn).

Yes, one could "just append at the end" of a file, although this was not the default for line files, but was the default for sequential files.

Users did have direct access to some devices including their own terminal and tape dives, but because the actual terminal or tape drive in use changed from session to session such access was discouraged and end users accessed these devices using "pseudo device names" which did not change. For a terminal session the terminal device was *MSOURCE* and *MSINK*. For a batch session the input stream was *MSOURCE*, while the output stream was *MSINK* or *PRINT*. Users could reserve a tape drive and assign a pseudo device name to it using the $Mount command. A typical name might be *T1*. End users had access to disk files, but only indirect access to the disk drives on which the files were stored.

Output from both terminal and batch sessions could be directed to a printer using the *PRINT* pseudo device which directed the output to the HASP spooling system and later its replacement, the Resource Manager (RM). Programs could access *PRINT* directly:
    $RUN  myprogram  SPRINT=*PRINT*
Or indirectly:
        $RUN  myprogram  SPRINT=somefile
        $COPY  somefile  TO  *PRINT*

Lines in line files could be from one to 32,767 bytes long. Writing a zero length line had the effect of deleting the line. It was possible to insert new lines at the start, in the middle, or at the end of a line file. It was possible to overwrite an existing line file line with a new line of the same or a different length.

MTS programs could read and write line files accessing the line numbers directly by specifying the @Indexed I/O modifier. If that modifier was not specified, then the line number parameter would not be used and the "next" line would be read or written. The MTS command language also allowed starting and ending line numbers and a line number increment to be specified by appending information to the file or device name (FDname).

    where start, end, and increment
    could be numeric values,
    the symbolic values FIRST, *F, LAST, *L, MIN, MAX, or
    a symbolic value with a numeric value added or subtracted.
    FIRST and *F specify the line number of the first line in the file.
    LAST and *L specify the line number of the last line in the file.
    MIN and MAX specify the smallest and largest possible line numbers.
    start defaults to 1 if not specified.
    end defaults to MAX if not specified.
    increment is ignored for reads and defaults to 1 for writes.
For example:

$COPY  somefile  TO  someotherfile
would copy lines starting with line 1 from somefile to someotherfile also starting at line 1 and moving on to line 2, 3, 4, …, possibly replacing whole numbered lines, but not fractionally numbered lines in someotherfile depending on what lines already exist in someotherfile.

$COPY  somefile(FIRST)  TO  someotherfile(LAST+1)
would copy lines starting with the first line in the file (which might be less than or greater than 1) to the end of someotherfile.

$COPY  somefile(FIRST)@-trim  TO  someotherfile@I@-trim
would make an exact copy of a file. The @-trim I/O modifier keeps the system from removing multiple trailing spaces from a line. The $DUPLICATE command was a simpler way to make an exact copy of a file.

Sequential files, unlike line files, always start with line 1 and line numbers always increase incrementally with no fractional line numbers. Reading a sequential file always starts with line 1. Writing a sequential file always appends lines to the end of the file.

Wikipedia has more information:  http://en.wikipedia.org/wiki/MTS_system_architecture#Device_independent_input/output

Somewhat more general information:  http://en.wikipedia.org/wiki/MTS_system_architecture

More general still:  http://en.wikipedia.org/wiki/Michigan_Terminal_System

Something with a more academic bent: "A file system for a general-purpose time-sharing environment", G. C. Pirkola, Proceedings of the IEEE, June 1975, volume 63 no. 6, pp. 918–924, ISSN 0018-9219

A reply

From: Geoff Kuenning
Subject: Re: Michigan Terminal System
Date: April 29, 2014 2:53:56 AM EDT
To: Jeff Ogden


Thanks for the note and the details.  I had no idea that MTS lasted so long!

I'd also forgotten about some of the finer points, such as the ability
to copy subsets of lines and the predecessor to stdin/stdout.  It's nice
to get some corrections.  A lot of the point of that slide (and the
following one) is to make sure students understand that there's more
than one way to design things, and to twist their minds a bit so that
they won't fall into a rut ten years from now.  MTS definitely had a
different approach!

A comment from Mike

From: Mike Alexander
Subject: Re: Fwd: Michigan Terminal System
Date: April 29, 2014 1:12:02 PM EDT
To: Jeff Ogden, mts-comments@umich.edu

I wonder where this comment came from:

• Slightly problematic when terminals introduced. . .

Terminals were never "introduced", they were there first.  Batch was introduced, not terminals.  The file system was designed around the use of terminals.

We also made at least two mistakes in the design of the file system:
  • zero length writes delete lines so there can't be a zero length line in a file
  • fine names are only 16 characters long when there was room on disk for 44 characters.