MVS TOOLS AND TRICKS OF THE TRADE
                          AUGUST 2002

                                      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.


POSITIONS, AND THE DIVISION OF LABOR

      Today I'm going to talk about a general principle more than usual,
with some of its ramifications.  The reason is, that if we all review
these ideas and let them "knock around inside our heads" for a while,
they'll eventually cause a lot of improvement in our quality of life,
both as "MVS System Doctors", and in other ways.  We'll eventually stand
to get a lot more satisfaction, on many fronts.  This idea revolves
around the general concept of dividing big jobs into many little jobs,
but there's a lot more to it.

      All of you know that MVS is a big operating system.  And just
about everyone in a corporate organization, or who has ever been a part
of one, knows that big corporations do a big job.  And there is one
basic way that the big job gets done.  That is, the big job is broken up
into smaller pieces.  Each piece is broken into even smaller pieces, and
finally, there are bite-sized pieces that one person can handle.  When
everybody covers his/her own piece, the corporation functions well.
Otherwise, problems result.

      Similarly, the MVS operating system does a big job.  And just like
the big corporation, this big operating system is broken into smaller
components, which handle smaller portions of the big job.  Finally, all
of the components are broken into bite-sized pieces--executable modules,
which form the individual units of execution, in this huge MVS system.
For the MVS system to function well, each module (i.e program) has to do
it's own job, and all the programs have to work together.  If one
program is remiss in its duties, problems result.

      This is very obvious to most people in the modern world, and why
does the world's big business, and the MVS operating system, work in
this way?  I'll give the obvious reason--it is due to physical
limitations.

      This is easy to see.  Let's ask an appropriate question:  How high
can a person jump in one bound?  The world record at this time, is held
by a man named Javier Sotomayor, who jumped eight feet high in a single
bound, perhaps a handful of times.  Quite a few other people have jumped
over seven feet, but nine feet--not one!  Yet, people walk up flights of
stairs every day, and the total amount of height they have scaled, is
much more than nine feet.  What's the difference?  They broke the big
"jumping job" into bite-sized pieces--each piece, the height of a step
on a staircase!  And scaling each step, is a job that can be handled.


LEARNING TO GENERALIZE THE PRINICPLE

      I want to take a few moments to digress from MVS in particular,
and talk about the ramifications of the idea of dividing big jobs into
bite-size tasks.  It's not the "division of the labor" that's the most
important thing.  It's the "division of the people who do the labor",
so that the appropriate people do the appropriate jobs, and the jobs
get done!

      Many people know the joke:  "How do you fit six elephants into
a Volkswagen?"  Answer:  "Three in the front, and three in the back!"
Why is this a joke?  Because everybody knows it can't be done, unless
you have very miniature elephants.  So we see that "dividing big jobs
into little ones" is not the main trick.  The trick is "finding the
right people who can actually accomplish each small job", after the
task list has been determined.

      Everybody who works for an organization has (hopefully) learned
the lesson of "teamwork".  Each person inside the organization does a
job, and all of the people, doing their jobs at least reasonably well,
allow the corporation as a whole, to function and achieve its goals.

      But there is a lot more potential in this principle.  It also
works in a direction that has become very obvious in today's
Internet-connected world.  Cooperation and position-playing often cross
organizational boundaries!


OPEN-SOURCE EFFORTS vs. CORPORATIONS

      Let's look across organizational boundaries.  For example, in an
"Open-Source" software development effort, this principle is just as
true.  A big goal is determined.  People want to develop a piece of
software that does a big job.  And then, the big job is divided into
necessary smaller jobs, and anybody who can do one of the smaller jobs,
takes a piece of the work.  Even though a person is not "hired" by an
open-source effort, each person who "takes a piece of the job" usually
does the piece that he/she is good at, and is suited for.  When they all
work together, the result can be a very good one.

      Why is this so?  It is because each person in life, is given a set
of capabilities and abilities, different from everybody else's.  And the
tendency of each person is (more or less) to gravitate to the things
he/she likes, and is good at doing.  At this point, you can notice a
key difference between commercial organizations and Open-Source
development efforts:

      Within a commercial organization, the abilities of the different
people dovetail.  Each one is hired for a job that he/she is good at.
But in commercial organizations, there is a "Personnel Department" that
oversees the picking of people for tasks.  The overall purpose of the
Personnel Department is to make sure that each task which the
organization needs done, will be covered by the appropriately skilled
people.

     But in an Open-Source development effort, the difference is that
