MVS TOOLS AND TRICKS OF THE TRADE
                          April 1996

                                      Sam Golob
                                      MVS Systems Programmer
                                      sbgolob@cbttape.org


Sam Golob is a Senior Systems Programmer


THE PLACE OF FREE SOFTWARE IN TODAY'S MVS SHOP.

      We've probably noticed that our profession is changing, and it's
debatable whether the change is for better or for worse.  Seemingly
gone are the days when a systems programmer actually made modifications
to the operating system, and coded in assembler language on a regular
basis.  The truth of the matter is that I know some systems programmers
who still code extensively in assembler, and who know very much about
how the MVS operating system works.  But by and large, on the strictly
MVS side and excluding some of the newer specialties, such as LAN and
client server work, there is a tendency toward hiring less skilled
systems programmers who could more be termed "installers".  As part of
this trend, the responsibility for debugging is being thrown more to
the shoulders of the vendors, and less trouble shooting responsibility
is being given to the systems programming staff.

      Many myths accompany this trend, and today we're here to discuss
sayings and thoughts which are true and false.  Or more accurately, they
are more true in one environment and less true in another.  My hope is
that this debate will focus our thoughts more clearly on activities
which will be beneficial both to our shops and ourselves.  We should
proactively watch and shape the trends that are happening in our work
places, rather than passively allow them to erode and degrade the
environment we work in.

      Our first task in this matter is to try and discern the overall
forces at work which are affecting us.  Then, we can attempt to find
ideas and policies that can help us to adjust, while maintaining our
considerable skills and our usefulness to the installation at the same
time.  Newer people who are more highly affected by these changes can
use this knowledge to plan their careers and get better experience.

      I guess we can call the first force, the "vendorization of
software".  We can call the second force, "reduction and reshaping of
our employment slots".  In this discussion, I think that the first force
weighs more heavily, so we will talk about that.  Let's take a look now
at what "vendorization of software" means.

      It used to be that when a shop needed some functionality, their
system programmers would write it themselves.  The OS and MVS
operating systems in the past were not so well developed and "feature
packed" as they are now.  Also, there was not so much vendor activity
which filled our needs.  Therefore, we had to do much of the work
ourselves, and IBM (to their credit) gave us the leeway to do it.  We
had microfiche listings of operating system modules and logic manuals
to show us how the different functional parts worked.  Many user
groups in addition to SHARE and GUIDE helped us to spread "user
knowledge" of the system and make it more commonly known.

      This has changed with greater "programming perfection" in the
MVS operating system and the incorporation of many more features into
the MVS system itself (data management being included).  Parallel to
that, there has also been an enormous proliferation of vendor software
writing activity.  Functionality that formerly had to be "custom built"
can now be "bought off the shelf".  Although there are advantages to
this change:  new releases of software can be more easily migrated
to, and the compatibility problems between products have been shifted
to the vendors, there is considerable fallout regarding personnel, and
the structure and morale of systems programming staffs.

      "Vendorization" has tempted the management of some companies
to scuttle the skill functions of their systems programming staffs
entirely.  "Installers" get paid less than seasoned systems
programmers who know how to code, diagnose, and fix software.  And as
their older staff leaves, some installations feel they can get away
with hiring far less skilled "replacements" for them.

      While there is some validity to this argument, there are also
several flaws in it.  First, some really hard problems can occur once
in a while, which could badly cripple a shop.  Often, this might happen
when one vendor's product tramples part of another vendor's product.
You can't rely on the vendors in such a case, because each one will
point a finger at the other products, and neglect to face the part of
the problem which is truly theirs.  In such a situation, your highly
skilled people will invariably grasp more of the picture, to "cut
through the fog" in a small fraction of the time that the less skilled
people would take.  The money earned by the shop's production and
reliability, will then easily outweigh the difference in the salaries.

      Second and not so easily noticeable, are the morale problems in
