MVS TOOLS AND TRICKS OF THE TRADE
                           APRIL 2003

                                      Sam Golob
                                      MVS Systems Programmer
                                      P.O. Box 906
                                      Tallman, New York 10982

Sam Golob is a Senior Systems Programmer.  He also participates in
library tours and book signings with his wife, author Courtney Taylor.
Sam can be contacted at sbgolob@cbttape.org.  Information about the CBT
MVS Tapes can be found on the web, at http://www.cbttape.org.


TSSO REVISITED

      Free tools have their advantages and disadvantages.  Let's look at
advantages first.  Last month, we discussed what happened to IBM's
"unofficial" MCNVTCAT tool for generating DEFINE NONVSAM statements from
VSAM catalog entries.  We saw that a user-written replacement, Alastair
Gray's RCNVTCAT REXX exec, has distinct advantages over IBM's tool.
First, RCNVTCAT works better than MCNVTCAT, and it's easier to use.
Second, IBM's MCNVTCAT was not written by IBM's programmers who write
the MVS operating system, but by the CBIPO software distribution folks.
That put MCNVTCAT into a category (like Field Developed programs) where
IBM was not obligated to support it.  Third, when the CBIPO went away,
so did MCNVTCAT.  But Alastair Gray, who wrote RCNVTCAT, can usually
be persuaded to improve his tool.  Alastair is not bound by IBM's
internal bureaucracy and contractual obligations.  So it's more likely
that you can get support service from this private author than from IBM,
at least in such a case.  I recently asked Alastair myself for an
improvement, and he made the requested code change for me within a
couple of days.

      The "down side" of using free tools, is that sometimes they stop
working when IBM comes out with a new release of the MVS operating
system (OS/390, z/OS, etc.), and it's up to a knowledgeable user to fix
the tool for the later version of the system.  Sometimes a knowledgeable
(and willing) programmer is available, and sometimes not.  So unless you
yourself have the know-how to fix the tool, you can be stuck.

      But often, the power of numbers comes to the rescue.  This is
especially true when the tool is in use by large numbers of people at
many installations.  In that case, more people have a vested interest in
keeping the tool working, so if one person (perhapes an original author)
doesn't fix it up, it's very likely that someone else will.  This
happens very frequently in the history of the more popular user-written
tools.  So we've seen some pros and cons.

      I think that an outweighing factor in favor of using user-written
tools, is the presence of an active exchange forum where people send
updates, and where prospective and current users can look for them.
A tool which is distributed on such a forum has a greater likelihood
of being fixed or improved in a timely manner.  I'll explain with an
example.

      A very good exchange forum for free MVS tools is the CBT MVS
Utilities Tape and the CBT Overflow Tape, whose materials are (also)
available online at www.cbttape.org.  This forum allows the users of a
tool to look online and see if an improved version has been made
available.  And if one of the users has made an improvement himself,
he/she has a place to send it in, so other people can use it, test it,
and derive benefit from it.  Without having such a forum, the tendency
is that one person makes an improvement to a tool, and that improvement
does not easily find its way outside that programmer's own shop.  Even
a person's personal web site doesn't often enjoy widespread public
access, but the Internet has made an improvement in the distribution of
an individual programmer's works.  Still, it is better to have a place
where everyone knows they should look, like the CBT Tape web site.


THE PLACE OF TSSO

      Today, I'm going to talk about a tool called TSSO (Time Sharing
Subsystem Option).  TSSO has been used at many shops over the years,
and it illustrates the ups and downs of running user-written software
very well.

      The basic idea of TSSO is to create a console environment (which
runs as an MVS subsystem) where TSO line-mode commands can be executed.
The TSO command (preceded by a subsystem character) is entered on an MVS
console, similarly to when a TSO command is entered at the command line
of a TSO session.  And the resulting displays from the command (if any),
which have to be in the form of PUTLINE line-mode output (no Fullscreen
TPUTs are allowed), get written back to the console via WTOs.  However,
whether display output is produced or not, the command will still
perform its action.  For example, if you use IBM's TSO RENAME command to
rename a dataset, no display output is produced, but the dataset is
nevertheless renamed.

      TSSO is the brain-child of Bill Godfrey, who wrote the first
version back around 1980, and Bill's version of TSSO, now on CBT Tape
File 306, still does exactly what I've described.

      You can glimpse the enormous potential of having such a tool.
For example, you can use IBM's RENAME, DELETE, and LISTD TSO commands to
do dataset renames, deletes, and displays from an MVS console in a
pinch.  And with the free PDS 8.5 command package, you can compress a
dataset, or copy dataset members to a different dataset, also from an
MVS console.  That's because the COPY and COMPRESS subcommands of the
PDS 8.5 package will invoke IEBCOPY in foreground TSO, and TSSO creates
a TSO-like environment at the console.  And these same operations which
are normally done only under TSO, now can actually be carried out
without TSO being "up".

      An enormous improvement to Bill Godfrey's TSSO was made by Marc
Schare in 1985-6 (Marc was then working at Bellcore) who took advantage
of TSSO's TSO-like console environment so he could use CLISTs (now REXX
execs too) and intelligently reply to MVS commands with them.  Marc
created a genuine "automated operations" environment built on top of the
basic TSSO structure.  Marc implemented sets of pre-assembled "AOF
Tables" in TSSO, to automatically and intelligently respond to certain
console messages with given replies.  To protect the new power of this
TSO-powered console environment against unauthorized use, Marc also
implemented the concept of "console security" inside TSSO, years before
IBM itself did that in native MVS.  TSSO makes it possible to protect a
console (using RACF, ACF2, or Top-Secret), so you have to logon to that
console with a password, in order to enter commands.

      As MVS changed, TSSO eventually needed fixing and improvements.
