MVS TOOLS AND TRICKS OF THE TRADE
                            JUNE 1999

                                      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.


SELECTIONS FROM CBT TAPE VERSION 420 (and 421)

      Last month, we began to look at a few of the new software
goodies that are on the new CBT MVS Utilities Tape, Version 420, which
was just released at the beginning of April.  Figure 1 summarizes all
the new and changed files in this latest CBT Tape version.  This month,
we'll continue by mentioning some more new products that I, personally,
consider very helpful in the daily life of an MVS systems programmer.

      Since the CBT Tape is now available online, it is possible to
also mention some files that "didn't quite make the deadline", and
which are slated to be included in the next release of the tape,
Version 421.  You can download these files also.  You can reach the
"Online Home of the CBT Tape" by going to 'www.naspa.net' and clicking
on "Online CBT".  This will get to the Version 420 files.  The
files slated for inclusion on Version 421 are available for the
time being, at:  ftp://ftp.cbttape.org/pub/cbttape/adhoc/CBTnnn.zip ,
where nnn is the file number for the new file.  The characters in
this URL are case sensitive.

      As most of you probably know, the CBT MVS Utilities Tape has
long been considered the "systems programmer's best friend".  This
enormous, totally free collection of MVS system software and other
goodies, was started in 1975 by Arnold Casinghino at the Connecticut
Bank and Trust Company in Hartford, Connecticut.  Arnie was extremely
dedicated to maintaining the collection, and it has grown enormously
to now span two tapes:  the "CBT MVS Utilities Tape" and the "CBT
Overflow Tape", both of whose files are available online.  When Arnie
had to stop maintaining the tape in 1990, I took over as its proprietor,
and at the same time, NaSPA became a major force in distributing this
public collection.

      The CBT Tapes don't have a monopoly on useful tools for sysprogs,
but they do provide a robust place to start looking for help.  File
071, and the "Modification Tapes Section" in the File 001 documentation
of the CBT Tape, attempt to point you to many other useful sources of
available free MVS materials.  With the CBT Tapes as a starting point,
you have access to lots of help.

      Today, we'll cover a few more new tools that you can try out.
They're only a sample.  Check over Figure 1 again, to see the complete
list of new and changed files for CBT Tape Version 420.


FILE 349 - UPDATING YOUR ISPF COMMAND TABLE.

      I'm glad I'm writing about File 349 this month, because, as
shipped on Version 420 of the CBT Tape, File 349 was missing a piece,
and it wasn't ready last month.  However, I'm so happy with it, and so
convinced of its usefulness, that I'm going to start our discussion
by talking about the "repaired" version of File 349 that you can
download.  The URL is:
ftp://ftp.cbttape.org/pub/cbttape/adhoc/CBT349.zip .

      File 349 gives you tools to update your own, personal, in-core
copy of the ISPF command table.  When you are in an ISPF session and
you enter a command on the command line, the ISPF command table is
one of the first places that ISPF tries to look, to interpret your
command.  Since we're systems programmers, we sometimes update DASD
copies of the ISPF command table and put them in our own ISPTLIB
dataset concatenations, but with this new technique, you can walk into
a shop, copy 3 REXX execs into a SYSPROC or SYSEXEC library and a
control member into your userid.ISPF.ISPPROF dataset.  Then you can
update your own ISPF command set at will.  It's a very quick and easy
setup procedure.

      The package was written by Willy Jensen of Harders-Jensen in
Denmark.  It contains 3 execs called ISPCMDL (ISPF command lister),
ISPCMDU (ISPF command updater) and ISPMSG (a service exec to write
messages--this was the missing piece).  The control member, called
ISPCOMND, can be copied to your ISPF profile dataset, and edited to
your taste.  The ISPCMDU exec, as coded, should default to looking for
its control statements at this location.

      The control member ISPCOMND is coded as in Figure 2.  To add
