MVS TOOLS AND TRICKS OF THE TRADE
                           March 1995

                                      Sam Golob
                                      MVS Systems Programmer


Sam Golob is a Senior Systems Programmer.  Sam can be reached at
sbgolob@cbttape.org.  Documentation about the CBT MVS Tapes can be
found on the web, at  http://www.cbttape.org


DATASET RECOVERY METHODOLOGY - PART TWO

      Last month, we started looking at a methodology for fixing broken
datasets.  My friend Rick Fochtman, who has a lot of experience, has
three simple-sounding rules on this subject.  When confronted with a
dataset problem, Rick asks:  "What does it look like?"  "How bad is it?"
"What can we do?"  These questions penetrate far deeper than they appear
to, and we talked last time at some length about them.

      This month, we'll confront another real damage situation, and
we'll apply these methods toward fixing the problems.  First, I'd like
to say a few words about the arsenal of tools we'll need to use.  We
mentioned last time that there are both IBM and non-IBM utilities
that can help.  My practical philosophy is to use whatever works,
whatever you have, whatever you can get, or a combination thereof.
However, I feel strongly that you must understand the problem first.
You must also understand how your tools work, and what they do.  If
you've proceeded in this order, that is, if you've answered the first
two questions about what the problem looks like, and about how bad it
is, then you're well on the way to properly marshal whatever tools
you're likely to need in fixing it.  Today we are going to examine
another case to illustrate this method.

      At this point, I'd like to say more about tools, specifically
