THE VALUE OF TOOLS, NEW AND OLD - PART 2 (c) Copyright 2019 by Sam Golob. All rights reserved. SOME NEWER TOOLS YOU MAY NOT KNOW ABOUT Our last article was a general introduction to user-written tools for the z/OS or MVS-related operating systems. Today I'd like to bring up some newer tools that are not likely to be well-known as yet. The usefulness of knowing about these newer tools depends on how badly you need them. But it shouldn't hurt to mention some of them, so people can see for themselves. Some of these tools may be found in the very interesting CBT File 731. File 731 was created to showcase TSO commands, usually of the APF- authorized variety (but not always), to let you know the innards of some control blocks related to the IKJTSOxx member of PARMLIB. Recently, a set of commands was added to cover the area of the TSOKEYxx member of PARMLIB, as well. If you want to be able to know about many of the workings of TSO in your system, it would pay to get familiar with the TSO commands and other programs in this file. How many of you have heard about the TSO RELOGON Buffer, for example, not to mention having some tools to manipulate it? THE PARMLIB DILEMMA To really treat this area properly, I feel we have to backtrack, and I'll tell you a story. In the early 1980's (around the time of MVS SP 1.3.3 and before), many (SYS1.PARMLIB-determined) MVS control blocks were "static", and it required an IPL to change them. Pressures from banks and brokerage houses, and other institutions which had to minimize "down time", forced IBM to create a new design pattern, so as to minimize the number of IPL's necessary. Gradually, one control block at a time, IBM made many control blocks renewable and modifiable without the necessity of an IPL. The design, in general, was as follows: The particular control block occupied some common storage, in a certain subpool, and was addressable from the CVT (Communications Vector Table) through a chain of addresses. So the plan would be, to GETMAIN some similar common storage, make a new copy of that control block in that storage, and re-point the chain of addresses to the new storage instead of the old storage. A program would be written to do this, and that program would be triggered by issuing a "SET" console command of some sort. Voila. The control block was changed, and we don't need to IPL. How would we instruct the system which way to change the control block? It would depend on a PARMLIB member. Initially, the control block was created at IPL time by setting up a PARMLIB member. Now, the dynamic change would be instituted by copying that PARMLIB member to a different one, and making the necessary changes to it. Then we'd issue a SET command to force the system to point to the new PARMLIB member instead of the old one. Easy? Yes. Nice design? Yes. It certainly seems to solve the problem of reducing the number of IPL's. And it did. But..... Now comes the dilemma. In earlier times, before this business of "renewable control blocks" was designed by IBM, many shops felt that to implement "security", they needed to restrict the personnel who were allowed to change members of PARMLIB. Some shops actually required up to ten signatures from company officers, before a PARMLIB change would be allowed to happen. Of course, this (almost) completely defeats IBM's plan, outlined above, to reduce IPL's. In order to change a control block and avoid an IPL, you'd have to create a new PARMLIB member, or at least modify an existing one, and management wouldn't allow that. Systems programmers had to get their work done, and keep the system running. To avoid an IPL, they'd sometimes have to change a PARMLIB member on short notice, and management policies were blocking this. What to do? The obvious solution would be to wrestle with management. Sometimes, though, they'd give you a deadline, and you just couldn't deal with the red tape at all, because the required officers were not available to sign off on the change. There wasn't time, and the job had to get done. So we worked on the problem, for at least those few PARMLIB members where we needed a solution. And for these PARMLIB members, we made a solution available. What did we do? DYNAMICALLY CHANGING SYSTEM VALUES If you have an APF-authorized TSO command, it can be made to do just about anything that one of IBM's "SET" commands can do. We can imitate IBM's "dynamic control block replacement" process ourselves. If we're APF-authorized, and systems programmers (who are the "system doctors") should responsibly have that privilege, then we can write our own programs to make necessary control block changes, when we're in a pinch. Management is forcing us to perform a change, and they are not giving us the time to do it "their way", which is a contradiction. So we can quietly get the job done our way (but only when it is really necessary to do it like that--I have been in that position myself, and I know what it feels like. I quietly, accurately, and safely got the job done, and nobody complained, because the system was running properly and there was no outage and there were no delays.) So to see some of the work that we've already done in this vein, look at the appropriate programs in CBT File 731. For example, if you want to find out about the parameters related to the SEND or LISTBC TSO commands, you should run our TSO command called EESCB, which shows their values in detail. If you want to look at the "PUBLIC" TSO authorization tables, then you should invoke the (authorized) TSO command called ASUB. If you want to look at your own TSO session's "PRIVATE" authorization tables, then you should invoke the (authorized) TSO command called TSUB (in CBT File 797). If you want to dynamically change your own session's auth tables, then these tools, and others, are in CBT File 797, and you can do that. ASUB ? and TSUB ? will get you online help. To display the XMIT-RECEIVE parameters in the IKJTSOxx PARMLIB member which is active, you can use the INMXD command, and if you want to dynamically change the OUTLIM value or the "warning" values there, you have the CINMX command. So you see there is a lot to study in Files 731 and 797. Files 731 and 797 have pretty good coverage, when you need to poke into TSO Parmlib-related values, and more recently, to look into TCAS-related values, such as USERMAX. Our USERMAX (authorized) TSO command can dynamically change the maxusers value, for example. And we have other (appropriately named) commands in File 731 to display or change any of the other TCAS-related values, such as HIBFREXT or LOBFREXT. We also have some coverage of the VATLSTxx PARMLIB member, with our DVAT TSO command. VATLSTxx is different, however, in that all the IPL-related stuff is used once, at IPL time, and then that storage is overlaid. DVAT shows VATLSTxx values that are still left in storage after IPL, but the command does not reflect the results of individual MOUNT console commands, which temporarily change the status of individual disk packs between IPL's. So far, the VATLSTxx coverage will only display values, but will not change them. The capability is still informative, however. And don't forget our general commands: SHOWTPVT and SHOWTCAS. These commands show all the general values and addresses in your system which are related to the TPVT (TSO Parmlib Vector Table) and TCAS (general TSO values mapped by the IKTTCAST macro) respectively. There is a lot more to look at in CBT Files 731 and 797. If you want to know more about authorizing your TSO commands, look in CBT File 185, because you'll have to do a lot of that. For those of you who use TEST and TESTAUTH to debug your programs, the DTEST TSO command will show you which TSO commands that TEST can execute and which "extra subcommands" can be run under TEST. Using the DTEST command, you can display the current configuration of TEST programs and TEST subcommands which are extra. However, if you want to change these values dynamically, without touching the IKJTSOxx PARMLIB member, we have a batch program called LOADTEST in CBT File 731, which will do that. For example, if you want TEST to be able to display 64-bit addresses, this can be set up. First you need a TEST subcommand to do it. There is a command on CBT File 300 called IKJT9LGZ, which can be invoked as the "LG" TEST subcommand. And IKJT9LGZ can display 64-bit addresses. The normal way that "extra programs" and "extra subcommands" for TEST (or TESTAUTH) can be deployed, is to enter them in the IKJTSOxx PARMLIB member under the category TEST, as TSOCMD and SUBCMD entries, and then issue a SET IKJTSO=xx console command, or a PARMLIB UPDATE(xx) TSO command. But using our LOADTEST batch program from CBT File 731, you can load these values dynamically using control cards, and you don't have to change anything in PARMLIB to do it. Invoking LOADTEST once, will generate the correct control cards controlling your current TEST PARMLIB configuration. And then you can modify these cards and reload them into storage using the LOADTEST batch program again, so TEST (or TESTAUTH) will then have the extra capability that you formerly could only get using the IKJTSOxx PARMLIB member. This is just a sample of what the TSO commands and programs in CBT File 731 can do. You see that many of them can dynamically change TSO-related values without your having to touch PARMLIB. LOOKING AT LOAD MODULES I don't know how you feel about it, but to me, there was always a kind of mystery around load modules. I had some trouble looking at them and understanding them, even though I could BROWSE them in hex, using ISPF. It was a matter of not seeing clearly what was going on. Of course, you can disassemble a load module to get a semblance of source code. IBM "frowns" on users doing that, but to solve a problem, you sometimes have to disassemble the code. There are some disassembler programs on the CBT Tape. One of the newest ones is on File 885, from Albert Cheng. IBM themselves supply a disassembler (called ASMDASM) in their optional HLASM toolkit package. That's what I use, but you have to be licensed for it. ASMDASM is located in library HLA.SASMMOD2. An advantage to using IBM's disassembler is that it is updated whenever IBM adds new instructions to the instruction set. A new development has made looking at load modules a bit easier, without actually doing any disassembling. That's what I'm going to talk about now. It's a way to look at the contents of a load module in a more meaningful way, and to see its raw contents, but clearly, and with all the hex displacements made obvious. The program is called LISTMOD, and it can be found on CBT File 994. LISTMOD is a TSO command, and in its present form, all you have to do is to point it at a load module name, and LISTMOD will display it. In other words, you can say: LISTMOD IEFBR14, and you'll get an ISPF-like 3-line hex display (with ruler) of that program's 8 bytes, together with a bunch of header information, and all displacements shown clearly. The interesting thing is, that you can display a load module with several million bytes just as easily. LISTMOD has one possible subparameter, "ENTRY". When do you use the ENTRY parameter of LISTMOD? Sometimes it is more convenient to do so. You do it when the entry point of a module is far from the beginning, and if you are mainly interested in seeing the code near the entry point. Sometimes the entry point is "too far" from the beginning of the load module, to easily scroll there. If the entry point of the load module is somewhere in the middle, and you don't want to start the display from the beginning of the module, you can use the ENTRY parameter to start the display from the middle of the module, at the entry point, and go on to the end, rather than starting at the very beginning of the module, and going to the very end. There are times when you will just want to use the ENTRY parameter, and after doing that, you might then want to look at the beginning of the module as well, so you'll then invoke LISTMOD without the ENTRY parameter, to see what's at the beginning. At this point, I have to interrupt in order to explain how to capture the LISTMOD output, and how to scroll up and down. LISTMOD, for a large load module, might have hundreds of thousands of lines of output, so you really need a way to capture it. The nice thing is that LISTMOD puts out its output to the terminal using PUTLINE, so the output can be displayed by TSO-in-batch, or it can be captured by OUTTRAP (in REXX) or SYSOUTTRAP (in CLIST). On CBT File 994, I have included the four "outtrapping tools" from Mark Zelden, called TSOE, TSOV, TSOB, and TSOR. These tools allow you to trap the LISTMOD output, even if it is many thousands of lines long. And then you can see all parts of a load module, scrolling up and down wherever you want. You can go top to bottom and back, or to anywhere in the middle. To use these viewing tools, for example TSOV, you just have to say: TSO TSOV LISTMOD modname and you'll get a fullscreen display (in this case, with ISPF VIEW). TSOE uses ISPF EDIT, TSOB uses ISPF BROWSE, and TSOR uses the REVIEW command from CBT File 134, which can also be run without ISPF, in TSO READY mode on the screen. In this way, you get a nearly instant view of entire load modules, scrollable. There is one drawback to the way LISTMOD works, which at the time of this writing has not been remedied yet. There is both an advantage and a disadvantage to the way LISTMOD works. The advantage is simplicity. You just name the name of the load module, and LISTMOD displays it. The disadvatage is twofold: First, you have to have the module in some place which is allocated to your TSO session, so LISTMOD can LOAD it. For example, you may have to first TSOLIB to the load library which contains the module, before running LISTMOD. And second, you don't know which copy of the load module you are looking at. You get the copy that the system "finds" for you. This is because LISTMOD works by doing a LOAD of the module into your session's storage, unless it is an LPA module, in which case it gets the address of the module from the LPDE (Link Pack Directory Entry). The way LISTMOD is currently coded, the LOAD is not a "directed LOAD", but it is an "ordinary" LOAD, which uses the system search path to find where the module is. In order to look at the copy of the module that you may really want to look at (if it isn't the standard copy), then you have to go through a few hoops to get that library allocated to your TSO session, so that the search for it is first. TSOLIB is helpful in this regard. So, other than showing you illustrations of some of the programs and TSO commands mentioned here, we have come to the end of the discussion for now. Since this is not being published in a magazine, as most of my other articles were, we don't have a space limitation concerning illustrations, so I can now show you quite a few outputs that are produced by the commands and programs mentioned here. For now, we wish all of you the best of everything, and we hope to see you again in this space, the next time. ILLUSTRATIONS Figure 1. Output of LISTMOD for the LISTMOD load module (abbreviated). Please note the contents of the header. Afterward is shown a LISTMOD of IEFBR14, which is in LPA. TSOV LISTMOD LISTMOD Loaded Program Name: LISTMOD ----------------------------------------------------------------- Module has been LOADED. CDE Address: 009AC600 Length of loaded module Hex: 00001530 Decimal: 5424 Length after entry address : 00001530 Decimal: 5424 Displacement of entry point: 00000000 Decimal: 0 ----------------------------------------------------------------- 00 LISTMOD - 09/19/19 - 11.54 } & && } &\ &}\ k 00000000 4FF21DCEEDDC464FF6FF6FF464FF4FF4409ED01C45CF45501E4DC05EC05DE094 7002C39234640000911911900011B540000C0C8F10FF10018D10B800BC000820 ---+---+---+---1---+---+---+---2---+---+---+---3---+---+---+---4 DKG E Dk .K < .K 0 < K U