MVS TOOLS AND TRICKS OF THE TRADE July 1996 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer EYES - PART 3 - Using SMP/E Our previous two columns have dealt with the subject of "eyes". We use the term "eyes" to describe tools that give you a look at some aspect of what your system is doing. Our first installment was a general introduction to the subject of looking at your system from the system itself. Last month's column was concerned with the idea of how to start looking at the working innards of a previously unknown MVS system. Our emphasis in each case, was on the proper "eyes", or tools, which you can use in exploring each situation. This month's piece will be about how to discover the module content of your system's software, using as your "eyes", the SMP super-structure through which that system was originally built. SMP/E, today's form of IBM's System Maintenance Program for MVS, is an extraordinarily helpful kind of "eye" in the hand of a knowledgeable systems programmer. You can use SMP/E as an "eye" in many ways you never previously thought of, because SMP/E contains very detailed records about much of your operating system's software structure. Generally speaking, SMP/E's job is to load software into partitioned dataset libraries. To simplify this article, it will be assumed here, that the contents of all libraries loaded by SMP/E on your system correspond exactly with the SMP/E records. On sloppily maintained systems, it could be that a systems programmer has done linkedit, copying, or zapping operations to the system libraries outside of SMP/E, so that the actual libraries, and the "corresponding" SMP/E files, are not in sync. Fixing such a situation is beyond the scope of our discussion. We will assume a well-maintained system, and we'll try to "see what we can see", from the SMP/E records. Because of space considerations in this column, I have to assume that you have some previous knowledge of SMP/E. For an old, but very thorough treatment of the basis and purpose of SMP, you can refer to my series of two articles that were published in "Technical Support" back in 1988, and which may be found on File 014 of the CBT MVS Utilities Tape. The CBT MVS Tape is included on the NaSPA CD-Rom, or it can be ordered separately through NaSPA. At this point, I'll give a very brief overview of SMP/E, and we'll go on from there. SMP/E OVERVIEW. SMP/E was designed to be an automatic way of installing system software and software changes, while keeping a thorough accounting of what it has done. While SMP/E's predecessor, SMP, kept its records in partitioned dataset members, the newer SMP/E keeps the corresponding records in special VSAM files called ZONEs. Physically, these VSAM files are called CSI's or Consolidated Software Inventories. Every such VSAM file has to have a dataset name that ends in ".CSI". Logically however, each CSI might be broken up into one or more ZONEs, each of which represents a sort of domain of operation to SMP/E. Units of work in SMP/E are called SYSMODS. SYSMODs are named with names that have up to (usually exactly) seven characters. There are four kinds of SYSMOD. A FUNCTION sysmod represents an entire product installation. PTF sysmods (once called Program Temporary Fixes) represent permanent incremental changes to a product. APAR sysmods represent temporary incremental system changes, a kind of trial fix to circumvent a problem. Finally, USERMODS are a type of sysmod which was designed and packaged by an individual installation, not usually by a software manufacturer. USERMODS are usually employed to install your own shop's software customizations. What do you do with a SYSMOD? You usually run an SMP/E procedure in the background, using JCL. I'll assume that you are familiar with your installation's SMP/E procedure(s), and how to use them. Whenever I do SMP/E work, I always try and keep the "SMP/E Reference" (SC28-1107) and "SMP/E Messages" (SC28-1108) handy. These manuals contain all the information you'd ever need, somewhere within them. There are three basic processes called: RECEIVE, APPLY, and ACCEPT. RECEIVE processing brings a brand new sysmod into your SMP/E system. APPLY processing installs the software represented by the sysmod into a real operating environment, known as a TARGET system. ACCEPT processing, usually done after the product has been tested, makes the installation permanent, and installs the software components of the product into special libraries known as distribution libraries, or DLIBs. Records are kept for the software installation in logical VSAM files known as ZONEs. Each zone has up to a seven-character ZONE NAME. As we mentioned, one or more ZONEs are stored in the physical VSAM files called CSI's. How you physically arrange the zones in your CSI's is up to your design. Each separate SMP/E environment has one ZONE for RECEIVE processing. This ZONE is known as the GLOBAL zone. Records for APPLY processing are kept in one or more TARGET zones. Each TARGET zone contains the records of a separate operating environment for the software. Finally, the records for ACCEPT processing are kept in one or more zones called DLIB zones. TARGET and DLIB zones come in pairs, but it is possible to change these pair associations. For example, in our shop, which is a large service bureau, we have multiple TARGET zones, but only one DLIB zone. Whenever we have to do ACCEPT processing, we simply go into the SMP/E zone administration ISPF panels and associate the DLIB zone with the particular TARGET zone we want to ACCEPT from. In regular SMP/E batch processing, how do you tell SMP/E which zone you want to look at? You use the "SET BOUNDARY" or "SET BDY" command, pointing to the name of that zone, in parentheses. Individual pieces of software in SMP/E are known as ELEMENTs. Different kinds of elements have different designations. The original designations were SRC for source modules, MAC for macros (which included all 80-byte non-source modules before Release 1.5 of SMP/E), MOD for one or more load module CSECTs taken as a unit, and LMOD for load modules which are linked together from one or more MODs. After SMP/E Release 1.5, there were many other types of element designations defined, such as PNL for ISPF panels, DATA, for not-necessarily-80-byte data, and so forth. As we said, the job of a SYSMOD is to install and/or modify ELEMENTS in pds libraries. There is one more aspect of SMP/E that is not sufficiently well-understood by the public. That is the idea of JCLIN. JCLIN is a kind of skeleton JCL which is fed into SMP/E target and dlib zones. JCLIN tells SMP/E "how to build the house from the individual bricks". JCLIN loads all kinds of patterns into SMP/E. This is for the purpose of telling SMP/E how to build the load modules from the individual CSECTs, and what libraries to put individual elements and load modules into. An example of JCLIN would be some linkedit JCL to access some modules in DLIBs, with the SYSLMOD statement pointing to SYS1.LINKLIB. The linkedit control cards would tell SMP/E how to linkedit the load module, and the JCLIN SYSLMOD statement would indicate that the target library for the load module should be SYS1.LINKLIB, or rather, its ddname of LINKLIB. One final note. SMP/E is ddname oriented and not dsname oriented. In other words, you specify ddnames to SMP/E and not dataset names. How does SMP/E know, when you give it a ddname, what dataset to use? This is done by SMP/E objects called DDDEFs (or DD definitions) which are stored in each zone. Each DDDEF takes one ddname and specifies the dataset name associated to it, in that zone. The original installer's job is to initially specify a set of all the DDDEFs needed for a product, in each zone. Then the APPLY or ACCEPT processing for that product will "know" which datasets to deal with. SMP/E will dynamically allocate the proper datasets as they are needed. If you are looking at an installed system, all the DDDEFs needed are probably already there. Checking the DDDEFs will be part of using your "eyes". FOUR SMP/E INQUIRY METHODS - USING THE "EYES" OF SMP/E. In my repertoire, there are four basic types of inquiry to SMP/E: batch, PTF, CLIST, and ISPF. Batch inquiry is very powerful, and in my estimation, it is probably not used enough. Batch inquiry consists of running your SMP/E proc using the LIST command in the SMPCNTL DD statement. Output of the LIST command goes to the SMPLIST ddname. Detailed instructions on all aspects of the LIST command are contained in the SMP/E Reference manual, but you must play with it to see the format of the outputs. That's where you'll gain the most knowledge of its power. Utilizing the outputs of the LIST commands will provide you with a most powerful set of eyes into the structure of your system software. PTF inquiry is a bit of my own invention. But it is logical enough for you to find many methods of doing it. PTF inquiry is based on the fact that SMP/E keeps all RECEIVEd and not-yet-ACCEPTed sysmods in one partitioned dataset library, the SMPPTS library. If you do a LIST DDDEFS batch inquiry against your GLOBAL zone, you'll see where the SMPPTS library is. Then you can make a simple CLIST to conveniently browse the members of this library. My favorite browsing tool for this purpose is the versatile (and free) REVIEW TSO command, from File 134 of the CBT MVS Tape. REVIEW does not need ISPF, but it can use ISPF if it is available. My simple PTF inquiry CLIST, whose name is "PTF", consists of 2 statements: The first is: PROC 1 PTFNAM. The second is: REVIEW 'smppts.dsname(&PTFNAM)' . That's all. To invoke the full-screen inquiry of looking at a PTF, all you have to enter is "TSO PTF ptfname" from anywhere in ISPF, or "PTF ptfname" in TSO READY mode. The REVIEW command is versatile enough to give a lot of power to this CLIST. For example, suppose you want to look at a PTF called UW11111, and it isn't there. When you get REVIEW's "member not found" screen, you can enter the DIR subcommand of REVIEW, and you get a complete member list of the entire SMPPTS dataset, to search in. Space precludes a further discussion of PTF inquiry here, but I guarantee that if you play with it, you'll use it often. CLIST SMP/E inquiry is the same as what you did before SMP/E came along with its ISPF panels. An SMP/E CLIST simply invokes batch-mode SMP/E interactively under your TSO session. You enter all the batch-mode SMPCNTL commands on your TSO screen, and the replies from SMP/E appear below. To finish your session, you simply enter /* in column 1, just as you'd do for a batch job. For a sample CLIST, see Figure 1. This CLIST method looks outdated; why should we have it? First, you can inquire on several elements at once. For example, you can say: LIST MOD(IEFAB4A0 IEFAB4A2 IEFAB4B0) to look at 3 modules at once. Second, if you know what you're doing, you can do limited UCLIN updates, checking yourself with LIST commands whose results you see on the screen immediately. Third, it's a quick method, not requiring one panel after another. Try this one too. I think you'll like it after you practice. Finally, the fourth method is the ISPF panel method supplied with SMP/E. For single-element inquiries and cross-zone inquiries, the ISPF panels are wonderful. They are also very good when you have to do SMP/E administrative touch-ups, adding a DDDEF or something similar here and there. The use of the SMP/E ISPF panels is well documented by IBM, but because of the space, I can't talk further about them here. In summary, I hope this series of installments has opened your eyes to the idea of "looking at the system from the system". Although documentation helps also, this slogan is my systems programming watchword. The only data I really trust is the data I "see", and to see, I have to constantly depend on my "eyes". Good luck and good vision. See you next month. * * * * * * * * * * * * * * * * * * * * * * * FIGURE 1. THE SMP/E INQUIRY CLIST. WE'LL CALL THIS CLIST "SMPETSO". This CLIST invokes SMP/E in the foreground under TSO exactly the same way as it would run in the background in batch. Input of commands and output of results go to the terminal. Since there might be quite a few lines of output, it is preferred to run this CLIST in TSO "Session Manager mode", which can preserve and print up to several thousand lines of TSO output. To set up Session Manager mode, simply replace PGM=IKJEFT01 by PGM=ADFMDF03 in your TSO logon proc. PROC 0 VOLID CSI('SMPE.GLOBAL.CSI') UNIT(DISK) TYPE(SYS1) NOLOG - SYSOUT LOGDISP(MOD) NOPTS LIST() /** YES OR NO **/ SET VOLID = ZRS001 /* SMP-CONTROLLED PACK */ IF LIST = YES THEN CONTROL LIST ELSE IF LIST = NO THEN CONTROL NOLIST CONTROL PROMPT WRITE *********************************************************** WRITE * * WRITE * WELCOME TO THE SMP INQUIRY SYSTEM. THIS MEANS * WRITE * MAKE INQUIRIES ONLY ........ * WRITE * * WRITE *********************************************************** WRITE WRITE T Y P E = &TYPE WRITE WRITE FOREGROUND EXECUTION OF SMP/E WRITE WRITE SYSTEM DEFAULT ====> &TYPE WRITE WRITE TYPE = &TYPE MVS SP 5.2.2 DFSMS/ESA WRITENR ENTER DESIRED TYPE ====> READ ANS IF &LENGTH(&STR(&ANS)) ^= 0 THEN SET TYPE=&STR(&ANS) IF &TYPE = SYS1 THEN SET VOLID = ZRS001 /* TARGET PACK */ IF &TYPE = SYS1 THEN SET DIST = SMPDL1 /* DLIB PACK */ WRITE WRITE YOU HAVE SPECIFIED &TYPE AS THE SYSTEM. WRITE TARGET = &VOLID ---- DISTRIBUTION = &DIST WRITE ERROR GO TO ENDALL ATTN GO TO ENDALL ALLOC FI(SMPLIST) DA(*) ALLOC FI(SMPCNTL) DA(*) ALLOC FI(SMPRPT) DUMMY IF &NOLOG = NOLOG THEN ALLOC FILE(SMPLOG) DUMMY /* NO SMP LOG */ ELSE ALLOC FI(SMPLOG) &LOGDISP KEEP DA('SMPE.GLOBAL.SMPLOG') IF &NOPTS ^= NOPTS AND TYPE = SYS1 + THEN ALLOC FI(SMPPTS) SH REUSE DA('SMPE.GLOBAL.SMPPTS') IF &SYSOUT = SYSOUT THEN ALLOC FI(SMPOUT) SYS(T) /* HELD CLASS */ ELSE ALLOC FI(SMPOUT) DA(*) CALL 'SYS1.LINKLIB(GIMSMP)' 'CSI=&CSI' ENDALL: ERROR OFF ATTN OFF FREE FI(SMPLIST SMPRPT SMPCNTL SMPLOG SMPOUT SMPPTS) END