MVS TOOLS AND TRICKS OF THE TRADE NOVEMBER 2000 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. DESIGNING SOFTWARE: WHAT'S IN IT FOR US? Our profession is many-faceted. In order to do our jobs properly, we need to be proficient in a variety of skills. The main function of a systems programmer is to keep track of the state and levels of system software in the shop. Along with that, comes installation skills, and the ability to install an entire operating system from the materials that IBM and the other vendors send us. I hope to make that topic the subject of another article in the near future. However, today I'd like to talk about an aspect of our jobs that we all deal with directly, but I'm sure that most of us, including me, do not spend a lot of time thinking about it. I was forced to face this subject, because I have an ongoing side project designing a software utility, which happens to be a tape copying program. In the past six months, I have added a lot of functionality to this program. The project has gotten big enough, that I have to think very carefully about how to proceed in designing my program further. Figuring out how to design my own rather complicated software utility, has gotten me thinking about how a user would attempt to learn about its many capabilities. We all have a lot to do. Every so often, our jobs require us to learn about some new utility. Once, I had to learn how to use SDSF. (I had used the QUEUE program before.) Then I had to re-learn most of this again, because I was forced to use IOF to do the same thing (browse job output). All of us have had to learn many aspects of ISPF/PDF in our everyday jobs. And those of us who are fortunate to use the free PDS 8.5 package (from File 182 of the CBT MVS Tape) or its vendor supported successor STARTOOL (from Serena International), know that it takes quite a lot of practice to familiarize oneself with that product's many capabilities. The rewards justify the effort, though. Once you've mastered one of these capable "multi-utility" packages, it becomes an integral part of your working day. Whenever you have to edit a file, your ISPF skills are exercised. Whenever you have to look at spooled job output, your skills with SDSF, or IOF, or whatever other package you use for that, are refreshed and renewed. If you use the PDS or STARTOOL packages, whenever you have to find complicated things out about a dataset or its contents, your mind is exercised, to figure out how PDS or STARTOOL will help you get the job done. To solve a performance question, your skill with Omegamon(R) (from Candle Corp.) or one of the BMC products, or whatever monitor your shop runs, will serve you well. I'm hoping that whenever you want to copy a tape, you'll turn to my collection of tape copying programs (which are free) on File 229 of the CBT MVS Utilities Tape. Or if you want to deal with SYS1.BRODCAST messages, or stop SYS1.BRODCAST from filling up, you'll learn to use my utilities package for that, on File 247 of the CBT Tape collection. I hope you find enough completeness in these two packages, that they will satisfy your needs in these areas, most of the time. My stuff is free. The commercial software vendors have similar hopes that you'll buy and use their stuff. The bottom line is that there are many software manipulation operations we have to do every day. And there are software tools and packages we have to learn how to use, so we can do these jobs. Often, there are several tools that can do the same job. But it is our job to learn to use at least one tool that can do each task which comes up. There are a lot of different tasks, and a lot of different tools to learn about. Usually, we don't have an organized path to take, which tells us how to proceed, and what tools to learn. So what do we do? If we have a need (say, to restore a deleted member of a partitioned dataset), we'll ask a more experienced colleague if there's a tool to do this. If the shop has such a tool, we'll try and find some JCL that runs it, or an ISPF panel to get into, that'll invoke it. We play around with the tool until we get the job done, and at that point, the question comes up which "separates the men from the boys": Do we drop things there, now that we've gotten past our immediate task? Or do we try and find out more about that tool? What OTHER things can this tool do? It's always a good question to ask. At this point, we'll shift gears, and look at these matters "from the other person's point of view". What if we were the software developers? How do all of a tool's many options look--from the developer's side of the fence? SOME INSIGHTS FROM MY EXPERIENCE Now that I've taken a simple tape copying tool (called COPYMODS from the CBT Tape - File 229), and given it about 30 new options, it comes to my mind to ask: How should I document all these options? And to be realistic, will anyone actually need all these capabilities? Who is going to be the reader of the documentation I write? What will that reader be able to gain, from what I am saying? In asking these questions, I've had to re-think the entire software learning process for myself. I'll take you though a short tour of what I've had to think about. I feel that this exercise has given me a better insight into the nature of our jobs, and that is why I want to take the time to share the results with you. First, let's see what the COPYMODS program does. As originally written, the COPYMODS program will make an exact copy of an existing tape, end to end. If the tape is Standard Labeled, COPYMODS will copy all the labels and the data. The copied tape will have the same Volume Serial as the original tape. If the original tape was Non-Labeled, COPYMODS would copy all the data exactly, with all the tape marks. Furthermore, COPYMODS could make multiple exact copies from a single tape. The original program could make 10 copies. My enhanced version can make 16 copies, if you have enough tape drives. In enhancing the COPYMODS program, I've kept two things in mind. The average user will want the original COPYMODS invocation JCL (COPYMODS is a batch program) to always still work. On the other hand, we will want to get rid of the program's shortcomings and limitations, while at the same time, we want to add new capability. So in short, I have several different users in mind: A) the simple user who just wants to copy a tape, B) the user who has more complicated needs, and/or C) the user who wants to delve deeper, and exploit the tool to its fullest extent. As the developer, I've had to keep mental track of all three types of users. Let me take you along the path I've taken, to make the enhancements and fix the bugs. I started out simply enough. COPYMODS had a limitation that it could only copy 32K blocksize, maximum. I knew that the architectural limit for one EXCP was 64K, so I sought to remedy that shortcoming. It wasn't so hard to do. The other limitation of COPYMODS led me on my present long path. COPYMODS was originally designed to copy NL tapes only, and whenever it saw two tape marks in a row on a tape, it would assume an end-of-tape condition and would mindlessly stop copying. When copying a Standard Labeled (SL) tape, where the tape data is surrounded by header labels and trailer labels, this would sometimes be very annoying. A SL tape file with no data in it, normally contains two tape marks in a row. That's because the header labels are separated from the data by a tape mark, and the end-of-data is separated from the trailer labels by another tape mark. If there's no data in the file, which can occur, say, when you're IEBCOPYing a pds with no members in it to a tape file, the header labels are followed by their tape mark, there's no tape data, and then there's immediately another tape mark, which separates the end of the (nonexistent) data from the trailer labels. When COPYMODS would see a null SL tape file, it would copy the file's headers only, and then stop right there. To remedy that shortcoming, I had to teach COPYMODS the difference between header labels (HDR1 and HDR2) and trailer labels (EOF1, EOF2, EOV1, and EOV2). If two consecutive tape marks occurred after header labels and before trailer labels, COPYMODS was instructed to continue copying. This solved the immediate problem. However, once I taught COPYMODS a little bit about Standard Labels, I asked if I should possibly teach it a little more, and then a little more. I taught COPYMODS to print a VOL1 label and show the volume serial if it was there. Then, I taught COPYMODS to print all the standard label types it found. Then, as I thought of more ideas, I invented an EXEC PARM parser to make it easy to add new options to COPYMODS (see this column from the July 2000 issue). Enhancements went on and on, until COPYMODS can now be invoked READ-only, making no copies. It can dump all the Standard Labels found on the input tape, to a disk file, and an NL version of the same tape (created by the COPYSLNL program, included in File 229), can be merged with these dumped label sets, to create a new SL tape. Meanwhile, you can edit the labels in the disk file. And all of the output tapes from COPYMODS can be made with up to 16 copies at a time. You see that COPYMODS, in skilled hands, has become an incredible tool! Yet, the original JCL to invoke COPYMODS to copy tapes, using no parms and no SYSIN cards, still works just about the same. If I write good documenation for the "advanced users" of COPYMODS, you see that I can satisfy the requirements of all three types of users I've mentioned above. SO WHAT'S IN THIS FOR US? So why do I feel that it's been worthwhile mentioning all this? Because it'll make all of us "tool users" more aware of how we should learn about new tools. We have to prioritize our time at work. But if we have some free time, we can spend it by asking ourselves: "What was a tool I've used recently in a simple way, that I might learn to use in a more advanced way?" An intrinsically complicated multi-use tool like Candle's "Omegamon(R)" monitor, or BMC's "RESOLVE(R) or "MainView(R)" might fall into this category. Or, you might find that a relatively simpler program you might use, such as the VTOC program from File 112 of the CBT Tape, has many other options that might be worth looking into for practical use. I'm really coming to suggest a way of growing. Just like the tool designers keep dreaming up more useful enhancements to their already capable products, so the tool users (That's us!) can gain by spending more time learning about some of the neat things that the tool designers have created. Our working lives, and our capabilities, can be greatly enriched in this way. I hope this month's column has gotten you thinking a little differently. I wish you all the best of luck, and I hope to see you again next month.