|
The History of IBM Operating Systems
From: geoff@utstat.toronto.edu
Date: Tue, 3 Oct 89 22:01:20 EDT
Subject: Re: more like tragicomic...
The history of IBM ``operating systems'' is really not difficult. Ian
could give a definitive history, but I'll sketch it.
The original (supported) OS for the IBM 360 was DOS (Disk Operating
System, there having been COS and TOS if I remember right), every bit
as bad as one would expect from the name, and worse: manual file
allocation with no sanity checking, files with fixed line lengths,
etc.
Next was OS/360, which may not have even had multiprogramming; this was
in the mid-sixties. Eventually this became MFT, which ran Multiple
Tasks of Fixed size, then MVT, which ran Multiple Tasks of Varying
sizes, and finally MVS, which runs Multiple tasks of Varying size and
is Secure, by IBM standards. You can still scratch VTOCs (Volume Table
of Contents, sorta like superblocks, partition tables, directories and
i-lists all rolled into one bundle-o'-fun) at will, so "Secure" is a
relative thing.
OS/360 is the origin of JCL (Job Control Language), as we think of it,
and thus the syntax of the UNIX dd command, by analogy to the OS/360
//DD statement. See Jon Bentley's comments about how in the old days,
Real Programmers (TM) swaggered up to the key punch and knocked off
nine cards of JCL to do what we know do with "summarize jan.summary". JCL is a crazed assembly language programmer's idea of
what a command language should look like: verbose, tedious and
error-prone. AND UPPER CASE.
Some time during this evolution, IBM added a bag-on-the-side to offer
token "TimeSharing" as an option (TSO, pronounced tee-slow; there are
invisible "l" and "w" in "TSO"). Originally TSO just turned
interactive commands into batch jobs, but Ian tells me that has
progressed to the point of actually being timesharing, of a poor sort.
TSO is famed for its slow response and lack of power, thus the famous
Steve Johnson quote: ``Using TSO is like kicking a dead whale along
the beach.''. See the TSO shell, tso(6), written here by Mike Tilson;
it appears on the V8 distribution too in VAX binary form, but I have
the source somewhere and the manual page will give you the flavour of
it, though not the full horrific experience of actual use.
Even within IBM, some people recognised early that OS/360 and kin were
trash, and IBM developers at its Cambridge Research Lab developed a
system programmer's tool, CP/67 aka VM, which could emulate the bare
hardware of a 360 or 370, thus allowing multiple virtual machines to
run on the same hardware, so you could mix DOS, production OS/360, a
test OS/360, CMS (see below) and in later years UNIX simultaneously
within a single machine. Running UNIX under VM is nice, though, since
as long as VM doesn't crash, you can run completely isolated test
versions of UNIX, boot and shutdown machines, and all from home.
They also wrote a CP/M-ish operating system called CMS (Cambridge
Monitor System, later revised to Conversational Monitor System) that
ran under VM (thus VM/CMS). By comparison with MVS, CMS was wonderful;
by today's standards it's CP/M with a floppy disk, card reader, card
punch, line printer and all in EBCDIC. As with non-UNIX micros, there
is *no* communication between virtual machines (e.g. CMS users, each of
whom get a single virtual machine running CMS), except by punching
virtual cards at someone's virtual card reader, and oh yes by mounting
someone else's floppy only for reading. And be careful not to punch
too much, those virtual card trays only hold 5,000 or so virtual cards;
the rest go on the virtual floor.
While that was going on, another group inside IBM wrote a real
interactive timesharing system, unlike TSO, called TSS, which they
spent a vast amount of time, money and effort on, then pretty much
abandoned, since interactive timesharing was clearly a fad. Bell Labs
was already using it, and many of the Bell Labs ports of UNIX to the
370 family use TSS as a lower layer to run the bare hardware.
From: Beverly Erlebacher
Date: Wed, 4 Oct 89 02:12:18 EDT
Subject: Re: more like tragicomic...
> The original (supported) OS for the IBM 360 was DOS (Disk Operating
> System, there having been COS and TOS if I remember right), every bit
> as bad as one would expect from the name, and worse: manual file
> allocation with no sanity checking, files with fixed line lengths,
> etc.
DOS was preceded by BPS (i forget the meaning of this acronym), BOS
(Basic Operating System - loaded from cards i think) and TOS, the
Tape Operating System, which predated the ready availability of
disks. i think variable length records were supported in DOS, but
they were (and are) such an incredible pain to manipulate correctly
that no one in his right mind used the feature except to ensure
their own job security.
the manual file allocation is correct. for each file used by a
program you needed one //DLABL card and as many //EXTENT cards as
you wanted to allocate discontiguous extents (usually one). the
//DLABL card mapped the program's name for a file to the real name
(label or disk label) of the file on disk. this was actually a
useful idea. on the //EXTENT cards you specified starting cylinder
and track and allocated size. i dont remember if you specified
volume (these were removable disk packs) or whether you had to
specify the size of a file you were planning to read only. the
VTOC helped you figure this out.
it's true that you could get the disk drives to walk. the easiest
method was to allocate the two sort work areas on the inner and
outer cylinders of the same pack. this might seem like an
outstandingly stupid and inefficient idea at first, but recall that
there was no sanity checking, so if the file you were planning to
sort far down a long job stream happened to be a lot larger than
you expected, you could clobber something useful. hence, mount a
scratch pack for sort work area. disk was very expensive in the
old days. the place i worked as a scheduler on a 360/40 had 3
drives, each of which took a 20M disk pack (about 16" diameter, 12
plates). we had a nice set of shelves for the disk packs and used
a lot of tapes for intermediate files in job streams.
DOS JCL was much simpler syntactically than OS JCL. DOS was
intended to run on the smaller models of the 360. it was succeeded
by DOS/VS (virtual system) and DOS/VSE (virtual system extended).
the original DOS was a single-tasking OS. this wasnt all that
unreasonable on a line of machines that included members with 16k
(8k?) of memory. the machine i used had 128k and we ran a non-IBM
print spooler which was quite useful since most job streams
involved a small amount of updating master (disk) files from boxes
and boxes of (punch card) transaction records, followed by long
sequences of sort and report. the spooler overlapped these 2
activities very nicely, and you could see by the gestalt of the
patterns of lights on the face plate when the spool area was full
and the spooler was holding back the other task while it
desperately pumped output to the printer.
> Next was OS/360, which may not have even had multiprogramming; this was
> in the mid-sixties. Eventually this became MFT, which ran Multiple
> Tasks of Fixed size, then MVT, which ran Multiple Tasks of Varying
> sizes, and finally MVS, which runs Multiple tasks of Varying size and
> is Secure, by IBM standards. You can still scratch VTOCs (Volume Table
> of Contents, sorta like superblocks, partition tables, directories and
> i-lists all rolled into one bundle-o'-fun) at will, so "Secure" is a
> relative thing.
MFT = Multiprogramming with a Fixed number of Tasks
MVT = Multiprogramming with a Variable number of Tasks
MVS = Multiple Virtual System
MVS was preceded by VS/1 (virtual system 1). MVS was called VS/2
for a short time. MVS was the result of growth by accretion of
OS/360, and by 1980, when i worked on an MVS system, it was an
estimated 6 million lines of assembly code. it was probably mostly
written in PL/S by that time, but source licensees were usually
given the assembler output of the PL/S compiler, according to
believable sources.
i never worked with MFT or MVT, but i did work with an IBM GSD
machine whose OS showed a lot of influence of DOS and MFT. its
"communications control program" (what you ran interactive tasks
under) was said to be a cut down version of CICS. it had generally
DOS-like JCL, but could do its own file space allocation, although
you could override it. it lost the capability for multiple extent
files however.
> OS/360 is the origin of JCL (Job Control Language), as we think of it,
> and thus the syntax of the UNIX dd command, by analogy to the OS/360
> //DD statement. See Jon Bentley's comments about how in the old days,
> Real Programmers (TM) swaggered up to the key punch and knocked off
> nine cards of JCL to do what we know do with "summarize >jan.summary". JCL is a crazed assembly language programmer's idea of
> what a command language should look like: verbose, tedious and
> error-prone. AND UPPER CASE.
well, did you ever see a keypunch with lower case?
it's not uncommon in dp work to use 8 or 10 different files in a
program. most of them will be tables of codes of various kinds
with their translations so you can validate input and emit
comprehensible reports. OS JCL is superficially confusing, but it
isnt very hard to learn. i found a teach yourself JCL book in the
company bookcase and after a few hours study i too could swagger up
to the keypunch (actually, it was a 3277 by that point) and knock
off a few dozen card images, to the considerable awe of my
colleagues who were too lazy to read the book and would rather
spend time looking for another piece of JCL that already did
something similar and fiddle it until it did what they wanted.
> Some time during this evolution, IBM added a bag-on-the-side to offer
> token "TimeSharing" as an option (TSO, pronounced tee-slow; there are
> invisible "l" and "w" in "TSO"). Originally TSO just turned
> interactive commands into batch jobs, but Ian tells me that has
> progressed to the point of actually being timesharing, of a poor sort.
> TSO is famed for its slow response and lack of power, thus the famous
> Steve Johnson quote: ``Using TSO is like kicking a dead whale along
> the beach.''. See the TSO shell, tso(6), written here by Mike Tilson;
> it appears on the V8 distribution too in VAX binary form, but I have
> the source somewhere and the manual page will give you the flavour of
> it, though not the full horrific experience of actual use.
actually, it's worse than that. i never tried to write TSO scripts
(why do i remember them being called CLISTs?) but some good
applications were written for it, notably SPF. SPF was a
block-mode terminal screen editor and had a lot of other useful
functions. it was really more like a shell in some ways. you could
tick off from the equivalent of a directory listing the files you
wanted to delete, browse, edit, print, execute etc, something like
the hi shell (vsh). similar programs exist for PCs now, and users
seem to like them. SPF was later expanded to ISPF. at some point
it became possible to write your own screen formats ("panels") and
have SPF drive them, which was a handy way of putting up flashy
looking simple applications. i liked SPF until i got into unix.
the editor was a vast improvement over the card images i was making
with the diskette keypunch (3741) before i got into MVS and
terminals for programmers.
i should clarify and correct my use of the word "files" in the
paragraph above. "files" are strictly data files, called datasets
in MVS parlance. there is also a thing called a partitioned data
set or PDS in which reside source, objects, executables, JCL
scripts (called "catalogued procedures" i think), etc as totally
different entities from actual data files. what i meant above by
files was PDS members.
as far as speed, the last thing ibm ever wanted to do was to write
fast software. their solution to slow software was to tell the
customer to upgrade to a more expensive leased model and their
ideal was for the machine to spend 75% of its time executing system
software. this isnt a difficult goal since ibm's method of doing
anything is to put another layer on top of existing stuff, so you
have e.g. MVS running IMS (hierarchical database manager) with an
SQL relational faking interface on top with a report writer on top
of that, for example.
i havent used CMS or the other things geoff mentioned so i cant
comment on them. IBM's concept of interactive computing is that
this is something tricky, delicate, special, complex to program and
for the users only. they usually provide a big bulky
communications manager to stand between the users and the OS to
handle interactive stuff. some examples are CICS and IMS/DC.
these managers usually fake up multitasking in a crude and insecure
way on top of and separate from the multitasking built into the
"real" OS. they also have a certain model of interaction that is
not suitable for programmers, but is fairly natural to a user
making inquiries or doing data entry. the way this model works is
an alternation of putting up a screen format (a compiled entity
which paints a full block mode screen, with some editing which
controls the nature of what the user can fill in the blanks with),
followed by a program which interprets and acts upon what the user
entered, and decides which screen format to put up next. on the
GSD machines i am most familiar with, you have an actual user
program figuring which screens to put up next and what to do with
the input, but under MVS/IMS/DC (DC == data communications: the
computer interacting with a terminal is always regarded as
"communications") screen format and progrm alternate: when the
user hits return, the user's input is queued up, a program is
loaded to handle it, the program terminates after queueing a
request to put up the next screen format. state, including program
and screen format name, is passed by (please remain calm) the
contents of non-display fields in the screen format.
it was interesting remembering this stuff this evening. after many
years working on ibm systems, i found unix to be very alien and
confusing when i first encountered it.
any questions from the class?
|