MVS TOOLS AND TRICKS OF THE TRADE February 1989 Sam Golob MVS Systems Programmer VARIOUS DATASET AND DASD MANAGEMENT TRICKS This monthly column is for sharing practical advice and techniques which you can employ in your shop. I hope that every reader will come away with something practical that can be immediately used. Most of the material in this column will take the form of short hints and tips. We shall try to mention as many of them as can possibly fit into the allotted space each month. Readers are welcome to share their own nice techniques, and can write to me care of the editor. The author's name will be included together with those contributions that are printed. We would like to help as many people and as many shops as possible. Therefore, most of the techniques mentioned in this forum can be carried out using the enormous literature of publicly available MVS tools. The vast "CBT Tape", which used to be available from Arnold Casinghino at the Connecticut Bank and Trust Company in East Hartford, Connecticut, and which is now available online at www.cbttape.org, is a treasure trove of hundreds of large and small tools. I believe it is the single best source of public MVS material in one place, and that no shop should be without having at least SOME tools from it. The CBT Tape web site is updated frequently; one should always check its UPDATES page. Much of my own system programming management technique depends on programs and other material from the CBT tape. The NaSPA VIP tapes have many helpful programs, which we shall draw from. The MVS SHARE tape from SPLA, the MVS JES2 and JES3 SHARE tapes, and the SHARE PL1 tape, are other good sources of time and labor savings. A list of public tapes for MVS was printed in the January issue of "Technical Support". This month's column, in keeping with the February theme of DASD management, will be devoted to five topics. These are: 1) Restoring deleted PDS members. 2) Extending the VTOC of a disk pack (while it is active). 3) Deletion and renaming of disk datasets that are enqueued upon. 4) Moving many datasets from one disk pack to another. 5) QUICKLY setting up tape backups of MANY partitioned and sequential disk datasets. Sound enticing? Read on. We'll deliver! Deleted PDS entries may be restored, with the proper knowledge and a few good tools. We're going to touch on the knowledge, and refer you to the tools. A PDS, or partitioned dataset, is MVS's version of a LIBRARY, or a subdirectory. It is basically a sequential dataset, but is divided into parts. The physical beginning of the PDS is called the DIRECTORY, which is in the form of 256-byte blocks. The directory has pointers to the location of MEMBERS, which are SEQUENTIAL FILES THAT PHYSICALLY BEGIN AFTER THE END OF THE FORMATTED DIRECTORY BLOCKS. The members are strung out one after the other in the dataset. The members are physically separated from each other (and from the directory) by EOF (end-of-file) markers on the disk. Our concern here is about what happens to a MEMBER when it is deleted or modified. Deleting a member just involves WIPING OUT ITS DIRECTORY ENTRY and rewriting the directory. THE DATA REMAINS IN PLACE ON THE DISK, but no directory entry points to it. Modifying a member (not in place) is done by rewriting the modified data after the end of the last member, and re-pointing the directory entry to the new location. Again, the original data stays in place on the disk, until the PDS is reorganized by being COMPRESSED. How should we restore a deleted PDS member in principle? A program which can MAKE A DIRECTORY ENTRY THAT POINTS TO THE OLD DATA, CAN EFFECTIVELY UN-DELETE THE MEMBER. There are three such programs that I'll mention. The simplest one is a batch program called "PDSGAS", which can be found on the CBT tape, file 316. One simply runs the program against the PDS, and it will find all physical member files that have no directory entries. New entries are made for them, which are given the names, $GAS0001, $GAS0002, etc. This treatment will suffice in most cases. At the very least, it will preserve the deleted data across subsequent dataset compresses. One can rename any of the restored members later. A better tool is the fantastic and versatile "PDS program product", an extremely valuable public domain tool, the likes of which can be found nowhere else. The "PDS program" is currently at version 8.6, and can be obtained from CBT tape file 182, with utilities on files 296 and 112. "PDS" (the program) has a RESTORE function that has much versatility in resurrecting deleted members. It can also reconstruct the more complicated directory entries associated with load modules. The PDS PROGRAM can "fix" directory entries with its ATTRIBUTE subcommand. In addition, you can learn a lot about PDS directory entries by using the DIRENTRY subcommand of the PDS PROGRAM. DIRENTRY will display (and explain) the directory fields of any member of any PDS. The third tool to UNDELETE PDS MEMBERS works under ISPF, and is called "FIXPDS". It was written by (the late) Bob Weinstein, and can be found on CBT tape file 36. It works on a different principle than the other programs. FIXPDS physically finds the LAST EOF MARKER in the extents of the dataset, and ISPF BROWSEs the LAST PHYSICAL MEMBER for your perusal. It then asks you if you want to make (or "STOW") a new directory entry for this member (even if it already has one). FIXPDS then GOES BACKWARDS and gives you the opportunity to stow a new directory entry for EVERY SINGLE PHYSICAL "MEMBER" that is there, all the way back to the beginning of the dataset. The next topic, EXTENDING THE VTOC (volume table of contents) of a disk volume, is of value because the normal procedure is hard to do, and is very disruptive to the users of the pack. I have a procedure (suggested by Jeff Broido of Broido Computer Consulting in New Jersey) which is quite easy to do, and which can be done while all the users are active. It is so non-disruptive that none of the users need be aware that it is being done at all! The exact procedure (down to the last detail) can be found on CBT tape file 29, and may soon be distributed with a NaSPA VIP tape. All ingredients necessary to do the work can be found on the CBT tape. The last step in the procedure is the most important (asking your boss for a raise after you've accomplished this miracle). The procedure depends on placing a file that is FORMATTED LIKE AN EMPTY VTOC just after the end of the existing VTOC. The existing VTOC also has to be converted to "nonindexed" format temporarily. (This is not hard.) The "FORMAT4.DSCB" (VTOC header record) is then fooled to think that the VTOC ends after the new file. The FORMAT1 (dataset) VTOC entry for the extra file is zeroed out, and the "DIRF BIT" in the VTOC header (reflecting the condition that the VTOC needs fixing) is zapped on. With this done, we then try to allocate a new file on the volume. The MVS operating system, seeing the DIRF bit on, enters the VTOC CONVERT ROUTINE that is built into MVS, which cleans everything up, and makes the extended VTOC usable. Nobody else realizes that this is going on. Wow! Our third topic is how to deal with datasets on disk, whose NAMES ARE ENQUEUED UPON by long-running jobs in the system. A typical example is if you have a scrap (say uncataloged) copy of SYS1.VTAMLIB on a disk pack, and VTAM is up. VTAM is likely to stay up all the time, and you definitely wouldn't want to bring down CICS and half the network, just to get rid of this junk dataset. What to do? This is a job for SUPRNAME !!!!! SUPRNAME comes straight from the Metropolis of Olympia, Washington. It is part of the magnificent collection of programs from the Washington State DP Service Center, File 270 of the CBT tape. SUPRNAME does the rename and delete of datasets by directly zapping the VTOC entries themselves without the programmer having to know where they are on the disk. Its control cards simply ask for the name of the dataset(s) to rename or delete, and the new name in the case of a rename. The action is done without actually accessing the datasets in question, and so it bypasses the enqueue mechanism completely. The junk copy of SYS1.VTAMLIB will soon be history. One small detail is left. If our VTOC happens to be indexed, this action will not be completely accurate, so the sample SUPRNAME JCL comes conveniently sandwiched between ICKDSF steps to "unindex" and "re-index" the VTOC if it is necessary. So, for systems programmers in distress anywhere from Metropolis to Smallville, SUPRNAME should come to the rescue. Topic number four is "moving many datasets from one disk pack to another". Normal vendor-supported vehicles for this service are DFDSS version 2 from IBM, and FDRDSF from Innovation Data Processing, among other products. These products are good, and I'm not going to disparage any of their considerable capabilities. There is at least one good free alternative (for non-VSAM) which is called COPYPACK from file 32 of the CBT tape, soon to make its way to a NaSPA VIP tape. COPYPACK does a bulk move of datasets from one disk pack to another, with optional dataset name filtering and recataloging of the datasets, if you so specify. It is also very good for moving MODEL DSCBs from one pack to another (without cataloging them). COPYPACK is not as fast as DFDSS version 2 (in speed), and does not delete the datasets from the "from" pack, but it offers different types of control that may make it more useful in many circumstances. It is also cheaper. Our final topic this month is a solution to a nagging bit of distress that even old (system programming) hands may not publicly admit to. This is the problem of doing IEBCOPY backup to tape, of large (or small) numbers of datasets. One usually has to code a proc and keep track of the file numbers (on the tape) of all the backed-up datasets. Type a wrong file number, and you abend in the middle of a long job. This is a pain for the experienced, and a terror for the novice. NO MORE. Just make a list of dataset names, and run a CLIST. The CLIST will generate all of the backup JCL, which will even do a TAPEMAP (CBT tape file 299) at the end of the backup. Where are these magic CLISTs? On CBT tape file 28, and soon on a VIP tape. There are quite a few of them. Some will generate JCL to INIT the tape first. Some will back up sequential datasets as well as partitioned datasets. Just code all the partitioned dataset names first, followed by a control card, and then list all the sequential dataset names. CLISTs are provided to do this processing for cataloged datasets, OR for datasets on a particular single volume. The general principle of the CLISTS is to read (&READDVAL) all the input dataset names into a single long string (&SYSDVAL) in 44-byte segments. Then, to generate the JCL, the segments are shoved back as output dataset names into pre-formatted pieces of JCL, one segment at a time. (This idea also came from Jeff Broido.) Good luck to you all, and please tune in again next month for more.