|
History of TSO: Part Two
by
Jim Moore
“Why the history lesson?”, you might be asking. My
answer would be: “Stick with me.” There are many valuable
nuggets of knowledge to be acquired by studying the history and
evolution of something like TSO.
Considering that TSO is still in use to this day, this has to
make it one of the oldest pieces of still-viable software on the
planet. Also, reading about its history reveals important and still-valid
characteristics of the TSO software: Program development, networking
and the concept of a teleprocessing monitor.
The Technical Underpinnings of TSO
The most descriptive word for software like TSO is conversational.
Conversational, in a shared computing context, means that each
TSO user logged on to an MVS system has their own address
space.
Present within a TSO session’s internal memory structure
will be every component of a standard MVS batch job or started
task. This includes things like TCBs (Task Control Blocks), an
entry in the ASVT (Address Space Vector Table), an ASCB (Address
Space Control Block) and JCL. TSO sessions also have their own
unique mnemonic designator within the scheme of MVS dispatching:
TSU (Time-Sharing User).
The hallmark of a conversational environment is the long term
holding of what could be a shared resource. That is, a resource
(file, memory, source member) is held onto as long as a user is
using it. The term for this is think time. Something like editing
a program (which can take many hours of think time) would be a
good example of a conversational task. For the entire time that
a TSO user is editing a file, an exclusive lock is maintained on
the file being edited. No one else can edit the same file while
the original TSO user edits it.
To underscore the conversational
nature of TSO sessions, compare TSO to IBM’s other classic
online teleprocessing monitor: CICS, introduced by IBM as an
extra cost software package in July,
1969.
CICS is said to be pseudo-conversational. In the simplest sense,
the difference can be seen in the accompanying graphics.
Figure
1 - The Conversational TSO teleprocessing model
TSO requires that a server address space commonly referred
to as TCAS (Terminal Controlling Address Space) be
active on the MVS operating system. The TCAS
server is constantly polling its chain of attached TSO address spaces looking
for input (typically, the press of what is called an AID (Attention Identifier)
key, usually the Enter key). Each TSU on the TCAS chain is also a discrete "unit
of work" on the operating system's dispatch queue.
When a TSO user is
not pressing an AID key, the operating system "swaps
out" the TSU address space. This conserves some resources
but still, each TSU requires significant operating system
servicing.
|
Figure 2 -
The Pseudo-Conversational CICS Teleprocessing Model
Unlike the TSO model in which each user
has a dedicated address space, the CICS model has a single address
space (commonly called a "CICS region") with a huge
number of dumb terminals connected to it.
It is a task-based model
in that when a terminal user initiates a piece of work,
a pre-defined task is run within the CICS region. Typically,
the task is programmed to display data on the user's terminal
screen and frequently, the task allows the displayed data
to be updated. However, during the elapsed time that occurs
between the initial request to view data and the eventual
update of the data, no locks are held (unless EXPLICITLY programmed)
and other terminal users are free to inquire against the
same data.
What this means is that
during the potentially long think time period,
the CICS terminal user is not holding on to data resources
in the same manner as a TSO user would be.
This is referred to as
a psuedo-conversational task-based environment. |
With CICS, all terminals sign-on to a single address space. The
CICS software manages this multi-tasking, concurrent terminal access
by using a standard API. Borrowing from database terminology, this
a one-to-many relationship: One CICS region (address space), many
users attached to it.
TSO is a direct one-to-one relationship: One user, one address
space.
Because of this, even
on a large MVS mainframe, TSO consumes far too many finite resources
to be a viable application platform for
a large group of users. This is why CICS followed on to TSO and
became the dominant teleprocessing monitor for heavy-duty, high
volume business applications—it was far less expensive in
terms of machine utilization. This is still true today.
TSO as a Development Environment
Once the time-sharing problem was adequately solved, CICS began
to stabilize as the application teleprocessing monitor of choice
for business applications. What role remained for the fledgling
TSO software? As the 1960s rolled into the 1970s, TSO slowly
became the de facto development environment for what was then
known as OS/VS2 (formerly OS/360-MVT). This is the role it has
played ever since.
From the late 1960s
until 1972, the most common type of terminals attached to either
TSO or CICS were of the paper-based, hard-copy
variety. The 327x line of CRT (Cathode Ray Tube), glass-screened
terminals weren’t introduced by IBM until 1972.
To a pre-1972 TSO user, the line-mode orientation of the interface
was perfectly natural. It was considered a huge improvement over
the more traditional punched-card, keypunch mode of working with
all of the clumsy coding sheets and overnight turn-around time.
When such a paper-based terminal user issued the TSO command:
LIST ‘dataset.name’
on an IBM 1050 or a
Telex machine, the entire contents of the file would be listed
on paper, one line at a time—no matter
how many lines the file contained.
Once glass-screened 327x dumb terminals were attached to TSO,
modifications had to be made to the underlying TSO and networking
access method software.
This is why, to this
day, three asterisks display at the bottom of every mainframe
TSO attached “green-screen” when
the screen fills up with line-mode messages. The three asterisks
are an accommodation to the fact that the terminal doesn’t
have a large supply of continuously fed paper running through it.
It might seem unbelievable to people who work with TSO/ISPF today,
but for most of the 1970s, programmers worked at the now-primitive
looking Ready mode. This is all the TSO Terminal Monitor Program
(TMP) ever displays to indicate that it expects some kind of command
input: Ready
If you compare something like the line-oriented Ready mode of
TSO to the equally line-oriented A: prompt of 1980s vintage MS-DOS,
the similarities should become clear.
Note that an A: prompt
was deliberately used above as a reminder that for most of the
1980s, PCs didn’t even have internal
hard drives (or C: drives).
Ah, progress!
Conclusion of Parts I and II
“
So, what about ISPF?” you might be asking. “I work
in ISPF all day, not TSO.”
Valid point. Rest assured that the TSO Times plans an exquisitely
detailed history of ISPF in upcoming issues.
Trust me on this: An excellent way to advance ones knowledge in
the TSO/ISPF world is to pry apart TSO from ISPF and examine each
one separately, as unique but related entities.
And the absolute best
way to do this is to consider their evolutionary history. Envision
a time when there was no ISPF. Imagine the thought,
hard work and creativity that went into solving that long-ago time-sharing
riddle. Learn how ISPF came along in the late 1970s to solve the “command
line” problem that Windows, in an almost exactly parallel
way, later solved for the “C:” prompt world of MS-DOS.
You will reap the benefits daily, especially, if you have a talent
for TSO/ISPF programming.
Follow this series, see what I mean.
Visit http://www.nadcomm.com/ - North
American Data Communications Museum for historical images
1960-vintage paper terminals.
|