there's no "Personnel Department" to hire, fire, and assign people to
their tasks.  It seems to happen "by itself", but it happens
nevertheless.

     It's amazing how Open-Source development actually does work:
People get the idea that it'd be a nice thing to get a big job done.
They get together and try--each one does a piece, the best he/she can.
There is a coordinator, who plans the tasks, and then they start
working.  A prototype product is created by the initial developers.
Other people try to use the "product" that results.  It needs
improvement.  The appropriate people are notified through the "news
group" that serves as a unifier and "central nervous system" for the
effort.  And the effort goes on, each contributor adding his own
personal pieces.  New contributors come on board.  And the product
develops and grows, until (hopefully) it becomes very good.


IMPLICATIONS FOR US AS THE "MVS DOCTORS"

     Now that I've spoken "in general", I'd like to talk about some
immediate implications as to how these concepts affect us.

     Most of us occupy positions in servicing the MVS Operating System
(OS/390, z/OS, or whichever version).  So every once in a while, we
should think about where our position is, in the larger scheme of
things, and whether we can do more.  Of course, in our own job and
organization, we perform our required tasks, and keep the system
running.  But while we have been doing this, usually for many years,
we're writing programs, REXX execs, CLISTs, and whatever tools we need,
to get the job done.  We're accumulating techniques, and (some of us)
write them down.  Hopefully we save all this stuff and keep it with us
as we proceed in our careers.  (That's good advice.)  It can be safely
stated that each of us has developed a niche (the kind of jobs we're
skilled at doing) and also, a personal collection of techniques,
programs, and tools.

     But each of us can become more aware of our position in the general
"world system programmer picture".  One of the things we can do, is to
communicate more with the other MVS (VTAM, CICS, TCPIP, etc.) systems
programmers of the world.  An easy way to do this, is by using the
Internet news groups.  There are now news groups which cover just about
every specialty.  (See my April 1998 column on the IBM-Main
LISTSERV-based news group.)  And it's easier, by participating in a news
group, to get all your (work) problems solved, and to get the enormous
satisfaction that comes with helping others, too.  This is actually a
direct benefit of the idea of looking at yourself as "part of the whole
world".

     Another benefit of "MVS Global Awareness" comes from hooking into
the large free MVS software collections such as the CBT MVS Tape
collections, which are available on the Internet (www.naspa.com has a
link to the CBT Tape web site.)  Enormous numbers of MVS tools can be
had there, for free.  And by contacting the contributors of the
individual files personally, you can develop a friendship with many of
the other MVS practitioners, asking them for help, if you need some,
and providing help to them, if you can.

     Under many circumstances, there is a tremendous advantage to using
tools from the CBT Tape collection when your shop needs a job done.  The
job can usually get done without the shop having to buy anything.  And
it'll save you personally, that you don't have to write the code
yourself.  Other people have already invented the wheel!  You'll look
very good at work, when you can come up with a solution to a problem
fast, especially if it doesn't cost the shop money or much coding time.

     A new advantage from the CBT Tape collection is the swapping of
techniques.  There is a new file on the CBT Tape, File 570, which
contains people's tips on "how to do things".  The first contribution
was a piece of advice about where to look, when your JES2 spool fills
up.  There have been quite a few more contributions, but in my opinion,
that file, while already very useful, should be bigger.  Please send me
your collections of pieces of "how to do it" advice (I'm in charge of
updating that), and I'll add them to File 570.

     Another related idea, is that many of you will be able to get
enormous personal satisfaction in life, if you'll contribute from your
experience (and tool and tip collections), to some piece of public work,
such as a software development effort, or a public software collection
like the CBT Tape, yourselves.  Helping other people is a good thing.
Some folks don't realize how much of a mistake it is for them, to hold
back from helping other people.  I've seen how much a person
short-changes HIMSELF by being "selfish" and holding back from giving.
The best way to have friends is to "be a friend", and to "not hold
back", but to give something of yourself to another person who needs it
NOW.  Life has shown, over and over, that the benefit of giving
something will eventually come back to you, in spades!  It's an
under-used principle in life.  More people should know it.

     Sorry for the generalities this month.  But I've been an MVS
systems programmer for many years.  And these ideas have helped me more,
to be a good MVS systems programmer, than many others.  I think that
they are relevant to our job, and they should be specifically expressed
at least once.

     Best of luck to all of you, and I hope to see you again, next
month.