MVS TOOLS AND TRICKS OF THE TRADE
                         September 1997

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


Sam Golob is a Senior Systems Programmer.


SYSTEM PROGRAMMER CREATIVITY

      Oftentimes, there's a way to do one of our jobs, but it's
cumbersome and time consuming.  I've had to do things this way, as
have all of us, every once in a while.  Have you ever had to copy a
long list of PTF numbers to put into an SMP/E job?  I'm sure you've
all had to do that more than once.  Haven't you ever wished you could
just have the computer read an SMP/E APPLY CHECK report and generate
your list of PTFs automatically?  Here's another case.  I know of one
software vendor that makes it very hard to read its distribution tape
and load the programs onto disk.  You have to write three lines of
control information for each individual program you want loaded into
its disk source library.  This involves a lot of file editing.  Don't
you wish that such a job would have been made easier and more
automatic?

      To these questions, many of us simply shrug our shoulders and
say that this is a part of our life.  Sometimes you just have to do the
cumbersome hard work, to achieve the proper result and set up the
system or the component properly.  However, very often, if you'll be a
bit inventive one time, you can save the repetition of some jobs, many
times.  That's the subject we're talking about today.

      For instance, in the case of the product that requires 3 lines of
control cards for every program name you want to unload from the product
tape, I wrote a CLIST which reads in the list of program names, and
creates the required 3 lines of output for each name.  To write a simple
list of 100 program names and to run a CLIST, is a lot easier than
to edit a list three times as long, in a fiendish format.


USING AN INVENTION TO SAVE WORK

      I'm going to start with an example that doesn't directly apply to
today's MVS system programming, but which illustrates a few valuable
points that we can employ in our current work.  Those of us who were
around in the days of SMP4 or before, will really appreciate what I have
to say here, while I hope to explain the concepts clearly enough, so
that everyone else will get the points, too.

      IBM used to send all the system's fixes in a monthly tape, called