Guy Albertelli and Dave Cartwright wrote many of the initial fixes, and
recently, for z/OS and the later OS/390 systems, Ed Jaffe wrote an
extensive series of modifications to TSSO.  TSSO can now be implemented
in all the modern MVS environments.   You can find the latest version of
TSSO on File 404 of the CBT Tape collection, and the previous versions
of TSSO (if you are still running an old version of MVS) may be found on
the CBT Overflow Tape.  So although TSSO came into some disuse for a
while, Ed Jaffe's fixes have now made it possible for every MVS shop to
run it.


INSTALLING TSSO

      I recently installed TSSO on an OS/390 2.10 system, and found that
it is not hard to implement.  I obtained the File 404 pds from the CBT
Tape collection, and made my own copy of it.  I allocated a load library
and ran the assembly job which was supplied, to assemble and linkedit
all the load modules.  One change had to be made to the source.  It
seems that the pound sign (back in 1980-1986) used to be an unused
subsystem character, but now RACF uses it.  So I had to change that.
Now, I use a question mark (X'6F') instead of the pound sign (X'7B').
It is a one-byte change in module TSSOINI2, at displacement +B3.  Once
the load modules were created, I moved them into a system library.  I
made a RACF change, to create a userid called TSSO (similar to userid
JES2), and added the subsystem name TSSO to the IEFSSNxx PARMLIB member.
Then I had to re-IPL, which TSSO requires when it is first installed.
The TSSO started PROC, which is distributed in File 404 as member
TSSOPROC, has to be copied to SYS1.PROCLIB, renamed to TSSO and then
customized.  After the IPL, you then issue START TSSO from the console,
or S TSSO,SUB=MSTR.

      At this point, I found that I could enter TSO commands from the
console, when I preceded the command with a question mark (in my case).
If you leave the default subsystem character as the pound sign, it won't
work, because the system interprets the command intended for TSSO as a
RACF command.  I found that I could do dataset renames and such, if the
the new TSSO RACF userid was given the proper access to them.  I found
I could compress datasets from the console by doing the following type
of console command, which invokes PDS 8.5:

  ?PDS85 SBGOLOB.CBT.CNTL COMPRESS SHR

and the command was carried out.  I could also invoke CLISTs from the
console when the CLIST library was put into the TSSO PROC under the
SYSPROC ddname, and RACF READ access was given to the TSSO userid, for
the CLIST library.

      For basic TSSO use, it is important to note that the TSSO proc
looks exactly like a TSO logon proc, except that you EXEC PGM=TSSO
instead of EXEC PGM=IKJEFT01.  There are some extra ddnames at the
bottom, for outputs (described in the supplied sample PROC).  All of
this is very simple to understand, and easy to get working.


IMPLEMENTING AUTOMATED OPERATIONS

      One must understand that the Automated Operations piece of TSSO
was written in 1986, at a time when the software vendors were only
beginning to create the sophisticated Auto Ops packages of today.  The
talk of the time, was to be able to establish "operator-less machine
rooms" that would only need intervention in the case of an IPL.  So
although the TSSO Auto Ops facilities (called the AOF component of TSSO)
were a great leap forward for their time, they may seem quite primitive
by today's standards.

      If your shop already has an Automated Operations package
installed, TSSO AOF can still work side by side with it.  I'd say that
you should use the installed Automated Operations package for the
"production work", and you can restrict the TSSO intervention into the
console traffic to specialized "sysprog matters", so to speak.  In
other words, if you want to play, and you don't want to interfere in
the normal Auto Ops functioning, you can use TSSO to do your own
console replies and stuff, as long as it doesn't interfere with the
normal production work.

      That said, I'll show you the externals of how TSSO AOF works.
AOF console intervention is driven by an assembled load module, which
is really a table.  You decide which messages are to be replied to.
You draw up a plan, and then you code (using the supplied macros) a
source table of messages and their replies, following your plan, and
using the TSSO macros.  You assemble your table, place it into a load
library that is referred to by the STEPLIB of the TSSO proc, and then
you issue a .RELOAD command under TSSO (in my case the full command
would be ?.RELOAD tablname) to load the table for use.

      An installation can keep a load library containing many AOF
tables, and you can issue .RELOAD commands at any time to load different
tables.  So you can vary your control how TSSO will manage your console
traffic.  TSSO supplies a DISPAOF command to display all the commands
and messages affected by the currently loaded AOF table.  The whole
maintenance and learning process is made easier by two sample members
supplied in the TSSO install pds.  Member ASMTAB is a CLIST which will
automatically assemble, linkedit, and optionally .RELOAD any assembler
source for a valid AOF table.  And member AOFIVP is a sample coded table
that is deliberately intended to show you as many possibilities of how
to code a table entry, as possible.

      I don't have space to show you more about the TSSO package right
now.  For further information about how to use TSSO, look at member
RELGDE43.  But my point is to let you know that a modernized version of
TSSO is now available, and it is free for the installing.  You have the
option of only using the TSO-command execution part of TSSO, or you can
delve into using the Automated Operations facilities of TSSO as deeply
as you prefer to.  Once TSSO is in place, the systems programmer has a
lot of flexibility to do maintenance on the system, and on datasets,
which was not possible before.  With TSSO in place, you can fix or
compress datasets while you're at the console in the computer room.  The
product is now available and it runs on z/OS.  It's my job to let you
know.  The rest is up to you.

      Best of luck to all of you.  I'll see you again next month.