MVS TOOLS AND TRICKS OF THE TRADE July 1997 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. OLD CODE -- OLD GOLD This month I'd like to provide some insight into what's been happening to MVS (or OS/390 if you will), from a perspective that you may not have seen elsewhere. I know that there is an undercurrent of opinion among systems programmers, who will see the point of this. I feel extremely strongly that what I'm going to say, has to be said. My teacher Howard Gilbert used to state that the development of MVS is not logical. MVS can only be understood by studying its history. The fact is that IBM developed OS/360 around 1964, and only kept changing it because of the requirements of its customers, usually the largest ones. Therefore, the structures and parts of (OS/)MVS have progressed and grown from what has been there before. A result of this fact is that those who understand MVS best, usually are experienced systems programmers who have followed this operating system through many of its previous stages. For example, you can only REALLY understand SMP/E if you know what the old System Generation (SYSGEN) process was. On top of that, you have to know how a PTF used to be applied to the system by using a piece of the SYSGEN Stage 2 deck as a model. Only then can you understand what SMP was created for. (Its purpose was to automate this process.) And only then can you begin, with real understanding, to make sense of the strange and unique control commands that inhabit SMP/E today. The same thinking applies to all components of MVS. You only really get the idea of what's happening in them, if you knew what was there before. This is not to say that components of MVS can't be rewritten. They sometimes are. It's just that because of its large customer base, IBM has made it a policy to usually make a new version largely compatible with what was there before. MVS also contains millions of lines of highly debugged code, and it is hard to justify spending many programmer hours to rewrite what already works. Therefore, if it "ain't broke", IBM doesn't bother to fix it, unless there's a need. What's been "fixed" or changed, is usually mentioned in the MVS Conversion Notebooks for each new release. Therefore, unless we're dealing with components of MVS that have (necessarily) changed, old system code should still largely work, even today. It comes out as a conclusion, that we can profit by studying old code. In many cases, we can still use the code, as is, (perhaps with reassembly to account for changes in system macros), or with some modification, if it hits system components that were changed, such as UCB lookups, for example. Another conclusion is that old system code can still tell us how many parts of MVS work. The actual fact is that the old programs will tell us how a component used to work, but a lot of times, it still works the same way. If you study the MVS Conversion Notebooks for the various system release levels, you'll see what doesn't work the same way. Probably (much of) the rest of it, does. I'd like to say one more thing before we get to today's topic. It seems to me that many installations today do not see the need for educating their system programming staffs, as much as used to be. SHARE and GUIDE attendance has dropped off. And even if attendance to these marvelous system programming "schools" (which is what SHARE and GUIDE are) has risen a bit, very recently, it isn't near the levels of six or seven years ago. To me, this reflects apathy on the part of computer installations, that staff creativity and knowledge will not show up on the bottom line. My experience is that I was always able to save my installation a lot of money after each of the ten or so SHARE conferences I attended. WHERE DOES OLD CODE COME FROM? The OS, MVT, and MVS worlds have benefited incomparably from a proliferation of free software that is available, in source form. I think that a comparison to the IBM PC software situation will shed light as to why this is so. To develop PC software, all you need is your own PC, which usually sits in your own house or apartment. If you develop software on your PC, it's yours to sell or give away, as you please. No one can stop you from doing what you want with your own software. To do comparable work on an MVS system, you've (historically) had to work at a multi-million dollar computer installation belonging to a large company or government department. This installation is not yours. Any person who owned an MVS site was usually not the systems programmer there. It follows that if some useful software was developed by a systems programmer at the Continental Widget Corporation, that company, which was more interested in selling Widgets than software, couldn't really care less about what that software could do, except as it affects its Widget production or sales. The programmer would seldom get any personal recognition from the company for skill in programming. The programmer usually could not market the software, if, for example, it was created for a company project on the company computer system. On the other hand, the company would not care about the programmer giving away the software, as long as a competitive Widget company couldn't use it directly to compete. An incentive for giving away the software for public use, would be that you could get somebody else's software for your use. You could also have the benefit of using someone else's skill, or different configuration, in debugging your code. Thus, the development of collections of high quality free software flourished in the MVS world. One of the premier collections of free MVS system software is the CBT MVS Utilities Tape that was started by Arnold Casinghino at the Connecticut Bank and Trust Company in 1975. Arnie maintained the collection through fifteen years and 321 version levels, until 1990, when it had to be given to someone else's care. As of this writing, the current level of the CBT MVS Tape is 414, and the tape continues to be updated with new code. The CBT MVS Tape is independently produced and is available from several sources, one of which is NaSPA. When the CBT Tape overflowed an uncompressed cartridge after level 404 (3158 feet at 6250 bpi), its proprietor started an overflow tape, so that any deleted code would continue to be available to the public. It seemed unproductive to distribute 370 feet of software as a separate tape, so more old code was added to what became the CBT Overflow Tape. The CBT Overflow Tape (now at level 413 to parallel the regular CBT Tape as much as possible) additionally contains the German, Swiss, UK, and Australian G.U.I.D.E. tapes, the entire SHARE MVS Tape (which was discontinued by the SHARE MVS committee), and all the material from the SHARE "ISPF Smoke and Mirrors Tape", which never got off the ground at SHARE. Other old code was also put on the CBT Overflow Tape. The CBT Overflow Tape may be obtained through the NaSPA office. After CBT MVS Mods Tape (as it was then called) level 249, dated July 1985, Arnie Casinghino performed a series of deletions because the tape was getting filled up. In order to ensure the continued availability of this material, Arnie deposited a copy of level 249 with the Share Program Library Agency (SPLA), now at the University of Miami in Florida. CBT Tape level 249 is a classic source of old code, and I always keep a copy of its documentation available to read. You can get a copy of CBT Tape level 249 by calling Fred Robinson at SPLA, 305-284-6257. This tape is not currently available through NaSPA. And what about IBM's old code? There are the IBM source tapes, known as Optional Materials for MVS components. I'd like to say a word about these. In the old days (i.e. MVS/XA and before), almost all of the base-level source code, in assembler language or compiled PL/S code whose output was assembler code, was available on tape. The installation only needed to order a set of optional materials tapes to get a complete set of source code. In addition, there was microfiche to show the PTF-fixed assembly listings. You could see how a module worked by looking at the code. For OCO (object code only) modules after 1986 or so, this service was no longer available. Now, only non-OCO modules are distributed by IBM in this way, with source available. For the rest of them, you couldn't see source code. There is now a facility on IBMlink to view source listings for products you have a license for. This helps, even though it's online and it's slow. The advantage is that quite a bit of source for OCO modules is now available to licensed installations. I personally have my way of dealing with IBM source code on tape. The source listings come in IEBUPDTE-unloaded files, component by component. Internal macros which were used by the component's developers, but which haven't found their way to a system macro library such as SYS1.MACLIB, are also included in this source, usually in a separate file. You can usually spot such a macro file by the fact that its members have widely different names, instead of IEFAB4A0, IEFAB4A2, IEFAB4B0, etc, whose names are similar to each other. These internal macros are referred to as IBM Private Macros. For each release of MVS, I try to make a library of all of the private macros I can accumulate from their Optional tape files. Then, I can assemble any module I want from the source, by concatenating the private macro libraries with the system macro libraries to obtain a clean assembly. When I have a documented, clean assembly listing, understanding how a module works is much easier. However, you can't do this with OCO modules. But you can take an older version of the module (from XA or MVS/ESA Release 3) which wasn't OCO, and assemble it. Then you can compare the assembly listing, and its documentation, with the existing module, and track the differences. How to do this is not in the scope of the present discussion, but if you have a little experience, you'll see that this idea is useful. Although there are other sources of old code, the ones mentioned here are vast enough to whet the curiosity of the most ambitious reader. The CBT Tape documentation (File 001) and CBT Tape File 071 list documentation for some other tapes and sources of code as well. You've got a lot of old code to look at. SOME EXAMPLES - OLD COMPILERS By now, you're probably anxious to see some useful things which can be done with old code. I'll show you a few examples. One of the first pieces of old code which comes to mind, are IBM's old language compilers. Once upon a time, all of IBM's OS software was free. This includes all of the language compilers which were available at that time: PL/I, FORTRAN, RPG, and ALGOL, among them. Just before OS/MVT was being replaced at his site, Jim Marshall (then of the U.S. Air Force) saved as many of the compilers and libraries as he could. These were donated to the SHARE MVS Tape (now contained in the CBT Overflow Tape) and the CBT MVS Tape. I was once doing some contracting work on a very old system, and I found a copy of the old OS/360 ALGOL compiler and library there. I donated those to the CBT MVS Tape as well. It turns out that all of these compilers, with one glitch that was fixed, run quite well on MVS/XA and MVS/ESA systems. Therefore, if your shop happens not to have any RPG, or FORTRAN, or PL/I, you still have the option of installing old versions of these, and trying to compile your progam source to run under them. Some of the manuals may still be available from IBM, although I can't guarantee anything. IBM's publications phone number is: 1-800-879-2755. Let me tell you about these compilers. PL/I F load modules are on File 092 of the CBT Tape and on File 119 of the SHARE MVS Tape (which is File 219 of the CBT Overflow Tape). It was reported at the outset, that the compiler and library had an occasional abend on XA (same for ESA), which resulted from a fetch error, because the linkage editor for those modules was so old that XA program fetch had some trouble loading a few modules into storage properly. The problem was solved by Larry Williams, who re-linkedited each load module, expanding every CSECT by 8 bytes. This forced the new linkage editor to "re-think" the entire linkedit process, adjusting the RLD counts, etc., so that the XA or ESA program fetch component would no longer have trouble loading these modules into main storage. The problem was solved, and the PL/I F compiler and library works perfectly now. The updated load modules are on the CBT Tape (File 092), while the non-updated modules are on the CBT Overflow Tape, File 219, if you need reference to them. Let me tell you how this process was done, just to show you the advantage of knowing how to use public tools. You can take any load module, and instantly generate the JCL to re-linkedit it, using the PDS TSO command from File 182 of the CBT MVS Tape. The PDS command has been further developed as a vendor product (called STARTOOL, from Serena International in Burlingame, California), but for this purpose, the free version will do the job, as long as the load library is not a PDSE. The PDS subcommand which generates the JCL is: MAP modname RELINK. However, you don't have to restrict the module name to one module. You can describe a "member subgroup" of modules in a zillion different ways, referring to the defined subgroup with an asterisk in place of the member name, or you can refer to all modules in the library, by using a colon in place of the member name. Thus, if you point the PDS command to the PL/I compiler and library pds, you can generate a complete re-linkedit JCL stream with the simple command: MAP : RELINK. Larry did this, painstakingly adding "EXPAND csectnam(8)" cards for all the CSECTS and running the resulting linkedit JCL job stream. Neat, eh? The copies of all the other compilers and libraries on the CBT Tape, which never showed problems on XA or ESA, were all re-linkedited with the DFSMS linkage editor. The compilers in their original form can be found on the SHARE MVS Tape, and therefore also on the CBT Overflow Tape. Thus you have the original and modified modules to work with yourselves, as you see fit. FORTRAN G and H is found on File 326 of the CBT MVS Tape, re-linkedited by Rick Fochtman. The original version of FORTRAN G and H is on File 218 of the CBT Overflow Tape. Vanilla OS/360 FORTRAN H is on File 232 of the CBT Overflow Tape. OS/360 RPG, relinkedited by me, is on File 327 of the CBT MVS Tape, and the original version is on File 231 of the CBT Overflow Tape. OS/360 ALGOL is on File 176 of the CBT MVS Tape. OTHER EXAMPLES. I'll give a few other examples of old code that's useful. All of us old-timers probably remember IBM's core-zapping tool called INCORZAP. INCORZAP will zap the virtual storage copy of any Nucleus or LPA module. It takes AMASPZAP-like control cards, looks into the disk copy of the module to find the correct CSECT structure, and then goes to the in-core copy to do the VERify and REPlacement operations. In OS/MVT or MVS/370, this worked fine. However, in MVS/XA or ESA, where there is fetch-protected storage and read-only NUCLEUS, INCORZAP will not work to modify those areas of main storage. It turns out that there's a charming story here. INCORZAP, originally written in PL/S at IBM around 1972, was disassembled into assembler code by Bill Godfrey around 1980 and put on the CBT Tape by Jim Marshall. The original author of INCORZAP, Robert Budge, who no longer worked for IBM, and no longer had access to the PL/S compiler, was looking through the CBT Tape around 1983, and saw Bill Godfrey's source for his program, now in Assembler source code. Budge, who wrote the original program, and who knew all the logic, was able to modify the assembler source to turn off page protection in the affected read-only and fetch protected storage. The resulting product, called XACORZAP, can now be found on File 421 of the CBT Tape, along with a user manual, written by Robert Budge. Now what does this mean for us? If you have to fix some old code, to turn off page protection, you can take an example from the source code of XACORZAP. Original INCORZAP is on File 316 of the CBT Tape, and you can track the source changes that were necessary. An example of such code borrowing, is the XA version of DYNABLDL, which had to modify the copy of module IGC018 in read-only nucleus, as compared to the original version for MVS/370 and before, which didn't have the problem. Both versions of DYNABLDL code can be found on File 407 of the CBT Tape. This is a good study example for you. A third example would be a program which accesses the APF list of authorized load libraries. The format of the APF list was changed in MVS/ESA Version 4, to be dynamically modifiable without an IPL. Code to access the APF list in the new format can be found in SHOWMVS by Gilbert Saint-flour, in File 183 of the CBT Tape. Thus, if you have to modify code that currently accesses the APF list in its old format, you can use SHOWMVS as an example to follow. I hope that this month's talk has proven stimulating and informative for you. If you have a systems programming job to do, it may pay to explore old code. You may find it to be Old Gold. See you next month.