MVS TOOLS AND TRICKS OF THE TRADE
                         DECEMBER 2004

                                      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.


IDEAS

      We systems programmers have to be creative people.  It is a
requirement of the job.  When you're setting up an MVS system or you're
fixing a problem with the system, you have to be logical, methodical,
neat, and clever.  If somebody isn't one of these, it'll lead to a
problem in all likelihood, because an MVS system has parts which all
have to be set up correctly, not interfere with each other, and work
together with each other.  Arrangements of datasets on disk packs also
must be carefully considered, and dataset placement has to be planned so
there won't be production problems later, with contention and such.

      So during a typical day on the job, you're usually called upon to
resolve a sequence of (possibly unrelated) problems, each of which
requires careful thought.  And sometimes you're stuck.  Where do you
pull ideas from, which will get you unstuck?

      Usually it's from experience.  After years on the job, you've
probably seen 90 percent of the problems before.  In the simple cases,
the error messages lead to a certain MVS component, and there's more or
less a "yellow brick road" to follow, which leads to an answer.  But not
always.  Timing problems, in particular, are very difficult to address.
And sometimes an error message from one component is merely triggered by
a problem in a completely different component, and it takes a lot of
digging to get to the bottom of it.

      Nevertheless, I have never forgotten what I was told on the very
first day of my first systems programming job.  And that is, that if
there is a problem, look up the error messages.  See what the book (the
IBM manual) says.  Then go from there.  In most of the cases, the error
messages will point out what direction to go in, to eventually solve the
problem.

      It also helps to have some knowledgeable friends in the business,
but not necessarily somebody working at the same shop.  There's an
advantage to calling someone at a different shop who is your friend.
Mainly, you don't "look bad" to your friend when you can't solve
something.  The truth is, that EVERYBODY can't solve something
sometimes.  No matter how "good" you are in this business, sometimes the
solution to a given problem will elude you.  So it's actually no "shame"
to be stuck once in a while.  However, within a shop, there can
sometimes be rivalries between the staff, and pecking orders.  If you
call someone outside, there's no temptation to do that silly sort of
stuff, because you're both not trying to impress the same boss.  And
you'll get your problems solved without any unnecessary emotional junk
mixed into it.  Therefore it's good to have at least one knowledgeable
friend who works outside.


BUT WHAT IF YOU'RE REALLY STUCK?

      I'm just grappling with a situation, as I write, where I'll
probably have to draw a solution from my own experience outside the
systems programming field.  Once in a while, you can get an idea from
what someone said on a news program, or in an old movie that you've
recently watched on DVD, or from some experience that you acquired in a
previous job, before you ever thought of working in the computer field.
One thing which life has taught me:  "You should never throw out
anything that you have ever learned or seen.  It might come back to help
you someday, often in some unexpected way.  BTW, you should always trust
that your many experiences won't fill your mind up.  You have enough
mental capacity to keep and hold everythihg that you've learned."

      For instance, my own particular previous background was "Pure
Mathematics".  Pure mathematics is all about "proving theorems" and it
doesn't bear too directly on the kind of work I have to do now.  Most of
the people who do "pure mathematics" are very abstract thinkers and are
generally not the types who do things practical, like fixing a table in
their house when it is broken.  If you're trying to grapple in your head
with truths about "n-dimensional manifolds" and trying to picture how
they work (a very old mathematical topic which roughly deals with curved
n-dimensional (n usually bigger than 3) spaces) or if you're into one of
the newer mathematical fields which are all very abstract, then
practicality of thinking usually gets in the way.  I personally am not
built like that mentally.  I like to fix my table.  That's why I left
the mathematics field.  (Besides, it doesn't pay much, for all the
mental work you have to do.)

      But, some of that mathematics training is helping me solve my
programming problem that I have now.  The particular idea I'm pulling
from the mathematics discipline is, that when you're analyzing a
process, you have to get to the bottom of how it really works, without
imposing any extra ideas on it.  Proving mathematical theorems is like
that.  You have to be (what mathematicians call) "elegant".  It means,
getting to the bottom of what's really going on, with absolutely no
frills and nothing extra to obscure the facts.

      So in my particular case, I wrote a program a few years ago which
works, but which doesn't take all the possible cases into account.  (If
you really want to know, it is my VTT2TAPE program from CBT Tape File
533, which cuts a "real tape" from an AWS-format virtual tape image on
an MVS system.)  When I wrote the program originally, I got it to work
for SOME AWS-format virtual tape files, but not for all of them.  Now I
am being forced to re-write the program to cover the rest of the
legitimate AWS-format cases which I didn't anticipate before.  In the
case of my program, it is not a simple fix.  I see now, that when I
wrote the program originally, I didn't really get to the bottom of what
was going on.  I imposed my own artificial ideas on the cases I knew
about, and I programmed for them.  Now I see that I have to rip much of
the program apart, and just program for the bare essentials.  I was
wrong before.  I didn't really look at the situation the way I should
have looked at it.  And my previous mathematics background showed me the
way to do it right.


PACKAGING PROGRAMS FOR THE CBT TAPE

      I know this is an MVS column and you don't want your time taken