or update a command, you start with a slash and delimit the (usual)
four fields with slashes.  The first field is the command itself.  The
second field is the abbreviation number.  If the abbreviation number
is 0, then the command must be entered as stated, and cannot be
abbreviated.  If the number is positive, from 1 to 8, then you only
have to enter that number of characters to issue the command.  For
example, a command called DOTHEJOB with an abbreviation number of 3,
can be entered as DOT, DOTH, DOTHE, and so forth, up to the full
length of its name.

      The third field is the ISPF statement to be executed.  For
example, it might be a "SELECT CMD", a "SELECT PANEL", or a
"SELECT PGM" statement, with the proper invocation parameters.
The fourth field is the text description, which serves as documentation
for what the command does.  Anyone who has ever added a command to the
ISPF command table, using ISPF option 3.9, knows about these fields.
The File 349 documentation member $$$DOC tells you how to delete an
active command, too, as well as how to add or update a command.

      The neat thing about this package is its simplicity.  To begin
using the package, enter TSO ISPCMDL on the command line, which
displays all of the current ISPF table entries.  Then (after
customizing your ISPCOMND member of userid.ISPF.ISPPROF), you enter
TSO ISPCMDU, and you receive a message stating how many commands were
added, deleted, or updated.  The first time you enter TSO ISPCMDU,
you'll probably see the message stating that a number of commands
were ADDED.  The next time you enter TSO ISPCMDU, these commands will
be shown as UPDATED, because they were already there, from the first
ISPCMDU invocation.  And that's it.  You can start using these new
commands immediately.  There's no need to recycle ISPF, because
you've updated the incore command table in your TSO address space.
Now invoke TSO ISPCMDL again, and you'll see all your new commands,
nicely displayed.

      My sample command table updates, partially shown in Figure 2,
are a copy of the options taken from the ISPF main menu, and the menu
for ISPF option 3.  The commands themselves are prefixed by the
letters "SP".  It works like this.  For example, if I enter SP2, my
command table entry will pop an ISPF option 2 panel on my screen, on
top of whatever else I was doing.  An SP314 command will pop an ISPF
option 3.14 panel up.  You can nest panels.

      This is very handy, because, in effect, it extends our
capability to do more things at once under ISPF.  You are not merely
limited to two single actions under the two screen splits.  Most of
the time we need this, we're in the middle of doing something, and we
say, "Darn it, I have to create a new dataset."  With this system,
you just enter:  SP32, get a fresh ISPF 3.2 panel, allocate the new
dataset, and when you end, you go back to whatever you were doing
before.  Try it.  You'll like it.


FILE 247 - SYS1.BRODCAST and TSO USERLOGS

      Every MVS system has to have a SYS1.BRODCAST dataset.
However, after you've set up TSO at your installation to use TSO
Userlogs, SYS1.BRODCAST isn't so useful anymore, according to the
"street opinion".  I say, "not so".

      I'm prepared to put my money where my mouth is.  I admit that
with only IBM's minimal (i.e. "next to nothing") toolset for handling
the SYS1.BRODCAST dataset, one feels rather helpless.  But I've
written a rather robust set of tools for managing and using
SYS1.BRODCAST.  My tools have been around for a few years now, on CBT
Tape File 247.

      Since last month, I've revisited this package to spruce it up
a bit.  The older version of the package, on File 247, works OK.
You can get this older version by going to www.naspa.net, clicking
on "Online CBT", clicking on "Download CBT", and going to
CBT247.zip.  However, my (somewhat revised) newer version is
available at ftp://ftp.cbttape.org/pub/cbttape/adhoc/CBT247.zip ,
and it's a good bit better.

      Let's start talking about it.  You can display other users'
TSO messages with the BCMLIST program, or its relatives that display
more info:  BCMLIS, BCMLISY, and BCMLISX.  In my newer version, anyone
can invoke these, with only READ access to SYS1.BRODCAST.  You issue
a TSO ALLOC command to allocate the ddname BRODCAST to SYS1.BRODCAST
(with SHR, of course).  Then you issue "TSO BCMLIST userid", and the
BCMLIST command displays that user's messages.  I think that when IBM
tried (around 1970) to make it impossible to do this, they thought
that someone else's messages were private things.  That may have been
true in the "old days", when SYS1.BRODCAST was probably the only TSO
messaging tool around.  Nowadays, it most likely doesn't matter much.
If someone else sees the notifications of your completed jobs, you
probably wouldn't holler about it.

      This only works when the other user's messages are in
