MVS TOOLS AND TRICKS OF THE TRADE June 1996 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer EYES - PART 2 Last time, we talked about some different ways of seeing what the various parts of your MVS operating system and DASD are doing. My approach in looking at a system is to find out as much as possible from the system itself. Today we will look at a few hints in taking over an MVS system from somebody else's care. Often, when a systems programmer leaves a shop, the remaining people have a hard time discovering some of the quirks in the way the shop was run. Documentation, if it exists, always helps (unless it is wrong), and I use it if I have it. Turnover information from the previous keepers of the system can be helpful, but in most cases such information is only partial. The old people, even if they are still around for a while, usually say to the new ones: "Take it, it's your baby now." And they make a quick exit. Today, we'll pretend that we're the new people. In a system programmer's career, such periods can either be nerve-wracking or fun, depending on your approach and level of experience. The kind of tools you have at your disposal, and how you use them, will make a lot of difference. Last time, we coined the term "eyes" to refer to any tools that will show you what the operating system is currently doing. What kind of "eyes" you have, and how you "look" with them, will tell you a lot about how your new system is structured. They will make it much easier for you to take care of things in the future. As we said last time, there are many types of "eyes", and much of a systems programmer's experience consists of learning how to use them. Some "eyes" are of a more special nature, doing one type of job, or just a few types. Others are truly multi-purpose tools which are capable of handling hundreds of different types of jobs. The phenomenon we called "the vendorization of software", that we talked about two months ago, has one very positive aspect. Many vendors have really "jazzed up" their tools in an effort to beat the competition, loading them with a large variety of features. Systems programmers having access to such products have a big opportunity to increase their "visual acuity" by learning how to use these "multi-purpose eyes" in watching their system. We're democratic here. A lot of you are working in shops that are smaller, which can't afford to buy some of the more sophisticated and expensive tools. Other shops will buy one tool, and therefore don't have the budget or the authorization to buy a different one whose functions partially overlap the functions of the first one. I have (as regular readers of this column know) always shied away from writing much about vendor products that you have to buy, because one shop may have it, and many others don't. I want the things I write about to be accessible to all. We fortunately have the alternative of being able to get what we have termed "Accessible Software", which is free to everyone. Accessible Software consists of free software tools, that usually come with source code. These tools can be found in such large collections as the CBT MVS Tape (obtainable through NaSPA), the NaSPA VIP tapes, the JES2 SHARE Tape (from Jack Schudel 904-392-4601), and the JES3 SHARE-GUIDE Tape (from Alan Field 612-828-4979). After this introduction, we'll now begin to use our available "eyes" to start "staking out" a new system that we're just taking over. WHERE TO LOOK FIRST. We've just gotten a TSO id on the new system which we've never seen before. What do we do? First thing, get into ISPF EDIT or BROWSE and look at SYS1.PARMLIB, wherever it's cataloged. (Write down the volume name.) Check out which IEASYSxx members are there, with a good look at IEASYS00 first. Remember that NIP (the Nucleus Initialization Program) always looks at IEASYS00, even if there are other IEASYSxx members present in SYS1.PARMLIB. The other members are merely overrides to IEASYS00. This little fact is not intuitively obvious from the way the rest of SYS1.PARMLIB is laid out, but it is mentioned in the IEASYS section of the MVS System Initialization Reference. You can probably guess by looking, if the other IEASYSxx members should be taken seriously. If you can look at SYSLOG since the last IPL, check the first console reply from startup, to see if SYSP is coded, or if it is anything besides SYSP=00. The purpose behind this is to see if the "real" LNKLST or other members is "00", or if any of them are something else? What are the actual startup conditions of our system? They are all in SYS1.PARMLIB somewhere, but you have to be sure as to what they really are. A really good example is the Master JCL. I once saw a system in which the main PROCLIB was SYS1.PROCLIB.NEW, and not SYS1.PROCLIB, as it usually is. The IEASYS member was pointing to MSTJCL=41, and when I saw that and checked out the load module MSTJCL41 (by browsing and/or disassembly), the pointer to the non-standard PROCLIB was discovered. I asked the previous keepers of that system why they had set things up with suffixes of "23", "41", and "50", besides having "00". They replied that this was a standalone system, not connected to any others. If they made one mistake with a PARMLIB member, they still needed some other ways to IPL so they could fix things. This also explains why they had set up a one- or two-pack "Rescue System", which is a completely self-contained IPL-able MVS. They needed to have several emergency routes to fix things under their circumstances. Files 164 and 022 of the CBT MVS Tape contain materials that can help you set up your own self-contained MVS Rescue System. After SYS1.PARMLIB, you go to the JES2 or JES3 proc in what the Master JCL says is your main PROCLIB. Usually it is SYS1.PROCLIB. The JES2 proc will tell you where all the other valid PROCLIBs are, and where the valid JES2PARM JES2 initialization statements are. The equivalent (I think) for JES3 is the JES3 Inish Deck. This will help you check out where the SPOOL packs are, and where the JES2 Checkpoint dataset is, plus all the JES2 network node names, job classes, output classes, and such. Or their approximate equivalents in JES3. After that, you have to find out about your I/O configuration, so you look at your last MVSCP, or HCD output, and try to make sense of it. This is the classic, basic, "stake-out" approach. PERFORMANCE MONITOR INFORMATION, A VERY BIG SET OF EYES. At this point, having as many extra "eyes" as possible, will enhance your effectiveness a dozen-fold. Again, if you have a vendor-supplied performance management product such as Candle's "Omegamon" or Boole and Babbage's "Resolve", you can very effectively use what you have. In my writing (for ALL of the public), I can't assume that you have any of these. Also, on a new system you're discovering for the first time, you can't expect these tools to be already installed. Therefore I'll use examples from what's free, and we'll go on from here. At this writing, I have to say that one of the best "free" sets of eyes for looking at a system, is the SHOWMVS program from Gilbert Saint-flour which can be found on File 183 of the CBT MVS Tape. SHOWMVS is simple to install, being a single load module, which is executed as a TSO command. The version of SHOWMVS which is on the current CBT tape (level 404 as of this writing) is version 5.14, which works for all MVS levels from 2.2.0 through 5.2.2. SHOWMVS shows you a lot. The output on one of my systems is over 2800 lines. SHOWMVS puts its output into the ISPF BRIF (browse) service, but if you allocate a file with LRECL greater than 101 to the ddname SHOWMVS, then SHOWMVS will write its output to that file when it is invoked. The SHOWMVS ISPF browse function takes effect almost immediately, while the file output takes a while, perhaps two or three minutes sometimes. The reason for this is that initial functions of SHOWMVS, such as showing the IPL date and system software levels, are done quickly and appear at the top of the ISPF display, while catalog, UCB, and VTOC lookups take much longer. SHOWMVS does the quick things with its main task, while it attaches a subtask to do the longer running things. The main task fills in a skeleton ISPF browse right away, while the subtask plugs in its newly found information as it is obtained. In ISPF, the result is interesting to watch, being dynamic, but the file-written output is not finished until the subtask completes filling in all the longer running information. For looking at a new system, the information displayed by SHOWMVS is unbelievably comprehensive, and for a first look at your new system, it's probably best to obtain a printout. Some of the initial things displayed are: MVS operating system level, DFP level, the first eight CVTOSLVL bytes (which show details of the ESA system level), JES2 level, the NJE node name of your system, detailed last IPL information, TSO/E level, ISPF level, RACF level, VTAM level, a dump of the first 100 bytes of your SORT program, SMF data, your SMS configuration if you have one, hardware configuration (CPUs and serial numbers, etc.), IODF data, LPAR data, a Virtual Storage map, and SRM data. These are just the initial things. After that, the following things are displayed: all the open catalogs (the CAX work area), the Page Datasets, the dump datasets and all dump options, a JCL listing of the MSTJCL00 load module, the entire Subsystem Vector Table (including active and inactive subsystems and all the function numbers of the active subsystems), the current TCAS parameters and all the program names in SYS1.PARMLIB(IKJTSO00), RACF datasets and some of the global RACF options in effect, the entire RACF started task table ICHRIN03, address space usage from the Address Space Vector Table (ASVT), and all active JOBS, Started Tasks, and TSO users. This is nowhere near the end. Then there follows a detailed display of all the datasets in the Link List, a similar display for the LPA List, and the APF list (whether the APF list is in the old or new format). Then the Active LPA queue (ALPA) is displayed, so you see the LPA program overrides. Then you get a complete listing of the SVC table, which is followed by all the Extended SVC Router numbers which are occupied and not occupied. If you're running authorized, you then get a complete display of the PPT (Program Properties Table) which shows you what privileged programs are running. This whole thing is followed by a complete display of all online units (UCBs) of all device classes, constantly updated with attributes, allocating jobs, and SMS information (if that is applicable). In our January 1996 column, we discussed how this current actual UCB information is obtained, even when SHOWMVS is running unauthorized. After that, all defined consoles are displayed. So much for system-wide information. The rest of the SHOWMVS display (if you can believe that there is more) concerns your own TSO session attributes. There is detail concerning your TSO session that is beyond belief. Some of the things shown are: your current JCL for your TSO job step, session startup and performance group information, your address space virtual storage map, RACF profile, TSO profile, your REXX environment, your ISPF environment, your whole TIOT (allocated datasets) with EXCP counts for each dataset, your Job Pack Queue and your entire Load List. When I started to write this column, I called Rick Fochtman and asked his opinion on how to stake out a new system. He agreed with me on all the preliminaries, adding the importance of seeing the I/O configuration. Then, I said to him that to be fair to everyone, I wanted to only write about free tools, for inspecting the system further. He answered very simply: "Then I guess you have to tell them about SHOWMVS." So I did. Of course, a picture is worth a thousand words, and I'd advise you to get a new CBT Tape (or a new Naspa CD-Rom) and fire up SHOWMVS for yourself. I'd like to apologize that so much of this article is a list of what SHOWMVS does. But if you'd look carefully at the items in this list, one by one, you'll see that most of the things you have to know when you stake out a new system, are mentioned here. So for people who need this information, I've mentioned what I could in the space provided. Believe it or not, SHOWMVS doesn't show you EVERYTHING you need to know, or should know about a system. Next time, we'll continue further, using different eyes. Good luck. See you soon.