MVS TOOLS AND TRICKS OF THE TRADE
                           JULY 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.


MEASURING AND ACCESSING TAPE DATA

      One of the hidden resources of a data center is its tape data.
I'm referring to tape data as being "hidden", because people don't think
of tape data as being readily accessible.  In order to look at tape
data, people think that you have to copy it over to something else, such
as disk, or print some of it out.  It is not easy to "read a tape
directly" without copying the contents.  The "conventional wisdom" about
tapes is, that "we know the data is there somewhere, just in case," but
we have absolutely no idea how to find it, or search out WHAT is there,
from the tapes themselves.

      Today, I'm going to talk about how to reveal more of what is
hidden on tapes.  This is an underdeveloped area of MVS knowledge, and
I'll tell you one of the reasons why I think that is so.  According to
my speculation, the IBM MVS development people were always nervous about
letting people find out about what was on a tape.  The reason is
security.  In RACF, as well as with the other popular security products,
it is easier to "secure" a data file than to "secure" a tape volume.  A
tape volume can contain all kinds of mixed data, and one tape can
contain many diverse files.  If you can make a "xerox copy" of an entire
tape and take it off site, then you might gain improper access to some
data that doesn't belong to you.  There isn't enough granularity to
distinguish what you should see, from what you shouldn't.  On the other
hand, if all of your data access is limited to "file access," then it is
easier for the installation to control "who" has access to "what" data.

      So it follows from this line of thought, that IBM has never given
the MVS world a simple tool to copy entire tapes on the volume level, as
opposed to the file level.  The one exception to this, is if you are
migrating all your tapes to an automated tape library.  Then such tools
have been made available, because since the output tapes would reside in
an enclosed tape library and would never leave the installation anyway,
except possibly for disaster recovery purposes, there isn't much danger
of an employee carrying out an unauthorized copy of a "company tape" for
himself.

      Nevertheless, tape data is, consciously or unconsciously, still
regarded as "hidden" by most people.  Although I am aware of the
security considerations mentioned above, I don't think this is entirely
a good thing.  Much time is often wasted in a shop, looking for data
that the company has on a tape somewhere, and the people don't know how
to find it.  People feel that one can't "search and browse" for the tape
data they need.  Most often, they give up trying, and I think that's
often unnecessary and a pity.  Something ought to be done about this
situation.


THE ART OF MAPPING A TAPE

      I would define the process of "mapping a tape" as that of
discovering the contents of a tape which you previously knew nothing
about.  There are tools for this.  Conceptually, it's a simple idea.
Tapes are sequential.  If they are "Standard Labeled" or SL, then the
data files are sandwiched on either side by "tape label" files, which
contain much useful information about the file contents, such as the
dataset name, file characteristics, blocking, creating jobname and
stepname, creation date, and so forth.  So if you can merely print out
and neatly format most of the fields in the tape labels for each file on
the tape, you have already made a lot of headway in discovering "what"
is on the tape.

      That is fine for Standard Labeled tapes, which have descriptive
labels, but what about Non-Labeled (NL) tapes, which don't have label
files sandwiching all the data?  In that case, a "tape mapping"
program would have to read the tape data files themselves, and would
have to draw conclusions from what it "saw" on them.  There do exist
useful tools for doing this also, as we shall see.

      Why do I call the process of mapping a tape, an "art"?  Because
there exist many free tools, as well as IBM's DITTO product, which do
various aspects of this job.  But no one single tool will show you
everything you want to know about a particular tape.  For example, if
you want to know about the data that is on each tape file, but you don't
want to see ALL of it, because that would be too much output, then you
have a choice.  You could dump a few records for each tape file, using
IBM's DITTO, but the problem is that DITTO will only dump an ENTIRE tape
block, and you might not want to see all 32000 bytes of it, if it is
that large.  Another choice of tool would be the TAPESCAN program from
CBT Tape File 102, which automatically hex dumps the first 100 bytes of
the first n blocks of each tape file, where n=4 by default, and n is
overrideable.  In a particular case, that might be the wiser choice of
tool.  TAPESCAN also formats and displays the contents of the tape
labels, if they exist.  For a similar purpose, you can use the free
COPYMODS program from File 229 of the CBT Tape, using a SYSIN parm of
READ, LABELS, HEXPRT, and PRINTRCDS=nnn, to print the first 132 bytes of
the first nnn blocks of each file on the tape, as well as the label
contents.  So that is why I call mapping a tape, an "art."  It takes
knowledge and experience with the tools, to make the correct choice for
what you want to do.

      So if mapping a tape is an "art", you have to become the "artist".
It pays to familiarize yourself with as many tape mapping tools as
possible, as well as to become somewhat knowledgeable about the various
fields of information in the tape labels of SL tapes.  This knowledge
will help you pick the proper tool to find out the particular
information about a tape that you happen to need.

      The information about data in the tape labels, may be found in the
IBM manual, "DFSMS: Using Magnetic Tapes" (SC26-7412).  If you are
licensed to use IBM's DITTO product, you should learn about its tape
functions.  But the free tape mapping tools, in my opinion, sometimes do
the job a lot better than DITTO does.

      Many of the free tape mapping tools can be found in the huge "CBT