the personnel.  The job isn't so interesting anymore.  And the new
people have far less opportunity and incentive to learn.  The vendors
(including IBM) are covering up the guts of their products, and are
giving us "black boxes" to shuffle around.  Again, the more skilled
professionals among us, who know how to code, can often read between
the lines, when a vendor changes a product.  They can figure out the
kind of coding which the vendor had to do, to come up with such a
result.  On the other hand, the less experienced people have far less
of an opportunity to learn, because they don't have the background to
understand the internals from looking at the externals.  These people
generally don't have a clue to how the internals work, at all.  For the
installation, the result is less support, and less control.  For the
employees, there is far less stimulation and growth in knowledge.
Systems programmers have historically been highly creative individuals,
but "vendorization" is causing this creativity to decline.


HOW ACCESSIBLE SOFTWARE CAN COUNTERACT THIS TREND.

      I call free (public domain) MVS software by a different name:
"accessible software".  It is possible to contend that accessible
software has benefits and drawbacks, and we will try to make both of
these 2ore clear.  The idea is to help every shop and its employees to
benefit from a compromise.  People's attitudes can then be adjusted,
and the place of accessible software in today's MVS shop will be better
understood.

      How can you get accessible software?  The "granddaddy" of free
software tapes is the CBT MVS Utilities Tape, which can be obtained
through the NaSPA office.  The CBT Tape is a vast repository of a lot
of other people's work.  There are highly complex utility packages on
it, along with many systems programmer helpers of every description.
NaSPA itself puts out its own public domain MVS VIP software tape,
which has other goodies.  SHARE puts out a cumulative software CD ROM
after every SHARE meeting, twice a year.  On the CBT tape, there is a
description of other tapes on File 001, and there is an index to the
contents of the other tapes on File 071.  This will give you a good
start in finding accessible software.

      I myself can do all sorts of jobs with accessible software,
which would be difficult even with vendor software.  For example,
using the Fullscreen Zap program from File 134 of the CBT MVS Tape, I
can look at a disk pack and examine the IPL text online, to see which
packs have IPL text, and if it is the correct version.  With the free
"PDS" product from File 182, I can expand the number of directory
blocks in a pds in place, without reallocating the pds and copying the
members.  "PDS" now has a successor vendor product called "PdsTools"
from Serena International (Burlingame, California) which is much
better, but either package can do some jobs that almost no other
utility can do.  Changing the DCB attributes of an existing dataset (on
the fly) accurately, without opening and closing the dataset, is a
piece of cake with the CDSCB TSO command from File 300 of the CBT Tape.
And so on, almost forever.  By looking at the source code, you can
learn how all this is done.  Once you have the CBT Tape, you'll never
be able to complain that there was no place to learn how to write
assembler code.

      Accessible software has several obvious advantages.  First, your
shop doesn't have to go through an elaborate and expensive acquisition
process.  The stuff just has to be assembled, installed, and possibly
customized a bit.  Then, it's there to be used.  Another advantage is
that the source code is available to learn from.  The code can be
studied as it is, but it is often accompanied by the phone number of
one or more authors, who can be called for help, although this service
is not guaranteed, of course.  I personally have never gotten a
discourteous response from any software author I have ever called for
help.

      The learning experience from accessible software is very very
valuable.  If you want to know how something was done, you can just
look at the code.  On many occasions, if I needed to access a control
block while I was writing an exit or another program, I would look at
a program from the CBT Tape which does a similar job, and obtain
working code.  The proximity to assembler source code which you get
as an installer of these tools, affords an opportunity that is almost
unparalleled nowadays, to hone your assembler language skills and
add to your knowledge of the MVS system.

      What are the objections to accessible software?  One of them is
the supportability.  The argument is that you have to support the code
forever, in your own shop.  I have several answers for this.  My friend
Bruce Bordonaro, who is a Systems Software Manager, told me that he
advocates a sort of compromise, as follows:  You can use the programs in
your own group.  Since it's internal, it is understood what the status
of these tools is.  As far as giving them out to the public, it
depends.  If your shop has the technical expertise and management
commitment to continue support for a tool, then fine, give it out.
Otherwise, it's probably best not to.

      Another answer applies to a product like QUEUE, which is a JES2
spool browsing program akin to SDSF.  Versions of QUEUE, a free
product which is user-supported, are available on the CBT Tape for
all versions of JES2 from 1.3.6 to 5.2.0.  JES3 users need not worry.
The free JES3 spool browsing program called SDF can be obtained for all
recent versions of JES3 through 5.2.  SDF is distributed on the JES3
SHARE-GUIDE tape which can be obtained from Alan Field, 612-828-4979.
These products are needed by many shops.  Therefore the job of
upgrading them from release to release is undertaken by knowledgeable
people who feel the need, and who do it for the public and for
themselves.  Although technically true, it's hard to make a statement
that such products are "not supported".  Practically speaking, they are
supported.

      This process is aided by the proprietors of the various free
