MVS TOOLS AND TRICKS OF THE TRADE JULY 2005 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. MVS IS ITS HISTORY Back in the 80s, I always used to complain that IBM never tried to teach MVS to new systems programmers properly. IBM has since addressed the "newbie education problem" better, having come out with a fine multivolume series of Redbooks called "The ABCs of z/OS System Programming". However, the practical problem of training new systems programmers to maintain MVS (which by any other name, is still MVS) is now becoming much more critical every day. The older systems programmers who have all the experience, are retiring, and the working MVS systems are nevertheless very much a crucial component of data processing in the world today. Who is going to continue to maintain MVS, as we go into the future? We have figure out how to bring up the new people, so that they properly appreciate the job they will have to do. What were my complaints about IBM's policies? First and foremost, was the gripe that IBM never would mention in their manuals, where a component of MVS came from, and what its history was. This IBM insistence on only mentioning the newest version of their products, and how their products currently work, may have been justified from the operational point of view. Because after all, the manual should teach you how to run the current version of the product. But in the special case of the MVS operating system, the omission of MVS history left a woeful inadequacy from the teaching point of view. If a new systems programmer would look at an IBM manual to learn something about an MVS component, he or she would often be confused by a maze of unintuitive keywords and terms, which could only be properly understood if you knew where they came from in the past. Many of us old-timers think that the thrust in teaching MVS has to be different, simply because of the way MVS has developed. MVS is historical. MVS has always been built on the past. Anybody who has taken care of MVS for more than a few years, can tell you that without batting an eyelash. Why this specialness about MVS? The reason is because OS/360 was designed and implemented to reach into the future, but in an evolutionary way. Most of the improvements to OS/360. OS/VS2, MVS, MVS/XA, MVS/ESA, OS/390, and z/OS have been customer driven improvements. But the shops which were running the new releases also had to keep running the old programs. The system was always designed with a compatibility and a connectivity to the past. So MVS has always grown from the branches, with most of the roots still left intact. That's why you can't properly learn about the current state of MVS without knowing what MVS was like before. And that's why, in the particular case of supporting MVS, that the old-timers have an almost insurmountable advantage over the newbies. But the old-timers are gradually leaving, and we have to face the inevitable problem of how to bring up the new people. AN EXAMPLE It took me four years to learn SMP4 and SMP/E, IBM's automated system to apply programming changes (i.e. PTFs, APARs, and USERMODs) to MVS. After the four years, I saw in retrospect that with the proper introduction, I could have learned most of it in three weeks. And that was a woeful shame. Nobody took the time or effort to explain SMP to me so it would be understandable. I had to wade through it myself and take the hard knocks, until finally it dawned on me, what was really going on. I determined to remedy the situation by writing a series of three articles for "Technical Support" magazine back in 1988, explaining in a few pages, why SMP(/E) does what it does, and why it is built the way it is built. (You can see these articles today, in File 014 from the free CBT Tape collection that is on the web. Just do a www.google.com search for the words "CBT Tape".) What I did in those articles, and what IBM would not (then) have done for almost any amount of persuasion, was to explain that the whole concept of SMP could not be understood, if you didn't already understand what the SYSGEN process was. And today, we don't even do any SYSGENs at all. The SYSGEN functionality has partially been superseded by HCD, the rest of it is built into the pre-packaged target zones from IBM, and we don't ever get to see it at all anymore. So today, how are we supposed to properly understand what SMP/E is, and how or why it does what it does? Of course, we can learn SMP/E by rote, and "just do" what the manual says. But there's no real understanding there, unless you have a good idea of what's behind the (very elusive) concept of "JCLIN". The word JCLIN doesn't seem to imply much. If you knew nothing about it, the word would suggest the idea of "putting JCL in". An intelligent person would ask: "What is this for? Why should you want to 'put JCL in'?" To explain to the user that the JCLIN process is the very heart and soul of SMP/E processing, was the farthest thing from the IBM manual writers' consciousness. That's why it took me four years to learn SMP/E instead of three weeks. I had to discover this idea for myself. If I had only known that JCLIN was a DD name for input to SMP's predecessor program, AMAPTFLE, that, in itself, would have helped a lot. And it would have helped me to have put in some PTF fixes to MVS the old way, using AMAPTFLE. Had I understood how to do the system fixes the old way, the new way would have made more sense to me. To use the old AMAPTFLE program required, that you had to access (at least) part of the JCL that was generated by Stage 2 of the SYSGEN. That JCL told AMAPTFLE how the particular piece of MVS being fixed, was originally put together. So therefore, had I had some practice using AMAPTFLE, I would have immediately understood the connection between applying the system fix, and the original SYSGEN JCL, inputted by the JCLIN DD name. But the main remedy would have been if the IBM manual writers had thought of simply stating the actual purpose of what JCLIN is for. The IBM manuals on SMP/E should have said: "The reason for the JCLIN input is to tell SMP/E what the structure of the MVS load modules and other components looks like. JCLIN tells SMP/E how to build each part of MVS functionality from its component elements. JCLIN tells SMP/E the "architect's plans" about how to put the MVS system together." If the IBM manuals would have said that, my learning of SMP/E would have taken mere months, not years. But if someone, or some manual, had gone a bit further and taken the time to explain the following historical fact, I would have gotten the correct idea, right away. The idea is, that just the way a SYSGEN puts the whole MVS system together and determines its entire structure, so does the JCLIN tell SMP/E how to insert a partial replacement, or even a complete replacement, into an already existing MVS system. So from this example, you can see how it helps to include a historical perspective, into explaining how a piece of MVS works. CURRENT MVS SYSTEMS LOOK LIKE THE PREVIOUS ONES Imagine this scenario. (Everybody who is experienced, knows that this is true.) Suppose you would be able to patiently go through an IPL of 20 or so successive releases of MVS, one after the other. Each release is one higher than the one before. If you were able to do that, you'd notice that the console messages for each system level do not differ too much from either its predecessor or its successor. For sure, you would certainly notice the differences at each level. (And that's what you're SUPPOSED to notice.) But by and large, the external appearance of MVS does not change much. Even if you were to go back 15 releases from the one you're running now, the general appearance would still be quite familiar to you. So I might ask, why can't a new MVS sysprog just learn the system from its current level, and then he or she will be "up to snuff"? The answer is in the changes. As I hinted before, most of the development of MVS occurs incrementally, as add-ons or as replacements to pieces of the system. Almost the entire education of an MVS systems programmer comes from the accumulation of knowledge about MVS components. And if you saw how each component was first introduced, and if you followed it through its successive developmental stages until it was finally stabilized, then you have a good chance to acquire a decent understanding of that component. You'll understand the "why" of the component, as well as the "what". This is what the experienced MVS systems programmers have, and the newbies (no matter how bright) do not. This is what the employers of the sysprogs, the MVS installations, are missing, when a seasoned MVS sysprog retires. Replacements for that knowledge are not easily found, and the installation will eventually suffer considerably because of that gap in understanding. CAN SOMETHING BE DONE ABOUT IT? Awareness of the history of MVS and its components is a very large part of the MVS sysprog's education. In my opinion, it seems that if you haven't lived through the history yourself, the historical knowledge of MVS is hard to come by. But some of the gaps can be filled in, and at least a piecemeal attempt can be made by a new sysprog, to be able to figure out "what must have happened before." Talking to the old-timers about MVS is very instructive. If a veteran MVS sysprog is nice enough to "talk shop" with the new people coming up, they can gain a world of knowledge. Having such a person to talk to, is one of the greatest resources an MVS sysprog can have. If you can't find an old-timer who's willing to talk in your own shop, you might join the IBM-Main news group and follow the discussions there. A lot of old-timers get into the discussions on IBM-Main. (See my April 1998 column entitled "Other People's Problems" on File 120 of the CBT Tape collection, and get a detailed introduction to IBM-Main. I've updated the specific URL information about IBM-Main there. In the reprint of the actual article, that specific information is old.) Since IBM-Main is available to everyone, you don't have to remain in isolation from the MVS old-timers of the world. Another thing you can do, is to run an ancient version of MVS, legally, for yourself, on your own PC at home. Get a copy of the Turnkey MVS system made by Volker Bandke, which runs on any modern PC under Windows, and you can be transported back to the mid-1970s era of MVS. You'll see for yourself, how things USED TO BE DONE. You'll run SMP4, which came before SMP/E. You'll have to work through the limitations of MVS that were there, before they got fixed by later improvements to the MVS system. This is entirely legal, because the version of MVS which comes on the Turnkey system (it can be installed and running in less than an hour), was free software, licensed by IBM but given out for free, vintage 1975. So go to the CBT Tape website (look on www.google.com and search for "CBT Tape") and follow the Hercules links on the home page. Order or download a Turnkey MVS system for yourself. Once you've played with the old MVS 3.8 system, and with some of the more modern toys that were re-fitted to it later, you'll acquire an enormous amount of historical perspective in MVS, and you'll become a far more valuable MVS sysprog on the modern z/OS systems. GETTING ON MY SOAPBOX Right now, I feel that it is appropriate to make a necessary point about judging the "qualifications" of an MVS systems programmer, specifically when it comes to evaluating a person for a job opening. Over the years, many of us have encountered "job requirements" for MVS sysprogs, stating that they have to be very familiar with the most recent versions of MVS (OS/390, z/OS, etc.) almost before the new releases come out. If a shop wants to install a new release of (say) z/OS, they tell it to their personnel people, and the personnel people erroneously only look for someone with VERY RECENT MVS EXPERIENCE. This is A VERY BIG ERROR. MVS is old. MVS knowledge, largely, is MVS history. MVS experience comes mostly from MVS history, and NOT from knowing only the newest release. Very fine and highly capable MVS systems programmers are often rejected from a job opening, only because their previous shop did not run a "very current release" of MVS. Evaluating the "talent" only from experience with a recent MVS release is a big mistake, because an experienced MVS person always knows about most of the system, and the "new stuff" can be picked up very quickly if you already have the "old knowledge". New people don't have the "old MVS knowledge". The experienced people DO have it. The way MVS is built, the "old knowledge" provides the skill to overcome myriads of problems. Lack of the old knowledge leaves a person empty of the means to overcome adversity. So shops looking for an MVS sysprog, would be better off considering an "old MVS hand" and trust that he or she can pick up the new stuff as needed. Systems programming managers should be quick to catch this mistake when they talk to their personnel departments, so they will hire the most skilled person for the job, and not let him or her go. I trust that this month's piece will be helpful to you in a practical way. Some of these topics have gone too long, without being specifically mentioned and spoken out. Things that "everybody knows, but nobody says", when they relate to MVS knowledge, are better "said" than "unsaid". That's why I'm saying them. I wish all of you the best of everything. Please come back here again, next month.