MVS TOOLS AND TRICKS OF THE TRADE June 1995 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer working in New York City. A VTOC ADVENTURE - PART III I mentioned in a previous column that a colleague of mine had accidentally deleted a partitioned dataset on a new MVS res pack, and there was no reasonable backup. Much SMP had been done to that library since any previous backup had been made. All that work would have to be done over, and many other libraries would have been involved unnecessarily. Anyone who has had this experience knows, that starting again from a backup and doing the SMP over is not so easy. Ah, if somehow, we could "undelete" that dataset.... Well, folks, sometimes it can be done. And I can proudly say that at least once in my life, I did it. Here's how. A SUMMARY OF WHAT'S INVOLVED. Basically, to "undelete" a dataset on DASD, you have to re-create its Format 1 VTOC entry, provided that the dataset has three extents or fewer. If there are more than three extents, you'd also have to re-create a Format 3 VTOC entry, which gives the CCHHR's of the fourth through sixteenth extents. Remember from our two past columns, that the Volume Table of Contents or "VTOC" of a disk pack, is a dataset which is the pack's directory of datasets. "Physically" speaking, the VTOC is a keyed BDAM unblocked dataset having fixed length records, which can also be read sequentially. The overall record length is 140, of which the first 44 bytes constitute the key. There are currently eight different formats of VTOC records, picturesquely defined by IBM as "Format 0" thru "Format 7". Each VTOC record is alternatively called a DSCB or Data Set Control Block. Unlike most other control blocks, which reside in computer memory, the DSCB resides on disk. See Figure 1 for a summary of what each of the VTOC formats is for. Today we will concentrate on the Format 1 VTOC entry, which describes the basic properties of a dataset on a disk pack. My specific problem involved the deletion of a dataset having only one extent. Therefore, we now have the job of constructing one Format 1 DSCB for it. Figuring out what to do for this case, probably would be enough work for today. However, if you really wanted to get experienced, you could probably un-delete a dataset with more extents. After practicing, you could track down the other extents and even rebuild a Format 3, if you really had to. Actually, the extra extents aren't that much harder. Once the dataset's characteristics are defined for the first extent, finding new extents is just a matter of adding CCHHR disk locations, either to the Format 1 or to the Format 3. OUR GAME PLAN. How do we approach this task? Before doing anything else, we have to find where the old data was on the disk. Without doing that, it is fruitless to try and make a directory entry, because the entry has to have a place to point to. Next, when we're sure where the old data was, by CCHHR, it would be helpful to find another dataset which is somewhat similar, and to look at its Format 1 DSCB as a model. Especially the first time out, it helps to have a model to follow. Later, as we've done this more times, the field names and locations in the Format 1 DSCB will become more recognizable. Then, we will be able to fill them in more directly from specific knowledge of where they are and what their values should be. So with experience, we won't need a model any more. Next, we have to un-index the disk pack if it was indexed, and we have to locate a suitable Format 0 DSCB to start converting into a Format 1. After that, we'll start filling in the VTOC record fields for a Format 1 DSCB, one at a time. Once all the principal fields are filled in, we'll then adjust the DS1LSTAR or "high water mark" field, to correctly mark the true upper limit of the real data, within the extents where the dataset was defined. Finally, we have to fix the un-indexed VTOC to correctly know that the deleted space is no longer free. Last, we re-index the VTOC if it had been indexed before. If the old dataset was cataloged, we'll have to recatalog the new one too. Since the space in this column is limited, I'll have to assume a bit more knowledge from the reader than I usually do. In this way, we'll be able to shorten the explanations to fit into the space we have available. TOOLS. In order to do this work, we have to have tools. First, we need a program to produce a CCHHR dataset map of a disk pack, sorted by tracks. See Figure 2 for a picture of the type of output produced by IEHMAP, or by the many "MAPDISK" programs that are available. Then, we need a tool to find, display, and change individual VTOC records. If you want to stick strictly to IBM-supplied tools, you can use a combination of IEHLIST and AMASPZAP, but I highly prefer a public domain program called "Fullscreen ZAP" for this purpose. Fullscreen ZAP is much quicker. Finally, we'll need to check our work. ISPF 3.2 or the IBM TSO command called LISTD can be used to check the dataset attributes in the VTOC entry that we've built. The non-IBM tools we talk about, may all be obtained from a public domain software tape called the CBT MVS Utilities Tape, which can be ordered from the NaSPA office for a handling charge. Fullscreen ZAP is on File 134 of the CBT Tape, IEHMAP is on File 083, the PDS command is on File 182, and the REVIEW TSO command is also on File 134. Readers of our previous columns have some prior knowledge of all these tools. DOING THE WORK. In my specific case, I was helped by the fact that I knew the deleted dataset was 150 tracks in size, and that it was part of a new MVS res pack. Therefore, I ran IEHMAP against the pack, and looked for a gap of 150 free tracks. IEHMAP gave me a CCHHR range to look at, and I then used Fullscreen ZAP in FULLVOL mode to examine the deleted data. In my case, there were two gaps of 150 tracks, but Fullscreen ZAP showed that the data in the first gap was a PDS directory with the properly named members. See Figure 3. Thus, I was able to correctly figure out the CCHHR range where the deleted dataset had been. We have to supply a bit more detail about this. See Figure 2 to see the type of information that IEHMAP shows--specifically the CCHHR range of the 150-track free space. You clearly see the gap starting at CCHHR 0277.0000, going up to CCHHR 0280.000E. In order to look at this data with Fullscreen ZAP, we have to run ZAP authorized in FULLVOL mode. The TSO command to do this is: "ZAP 'FORMAT4.DSCB' VOL(volser) FULLVOL". This allows us to see all the data on the disk pack, from the beginning to the end. The initial command positions us at Track 0, Record 1. Then we enter the ABS subcommand, to see data at an absolute CCHHR location on disk. We enter: ABS0277000001 to look at the first record after the beginning of the extent. This shows a PDS directory with the names we expect. See Figure 3. Now that we know the place where the data is, we have to go about constructing the Format 1 VTOC record from a Format 0 record. First, we un-index the disk pack if it was indexed. This is done with an ICKDSF job that includes among its control statements: "BUILDIX DDNAME(ptstovol) OSVTOC". Next, we have to find a Format 0 record to work with. We do that by getting into Fullscreen ZAP with the command: TSO ZAP 'FORMAT4.DSCB' VOL(volser). This will get us to the Format 4 DSCB (the VTOC header). We can step forward record by record with repeated "R" commands until we find a record with all hex zeros. If that is too tedious, we can enter the subcommand LASTDS1 to find the last Format 1 DSCB in the VTOC, and then we can bop forward a few records with "R" commands, until we find a Format 0 record at the end. Anyway, Fullscreen ZAP has its own internal help screens, which you can enter with a "?" command and exit with a "U" command. Once we're at the Format 0 record that we want to work with, it would help if we had a printout of a model Format 1 from another pack. In our case, since we have multiple res packs with other copies of this dataset, we could enter Fullscreen ZAP on the other pack's VTOC, and print screen or "DUMPF" the Format 1 DSCB for the corresponding dataset on the other pack. Then we could take that printout and start constructing our own Format 1, replacing four or eight bytes at a time on the former Format 0. Of course, our Format 1 will differ from the other dataset's Format 1. To get the dsect layout of a Format 1 DSCB, assemble the macro IECSDSL1 from SYS1.MODGEN or AMODGEN, using the operand "1". In other words, you would assemble the macro instruction: "IECSDSL1 1". Then you will have a road map of the Format 1 DSCB, to see where you are. Fields that are likely to differ are: the Dataset Name (perhaps), the Create Date, the Date Last Referenced, the DS1LSTAR (high water mark), the Extent Lower Limit, the Extent Upper Limit, and perhaps other extent information. The rest of the Format 1 will probably be similar. When you have filled in the entire Format 1 DSCB, remember to test the supposed attributes of the dataset by using ISPF 3.2 or ISPF 3.4. You might have to play around a little. To set DS1LSTAR, use the TSO REVIEW command on the pds (with the VOL keyword, since the dataset is still uncataloged), and sort the directory by TTR. This will give a good indicator of where you should start setting DS1LSTAR, by going a bit past the highest TTR in the directory. Make sure you recover all of the data in the last member. After you've finished, you should have something that looks like Figure 4. Use ISPF 3.2 over and over again until you know that the dataset is good, and all the old members are available for use. You must now reclaim the free space. Using Fullscreen ZAP, go to the Format 4 DSCB (enter "P" to go to the beginning of the VTOC). Then turn on the DIRF bit (X'04' at +E past +2C from the beginning of the record). Then go into ISPF 3.2 and try to allocate a new dataset on the pack. The console will show a message that the VTOC Convert routine has been entered for reason, DIRF. This will fix up the free space for the pack. If the pack has to be indexed, run ICKDSF with statement: "BUILDIX DDNAME(ptstovol) IXVTOC". The dataset should now be usable. If you're a born system programmer, this should be the utmost fun, when you see that you've gotten the dataset back. In any case, you've at least helped your shop, and you've learned quite a bit in the process. Good luck. See you next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. A Quick Summary of the VTOC formats. FORMAT 0 DSCB - Blank entry (all hex zeros) FORMAT 1 DSCB - Dataset descriptor FORMAT 2 DSCB - ISAM dataset information FORMAT 3 DSCB - Location of extra extents FORMAT 4 DSCB - VTOC Header Record FORMAT 5 DSCB - Chained Free Space Descriptors (if VTOC index is disabled or is not there) FORMAT 6 DSCB - Cylinder sharing FORMAT 7 DSCB - Free Space Descriptors for 3390 model 9 (or future large-capacity disk packs) Every VTOC begins with a Format 4 DSCB. It is always followed by one Format 5 DSCB. This Format 5 DSCB will begin a chain of other Format 5's to describe the free space on the volume if there is no VTOC Index, or if the VTOC Index is disabled. * * * * * * * * * * * * * * * * * * * * * * * Figure 2. Illustration of IEHMAP track map output, showing the 150-track gap where our deleted dataset had been. The name of the deleted dataset was SYS1.AOC.SAOFNCLS. - - - - more data - - - - - 0263.0000 0264.000E 30 1 NFTP210.SDVGMAC0 0265.0000 0265.000E 15 1 NFTP210.SDVGMOD2 0266.0000 0266.000E 15 1 NFTP210.SDVGMSG0 0267.0000 0272.000E 180 1 NFTP210.SDVGPNL0 0273.0000 0273.000E 15 1 NFTP210.SDVGSAC0 0274.0000 0275.000E 30 1 NFTP210.SDVGSAM0 0276.0000 0276.000E 15 1 NFTP210.SDVGSAR0 0277.0000 0280.000E 150 **********AVAILABLE********** 0281.0000 0286.000E 90 1 SYS1.AOC.SAOFNPNL 0287.0000 0287.000E 15 1 SYS1.HLASMBLR.SASMMAC1 0288.0000 0288.000E 15 1 SYS1.HLASMBLR.SASMSAM1 0289.0000 028B.000E 45 1 PLI.V2R3M0.PLIBASE 028C.0000 028C.000E 15 1 PLI.V2R3M0.PLICMD 028D.0000 0292.000E 90 1 PLI.V2R3M0.PLICOMP 0293.0000 0293.000E 15 1 PLI.V2R3M0.PLIHELP - - - - more data - - - - - * * * * * * * * * * * * * * * * * * * * * * * Figure 3. This is the beginning of the raw data at the absolute CCHHR disk location where we think we deleted a PDS. You will notice that the format of the data is that of a PDS directory, and the member names look like they would come from an AOC CLIST library, which is what we want to restore. Z A P _ ENTER VALID COMMAND ABOVE OR ? FOR HELP VERSION=2.3G 17AUG92 00000 >C1D6 C6C5 C9C3 C7E5 00F8 C1D6 C6C5 C1C3 *AOFEIGCV.8AOFEAC* 00010 C1C6 0002 0C00 C1D6 C6C5 C1C9 D5E3 007B *AF....AOFEAINT.#* 00020 030F 0104 0015 0094 186F 0094 320F 1126 *.......m.?.m....* 00030 012D 012D 0000 C9E2 D7C6 C9C4 4040 4040 *......ISPFID * 00040 C1D6 C6C5 C1C9 E2D4 0003 0500 C1D6 C6C5 *AOFEAISM....AOFE* 00050 C1D5 E3D3 0004 0200 C1D6 C6C5 C1E2 C1C6 *ANTL....AOFEASAF* 00060 0004 0400 C1D6 C6C5 C1E2 D3C1 0004 0700 *....AOFEASLA....* 00070 C1D6 C6C5 C1E2 D3C7 0005 0100 C1D6 C6C5 *AOFEASLG....AOFE* 00080 C1E2 E5C1 0005 0300 C1D6 C6C5 C3C1 E2C6 *ASVA....AOFECASF* 00090 0005 0500 C1D6 C6C5 C3C6 C7C1 0005 0700 *....AOFECFGA....* 000A0 C1D6 C6C5 C3C6 C7C2 0005 0900 C1D6 C6C5 *AOFECFGB....AOFE* 000B0 C3C6 C7C3 0006 0100 C1D6 C6C5 C3C6 C7C4 *CFGC....AOFECFGD* 000C0 0007 0300 C1D6 C6C5 C3C6 C7F1 0007 0500 *....AOFECFG1....* OFF: 0000 ( 0) ADDR: 00000 ( 0) DSN: VOLUME MRS003 LEN: 0108 ( 264) BASE: 00000 ( 0) CCHHR: 0277000001 TTR: 24F901 * * * * * * * * * * * * * * * * * * * * * * * Figure 4. This is a Format 1 DSCB as pictured by the Fullscreen ZAP program from the CBT MVS Utilities Tape, File 134. From here you can see some of the advantages of using this TSO command for viewing VTOC records. Everything can be seen very clearly. This is our finished VTOC record for the dataset SYS1.AOC.SAOFNCLS, which resides on pack MRS003. Z A P _ ENTER VALID COMMAND ABOVE OR ? FOR HELP VERSION=2.3G 17AUG92 00000 >E2E8 E2F1 4BC1 D6C3 4BE2 C1D6 C6D5 C3D3 *SYS1.AOC.SAOFNCL* 00010 E240 4040 4040 4040 4040 4040 4040 4040 *S * 00020 4040 4040 4040 4040 4040 4040 F1D4 D9E2 * 1MRS* 00030 F0F0 F300 015F 001A 0000 0001 0000 C9C2 *003...........IB* 00040 D4D6 E2E5 E2F2 4040 4040 405F 0063 0000 *MOSVS2 ‰....* 00050 0000 0200 9000 6D10 0050 0000 0082 C000 *......_..&...b{.* 00060 0000 007B 041A 2A00 0081 0002 7700 0002 *...#.....a......* 00070 8600 0E00 0000 0000 0000 0000 0000 0000 *................* 00080 0000 0000 0000 0000 0000 0000 *............ * OFF: 0000 ( 0) ADDR: 00000 ( 0) DSN: VTOC FOR MRS003 LEN: 008C ( 140) BASE: 00000 ( 0) CCHHR: 000000031F TTR: 00021F