tapes, who try and accumulate the updates as users fix things.  If your
shop has upgraded some free tool to fit a later release of the
operating system or some component, please send it in to the proprietor
of a public tape, so the tape can be updated, and everyone will
benefit.  You can contact me through the NaSPA office for more
information.


SMALL SHOPS, LARGE SHOPS, AND INCENTIVES.

      I once worked for a shop that had to resist something like eight
outsourcing attempts in eight years.  In order to run our place on a
lower budget than the vendors wanted to charge, we made enormous use of
accessible software, which has the advantage that it is free.  We used
TSSO (CBT Tape file 403) for console automation, and several other tools
such as Dave Cole's automatic job scheduler (File 388) to assist in the
process.  Many other tools were available for diagnosis purposes, such
as the CMD1 subsystem (File 261) which provides multiple system-level
services, such as making non-cancelable started tasks cancelable, etc.
Although we also bought vendor products, we only bought what we really
needed, with the extra peripheral functions being provided by free
software tools.  Because we were able to resist the outsourcing, all
our jobs were saved, literally.

      That was a relatively small shop.  Large shops have to buy more
vendor software to help them with their larger workload.  But this does
not mean that systems programmers can't have handy tools which do
necessary jobs quickly, sometimes a lot quicker than the vendor
products can.  Since many of these tools are used in a great number of
shops, any problems generally get reported to the proprietors of the
free tapes where the tools are distributed, after they've been fixed by
a user.  Many "standard" tools from the CBT Tape are very reliable
indeed, because a large number of people actually use them.  In the
case of larger shops, Bruce Bordonaro's advice is very much in order:
For internal Systems Support, use and learn from all the tools you need.
If there is management commitment and technical expertise in the shop
to continue the support of a product, it is OK to give it out to the
user community.  If the commitment and expertise aren't there, it's
probably best not to.  The case of each tool should be considered on
an individual basis.

      This minimizes the risk involved.  A decently skilled systems
programmer (armed with source code) generally can estimate how safe a
product is.  For example, TAPEMAP (File 299 of the CBT Tape) tells
you what's on a tape, and it cannot do any damage, because all it does
is read tapes and it cannot write.  Therefore, my friend Rick Fochtman,
who is very careful, gives TAPEMAP out to his user community on a
non-supported basis, and he gets a lot of "thank you's" from them.

      Before closing, I have a few more thoughts.  One argument against
accessible software, is that if you don't pay for something, you don't
have a contract, and therefore you don't have anyone to sue if something
isn't right.  To this I answer:  Don't sue, fix the darn thing and avoid
the hassles.  Another answer, from Rick Fochtman, is that if you find,
for example, a copy program to substitute for IEBGENER which is better
in some way, perhaps it produces record counts and runs faster, and the
program doesn't work right, you can always go back to IEBGENER.
Looking for a second way to do something better, when IBM provides a
"first" way, always leaves you the guaranteed fall back to the old
program.

      One final thought is about systems programmer pride.  Systems
programmers thrive on the thought that they've done something to save
the company money.  There is always the hope of a bonus or some direct
reward.  But even if that isn't forthcoming, one realizes that when you
have the skills to save one company money, these skills will carry over
to another company too, and they will make you more marketable.
Somehow, accomplishment will pay you back.  One of the thrills of this
job is the opportunity to find new ways to "establish your worth" to
the operation.  Companies should realize that systems programmers can
improve their computing efficiency, and this will reflect in the bottom
line.  If you give your systems programmers the incentive to learn and
grow in the job, they will certainly save your company money in the
long run, because they are motivated to.

      I know I haven't mentioned all the arguments on all sides of
these matters.  But in this attempt to lay out the substance of these
issues which are on our minds, I hope to stimulate your thoughts and
help you establish a better relationship between management and staff
on the subject of incentive to learn, personal growth, bottom-line
computing efficiency, and staff morale.  Good luck.  See you next
month.