|
History of TSO: Part Four
by Jim Moore
So here we are in the 21st Century, still using something
named TSO (actually now known as TSO/E, or TSO/Extensions). Every day, people
all over the world use TSO, invented in the late 1960s and perfected in the
1970s. Is this a good thing? Is there a better way? Is it time to retire the
old plow horse known as TSO?
Maybe, maybe not. In this concluding article, I will compare something
like TSO to more modern networks. Specifically, a comparison will be made to
what is known as a thin-client, client-server network.
Truly, in many ways, this is what TSO really is. Oh, the
term "thin-client" wasn't even heard of back in 1968. The word
"server", as applied to modern computing environments, probably
wouldn't have had much meaning in 1970 either. But somehow, those early TSO
time-sharing pioneers got it right.
They set up a networking environment where each client
was just a virtual hunk of memory called a TSU address space. Stop and compare
that with a thin-client machine connected to a contemporary network: A
dumb terminal, essentially, that is slavishly dependent upon something else to
service its needs. Hunk of memory, thin-client PC, whatever. Conceptually,
they're identical.
This is what a TSO session most looks like: Something that
is asleep more than it is awake. Something that fades into the background when
it doesn't need servicing. Something that jumps into the foreground only when
it needs to.
But Should It Still Be Called TSO?
For sure, the TSO name is an anachronism much like the "horseless
carriage" example from Part One of this series . The time-sharing option
is no longer optional for z/OS just as turn signals, which were once an extra
cost luxury item on cars, are no longer optional.
Yes. It should still be called TSO because the name still
fits. It has earned a place within the larger scheme of mainframe software,
particularly as an environment for developers.
Offloading Development to PCs
A few years ago, in the early 1990s, there was a large push
to offload mainframe development to far less expensive personal computers. From
this movement, a rash of PC-based mainframe emulators, compilers and simulators
arose. Cost savings were the primary reason to undertake such an offload. The
theory was that since PCs were so inexpensive and had unlimited amounts of
dedicated CPU time available to them, why not give each mainframe programmer a
downsized, inexpensive workbench?
I don't hear the cost saving reason much anymore. Why is
this?
Perhaps, like so many other things in the distributed world
of PCs, it has become clear that offloading development isn't quite as cheap as
first envisioned. Also, mainframe time has become less expensive and mainframe
hardware continues to modernize.
To be frank, I actually haven't heard much at all about
offloading mainframe development to PCs in the last few years. So much for that
fad.
History Lessons
In the earliest days of TSO, the most basic challenge was
solving the time-sharing problem. Initially, this was the marvel that wowed
IBM's customers. But as time passed, things like time-sharing came to be
expected.
This is how many things evolve. Eventually, after decades of
refinement, something like TSO becomes so stable, so solid, that it makes no
sense to replace it.
And that is where TSO is today. No longer cutting edge but
quietly humming along like some sort of electric wires behind the walls. Used
when needed, ignored when not. Progressing along with new hardware developments
but in a quite slow and incremental fashion.
TSO will be around as long as there is some version of MVS
around. Count on it.
|