a PUT tape.  Each installation would keep up-to-date by APPLYing (with
SMP - the System Maintenance Program) as many PUT tapes as they desired,
to keep as current as they felt they needed to be.  Later, the same sort
of maintenance could be done with CBPDO tapes, but since CBPDO tapes
are designed to be used with SMP/E, and my work was done with SMP4, I'll
restrict this example to refer to PUT tapes.  PUT tape maintenance was
designed so that you would generate a partitioned dataset called the
PUTPDS.  Part of the PUT processing was to fill the PUTPDS with members
containing all the information needed to install the PTF fixes properly.

      What if a PTF was found to be in error (or PE'd) after it was
inserted into a PUT tape and distributed?  Nowadays, with SMP/E, the
PTF is placed into HELD status by RECEIVEing a ++HOLD statement into
SMP/E's HOLDDATA in the GLOBAL zone.  But SMP4 had no such thing as a
HELD PTF.  With SMP4, all PTFs had the same status.  They were all
eligible to be APPLYed to the system, unless they were specifically
EXCLUDEd in the APPLY control cards to SMP.  Thus, in order not to
APPLY a bad PTF, you had to include it in what was called the "EXCLUDE
list" in all mass APPLY and ACCEPT runs.

      Therefore, if IBM found that a PTF was in error, it would mention
in the PUT tape, or in a PSP bucket, that the PTF was to be included in
the EXCLUDE list.  The PUT tape processing itself would generate a list
of known PTFs from the current or previous PUT tapes, to be excluded.
You then would add more bad PTFs to the list, from the PSP buckets, or
from other information gotten from the IBM Support Center.

      Now let's ask ourselves, what happens when a PTF is EXCLUDEd,
even with SMP/E, and it is a prerequisite for other PTFs to be APPLYed?
The answer is, that the other PTFs also can't be put on, for the reason
of a missing PRErequisite or coREQuisite PTF, and an error message is
generated.  In the SMP4 days, when many PTFs were specifically excluded,
and you ran an APPLY CHECK job, this error list was often very long.
Suppose now, that you were putting on six PUT tapes, and you got an
error list (of missing prereqs) a mile long.  You'd scan the error list,
copy (by hand) more PTF names to the EXCLUDE list, and rerun the APPLY
CHECK job a second time.  Then you'd get more error messages, if the
newly excluded PTFs were also prereqs to other PTFs you were trying to
APPLY.  But the error list would become gradually shorter, because it
only referred to PTFs that weren't yet on your system.  After the second
APPLY CHECK run, you'd look at the error messages still outstanding,
copy more PTF names to the EXCLUDE list, and run the APPLY CHECK for a
third time.  You'd repeat this process until the APPLY CHECK run was
clean.  Often it could take six, seven, or eight iterations.

      Now please bear in mind that in those days, a mass APPLY CHECK
run on a large system might take close to an hour.  Copying the newly
excluded names from the previous APPLY CHECK run might also take an
hour.  Thus, the process of putting on 6 PUT tapes worth of maintenance
might consume the system programmer's full time for a day or two.
There would be no time to do anything else, on those days.

      I solved those problems by writing a program to read a disk copy
of an SMP4 APPLY CHECK report, and to create a list of new PTF numbers
to be added to the EXCLUDE list.  The new numbers were then sort-merged
into the old EXCLUDE list, duplicate numbers were removed with a program
(SMP wouldn't tolerate them), and a new APPLY CHECK job was generated.
The whole recycling time took two or three minutes.  While these APPLY
CHECKs were running, my time was free for other things.  Mass PTF
maintenance was no longer an all-consuming chore.  As a by-product, my
installation was far less hesitant to keep the system current, because
it took less work.  Therefore, the whole site benefited, because it was
running a more current, and error-clean, system.

      Most of my SMP system is old now, but it can be found on File 058
of the CBT Overflow tape, an independently produced software tape with
older, but useful code, that can be ordered through the NaSPA office.
The part of this system which is still useful nowadays, can be found on
the CBT MVS Utilities Tape (also obtainable through NaSPA), on File 118.
My point in showing this, is that the time spent writing one or two
programs (a day or two) can often save many days of your work, far into
the future.  I used this package of programs in my work for six years
afterward.  Furthermore, the idea of what was done, is not dead.  The
same idea can (and has) been used over and over by me, for other
work-saving projects.


AVOIDING REPETITIVE WORK

      Any time you have to do a tedious job which is repetitive, you
have a good candidate for a small programming project, to let the
computer do most of the work for you.  One of my previous sites had
multiple LPARs which ran copies of a standard system residence pack.
Contained on the res pack was also an SMP/E target zone with all the
software installation information.  We would develop every new res pack
on a test system, and then it had to be cloned to all the production
systems.  Our site developed a CLIST which made most of this cloning
process completely automatic.  You just would enter the source pack
which was the model for the clone, and the target pack which would be
overlaid by a "near copy" of the source pack.  Then you would enter a
level number from 01-99 (the installation assigned maintenance level of
the source res pack) and you would enter today's date.  The CLIST would
generate a complete multi-step batch job to properly create a new res
pack with all the library information and SMP zone information (with the
zone renamed) copied from the old one.

      This CLIST method had a tremendous advantage over hand methods of
doing the same thing.  Suppose you had some JCL which did this job, and
every time you wanted to do a clone, you would modify this JCL.  There
would be a lot of margin for error.  First, you might not do a global
change for everything that is different.  The new pack might have some
incorrect pack names embedded in some of its components, such as the SMP
target zone.  Second, a typographic error might slip in unnoticed, and
cause damage.  A subtle malfunction in an operating system res pack can
be very dangerous to the installation, later.  Third, adequate records
of the changes would probably not be made; the CLIST takes care of this
automatically.  Finally, each LPAR that is running, is properly labelled
with its correct maintenance level, so the central administration of the
site can easily oversee which division is running which software level.

      You can find a sample of this system on Files 204 and 205 of the
CBT MVS Tape.  Similar systems for CICS and DB2 can be found there also
on Files 210 thru 213.  You can use these as starting points, and
develop customized automated procedures appropriate for your shop.  If
your shop needs these things, a few hours or days spent setting these
up, will pay for themselves for years afterward.


CHOICE OF LANGUAGE

      If you are developing an automated procedure for yourself or your
site, I'd recommend picking a progamming or interactive language that
is easy for you to use.  If you're familiar with CLISTs, I'd suggest
you start there.  If you know REXX better, then use REXX.  For some
projects, speed of execution makes a difference.  Compiling a REXX exec
can speed it up.  Assembler programming is good for speed of execution
and for availability of system facilities to help you.  That'll only
work if you're familiar with programming in assembler.  I wrote most of
the SMP system mentioned above, in COBOL, because I had been an
application programmer before, and at that time, I was more fluent in
COBOL than in assembler.  The rule is, don't make the job unnecessarily
hard for yourself.  Use the language that is easy for you.

      That's all true if you're writing the tool for yourself.  What
about the case where most of it's been done by somebody else?  The
answer is, that you'll have an easier job, and a harder job.  It's
easier, because someone else has done most of the work.  It's harder,
because you may have to understand a program written in a language
you're not so familiar with.  My experience is mostly drawn from
looking at other people's work that I found on the CBT Tape.  When I
first started doing this, I'd print out the other person's program, and
I'd only look for the parts I had to change.  Usually, a small change
was adequate to customize that program for my needs.  Later, I built on
my previous knowledge, and was consistently able to see more.  My
general take on this matter, is that if you know how the program works
externally, you'll be able to learn to pick out the parts of the
program source that you need to change, despite the language barriers.

      I'd like to conclude by saying something I heard many times from
my teacher, Jeff Broido, and which I found from my travels, that people
need to hear.  Jeff always told me to invest a half hour a day in
exploring, and expanding my horizons.  Invest some time in learning
something new, and it will pay itself back many times over, for many
years to come.  This applies to writing a new tool, as well as learning
about some existing tool.  It can be fulfilled by exploring the software
goodies on the CBT Tape or in some other public forum.  Or it can even
be satisfied by spending some time in learning the ISPF Tutorials.  By
doing this, you'll certainly come across new techniques which will save
you work later.

      As trivial as it may sound, learning the commands of ISPF EDIT
from the Tutorials, will help you to write EDIT macros, which are a
very significant work shortener.  Any new fact you can pick up, is a
potential time saver.  Once you've seen the Tutorials for ISPF EDIT,
you might explore two EDIT macro collections on the CBT Tape by Paul
Davis, on Files 095 and 251, for examples of what can be done.  After
that, you'll be in a position to apply these techniques to shorten your
own everyday work.

      I hope that this month's talk will be of help to you.  Mental
inertia is a hidden enemy of all programmers.  After an initial burst
of learning, there often is a lot of time spent resting on one's laurels
until the next shock comes.  Investing a half an hour every day for
some type of exploring, is a trick that can guarantee your continued
mental growth.  Shortening the time needed to be spent on each task,
will then come naturally.  Good luck.  See you next month.