MVS TOOLS AND TRICKS OF THE TRADE
                          January 1990

                                      Sam Golob
                                      MVS Systems Programmer
                                      sbgolob@cbttape.org

           TAPE MAPPING, TAPE LOOKING, AND TAPE COPYING

      I am pleased to announce that the unbelievably useful "CBT" MVS
Mods tapes, which have been available from the Connecticut Bank and
Trust Company for many years, will still continue to be available from
NaSPA.  In spite of the imminent closing of the CBT data center,
provision is being made to continue the updating of these valuable
tapes.  NaSPA, and SPLA at the University of Miami will become the
primary distributors of the tapes for the public during the time that
Arnold Casinghino is being resettled.  I am hoping that both the
functions of editing and distribution of the tapes can be returned
back to Arnie when his situation gets stabilized.

      I have received several panicky calls from programmers who have
fixed their code from the CBT tape, and who want to know where to
send the updates.  If Arnie's phone (203) 244-5495 is still working at
the time of print, please find out the details from him.  Otherwise,
contact me at Newsweek in Mountain Lakes, New Jersey for current
information and status on the tapes, or contact NaSPA in Milwaukee.

Note: (The CBT Tape materials are now obtainable from www.cbttape.org.)

      Again, please order the "CBT" tape (now renamed the "Former
Connecticut Bank Tape" of MVS Mods, for want of a better way to keep
the acronym) from NaSPA, (414) 423-2420.  For your information, there
is a good tape copy program called COPYMODS on file 229 of the CBT
tape, which you may use for creating additional copies.  That may
help to split the higher tape handling cost of 50 dollars from NaSPA.
(Since this month's article concerns tape manipulation, I'd suggest
that you read on for details on how to use the COPYMODS program.)

    *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

      Now to this month's topic, which concerns available tools for
dealing with tapes and cartridges.  I am of the opinion that handling
tapes is a lost art.  Many people think that nowadays, since disk
storage space is so abundant, one need not concern oneself on a major
basis with tapes.  They tend to regard tapes as antiquated--a
throwback to a bygone era.

      How wrong they are.  There is a great difference between the
needs of a Technical Support Department and those of a production
application environment.  We "techies" tend to squirrel away a lot of
our software resources for future retrieval when they might be
needed.  Many companies, even nowadays, are hurting for disk space.
Unless the disk space is really abundant, shops may be reluctant to
commit large enough quantities of it, toward what can be regarded as
"dead storage" for those "inscrutable genius types" in the corner
section of the floor.

      It is easy to forget how large a quantity of data can be stored
on one small tape--even more so, on a cartridge.  We shall discover
that a relatively small amount of disk space can be exploited, to
accomplish quick retrieval of data from a huge private Technical
Support tape library.  One need only know how to use the available
tape-handling tools.  The entire Tech Support department can be the
grateful beneficiary of the easy access to large quantities of
software materials, which formerly stood unnoticed, unused, and
stuffed into cardboard boxes in the back closet.

      Tape mapping programs, tape copying programs, and tape "splicing"
programs are the keys to better utilization of the tape medium.  In
addition, my handy "finding" system for tape data, which is easily
implemented, can make the location and retrieval of data on tape far
easier.  I shall review the essentials of my tape data finding system
after our discussion of the TAPEMAP program.

      One of the aims of this column is to bring new techniques
within the reach of every MVS shop, regardless of budget.  I will
therefore concentrate on implementing my techniques using FREE
SOFTWARE, although vendor products may further enhance these processes
and might even make possible other and better methods.  We're merely
trying to induce people to utilize their noggins, and we'd like to
start our readers thinking of new ways to get their jobs done.

      Let's start with tape mapping programs, in particular, the
program found on File 299 of the CBT tape, known as TAPEMAP.

      There are many "tape mapping" programs floating around.  The
