MVS TOOLS AND TRICKS OF THE TRADE DECEMBER 2000 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. KEEPING YOUR FINGER ON THE PULSE When we think about the nature of our jobs, we can't forget one basic fact: It is our duty to know our shop's maintenance structure, and to keep our finger on the pulse of all system software changes. Today, I'm going to talk about this subject. I'll start by mentioning the obvious truth that although the operating system itself is common to all OS/390 and MVS shops, each individual shop is set up in a different manner, and each is maintained, using different procedures. How an MVS shop is maintained, depends both upon the people who had set up the MVS system initially, and also upon the people responsible for the system now. The way you deal with the maintenance of your shop, is intimately dependent on the tools you know how to use. For example, if you know how to use the free PDS product (on File 182 of the CBT MVS Utilities Tape), it is obvious that you will maintain your software inventory differently than if you don't know how to use PDS (or its vendor-supported successor STARTOOL from Serena, Inc.). This is because the PDS product allows you to do manipulations that the IBM-supplied tools don't allow, such as expanding a partitioned dataset directory on the fly, without your having to re-allocate the dataset. The PDS package also allows you to easily create and change ISPF statistics or load module attributes, without your having to re-create or re-linkedit the member. Those are just a few of the many relevant tricks that the PDS package allows you to do. These manipulations are much harder to accomplish with native IBM-supplied software tools. In the latter part of this column, I'll mention a couple of procedures you can set up to better keep track of your shop's maintenance, if you take advantage of the capabilities of some free tools. IBM gives certain recommendations as to how to maintain an MVS system. However, IBM is restricted to talking about its own tools that it ships, and usually will not recommend an independent vendor's tools, or free tools. Therefore, IBM's recommendations are always taken "with a grain of salt", in most shops. That is, we read them and pay attention to them, but we always know (in the back of our minds) that sometimes there is a better way. Now let's talk about record keeping. System software changes must be kept track of. If you put in a new PTF level of your system software, you must keep some record of it, so that somebody else, or even you yourself, can later follow what was done. For example, if you have a single system or a single LPAR, you might say that this is very simple--just look at the SMP/E records and you'll know what's there. But if you have several LPARs or many diverse MVS images, and the changes are done to a single system and later propagated, then the task of keeping records about which system received the maintenance, rests squarely on your own shoulders. You have to keep some good records of that. It usually pays to set up a text pds, common to all the systems programmers in the group, where maintenance changes have to be recorded when they are made. I'd say that in most shops, this task is complicated by the fact that SMP/E work is never done to a running production system. SMP/E is usually done to a test system, or to target libraries that are never directly used for execution. Therefore, the propagation of software changes to the running system is still done in an individually designed manner, which is different for each particular shop. Again, you have to keep good records of what was done, otherwise the status of the shop will degenerate to a state of confusion. And with a software system as complicated as MVS is, confusion can't be tolerated. At a previous shop where I worked, we had an excellent automated system to maintain given software levels for multiple LPARs. We would do all our SMP/E maintenance to a test res pack that was IPL'ed and was connected to the production packs so it could run real work. This res pack could be cloned through an automated procedure that was executed by the systems programmers. The target SMP/E zone was cloned along with the libraries, and ZONERENAMEd. An image of this res pack would then become the production res packs for the various LPARs, and every time the test res pack was cloned, a record would be written automatically to a common file, so that every invocation of the cloning procedure was thoroughly documented. At the time I worked there, I got permission to get this system (as it existed then) put on the CBT MVS Utilities Tape, and it is on Files 204 and 205. Additionally, a similiar system to maintain CICS is on Files 210 and 211, and the same sort of thing for DB2 maintenance, is on Files 212 and 213. WHAT MY APPROACH IS. In my travels, I've seen many diversely set-up shops. I have my own opinions as to what is "better". But I always keep in mind that the designer of a shop's setup may have had needs or requirements that I don't know about. The world of MVS, 10 or 15 years ago, was far different than it is today. There may have been a "service level requirement" in effect then, which isn't so relevant now, since today's machines are faster, and the operating system is more efficient. When I look at a shop's structure, I always assume that the person who designed it acted intelligently, to the best of his or her ability, at the time the decisions were made. However, I also assume that there could be room for improvement, and that the system can somehow be made better, if I look carefully and analytically at it. It is my opinion that "simple is better". If the maintenence procedures are simple--that's better. If the record keeping is simple and easy to follow--that's better. If any sysprog who comes in, can easily learn this "software change and record keeping system", that's better. If PARMLIB setup is simple, and workload management is set up simply and logically--that's better. If straightforward and relatively simple procedures have been built into the design of the shop, then you can change systems more easily, and you can put in system software improvements very quickly, and with far less hassle. It's also a great help, when a shop is arranged so that all software change information is kept in one place. When you work at a particular shop though, the reality isn't usually that way. Let's look at a "bad case" scenario. The shop might have been heavily customized. Some piece of system software might use the "user CVT" area, in a way that's not easy for you to discover. Information about various exits, usermods, and customizations, might be scattered among the old sysprogs' CNTL datasets, and might not be kept in one central place. The shop-developed tools for keeping track of the software inventory, might be written in a language you may not understand when you come in, such as SAS. To see what's going on, using such tools, you'd have to learn SAS. Although I feel that it's intrinsically good to learn new things, my opinion is also, that the maintenance of an MVS shop should be set up so it's doable by any "standardly trained" MVS sysprog. (However, performance tuning and capacity planning might require a good knowledge of SAS.) I'd say that once every 3 months, and more often if you're new, you should ask yourself one question. The exact text of this question depends on how long you've been at your shop. If you've been at your place for a long time, you should ask: "Can I truthfully say to myself that I can explain this system to someone else?" However, if you're newer at the shop, or you're just coming into this shop for the first time, you should ask: "How do I go about making sense out of this situation without inadvertently destroying or damaging some essential system function? How do I go about learning what's going on, and acquire a sense of completeness in my knowledge?" My own approach to an answer is two-pronged. If I'm new, I try to set up my own free diagnostic tools. These tools can "feel out the system". Tools which check "what's in the system, from the system itself", such as SHOWMVS, MXI, and TASID (see my April 2000 column), will reveal the system parameters, and many details about how the system is running, without my having to ask anyone. The other thing I do when I'm new, is to ask the other people at the shop, various questions about how the system is set up and maintained. My questions to them are made far sharper and to-the-point, by the fact that I've used my own diagnostic tools to already find out a lot of the particular information for myself. For example, I may already have found out where many of the user exits are. Asking the other people, is usually a matter of finding out where the source code for the exits is kept, and historical matters, such as why it was necessary for the shop to implement a particular customization procedure or exit. Also, it can be a very good idea to find out the names and (former) userids of all the system programmers who have worked at the shop in recent years. If some of their datasets are still around, I take a very careful look at their contents. Now that we've talked about some general matters of how system maintenance SHOULD be designed, I'd like to mention a few specialized SMP/E tools that I myself have found useful. These are definitely things that IBM can't recommend, and they can and do make our lives much easier. MY LPTF CLIST What's in a PTF? Want to find out quickly and effortlessly? Using the free REVIEW dataset browsing program that you can obtain from File 134 (load modules are on File 135) of the CBT MVS Utilities Tape collection, you can make a simple CLIST, which I call LPTF, to browse any PTF you've RECIEVEd, and which is still on your SMPPTS dataset. The LPTF CLIST reads as follows: PROC 1 &PTF CONTROL NOLIST REVIEW 'SYSSMPE.SMPPTS(&PTF)' where you can specifically code the name of your SMPPTS dataset in the text of the CLIST, as I've done. If you add an invocation of this CLIST to your ISPF command table, using an invocation string of "LPTF", you won't even have to precede this inquiry with the prefix of TSO. You just say: LPTF ptfnumb and when you press ENTER, you can see the text of your PTF immediately, on top of whatever else you were doing. This tool comes in extremely handy, once it's been set up in your shop. Its value is enhanced additionally, by the fact that the REVIEW command contains the DIR subcommand, to list the entire directory of the current (SMPPTS) partitioned dataset. What you do is as follows: Suppose you want to see PTF UW12345. You invoke LPTF UW12345 from the command line of your ISPF screen. Suppose you got the number wrong, and you get a blank REVIEW screen instead. You can then simply enter "DIR" (a REVIEW subcommand), which shows the entire pds directory, and scroll down to the area which has similar PTF numbers. Then you can look at the text of other PTF numbers which were "close" to the one you originally wanted. The LPTF CLIST thus becomes a handy tool indeed, and you can use it at any time. The REVIEW program works under "raw TSO" too, so you can use this PTF inquiry method even without ISPF. OTHER SMP/E-RELATED TOOLS Years ago, I worked out a method of determining the FMID of all the SYSMODs in any SMPPTFIN-format file (usually a file of PTFs). All of the software programs necessary to do this processing, can be found on File 118 of the CBT MVS Tape. This processing method utilizes a program originally written by Jerry Lawson, and a post-processing program written by me. It does not involve SMP/E at all, and using it, I can analyze PTF tapes for FMID information before the time of the RECEIVE. Input to my procedure is any SMPPTFIN-format file. Output is a file of SYSMOD or PTF numbers, ordered by FMID, and with no repeats. I don't have space to describe the details of this processing here. However, you can set it all up, using the materials provided on File 118 from the CBT MVS Tape. If you'll also look at File 215 of the CBT Tape materials, you'll find my LPTF CLIST, and a mighty handy CLIST to invoke SMP/E in the foreground. The CBT Tape materials can be accessed through the Members Only portion of www.naspa.net , or through the new NaSPA cd-rom Version 1.5, or from an actual tape. I hope you've found this month's thoughts to be helpful, and I sincerely wish you all a Happy Year!