MVS TOOLS AND TRICKS OF THE TRADE JANUARY 2005 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. MY POINT OF VIEW This month, I want to talk about some of my personal ways of doing things. Everybody has his/her own "style", for want of a better way to describe one's personal preferences in how to do the work. Along with a personal style, everybody develops a personal set of tools to use, over the years. A lot of times, we write these tools ourselves, but more often, we borrow them from others, and adapt them to our own needs and likes. The huge CBT Tape collection of free tools and "stuff" for MVS systems programmers, in its almost 30 years of existence, has become an important source for all of us to borrow tools from. Do a www.google.com search for "CBT Tape" to find out more information about the CBT Tape collection. Today, I'd like to describe some of my own tools and ways of doing my own work. The first reason for choosing this topic is that most people pick up pointers to improve their working style, one pointer at a time. Watching me talk about my own methods, is very much like picking up one pointer at a time. Also, some of my own personal gimmicks are from the newer creations that have been contributed to the CBT Tape. If someone hasn't looked at a CBT tape or the cbttape.org web site for a while, these ideas might be new and useful to them. A second reason for choosing this topic, is to answer people's questions as to why some of the CBT Tape files are built the way they are. As proprietor of the collection, I have to make quite a few decisions about the content and structure of the files. And if people ask questions like why am I reluctant to delete old pds members from a file, I'd like to talk about that. Normally, I have to explain these things many times over to everyone who asks the same questions. HOW I SET MYSELF UP I have to admit that like most people, I am not "the complete innovator". I have invented a few of my own setup tools, but I have borrowed and adapted most of the session setup tools that I use. These have varied over the years. But I always angle the type of tools I want to use, in certain directions, even if the exact tool for a given purpose isn't the same one I used ten years ago. That's why I think that many of you might be able to pick up a pointer or two from watching me work. First, I have to state that in my position as the "system doctor", wherever I have worked, I insist on having access to as many APF authorized TSO commands as I feel I need. Sometimes a particular shop would try and restrict my access in certain directions. If it is to preserve their company data, I have always respected that. After all, I was hired to protect their installation and guard it, not to harm it in any way or to cause them unnecessary data loss or down time. But I feel that I am responsible enough to be trusted to fix any part of the system when a repair is needed. And I need access to my special tools for that. So to set up APF authorized access to special tools for myself, I try and get my own TSO LOGON PROC, or in a slightly worse case, to use the installation's "sysprog" LOGON PROC. The main thing I want from the LOGON PROC, is to have a STEPLIB with only an APF authorized load library in it. This allows me to accomplish what I call "personal APF authorization" of TSO commands and programs to be run under TSO. Details on what this gains for you, can be found on Files 185 and 186 of the CBT Tape collection. For space reasons, I don't want to elaborate any more about it here, except to say that if IKJTABLS is running from an authorized STEPLIB (either in the LOGON PROC or TSO-in-Batch), then it completely overrides the active global IKJTSOxx member in PARMLIB. Once I have access to my authorized library of TSO commands, I am pretty much "in business". But there is quite a bit more that I need, especially under ISPF, that will help me to get quick access to my arsenal of tools. For that reason, I want to customize my own ISPF command table, and do it quickly and effortlessly. I've had various ways of doing it over the years, but currently I use Willy Jensen's REXX execs, ISPCMDL, ISPCMDU, and ISPMSG from File 349 of the CBT Tape, to add new entries to the ISPF command table "on the fly". The way it works is that you code a member called ISPCOMND in your ISPF.ISPPROF pds, and put all the new ISPF commands you want to add, there. Then you invoke the REXX exec (which goes into your SYSPROC or SYSEXEC library concatenation) ISPCMDU to update the incore command table and add your special commands. Or you invoke the exec ISPCMDL to list your current active command table in storage. A sample ISPCOMND member to add to your ISPF profile dataset is included in File 349 of the CBT Tape. I'd strongly recommend that you look at it and see the enormous advantages that these extra commands give you, like being able to invoke any ISPF panel "on top of" any other work under ISPF that you're currently doing. A disadvantage to using this "on the fly" command update method is that the updates disappear whenever there is a severe ISPF error, and then TSO ISPCMDU must be invoked again, to reinstate your personal ISPF command environment. My personal answer to this, is to make "TSO ISPCMDU" easy to invoke. I do it by making a single addition to the static ISPCMDS ISPTABL member (which should be first in your ISPTLIB concatenation), to invoke only %ISPCMDU. The entry is as follows: CMDUPD 4 SELECT CMD(ISPCMDU) So by simply entering CMDU on the ISPF command line and pressing ENTER, I can always reinstate my ISPF command environment. In my LOGON CLIST, I include the command ISRPCP CMDU at the bottom, so the "invalid command" CMDU will appear at the top of my initial ISPF screen, and I only have to press ENTER to invoke it. This method of creating your own ISPF command environment is especially helpful in a large shop, where you don't want to "rock the public boat" by personalizing too much stuff that is in common libraries. Speaking of the ISPTABL and ISPTLIB libraries, most of you know this, but I'll just repeat the facts to refresh your memory. ISPTABL is the library concatenation which is written to, when you make ISPF 3.9 (command table) updates. ISPTLIB is the "reference library concatenation" which is read by ISPF when it searches for xxxCMDS members. So therefore, it pays to make your ISPTABL library which is first in the ISPTABL concatenation, also the first library in your ISPTLIB concatenation. That way, as soon as you make command table updates, they will be immediately effective. In my own place, I use my ISPF profile dataset pds as the first library in both my ISPTABL and ISPTLIB concatenations, so my personal updates remain personal. LOGON CLISTS VERSUS HARD-CODED LOGON PROC JCL I strongly prefer to allocate my TSO LOGON PROC datasets via a LOGON CLIST, rather than to hard-code the DD names of all the libraries in the LOGON PROC JCL. In fact, my ideal LOGON PROC looks very much like the "emergency LOGON PROC" that is shipped with new IBM MVS systems, but with four exceptions. The first is that I hard-code my APF authorized STEPLIB in the STEPLIB ddname. The second is that I prefer to use the TSO Session Manager instead of the normal TSO READY prompt, so I code PGM=ADFMDF03 in the EXEC card instead of PGM=IKJEFT01. The third is that I code a SYSPROC ddname that points to the clist library containing my LOGON CLIST which does the allocations. And the fourth is that I code a PARM='%myclist' in the EXEC card, to invoke my own LOGON CLIST that is in the SYSPROC library. The enormous advantage of a "sparse LOGON PROC" which uses mostly CLIST allocations, is that when one of the datasets to be allocated is missing, you only get an allocation error for one ddname, but you still have your TSO session in operation. If the missing dataset DD card had been hard-coded in the JCL, you would have gotten a JCL error when logging on to TSO, and so you would have no TSO session at all. To easily create a LOGON CLIST instead of the existing allocation method, just get into your current TSO session under ISPF and invoke ISRDDN. Then (for most later versions of ISPF) invoke the CLIST subcommand of ISRDDN. This will create a CLIST that will be a good starting point for making a personal LOGON CLIST to allocate the proper libraries for your session. So how do you fix a bad allocation when you don't have ISPF to edit the LOGON CLIST? I use an editor which works under "raw TSO" and which does not need ISPF at all. Three such editors are: RPF from Rob Prins, and RPF/E, which is the XA version of RPF. RPF resides on the CBT Tape collection in File 415. RPF/E resides in File 417. These two TSO-based editors are ISPF-like for FB-80 datasets, and they have extra utility functions which you are only used to seeing when you have ISPF up. These two editors (should) have identical functionality, but with RPF/E, since it uses the storage area above the 16M line, you can edit much larger datasets. So if you have a modern MVS system, RPF/E is the preferred editor to install. The other TSO-based editor is new in the REVIEW command, from CBT Tape Files 134 (source) and 135 (load). The newest REVIEW command from Greg Price doesn't only browse datasets without ISPF, it can now edit them too. Just REVIEW a single member or dataset and type UPDATE on the command line, to invoke the REVEDIT editor and edit that dataset. If you're in the REVIEW pds member list, type U (for UPDATE) next to any member, to edit it. REVEDIT, now an integral part of the REVIEW command, is also very ISPF-like in feel, although it doesn't (yet) have all the subcommands that the ISPF editor has. (Give Greg a little time.....) If you have one or more of these tools already installed on all of your systems, you can much more easily fix TSO problems and general system problems. I trust that one word to the wise, will be sufficient. A SMALL RACF TIP If I want to share my RACF database across several MVS releases, I update a common RACF database and its backup, with the highest MVS level RACF templates. And I point to these common databases using an ICHRDSNT module that I try and put into a linklist library at the highest possible concatenation level on each system. RACF at lower system levels is always built to understand a RACF database at a higher RACF level. Therefore I don't have to re-establish all of my permissions at each system level. I only use one set of common RACF databases at the highest MVS level, and do all the permissions only once. WHY I DO THINGS MY WAY, ON THE CBT TAPE I've been editing the CBT Tape collection for over 14 years now, and Arnold Casinghino before me, edited the collection for 15 years before that. During the last 5 years of Arnie's time managing the collection, I worked in fairly close collaboration with him. So between what I've learned from watching Arnie, and from my own experiences, I've developed a point of view which kind of encourages me to do things "a certain way". Of course if anybody thinks I should do things differently, I'm always willing to listen, and I've picked up a lot of suggestions from quite a few people over the years. One thing I do is to try and preserve old pds members. When someone sends me a new pds to update his/her file, I compare the new pds with the old one, and only update the changed or new members that the contributor sent me. I try to keep all the old members, unless the contributor expressly tells me to delete them. The reason for this is as follows: In managing the CBT Tape collection, I feel I have to "cater to all the world's needs". Some shops are running old versions of MVS, although after Y2K, almost all shops are past OS/390 1.2 or 1.3. But these were 16 or 17 releases ago, and a lot of water has already gone under the bridge, even since Y2K. So the older pds members in a package, which might be irrelevant for newer MVS releases, sometimes are needed to run the package or program on an older MVS version. Once in a while, a contributor, who himself is running some very new MVS version, loses sight of that fact, and deletes "irrelevant" members that are useless to him at his own shop, but not necessarily to others. To stay on the safe side of that, I keep old pds members, unless I'm explicitly told not to. The other big question concerns producing load modules. Most of the CBT Tape contributions are in source form. So at each installation, a person installing the package has to assemble or compile the modules and produce his own executable load modules. But for some of the packages, either for the purpose of quick installation, or because some shops don't have the required level of MACLIB, MODGEN or the assembler itself, I have to create these load modules myself. What are my general criteria when I do this? Please bear in mind that I have to cater to at least 17 levels of the operating system, if not more. If I'm assembling something, I try and use the latest MACLIB and MODGEN I have, unless they absolutely don't work for some reason, and then I have to revert to using an older set of macro libraries. I try to use the latest version of the assembler, though not necessarily the latest version of the Binder or linkage editor. Sometimes I'll even use HEWLKED instead of IEWL. HEWLKED is the pre-Binder old linkage editor, which is still shipped with z/OS. Usually the version of Binder or linkage editor doesn't matter, but the version of the assembler sometimes does matter. A "new" program like SHOWMVS (on CBT File 492) absolutely requires the newest assembler and macro libraries. But the load module will run on older systems, usually. (ShowZOS runs only in 64-bit mode, ShowMVS 7.09 runs on OS/390 and above, while ShowMVS 6.30 is required for older systems.) Therefore I feel it is a requirement for me to produce load modules that cater to the widest audience possible, and to make the tool available to as many people as I can. With the PL/I Optimizing compiler, the situation is opposite. Nowadays, there aren't too many PL/I contributions remaining on the CBT Tape, but the ones which are still there, like VSAMANAL (CBT File 294) and ASMTOZAP (File 044 for source, File 035 for load) are very important. In producing PL/I load modules, I use the OLDEST PL/I compiler I can get hold of. The reason for that, is also to cater to the widest audience. Some shops pay for PL/I run time libraries, but not for the compiler. New run time libraries will run old load modules, but not the other way around. So I produce old-style PL/I load modules with the oldest PL/I Optimizing Compiler version I can get hold of. CONCLUSION I hope this month's piece has been helpful to the widest audience possible (in keeping with my general outlook). All of the opinions expressed here are my own, but not necessarily ONLY my own. In my own work, I try to make what I do and the environment I create, as universally applicable as I can. And I try as hard as possible while doing my own work with as many tools as I can muster, not to impact the other users, and all the application programmers, in the shop. I isolate my own environment and try to keep it as private as possible. All the best of everything to everybody.... I hope to see you here again next month.