MVS TOOLS AND TRICKS OF THE TRADE DECEMBER 2007 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. DISPLAYING MVS SYSTEM VALUES - Part 2 Last month, we talked about the idea of looking at significant system values in an MVS system (z/OS or previous), which determine different aspects of how the system will run. Not only is it important to know about many of the system values connected with the various MVS components, but it is also of great help, if you can figure out how the system itself gets to access these values. Either way, the more you can find out about the contents of MVS control blocks and control values, the better you'll be able to get the most out of your MVS system. It is true that in being an MVS systems programmer, the emphasis is more on "looking at the system" than on "changing the system". And if you have tools (such as the free "SHOWzOS" or "SHOWMVS" tools we mentioned last month) to look at the current values in an MVS system, you've done 70 percent of the work. Nevertheless, once you've seen "what is going on", and you have a tool to CHANGE some value, the possession of an arsenal of such tools gives you a flexibility that can help your shop get more work out of the system. But this flexibility must come with knowledge. Making a system value "more wrong", without knowledge, can be just as easy (and far more damaging) as making that system value "more correct". IBM has made it much easier to change certain system values without an IPL in recent years. Many adjustments can be made to many system values, by simply changing a PARMLIB member and by issuing an operator command to make that changed (or new) member "active". We see this with the IKJTSOxx PARMLIB members and the PROGxx and SMFPRMxx PARMLIB members as well as with quite a few others. These can be activated using an Operator SET command. After the PARMLIB member has been made active with the SET command, its new values can usually be displayed using an Operator DISPLAY command. So IBM has, in many ways, made MVS system operation easier, and has made it possible to avoid IPLs, simply by giving us the ability to change certain system values "on the fly", while the system is running, and not requiring an IPL to change those values. In the old days, when more IPLs WERE required to change system values, wily systems programmers worked hard to write programs that DID change these values "on the fly". This would make "the impossible" POSSIBLE, and would allow the sysprog to fix a situation which would otherwise require a complete IPL that might bring the system to a halt in the middle of a workday. This column was originally designed for the purpose of letting people know about such commands and programs that could manipulate critical system values and change them easily and quickly while the system was up. Many of these tools can be found in the free "CBT Tape" utilities collection, at www.cbttape.org. My recommendation is to use the Updates page there first, before going to the "CBT" page. In practice, if you would experiment, sometimes changing a system value would work, and sometimes it wouldn't work. Usually the problem would be that the system did not recognize the new or changed values, and it would still use the old value. Other times (more happily), you COULD get somewhere by altering a system value in machine storage, or on disk. As with any complicated system, each case was different. Systems programmers had to KNOW what to do, in each situation where a (wrong) system value could pose a problem, and you had to do something to set it right. If there existed a tool to change that value, and the sysprog had it in his or her pocket, this would make him or her a "magic worker" to fix the system and save it from having to be brought down. Fixing these types of problems helped the sysprog to earn his or her salary, by keeping the machine up and running during productive hours. For me, it was always one of the thrills of the job, to know that I had saved a production day, on a multi-million dollar machine, from down time or a disaster. DISPLAYING, VERSUS CHANGING, OF VALUES When looking into computer storage, there is a very great difference between DISPLAYING a system value and CHANGING that value. Usually, especially if the value is system-wide in scope, the system values are contained within some sort of protected storage. Otherwise, any non-authorized user could come along and change a value critical to system operation, or corrupt it. If any of you remembers back to the MVT days, many system areas were not adequately protected from user alteration then. "Security by ignorance" was the rule then, more than the exception. But nowadays, MVS systems have much more need to be protected from harm, against much more knowledgeable intruders, or from application or system programmer blunders. The stakes are higher today, and IBM takes protection of the system's "family jewels" much more seriously. So it makes sense that just READING the value that's there, for display purposes, shouldn't require a great degree of authorization, because one should usually be given the ability to determine the state of a machine, or of one of its component parts. But ALTERING system values, of course, must always be done with care, knowledge, and (above all) authority to do so. The systems programmer, when it comes to "authority", is always walking on a fine line. He or she is the "system doctor" who must fix what ails the machine. Denying "authority" to the system doctor will sometimes prevent him or her from doing the job. On the other hand, even though the system doctor can (and should) fix the "system" programs, this person does not generally have the know-how to interfere with the "applications" that are running on the machine, unless the applications people are also watching. So there is some theoretical limit to the system person's scope as well, and also to the "authority" that might properly and fairly be granted to him, her, or them. A given company's "technical management" people, being human beings, might vary greatly in the degree to which they understand the needs of the systems people, or "trust" them in doing their jobs. I have heard of a shop where it took the signatures of ten levels of management just to authorize a PARMLIB change. This is not a joke that someone made up. A real shop (a very large one) actually operated that way! If that were the case, or even if there were lesser restrictions imposed on things like PARMLIB changes, the sysprogs might actually need some extra tools to change control block values, which IBM made "easy to change" through the making of a new PARMLIB member. Management, in that case, simply closed the door that IBM opened. In a pinch like that, or in a similar situation, when production is heavy and you "can't change things", sometimes you have to "change things", and you need the tools to do so. So the systems programmer (at least) needs APF authorization when it's necessary. At least the management has to be understanding enough to grant THAT. And once APF authorization of TSO commands and batch programs has been granted to the sysprogs, it is then up to the sysprogs to make the most of it, each in one's own situation. Therefore, I think it is an "unofficial obligation" on every systems programmer to write, or otherwise accumulate, a set of tools which takes advantage of APF authorization, and which can accurately and consistently alter various system control blocks or control areas, as needed. MORE ABOUT DISPLAYING AND ALTERING If you have gotten used to using a program like SHOWzOS, which we mentioned last month (source can be found on www.cbttape.org UPDATES, File 492), then you see that it is very possible to display many many system values, even if you are not running the SHOWzOS TSO command APF authorized. However, changing any of the values with an incore zapper (I use Greg Price's IMON with the VB option - www.prycroft6.com.au) or with a user-written program, is tricky at best, and you'd better know what you are doing when you try it. For example, I attempted to change the active Broadcast Dataset in an MVS system by zapping a new name into the appropriate place in the IKJEESCB control block (in live storage), and a new volser for the new dataset's location. At first, this didn't work, because before the dataset name, there is a one-byte field containing the length of the name. And that was wrong. The second problem was, that the system does not know if the new "Broadcast Dataset" determined by the new name, and the new location, really exists. And if it does, is it properly formatted as a Broadcast Dataset, with the proper LRECL, KEYLEN, RECFM, BLKSIZE, and internal structure (header record first, and so forth)? When you do a PARMLIB UPDATE(xx) TSO command or a SET IKJTSO=xx Operator command to do a Broadcast Dataset Switch, the system programs verify all that information before actually making the switch. But if you zap the new values directly into core, there is no such validation or verification taking place. So when you change any system values by zapping core, you must either use a specialized program for the purpose (which verifies and validates all the housekeeping necessary), or you must know everything that has to take place in order for the switch to be successful. I was (in practice) actually able to switch the Broadcast Dataset in this way. But I just happen to know a lot of stuff about the control blocks involved, and about the internal structure of how the Broadcast Dataset should be. In another part of the system, I would be as much "in the dark" as anyone else, with regard to the structures and quantities that needed to be changed, in order to make any new system values work, be valid, and be completely consistent with what they should be. So my general rule is as follows. Do not play with system values by changing them unless: 1. You know ALL the quantities that need to be changed in order to make the new values work properly in the MVS system and with the appropriate MVS support programs (in your current release of MVS). OR 2. You possess a program which has been debugged to do all these changes, in a consistent manner with the way (your current release of) MVS works. This is a hard and fast rule. Do not violate it, or you are asking for a lot of trouble! However, if you do want to FIND the control blocks pointing to the system values you want to study, then I would suggest that you study the SHOWzOS source code which does the finding, and trace the path taken by SHOWzOS, using the LOOK program or some similar core browser. Then, once you are sure about how to get to the place you want to see, you might want to write your own display program that displays the control block's system values. If your program's display values are consistent with what SHOWzOS shows, then you can (probably) safely feel that "you got there". After that, you might do the research to properly change some of the values, and you could write your own (probably APF-authorized) program to do just that. THE ART OF DISPLAYING Displaying a number at a terminal, or in printed output, usually involves converting an internal quantity into EBCDIC display characters. In Assembler language, if the original quantity was a number, expressed as fullword BINARY, this usually involves converting the number to packed decimal using the CVD (convert to decimal) instruction, and then using the ED (edit) instruction to display the packed number on a display line in EBCDIC characters. If you don't care about leading zeros in the displayed numbers, you might want to use the UNPK (unpack) instruction instead of the ED (edit) instruction to convert the packed number to EBCDIC display characters. SHOWzOS has a specialized tool to do its number and character displays. This is a macro (invented by Gilbert Saint-flour and his co-workers) called STRING or STRING64 (for the 64-bit version), which is quite complicated, and which does all the number conversions to EBCDIC display characters automatically. You can gain a lot by studying the STRING and STRING64 macro source in CBT Tape File 492. However, if you write a TSO command to display lines of numbers or characters at a terminal, you have to use either of two methods. First is the simple method that uses the TPUT macro. To use the TPUT macro in a program, all you have to do is to put your data into a display line, and then issue TPUT on that display line for a certain number of characters. For example, TPUT LINE,30 which will output the first 30 lines contained in field LINE, to the terminal. This is very simple to code. There is a big drawback to using the TPUT macro method, however. That is, if you run the TSO command under TSO-in-batch, you cannot see the output displayed by TPUT. Also, you can't SYSOUTTRAP any TPUT output. So in order to see terminal output under TSO-in-batch, you have to use another method of displaying it. That method uses the PUTLINE macro, which is much harder to set up and code, than is the TPUT macro. Fortunately, there is a gizmo on the CBT Tape, in File 136, to convert TPUT code to PUTLINE code. Here is what I do, to use this conversion method. The conversion code (from TPUT to PUTLINE) consists of two parts. One part is a macro, called APUT, which takes TPUT-like input and calls the second piece, a subroutine called EPUTL. EPUTL should be linkedited together with your TSO command. EPUTL automagically sets up the entire (complicated) PUTLINE environment. So just add the EPUTL source to the bottom of your TSO command's source, copy the APUT macro source inline to your TSO command source, and change every place where you coded a TPUT, to an APUT. Usually, that's all it takes to convert the TPUT terminal display to a PUTLINE terminal display, and then you can see the output after doing a SYSOUTTRAP or in a printed output display under TSO-in-batch. I hope that this month's piece has made you a little bit wiser, by getting your own brain working in a new direction. Displaying the contents of MVS control blocks is always very instructive, but CHANGING something can be very tricky, because you have to know about all the interrelated values that have been affected by any change in that area. Perform all system value changes with caution, or use a pre-programmed tool to do so, that has already been debugged and proven to be accurate. I wish all of you the best of everything, and I'm looking forward to seeing you here again next month.