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.