MVS TOOLS AND TRICKS OF THE TRADE APRIL 2005 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. MVS SYSTEM LEVELS Anyone who has been around the MVS world for a long time, knows that IBM is always trying to improve MVS. Much of the time, the changes are driven by customer needs, and often they are also driven by changes in the computing industry in general, such as connectivity issues. For the past ten years or so, IBM has committed itself to put out an integrated new release of MVS every half-year or every year. And therefore, it behooves the MVS systems programmer, who is taking care of these different releases, to know something about MVS "release dependencies" and how they are indicated internally within the operating system. Any program which refers to or uses an MVS facility, should have the capability of first determining if the MVS level it's running on, supports that facility. This is especially true for the newer MVS facilities that haven't been around that long. For instance, if a tool (which someone has written) uses, or refers to Hiperspaces, then that tool should be able to look at the particular MVS level it's running on, to see if that level supports Hiperspaces. If the MVS level is too low, then the tool should issue an appropriate error message and end. This certainly makes sense. GETTING STARTED - THE CVT Where are the MVS system levels displayed internally? For this question, as for most MVS internal control block chasing, the starting point should be the CVT or "Communication Vector Table", which is mapped by the CVT macro in SYS1.MACLIB. (For the record, the CVT macro was shipped in SYS1.MODGEN in very early releases of MVS. My guess would be that for assemblies that did control block chasing, it would be very inconvenient to always require that MODGEN be included in the assembly, so CVT was moved to MACLIB.) After the ESA 3.1.0 level, there has been included a relatively new 16-byte field called CVTOSLVL that indicates the presence of certain hardware facilities and indicates the exact system level. The existence of the CVTOSLVL field of bits is indicated by an X'08' in the CVTOSEXT field. When that bit is on, you can query the CVTOSLVL bits to determine the current system level exactly. To get to the address of the beginning of the CVT (ahead of its prefix), you load a register with the absolute decimal value of 16, or with X'10'. The CVT prefix (which is just BEFORE the beginning of the CVT in storage) includes the FMID of the current system level also, but it does not contain bits that can be queried. It just states FMID names. Another indicator of the presence of hardware facilities is the SCCB (Service Call Control Block), which deals with the MVS Service Processor Interface, and which is mapped by the IHASCCB macro. The CVT points to a permanent copy of the SCCB, whose address is located in CVT field CVTSCPIN. The copy of the SCCB which is pointed to by CVTSPCIN, is never deleted for the life of the IPL. You should look at the macro IHASCCB that is in SYS1.MACLIB for more information. At this point, I'd like to suggest, in general, that one try to follow IBM's official guidelines when it comes to extracting a piece of system information. So I'll say that to programmatically (in Assembler language) determine the presence or absence of any particular MVS facility, you should look at the particular documentation for that facility in the IBM manuals, because although most facilities can be tracked down by experimenting, it is best to use an IBM-recommended and (if possible) an IBM-supported way of determining its existence. For most of the facilities that are intended to be used by the (educated) public, IBM tries to provide adequate documentation (for that facility) somewhere. LOOKING AROUND YOUR OWN SYSTEM There are (at least) three good tools for nosing around within your own MVS system, to see what exists there, and to find out the MVS system levels that you're running with. In my opinion, these tools can completely replace most of the specialized auditors' tools that the MVS auditors used to write. (See CBT Tape Files 220 and 221 for an XA version of some specialized Auditor's Tools from Lee Conyers, a well known MVS auditor.) In my opinion, these 3 integrated tools completely replace the collection of specialized individual tools which Lee Conyers wrote, years ago. (You can look at these files in the CBT collection and check the facts out for yourself.) Do a www.google.com search for "CBT Tape" and you'll find all this good stuff on the CBT collection. The three tools referred to, are SHOWMVS (CBT File 492) from Gilbert Saint-flour, now supported by Roland Schiradin, MXI (CBT Files 409 and 410) from Rob Scott, and TASID from Doug Nadel (downloadable from his web site www.sillysot.com/mvs). SHOWMVS is available in source code as well as in load module form, and therefore you can learn how to get a lot of MVS internals information from looking into the SHOWMVS source code. Many of the SHOWMVS nosing-around methods are undocumented by IBM, and had to be figured out by the program's authors. While this is not a recommended method, the authors of SHOWMVS really had no choice. But SHOWMVS is an invaluable tool for us, both in its output and in its source code. So by making even a moderately thorough study of the SHOWMVS source, you can (once you get used to the methodology) learn a great deal about many aspects of MVS internals. In addition to using these Assembler-based tools to nose about your MVS system, it's also good to look at Mark Zelden's IPLINFO REXX exec on CBT Tape File 434. IPLINFO, as a REXX exec, is an excellent example of showing the very considerable power of REXX in chasing MVS control blocks. Mark's collection of other useful tools on File 434 are also well worth looking at, and using. Most of them, being REXXes, are quite simple to use. THE THREE AUDITORS' TOOLS SHOWMVS, MXI and TASID are so good, that anyone who knows how to use all three of them well, can keep an extremely sensitive finger on the pulse of an MVS system. Figure 1 shows the first 40-or-so SHOWMVS output lines out of about 5000 (yes, FIVE THOUSAND). You'll see SOME of the MVS component release levels shown there, although there are even more of them in the rest of the display. SHOWMVS shows its information under ISPF BROWSE, but it can deliver its output in several other ways, including a TCP/IP connection. Much MVS information that is specific to the installation, and a ton of information about the invoking TSO userid are displayed by SHOWMVS. And again, since the source code of SHOWMVS is distributed too, you can (after some study) figure out how SHOWMVS gets its information which is in the display. MXI is an ISPF application from Rob Scott, who was supporting it for years by himself, until he finally got a job with a good company (Rocket Software) which is allowing him to support the free version of MXI while at the same time developing a vendor-supported enhanced "pay version" that is for sale. I only got to see the free version, which is part of the CBT Tape collection, but it has so many display options (at last count, about 118 general ones in the free version, besides the sub-options and memory displays) that if you study it well, it will keep you busy for some time. Many innards of MVS are displayed by MXI, including UCBs, ESOTERIC device names, SMS information, RACF innards, and many other things. I can't even begin to scratch the surface of what MXI does, here. But I can tell you, that you can find out a lot of information about your system and software levels using MXI. Doug Nadel (the developer of TASID) works for IBM, and he was one of the ISPF developers for a long time. One of the things Doug did, among many others, was to develop ISRDDN. Since IBM equipment was used in developing TASID, it has an IBM copyright, and I can't put it on the CBT Tape, although Doug has permission to distribute TASID for free. So you can get TASID from Doug's website, www.sillysot.com/mvs. TASID will tell you many things, and will allow you to browse storage with quite a bit of help, such as a FIND facility. There are a lot of point and shoot features in the TASID storage viewer. ENQ displays are a particularly strong suit of TASID, and the RACF information is very useful. Of course, there is a lot more to TASID than I have space to mention here, and therefore I encourage you to try it and play with it. AN ILLUSTRATION OF SYSTEM LEVEL DEPENDENCE A particular instance of system level dependence can be found in the changes which IBM made to UCB lookups, around ESA version 4. The UCB lookup scheme had been changed once before that also, at the XA 2.2 level. So any code which is intended to run on multiple MVS releases and which looks up devices, device characteristics, and device activity, especially if it does not run authorized, has to have release level dependent coding when it comes to the UCB lookups. SHOWMVS itself has such a requirement. One of the chief displays of SHOWMVS is of device activity. You want to know which disks are allocated to which jobs, and which tapes are on the tape drives. Take a look at Figure 2 to see a partial illustration of this SHOWMVS display, for DASD. Gilbert Saint-flour maintained the SHOWMVS code for many years, since SHOWMVS is his program. (Roland Schiradin maintains SHOWMVS nowadays.) When IBM changed the UCB lookup scheme in ESA version 4, they required that mass UCB lookups which found the actual UCBs (and not a copy of the UCB) had to be done by authorized programs only. Only APF authorized programs could execute the IBM-mandated mass-lookup options in the UCBSCAN macro. So Gilbert, who was supporting these lookups in the SHOWMVS displays, and who needed the actual UCB for real-time information (and not a copy of the UCB), was stuck. SHOWMVS supports a complete refresh of the DASD and TAPE devices display, every time you press Enter under ISPF, and Gilbert did not want to eliminate this display whenever SHOWMVS would be run non-APF authorized. So Gilbert did some research into how the UCB lookups are done internally, in the IBM code, and he came up with a scheme to do the mass UCB lookups in a non-authorized fashion. You can find his code by looking at the SHOWMVS source code and doing a FIND on the string "ULUT" (which means "UCB Lookup Table"). There you will see the release-dependent code, in all its glory. When SHOWMVS runs non-APF authorized, it will still create the DASD and TAPE device displays. ALERTNESS IN RELEASE DEPENDENCY MATTERS IBM is very customer-driven when making changes to MVS. So for instance, when banking, insurance, and other large institutions which have to stay open all the time, asked IBM for IPL reductions, IBM had to respond by changing and restructuring parts of MVS. Many of the changes had to involve a redesign of the original MVS structures which were created at IPL time, and which could not be changed without another IPL. These all had to be (one at a time) converted into dynamically alterable structures that accomplished the same result as the former static structures, but which could be changed with an operator command. For example, one of the first areas to be addressed was device definitions. MVS used to be statically generated with all the devices statically defined, with an "IOGEN" required when changes were needed. That was one of the first things that had to go. There is HCD that does the same job now. A new IODF can be made and plugged in much more easily than by doing the complete system change which an IOGEN used to require. Then there was the static APF list and other static things which had to be made dynamic. JES2 needed many such changes also. And the new requirements for restructuring of MVS internals are constantly coming in. So (in conclusion), what should we do about it? A general piece of advice is to keep abreast of the IBM announcements and get the MVS conversion guides, whenever your installation is planning a release change, and even if it isn't. Staying abreast of the changes to MVS is the main part of the effort. What to do about them, will depend on your installation's particular needs. I certainly wish you much success in all these, and your other, endeavors. And I hope to see you again here next month. * * * * * * * * * * * * * * * * * * * * * * Figure 1. About the first 40 lines of SHOWMVS output. There are over 5000 lines more. Much system information is displayed. Quite a bit of it is renewed every time you press Enter. SHOWMVS is running authorized >Operating System: z/OS 01.06.00 FMID: HBB7709 CVTOSLVL: FF FF FF BF E9 00 00 00 DFSMS/MVS 1.6.0 Dynamic Linklist is supported Dynamic LPA is available DFSMS Loader Fork Exit is present DFSMS RVA SnapShot is available DFSMS RVA SnapShot API is available JES2 Level: z/OS 1.5 NJE Node: N1 DSNID: 01 >Last IPL: Date: Sunday 2005-03-06 (2 days ago) Time: 11.08 Julian: 2005.065 From: Z6RES1/0A80 NUC Id: 1 Type: Warm Start CVTUSER: 00000000 Last Cold Start (CLPA) Date: 2005-02-27 Time: 06.21.19 Last Quick Start (CVIO) Date: 2005-02-27 Time: 06.21.19 SYSPLEX name: ADCDPL SYSPLEX ID: 1A Sysname: ADCD Lparname: Timezone: W 05.00.00 Leap Seconds: 0000000000000000 >System Software: TSO/E Level: 3.6.0 ISPF Level: 5.6 PDF 5.6 DF/DSS Level: 1.6.0 RACF Level: 7.70.9 ICKDSF Level: 1.17.0 VTAM Level: 6.1.6 VE616 00C45008 LE Version: 1.6.0 TCP/IP: 2004.0 M 5655-H MVPTASK Tseb SI Proc Ver Tsdb Tsdx Asid TraceOpts Status 1040B040 01 TCPIP 06.16 103F4000 103F40C8 0048 00000000 Active * * * * about 5000 lines more * * * * * * * * * * * * * * * * * * * * * * * * * * Figure 2. SHOWMVS display of DASD devices, showing which address space has allocated each device. Every time you press Enter during the SHOWMVS ISPF display, this information gets updated. >Device Class: DASD Unit Names: 3390 3380 DASD SYSDA VIO SYSALLDA UCBs: 368 (defined) 45 (on-line) DEVN UCBTYP Unitname S Volser Status 0124. 3030200E 3380 S OS39H3 Resident Private IDAW 0130. 3030200E 3380 S RESCUE Resident Private IDAW 0300 3010200F 3390-1 WORK01 Resident Storage IDAW 0301 3010200F 3390-1 WORK02 Resident Storage IDAW 0302 3010200F 3390-1 WORK03 Resident Storage IDAW 0303 3010200F 3390-1 WORK04 Resident Storage IDAW 0304 3010200F 3390-1 JES301 Resident Private IDAW 0305 3010200F 3390-1 MOD113 Resident Private IDAW 0306 3010200F 3390-1 MOD114 Resident Private IDAW 0307 3010200F 3390-1 MOD115 Resident Private IDAW 0308 3010200F 3390-2 MOD201 Resident Private IDAW 0A80. 3030200F 3390-3 S Z6RES1 System Resident Private Allocated J=LLA 0A81. 3030200F 3390-3 S Z6RES2 Resident Private Allocated J=IBMUSER IDAW 0A82. 3030200F 3390-3 S Z6SYS1 Resident Private Allocated J=DUMPSRV IDAW 0A83. 3030200F 3390-3 S Z6DB81 Resident Private Allocated J=OMVS IDAW 0A84. 3030200F 3390-2 S Z6CIC1 Resident Private Allocated J=OMVS IDAW 0A85. 3030200F 3390-3 S Z6DIS1 Resident Private IDAW