SYS1.BRODCAST, not in a TSO Userlog dataset.  However, my package has
many other goodies in it.  First, the batch program BCSCAN (which is
old, from Richard Nikula, but modernized), will give you a global view
of SYS1.BRODCAST, and will tell you:  how full it is, which users have
undelivered messages, and how many outstanding messages each user has.
This is handy when SYS1.BRODCAST fills up.

      Suppose one user has over 1000 undelivered messages.  (He's a
guy who left the company 8 months ago, and ten production jobs send
their NOTIFY messages to his id every day.)  How can the administrator
delete them?  My package supplies four different ways.  Three
programs, BCMDEL, BCMDEL1, BCMDEL2, will display and then delete an
arbitrary user's messages.  Each of these programs works on a
different principle, and each one may work in a situation when the
others won't.  The fourth way is a program, BCMUSDEL, which deletes
the user's "userid record" in SYS1.BRODCAST itself.  BCMUSDEL uses
IBM's official SYS1.BRODCAST programmable interface, and when you
delete a userid with this method, all its messages will be cleaned off
nicely, too.

      You can learn much more about this package by reading the
$$$DOC member of File 247.  But before leaving this topic, I'll tell
you a novel idea about how you can use a nice big, empty SYS1.BRODCAST
dataset, that stays nearly empty, because all the TSO users are getting
their messages via their Userlogs.  You thought that this big, ugly,
nearly empty SYS1.BRODCAST was useless, huh?

      With my package, it isn't.  If you're careful not to fill it
up, you can use that big, empty messaging space for production control
testing.  Suppose there's a daily production job that's been failing
once in a while, under mysterious circumstances.  To make matters
more interesting, suppose that the JCL in the production job run
gets purged pretty quickly, or suppose, if there's an abend, it purges
itself, leaving almost no trace in spool.  This is not too likely a
situation, but I'd bet it occurred at least once in nearly everybody's
career.  How can we go about tracking the times when a bad run has
occurred?

      We can do it with a NOTIFY= parameter in the JOB card of the
production job.  Upon job completion, NOTIFY causes MVS to issue an
operator SEND command, which sends the job completion notification to
a TSO user.  What if there's no TSO user to send the notification to?
In that case, MVS purges the message, because, if the SYS1.BRODCAST
dataset doesn't know about the userid, there's no place to store its
messages.  Now, using my BCMUSADD TSO command, we can create an
arbitrarily-named userid record in the SYS1.BRODCAST dataset, which
exists nowhere else, and we can code NOTIFY=thatid on the production
JCL jobcard, to point to the new userid.  Or we can create a new
userid name to match the RACF userid (even if that userid doesn't have
a TSO extension) that the production job gets submitted under.  In
either case, the NOTIFY messages will start accumulating in
SYS1.BRODCAST, under the newly "created" userid.  You can display and
print these messages with the BCMLIST program, and you can delete them
with one of the BCMDELx programs.  With these tools, you have the
ability to track the times of the production job runs, and no TSO user
can purge the information (in the ordinary way with LISTBC), because
no one can logon to this specially created "userid".  It's a nifty
trick.  The method is available, if and when you need it.


SOME OTHER NICE PACKAGES

      Space is short, and I'd like to conclude by mentioning some
other important packages briefly.  Lionel Dyck, in File 312, has
contributed two important tools, FTPBATCH and XMITIP.  FTPBATCH
provides an interface for setting up multiple file transfers in batch,
using FTP.  XMITIP allows you to send email messages across the
Internet, directly from TSO on your MVS system.  Lionel keeps tweaking
and improving these packages.  It pays to take a good look at File
312, and keep following his updates.

      Files 035 and 135, the load module libraries, have been much
