MVS TOOLS AND TRICKS OF THE TRADE OCTOBER 2004 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. WORK AND PLAY Many of us have heard the expression: "All work and no play makes Johnny a dull boy." Believe it or not, this concept has a lot to do with MVS systems programming too. One might wonder how? After all, systems programming IS work. But during my years of working in this field, I've discovered that there is a method of creating a happy medium between "work at work" and "play at work". The way IBM has constructed the MVS operating system, makes this possible. And the result is that if you exploit this situation correctly, you'll increase your productivity immensely, and not only that--it'll make the work very much more fun to do! IBM really created this scenario themselves. In the design of OS/360 and its descendants, IBM themselves never did the full job of supplying tools. Of course the operating system itself was completely functional, but many gaps were left, probably because IBM didn't want to allocate programmer time for them, and much of the utility development was left to the customers, and later, to the vendors. In fact, at one time, the job of systems programming actually required a lot of programming in Assembler Language. Different sites would make modifications to the operating system according to their individual needs. JES2 is a prime example, where modifications were the rule rather than the exception. For example, the user-created free spool browsing tool called QUEUE, actually predated IBM's equivalent offering, SDSF, by a few years. Many of these modifications ended up residing in large free collections of MVS tools, because in order to sell software written for MVS, you usually need a whole marketing setup. Most of the program authors, who are sysprogs working for companies that aren't interested in selling software, can't afford to buy their own machine and do their own development and marketing to sell their creations. Furthermore, the companies which employ these "sysprog-authors", usually don't mind if their system-level software is given out for public use. Again, the companies which own the machines, usually aren't in the business of selling MVS system software. So IBM itself is largely responsible for making this environment what it has become, because IBM tacitly encourages MVS software writing by making most of the various system interfaces publicly available. One of the largest collections of free MVS software tools is the enormous "CBT MVS Utilities Tape" collection, which is now also on the web. On www.google.com, search with the words "CBT Tape". So where does the "playing" come in? "Playing" (in our sense) means trying to create or use new tools, especially some of the free user-written tools from the CBT MVS Utilities Tape, or from the free section of www.xephon.com. I'll give one example (among many hundreds) to illustrate this point. Suppose that you are the SMP/E person who looks at the IBM monthly maintenance tapes as they come into your shop. If you just RECEIVE the maintenance as it comes in, you're doing the "work" involved in the job. But if you go to File 118 of the free CBT collection of MVS tools, and you try out the two SMP/E pre-processing programs PUTXREF and SMPUPD which are there, you'll then get a completely different insight and analysis of the IBM maintenance. And you'll take much more control of the maintenance process in your shop. It may not seem to make much of a difference to do this, but if there's a "situation" where you need to carefully select PTFs, the impact can be major. What does the PUTXREF program do? In summary, it shows which FUNCTION each PTF, APAR, or USERMOD belongs to. And what does the SMPUPD program do? It breaks a (possibly very large) sequential PTF dataset (in "SMPPTFIN format") into a pds, with the individual PTFs, APARs, or USERMODs as the members. Once you know what these basic functions of PUTXREF and SMPUPD are, I can show you more details about what they can do, and how they can profoundly affect the way you run the maintenance of your shop. Ultimately and hopefully, you'll get to see some of the enormous additional power over the maintenance processes, which this puts into your hands. And that power comes directly from our kind of "playing". PUTXREF and SMPUPD Let's see how to "play" with the PUTXREF program first. The idea of PUTXREF is to find out which FMIDs your PTFs in a PTF tape belong to. I once received a maintenance tape from IBM (long ago) which didn't contain stuff for all the FMIDs it was advertised to contain, so I wanted a way to check up on them, and found half of the job already done. This was Jerry Lawson's PUTXREF program. I added more functionality to it. The outputs to this processing are now in 3 different formats. The PRINTER DD points to an FBA-133 report, that lists an FMID and then all the PTFs, APARs, or USERMODs that belong to it. The SMPCOUT DD points to an FB-80 sequential dataset that contains a list of each SYSMOD belonging to each FMID, with the different FMID's PTFs being separated by ./ ADD NAME=fmidnam IEBUPDTE-type control cards. This allows you to do a de facto APPLY SELECT for one FMID at a time, and feed an SMP/E APPLY CHECK job with everything belonging to only one or a few specific FMIDs. I used to use this processing with SMP4 after SMP/E came out, to achieve a FORFMID effect that was not yet built into SMP4. (The Hercules people running MVS 3.8 can still take advantage of this.) Finally, the PDSATOUT DD name gives the output in the form of PDS 8.5 ATTRIBUTE commands to add or change ISPF stats of a pds member that didn't have any stats. You use this output by pointing the free PDS 8.5 command at your SMPPTS dataset, and you add ISPF stats in batch, to the PTF pds members, with the owning FMID as the "userid", using these pre-generated ATTRIBUTE subcommand cards. Pretty cool! Then you can look at your SMPPTS dataset with ISPF and see at a glance, which PTFs you have, that belong to a certain FMID. Since pds members with ISPF stats take up more directory space than those without stats, you probably will have to add more directory space to the SMPPTS dataset on the fly, using the PDS 8.5 subcommand: FIXPDS EXPANDDIR(nnn), to add nnn more directory blocks. This is very nice "playing." If you think about it, you'll see that you're no longer at the mercy of SMP/E RECEIVE processing, to choose what maintenance will go onto your system. I invented the SMPUPD program because I wanted to BROWSE a particular PTF from a tape. If I would IEBGENER an SMPPTFIN file from a tape, into a big sequential dataset on disk, I found out that BROWSE, which uses BSAM reads, took forever to find the PTF number I was looking for. So I wrote the SMPUPD program to put ./ ADD NAME=ptfnumb cards into the copied stream, right ahead of each new PTF. And then, I run IEBUPDTE against the copied stream, and load up a pds with the individual PTFs as separate members. This made it easy to look at each PTF individually. SMPUPD can be run with PARM=READ, and its report lists each PTF number on the SMPPTFIN file (say "tape" for simplicity), together with how many lines of code each PTF (read SYSMOD) contains. So you can also use SMPUPD to find out if a particular PTF number resides on a certain tape. So what's my point in telling you all this? The idea is that if you find some extra tools to "play" with, your "work" will be much more accurate, satisfying, and fun. (Of course, it's assumed that you like doing sysprogging.) Someone who only does things the "vanilla IBM way" is not only missing out on a good time, but he or she is also losing a good measure of control over the system maintenance process. LEARNING HOW TO PLAY The obvious question now is: "How do I start learning to play?" And if I already know how to play a little bit, how do I learn how to play better? My answer is: "It depends what you're working on." I'd suggest that while you're working on whatever is currently keeping you busy, you should take a few minutes out, and look at the CBT Tape directory to see if you can find some tool(s) that relate to your current task. Then download them from the web site, install them (if they look like they'd help you) and try them out. You might search the Xephon web site (www.xephon.com) and look for tools there also. Don't stop your regular work and just do this. Rather, allocate a small portion of your workday for "experimenting". If you do this on a fairly regular basis, you'll soon find that you can get all of your work done sooner, and you'll even have more time left over for more experimenting. You have to remember that your main job is what they're paying you for. The "playing" is only for the purpose of making shorter work of what you have to do. Done correctly, it becomes a "win-win" situation, and your employer will gain, as well as you. WRITING YOUR OWN STUFF Sometimes if you're trying to solve a problem more quickly, you might feel that the best way is to write your own tool to do it more efficiently. If you're good at REXX or Assembler language, this may be a productive direction to take. In former years, I used to do it in COBOL too. But I found that since COBOL needs a run-time library, and the "newer COBOLs" had different syntax rules than the "old COBOL", the COBOL tools of mine became difficult to maintain. So in the end, I converted them all to Assembler and was much happier with them. Many of us have written our own stuff, over the years. It pays to save it, for several reasons. First, you won't have to invent the wheel a second time, when you encounter the same problem over again. Second, somebody else might have the same problem in a different shop, and if you share your tool on a public tool collection (like the CBT Tape), each person can benefit from other people's work. If you have some tools to share, you can email them to me, because I'm the proprietor of the CBT Tape collection, and I can put them there so they can be used by many people, hopefully for a long time to come. I almost never consider a tool "too trivial" to archive. If it saves work, then it doesn't matter if it's intrinsically simple. IBM doesn't give you everything you need, in the way of tools for MVS. We all need extra help. And if one very simple mechanism will save you a lot of time, I feel it's worth shouting about. So I accept all kinds of tools, both simple and complicated, for the CBT Tape collection. If they work, then they are "good" for me and you. That said, let me give you a few pointers. Before you start writing, first do a thorough search of both the CBT Tape and Xephon stuff, to see if someone solved the same problem before, and wrote a ` tool that you could use. If you're searching for a tool and you don't know if one exists, you can post a message on one of the news groups such as IBM-Main, or RACF-L or any of the others. These lists are monitored by many experts and if a tool is there, they'll most likely point you to it. Also, once a discussion has started on one of the news groups about a tool, it may come out that someone has written just what you need, but until now they haven't sent it in to the CBT Tape or to somewhere else that is searchable. So as a result of your question, the tool will get sent to me so we can archive it on the CBT Tape and make it available. When all these paths get exhausted, then you can start writing, unless it is in REXX and it is a simple process to carry out. SAVING YOUR STUFF I'm a big believer in saving machine-readable copies of all the software I've written, provided that it doesn't conflict with the policies of an employer (say, a software company). If the stuff is potentially publicly distributable, or even it I feel I'd like to use it someplace else, at a later time, I try to archive it so I won't have to reinvent the wheel twelve more times. You should know that it is now possible to save your tapes on cd-roms or dvd-rom disks. You can use any MVS system to read your physical tape into my VTT2DISK program from File 533 of the CBT Tape collection, and convert it into an FB-80 folded AWS-format tape stream that can be FTP'ed to a pc and archived on a cd-rom or dvd-rom. Then at a later time, you can move the AWS-format file onto another MVS system and have FTP or IND$FILE fold it over into an FB-80 format file. This file can then be used as input to my VTT2TAPE program from CBT File 533, and a real tape can be cut from that AWS-format file. At the CBT Tape web site most of the materials are stored as zipped XMIT-format pds'es. By unzipping each file, uploading to an MVS system in BINARY, and running the TSO/E RECEIVE command: RECEIVE INDS(your.FB80.XMI) against it, you can re-create the pds exactly as it existed before, even with the ISPF statistics for source and even for a load module pds. This judicious use of the TSO/E XMIT command to preserve pds'es, now has become a standard technique to save your stuff. The required syntax of the XMIT (or TRANSMIT) TSO command is: XMIT node.userid DSN(your.dataset) OUTDSN(your.FB80.XMI) The output dataset is FB-80 sequential, and you can zip it, unzip it, upload it, download it, or send it anywhere very easily. This format makes archiving your own work for later use, extremely easy. CONCLUSION IBM has never pretended to have written a "complete set of tools" that will manage every part of an MVS system. But IBM has provided many of the primitives and interfaces for us (and vendors) to write our own sets of tools. There are collections of user-written tools such as the CBT Tape collection and Xephon's collection which are freely available to everyone, and it pays to spend a certain amount of time "playing around" with these tools to make the rest of our work easier. In most cases, the time spent "playing" is more than made up by time saved because you're using this "new equipment." I wish all of you the best of everything, and I'm looking forward to seeing you here again next month.