MVS TOOLS AND TRICKS OF THE TRADE
                          November 1989

                                      Sam Golob
                                      MVS Systems Programmer
                                      sbgolob@cbttape.org

            NO-COST SUBSYSTEMS:  TSSO, ETPS, AND CMD1

      This month, I would like to begin with an endorsement for a
unique book, which has helped me for years in my own career.  It has
recently come out in a second edition, and is available at a discount
to NaSPA members.  The book is entitled, "The Systems Programmer's
Problem Solver", by Bill Mosteller, who worked as an MVS Systems
Programmer for many years, with a good reputation.  Now, Bill has
gone into VM, and he works for Systems Center in Virginia.  (I think
he still has a good reputation.)  "Systems Programmer's Problem
Solver" is published by QED Information Sciences in Wellesley,
Mass., and NaSPA has an agreement with them for a 15% discount
to members.  They have an 800 number, 1-800-343-4848.

      The book is composed of tidbits of good advice to people in
our field.  You do not have to work in MVS to benefit.  As a matter
of fact, when I first saw a copy, I was a DOS applications programmer.
But its down-to-earth approach to the everyday realities of the
programming life, hits home in many ways.  Of course, the MVS SysProg
will be in tune with the book on all cylinders, and will benefit
directly from every page.  IT'S MADE FOR US.  But ALL programming
personnel will empathize with the points Bill makes, and the stories
he tells will strike a receptive chord in the heart of anyone in
this profession.

      So I am going to (uncharacteristically) urge you to go out
and spend a few bucks, and buy the book!  It's practically guaranteed
to multiply a return on your investment, if you count money saved for
your company, "Brownie points" for you with your management, and
a general increase in your satisfaction, that you're more competent
and confident to do your job.  HOLD ME TO IT.  I don't expect (m)any
complaints.

      *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

      Please note an important announcement as part of our topics for
this month.  It concerns the Connecticut Bank and Trust (CBT) MVS
Mods tapes, which have saved my company hundreds of thousands of
dollars over the past few years, and which should be a mainstay of
every MVS System Programmer's arsenal.  The hundreds of programs and
software packages on these tapes, ALL PUBLIC DOMAIN, have provided
tools to implement many of the suggestions in this column.  Many of
these packages provide equivalent or near-equivalent function to
expensive vendor packages.  In a few cases, I think that a facility
provided on this tape may be EVEN BETTER than anything that is on the
market.

      There has been some uncertainty at CBT, due to a drastic
reorganization, concerning their ability to reproduce the tapes
in the quantity necessary to supply our needs.  In response to the
situation, Arnold Casinghino (our benefactor, who produces the tapes)
has agreed to keep NaSPA supplied with the current versions, so that
anyone may order them from NaSPA.

      Please get into the habit of ordering the CBT tape from NaSPA,
if you can.  To offset the slightly increased cost, due to handling
overhead, we suggest that several installations can pool, to share a
single tape.  The "Air Force" TAPE COPYING PROGRAM, on file 229 of
the CBT tape, will make up to ten copies of a single tape at the same
time--as many copies as you have drives.  Arnie Casinghino himself,
has used this program to cut the copies of the tapes that he sends
out.  OUR AIM IS TO MAKE THE TAPE GENERALLY AVAILABLE, IN ITS CURRENT
VERSIONS.  There are no restrictions on copying, and we would like to
see that the tape be spread around as much as possible, for every
shop's benefit.

      As far as making new versions of the tape, with changes, Arnie
will try to continue doing that as long as he can.  If for some
reason, Arnie has trouble getting a system on which to do the updates,
I will endeavor to keep them going myself, as long as necessary.
NaSPA might then become the main distribution point.  In any case, I
hope that we can continue to keep the tape current, as a vibrant and
responsive vehicle to supply the needs of this profession.

      It is important to make the point that packages on the CBT
tape have often been kept close to sync with new levels of system
software.  Original contributors, and others, have bent to the
effort, and kept many of these programs in touch with modern times.
(The support, of course, is voluntary, and it varies from package to
package.)  Usually, if hundreds of companies use a package, SOMEONE
is going to fix it for a new level.  (And I'VE BEEN THE ONE, more
than once.)  Another consideration:  because the CBT tape has often
been in danger of becoming full, Arnie has gone through a series of
mass deletions of old files.  THEREFORE, MOST MATERIAL ON THE CBT
TAPE IS FAIRLY NEW, and there is not much "dead wood" on it nowadays.

      So please keep in touch with notices in this column, and we'll