minimal job of a tape mapping program is the display of information
in tape labels (for standard-labeled tapes) and the reporting of
block size and block count information for all tapes, by means of
some scanning method.  There are tape mapping programs which will
attempt to calculate and display footage counts, to give the user an
indication of how full the tape is.  Many such programs also include
COPYING functions for tapes, although strictly speaking, the MAPPING
function is one of summarization, and reporting of record totals and
other statistics.

      I am not including in this classification, programs such as
OSDITTO (from IBM) or MVS DITTO (the cleaned-up newer version of
OSDITTO), which actually PRINT OR COPY THE DATA on the tape.  My idea
of a MAPPING PROGRAM is that it perform the function of SUMMARIZING
THE CONTENTS OF AN ENTIRE TAPE.  Data printing and copying of tape
data is a different classification.

      The best example of a tape mapping program in this category is
TAPEMAP (CBT tape file 299).  TAPEMAP produces two reports (see
figure one), which superlatively cover the ground of what is good in
a tape mapping program.  The first report (which has some variations,
controlled by parms) displays the label fields (for standard-labeled
tapes), data summary information obtained from BLOCK SCANS, and
footage counts.  The footage counts are obtained by estimate, either
from the labels, or from the actual data scan.  If obtained from a
scan, these footages are usually very accurate.  The record format of
each file is also indicated, if found in the labels; the program
itself can only scan data blocks, but not individual records.

      So far, this does not sound unusual.  However, in addition to
these things, TAPEMAP recognizes at least ten standard MVS file
formats, such as IEBCOPY, IEBUPDTE, FDR, FDRDSF, SMPPTFIN, and
IEHMOVE.  When reporting on each file in its first report, TAPEMAP
will indicate the presence of one of these file formats if it
recognizes it from reading the tape.

      TAPEMAP's real distinction comes from its second report.  The
second TAPEMAP report concerns the special file formats that are
recognized by the program.  On that report, MEMBER NAMES from the
unloaded pds library are displayed.  In the special case of an FDR
tape dump, the dataset names of files that were dumped by the backup
are listed, along with the "vital statistics" from the original
disk files that were backed up.

      For the IEBCOPY format, all members in the library that was
unloaded, are listed.  For IEBUPDTE, not only is the member name
information present, but also whether the update is an ADD, a CHANGE,
or a REPL.  For SMPPTFIN, the SYSMOD NUMBER is listed, together with
information on whether the sysmod was a PTF, an APAR, a USERMOD, or a
FUNCTION.

      I have recently modified the TAPEMAP program to list INTERNAL
MEMBERS WITHIN MEMBERS, for IEBUPDTE-unloaded tape files.  Such a
situation might occur in a package of programs that has its own
macro library.  Rather than mix the macros as members of the source
pds, together with the source programs, the author would rather
PACKAGE ONE PDS MEMBER OF ALL THE MACROS TOGETHER, in IEBUPDTE-unload
format.  This member would later be converted into a separate macro
library at product install time.

      In order to insure that the IEBUPDTE program will continue to
treat an entire macro library "member" always as only one member, the
'./' strings denoting member manipulations within the macro library
are all altered to another string, such as '><' after the creation of
the unloaded library "member".  IEBUPDTE will then ignore those
internal manipulations for the time being.  TAPEMAP as now modified,
will read an IEBUPDTE-unloaded pds file as before, but it will also
report the names of all the macros in these "imbedded" macro
libraries, in addition to showing all the regular member names.

      My modification of TAPEMAP also allows it to read the compressed
files on the CBT Tape directly, and to report the names of all members
of the dumped and compressed libraries on that tape.  It therefore
provides us with a vehicle to "scope out" the contents of a CBT tape,
member names and all.  That helps us get more easily to the files
on the CBT tape which we want to look at.

      One of the most useful applications of TAPEMAP, in my opinion,
