MVS TOOLS AND TRICKS OF THE TRADE April 1990 Sam Golob MVS Systems Programmer sbgolob@cbttape.org THE PDS PROGRAM PRODUCT, PART 1 This month, I'd like to begin a mini-series to feature a deserving product that is found on the CBT Mods Tape. Anyone who has extensively used this product will immediately understand why we should devote some major attention to it. I'm definitely not repeating myself in talking about this product more than I have already. Using this package will earn you some enormous savings of time and effort! I have been asked (even by my boss) how it is possible for me to do all of my company work, and still have time to write articles and do many "side projects" in the systems programming field. My reply is invariably that I use many tools to shorten the work. The time invested in installing and learning the tools, is quickly made back from the shortcuts made possible by using them. My second reply, is that "I use PDS". I have written quite a lot about "PDS" (the PDS Program Product). Those of you who are immersed with using PDS, will readily agree that I have not come near to saying enough about its enormous power to help a systems programmer. To answer the skeptics, let me just tell you how my own involvement with this marvelous product grew. A good friend was kind enough to give me my first CBT tape "n" years ago. After looking at a printout of File 1 (the documentation), which describes its enormous number and variety of free offerings, I felt like a kid in a toy store who could take home any toy he wanted for nothing. For close to half a year, I collected and tried tools by the dozens, expanding my powers and enjoying every minute of it. I remember installing eight programs one day, six the next, another four or five afterward, and so on for a good while. Then my friend took me aside. He told me to look inward instead of outward. "Look inside PDS alone for a while. You'll see almost all of what you need in there, usually done even better than with the 'individual' tools." Having been awakened to notice the PDS product, I surprised even myself by being absorbed for the next half year in exploring the tools that were embedded in it alone. This is a true story. Hear me out, and see some of the things that PDS can do, easily and with small effort, for you. GETTING THE TOOL (if you don't already have it). First you have to GET PDS. It is found (version 8.3) on File 182 of a recent CBT tape, with necessary auxiliary programs on Files 296 and 112 of that tape. The install is the assembly-link of a load module, and the copying of ISPF panels and a message member into the appropriate libraries for your ISPF session to use. Assembly and linkedit of the auxiliary load modules from files 296 and 112 completes the installation. Options for tailoring the main load module can be adjusted using conditional assembly globals that are located in members #PDSGEN and #PDSGENB of file 182. That's it. PDS is executed as a TSO command, or as a dialog manager option under ISPF. If ISPF is present in the TSO session, the two modes may be toggled back and forth. PDS may also be executed recursively under ISPF if a command table entry is set up to invoke it (see my May 1989 column). PDS comes with loads of documentation and a TSO help member for all its subcommands. PDS is free for all to use. For your extra information, a vendor-supported outgrowth of PDS with additional capability (called PDS/E) has been released by Serena Consulting of Burlingame, California and is being supported by the principal authors of the free PDS product. PDS/E, although currently a released product, is being intensively enhanced further by its developers, and I can assure you that its maintenance agreement will be well worth the money. However, the public product's great capabilities even without the vendor enhancements are extremely beneficial to its users, and so, we will concentrate on the public PDS product in this column. People in installations that "do not like public software" may inquire from Serena about PDS/E. Also, you may want some of the extra capability of PDS/E later on, once you have a good idea of what the "free" PDS can do. But "public PDS" offers enough to swamp a user's curiosities for a good while, as it did to my own. ONCE YOU'VE GOT IT, WHAT CAN YOU DO ? What are some sticky everyday system programming situations that can be easily solved with PDS? We will consider one particular problem for this month's instalment. The problem is: How can you keep track of vendor load modules in a big program product library, where lots of modules from many different packages have been mixed together? There is a familiar difficulty that occurs when you have reinstalled later releases of some of the products. How do you make sure all of the modules in the library are from the new release and that you've deleted the modules from the older releases? How can you ensure the "purity" of each product whose modules are in that library? This is really not a hard problem to solve, when PDS is available. (It is as close as the nearest NEW CBT tape.) One need only implement a few product installation standards made practical by certain of the PDS capabilities. The solution boils down to MARKING the load modules, to show them as belonging to a certain product and a certain release at install time. Then, to isolate all the modules from one product, once they've been mixed together with the others, you merely have to pick these modules out by use of the "markings" you've given them. The modules from an older release of one product will then be shown as belonging to that product, but to a previous release of it. Modules from a completely different product will have completely different markings, so they will be readily distinguishable from all modules belonging to the other products. How does PDS make it possible to implement this scheme? PDS has the capability of SUPPLYING SUCH MARKINGS. It can also POSITIVELY SELECT ONLY THOSE MODULES having certain given markings or partial markings. Thus, it can choose with complete certainty, all modules belonging to a given product, or to a known release of that given product, provided that the modules have been marked. It will exclude all other modules in the library from the selection. In this way, we have achieved positive recognition of all modules belonging to a given product and a given version of that product. HOW DO YOU USE PDS TO MARK LOAD MODULES ? So what are the markings? And how does PDS supply them and use them for group selection? For a load module, the user-supplied "marking" is the "SSI" or "System Status Indicator". The SSI is a four-byte hex number (eight hex digits) that can be placed in a module's load library directory entry by the linkage editor. During linkedit, the SSI is supplied using the control statement, SETSSI, followed by the eight hexadecimal digits which will constitute that module's SSI. PDS can change any module's SSI "on the fly" without another linkedit, or it can supply a new SSI where none existed before. PDS can not only do this for one load module at a time, but it can do it for any preselected group of modules in a library or for all members of the library, all at once. PDS can also look at any load library and select only those modules having a given SSI, partial SSI, or consecutive string pattern in an SSI to be in its current member subgroup. Membership in PDS's current member subgroup means that subsequent PDS operations can be performed on ALL MEMBERS IN THE ENTIRE SUBGROUP AT ONCE. PDS can then delete or copy out to another library, all the modules belonging to one subgroup of members. We see that we can isolate and/or operate on one product's modules from within a large library through using PDS. Which PDS commands can change a module's SSI, and what commands will select all modules in a library having a certain given SSI? To supply an SSI to a load module, or to change an existing SSI, we use the ATTRIB subcommand of PDS. If we wish to mark all modules in an install library with the same SSI, the commands would be: PDS install.library.name Assuming PDS is the PDS load module's name, this command points PDS to the desired library. ATTRIB : SSI(hhhhhhhh) where the colon in the member name field signifies "all members" and hhhhhhhh is the eight-digit SSI hex number that we want to assign to all the modules. If we've already selected a subset of members to be included in PDS's "current member subgroup", we can supply the SSI to all of these members at once, by substituting an asterisk "*" for the colon. An asterisk in the member name field of a PDS subcommand always denotes "all members belonging to the currently selected member subgroup". At install time for a product, we can easily supply a telltale SSI to all its modules by using the ATTRIB subcommand of PDS. Then when we copy the modules into the program product library for public use, they will already have been distinctly and properly marked. How can we use PDS to select a member subgroup consisting of only those modules having a certain given SSI? We can do so, using the "IF" subcommand of PDS. The actual command would be: IF : SSI(hhhhhhhh) THEN(SUBLIST) "SUBLIST" is a PDS command that creates the "current member subgroup" as a list of member names. Thus, the result of the subcommand is, that the new "current member subgroup" defined by PDS, now consists of a list of only of those members having the SSI equal to "hhhhhhhh". The currently selected subgroup can now be referred to by putting the asterisk "*" in place of the member name field in any PDS subcommand executed subsequently. Thus, COPY * 'ANOTHER.LIBRARY' will copy all of the selected members over to 'ANOTHER.LIBRARY'. DELETE * will delete all the members of the subgroup from the current library. And so forth using other PDS commands. In our installation, we use the following SSI naming convention to mark vendor load modules. The first four hex digits will denote the product identifier (made to be consistent by arbitrary convention). The last four digits will be a designation of the release and modification levels. Therefore modules from CA-11 Release 1.4 newsletter 2 will be marked with an SSI of CA111402. To pick out ALL CA-11 modules in a given library, we need only ask for: IF : SSI(CA11) THEN(SUBLIST) and we will get ALL modules of ALL releases of CA-11 that we have previously marked and installed. This is because any SSI that we assign to a CA-11 load module always begins with the four hex digits: CA11. To obtain CA-11 modules belonging only to release 1.4, we will instruct PDS as follows: IF : SSI(CA1114) THEN(SUBLIST) This command will pick all of the CA-11 release 1.4 modules, regardless of "newsletter" modification level. Finally, to pick the CA-11 release 1.4 modules that have been upgraded by the Newsletter 2 modification level, we merely ask PDS: IF : SSI(CA111402) THEN(SUBLIST) and all modules affected by the Newsletter 2 upgrades, will be selected for membership in the current member subgroup. This whole scheme is neat and simple. Enter SYS1.VENDOR for Forensics. In addition to marking all of our program product modules to be selectable by partial SSI, we maintain another card-image type library that we call SYS1.VENDOR. In SYS1.VENDOR, we keep some "fingerprints" of each module that was installed with a new release of a product. These "fingerprints" are generated by some other facilities in PDS, and they can readily be compared with similar fingerprints generated from the currently running modules that are in the system. Having the fingerprints available from install time will often enable us to determine if a module has been changed since then. What kind of fingerprints do we take? Actually, PDS gives us a considerable choice. Our own choice was affected by the consideration that we did not want the records to be too bulky. In practice, we take four or five pictures of the modules in our shop. We take a short ATTRIB listing, a long MEMLIST listing, a MEMBERS listing, and a linkedit HISTORY listing. If there are not too many modules, we may also keep CSECT MAPS of them, obtainable with the PDS "MAP" command. With these listings on record, it is possible in most cases to positively identify the particular level of any vendor-supported load module that we have in one of our production libraries. I have supplied illustrations (Figures 1 thru 6) to show the kinds of "module fingerprints" that we keep. Seeing these should be most instructive in illustrating the power of our techniques. Please bear in mind that corresponding records can always be obtained by PDS from existing load libraries, so that we can graphically compare our archived snapshots with current ones obtained from modules we are now using. In conclusion, we have shown how a very small subset of PDS capabilities will support an important function that every data processing shop has to cope with--making sure that you're executing the correct version of your programs. Application groups can benefit from these techniques also, and can just as easily use them as we systems programmers can. I hope that next time, I can present another, equally useful shop technique that exploits the powerful PDS utility functions. If you (our readership) keep your enthusiasm, we can keep doing this from time to time, and add to the mini-series every couple of months. I have considered the idea (energy permitting) of producing a periodical PDS(/E) Newsletter containing techniques such as this. Given the versatility of PDS and PDS/E, such a newsletter can go on for years and years and years. Anyone who has ideas or suggestions about such a project and its benefits may call me directly or write to me about it. WHO YOU GONNA CALL ? The CBT MODS TAPE can be obtained from NaSPA at (414) 423-2420. This tape contains "public PDS" and many other fine products. SERENA Consulting distributes PDS/E and is located in Burlingame, California. They usually have an ad in this magazine that includes their phone number. My phone number is . Any PDS(/E) Newsletter ideas regarding distribution, contributions, or material are most welcome and appreciated. Good luck in all your endeavors. Hope to see you next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. "Fingerprint" Members for a Product Install in the SYS1.VENDOR Library. ------------------------- MEMLIST Source Member List 1 ----------- ROW 1 OF 5 COMMAND ===> SCROLL ===> CSR Enter an ISPF command, a PDS/E subcommand or a special control code: FUNCTION FEATURES CODES NAVIGATE DSNCMDS MEMCMDS DEFAULTS OTHER - DSN=SYS1.VENDOR,VOL=SER=MVSRES MEM=(CA11 ---------------------------------- CMD NAME DATA VER.MOD CREATED LAST MODIFIED SIZE INIT ID CA11 01.00 88/10/20 88/10/20 14:22 344 344 CA11-14 CA11A 01.00 88/10/20 88/10/20 14:22 120 120 CA11-14 CA11E 01.00 88/10/20 88/10/20 14:22 23 23 CA11-14 CA11H 01.00 88/10/20 88/10/20 14:22 375 375 CA11-14 CA11M 01.00 88/10/20 88/10/20 14:22 835 835 CA11-14 ****************************** BOTTOM OF DATA ******************************** * * * * * * * * * * * * * * * * * * * * * * * Figure 2. Output of "Long" PDS MEMLIST Listing for Load Modules. *** MEMLIST TABLE OUTPUT *** 2.06.28 PM THURSDAY OCT 20, 1988 - DSN=TST.CA11.LOADLIB,VOL=SER=VEND01 MEM=(CACTPROD CMD NAME DATA ALIASOF LEN/LKED -- ATTRIBUTES -- APF MODE MAIN MATCH LENGTH TTR ENTRY SSI CACTPROD 88/07/21 REUS 0015C0 001204 000000 CA111400 C11ICNQ0 88/07/14 AC=1 000D70 000128 000000 CA111400 C11ICUP0 88/07/14 AC=1 000EA8 000219 000000 CA111400 C11IDIS0 88/07/14 AC=1 000DC8 000205 000000 CA111400 * * * * * * * * * * * * * * * * * * * * * * * Figure 3. Output of "Short" PDS ATTRIB Listing for Load Modules. *** LOG TABLE OUTPUT *** 2.07.38 PM THURSDAY OCT 20, 1988 - DSN=TST.CA11.LOADLIB,VOL=SER=VEND01 MEM=(CACTPROD >at * short NAME ALIASOF CREATED SIZE SSI ATTRIBUTES CACTPROD 88/07/21 5568 CA111400 REUS C11ICNQ0 88/07/14 3440 CA111400 APF=1 C11ICUP0 88/07/14 3752 CA111400 APF=1 C11IDIS0 88/07/14 3528 CA111400 APF=1 C11IJNQ0 88/07/14 3552 CA111400 APF=1 C11IJUP0 88/07/14 4344 CA111400 APF=1 C11ILJO0 88/07/14 3400 CA111400 APF=1 C11ILRE0 88/07/14 3176 CA111400 APF=1 C11ILST0 88/07/14 3464 CA111400 APF=1 C11IONQ0 88/07/14 3176 CA111400 APF=1 C11IPRE0 88/07/14 4096 CA111400 APF=1 C11IPUL0 88/07/14 3352 CA111400 APF=1 C11IRST0 88/07/14 3624 CA111400 APF=1 C11IRUP0 88/07/14 3576 CA111400 APF=1 C11ISIM0 88/07/14 4096 CA111400 APF=1 C11ISTA0 88/07/14 3584 CA111400 APF=1 IEFACTRT 88/10/20 18424 CA111400 RENT, REUS L7CNTL 88/06/16 224 CA111400 REUS L7CNTL14 88/06/16 224 CA111400 REUS * * * * * * * * * * * * * * * * * * * * * * * Figure 4. Output of PDS "MEMBERS" Subcommand. *** LOG TABLE OUTPUT *** 2.09.29 PM THURSDAY OCT 20, 1988 - DSN=TST.CA11.LOADLIB,VOL=SER=VEND01 MEM=: >mem * MEMBERS ARE: CACTPROD, C11ICNQ0, C11ICUP0, C11IDIS0, C11IJNQ0, C11IJUP0, C11ILJO0, C11ILRE0, C11ILST0, C11IONQ0, C11IPRE0, C11IPUL0, C11IRST0, C11IRUP0, C11ISIM0, C11ISTA0, IEFACTRT, L7CNTL, L7CNTL14, L714CNTL, L714INIT, L714PTF, NW1ACTRT, UCCACTRT, UCCEFUJV, UCC11BLD, UCC11BNQ, UCC11CIE, UCC11CII, UCC11CRD, UCC11DAT, UCC11DYN, UCC11GRP, UCC11HEX, UCC11INT, UCC11JQM, UCC11MGR, UCC11MSG, UCC11MS0, UCC11MS2, UCC11MS3, UCC11MS6, UCC11MS8, UCC11OBD, UCC11OCD, UCC11OCF, UCC11OCI, UCC11OCP, UCC11OCR, UCC11OCU, UCC11ODC, UCC11ODS, UCC11OHL, UCC11OJB, UCC11OJD, UCC11OJF, UCC11OJI, UCC11OJK, UCC11OJS, UCC11OJU, UCC11OOI, UCC11OPI, UCC11OPL, UCC11OPR, UCC11OPT, UCC11ORR, UCC11ORU, UCC11OSM, UCC11OSP, UCC11OSR, UCC11OST, UCC11OTD, UCC11PDS, UCC11PJQ, UCC11PRE, UCC11PRT, UCC11PSU, UCC11RCP, UCC11REA, UCC11RES, UCC11RMS, UCC11R21, UCC11R22, UCC11R23, UCC11R24, UCC11R25, UCC11R26, UCC11R27, UCC11R28, UCC11R31, UCC11R41, UCC11R42, UCC11R43, UCC11R44, UCC11R81, UCC11SUP, UCC11SVC, UCC11TRT, UCC11TR1, UCC11TR2, UCC11TR3, UCC11T30, UCC11T45, UCC11UCS, UCC11UPD, UCC11UPF, UCC11UTI, UCC11VSM, UCC11WRK, U11JCC, U11JCR, U11RDSEX, U11SRUEX THIS GROUP CONTAINS 113 MEMBERS * * * * * * * * * * * * * * * * * * * * * * * Figure 5. Output of PDS Linkedit HISTORY Listing. *** LOG TABLE OUTPUT *** 2.10.44 PM THURSDAY OCT 20, 1988 - DSN=TST.CA11.LOADLIB,VOL=SER=VEND01 MEM=: >hi * ** HISTORY CACTPROD LAST LINK-EDITED ON 7/21/88 BY LKED 566528408 V71 M00 ** HISTORY C11ICNQ0 USER-SUPPLIED UPDATE HISTORY BY CSECT - ISPLINK 4/01/85 RSI50860044 LAST LINK-EDITED ON 7/14/88 BY LKED 566528408 V01 M00 ** HISTORY C11ICUP0 USER-SUPPLIED UPDATE HISTORY BY CSECT - ISPLINK 4/01/85 RSI50860044 LAST LINK-EDITED ON 7/14/88 BY LKED 566528408 V01 M00 ** HISTORY C11IDIS0 USER-SUPPLIED UPDATE HISTORY BY CSECT - ISPLINK 4/01/85 RSI50860044 LAST LINK-EDITED ON 7/14/88 BY LKED 566528408 V01 M00 ** HISTORY C11IJNQ0 USER-SUPPLIED UPDATE HISTORY BY CSECT - ISPLINK 4/01/85 RSI50860044 LAST LINK-EDITED ON 7/14/88 BY LKED 566528408 V01 M00 ** HISTORY C11IJUP0 USER-SUPPLIED UPDATE HISTORY BY CSECT - ISPLINK 4/01/85 RSI50860044 LAST LINK-EDITED ON 7/14/88 BY LKED 566528408 V01 M00 * * * * * * * * * * * * * * * * * * * * * * * Figure 6. Output of PDS "MAP" Subcommand. *** LOG TABLE OUTPUT *** 2.11.45 PM THURSDAY OCT 20, 1988 - DSN=TST.CA11.LOADLIB,VOL=SER=VEND01 MEM=: >map * ** MAP CACTPROD CACTPROD 000000 0015BA ENTRY POINT AT 000000 -- CACTPROD MODULE LENGTH 0015C0 -- 6K ** MAP C11ICNQ0 C11ICNQ0 000000 000C4F ISPLINK 000C50 000120 RMODE 24 AMODE ANY ISPLNK 000C68 ISPEXEC 000C6E ISPEX 000C74 ENTRY POINT AT 000000 -- C11ICNQ0 MODULE LENGTH 000D70 -- 4K ** MAP C11ICUP0 C11ICUP0 000000 000D87 ISPLINK 000D88 000120 RMODE 24 AMODE ANY ISPLNK 000DA0 ISPEXEC 000DA6 ISPEX 000DAC ENTRY POINT AT 000000 -- C11ICUP0 MODULE LENGTH 000EA8 -- 4K