MVS TOOLS AND TRICKS OF THE TRADE March 1993 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer "SHOW ME MVS" IN ONE PLACE. Before speaking about our main topic, I'd like to start this month's article by recommending two books. It is our purpose here, to advance the skill levels of all practitioners of our trade. Until recently, assembler coding and knowledge of the innards of MVS were solely the hard-won fruits of our efforts on the job. In most parts of the country, there wasn't a school to go to, to learn the nitty gritty of this work. However, there has existed a school for many years, the Information Technology Institute of the New York University School for Continuing Education, which has taught many courses catering to our knowledge needs. Many highly successful systems programmers and software developers in the New York area and elsewhere have profited through this school's offerings. There have now arisen some fruits of this school which can greatly benefit all systems programmers everywhere. These are in the form of two books, which originally were outgrowths of NYU Information Technology Institute courses. These books are so valuable and so concentrated, that they knock my socks off. One of my own primary wishes is to know and be able to use all the material in both of them. The books are: "Advanced Assembler Language and MVS Interfaces" by Carmine Cannatello, published by John Wiley, and "MVS Power Programming" by Mitchell Marx and Penelope Davis, published by McGraw Hill. Let me briefly give you my impressions of both books before dealing with the topic at hand for this month. Carmine's book is a wealth. Splendidly organized and enormously rich in facts, it must be characterized as a primary source for a system programmer's apprenticeship and continuing growth over the years. Coding examples abound, and the author systematically explains methods of reaching many parts of the MVS operating system. This knowledge is normally acquired in a more haphazard manner by most of us, and many of these techniques, though essential to our trade, are never acquired. Nobody ever wrote about them before for the public, outside of manuals. If you want one place to systematically march through the maze of MVS techniques, and you're willing to put in the work, this is the place. Mitch and Penelope's book complements Carmine's. More recently written, "MVS Power Programming" is thoroughly pervaded by ESA coding techniques. In this book, the MVS Operating System is explained completely from the ESA point of view, taking advantage of all the new features. The new assembler instructions and hardware concepts are completely integrated into this thorough and systematic walkthrough of deep MVS concepts. Even seasoned old pros can greatly profit from "MVS Power Programming", together with all of us beginner and intermediate people. Both books have optional diskettes available, containing machine readable copies of all the coding examples. Now that you've found out about these marvelous sources of our basic knowledge, you can't afford, for your own professional standing, to do without them. For those of you within reach of New York, the Information Technology Institute of the NYU School of Continuing Education can be contacted at 212-998-7190. SHOW ME MVS. Our current topic is based on a fascinatingly simple concept. Suppose I want to see everything about my MVS system and TSO session in one place. Can I? The answer is, that it's getting pretty nearly possible. A very clever offering in the form of a TSO command, has appeared on the CBT Tape File 183. This command is called "SHOWMVS". Its contributor is a good friend of mine, who is a consultant specializing in VSE to MVS conversions. My friend tells me that he wants everything to be in one place. He can't stand hunting around with many commands for a half hour to find out what he wants to know. SHOWMVS doesn't have any parameters; it always shows everything. And there are only two ways to invoke it. Entering "TSO SHOWMVS" from an ISPF session will produce (on my system) about 1400 lines of BROWSEd output. Pre-allocating a file using a ddname of SHOWMVS with a record format of FBA and an LRECL of at least 101 will cause the output of this TSO command to be written to that external file. What does SHOWMVS produce? A lot. For starters, see Figure 1, which shows the first page of its output. There are tons of essential facts about your system shown just in the first page. I'll detail these a bit later. After the first page, in addition, you get a Virtual Storage Map, SRM Data, display of open catalogs, all your page datasets and dump datasets, the full subsystem vector table with all used program numbers, the linklist, the LPA list, the APF list, the active LPA queue (ALPA), the SVC table with all its extended routers, and a display of all online devices with SMS data if applicable. That's the system-wide stuff. For your own TSO session, there's the TIOT (all your allocated ddnames), your TCB tree and RB chains, the job pack queue (JPAQ), and the Load List off of each of your TCB's. This is quite a mouthful. My friend told me that he's added a few more things for his next release. I just got it yesterday. He's put in extent information on all the linklist libraries, and he's listed all the esoteric and generic names of the units on your system, together with unit counts. The entire report has been tastefully lower-cased. The response for SHOWMVS seems very fast, considering that a lot of catalog lookups have to be done. APF libraries are marked if they are not cataloged, and there is other similar information elsewhere in the output that would seem to take more time. This result is achieved through a trick. The top of the output is produced right away, while a subtask is created to complete the gaps in the report while you're browsing the first page. Clever. For the rest of this article, I want to slow down and explain the significance of what we've got here. If you want to maximize your profit from this product, you'll use SHOWMVS at your work every day, early and often. WHY WE CAN PROFIT BY RUNNING SHOWMVS FREQUENTLY. SHOWMVS tells you, right up front, many kinds of things we usually ask about anyone's system. SHOWMVS also appears to run very fast, as I've mentioned. If you are using its ISPF BROWSE display, the top information will all appear probably in a second or two. Writing the output to a pre-allocated dataset is slower because the subtask needs time to complete, but it is still very quick for the results you get. Even though the output is many hundreds of lines, the information that's up front, shown in Figure 1, is the type of information you might want to see several times in the course of a day's work. Most of the first page is system-level stuff, but there's a lot of it. It's too much to absorb all at once, so you might want to repeat running SHOWMVS, so you can focus on different parts of its output at different times. I'll list most of the items in the first page of the SHOWMVS display, so you can get an idea of its richness. At the beginning, you get the operating system level, the DFP level, the JES2 level if you have JES2, and the name of your NJE node. Then you get a lot of information about your last IPL. Added to that knowledge is a display of your CVTUSER field, to see if CVTUSER was used by some product or add-on to your system. It is important to be careful that you not try to use CVTUSER twice, without planning for a circumvention of the conflict. Added to this initial system display is a software display that shows the TSO/E level, the ISPF level, the level of DFDSS if you're running that product, the DFHSM level if you've got that, the RACF level if you're running RACF, the VTAM level, and the DB2 level if your site is running DB2. Different sites may use different SORT products. SHOWMVS displays the eyecatchers of your SORT load module so you know beyond any doubt, which brand of SORT your machine is running. There follows a complete display of your SMF datasets and their current state of use. Along with that is your SMF system id, plus the currently active setting of your system's SMF job wait time (JWT). The SMF record types you choose not to record, round out the SMF display. This stuff is great. It's all real time, and it reflects what your system is actually using. It beats guessing and getting fooled by looking at the wrong PARMLIB member. The first sixty lines of output are completed by all your CPU ids and serial numbers, followed by estimated processor speed, the quantity of real storage available, and the expanded storage installed. Now you can understand why it might be desirable to refer to this much data several times during various moments of a day's activity. You'll need to examine different parts at different times. MORE PRACTICAL RECOMMENDATIONS. There's another reason to get into the habit of running SHOWMVS several times a day even if you think you don't need to. This is for the repeated learning experience. As the wealth of information impresses itself upon your brain, you'll accumulate a greater understanding of your system's activity. Your mind will acquire an instinctive feel for what your system and your session are doing, much more so than before. This is especially true with regard to the program load displays occurring later in the SHOWMVS output. The program loading information, which comprises much of the remainder of SHOWMVS output, is fit for longer study. Many of us, including myself, haven't been sufficiently aware that copies of load modules are loaded into address spaces and used over and over. Awareness of loaded modules, their responsibility counts, and related matters, can often shed light into why a new version of a program isn't taking effect. An old version of a load module might currently be in use by your session. You may have to logoff and logon again to put the new version of that program into actual use. SHOWMVS reports all of this clearly, in its later displays. Studying the SHOWMVS output in detail, will clear up much of your confusion as to what is actually happening regarding program execution. I found it to be a real eye-opener. SHOWMVS output complements Carmine Cannatello's and Mitch Marx's explanations of program execution mechanisms in MVS. SHOWMVS sheds a lot of light in understanding these matters. It also won't hurt to refer to SHOWMVS's unit and device displays frequently. SHOWMVS will show all the units and devices online to your system. You get full detail of your online devices and their device types. I've often wanted to see if a particular disk pack or tape drive was online to one of my systems. This is especially true in our large shop with many LPARs. A quick SHOWMVS ISPF run, and a "FIND" command in the ensuing BROWSE, settles my question immediately. UCB device type numbers are also shown. On occasion it's helpful to find out what they are, without trying to browse the UCB's themselves in virtual storage. IN CONCLUSION. As usual, space restrictions preclude any further explanations of SHOWMVS here. I have left a lot out. I have to leave the rest of the exploring to you. However, suffice it to say, that nothing shown by the enormous SHOWMVS output is useless. The very reason why its author chose to include something in his program, is because he needed to know about it for some reason. After all, MVS is a big subject. Any tool that will help summarize MVS or give a general picture of it, is of great help to us. I trust that SHOWMVS will be a great help to all of you. Good luck in your searches. See you next month. * * * * * * * * * * * * * * * * * * * * * * * FIGURE 1. This is the top of the output of the SHOWMVS TSO command. The wealth of information given here is obvious. On my system, the output of SHOWMVS goes on for some 1300 lines in addition to what is included in this picture. As you see, this is quite a big computer. It's a 600J. The serial number has been changed for purposes of anonymity. BROWSE -- TCN/AMS UTILITIES - SHOWMVS V3R7M0 ------- LINE 00000000 COL 001 080 COMMAND ===> ********************************* TOP OF DATA ********************************* OPERATING SYSTEM: CVTPRODI: HBB4410 CVTPRODN: SP4.1.0 DFP LEVEL: 3.2.0 CVTDCB: 9B CVTOSLVL: BE 00 00 00 00 00 00 00 JES2 LEVEL: 410 NJE NODE: MSQBATCH LAST IPL: DATE: SUNDAY 93/01/03 (12 DAYS AGO) TIME: 05:59 JULIAN: 93.003 FROM: MRS001/840 NUC ID: 1 CLPA: YES CVTUSER: 00000000 SYSTEM SOFTWARE: TSO/E LEVEL: 2.2.0 ISPF 3.3 DF/DSS LEVEL: 2.5.0 DF/HSM LEVEL: 2.6.0 RACF LEVEL: 1.9 VTAM LEVEL: VX33 00B824F0 DB2 LEVEL: 5740XYR01 SORT'S TRUE NAME IS ICEMAN (FIRST 100 BYTES FOLLOW) D3C9C3C5 D5E2C5C4 40D4C1E3 C5D9C9C1 D3E24060 LICENSED MATERIALS - 40D7D9D6 D7C5D9E3 E840D6C6 40C9C2D4 40F5F7F4 PROPERTY OF IBM 574 F060E2D4 F1404DC3 5D40C3D6 D7E8D9C9 C7C8E340 0-SM1 (C) COPYRIGHT C9C2D440 C3D6D9D7 4B40F1F9 F7F36B40 F1F9F9F1 IBM CORP. 1973, 1991 404DC35D 40C3D6D7 E8D9C9C7 C8E340E6 C1E3E2D6 (C) COPYRIGHT WATSO SMF DATA: SID: MVSP JWT: 0030 CVTSNAME: MVSP SYS1.MAN1 ACTIVE ESACAP 0% SYS1.MAN2 DUMP REQUIRED ESACAP 100% SYS1.MAN3 ESACAP 0% SYS1.MAN4 SMF001 0% SYS1.MAN5 SMF001 0% SYS NOTYPE(16,62) HARDWARE CONFIGURATION: CPU 0 SERIAL: 63098765 MODEL: 3090 CPU 1 SERIAL: 63198765 MODEL: 3090 CPU 2 SERIAL: 63298765 MODEL: 3090 CPU 3 SERIAL: 63398765 MODEL: 3090 CPU 4 SERIAL: 63498765 MODEL: 3090 CPU 5 SERIAL: 63598765 MODEL: 3090 PROCESSOR SPEED: 137.4 MIPS ON-LINE REAL STORAGE: 452608K HIGHEST REAL STORAGE ADDRESS: 452608K EXTENDED STORAGE: 851968K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (The rest of the output continues for many more lines, below.)