is that of FINDING MEMBERS, LOAD MODULES, OR PTFS, ON A TAPE.  This
is a usefulness that was not anticipated, or possible, with the
ordinary run of tape mapping programs, because they do not provide
the ability of DISPLAYING THE NAMES OF INDIVIDUAL ELEMENTS LOADED on
the tape.  With TAPEMAP's report two, and the reporting of individual
member names, updates, or PTFs, the ability of looking these up
becomes a conceivable goal.  Only one obstacle remains to having a
viable tape search system--that of being able to do a quick search
for a particular element name string.

      The free PDS program on the CBT Mods Tape (or its vendor product
successor, PDS/E) provides the missing part to an efficient tape
library search system.  The PDS programs have a "global string search"
facility (their "FIND" subcommand), which allows a quick search for a
character string across many members of a partitioned dataset at once.
Therein lies the final key to the tape search system.  One need only
move the two TAPEMAP reports for a tape, INTO TWO SEPARATE MEMBERS OF
A PARTITIONED DATASET WHICH HAS LRECL=133.  Every tape in our collection
can be so mapped.  Then a SEARCH FOR A MEMBER OR PTF will merely
consist of executing a PDS "FIND" COMMAND for the desired string,
against groups of members (or all members) of the "map pds".

      For example, we have a collection of PUT tapes from 8701 thru
8906, and we want to find one PTF, say UY26372.  Assume that we have
run all these tapes thru the TAPEMAP program by having executed a
PROC (see figure two) that created two pds members for each tape read
in.  Again, say PUT tape 8709 is assigned VOL=SER=TM8709, and the two
members created in the pds called 'TST.PTFTAPE.MAPS' are called:
TM8709 for report one, and TM8709M for report two.  Since this
mapping has been done for all our tapes, 'TST.PTFTAPE.MAPS' has a
collection of members which range from TM8701 and TM8701M, to TM8906
and TM8906M.

      With this having been set up, we need merely invoke the PDS
program against the current dataset of 'TST.PTFTAPE.MAPS'.  We then
issue a FIND command:  FIND : /UY26372/    (where the colon stands
for "all members of the current pds").  The PDS program will yield a
result (see figure three) showing that UY26372 is found on tape
TM8807.

      This same technique can be used for IEBCOPY-unloaded files,
if one is searching for a source or load module member.  It can
even be used to search for a member name on the CBT Mods tape
itself.  IN THIS WAY, A RELATIVELY SMALL AMOUNT OF DISK SPACE (THE
TAPE MAPPING PDS) CAN BE USED TO "INDEX" A LARGE NUMBER OF TAPES,
QUICKLY AND EASILY.  Our "easy finding system" for tape data has
become a practical reality.

      TAPEMAP has other uses.  For example, it can be used to
monitor when a tape is becoming full, or if there still is a lot of
room left on it, to store more data.  We can get a good idea if we
are getting efficient use of our tape storage space.

      TAPEMAP can report defects on a tape.  It is rather detailed
in specifying I/O errors that were encountered.  Because of the
wealth of material in its reports, other clever uses can be found
for the TAPEMAP program.  In short, TAPEMAP is a handy tool that
merits study, because it can be used for many purposes that we have
not anticipated.  We have too many preconceived ideas about what such
a program can or cannot do.

      The next program on our agenda is called "TAPESCAN".  TAPESCAN
versions have been around for many years.  A version of TAPESCAN that
is able to read cartridges, can be found on a newer CBT tape, on File
102.  This is the particular version we will talk about.

      TAPESCAN does functions in two categories.  It MAPS, or
SUMMARIZES the contents of a tape.  It also can be used to COPY DATA
FILES from one tape to another.  It is superior to TAPEMAP in that
it can be told to skip a given number of tape marks, and it can deal
with "weird" tapes.  TAPEMAP is more suited for "normal" MVS tapes.

      TAPESCAN's mapping report does not look much like TAPEMAP's
reports, although there is some overlapping of the information
conveyed.  By and large, TAPESCAN has a different purpose:  it can
actually summarize the contents of the tape's DATA FILES (see figure
four), and IT SHOWS ACTUAL DATA, DUMPED IN HEXADECIMAL.

      TAPESCAN, in its MAP operation, does three things.  First,
