MVS TOOLS AND TRICKS OF THE TRADE JUNE 2001 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. FIGURING OUT THAT MODULE Any practitioner in our field of MVS installation and support, has a lot of experience in growing. The maintenance of the MVS operating system requires of its practitioners, to be constantly learning new things. It's hard enough to learn the basics of how MVS works, and the functioning of its many components. Add to that: UNIX services, web enablement, connectivity to other systems, TCP/IP, and a dozen other new areas. The result is a challenging mountain climbing experience in learning, that we all have to face. Today, I'd like to look at personal growth directions in supporting MVS (i.e OS/390 or z/OS) that are more basic. As a member of the "old school" in this profession, I want to look at directions and methodologies that bring out the hacker in us. We're all driven by the questions: "How does this work? What makes it all work?" Many of those questions stay in our heads for years, before we begin to acquire tools that will help us get answers to them. My perspective tells me that the MVS operating system is so vast, that we'll never find out answers to most of our questions of "how does this work"? We are simply very happy that it all does work. (The rest is IBM's problem.) Nevertheless, we can acquire a thinking methodology that will help us get these answers in a specific case, for one or more specific modules, and to solve a specific problem. If one system module doesn't work, we will be able to find out why. And furthermore, we will be able to get a better insight into the workings of that particular module, than IBM would care to provide to us. RUSSIAN TRAINING Political considerations aside, I would like to make a statement whose implications can help all of us become better systems programmers. I have endless admiration and respect for those Russian programmers who had to keep their OS/360 (and later) systems running, with no outside support at all. With the Cold War over, many of them now live and work in the United States. I have talked with quite a few of these people. Their training conditions were extremely tough, and these people successfully endured those conditions. In my opinion, such people can function as the backbone of any computer installation's support, anywhere. I was talking to one such person yesterday. I mentioned to him, that another Russian friend of mine wrote a clever and useful MVS disassembler program, because in Russia in the 1980's, "we didn't exactly have access to the IBM Support Center" (to quote his words). This (second) person answered me, that he wrote many disassemblers in his working life, for many different operating systems, and in his current work, he "can't live without them". That is just a glimpse of the caliber of expertise and skill we are talking about. It all comes from their old environment, the daunting conditions they had to face, and what they were forced to do, in order to cope and triumph. We can all learn from the old Russian challenges. This article is for us, not for them. I am here to add my own experiences to theirs, and to outline some directions in thinking, which can eventually make all of us (also including me, perhaps) into powerhouses of MVS internals knowledge and diagnosis skill. "RETRO COMPUTING" WITH HERCULES. Our field sometimes takes odd twists. Many of us "old timers", including me, have saved copies of many versions of the OS/360 and MVS operating systems, over the years. We didn't fully know what we'd do with them, but the universal motivating factor for doing this, seems to be, that we'd eventually need some of the knowledge. The MVS system is built on what was past. Most MVS structures seldom become completely obsolete. So therefore, we certainly have the instinct to feel that the knowledge we've acquired and saved from the old systems, will help us later, to better understand what is new. Now add to this scenario, that there is currently a burgeoning movement to get old OS/360 and MVS 3.8J systems running. That is truly a surprise. Five years ago, no one would have dreamed that such a thing could happen at all. The twist here, is that these old operating systems can now be set up, for free, on your home Personal Computer. There is a new, free System/390 hardware simulator named Hercules, which runs on your home PC, under Linux or under Windows. Actually, Hercules has the "smarts" to run OS/390 Release 2.10 on your personal computer at home. Hercules is free. However, OS/390 is not, and its licensing costs have to be negotiated with IBM. Therefore, most "home MVS systems programmers" have to content themselves with running versions of MVS which don't cost money. So we now are seeing a big movement toward getting very old versions of MVS running sucessfully. How does this development help us, to do our regular jobs? One answer is that old MVS 3.8J source code is now more widely accessible and available. As I mentioned in this column a few months ago, we can look at the commented old assembler code, compare it to newer versions, and better figure out how the newer code works, when it is giving us a problem. Also, by getting involved in running "old MVS" at home, we can sharpen our skills immensely, in solving our problems at work with the current MVS systems. So if you want to learn more, and find out about Hercules developments, there is a Hercules news group. Its current relevant URL's are: Subscribe: hercules-390-subscribe@yahoogroups.com Post message: hercules-390@yahoogroups.com DIGGING INTO MODULES Most of us investigate a system module on an "as needed" basis. And most of our system problems, at the module level, are taken care of by the respective vendors. For example, tape management hooks into the MVS operating systems, are fitted into the IBM system modules by the tape management vendor. We usually don't have to worry about fitting them ourselves, or figuring out where they should be inserted into the IBM modules. That's the vendor's job. So when can we get such practice? Usually that happens when we have locally developed system modifications, and that depends on the shop. However, sometimes you can second-guess the vendors, and do things like figuring out why the tape management system hooks go where they do. If you understand that, you'll really gain some insight into how tapes can be managed. My main point is, that if you can do some module surfing, and you gain some knowledge of a small piece of the system, it'll give you a deeper and better "general idea" of how the whole thing hangs together. You will be a better systems programmer as a result. SOME ANCIENT EXPERIENCE I think it is worth mentioning some of my past experience in figuring out how a few system modules work. The modules concerned, are allocation modules. And in case you don't know, much of the allocation code in MVS is lumped into a humongous load module, containing hundreds of csects, called IEFW21SD. Load module IEFW21SD resides in LPALIB. The modules I worked on, are called IEFAB4B0, and IEFAB4A2. These, and related code, produce those nice IEF285I messages in the MVS Job Log, telling you whether your dataset was KEPT, CATALOGED, or DELETED. Our modification (largely developed by Charlie Pitts) to module IEFAB4B0 added some information to the IEF285I messages, namely, counts of the EXCPs that your job used, to write to, or read from, all the datasets that it allocated. The modification was so good, and it was so "close to the system action", that the EXCP counts even showed up for the dynamically allocated datasets that were grabbed by your TSO session. All this was before SMS (System Managed Storage) stuck its ugly changes into the allocation modules, and made it hard to keep up with what we had to modify. After MVS/XA 2.2, we had to give up. Nowadays you have to use SMF exits to get the equivalent information into the Job Log, and they're ok, but they're not as good as our original mod. IBM never directly supported these changes that we made to the system. But as long as we supported this mod, I was able to get a pretty good idea into the workings of modules IEFAB4B0 and IEFAB4A2. And seeing those EXCP counts in our jobs, sure was helpful and nice! You can see these old modifications to the operating system on File 369 of the CBT MVS Tape collection. I had to refit the modifications to several versions of the system, including one in which I had no access to the "source code microfiche" of IEFAB4A2 and IEFAB4B0 that IBM gave out. I actually worked from a disassembly of these modules, and I still successfully figured out how to make the changes. Now, I'll talk about a few of the details. I hope that some of the spirit of what we were doing, will get across. ASMTOZAP AND NITTY-GRITTY Howard Gilbert (of Yale University) once wrote a marvelous PL/I program that converts specially constructed Assembler code, into module zaps in AMASPZAP input format. Howard's program is called ASMTOZAP, and you can find it on File 044 of the CBT Tape collection. There is also a PL/I F version of ASMTOZAP, which you can run, for free, on any MVS system, even if it is not licensed for PL/I Optimizer. Load modules for both versions of ASMTOZAP are on File 035 of the CBT Tape collection. The idea of ASMTOZAP is that you don't have to code the SPZAP VER and REP statements to make a system module modification. You just code Assembler language code, assemble it, and get the listing. The ASMTOZAP program reads that assembly listing file, and creates the SPZAP input for you. If you're doing a complicated modification, ASMTOZAP makes it much easier to code and maintain the source for the mod. Please see Figure 1 for an abbreviated sample of ASMTOZAP source code, with its *ZAP CARD , *ZAP START VER , *ZAP START REP , and *ZAP END control cards. When coding the ASMTOZAP Assembler source code, you ORG to the places you want to start modifying. Then you place the VER code after the ORG, if you're after a "START VER" control card, or if you're after a "START REP" control card, you place the new REP code after the ORG. A *ZAP END card stops the generation of SPZAP control statements from the assembly listing. Figure 1 gives you the idea. Our allocation module modifications were in ASMTOZAP format. I don't have space to discuss ASMTOZAP further here, but again, you can get a considerable idea of how it works, by looking at Figure 1. Now, I'd like to explain how I was able to refit our old zap, across a rather sizable change to the IEFAB4B0 module. How does module IEFAB4B0 work? IEFAB4B0 is called by IEFAB4A2, and, at the MVS/370 and MVS/XA system levels, it actually produced the lines of IEF285I messages for the Job Log. Our modification to IEFAB4B0 actually had to go back to its caller's registers, to point to the control blocks where the I/O counts were being kept. After having extracted those counts, our modification then stuck them into the IEF285I messages. At some point, shortly before the onslaught of the SMS-based changes to IEFAB4B0, IBM added a new workarea to the module, and without source code, I didn't know if that workarea interfered with our zap code. Using a disassembly, I followed the workings of the module from the beginning, and watched as the workarea got filled. There were a lot of STore instructions to displacements off R9. So I saw that R9 was pointing to the new workarea and a lot of stuff was being put there. I could even map the layout of the information in the area. But I also saw that IEFAB4B0 didn't use the materials in this workarea, until after our zap code had finished doing its job. So I was safely able to fit my zap, and our code continued working at that company for another eight years. (They never went to ESA.) I hope these thoughts have provided some stimulation, and I'm sure that we can all gain from these ideas. Take care, and have the best of everything! I hope to see you again next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. Abbreviated ASMTOZAP Source Code for a System Zap This is a "snipped" example of some ASMTOZAP source code, which is assembled. The assembly listing gets converted into SPZAP "VER and REP" input by Howard Gilbert's ASMTOZAP program. The full code can be found on CBT Tape File 369, member LM02301A. (Generate card images) *ZAP CARD ++ USERMOD(LM02301) /* I.O COUNTS IN IEF285I */. *ZAP CARD ++ VER(Z038) FMID(EBB1102) PRE(JBB1326). *ZAP CARD ++ ZAP (IEFAB4B0). *ZAP CARD NAME IEFAB4B0 *ZAP CARD EXPAND IEFAB4B0(128) LM02301A CSECT IEFAB4B0 DS 0H PRINT ON,GEN,DATA ORG @PSTART USING *,@12 USING @DATD,@11 *ZAP START VER (Start to generate VER statements( ORG CLRKEY (Go to location equated below) STC @02,@OLDKEY (Verify the code that's there.) ORG CLRTXT (Go to location equated below) MVC MSGBUFFR+1(73),MSGBUFFR BLANK ENTIRE BUFFER ORG STEAL (Go to location equated below) MVI MSGDISP+1,C' ' DISPLACED INSTRUCTION ORG @EL00001 (Go to location equated below) IC @02,@OLDKEY (Verify the code that's there.) ORG @SIZDATD (Go to location equated below) DC AL1(230),AL3(@ENDATD-@DATD) ORG PATCH (Go to location equated below) DC 4F'0' (Verify the code that's there.) *ZAP START REP (Start to generate REP statements) ORG CLRKEY (Go to location equated below) STC @02,@NEWKEY (Modify the code that's there.) ORG CLRTXT (Go to location equated below) MVC MSGBUFFR+1(78),MSGBUFFR BLANK ENTIRE BUFFER * * * * LARGE SNIPPAGE * * * * B PATCH MAINLINE EQU * ORG @EL00001 (Go to location equated below) IC @02,@NEWKEY (Modify the code that's there.) PATEXIT MVI MSGDISP+1,C' ' DISPLACED INSTRUCTION B MAINLINE * EDMSK1 DC X'60206B2020206B202120' *ZAP END (Stop generating REP statements) @DATD DSECT ORG @DATD+X'48' @PC00001 DS 5F ORG @DATD+X'B4' MSGLNGTH DS F DS 2F * * * * LARGE SNIPPAGE * * * * * ***** EQUATES FOR LOCATIONS WITHIN IEFAB4B0 * (These depend on the PTF level of the module) @PSTART EQU IEFAB4B0+X'1C' CLRKEY EQU IEFAB4B0+X'52' CLRTXT EQU IEFAB4B0+X'76' STEAL EQU IEFAB4B0+X'156' @EL00001 EQU IEFAB4B0+X'2EE' @SIZDATD EQU IEFAB4B0+X'3E8' PATCH EQU IEFAB4B0+X'45C' * * * * DATA AREAS * * * * END