MVS TOOLS AND TRICKS OF THE TRADE August 1996 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer PERSONAL TOOLS FOR YOUR SMP WORK One of my senior managers used to write a lot of code in the "good old days". He's been showing quite a bit of it to me lately. One of the programs he wrote was a "quick and dirty" COBOL program to read an SMPPTFIN file (PTF input to SMP/E) and produce a report which shows the products that the PTFs belong to, and what APARs they fix. This is very useful information that IBM does not always supply concisely. One normally needs to second-guess IBM and verify that they sent you the right maintenance. For my own use, I had been running some similar user code that I had borrowed and improved upon. This class of programs tells you what products you're getting PTFs for, even before SMP/E takes its own look. The processing is quick, and in many ways, it's a lot better than what IBM offers. Look at Figure 1 to see a sample output from this code. For a long time, I've been "helping SMP" with user-developed programs and techniques. Nowadays, SMP/E has a fairly robust, although by no means complete, collection of reports. But it used to be a lot worse. Especially with SMP4, but even now with SMP/E, I've found it very helpful to add some of my own programs and post-processing to SMP, and I've profited greatly by doing that. Today, we'll ramble on this subject together for a while. I hope we'll all gain a bit of knowledge and a few ideas. Hopefully, this will lead to implementing some kind of helpful SMP/E supplementation in your shop. Once that is in place, and you know how to use it, I know I'll get some quiet "thank you's" without having to hear them explicitly. HOW I GOT STARTED Back in the days of SMP4, before there was HOLDDATA, there had to be a way to exclude APPLYing PTFs that were in error. The answer was that you had to explicitly EXCLUDE them in the APPLY job. IBM would ship a list of PTFs in error together with the monthly PUT tape of maintenance, and you would copy this list into the APPLY job as an EXCLUDE list. Problem was that when one PTF was in error, it would hold other PTFs off also, if they depended on the PTF in error. It was difficult to obtain a clean APPLY because of all the induced errors. That release of SMP could not analyze an error further than one level. In other words, if PTF A was bad, and it was a prerequisite for PTF B which was good, and PTF B was a prerequisite for PTF C which was also good, you usually didn't want to APPLY any of them. However, the only PTF which was on the original exclude list was A, and the APPLY CHECK report would mention that B wouldn't go on. There was no mention of C at all. This was because C had B as a prerequisite, but there was no direct connection between C and A. C was two levels removed from A. In order to avoid APPLYing C, you had to add B to the exclude list of EXCLUDEd PTFs, and then run another APPLY CHECK. This second run would now show that C should also be excluded. Then you would add C to the exclude list, and run a third APPLY CHECK. You'd keep doing these iterations until the APPLY CHECK was clean, or was otherwise acceptable. In a mass APPLY of hundreds or thousands of PTFs, adding PTFs to the exclude list by hand was an extremely tedious chore. Typically during a maintenance cycle for APPLYing multiple monthly PUT tapes, you'd run an APPLY CHECK for an hour or two, and spend the entire next hour or two adding PTFs to the exclude list by hand. Then you'd wait still another hour or two for the next APPLY CHECK run to finish. The typical six or seven iterations needed for a mass APPLY, was easily a whole day's effort on your part, if not more than that. Enter my invention. I wrote a COBOL program to read the printout of an APPLY CHECK run and generate a list of possible further excluded PTFs. These consisted of all PTFs which got held off because of errors, plus the other PTFs which held them off. I generated the PTF id numbers by copying the "held off" PTFs plus the other PTFs which occurred in the report with an asterisk behind them. This list might contain duplicates, and APPLY processing doesn't tolerate duplicate excluded PTFs. So I SORT MERGEd my list into the original exclude list and deleted the duplicates with a program. This automated process took all of two minutes. Between APPLY CHECK runs, the rest of my day was free. Following this act, I wrote other programs to list all the ELEMENTs that appeared in an APPLY CHECK run or an ACCEPT run. This report would allow me to study which programs were affected by an APPLY, and to figure out which libraries were modified. I achieved far better control of my environment as a result of these tools I wrote. Then I wrote a program to turn a sequential SMPPTFIN file into a partitioned dataset, with each PTF as a separate member. This program can still be found on File 118 of the CBT MVS Utilities Tape (orderable throough NaSPA). CBT Tape Version 404 is also on the NaSPA CD-Rom. By separating each PTF in the (sometimes enormous) IBM tape file, I could better examine a piece of maintenance I was getting, if I needed to. I didn't have to ISPF browse a file that could possibly contain over a million lines. Although I don't like to write about vendor products, I have to mention at this point that the product PDSTOOLS (from Serena International, Burlingame, California) can be used to fit zaps to modules before the maintenance gets APPLYed. This pertains to TMS or TLMS hook fitting, etc. if the IBM modules that get hooked into, are very new. Sometimes the vendor didn't have a chance to fit the proper hook in yet. The vendor usually asks you to fax them an AMBLIST dump of the module at the new PTF level. I just use the SMP/E APPLY or APPLY CHECK report to find out which PTF modified the module, and run the PDSTOOLS object deck disassembler against that PTF. To do the same job without PDSTOOLS, you'd have to isolate the new object deck and linkedit it. Then you run a regular disassembler (For example, the ones on CBT Tape Files 217 or 171) against the one-CSECT load module, and report the needed locations to the vendor. This activity adds to the fun of applying system maintenance. I enjoy having this degree of precision when I need it. All of these tools aided me in controlling the maintenance of my system. In addition, I made my own processing to do FORFMID work (separating PTFs by which product or FMID they belonged to). That stuff still is valid today, because it reads the sequential PTF file directly and is independent of SMP/E. This material is on File 118 of the CBT Tape also. My boss Walter Shelley's program, mentioned at the start of this column, which does the same kind of thing, is being placed on File 262 of Version 407 of the CBT Tape, so you can see what he does, and how simple it is to do something similar yourself. I'll try and get my old SMP4 code placed on Version 407V of the new CBT Overflow Tape, which contains a lot of older code. You can also obtain the CBT Overflow Tape through NaSPA. My ancient SMP code used to appear on the CBT MVS Tape, in File 428, between Versions 250 and 316, so if you have an old CBT tape, you can see these software ideas for yourself. OTHER TOOLS AND IDEAS The SMP/E ISPF inquiry and administration facilities are very helpful in many ways, but they do not fully replace our old ways of doing things. For example, using the SMP/E ISPF inquiry, you can query on a single element or sysmod, but you cannot ask about two, three, or five of them at the same time. With the old way, you could. With SMP/E ISPF inquiry you cannot make small UCLIN adjustments to a MAC, a MOD, or a SYSMOD entry, whereas with the old way, you could. What was the old way? It was a CLIST which runs the SMP/E GIMSMP background program in the foreground. You simulate a batch SMP/E run in the foreground under native TSO, and enter the SMPCNTL commands at the terminal, receiving the replies one by one, at the terminal also. The first thing you do is to enter a SET BOUNDARY command and point to a ZONE. Then you can enter LIST commands to point to multiple elements, or UCLIN commands or RESETRC, and the like. When you have finished, you enter slash-asterisk /* in column 1, as you would in batch, and the CLIST then ends. You can find a sample copy of this CLIST on CBT Tape File 120, where my old columns are kept, and it was also printed in last month's column. Just search the File 120 PDS for the string SMPETSO. How do you look at the actual text of a PTF? You can take advantage of the fact that the SMPPTS dataset contains actual text of PTFs that have been RECEIVEd. So you can either ISPF BROWSE the members of this dataset, or simplify the "looking" process with a CLIST. I personally use the free REVIEW TSO command from File 134 of the CBT Tape for looking, which I find more convenient than ISPF Browse for many purposes. My two-line CLIST named "PTF" reads as follows: PROC 1 &PTFNUM is the first line. REVIEW 'smppts.dataset(&PTFNUM)' is the second line. To invoke, you just enter TSO %PTF ptfnumb on an ISPF command line, or PTF ptfnumb in READY mode. With these two CLISTs in place, your life in system maintenance will be a lot easier. Under ISPF, I assign a PFKEY to the command TSO. My personal preference is PF4, because I do not use the RETURN command much, preferring to use multiple END commands. Having done this for all my APPL ids, I don't always have to type the word "TSO" when I want to invoke a TSO command under ISPF. I just type the command or CLIST I want to invoke, and press the designated PFKEY. This saves a lot of mental effort during a day's work. It also helps when I run my SMP-type CLISTs that we just talked about. I can get into them more quickly. I hope that some of these ideas help you. If you consider your own work, you'll probably realize that you too, can profit by writing a few programs, CLISTs, edit macros, or REXX execs to process the SMP-generated data or SMPPTFIN files. The idea is to get your own mind working in that direction. Once you've done something useful for yourself, you can then acquire that very special feeling which only comes when you've shared your work with others and helped them too. You can do this by sending some of your things to a public software tape so others can benefit from your good ideas, and you can benefit from their feedback. Good luck. See you next month.