MVS TOOLS AND TRICKS OF THE TRADE APRIL 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. MVS EXPERIENCE I figure that now is the time to talk about what is considered "MVS Experience." Any experience that you get, at least in the computer field, usually takes the form of acquiring some familiarity with the environment, and learning HOW to do what you WANT to do. At the very beginning, it also involves learning WHAT you want to do in the first place--an absorption of the aims of what we're all about, and about what computing does. When we first break into MVS in particular, we absorb very much information about the capabilities of the MVS system and what it is used for. We learn all the ins and outs of JCL, TSO, and Operator Commands, which are the tools that everybody uses for interacting with the MVS system. We also spend a lot of time gathering knowledge about the individual components of MVS and what each of them does. Then, we have to form a bigger picture in our mind about how the various components of MVS hang together, function in tandem, and how processes pass information and data from one part of MVS to another. This "bigger picture" is a very important thing to acquire. As one of my former colleagues put it: "You aren't a real MVS systems programmer until you acquire the big picture about how the MVS components hang together." Everyone out there who has extensive experience, will probably agree with me. At the same time, we constantly try to set up our INDIVIDUAL instances of MVS, so they can be all that they can be. Each particular MVS installation has to be properly tailored for its own workload. And since MVS, and the machines which run it, cost such a large sum of money, the company pays us the big bucks (hopefully) to make MVS deliver all of its potential value. As all of us know, this is not a simple job. That's why we get paid for the hard-earned experience which we have acquired, to help make this happen. THE BASIC DESIGN OF MVS One of the primary motivating factors in acquiring MVS experience comes from the nature of MVS itself, and what IBM has tried to design into it. From the very earliest days of OS/360, this operating system was designed for adding on. Even now, after dozens upon dozens of iterations of the operating system, thru MVT and VS1, with MVS (as VS2) and MVS/SE, MVS/SP1 (non-XA), MVS/SP2 (XA), MVS/SP3 thru 5 (ESA), the 10 releases of OS/390, and the various releases of z/OS, the basic structure of the MVS operating system follows almost the same pattern as it did at the very beginning. Someone who acquired extensive MVT and MVS experience 20 or more years ago, can still use that same experience today. The only difference is to learn the add-ons, with a few (but very few) exceptions. (There's no SYSJOBQE anymore.) For this reason, I have to make a statement whose truth every experienced MVS systems programmer knows. That is, if you are an experienced MVS hand, with a lot of system knowledge, and you have gone through a layoff from MVS for a while, it is very easy to pick up where you left off and regain your MVS expertise, to bring it up to date in a very short time. You merely have to learn the new things, and re-familiarize yourself with the old ones. Almost all of the old stuff is still there, and very little of it goes away. I personally have seen many examples of very good MVS sysprogs who were laid off for a while, even for a period of years, and with the chance of a new job, they were completely caught up to speed in the space of a couple of months, or even weeks. Sometimes, an experienced MVS sysprog was stuck in a shop that had a back leveled version of MVS. When that same person was put in a shop which had the new stuff, he or she was up to snuff in almost no time. The basic MVS knowledge is very hard to acquire. But the add-ons are usually not as difficult, and their knowledge normally comes fairly quickly, if you already know the basics well. So this gets me to describing an old gripe, which I don't think is quite as prevalent nowadays in the MVS world as it used to be. It used to be that when a company was looking for an MVS sysprog to fill a job slot, they would describe the slot to their personnel department, that they wanted to put in MVS release x.y (the newest one which was only out for a month or two). The personnel department interpreted that to mean therefore that they needed ONLY a person with experience in installing JUST that release. This request is simply not logical. First of all, if the release was out for just a month, how many people would be available for work at this moment in time, who have already installed it? And secondly, who says that even if there does exist such a person who IS available, that he or she is more valuable to the company than an old MVS hand with a ton of experience on slightly older MVS releases? Here we see a piece of ignorance (usually on the part of personnel, but even on the part of a manager or two), which could lead to a big disaster in hiring. An experienced sysprog who knows what he or she is doing, is far more valuable a resource to a company, than is a new person who was lucky enough to be exposed to a recent MVS release, recently. Who knows more? The experienced one, of course. So therefore, a company could severely short change itself by blatantly hiring the wrong person. This practice is only the result of extreme ignorance, concerning what MVS knowledge is all about. But since it has actually affected so many people, so often, within my memory, I feel I have to mention it, because it irritates me to the point of anger. In summary, MVS experience is built up first by learning the basics, which have existed from time immemorial (that is, 1964 or later), and then learning about the new features or structures which were added on afterwards. Those old hands, who had gone through all the changes when they first occurred, are in the best position of understanding the total structure of MVS today. Newer people will have to content themselves with trying to relive the old experiences by talking with the older people, or by fishing out the old conversion notebook manuals to witness (for themselves) the step by step changes and add-ons to MVS at each stage. The total MVS system is a result of very many add-ons. Make no mistake about it! You learn MVS best, once you know how the basics work, and then by learning how each of the new features was added on later. TSO/E I'll try and illustrate what I've just said, by using the examples presented by TSO/E and ISPF. We'll start with TSO/E. "Plain TSO" is much older than TSO/E (which means "TSO Extended"). Plain TSO was free with the MVS Operating System. You had to pay extra for TSO/E. TSO/E came out in the early to mid 1980s, around the MVS/SP 1.3 time. (Nowadays, we take the presence of TSO/E completely for granted.) I first saw TSO/E, in our jump between MVS/SP 1.3.3 and 1.3.5, but you have to remember that then, all the separate pieces of MVS were delivered as separate and interchangeable components, and billed separately. The OS/390 era of integrated testing and software delivery had not yet started. So TSO/E, which presented a large bunch of enhancements to "old TSO", could have been delivered with MVS/SP 1.3.3 or possibly earlier. It only depended whether you wanted to pay for it, or not. TSO/E came with an enhanced ALLOCATE command, that allowed the REUSE keyword. In other words, if a DD name was already allocated and you wanted to ALLOCATE it again to another dataset, you first would have to FREE it, and then re-ALLOCATE it. This presented the problem in a CLIST, because to ALLOCATE the dataset to a DD name in a CLIST, you would first have to use some "robotic" method of determining if the DD name was already allocated to some other dataset. The REUSE keyword of ALLOCATE eliminated that problem. If you wanted to force a reallocation of the DD name no matter what was there before, you would just code the REUSE keyword of the (new) ALLOCATE command. Today we take the REUSE command of ALLOCATE for granted. In the old days, people had to write their own TSO commands to use in CLISTs, that determined whether a DD name was already being used, or not. Another thing introduced by TSO/E was the altogether new TRANSMIT and RECEIVE TSO commands. These were designed to send datasets between userids that were attached to different MVS nodes. The TRANSMIT (or XMIT) command would (under the covers) repackage the dataset as an FB-80 bundle and then ship it across JES lines, to another connected MVS system that was defined as a node to the SNA network. And on the other end, the RECEIVE command (operating under the control of a userid), would unpackage the bundle and re-create a copy of the original dataset in the new place, at the new node. Nowadays, we take advantage of the repackaging aspect of XMIT and RECEIVE in a way unforeseen by (perhaps some of) the designers. By using the OUTDSN( ) keyword of the XMIT command, instead of preparing an FB-80 bundle under the covers, XMIT will actually bring it out into the open, as a sequential dataset. And using the INDS( ) keyword of the RECEIVE command against that sequential dataset, we can re-create the original dataset on a new system, just using the dataset created by OUTDSN. So as a consequence, we can use the TSO/E XMIT and RECEIVE commands to transport a dataset between ANY two MVS systems, even if there isn't a line which connects them, in between. For the purpose of this article, we must mention that all of this wonderful functionality only came into being with TSO/E, and it was not there in "old TSO." So from the point of view of the MVS sysprog, what experience did we gain from TSO/E, as opposed to "old TSO?" At the time TSO/E came out, MVS sysprogs would read the conversion manual and try to learn the new features. They would possibly rewrite some of their CLISTs to make use of the new REUSE feature of ALLOCATE. And if they were of a visionary nature, they might try to figure out how the new TRANSMIT and RECEIVE TSO commands would make their lives easier. I remember how I used XMIT and RECEIVE to transport a copy of the TMS TMC dataset from one datacenter to another, on a regular basis, so we could perform statistical analysis using SAS, which was only licensed at one of the datacenters. Other installations might have (inventively) used TRANSMIT and RECEIVE for similar, but equally novel, purposes. This illustrates how an add-on feature of MVS becomes an integral part of "MVS experience." ISPF Today, we almost universally take for granted the presence of that fantastic file editor and utility super-package on MVS which is known as ISPF, or ISPF/PDF. Once upon a time, ISPF didn't even exist on MVS. I remember when you had to use the line editor called EDIT, to edit a file. At that time, our installation invested some well-spent money on an OEM supplied vendor product called FSE (or Full Screen EDIT), which was much more powerful and easy to use, than the IBM EDIT line editor program. Most of our programmers became very proficient using FSE, and it was a powerful productivity tool at that time. But FSE was absolutely nothing, when compared to IBM's new ISPF. ISPF evolved gradually, requiring its users to learn some of its features initially, and to add on to the experiences later. ISPF always came with a full-screen tutorial. If you took the time to read it, you would learn a lot, and your productivity would profit a lot. One of my friends told me, that much of his value (to the company) came from the fact that he took the time to read ALL of the ISPF tutorials and to study them well. ISPF is expanding, even today, and MVS sysprogs will surely profit greatly, by reading its enhancement notices. But I have to say that even if your "ISPF experience" is old, you still know a lot. That's because ISPF, as with the other MVS components and products, was always built using the same "add-on" concept. The old features usually do not go away. They are only supplemented by new features. Today's space is short, and I don't have the time to dwell on the great many particulars about how ISPF experience gets "built up over time." If you see Jim Moore's columns, especially if you've followed them over the years, the immense value of learning new ISPF tricks will be greatly noticed. But today I want to say that "ISPF experience" is "MVS experience", and so is TCP/IP experience and Unix Systems Services experience. The "core MVS experience" has existed for a long time. But the "add-on" MVS experience becomes part of the whole, and once you've acquired much of the core experience, most of the rest of it is the add-on experience. SUMMARY As is often the case, the things I've mentioned today about "MVS experience" are things that most people already know. But a significant number of people, the newer ones, and the ones not deeply involved in MVS, don't know them. A "gifted manager" with different experience, who is forced by the upper management to head an MVS group, is often put into this position, and runs afoul of his or her lack of knowledge about how MVS experience works. Therefore I feel that it is VERY IMPORTANT to point out that the experience acquired in the process of maintaining MVS, is extremely dependent on how IBM designed MVS and its predecessors in the first place. The original (circa 1964) design of OS/360 was based on keeping the core structure intact, and then adding onto it later. That's the way our "experience with MVS" is acquired too. If you don't know that, then you don't have any "professional direction" in this field. "The old guys know the most." That's just how it is. Other computing systems that get completely rewritten, or which were not originally designed in this way, may have other "learning parameters" and patterns. But MVS has its own design structure, which was imposed on us, for our fun and profit, by IBM. If you don't respect that and know that, then your company will suffer, and so will the employees. That's why I think it pays for me to say this. In any case, I always wish all of you well, I hope all of you have many good months and years ahead, and I'm looking forward to seeing you here again, next month.