MVS TOOLS AND TRICKS OF THE TRADE
                         SEPTEMBER 2007

                                      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.


SYSTEM SOFTWARE "QUALITY"

      There are many possible "standards" by which we can judge the
so-called "quality" of MVS system software.  In order to sell some tool
or product commercially, certain standards of reliability and usability
have to be met, or else the users will not feel happy with the feel and
results of the product, and they will not want to buy it.  If their
installation has already bought it, and the sysprogs don't like to use
it, the sysprogs' opinion will surely be felt--a future recommendation
will not be forthcoming.  On the other hand, if the product is a dream
to use, and it is almost impossible to make errors with it, then its
acceptance level among the users will most certainly be high.

      On the system level, and as a practitioner, I get two feelings
about the quality level of tools.  On the one hand, there is the "quick
and dirty" tool that throws the bit I want to throw, and I don't care
what it looks like or feels like to use, as long as it gets the job
done.  On the other hand, there is a complete and polished multi-set of
tools, with its own contextual help, complete 24/7 support, and a nice
manual that is easy to use.  In between, there is everything else.  This
is the area that we want to look at today.  Not only do we want to
consider the "absolute usefulness" of a piece of software--whether it
will get the job done for us.  But also we want to consider its
reliability, helpfulness when we don't know how to do something, and its
ease of use.


THE WRITER'S (PROGRAMMER'S) POINT OF VIEW

      In the "older days" (20 or 30 years ago) when there weren't so
many free or commercial packages which catered to a systems programmer's
needs, people had to grope for a way to throw a crucial bit, and they
didn't care too much how it was done, as long as it got done somehow.
One example comes to mind from my experience.  I worked for an fairly
large sized MVS shop, JES2 was giving us problems in the middle of a
busy day, and I couldn't cancel JES2 and restart it.  JES2 (of course)
is marked non-cancelable, and I didn't (then) have a tool to make it
cancelable.  (You only have to throw one bit to do that.)  The result
was that this large company had to IPL in the middle of the day.  A
couple of months later, I acquired a free tool which can make a job
cancelable (i.e. it "knows" which bit to throw) and we never had such a
problem again.

      Now suppose I'm a sysprog, and (for argument's sake), I have done
the research and found out which bit to throw, on or off.  If I have a
minimal knowledge of how to write a TSO command, I can quickly write
a specialized command which would access the bit, and take a parameter
to turn the bit either on or off.  Of course this would get the job
done to my satisfaction, and I'd keep this tool in my "bag of tricks",
ready to use if I ever got into that situation again.  But could I ever
sell this tool as a commercial product?  Most likely not, because it is
too "raw" and it might cause a system error if somone used it
incorrectly--not as it was designed to be used.

      Suppose now, that I wanted to share my tool with other people.
In order to do that, I'd have to "clean it up" so that nobody might be
able to make an error with it or misuse it somehow.  I'd have to
examine the parameter setup, so that if you entered the wrong parameter,
you would get a meaningful error message instead of getting an
unpredictable result or an abend.  I might also have to research the
particular control block setup, to make sure it isn't release dependent,
and an older or newer MVS release would be able to run my command
equally well.  As you can surmise, there are many ways to improve the
way a program runs, and there are also many ways to make it more
foolproof.


WHAT'S IN BETWEEN?

      What steps can you take to improve a program?  Actually, there are
more things than you can imagine.  A few obvious steps would be to look
at "boundary conditions".  What would happen if the size of a parameter
exceeds the maximum that should be allowed, or it's smaller than the
minimum, or if it is not numeric, and it is supposed to be numeric?
What happens if the parameter is exactly on the border between a "good"
value and a "bad" value?  What happens if the user enters an extra
parameter that the programmer didn't anticipate?  And what happens if no
parameter is entered, when there is supposed to be one?  All of these
cases have to be considered, if you want to "clean up" a program.

      These considerations are not really enough.  Sometimes a program
appears to run perfectly, but if you would examine the code line by
line, you'd see errors that don't affect the code now.  But in the
future, some unanticipated problems might rear their ugly heads.  For
example, suppose the program has three base registers, and the last one
was not initialized correctly.  If the program currently does not exceed
two base registers, but in the future, a modification would overflow the
second base and go into the range of the third, you'd get a big problem
all of a sudden.  How do we anticipate and cure this kind of error?  In
my opinion, the easiest way is probably with a line-by-line source code
check.

      Line-by-line source code checks will expose and cure many