neglected in this column, so I'd like to say a word about them.
Many sysprogs like to always "assemble their own stuff", because when
you assemble your tools, they're most likely to best match the level
of the operating system that they're running on.  Nevertheless, the
"quick install", that is, copying load modules into an executable
library, sometimes saves the day.  On Files 035 and 135, load modules
of useful programs such as PDSLOAD (our IEBUPDTE substitute that
preserves ISPF statistics) and CBT973 (the CBT Tape decompression
utility) are instantly available.  If you want to try REVIEW or
SHOWMVS, which are big programs, but easy to run under TSO, you have
the shortcut of copying them out of File 135 and running them.

      Files 035 and 135 are updated to match the level of source code
that's on the source files they come from.  Since they're quite
current, it's usually a good bet that most of their files will run
properly on a modern MVS or OS/390 system.  When you get a new version
of the CBT Tape and you're trying out an updated version of one of
these programs for the first time, a "test in a hurry" could consist
of copying some load modules out of File 035 or File 135.

      Well, I guess it's time to go.  I hope you've gained something
from this month's "sojourn into the unknown".  There's a lot more
material awaiting you on Version 420 of the CBT Tape.  Please spend
some time looking at Figure 1.  See you next month.


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


Figure 1.   Summary of File Changes in Version 420 of the CBT Tape.


 File Number         Quick Summary of Contents or Changes
 -----------         ------------------------------------

  001           Documentation File is now in mixed case.
  004           CBTUPDTE edit macro - IEBUPDTE separators in File 001
  006           Tools to manipulate File 001 and improve readability.
  035           Load module library. Latest version of PDS 8.5 etc.
  071           Updated documentation of other tapes. JES3 Tape.
  118           SMP/E SMPPTFIN pre-processing.  Upgrade to COBOL/370.
  120           More of these articles.  (MVS Tools and Tricks)
  130           Former File 006. Loads File 001 into INFO/MVS database.
  134           Greg Price source.  Latest version of REVIEW, etc.
  135           Greg Price load modules.  SHOWMVS load module, etc.
  166           Vinh Vu's collection, updated.
  171           LU 6.2 Bulk Data transmitter. With DITTO, DISASM etc.
  182           PDS package. Version 8.5, update 8, from John Kalinich.
  183           Gilbert Saint-flour collection.  New SHOWMVS program.
  296           Utilities that work with PDS 8.5, and standalone too.
  300           Update to CDSCB for Y2K. With zillion other TSO pgms.
  311           Refresh of Dave Alcock's large utility collection.
  312           Lionel Dyck's ISPF FTP Batch interface, and XMITIP.
  321           Roland Schiradin's COBOL load module analysis pgm.
  338           Gilbert Saint-flour and Larry Williams - P390 tools.
  344           REXX exec from Joerg Berning to do a VTOC map.
  347           Look at load library and list COBOL compile options.
  348           Pgms to list pds members in alphabetical order.
  349           Change your ISPF command table options on the fly.
  350           JES2 exits. Convert JCL from Mellon Mods to SCHENV=.
  351           Programs to list currently installed LE level.
  354           Randy Hall collection of programs. New. BACKDSNS etc.
  355           KONCAT (concatenation program) from Kaiser Permanente
  356           NETSOL (VTAM multi-session manager). Works for OS/390.
  357           PDSGEN, PDSLIST programs from Carl Hafner of Steli.
  358           SYSOUT writer from Eric Bielefeld.
  361           Frank Johnston programs. Multi-string scanner, etc.
  362           Frank Johnston load modules.
  363           ISPF/PDF Data Set Name change exit. (ISPF exit 16)
  364           Control Card Subsystem. Works for OS/390.
  365           Error-check multiple-file TSO XMIT pkg from Ron MacRae.
  369           Multiple changes to DSPACE program from Dale Vick.



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


Figure 2.   Sample ISPCOMND member to update the incore copy
            of your ISPF command table using the REXX exec
            ISPCMDU from Willy Jensen (CBT Tape File 349).
            You copy this member into your ISPF.ISPPROF dataset,
            and edit it according to your taste.  Each line
            adds a separate new ISPF command.  The new
            commands are usable immediately after invocation
            of the ISPCMDU exec.


