MVS TOOLS AND TRICKS OF THE TRADE August 1997 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. Profiles in Creativity This month, we'll begin to feature the work of a few of your colleagues, who have made sizable contributions to the welfare of MVS (or OS/390) systems programming. These people are just like you and me. They are systems programmers who maintain MVS at one or more installed sites. In the process of doing their jobs, they have come up with some clever innovations, tools, and methods, to make the work easier. However, they have done one more thing. They have shared the results of their work with the rest of the systems programming community. We can all benefit from their contributions, and therefore we owe them a hearty: "Thank You!" It pays to look at some of these people, and at what they've done. We might find that we could do it too. There are some old adages which apply: "The way to have friends is to be a friend." "The way to be happy is to make other people happy." "The way to be successful is to sometimes assist other people to also be successful." "The way to learn is to help other people learn." I might also say: "The way to be a better systems programmer is to help other systems programmers." This process can work on several levels: Talking shop with other systems programmers is one way. Looking at other people's code is a second. Using other people's public domain tools is a third way. Writing your own tools, and calling another systems programmer for a discussion of the work, is a fourth. Contributing software to a public tape is a fifth way. And with each of these, if there is an interaction with between you and another systems programmer, both of you stand to gain in a big way. Before elaborating on the details of this, I might add another thought. I have found that often, the most fruitful of these interactions occur at user groups (such as the SHARE and GUIDE conferences or a local user group meeting), where the participants are not from the same shop. Each person involved in the discussion is in charge of a different hardware and software configuration, and has a somewhat different point of view from the next person. This diversity provides a fertile ground for learning, on both sides. Also, since most of the people who are interacting are not from the same shop, there is no temptation to have any petty rivalries and such, since nobody thinks they have anything to gain from these "games". They are from different shops, and therefore they will sincerely help one another. After a user group meeting is over, the people can phone or E-mail each other, to continue their discussions and benefit further. Let's get down to some examples of how you can learn, and help others to learn. I often have telephone conversations with people from other shops. Sometimes, I ask them to tell me what problem they are working on currently. When they start talking, I often find that I don't know about either the hardware or the software that is currently concerning them. (MVS is quite vast.) But I ask them to tell me about it anyway. In the ensuing process, both of us gain. I gain, because I find out about some new stuff I didn't know about before. They gain, because they are talking out the problem to a "disinterested" other party. They gain clarity of thought, and in the process of discussion, new ideas and solutions might present themselves out of nowhere. On the other hand, if I know something about their problem, I might directly help them. On many occasions, I have made short work of someone else's tough problem, and they have done the same for me. Both of us will eventually look good to our respective managements, and will help our shops in a sizable way. Sometimes, the process of interaction occurs when I look at other people's code. Where can you find other people's code? A lot of it is available on the CBT MVS Utilities Tape, an independently produced collection of goodies, which can be obtained through the NaSPA office. There are more collections available through NaSPA, SHARE, and other groups, as well as online from MVS discussion groups on the Internet. File 001 (the documentation file) of the CBT MVS Tape, contains pointers to many other sources of other people's code. File 071 of the CBT Tape has the actual documentation files from these other tapes and sources. A lot of this material is obtainable on the NaSPA CD-roms. When I look at some code from these places, the author's name and address is usually found there too. A lot of times, if the author hasn't moved, I can call that person directly and have a discussion. I can personally testify that you don't have to be shy about calling anyone up. In my entire career, I have called hundreds of these people, and not one of them has been impolite to me in any way. They are more than anxious to discuss their work with any person interested in it. And I have formed many telephone and E-mail friendships with knowledgeable people. There is no reason to be bashful. These are the people I will call, when I have a problem. They have all been very courteous and helpful to me. I try to be the same way with them. The way to have a friend is to be a friend. And both of you gain from it. Using a public domain tool, without actually looking at the code, is another way to learn by finding other people. I'll often assemble someone's utility from the CBT Tape and install it. Then, I'd try to learn as much as possible about using the tool from the documentation. During this process, sometimes I can get to talk to the author and learn more. Other times, I'll ask if anyone else has experience with this tool, at a user group meeting. Or, I'll ask one of my telephone friends. In the process, I'll often gain a ton of system knowledge, and I'll also learn how to deploy the tool in crucial system situations. Finally, sometimes I am writing a program to address a system problem, or to access a certain system resource, and the IBM documentation isn't especially clear. I'd like to see a coding example. Plenty of examples can often be found on the CBT Tape, or in one of the other sources. I can call up the author, or one of my telephone friends mentioned above, to discuss how best to approach my particular implementation of the system facility. This personal interaction process speeds up the coding, and I usually produce a better utility program than I would otherwise have done. Now that we've talked about the first four aspects of this process, let's meet some people who have made contributions to public tapes, and see what they've done to help us. A PUBLIC TAPE AND ITS CONTRIBUTORS One public tape that I am familiar with, is the CBT MVS Tape. Contributions, "large" and "small", come from all sorts of people in our business. No contribution is too small. If an idea will help somebody to save time or money, it is useful, and is worth contributing. My friend Eli Duttman (File 195 from the CBT Tape) has contributed some very simple, but surprisingly useful CLISTs, which help him every day in his work. Consider, for example, a CLIST that contains one line and one command: LOGOFF. You can name this CLIST anything you want, so it won't confict with another command. In my last shop, we called it X. Thus, if you're in TSO READY mode and you want to LOGOFF quickly, you just type X and press ENTER. You might also alias the name of this CLIST as LOG, LOGO, and LOGOF, etc. (the possibilities are endless), and you don't have to put it into a public CLIST library, so it won't interfere with the general public. It's a very simple idea, but it's darn useful and it saves time when you have to get out quickly. There are a huge number of other people who have made all sorts of contributions to the CBT tape. I'd like to mention a few of the names in particular, just to show something about the kind of work they have done, and how diverse their backgrounds are. Let's consider David Cartwright from England (CBT Tape File 172), Vinh Vu (originally from Vietnam) who lives in Texas (File 166), Paul Moinil from Italy (Files 453 thru 459), Gilbert Saint-flour (originally from France) who has contributed File 183, Greg Price from Australia (Files 134 and 135), and Jim Marshall (formerly of the U.S. Air Force), who is responsible for Files 300, 316, and 161, among others. Dave Cartwright is an original thinker, and he has worked in mainland Europe as well as in England. Since Dave speaks and reads German, he could easily profit from the German and Swiss G.U.I.D.E. tapes. In fact, he is responsible for making them available in the United States (Dave sent them to me, and I contributed them to the CBT Overflow Tape--also obtainable through NaSPA). Dave's software collection encompasses some novel ideas, a few of which I'll mention here. Consider CAVEAT (Cartwright's Amazing VSAM Entity Automatic Tuning). This is a program which takes as input, the mere dataset name of any VSAM dataset on your system. The CAVEAT program looks into the system (particularly the VVDS) to find out how the dataset is defined, and outputs IDCAMS ALTER cards to optimize the number of index buffers, so the entire INDEX set is always in main storage. Until recently, this worked "amazingly" well. It could be driven off any list of VSAM datasets, to optimize access time to the data, by adjusting the number of index (or even data) buffers for all of these datasets. Unfortunately in the latest versions of DFP, IBM has taken away the BUFNI and BUFND parameters from the ALTER command of IDCAMS, but you have to admit that the ideas behind CAVEAT are dynamite. It may be possible to fix CAVEAT to output VSAM JCL, where the buffer parameters may still be found. Any person's work to fix CAVEAT for the latest DFP will be greatly appreciated. You can get the address of the proprietor of the CBT Tape through the NaSPA office, and contribute your work there. Dave Cartwright has a lot of other good things on his CBT Tape file. Among these are an external writer to archive SYSOUT to tape or SMS datasets. This is called CHEW (Cartwright's Housekeeping External Writer). Once your SYSOUT is on SMS, HSM can manage it. This might be a good idea for your shop. Among Dave's SMF reporting programs is CRAP (Cartwright's RACF Accounting Program) which reads SMF Type 80 RACF records and produces reports. If you have documents in old Waterloo Script format (see the CBT Overflow Tape for that), and you now have DCF/GML, Dave has an edit macro to convert the document. And there's much more on his file for you to profit from. Dave told me that when he has to write a new program, he himself profits from File 172 by borrowing "already tested" segments of code from there. Dave's E-mail address is: dcuk@dcuk.demon.co.uk Vinh Vu (CBT Tape File 166) is equally creative, although his stuff deals with different things. Vinh has a program to display Job activity, a REXX exec to display MVS control blocks, linklist, APFLIST etc., a program to refresh any single module in LLA (or VLF), and he has much more than that. His file is very much worth exploring. Paul Moinil is one amazing person. At last report, he has been working in Ispra, Italy, at a shop which was discontinuing its use of MVS. Paul's AMDAHL representative in Italy, Antonio Colombo, sent this enormous collection of over 300,000 lines of code, to the proprietor of the CBT Tape. Much of what Paul did, was to make modifications, large and small, to improve a very large number of public domain programs. This is in addition to Paul's original work. The files (453 through 459) are so large, that I can't single out a few things which are especially noteworthy. But I will say this: If you have some favorite program from the CBT Tape, such as Fullscreen ZAP for example (see File 134), I'll advise you to also look at Paul's version of it to see what he's done, and how he's modified it. Also, if you want to find many convenient ways to shorten your system work, you would do well to search through Paul's files and see what he has there. My good friend Gilbert Saint-flour has contributed File 183 to the CBT Tape. I have written in the past about his amazing SHOWMVS program, which in its latest version that I have used, produced over 4000 lines of output, reporting all kinds of status about our large MVS system and my own TSO session. File 183 is a large collection of useful and varied tools, such as the LOADMLPA program to refresh MLPA on the fly, or an SVCUPDTE program to do the same for a Type 3 SVC. There is a program to prevent timeouts of your TSO session, a generalized extension of the ISPF BROWSE facility, and there is much other miscellaneous software to help you. Gilbert has done a lot for us. Greg Price in Melbourne Australia, cut a lot of his System Programmer teeth writing and modifying MVS software for Fujitsu systems. Since Fujitsu hardware and software (to my knowledge) is not sold in the U.S., Greg's experience cannot be recreated easily here. His collection of his own, and his friends' software from Australia, is very extensive. Many of his programs, such as his vast extension to Bill Godfrey's REVIEW "file browsing" program, reflect enormous system and control block knowledge. I know this from my many long conversations with Greg. Much of his knowledge specifically comes from the differences between Fujitsu software and MVS. We can all profit from it, by looking at Greg's files (134 and 135) on the CBT Tape. Jim Marshall was in the U.S. Air Force as a Systems Programmer for many years, during which time he had the privilege of working together with many skilled coders. Jim sent the other people's stuff to the CBT Tape and the MVS SHARE Tape (now part of the CBT Overflow Tape). Bill Godfrey, who was a pioneer in MVS system coding, told me that his code would never have been known (and improved) by the public, had it not been for Jim Marshall. Jim contributes a very large file of TSO programs and commands (File 300) and a large file of batch utilities (File 316). My own career has been greatly shaped by the fact that Jim Marshall took the time and made the effort to send other people's code in. You owe what you're reading to Jim Marshall, my teacher Jeff Broido, and to all the others who took some time to help someone else. That's it for now. Help yourself by helping and contacting others. Good luck. See you next month.