Tape" collection of free MVS tools.  You can do a www.google.com search
on CBT Tape to find out how to get these tape mapping tools.  Notable
tape mapping tools from the CBT Tape collection are TAPEMAP from File
299, TAPESCAN from File 102, COPYMODS (a tape copying program which can
be run in READ only mode) on File 229,  TCOPY from File 193, SS0104 from
File 266, and Leonard Woren's version of TAPEMAP, which you can get from
Leonard's web site at www.ldworen.net.  Each of these programs is
different from the others, and each reports its outputs differently, but
the idea behind all of them, is pretty much the same.


WHAT DOES A TAPE MAPPING PROGRAM DO?

      A tape mapping program reads the data blocks and tape marks (the
file separator marks) on a tape, and interprets their contents.  The way
in which a tape mapping program reports what it "sees" depends on the
information that the programmer wanted it to report.  This information
generally breaks down into two categories:  tape label reporting, and
physical scanning of the tape blocks.

      The TAPEMAP program from File 299, and Leonard Woren's (different)
version of it, generally do the both of these jobs best.  So I would
recommend them most highly, if you need one program that finds out what
is on a tape.  TAPEMAP has two output DD names, SYSPRINT and SYSPRNT2.
The SYSPRINT DD name contains tape label information gleaned from the
tape labels (if any), and also the block information obtained by reading
and scanning the data blocks on the tape.  But in addition, TAPEMAP can
figure out, in many cases, which program dumped the contents of each
tape file.  For example, if IEBCOPY dumped a pds, TAPEMAP will tell you
so.  The CBT Tape File 299 version of TAPEMAP will tell you if FDR or
FDRDSF created that tape file.  There are many other formats supported
by the CBT File 299 version of TAPEMAP, such as SMPPTFIN and IEBUPDTE.
If TAPEMAP has encountered a tape file in one of its recognized formats,
the chances are that the SYSPRNT2 DD name will report the details.

      For example, if a tape file was created by an IEBCOPY dump of a
pds, then the SYSPRNT2 DD name will display the names of the members of
that pds.  If the tape file was created as an FDR dump, then the
SYSPRNT2 DD name will display the dataset names on the volume that was
dumped.  If the input tape file is in SMPPTFIN format, then the CBT File
299 version of TAPEMAP will display the PTF, APAR, or USERMOD numbers in
the file.  This is extremely useful information that you can't easily
find out with other tape mapping programs.  That is why I think that the
TAPEMAP program is often more useful than other tape mapping programs,
and it is probably the first program you should try when you want to
find out what is on an unknown tape.

      I think the second program you should try, is the TAPESCAN program
from File 102 of the CBT collection.  TAPESCAN will hex dump the first
100 bytes of the first few blocks on each tape file, and it will also
format most of the tape label information for you.  So if TAPEMAP will
not tell you enough detail about what is on a tape, often TAPESCAN will
tell you more.

      The third program I would try, is my version of the COPYMODS
program, from File 229 of the CBT Tape.  My version of COPYMODS can be
run in READ only mode, to scan the contents of a tape, as well as in its
normal mode, to create "xerox" copies of an entire tape from end to
end.  My version of COPYMODS can be made to show byte counts for all the
tape files, and to separate the byte counts in the label files from the
byte counts in the data files (the CUMSEP option).  I think that anyone
who wants to do serious tape work, should learn the details and many
options which are found in my version of the COPYMODS program.  But the
first two programs, TAPEMAP and TAPESCAN, are easier to use by default,
and they should be your first choice in getting started with tape
mapping programs.

      A fourth choice in mapping a tape might be the old SS0104 program
from Florida Power, which is on CBT Tape File 266, and which I recently
fixed up.  SS0104 will figure out footages for each tape file, as if the
tape were a 6250 bpi tape reel.  These footages give us a standard way
of roughly determining how much data is on a tape.  I have recently
imported the SS0104 footage calculation code into COPYMODS also (option
FOOTAGE in COPYMODS Level 076), so you can now also find out this
information for a tape, using COPYMODS.  COPYMODS contains many advanced
features to do all kinds of exotic tape manipulation, so if you're
serious about improving your tape skills, you should spend some serious
time learning to use COPYMODS.

       A fifth choice, TCOPY, in its LIST mode, will report maximum and
minimum physical block sizes in each tape file.  Most of the other tape
mapping programs won't report that information.  TCOPY is on File 193 of
the CBT Tape collection.


LIMITATIONS IN THE CURRENT TECHNOLOGY

       Tape files are still not as accessible to us as disk files.  In
order to change what is on a tape, you either have to make a copy of the
tape, or write it to disk and change the disk file.  In order to SEE
what is on a tape physically, the REVIEW program from File 134 can be
rigged up for that purpose, and if your tape happens to reside on an
automated tape library or a virtual tape library, the response when you
REVIEW a tape file can be very fast.  So it pays for you to look into
the free REVIEW program, and to learn how to exploit REVIEW to look
directly at the contents of a tape.  IBM's DITTO program can also be
used to browse the contents of tape files, but I think that REVIEW is
probably better suited for the purpose.  It depends on your individual
preference.

CONCLUDSION

       I feel that an MVS systems programmer must have the skill to
look at a completely unknown tape, and be able to discover what is on
it.  Before I used to install any vendor's product on my system, I
would always TAPEMAP their installation tape, and I would never take
their word at face value, without also investigating on my own.  This
skill should also be used to help you find archived information in your
company's tape library, when that job needs to be done.  In any
installation, a person who has the skills to explore completely unknown
tapes, is a valuable corporate asset.

       I wish you all the best of everything, and I hope to see you
here again, next month.