MVS TOOLS AND TRICKS OF THE TRADE OCTOBER 2003 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. He also participates in library tours and book signings with his wife, author Courtney Taylor. Sam can be contacted at sbgolob@cbttape.org. Information about the CBT MVS Tapes can be found on the web, at http://www.cbttape.org. A PHILOSOPHY OF MVS UTILITY DESIGN - POWER VS SAFETY To tell you the truth, I don't like the word "philosophy". To me, the word conjures up images of non-practicality, of "thinking in the air". But the word also has another connotation, which boils down to the idea of approaching a subject from many directions, and coming to a consensus about what your general view is about that subject. It is this usage of the word that I like. And for the purposes of today's subject, I don't think there's a better word that describes what we're going to talk about. All of us, as MVS systems programmers, use program utilities. We can't manipulate objects in the MVS operating system without the tools that do the manipulations. It is patently obvious that computers are not the type of machinery that one can stick one's hand into, and turn a bolt with a wrench. Our "wrenches" are the utility programs. Without them, we would get nowhere. So all of us start manipulating MVS with the basic utility programs that IBM supplies to us. But the peculiar nature of MVS is that IBM will not, and cannot, complete the "utility creation job". IBM supplies you with many basic tools, and with the building blocks to add your own tools. Vendors spend their full time trying to fill the gap left by IBM, by creating utilities to sell us, but our own fellow systems programmers have also done their share in "filling the tool creation gap" themselves. Large collections of free tools, such as the CBT Utilities Tape collection, or the tools contributed to Xephon over the years, have contributed to our "good standard of living" when doing our jobs. Such extra "wrenches" and special-purpose utilities make it possible for most of us to bypass the built-in difficulties of living in a "pure-IBM" environment. In some areas of the MVS life, trying to make do with only IBM-written utilities, is like trying to wash clothes without a washing machine. You can do it, but it's tough. DESIGNING BETTER TOOLS Let me start telling you what I'm talking about. Take a look at IBM's AMASPZAP program, which allows you to change just about any byte on a disk pack. In my opinion, despite it's enormous generality, AMASPZAP is an extremely difficult tool to use for any job greater than zapping a few bytes somewhere. Also, if you zap the wrong byte, AMASPZAP might potentially cause enormous problems in your MVS system. There's not much of a built-in safeguard in AMASPZAP to tell you that you could be making a mistake and changing the wrong bytes. So we have already touched on two factors in utility design: capability--power, versus foolproofing--safeguarding against mistakes. Of course, the ideal utility should have unlimited power, and it should never let you make a mistake. In former times, I would have said that anyone who could design such a utility would make millions of dollars, but in today's economic climate, I'm not sure I'd say that. All kidding aside, I'd like to get down to business and show you how some users (your fellow sysprogs) have written more practical and helpful utilities than AMASPZAP. AMASPZAP is most frequently used for changing a few bytes in load modules, in zapping VTOC entries (DSCBs), and sometimes AMASPZAP is actually used to change arbitrary data bytes. Users have written far better tools to do these tasks, with far less risk of making mistakes. For example, the quintessential tool for zapping load modules and data bytes is the TSO-based Fullscreen ZAP program, which can be found on File 134 of the CBT MVS Utilities Tape collection (the load module is on File 135). Using Fullscreen ZAP, especially in authorized mode with the FULLVOL option that was implemented by Greg Price, you can also change any byte on a disk pack, but with the following helpful additions: First, you get to see what you're doing. Fullscreen ZAP, as a TSO command, displays up to 300 bytes on your screen, in hex and in EBCDIC, with the additional ability to disassemble the current assembler instruction when that's the data being pointed to. This helps you see what you're doing, and it makes the process of changing data far less prone to error. On the other hand, IBM's AMASPZAP will not let you look at what you're changing unless you know (in advance) exactly where you want to look. You cannot easily use AMASPZAP to fish for, and find, the data that you want to change. Additionally, Fullscreen ZAP contains a FIND command, that allows you to look forward in the data and find any string that is the likely candidate for a zap. AMASPZAP doesn't have a FIND capability, to my knowledge. Third, Fullscreen ZAP always displays the actual physical format of the data block currently being looked at. You can see that at the bottom of your screen. So you have an additional safeguard to know (or guess better) that you're changing the data in the right place. The next job that AMASPZAP is used for, is to change dataset characteristics by zapping (changing) bytes in the VTOC (Volume Table Of Contents) entry that describes the dataset on the disk pack. When you zap a VTOC entry with AMASPZAP, it's really easy to zap the wrong byte. Even using Fullscreen ZAP, where you see what you're doing and it's harder to make a mistake, you can still do unnecessary damage. But using another specialized tool called CDSCB (Change the DSCB), which is a TSO-based tool that can be found on File 300 or File 301 of the CBT Tape collection, making a mistake in zapping a VTOC entry for a dataset becomes much harder. That's because CDSCB has intuitively obvious parameters, such as CDSCB your.dataset BLKSIZE(32720) LRECL(80) RECFM(FB), and what isn't obvious can be explained by looking at the CDSCB HELP member (which of course, you have to install yourself by copying it from File 300 to your SYSHELP dataset). You can use the CDSCB program to change almost any dataset characteristic that's described by a Format 1 DSCB (VTOC entry). And it'll be foolproof, unless you make a mistake typing in the parameters. An additional advantage of using CDSCB is that you can change hundreds of datasets at a time with it, by executing CDSCB under TSO in Batch. Just make sure you have the RACF permissions (if you use Mike Cleary's version from File 301) or that you execute CDSCB as an authorized TSO command from an authorized load library. (See Files 185 and 186 of the CBT Tape collection for additional help with that.) Now I'll show you when this technique comes in handy. Everyone knows that IBM's allocations, especially the secondary allocations for SMP/E-controlled datasets, leave much to be desired. They are usually way too small. And this results in the failure of mass APPLY jobs, and especially mass ACCEPT jobs. You can safeguard against many such failures before attempting a mass ACCEPT job. Just make a list of all your DLIB datasets, and run a TSO-in-batch job to execute CDSCB against all of them that have small secondary allocations. For example, you'd list all your DLIB datasets and execute: CDSCB your.dataset SPACE(30) ALLOC(TR) against each of them. This operation would make the secondary space allocation for each dataset, 30 tracks. If some of the DLIB datasets are larger and need bigger secondary allocations, you can specify those allocations differently for those datasets, in your batch job. Then, in one fell swoop, all the DLIB datasets can be given adequate secondary allocations, and the mass ACCEPT job won't fill them up. Just try and think about how long that same operation would take using AMASPZAP. It would be supremely impractical. So you see that the raw power of AMASPZAP isn't the be-all and end-all. To do practical jobs, you need better tools that are easier to use and less error-prone. In other words, you also want a tool that will help guide you to do the correct thing, while you are using it. As an aside, I'd recommend using the free PDS 8.5 utility program from File 182 of the CBT Tape, to add more directory blocks to all your DLIB datasets, as well. Just run a TSO-in-Batch job executing the PDS utility (which doesn't have to be authorized) as follows: PDS your.dataset FIXPDS EXPANDDIR(20) and do that for all the DLIB datasets that you have, before you run the mass ACCEPT job. This operation adds 20 more directory blocks to each DLIB dataset. Then, it'll be far less likely that the pds directories for all your DLIBs will fill up. DESIGNING "FOOLPROOF" VERSUS "POWER" I recently had to make a "design decision" when I improved an existing tape copying tool called COPYFILE. COPYFILE can be found on Files 229 and 316 of the CBT Tape collection. I'll show you why my improvement uncovered a potential problem, and how I needed to make a non-trivial design decision to get around it. The COPYFILE program can copy selected files from one Standard Labeled tape to another. For example, you can copy files 7, 8, and 22 from volume TAPE01 to files 5, 6, and 7 of volume TAPE02 using the COPYFILE batch program. The COPYFILE control cards to accomplish this are the following: 7/5 8 22 This means that you copy file 7 from the input tape to file 5 of the output tape, and then file 8 from the input tape to the next output file, and finally file 22 to the next output file. But before I made my improvement, you couldn't go backwards. In other words, you couldn't code: 7/5 2 22 which would copy file 7 to file 5 as before, and then copy file 2 to file 6 of the output tape. The original coding of the COPYFILE program would only allow you to go forward on a tape, not backward. I introduced an improvement to COPYFILE, to be able to go backward, for either the input tape, or the output tape. It was easy to code the change, which was the same for either the input tape or the output tape. But the "change in design architecture" introduced by the ability to go backward, introduced a potential safely problem that had to be accounted for. Going backward made it possible, potentially, to write over the same file number on the output tape twice. In other words, if I coded: 7/5 8 22 4/7 I would first be writing file 7 on the output tape using file 22 from the input tape, but then afterward, I would write over file 7 a second time, using file 4 of the input tape. The resulting output tape would have file 7 written from input tape file 4, not from input tape file 22. Is this a mistake? In most practical situations, it usually would be. But my "architecture" or my "coding design" allows this situation to be permissible. So what should I do, to safeguard against an unintentional mistaken result, or a mususe? I had a heated discussion about it with several of my friends. First, I had to make a decision whom the utility was for. If it would be used by systems programmers, I could be more lenient with the power and less stringent with the safeguards. If it would be used by other types of users, I'd have to clamp down hard with the safeguards. My interim solution was to put out a loud warning message to the SYSPRINT file for the utility, if the double overwrite of an output file was about to occur. Then I would let it happen, but I would flag it with a return code of 4 instead of 0. This is obviously being very lenient with the safeguards. I figured that the system programmer would see the situation, decide if there was an error, and either let it go, because that was the desired result, or run the job over with corrected control cards. If the utility were to be designed for applications types, I'd definitely not let the second overwrite happen. I'd make the return code 8 or 12, and stop the tape copy then and there, making a clear announcement about what the "error" was. That's a decision about "power" versus "safeguards". The utility writer tries his best. But an ultimate decision probably has to come from the user feedback. SUMMARY Today I've written about "power" versus "safety" in utility design, because that's not a frequently discussed topic among system programmer types, but the issue definitely affects our jobs. I want to raise our awareness concerning this topic. Since sysprogs usually aren't in the business of writing utilities, but rather they are users, it is easy for vendors to brush the issue off, and say that this issue is not the sysprogs' business. But sysprogs are not ordinary "users", they are "powerful users". The system programmer is the "system doctor" who potentially has the power to change anything, in order to make the system run better. And he or she is supposed to have the knowledge that goes along with the responsibility. So sometimes, a systems programmer has to have a more powerful tool to do a job, rather than a safer one. And the systems programmer should have a say. That's my opinion. Best of luck to all of you. I hope to see you here again next month.