try to bring you the latest news concerning the CBT Mods Tape.

      *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

      Now to the month's topic.  First, I sincerely feel that we
should publicly appreciate the efforts of Arnold Casinghino, who has
exerted himself mightily for almost fifteen years to bring us the
unbelievably rich CBT tape.  This tape has gone through 310 release
levels, STARTING FROM VERSION ONE.  I always say that Arnie has to be
a very fine person, because someone who isn't willing to help people,
would have weaseled himself away from such a task long ago.

      I personally think (and would welcome correction from our
readership), that perhaps 95 percent of MVS installations in this
country possess, in house, programs that are either directly from
Arnie's tape, or which were transported indirectly after originating
from there.  I suspect that the figure is actually higher.  It is a
good example for us to ponder, that one person, who sits in one
chair, could do so much to help so many people and installations,
simply by continuing to be "the swap shop" for such a length of
time.  One man's quiet dedication pays dividends for many.  Thanks,
Arnie.  We wish you well, and hope you can continue to help.

      So in keeping with this, we'll talk about some more software
items from the CBT tape that we haven't elaborated on previously in
this column.

      Three unbelievably handy software packages to have at your
side, are TSSO (Time Sharing Subsystem Option), ETPS (Emergency
Tele-Processing System), and CMD1 (Command Subsystem).  I have
singled them out, because they are not only convenient tools, but
they are of valuable aid in automating operations (in the case of
TSSO), in monitoring the operation of the system (CMD1), and in
bailing out the installation in cases of system emergency (all three
packages).  These three packages HAVE BEEN WRITTEN AS SUBSYSTEMS
under MVS, and as such, THEY CAN FUNCTION WITHOUT JES2 OR JES3 BEING
UP.  Their utility value under circumstances of system distress, as
well as under normal conditions, makes for the avoidance of
standalone restores and other time-consuming and painful recovery
practices.

      The function in these packages together, in my estimation, have
what I'd call a "vendor package replacement value" of forty to eighty
thousand dollars to a company.  They are public-domain (not guaranteed
in writing, etc.), but to obtain equivalent value from vendor
products, an installation might have to spend the aforementioned sum,
or more.  In addition, most vendor products are not subsystems, and
cannot be used to fix the system software if there is a problem with
the primary subsystem (JES2 or JES3).

      TSSO is found on CBT tape file 401.  A version of CMD1 which
works under XA can be found on file 261, and ETPS is a part of file
353.  The original version of TSSO is distributed on file 306,
although it can be completely replaced by the version on file 401.
A series of examples in the use of TSSO for automating operations,
can be found on file 399.

      TSSO was originally written by Bill Godfrey (his version is on
file 306 of the CBT tape) for the purpose of executing TSO commands
from a system operator console.  TSSO in its original form emulates
a TSO environment (with CPPL and other control blocks), so a TSO
command will execute under it.  Responses from TSO commands executed
under TSSO will appear on the system console, but only if the
particular TSO command does its terminal I/O using the PUTLINE
terminal interface, and not the TPUT interface.  In either case, the
command would be executed.  However, it is obvious that one should
choose TSO commands that use PUTLINE I/O to execute under TSSO, so
that the response is reported to the issuer.  One should also note
that FULLSCREEN terminal I/O will cause TSSO to abend.  (The system
operator console is a TTY-type line-oriented environment).  It
follows that any TSO command doing fullscreen I/O must not be
executed under TSSO.

      The version of TSSO on file 401 of the CBT tape (the public
Bellcore version 4.3) completely supersedes Bill Godfrey's version.
That version of TSSO (which carries a Bellcore copyright notice, but
which is their last release as public-domain software) adds two
additional functions.  The main one is AUTOMATION OF CONSOLE
OPERATIONS, and the second one is CONSOLE SECURITY.  This is in
addition to the ability to execute TSO commands from the system
console, as mentioned before.

      I recently attended a fascinating session at a large IBM user
group meeting.  The speaker, who was from IBM, did an in-depth study
of different types of console messages, for the purpose of learning
how to use the messages to automatically drive system responses.  The
vehicle she used for doing the automatic replies (etc.) was IBM's
NETVIEW(TM), which isn't cheap.  Besides what I learned from her
incisive and deep observations, I was struck by a big point.  I COULD
DO EVERYTHING WITH TSSO IN THE WAY OF CONSOLE AUTOMATION, THAT SHE
SAID SHE HAD DONE WITH NETVIEW!  I know that TSSO cannot do everything
Netview can.  But I found I COULD do with my TSSO, everything that
this speaker mentioned, in the way of using messages to initiate new
system actions.  TSSO has the "console automation scene" pretty well
covered.

      From the user's point of view, TSSO accomplishes console
