MVS TOOLS AND TRICKS OF THE TRADE JULY 2003 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. ATHLETICISM IN SYSTEMS PROGRAMMING In my opinion, musicians are athletes. They don't lift heavy weights, throw baseballs at 98 miles per hour, or run 40 yards in 4.2 seconds. But in order to play the required number of notes with the required precision and tonality on their respective instruments, they have to move their fingers, mouths, lungs, arms or feet with strength, enormous coordination and endurance. This usually requires many years of physical and mental training. So I think that anyone would be hard put to argue that a musician is not an athlete. Just about every musician, and for sure a professional one, is a prodigious athlete. So what does this have to do with systems programming? I learned early in my career that it has a great relevance. In truth, I think that all of us will agree to this. It's just that we don't think of the situation in precisely a way which points out this association of some of our activities with athletic acts. For example, when installing a new version of MVS, has any of us had to build a new list of dataset names or the like, from another list, in a non-trivial way? All of us have had to do that, one time or another. And we usually had to do it by hand, because a utility to do precisely what was needed, was not available. So we had to bite the bullet and sit at the terminal for several or many hours, until the new list was in good shape, and the new system would be able to use it without an error on even one line out of many hundreds or thousands of lines. Again, in my mind, that is a feat of athleticism. Although we may only have to do it once in a great while, this is still an act of athletics. It requires a great concentration and a coordination of mind and body. One mistake can lead to a disaster and a great loss of productivity for the installation. Every line of the resulting file has to be exactly correct, and often we don't have a utility program that lets the computer do the job for us. So, at least occasionally, we are all required to be athletes. And it is this athleticism that I am addressing today. IS OUR ATHLETICISM GOOD OR BAD? My quick answer for this question is that we try to avoid it, but that it sometimes is necessary. My opinion is that a good systems programmer should avoid athletics and acquire a good command of utilities that will get a job done, using the computer to do the labor. In other words, a good systems programmer is not lazy to learn how to use a new utility, because the utility will ultimately help avoid a situation in which athleticism is currently the only answer. On the other hand, we should not flinch from athleticism when it is necessary, but we should jump in, grit our teeth, do the big job, and then it will be done. That's part of a systems programmer's skill set too. Sometimes a job needs to be done now. Looking for a utility would take too long, if you don't already have one. So you just do it the long way, get it done, and be proud of yourself. So my take is that system programmer athletic feats should only be necessary when they are unavoidable. In other situaions, we should have a command of utility tools that will let the computer do the labor for the job we need done. The computer is faster, and if the utility is appropriate for the job, it is more accurate. I have seen systems programmers who perform athletics during much of their regular daily work. For them, I have the criticism that they did not take the time or effort to learn how to use the tools that are available. In our job, I feel that athleticism does not really have to be employed very often. Telling you about tools which avoid "sysprog athletics" is one of the reasons why I write this column. STEPS TO AVOID SYSPROG ATHLETICS As I said before, I think it's better for the computer to do the work than for you to have to do it. So to that end, one should start to acquire, or continue to acquire, a repertoire of tools to help you do various kinds of jobs. A good place to look for tools, is the huge free collection of MVS sysprog goodies known as the CBT Tape collection. You can get to its web site through the NaSPA web site, or you can get to it directly through its own URL. The CBT Tape collection actually is also available on two tapes, and the various single contributions to the collection are normally referred to by their tape file numbers. I would say that the first tool to look for, if you don't already have it, is the PDS multi-utility program on File 182 of the CBT Tape. Originally written at the Firemen's Fund in San Francisco, and greatly expanded by Bruce Leland and Steve Smith, the PDS command package is now maintained by John Kalinich, who does his best to keep it as useful as possible. The PDS program should rightfully be the subject of several articles, as it has been in the past. See members $PDSART0 thru $PDSART3 in File 182, which is a course on how to use most of the many subcommand utility tools in the PDS command package. The PDS package is a TSO command containing approximately 50 subcommands, each of which invokes a separate utility function. Within each subcommand, there are sometimes as many as 40 or 50 variations as to what can be done. So I would safely say that the PDS command package contains perhaps 1000 separate utility functions within itself. PDS also has an ISPF interface that invokes all the line-mode PDS commands and more. If you are running the PDS command in an ISPF environment and you copy its panels and messages to the appropriate libraries for your TSO session, you have a formidable arsenal of utility functions to help you avoid "sysprog athletics". As are all of the contributions to the CBT Tape collection, the PDS command package is perfectly free. HOW A TOOL LIKE THE PDS PROGRAM CAN HELP When you get somewhat familiar with the capabilities of the PDS program, you'll start to realize that some jobs you've formerly pictured as arduous tasks, become ridiculously simple to do. For example, suppose you have a partitioned dataset with many members in it, and you want to search the members for a string of characters. With the PDS program it's no problem. Just issue a FIND subcommand with the PDS command pointing at your partitioned dataset. Give FIND the member group of members (or a colon : for all members) you want to search through, and put the string between two delimiters (like / or ?) after the member group. The whole command will look something like FIND : /mystring/ The PDS command will go through the entire partitioned dataset, and display all occurrences of the string. It's that simple. Once you know which members contain the string, you can deal with them any way you want. But it doesn't stop there. You can grab the group of all members which contain the string, and deal with that group as one entity, directing subsequent PDS subcommands at just that subgroup of members. This is done by referring to the current subgroup of members with an asterisk. You can create this subgroup from the group of all members by issuing the PDS command: FIND : /mystring/ THEN(SUBLIST) This creates a group of members consisting of a list of member names, which all contain the requested character string. A subsequent FIND command for a different string can now be directed at this subgroup of members only, like FIND * /otherstring/ THEN(SUBLIST) That subsequent FIND command in PDS will further reduce the current subgroup of members to a list containing the first string, reduced to those members which also contain the second string. You are starting to get the idea that a tool this good can save you quite a bit of raw gut work. Multiply by the fact that there is a REPLACE command that works like the FIND command, and there are about 50 other different types of subcommands as well, which can operate against all members in an entire subgroup of the pds members. Once you're thoroughly familiar with the workings of the PDS command package, you'll find yourself doing a lot less "athletic work" and you'll be getting your jobs done far more accurately and in far less time than ever before. REXX EXECS AND CLISTS CAN HELP The PDS command package is written in Assembler, and even though it contains an enormous amount of built-in capability, you might find that the quickest solution to a given problem is to make your own CLIST or REXX exec to handle the specialized situation. For example, suppose you are comparing two files and picking out differences between them. You might try to use a tool like SUPERC to discover all the file differences, but once having done that, you might want to write a REXX exec to read the two files line by line, and then manipulate their contents in some special way. This might turn out to be the quickest way to solve your particular problem. If you don't know how to do this, the CBT Tape collection is full of CLIST and REXX collections that do particular jobs. You can search the CBT Tape collection for CLISTs and REXXs, until you find one that does almost what you need to do. Then you can copy most of the code, which is free, and adapt that code so it gets your particular job done. Files 95 and 251 contain many CLIST-based edit macros from the late Paul Davis. In the newer CBT Tape files, from the 400s up through the 600s, there are many REXX-based tools, and there's a lot of code to look through and copy from. You can look at the 50000-plus lines of the CBT tape documentation (File 001 of the tape) using the PDS command, and just scanning that file for the word "REXX", you'll discover many collections of REXX-based tools to look through. SUMMARY So I've only scratched the surface, to indicate a direction to go. If you want to avoid having to do huge feats of "sysprog athletics" often, you should start to acquire a collection of utility tools that make long jobs easier, like the PDS command package from CBT Tape File 182. Once you've installed this package and become somewhat familiar with it, then you've taken a big step toward avoiding "athletic solutions" for your big jobs. Learning to write REXX fluently will help you a lot too. And if you've solved a big problem by writing a specialized REXX to do it, you might think of donating it to the CBT Tape collection, so that other system programmers won't have to reinvent that wheel. Instructions at the CBT Tape web site will tell you how to donate your work. Or you can email it directly to me. Devoting a half hour per work day to looking for and acquiring new tools from the CBT Tape collection, will save you many hours of athletic system programming in the future. Best of luck to all of you. I hope to see you here again next month.