it dumps the contents of the tape labels (for labeled tapes).
Second, it dumps the first hundred bytes of each record of a tape
file (in hex) for "n" records at the beginning of EACH file--default
for "n" is four records.  This constitutes what may be called "a
summary of the data".  Finally, at the end, it does a short version
of what TAPEMAP's file one does, showing statistical counts for each
tape file, and issuing summary total statistics for the entire tape.

      In addition to its mapping function, TAPESCAN is a good utility
for copying tapes.  it issues its mapping report at the same time
it is copying the data from one tape to the other.

      This version of TAPESCAN (from file 102 of a recent CBT tape)
can deal with cartridges as well as reels.  This makes it "special".
It was contributed by Frank Pajerski of Syntelligence in California.
Most other versions of TAPESCAN that are to be found, only can deal
with tape reels and do not work for cartridges.

      Now, we'll ease away from the programs which are primarily
mapping programs, toward the ones which are principally COPYING
programs.

      Among these is IBM's field-developed program OSDITTO, a card
and tape copy-dump-print utility that is the OS version of the
ubiquitous DOS and VSE DITTO programs.  OSDITTO can be used to dump
the contents of a tape file, or copy any part of it, record by
record.  It respects only the physical data contents of a tape, and
has absolutely no respect for logical structures recognized by an
operating system, such as an OS or DOS Standard Label.  With OSDITTO,
you can ABSOLUTELY DISPLAY what is on any part of a tape, with the
exception of what a tape mark really is.  (You do see the EXISTENCE
of tape marks, and OSDITTO can write them at any point on a tape,
as desired.)

       With OSDITTO, one can copy any parts of a tape file to disk,
to another tape, or to cards.  OSDITTO is decidedly NOT A MAPPING
PROGRAM by our definition, because IT DOES NOT SUMMARIZE OR MAKE
STATISTICAL TOTALS from a tape.  It merely dumps or copies tape
data as it is.

      OSDITTO, for the record, can be run either from an MVS
Operator Console, or from a batch run.  When it is run in batch, the
EXEC card has to say 'PARM=JOBSTREAM'.  A help sheet, produced by
OSDITTO function "XXX", gives complete syntax of all functions, for
either console or batch operation.  As DOS or VSE users know, DITTO
offers exquisite control from a console, although it is a bit
awkward to use.  If you are trying to extract bits and pieces of many
files from a tape, and you want to watch what you're doing, OSDITTO
is probably one of the best utilities available.  If you want to "fix"
a tape, OSDITTO is also very good, provided you are willing to make
all the adjustments by hand.  In short, OSDITTO gives a user great
flexibility in tape copying, dumping, and altering of specific records.
This flexibility is probably its greatest asset.

      MVS DITTO is an improved variant of OSDITTO, which may be run
out of ISPF.  Being newer and better, it inevitably costs more money.

      Now we come to some "pure copy" programs:  COPYMODS, COPYFILE,
and TAPECOPY.  With the exception of TAPECOPY, these can also be found
on the CBT Mods Tape.  COPYMODS is on File 229; COPYFILE is on File
316.  TAPECOPY was written by Aron Eisenpress of the City University
of New York, and is obtainable from him at the CUNY Computing Center,
555 West 57th Street - 16th Floor, New York, NY 10019.

      The purpose of COPYMODS is to make a "Xerox" copy of a tape,
labels and all, if the tape has them.  COPYMODS has the additional
ability of making AS MANY AS TEN COPIES OF ONE TAPE IN ONE RUN,
provided the tape drives are available.  COPYMODS works well with
cartridges, and one can mix-and-match tapes or cartridges in any
COPYMODS run.  Sample JCL for a COPYMODS run is shown in figure five.
COPYMODS has been used by Arnie Casinghino to make copies of the CBT
Tape itself, and I use it for that purpose.

      COPYMODS is normally very reliable.  I know of only one case