different classes of program error.  If you are looking at a piece of
code, and are trying to imagine what the machine is doing while it is
executing that code, you'll often see things that don't make sense.
Question is, why didn't you see that before?  Answers can be:  Maybe a
normal execution of the program won't pass through this code--only a
boundary condition will cause those instructions to be hit.  Second,
maybe an incorrect value in a register or in some other field, might not
be seen by the user during the usual execution conditions (but it could
be doing some system damage that you don't see).  Third, the program
might not be properly "cleaning up after itself".  I once had a program
that didn't FREEMAIN the storage it GETMAINed.  A system dump revealed
many multiples of the control information which this program was
supposed to create.  These are some of the non-obvious types of errors
which you may encounter.  A line-by-line source code check will reveal
this type of problem more easily than other diagnostic methods.

      Then, there is the class of error which a "debugger" type of
program will reveal.  A debugger program allows you to partially execute
a program, and stop in the middle, at crucial points where you suspect
there might be an error.  These points are called "breakpoints", and you
set them up yourself.  When you stop the program execution at a
breakpoint, the debugger program will allow you display many aspects of
the program's environment, such as the register contents and the storage
currently being accessed.  Using a debugger program will definitely help
you clean up how a program executes.  But it will not necessarily reveal
fundamental coding errors that aren't hit by an actual program execution
in a run.  For that, you still have to do a line-by-line source code
check, to examine or "eyeball" the code yourself.

      After that, there's plain old "usability".  What if a program will
execute perfecly and do what you want, without making a system error?
But it "is a bear to use"?  An example I can think of, is IBM's AMASPZAP
program which can change disk storage.  IBM made the AMASPZAP program
very general, and it has enormous capability.  But what if you want to
find a piece of disk storage containing a string, and that's the only
storage you want to change?  Then AMASPZAP is not the tool you want.
Fullscreen ZAP, a TSO command which can be found on File 134 of the
(huge and free) CBT Tape collection (www.cbttape.org), is the tool you
want to use for that job, not AMASPZAP.

      So suppose, for argument's sake, that I wanted to add a "string
find" functionality to IBM's AMASPZAP program.  First of all, I couldn't
easily do that, because IBM controls the code, and the next release of
AMASPZAP wouldn't contain my changes.  Therefore, if I were bullheaded
enough, I'd have to put in a change request to IBM, and they may, or may
not, listen to me.  If the code I want to improve is public code, such
as code on the CBT Tape, then I can fix it.  And Sam Golob, who controls
what gets into the CBT Tape collection, might be sympathetic enough and
load my improved version of the program into the collection, in place of
(or in addition to) the old version that was there before.  But in
either case, here was a program that was working properly, but it was
not usable easily enough, or it was plain "hard to use".  That, in
itself, cries out that a fix is either needed or should be desirable.


QUALITY OF PUBLIC PROGRAMS VERSUS COMMERCIAL ONES

      A vendor of commercial programs usually offers a written warranty
that the program(s) will (at least) be supported if some error or defect
is present.  The vendor has to be aware of "customer satisfaction" and
usability issues.  They certainly want to sell more licenses of their
product.  And in general, it is in the best interest of a vendor of
software, to give out good code.  So they are forced to live up to
standards, which are partly of their own making, and which are partly
imposed upon them by their customers.

      Public code, on the other hand, is expressly released with no
warranties, no guarantee of support, and the user is assumed to take his
(or her) own risks in using it.  Nevertheless, in my very long
experience with the code on the CBT Tape collection, and code from other
places, I've observed that people who write public code tend to have a
certain pride in their workmanship, and in many cases, they're more
devoted to user satisfaction than even the vendors are.

      You can see this by comparing code written under "open source"
conditions to code written by software vendors.  Of course, results may
vary, depending on who the people are, and what their circumstances are.
I've found that vendors, who are often more short of programmer time and
programming resources than their customers realize, will not make the
programming effort necessary to put in a user-suggested enhancement,
simply because they don't feel that they have the resources to allocate,
and they deem that the change will not be economically feasible.
However an "open source" programmer, who is doing it "for the love of
the game", will gladly attempt the improvement, and will even add
several more improvements of his own.  Quality of the software is not
even an issue much of the time, because the "open source" programmer,
doing it for pride, will take the user feedback and gladly fix any code
that is shown to be in error.

      I have, over the years, of course seen exceptions to this on both
sides of the fence.  Some software vendors are extremely responsive, at
least to "program fix" requests.  But in general, the vendors are trying
to make as much money as possible, once a software product has been
developed and is "mature".  They don't want to mess with code that has
worked for a long time (and which they warranty in writing).  So I'd say
in general, that vendors tend to be less inclined and flexible with
regard to putting in "usability fixes" then are the "open source"
writers.


SUMMARY

      "Quality issues" in system software should be thought about.
Today, I've only scratched the surface in dealing with them.  But I want
to open your minds and generally get you to think about factors which
affect software "quality".

      You can't beat the price of free software.  But it must be pointed
out that a writer of free software is not being FORCED to make his
programs the best that they can be.  Nevertheless, in many cases,
someone who writes free software, and (you and) they know who they are,
takes enormous pride in their work, and they do it for the love of it.
They are also not restricted by any economic factors, other than the use
of their time.  So the "free software writers" tend to be more open to
improvement suggestions because of this.  And sometimes, strange as it
may seem, free software is simply better.

      But, free or vendor-supported, quality is the bottom line, unless
of course you need a tool quickly, and you must write your own.  In that
case, the main idea is simply to get the job done any way you can.  And
for that purpose, the tool which was used, doesn't necessarily have to
be polished up, or adhere to a group of standards.

      I hope that you've found this month's issue to be thought
provoking, and I wish all of you well.  Best of luck.  See you here next
month!