/*    MEMBER TO UPDATE THE ISPF COMMAND TABLE IN STORAGE  */
/*  ------ you should enjoy using this immensely ------   */
/*  ------     Invoke by issuing TSO ISPCMDU     ------   */
/SHOWMVS/5/SELECT PGM(SHOWMVS)/INVOKE SHOWMVS COMMAND/
/PDE/0/SELECT PANEL(PDS@PRIM)/STARTOOL OR PDS 8.5 MAIN ENTRY PANEL/
/SX/0/ALIAS SAVE                    /SHORT FORM OF SAVE/
/SP0 /0/SELECT PGM(ISPISM) SCRNAME(SETTINGS)/ISPF 0/
/SP1 /0/SELECT PGM(ISRBRO) PARM(ISRBRO01) SCRNAME(VIEW)/ISPF 1/
/SP2 /0/SELECT PGM(ISREDIT) PARM(P,ISREDM01) SCRNAME(EDIT)/ISPF 2/
/SP3 /0/SELECT PANEL(ISRUTIL) SCRNAME(UTIL)/ISPF 3/
/SP4 /0/SELECT PANEL(ISRFPA) SCRNAME(FOREGRND)/ISPF 4/
/SP5 /0/SELECT PGM(ISRJB1) PARM(ISRJPA) SCRNAME(BATCH) NOCHECK/ISPF 5/
/SP6 /0/SELECT PGM(ISRPTC) SCRNAME(CMD)/ISPF 6/
/SP7 /0/SELECT PGM(ISPYXDR) PARM(&ZTAPPLID) SCRNAME(DTEST) NOCHECK/SP7/
/SP8 /0/SELECT PANEL(ISRLPRIM) SCRNAME(LMF)/ISPF8/
/SP9 /0/SELECT PANEL(ISRDIIS) ADDPOP/ISPF 9/
/SP10 /0/SELECT PGM(ISRSCLM) SCRNAME(SCLM) NOCHECK/ISPF 10/
/SP11 /0/SELECT PGM(ISRUDA) PARM(ISRWORK) SCRNAME(WORK)/ISPF 11/
/SP31/0/SELECT PGM(ISRUDA) PARM(ISRUDA1) SCRNAME(LIBUTIL)/ISPF 3.1/
/SP32/0/SELECT PGM(ISRUDA) PARM(ISRUDA2) SCRNAME(DSUTIL)/ISPF 3.2/
/SP33/0/SELECT PGM(ISRUMC) SCRNAME(MCOPY)/ISPF 3.3/
/SP34/0/SELECT PGM(ISRUDL) PARM(ISRUDLP) SCRNAME(DSLIST)/ISPF 3.4/
/SP35/0/SELECT PGM(ISRURS) SCRNAME(RESET)/ISPF 3.5/
/SP36/0/SELECT PGM(ISRUHC) SCRNAME(HARDCOPY)/ISPF 3.6/
/SP37/0/SELECT PANEL(ISPUDL) SCRNAME(DOWNLOAD)/ISPF 3.7/
/SP38/0/SELECT PGM(ISRUOLP) SCRNAME(OUTLIST)/ISPF 3.8/
/SP39/0/SELECT PANEL(ISPUCMA) ADDPOP SCRNAME(CMDTABLE)/ISPF 3.9/
/SP311/0/SELECT PGM(ISRFMT) SCRNAME(FORMAT)/ISPF 3.11/
/SP312/0/SELECT PGM(ISRSSM) SCRNAME(SUPERC)/ISPF 3.12/
/SP313/0/SELECT PGM(ISRSEPRM) SCRNAME(SUPERCE) NOCHECK/ISPF 3.13/
/SP314/0/SELECT PGM(ISRSFM) SCRNAME(SRCHFOR)/ISPF 3.14/
/SP315/0/SELECT PGM(ISRSEPRM) PARM(S4) SCRNAME(SRCHFORE) NOCHECK/3.15/