in which COPYMODS is fooled into ending its copy operation before the
end of the input tape.  That case is when an "empty" SL file
(standard-labeled file) is present on the input tape.  This can occur
if you IEBCOPY-unloaded a PDS that has no members, which is a common
cause of the condition.  Somehow, COPYMODS "thinks" that this set of
header-trailer records constitutes a double tapemark, and it stops
copying, even though there are other legitimate files beyond that
point.

      One solution for getting around the empty file is to use OSDITTO
or TAPESCAN, to bypass the "trouble area".  Another, smoother solution
is to use the program especially written to copy standard-labeled
tapes:  COPYFILE.

      COPYFILE can copy all or part of a Standard-Labeled tape
to another SL tape.  It is very powerful, in that it can literally
CUT AND PASTE WHOLE FILES from one tape to another.  For example,
if you want to copy files 1, 7, 8, and 13 from Tape A, and files
23, 57, and 68 from Tape B, to files 1 thru 7 of Tape C, this is
easily coded with COPYFILE control cards.  Partial "HELP" for
COPYFILE is included in figure six.  COPYFILE is not fooled by any
standard labels on a tape, and it can faithfully copy an SL tape
containing null SL files within it.  The only condition is that
the output volume serial must be different than the input volume
serial, because COPYMODS actually refers the tape to the operating
system as SL, and not as BLP.

      COPYFILE is a very very powerful utility, and the implications
of having it are really much farther-reaching and warrant a larger
discussion than I can give here.  Suffice it to say that COPYFILE
allows you to custom-build special output file collections on one
tape, made from several of the tapes in your library, without the
intervention of any intermediate disk files.  Tape-to-tape
customization is definitely in your power, if you know how to use
COPYFILE.

      Finally, we shall discuss TAPECOPY.  TAPECOPY is an older
program, but it has been made to work for cartridges, since the CUNY
Computer Center is dominated by cartridges, and there are very few
old 3420 tape drives left there.  TAPECOPY is similar in function to
TAPESCAN, but with more emphasis on copying than on scanning for data.
One noteworthy thing that TAPECOPY will do, is to manufacture standard
labels, so as to make a standard-labeled tape out of a non-labeled
tape.  The DCB information that would be written on the labels for all
the files is entered as a PARM on the EXEC card, and has to be the same
for all the created file labels.  This is a drawback, but it is better
than having no such utility at all.

      Using the SL-creating ability of TAPECOPY, I have figured out
how to edit the 472-file non-labeled CBT tape without using much disk
space, but by doing mostly tape-to-tape copy processes.

      First, I create a standard-labeled master version of the current
CBT tape on a 3600-foot super reel, using TAPECOPY to manufacture the
standard labels.  Under ordinary circumstances in my shop, the CA-1
tape management system would necessitate 1419 console replies in order
to do this to completion.  (At first, I automated the replies with a
TSSO AOF table - see last month's column - but the flood of CA-1 reply
records blew the TMS.AUDIT file, so this was unsatisfactory.)  A
USERMOD from CA-1 support, reducing the number of required replies to
ONE, provided a better long-term solution, and a big standard-labeled
master CBT tape was created.  See figure seven for the JCL.

      Now that the Old Master tape is standard-labeled, I can employ
the services of the COPYFILE program.  Changed files, or new files,
can be placed on another SL "transaction tape".  Using the COPYFILE
tape-file splicing capability, a "New Master" SL tape can be created
by merging the transaction tape files into their proper places on the
big tape.  Once the CBT New Master SL tape has been finalized, all
the labels can be stripped off by a big OSDITTO batch job (see figure
eight), to create an updated, non-labeled new CBT tape to distribute.
This is a good example of how several of our tape tools can be
combined to complete a desired task.

      I hope that this article will stimulate our readers into
creative thinking.  There are enormous opportunities in innovative
tape manipulations.  Possibly, some of you will send in your ideas
as letters to the editor, or even as articles, so we all can benefit.

      Good luck, and good thinking!  See you next month.