automation tasks through an assembled and linkedited module, called
the AOF (Automated Operations Facility) Table.  The active table can
be instantly replaced with a new version or another module, through
an operator ".RELOAD" command.  Various types of actions can be
specified in the table.  Selected messages can be highlighted,
lowlighted, or suppressed from the console (but not from the system
log).  Also, a message can be used to drive an operating system
action, such as the execution of a system command.  It is easy, for
example, to simulate new system commands.  One merely intercepts the
"IEE305I syscmnd COMMAND INVALID" message from a particular invalid
command, (one can specify the contents of the second word in the
message to key on), and then an "OSCMD" reply can be issued to
perform any action desired.  Then, one merely suppresses the original
"COMMAND INVALID" message from appearing on the console.  Our shop
uses one such "invalid command" to start JES2 with all the required
parameters.  The operators simply enter one command, and are relieved
of the responsibility of getting all the JES2 start parameters right.

      Because a TSO-like environment is present in TSSO, IT IS
POSSIBLE TO EXECUTE OPERATING SYSTEM COMMANDS OUT OF A CLIST, AND
RETURN THE RESPONSES BACK TO CLIST CONTROL.  The entire power of the
CLIST environment can thus be brought to bear on the task of
automating console activity.  If you think about it, THIS IS BIG
STUFF.  Some examples of what people have done, appear in file 399
of the CBT tape, but they do not come close to exploiting TSSO's
full capability.  As far as we're concerned, the sky's the limit.
We're free to use our own inventiveness to the fullest, in this
arena.

      If you're running MVS under VM, a "CPCMD" command processor is
supplied, to issue VM commands from MVS, that are executed by the
underlying virtual machine.  One can inquire about attached devices,
paths, other VM users, and such.  It is easy to attach or detach
devices to MVS and to other machines as needed, too.  VM users can
figure the rest out for themselves.

      Just to entice the imagination, I'll cite a few examples of
what people have done:  Vary tape drives online or offline in
selected bunches, trigger a response or a warning when spool space
gets too full, reply to WTORs or to sequences of WTORs.  One can
start up everything after a new IPL; one can shut down the entire
system in preparation for a new IPL, just with a single CLIST
execution.  This is with a single command to initiate each
"intelligent" sequence of actions.  One can set up all the operator
consoles to proper (rollable) status at any time.  (At IPL time this
may be done in the PARMLIB COMMNDxx member.)  Much manipulation can
be accomplished with remotes.  All the initiators can be set up to
different configurations at different times of the day.  Date
conversions may be displayed on the console, using the power of CLIST
string manipulations.  I must emphasize that these are but a very few
examples of what is possible.

      Space prohibits further elaboration of TSSO's console
automation capabilities.  The CONSOLE SECURITY feature must get some
mention, although few installations use it.

      Console security requires that TSSO work together with a data
security system, such as RACF, ACF2, or Top Secret.  The result of
console security is that OPERATORS HAVE TO LOG ON TO THE CONSOLE
WITH A PASSWORD, BEFORE BEING ABLE TO ENTER COMMANDS.  This has the
effect of allowing the installation to track WHICH operators entered
WHICH commands.  Console security may also be of help for large
installations that have many secondary operator consoles, some of
them lying around in user areas.  The feature may do something
significant, in preventing unauthorized persons from entering commands
at these consoles to manipulate the system.

      Now we'll talk about ETPS, and we'll finish up with CMD1.

      ETPS (or Emergency Tele-Processing System) comes from Brian
Cook of Morton-Thiokol in the Chicago area.  ETPS is a system to do
NATIVE TERMINAL I/O in the event that important parts of an MVS
installation, such as the primary JES, VTAM, or TSO, will not
start.  ETPS supports an ISPF-like BROWSE and EDIT, and allows the
entry of IDCAMS commands to perform VSAM functions when "nothing
else is up".

      The idea of ETPS is excellent, and the system really works
in an emergency, "grabbing a terminal" without VTAM or BTAM and
allowing you to fix the system.  One must watch out, however, because
native terminal I/O is not easy to write correctly, and the system has
some bugs, especially in the editor.  However, IT CAN BE A LIFE-SAVER,
and it sure is a handy tool to have around for when you need it.

      In the more recent release of ETPS, the author has front-ended
