MVS TOOLS AND TRICKS OF THE TRADE MAY 2002 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. DRIVEN BY NECESSITY It's obvious to all of us, that most of the work we do, is driven by necessity. We have to maintain our installation--a certain result needs to be obtained--and our technical tasks are directed to achieve this result. I'd say that upwards of 95 percent of our "experience" is gained by doing technical tasks that our shop requires us to do. I'd like to make a point. Even though the MVS operating system which runs at different installations is essentially the same thing, each installation's current requirements and emphases may be widely different. Some shops have a need to run a web site from MVS. Some shops are worried about CICS terminal response time (even today). Some are concentrating on putting all their tape work on a Virtual Tape system. There are hundreds, and possibly thousands, of different "hot needs" at every installation, at any given time. And who works at satisfying them? We do. My point is, that most of us are only worrying about what is going on at our own shops. I have a different view, being the proprietor of a very large free software collection (the CBT MVS Utilities Tapes). In my CBT Tape activity, I have to "cater to the world", so to speak. I get to see the varied software contributions which are coming in from all over the world, dealing with many different aspects of MVS. Most of these software creations were driven by a requirement in "that particular shop", at "some particular time". What we often DON'T DO, is to realize that there is benefit to US, to see that some OTHER SHOP had a certain particular need. I want to point out that there is an advantage to us, to think more globally, and to pay a certain percentage of our attention to being aware of other people's MVS problems and needs, not just our own immediate assignments, that have been driven by our own shop's needs at this current moment. By being aware of problems in other shops, we add another dimension to our outlook. MVS, now encompassed in OS/390 and in z/OS, is vast. We find that we can't learn ALL of it, but we can at least try to learn a lot of it. My experience tells me, that if you have a broader view of MVS than just what your own shop needs, you can provide a vision and a direction for your shop, on such occasions when that might later be required. This is because your outlook is now "outside" as well as "inside", and you will get to grow more aware of the many things that MVS can be used for. NECESSITY AS A FORCE I remember in the old days of MVS systems programming, when there were a lot of Assembler "hotshots", who claimed they could code any tool or utility they might need in doing their work. I watched some of these people. My take on their claim was: Yes, they probably could code any utility they wanted to. But practically speaking, their everyday work did not allow them the time or concentration to do a proper job, in writing every tool that might be needed. They simply didn't have the time, and never got around to it. So we see that human limitations usually got the best of even these people, who knew the system inside-out, and who could "code anything". Today with the standards for a useful tool being higher, the MVS system being more complicated, and with the Assembler skills, on the average, being much lower, I don't think it is practical for most people to go around, saying: "I can code up anything I want, whenever I'll need it." You simply have to have the time to do it right, besides having the skill too. So it becomes practical for all of us to rely, for at least our free tools, on someone else, who at one time was driven by necessity, and who had the time to do it right. I might point out that the vendors are also driven by necessity--to produce a product that they can sell to satisfy the customer needs, and to keep their customers' satisfaction. Let me supply an example. I'll ask: Which of you has ever had a need to code a set of tools to manage SYS1.BRODCAST messages? I'd bet that very few of your shops ever paid someone to write a tool to print or delete a selected user's TSO Broadcast messages--it simply isn't economically feasible at most shops, to spend programmer money on that kind of work--there isn't a need. But I was paid for over two months once, to do just this, because my shop had such a need. I worked for a large service bureau, which managed a diverse set of LPARs for various separate agencies, and we had political reasons to be careful with all their data. We could not simply delete an agency's Broadcast or Notify messages whenever we felt like it. We had to have a measure of real control and accountability to each agency. So the need was there, in that particular case, and I had to do the job. As a result, I wrote a comprehensive set of tools to manage SYS1.BRODCAST messages, and I've improved on these tools since then. I've even gotten these tools to the point where I can display or delete any number of selected messages for any userid, at any point in the chain--I'm not restricted to deleting all of them. My friend Vinh Vu even wrote an ISPF interface for using these tools easily and safely. So here's one clear example, where you see that because one person's shop had a rather unusual need, all of you can now enjoy the results of the work, and use the tools that were created because of this need. You can find my set of SYS1.BRODCAST management tools by obtaining File 247 from the large CBT MVS Utilities Tape collection on the web. www.naspa.com has a link to the CBT Tape web site. The entire CBT Tape collection of utilities is filled with such creations, from people who, at a certain time and place, were driven by necessity to create certain kinds of tools. I always say that the world is usually better off, when "one hand washes the other", and people help each other to solve one another's problems. If one person was driven by necessity to do a certain job at a certain time, and the resulting tool was contributed to a common pool (the CBT Tape collection is one of the most well-known common pools of software and tools), then a lot of other people can also benefit. One person's "necessity" has become everyone's profit. NECESSITY CREATES ACCURACY This is an easy concept to understand. When you have a need at the job, and you have to write a program, or perform some maneuvers to get around the difficulties and solve the need, you had better be accurate. Otherwise, you will not solve the problem or satisfy the need. The PROBLEM requires you to be accurate, in the process of solving it. To show how this works, I'll use my previous example. When I was writing my SYS1.BRODCAST utilities that I mentioned before, and I wanted to delete a particular userid's messages, I realized that I had to do it correctly. Otherwise I would have corrupted the SYS1.BRODCAST dataset for the entire system. Therefore, I had to be careful to make sure that my code didn't leave any "orphaned" message records (one userid's message records are all chained together), and I had to get the system enqueues correct. I didn't want to be mucking with the userid message chains, while somebody else was trying to do a SEND or a LISTBC command under the covers (such as processing a JCL NOTIFY=userid request). I knew I couldn't attempt to do this kind of a programming job, unless it was completely reliable, accurate, and dependable. The fact that I was responding to a necessity, required me to "do the job right". Again, at this point, I'd like to emphasize that since I have already tackled this job, and I've shared my code with the public, you don't have to re-do that work all over again. But I'm also saying that in my own personal experience, I realize very well, that necessity in solving a problem, requires enough of a degree of accuracy in the solution, that no further problems would be created by what you've done. Necessity has thus become a force, to ensure the accuracy of the solution. So the necessity which gave rise to trying to solve the problem, also serves as a deterrent to making errors. THE OPPOSITE OF "NECESSITY" - MAKING TIME TO LEARN So at this point it might seem to you, that everything you do in your MVS work is driven by the necessity created by the job, and that there is nothing else which motivates you. This doesn't have to be the case. My MVS teacher, Jeff Broido, always used to emphasize that an MVS practitioner should invest at least a half hour a day, to learn something new. Jeff told me that long ago, when ISPF was first released, he took the time to learn all of the ISPF tutorials. In this way, he was able to accumulate enough ISPF knowledge to do his job more efficiently, and he could save his company's time in the long run. I think that everyone should seriously consider the merit of what Jeff suggested to me then. Jeff used to spend a lot of his time writing specialized TSO commands. You can see the results of some of Jeff's work on CBT Tape File 423. Part of his motivation was to use this "piece of the day" to learn new things. But he frequently aimed his extra projects at satisfying some actual need which the installation had, but which they didn't specifically order him to work on. It's true that most MVS systems programmers are required, to a large extent, to use their own individual initiative, usually within the range of working on the installation's current "hot needs". But sometimes, an installation's "lukewarm need" might become a "hot need" later. And you can spend your extra learning time working on that kind of stuff too, provided that your management doesn't object. SUMMARY, AND A FEW SUGGESTIONS The main thing I want to point out, is that I've noticed that many of us tend to get completely absorbed in only solving the "hot needs" of the installation. It's true, that we can grow a lot (professionally) that way, but I think that only tending to the "hot needs of the hour" will stunt the growth of our MVS vision in the long run. You have to be able to "look outside of yourself" sometimes. And the installation will profit too, in the long run, from your developing some broad-mindedness. You can develop some breadth of vision by looking at other people's problems, preferably from other shops. One way you can do that, is to monitor some relevant news groups, such as the IBM-MAIN news group (see my April 1998 column for more details). The current listserver address for IBM-MAIN is listserv@bama.ua.edu . And the message posting address for IBM-MAIN, once you've subscribed, is IBM-MAIN@bama.ua.edu . I get a daily digest of the IBM-MAIN group, so I don't get bombarded with the individual email messages, and I look through the digests whenever I have a free moment, or I feel that I need a break. Some of the other LISTSERV-based news groups are: ISPF-L, RACF-L, ASSEMBLER-LIST, MVS-OE, C370-L, PL1-L, JES2-L, JES3-L, and DB2-L. The LISTSERV-based news groups are linked together. Once you subscribe to one of them such as IBM-MAIN, you can request an INFO REFCARD from its listserver address, to tell you how to find, and subscribe, to the other lists that you're interested in. Other news group lists are not LISTSERV-based. A notable example is a whole bunch of them, that are maintained at www.yahoogroups.com . The principal one of these that I subscribe to, is the Hercules-390 list. To subscribe to that, the address is hercules-390-subscribe@yahoogroups.com . And its message posting address is hercules-390@yahoogroups.com . Once you're into the www.yahoogroups.com family of lists, you can find a whole bunch of those, to interest you as well. In my opinion, this extra stuff should not be done to extremes, but it's only for "broadening purposes", and it should be done in moderation. Most of what we do at work, is driven by necessity, and it should remain so. Remember that Jeff Broido's guideline was to spend roughly a half hour each day, at generally broadening your knowledge. The purposes of these extra activities, is just to put your overall vision into perspective, as it relates to what other people in other shops, do. By maintaining a healthy balance, you will grow toward becoming a more complete and valuable Systems Programmer. I hope you all have a good month, and I'm looking forward to seeing you again, next month.