IBM ones versus non-IBM ones.  IBM supplies some good tools that we
all use to some degree.  For zapping disk datasets, VTOC entries
(FORMAT 1 DSCB's) and the like, there is superzap, whose program name
is AMASPZAP.  To use AMASPZAP, you can look in IBM's Service Aids
manual for almost any level of DFP or MVS.  This manual contains
an entire section on AMASPZAP.

      Our old familiar ISPF/PDF from IBM can also be a helpful tool in
certain ways, mostly to check the work you've done through other
means.  For example, ISPF/PDF 3.2  (dataset allocation, attribute
display, and catalog/uncataloging), and ISPF 3.4 (dataset listing with
attributes, etc.) can be used for displaying the DCB attributes of a
given dataset after you've altered them.

      But the few standard IBM tools have disadvantages.  ISPF/PDF can
be rather limited in its ability to change the things we need to
change.  On the other hand, AMASPZAP, which is IBM's tool for changing
disk data, is very general in its application rules, and therefore,
for changing things like VTOC fields and pds directory fields,
AMASPZAP is extremely user unfriendly.  You must know the exact data
representation, and the exact physical location of the field you want
to change.

      Non-IBM tools that are more user friendly, would be more
convenient to use for much of this work.  Many of these tools can be
obtained from the CBT MVS Utilities Tape, which you can get from
www.cbttape.org, at no cost.  I have mentioned several of these tools
in last month's column, and we'll show you, as we go along, how they
come into play.

      Let's give an example.  Suppose you have somehow copied a load
module with some large data blocks into a load library which has a DCB
blocksize that is smaller.  And suppose also, that you've managed to
delete all other remaining copies of this load module (quite a feat).
To rescue the situation, and to be able to view and use that load
module, you'll need to increase the DCB blocksize of the load library
without reallocating it.  In other words, you'll have to somehow ZAP
(change) the "blocksize" field in the VTOC entry for the load library,
so it's at least as big as the largest data block in the load module.

      Let's say for definiteness that the DCB blocksize of your load
library is 6144.  But the largest block in the load module you've
copied in, is 19069.  Let me ask you, is it less error-prone to use
IBM's IEHLIST LISTVTOC command in batch to get the CCHHR location of
the load library's FORMAT 1 DSCB (VTOC entry), and then zap its
blocksize field in hex with AMASPZAP, or is it safer to use a non-IBM
command like CDSCB (from File 300 on the CBT MVS Tape) and type:
"CDSCB load.library BLKSIZE(19069)" ?  Both methods have accomplished
the same purpose of making that load module usable, using the same
mechanics.  But from the user's point of view, one method is more
foolproof than the other.

      The old-time systems programmers (I guess I'm one of them) had
to put up with zapping VTOCs the hard way.  Now, with the free user
tools such as fullscreen ZAP (CBT Tape file 134) and CDSCB, the job
is much easier, quicker, and cleaner.


THE OVERLAID PDS DIRECTORY

      One dataset recovery case is that of the "blown" pds directory.
This could happen (only try it on a "junk pds", or don't try it at
all) when one tries to copy a sequential dataset into a pds without
mentioning the member name of the pds.  From an application
programmer's point of view, the whole pds gets ruined.  A pds consists
of a directory at the beginning, whose DCB attributes are LRECL(256)
KEYLEN(8).  The directory has entries which point to data locations
further along in the extents of the dataset, where the members reside.
The DCB attributes of the data in the members can, of course, vary.
You have, for most practical purposes, as much choice in DCB
attributes of pds members, as you have for sequential datasets
themselves.  These "data" DCB attributes reside in the VTOC entry
for the pds on the disk pack.

      When a sequential dataset is copied to a pds without mentioning
the member name, part or all of the pds directory is overlaid by the
copy of the sequential dataset, ruining "normal" access to the rest of
the data, which resides further along in the member locations.  At this
point, we've answered the question:  "What does it look like?"

      Now we ask:  "How bad is it?"  In our case, since we have an
idea what the data looks like, the question is:  How much of the pds
directory area, and how much of the member area afterward, did the
copy of the sequential dataset overlay?  This will determine how much
of the remaining non-overlaid data, we will later be able to recover.

      Now we can start the question:  "What can we do?"  The answer
will boil down to two parts:  "What can we do to determine the extent
of the damage", and then, "what can we do to recover the undamaged
data?"  To answer these questions, we have to start gathering tools.
Initially, we'll need tools to determine the extent of the damage.  An
IBM way, would be to use IEHLIST to determine the CCHHR disk locations
of the beginning of what used to be our pds.  Then we could use the
CCHHR options of AMASPZAP to print a hex dump of these beginning
locations.  The extent of the overlay should then be apparent, if
you've printed out enough CCHHRs.

      One non-IBM way to do the same thing, would be to use the REVIEW
TSO command from CBT Tape file 134.  REVIEW is a full screen TSO
browser of enormous power.  The normal way to browse a dataset with
REVIEW is to say (from an ISPF command line):  "TSO REVIEW
dataset.name" .  However, REVIEW has some specialized subcommands
which we may need.  In this case, we'll need to know the block size of
the data which got copied into the beginning of the pds, in order to
see that data.  Therefore the BLKSIZE sub-parameter of REVIEW can be
used to make the overlaying data visible.  Thus we type:  "TSO REVIEW
dataset.name BLKSIZE(32760)" or some other big-enough number that will
enable the data to be seen.  We go to the bottom of the data, using
the BOTTOM subcommand, and an ending TTR will be displayed.  Copy this
TTR down.

      The next step is to get past the overlaying data to the old
data.  REVIEW has the power to "fake" the top of the dataset with its
NEWTOP subcommand.  Simply step past the EOF mark, which occupes one
TTR location, and type NEWTOP(ttr) for the following TTR to get to the
location after this.  The TTR is usually a five or six-digit numeric.
The first non-overlaid data should now become visible.  My guess is
that you'll probably have to play around with this for a while, but
you might be pleasantly surprised when the data appears on your
screen.

      Using REVIEW in this way has helped us to see the extent of the
damage.  We have thus answered the question:  "How bad is it?"  ISPF
3.2 might give you the same information, less precisely.  But the
accuracy of ISPF 3.2 depends on how the overlaying data was copied.
If the "pds" was sequentially opened for output, and then closed,
then the DCB information in the VTOC entry was updated by the sequential
copy.  But if the VTOC was not updated, then the "easy" methods will
not work.  You'll have to use tools which look at the data itself, such
as the ones we have just mentioned.

      Now we ask the second sub-question of "What can we do?", namely,
"How do we fix the damage?"  There may not be only one type of "fix".
What particular action you want to take, must now be decided upon.
In our case, the answer will depend on the extent of the damage, the
importance of the data, and the availability of a possible backup
copy.

      On a production dataset, I would not suggest using our methods
except as a last alternative.  The most reasonable first thought,
would be to do a dataset restore from a backup copy.  This is what
most people do, in practice.  After that, the remaining problem would
be to update the restored copy of the dataset with the data that was
added or removed since the time the backup was taken.  Our methods
are a second-line and third-line defense, to be used in the event that
no reasonable backup copy is available.  However, we can also use our
techniques to alter a similar, but not identical dataset that was
restored, so it matches the dataset that was lost.

      In the case of an overlaid pds directory, the first part of the
solution might be to format a back-leveled or a blank directory of
proper size.  Then, new directory entries have to be made, to point
properly to the lost members which have not physically been overlaid.

      Again, tools must be chosen.  One tried-and-true method is to
take an FDR or DFDSS backup (or equivalent) of some similar pds, and
restore just the directory tracks over the location of the lost pds
directory.  Then you have a model pds directory to work with, which
can later be added to or altered.  You can "clear out" a directory
to make it appear empty, by zapping eight bytes of hex 'FF' in the
first eight bytes of the directory data (the key).  After that, we
must consider how to re-create accurate directory data for the
"members" that are still physically there.  In my opinion, it is
not easy to directly "zap in" directory members to a blank pds
directory because of the internal structures involved.  You rather
need a specialized tool for STOWing member entries into the directory.

      The best public tool I know of, is the "PDS" TSO command from
File 182 of the CBT Tape.  Normally, "PDS" requires a small
installation effort, with an ISPF panel library and an ISPF message
library.  However, a load module for the PDS command exists on file
035 of the CBT Tape, and if you invoke "PDS" not in ISPF mode (called
ISPMODE), you won't need the panels and you can use it right away.
Just suffix the word XISPMODE to the initial invoking command.

      You point the PDS command to a dataset when you invoke it
initially.  Then, once you have the "ENTER OPTION" prompt, you can
enter subcommands.  The RESTORE subcommand of PDS is the one we'll
use now.  To restore all deleted members at once, you pick a prefix
for the restored members.  For example, you may pick the prefix "$$"
to place the restored members at the beginning of a directory list.
Then you enter the subcommand:  "RESTORE $$ REPEAT NOPROMPT".  The
PDS command does the rest.  In TTR order, pds directory entries for
members called $$000001, $$000002, and so forth, will be created.
These members may be renamed by more conventional means later.

      Another tool for creating pds members is the PDSGAS batch
program from CBT Tape file 316.  PDSGAS is fine for FB or VB pds
members, but it will not do a good job on restoring load module
directory members.  The FIXPDS program from File 036 of the CBT Tape
runs under ISPF, and allows you to ISPF browse all physical (deleted
or not deleted) pds members backwards from the dataset high-water
mark, giving you the option of STOWing new member names for each one
after you browse it.  If you look around the CBT Tape documentation,
you will doubtless find other good programs that can do a similar
job.

      We've probably answered 70 to 100 percent of the question:
"What can we do?", depending on the case.  However, if the overlaid
pds was a load library, there is more work to be done, because load
module attributes are found in pds directory user fields, and they may
not be restored adequately from many of the "member creating"
programs.  The "PDS" TSO command comes to the rescue with its "ATTRIB"
subcommand.  ATTRIB can be used on a pds member or a group of members
to change most of the load module attributes to the way you want them.
We don't have space to discuss the details here.  Look in the PDSHELP
member on CBT Tape File 182, under the ATTRIB subcommand, for the
details and possibilities.

      To summarize, our aim this month was not to write an exhaustive
treatise on dataset restoration.  Rather, it has been to illustrate a
method of approach that can really be used on a wide variety of
dataset problems.  The questions:  "What does it look like?", "how bad
is it?", and "what can we do?" will support us well, when tackling
dataset problems throughout our careers.  Good luck.  See you next
month.