it with a TSO command, called ETPSTSO.  This command allows a user to
use the ETPS facilities under TSO, so as to gain practice with it
under more normal conditions.  If one already is familiar with using
the ETPS facilities, one is all the better prepared in the event of an
emergency.  In short, ETPS is a good thing to have.  The non-price is
right, and it is one more nice safeguard between us and disaster.

      I might add at this point that one can get around some of the
necessity for ETPS, by using a combination of TSSO and the PDS
command (file 182, 296, and 112 of the CBT tape).  If one brings up
TSSO without JES, (this can be accomplished by "START TSSO,SUB=MSTR"),
TSSO can still run any TSO line command which uses the PUTLINE terminal
interface.  That includes TSO EDIT and also the PDS package.  PDS in
particular, has a scan/replace that works by update-in-place, and
which can be used to look at JES parms or PARMLIB members, to fix an
ailing system.  PDS will compress libraries that are full, add
directory space to a library "on the fly", copy members from one
library to another, and help in many other ways.  My own emergency
requirements have usually been satisfied with just this combination of
tools.

      I cannot do proper justice to CMD1 (the Command Subsystem)
here.  CMD1 has many, many display and monitor functions, operated
both from the system console and from a TSO userid.  The closest
thing I can compare it to, in a vendor package, is the "RESOLVE"
package from Boole and Babbage, with its many "authorized" utility
and monitor functions.  I privately refer to CMD1 as "the poor man's
RESOLVE".  At this juncture I must point out that CMD1 is written
as a subsystem, and it can do most of its functions "without
anything else up" on the system.  That can be helpful also.

      The greatest necessity for CMD1 at an MVS installation, is in
its "authorized function" capability.  One sometimes needs to make
an address space NONSWAPPABLE, or CANCELABLE, or the like.  Sometimes
one needs to display and zap memory, to save the system at a crucial
time.  CMD1 has large capability in this area.  Without some vendor
package to fill that bill (usually costing in the neighborhood of
forty thou), an installation can find itself helpless sometimes.  Once
(many moons ago, I must say) our own installation had to IPL when JES2
got into serious trouble, and even a "$pjes2,abend" command didn't
work.  With CMD1, I simply made it cancellable and cancelled it, or
terminated its address space.  DONE--no fuss.

      CMD1 has many display facilities too, to the point that one
may get quite overwhelmed with them.  For example, #J is a useful
display of jobs and started tasks, etc. in the system.  The various
types of #I command show different types of SRM values, paging, swap
activity, and other statistics.  #V tells you all kinds of things
about the mounted disk volumes.  #FC displays CSA and SQA usage.
And so on.  There is a user guide, and you have to look for what
you need to measure.

      A large part of CMD1 has been adapted for use under XA.  This
opens up a different area in our discussion of CMD1.  Such a product
is bound to change greatly, because of variations and enhancements in
the underlying operating system.  Traditionally in the history of CMD1,
large numbers of modules had to be changed because of a new operating
system release.  In fact, the installation procedure of CMD1 reflects
this greatly.  You start with a set of modules for a lower system
release than yours.  Then you execute a CLIST against the install
library, which renames a whole bunch of modules so that the next
level of operating system becomes the currently installable level.
This keeps going on, until you reach the level of operating system
that you're at.  Then you install the thing.  This is really how
it works, no joke!

      Anyway, this incredibly rich package is yours for the looking
and taking.  I must say that it takes up some LPA space.  But you can
often save that space in other ways, such as removing ISAM from LPA,
if no one in your shop uses ISAM, for example.  If you're really
interested in tuning LPA, IBM has a Dallas Systems Center book that's
good: "MVS Virtual Storage Tuning Cookbook", G320-0597.  There's a
chapter in there that says what you can remove from LPALIB to a link
list library, so that the system will still work.

      Getting back to CMD1, it's very good, but not 100% guaranteed,
because it's not formally supported.  It does have a built-in
safeguard to stop a command that doesn't work properly from damaging
the system.  I still think that the advantages of CMD1 far outweigh
the deficiencies, and if your shop won't spend the money for the
expensive utility and monitoring packages (probably not so good an
idea), CMD1 will fill a lot of the void for you.

      Between all three of these packages, you and your shop can be
a lot better off.  Good luck.  See you next month.