up by general concepts of "idea grabbing", unless they relate to what
we do every day.  So I'm going to talk about some of the things I do
every day.  I'll give you a small glimpse into where I pull my ideas
from.  And then you yourselves can pull some of these ideas from here,
to gain a bit of benefit for yourselves.  Most of what this is about,
relates to moving moderate amounts of data from one system to another,
or from one shop to another.

      As proprietor of the "CBT Tape" collection of free MVS software,
it is my business to gather up people's useful tools, software,
techniques, and other things--anything that will help an MVS systems
programmer to do the work better.  BTW, do a www.google.com search on
"CBT Tape" if you want to know how to get these free materials.

      Nowadays, we are not dealing with "pure MVS" anymore.  Most of us
now work on Windows-based terminal emulators, not on directly-attached
"green screens".  Recent directions in computing, such as the fact that
many people are running MVS on Linux-based FLEX-ES systems, force us to
diversify and relate to tools that are partially rooted in non-MVS
systems as well as in MVS itself.  For example, many people now write
their documentation for MVS tools in Microsoft WORD or in PDF format,
and that stuff is not directly usable on MVS.  You need a PC, and you'd
probably have to deal with some Windows-based system, to be able read
the doc for these MVS tools.

      Now by definition, the CBT Tape collection is MVS-based.  But as
the proprietor, I have to account for all the new diversity in MVS
system tools.  For example, I just got some contributions which do
FLEX-ES tape management, RACF reporting, and CICS work, using Perl
scripts on Linux.  (This is from John McKown.)  There is an MVS portion
of each tool, and a Linux portion which has to be packaged in a TAR
file.  To fit the CBT Tape requirements, I have to get all of that stuff
into FB-80 EBCDIC format.  This was a problem to solve, and I needed to
gather ideas.  John himself provided many of them.

      To understand it better, let's back-track and relate some history.
When Arnold Casinghino started the CBT Tape collection almost 30 years
ago, he put separate programs into separate tape files.  Then he started
to gather multiple files into pds'es, and package them on the tape using
IEBCOPY.  After that, a program was written (called CBT973) which took
a pds that was in IEBUPDTE format and squeezed the blanks out.  For
source code, that program saved almost half the length on a tape over
IEBCOPY packaging.  Load modules and other non-FB-80 materials still had
to be dealt with using IEBCOPY if they were pds-based, or with IEBGENER
if they were in some weird sequential format.  And the load modules
could never be packaged together with source modules for the same program
package.

      All of this changed, when TSO XMIT format started to be used.  TSO
XMIT format was designed to send non-VSAM files over JES transmission
lines.  JES2 and JES3 both are very FB-80 friendly.  So in order to
facilitate the transmission, the idea was first to transform the data
from whatever format it was in, to sequential FB-80, transmit it, and
then to maintain integrity and transform it back the way it was, once it
reached its destination.  For our purposes, we weren't interested in the
transmission of the data over the NJE lines.  We were interested in
transforming it to and from FB-80 sequential format reliably.  We took
advantage of the OUTDSN( ) keyword of the TSO XMIT command, which does
this transformation.  The XMIT command (and its opposite number, the
RECEIVE command) are IBM-created programs that are found on all MVS
systems which have TSO/E.  So if you can reliably create FB-80 format
files out of almost anything, then you can package a load library as a
member of the same pds which contains the source code.  And there are
zillions of other possibilities that this XMIT facility opens up, when
we consider using it for our packaging purposes.

      So how does John McKown package his Perl scripts for distribution
on an MVS system?  He FTPs a TAR file containing them, from the Linux
system to a sequential file on an MVS system, and then puts it into
FB-80 format on MVS using the XMIT command and its OUTDSN( ) keyword.
This becomes a member of a pds on a CBT Tape file.  To use the material
on Linux, you have to RECEIVE it on the MVS system and then FTP the TAR
file back to Linux, where it can be expanded and used.  Since quite a
few people have such a configuration nowadays, we can still use "pure
MVS" to distribute software that is meant to be used only partially on
MVS.

      While we're talking about that, I might as well mention that we
have MSWORD and PDF files on the (MVS-based) CBT Tape too.  Sometimes
when it's too hard for me to convert somebody's WORD doc to EBCDIC FB-80
text, I just FTP the WORD (or PDF) doc in BINARY to an FB-80 file on
MVS, and make it a member of a CBT Tape file pds.  It takes up a lot of
room, relatively speaking, but the process works!  To use these files,
you have to FTP them back to a pc, of course.


SUMMARY

      I certainly hope that you've gotten some benefit from reading this
month's column.  The point is that in order to solve our problems, we
shouldn't limit our thinking, but we should set our minds to be able to
pull ideas from ALL of our experiences, not just our current
work-related ones.  We should try to use these ideas, and bring them to
bear on the daily problems we are solving.  If a simple solution
suffices for the current task, then all well and good.  But if we have
to rack our brains on a tough problem, maybe we should start thinking of
that movie we saw last week.  It might give us a good idea.

      I wish you all a happy and prosperous year, as we are finishing
the 16th year of this column and going into the 17th.  You can find
all of these columns on File 120 of the CBT Tape collection, so if you
want, you can look up any of the back ones.