MVS TOOLS AND TRICKS OF THE TRADE MAY 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. IF IT AIN'T BROKE, DON'T FIX IT Everybody knows that it's often difficult to write an Assembler program of any complexity, and most of us know that it sometimes can be even harder to debug it. The same holds true if you're programming in other languages. Writing error-free code takes a lot of effort, and usually, you don't want to make that same effort twice. So once you've been able to successfully complete a piece of error-free code, that's a real accomplishment, and you'll (of course) want to save and preserve the result. This holds true for commercial vendors too. Let me tell you an example. I once had the privilege of developing a piece of code that (in the wrong hands) had the potential of creating a serious security vulnerability in tape processing. My own code could detect the situation which I myself created, but I wasn't sure that there existed any commercial code which could also figure out that something was suspicious (with the tape). So in fairness to the public, I contacted a vendor of such software, and apprised them of my code and what it could do. Their answer was a bit of a shock to me. They told me that the code in their product was 25 years old, tried and tested by the whole world, and they were afraid to mess with it, to have to deal with such a far-out situation. Also, it was designed to deal with ordinary situations that occur every day, not with such a strange one. So they didn't want to do anything about the special handling of my special case. When I thought about it, I couldn't say that I blamed them. Sure, my code could do something that fooled their code. But their code was capable of doing its designed job to perfection, which was the reason why most people bought it. And to risk that, just to cover a very minute possibility of potential abuse which probably no one would attempt anyway, was not worth the risk of breaking their tested, debugged, and tried-and-true code. IBM does the same thing. Anybody who ever worked there (or in any other software company) can tell you that programmer time is a very precious commodity. You absolutely do not want to make the same effort twice. So if you've got good code, you don't change it unless you have outside requirements to either fix it or enhance it. I'll tell you one more example, which has to do with IBM. Back in the MVS SP 1.3 and XA days, we used to support a system mod which would put I/O counts into the IEF285I messages (KEPT, DELETED, PASSED, CATALOGED etc.) that describe datasets used by batch job executions, TSO sessions, or started tasks. This mod was very useful, because you could see very graphically, if a dataset was really being used by a job, or not, and HOW MUCH it was being used. The IBM modules affected most by our mod, were IEFAB4B0 and IEFAB4A2 (allocation modules). Until SMS development came along, and IBM started messing with allocation modules in a big way, these two modules were relatively stable, and for 10 years, IEFAB4B0 in particular, wasn't changed at all. One time, I had to make a Level 2 call to IBM, concerning some other allocation modules which had problems. The Level 2 person seemed very knowledgeable with that component, so I asked her if she had ever heard of module IEFAB4B0. She said she hadn't, and I told her why. The module hadn't been changed in 10 years, and there were no problems with it. So she never saw it. It was one of those "huge gobs" of IBM code that "takes its licking and keeps on ticking". In other words, it's good code that keeps working, so no one has any mind to try and change it unless they have to. Therefore, even (some of) the support people didn't notice that it exists. STABILITY AND UPWARD COMPATIBILITY So how does all this apply to us, the MVS systems programmers? What difference does it make? I'd say that in general it is a very good thing for us, that IBM and vendor code does not change too much. It makes for stability and predictability in our working environment. And even when we change operating system releases, we only concentrate on the differences. We don't have to recreate the entire environment over again, because the underlying code has not changed all that much. This is a situation which we all take for granted, and we don't often take the time to think about why all the changes and developments in the system are so gradual. The fact is, that it is quite difficult, and it is usually unnecessary, to rewrite good code. Nowadays, there is also another factor, and that is the increasingly blurred distinction between hardware and software. Software functions are now being used, to emulate hardware functions. And we are increasingly making more and more use of software to do things such as machine instruction emulation. The "software-hardware" is no longer so hidden under the covers, as in IBM microcode, which is really software, but it looks like hardware and we never see it. In either case, once the (humanly programmed) software works correctly, whether it be "real software" or microcode, why should we change it? For example, you can now run MVS on a PC, because of software emulation. IBM machine instructions (if we ignore the current IBM instruction patent fights) can technologically be emulated on a machine that is completely different from the hardware which the instructions were designed for, and therefore, in a strict sense, it is software which is running the instructions, and not hardware. These days, software has increasingly become a replacement for hardware. So again, since this software was initially quite difficult to write (accurately) and required a considerable human effort to develop, once it is there, we have very little temptation to rewrite it, or mess with how it works. Further, you can see that when we write software, we also "build technology". (See my February 2007 column about "Technology Breeds Technology" for a more detailed treatment of that subject.) This means that debugged software, which performs "necessary" functionality that we come to take for granted, becomes part of our environment. And that environment is then used recursively, to either further extend our environment or to do our necessary work that "keeps industry going". So once we are using a wrench to turn bolts every day, we are not going to try to break that wrench each day, and build it anew. It would be far too disturbing for anyone to think about. One of my dear friends who comes from a third world country, describes why the development of his country is severely and unnecessarily impeded. This shows us why OUR situation is so much better, and it makes my whole point. In his country (it is hard for us to fathom this), when a new president comes in, they completely drop all the humanitarian development projects that were started by the previous government. If they feel like it, they start some entirely new and different programs of their own. So in effect, the good works of one government do not last, past the duration of that government in office. And little permanent progress is made. This situation sounds crazy and ludicrous, but it is REAL. IT ACTUALLY HAPPENS THERE! When people tear down what is already good, to try and build it over, or they stop a work that is already in progress and nearing completion, they often are destroying far more than they are building. We have to be very grateful that both system and application software is not normally dealt with, in such a way. GROWTH Now we're coming to the second side of the coin. Of course, it's fine and well that old code, which works, should be preserved. But then there's the second question: "How do we make progress?" And after that we have to ask: "How do we reconcile the two concepts with each other?" I can supply several examples from my "CBT Tape" experience. These will show you the basic idea I want to get across, and you can figure everything else out from there. As most of you know, the "CBT Tape" collection of free MVS software, can be found at our web site by doing a www.google.com search on "CBT Tape" and looking at or near the top of the resulting list. In the CBT Tape free collection are some very amazing software programs which started relatively small, and which grew both in functionality and size, quite amazingly over the years. The original code in these programs was not (for the most part) destroyed. It was added to and enhanced, with dramatic results. One of the programs I want to talk about is called REVIEW. REVIEW is a TSO-based file browsing command that was written originally by Bill Godfrey around 1979 or so. Bill has told me that he intended (at the outset) for most of his creations to be added to, eventually, by others. This has happened, and his wish has been abundantly granted. Bill's TSSO program (CBT Tape File 306) has been added to by Marc Schare, Dave Cartwright, Ed Jaffe, and others, and it has grown from being a console-mode TSO substitute, to being an Automated Operations tool, and much more (CBT File 404). Bill's REVIEW program has grown from being a basic 4000-line sequential file browser program to being a 50000-line jack-of-all-trades file looker, with an ISPF-like editor added on, an SMF record and LOGREC record interpreter, and many more exotic features. Greg Price has been responsible for most of the improvements to REVIEW, and he has produced most of the 46000 or so extra lines of code which have been added after Bill Godfrey's initial work. REVIEW is the only program I have, which will accurately browse the (keyed) SYS1.BRODCAST dataset. ISPF Browse counts the first character (the key) with the data, and drops the last character so you can't see it. REVIEW does it right. (Yes, DITTO does it too, but not as conveniently.) Greg Price did not abandon Bill Godfrey's REVIEW code. Instead, he built on it and enhanced it, in ways not dreamed of. Actually, Greg sent his (already hugely enhanced) REVIEW program into the CBT Tape collection (to Arnie Casinghino) in 1989, 10 years after it was originally written. I myself, had been tempted to start enhancing REVIEW before then, but once I saw what Greg had done, I realized that I could never equal his accomplishment. And Greg has still been working on REVIEW ever since then. REVIEW can look at VSAM files and HFS files and all kinds of other "MVS things". Source code is on CBT Tape File 134, and load modules are on File 135. Bill Godfrey had also originally written a full screen TSO HELP program, called HEL, to look at SYSHELP files in full screen, based on the REVIEW code, and Greg Price merged the HEL code into the REVIEW code so they both could be enhanced together as one program. HEL is now an ALIAS of REVIEW, and it is an enormous aid in reading a long TSO HELP file. HEL (instead of TSO HELP) allows you to scroll up and down the file, which regular TSO HELP (being a line-mode command) does not. My point is that Greg Price did not destroy Bill Godfrey's tried and tested code in REVIEW. Instead, he enhanced it and built on top of it, so that the "basic engine" of Bill Godfrey's could be made to do more. When IBM enhances a product, they tend to do the same thing. I often look at old IBM source code for TSO modules, and I compare it to the current code (OCO of course) for the same modules. I usually find that the original principles and coding have not been changed. They have only been adjusted a bit for modern times, and tweaked. One more enormously improved utility package that must be mentioned here, is the "PDS Utility Package" which I have used, even back in the MVT days. "PDS" was originally writted at Firemen's Fund to look at a partitioned dataset and perform a limited number of functions. See Figure 1 to see the original list of its options. The modern "PDS package", versioned PDS 8.6, is still free, being maintained by John Kalinich, and you can find it (together with the original version) on CBT File 182. There is also a commercial product called "Startool FDM", now owned and marketed by Serena, which is an outgrowth of the original "PDS" product as well. Both of these products have thousands of separate functions built into them. How did this happen? It came from an idea by Bruce Leland, who tried to add functionality to the original PDS code. Bruce told me that he spent a year studying the PDS source, until he understood it well enough that he felt he could make meaningful changes. But once Bruce made changes (without destroying the original engines, of course), they started to come by the dozens. Bruce was soon joined by Steve Smith, who made an ISPF interface for the product (which still works both in ISPF mode and in TSO line mode). When Bruce was offered the opportunity (by Serena) to extend "PDS" into a commercial product, Steve Smith joined him, and together, they enhanced the package for over 10 years. When Y2K threatened its big ugly head meanwhile, John Kalinich picked up the free version (which hadn't been changed since 1989), and John has been adding more features to the public version ever since. You see from this that enormous enhancements can be put into a product without destroying its original mechanisms. If it ain't broke, you (usually) shouldn't try to fix it! SUMMARY Debugged code which works, is hard to duplicate. The effort that would be spent in rewriting perfectly good code from scratch, is usually wasted effort. Therefore, most good code gets saved and reused. This is generally a happy thing for us, because the MVS operating system, being largely based on old code which always has worked, doesn't change too fast, and we can use most of our old experience, in our job of maintaining it. When enhancements ARE made to old code, they usually do not destroy the basic "engines" which were put there by the efforts of the original coders. If these engines do their work well, it pays to preserve them. If they do not, then we are forced to rewrite them, but ONLY then. We can always try to alter these "facts of life" and rewrite existing functionality anew, but I think that we need a good reason to do so. Learning new techniques, in my opinion, counts as a "good reason". So does "machine inefficiency", if it applies to a particular case. In general, though, it pays to build new technology on top of existing good technology. If it ain't broke, then don't fix it. I hope you have profited from this month's piece. At least I hope that it has made you think a bit. Please come and visit this column again next month. I'll be looking forward to seeing you. * * * * * * * * * * * * * * * * * * * * * * * * Figure 1. Options available with the original PDS program to manipulate pds members. This is from before Bruce Leland and Steve Smith (and John Kalinich) got a hold of the program. After the PDS command is pointed at a dataset, you have the following choices: THE FOLLOWING OPTIONS ARE AVAILABLE: DISPLAY - DISPLAY DIRECTORY RENAME - RENAME A MEMBER SCRATCH - SCRATCH A MEMBER ALIAS - ASSIGN AN ALIAS TO A MEMBER ATTR - LIST LOAD MODULE ATTRIBUTES MAP - MAP STRUCTURE OF LOAD MODULE HISTORY - LIST HISTORY OF LOAD MODULE LIST - LIST CONTENTS OF A MEMBER USAGE - LIST DIRECTORY STATISTICS CHANGE - SELECT A NEW DATA SET OPTIONS - DISPLAY THIS MENU HELP - DISPLAY HELP TEXT