MVS TOOLS AND TRICKS OF THE TRADE July 1998 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. When IBM Says You Can't... Sometimes You Can Everyone in the computing field must live with limitations. For example, application programmers feel constantly hemmed in, because their authority to access the installation's data is always being limited by the security system. We systems programmers also experience that feeling to a lesser extent. But such a limitation, however irritating, is not necessarily bad. It stops people from destroying or altering mission-critical data that they shouldn't have access to. In contrast, here's a different kind of limitation, which in my opinion, is a very bad thing. Sometimes you wish you had a utility to perform a certain function, but you're told that such a utility doesn't exist. My answer is that it's not necessarily true. In fact, it might be amazingly easy to write an assembler program or a REXX exec to do exactly what you want to do. Furthermore, someone else might have already done the work. When you experience this frustration, you can often do something about it, and it's legitimate for a systems programmer to refuse to permanently accept that kind of limitation. In truth, many IBM "no-no's" are actually doable. Often, if you sit down to do the research concerning the internal structures that you want to manipulate, you'll see that there's nothing to prevent you from writing a program to do the job. I have surprised myself by having done some fairly clever things which I never thought that I could do. My SYS1.BRODCAST manipulation package (CBT Tape - File 247) is an example. IBM says you can't display and clear other people's messages from the SYS1.BRODCAST dataset. I wrote a bunch of utilities to do it easily and safely. Of course, this took time. It follows, that our problems could be solved if we could all divide the work, and share the results. Well guess what? There are already large collections of free utilities already available, and they are being added to. One of the biggest single collections is the CBT MVS Utilities tape, a huge collection that's independently produced, and it's available from the NaSPA office and other sources. Once you are in possession of a CBT tape of your own, you can make copies for all your friends (using a utility that's on the tape--the COPYMODS program on File 229). There are many other such free collections. A file on the CBT Tape itself (File 071) contains the documentation files for a large number of them. Let's look at another specific example. IBM says you can't add directory blocks to a partitioned dataset, without reallocating the dataset (with more directory blocks) and copying all the members from the old partitioned dataset to the new one. There is a RACF drawback to having to allocate a new pds and delete the old one. You need ALTER access to the dataset name. Upon studying the situation, one can see that it doesn't have to be that way. If you could only be able to move some members from the beginning of the pds to the end, and reformat that space from the beginning into new directory blocks, you wouldn't have to reallocate a new dataset; you could reuse the old one, and you'd only need UPDATE access, not ALTER. This could save a programmer a lot of trouble. Well, there exists a free utility which does this. You point the utility to the pds, tell it how many more directory blocks you want, it tells you which members have to be moved to the end, and asks you if you want to continue. When you say yes, the members get moved, and the directory gets extended. It's that simple, and the process works very reliably. As I mentioned, the utility only requires UPDATE security access to the dataset, you don't have an enqueue problem deleting the dataset, and this utility does not have to run APF authorized. Where is this magic bullet? It's actually something I've mentioned many times in this column. It's the "PDS" program package that can be found on File 182 of the CBT MVS Utilities Tape. The PDS package (and its vendor-supported successor called STARTOOL from Serena International) actually performs many more functions that IBM says are impossible. And the CBT Tape as a whole, has many more utilities than just the PDS program package. Once the PDS program is set up (it runs as a TSO command), you point it to the dataset you want to change. Then you enter the subcommand: FIXPDS EXPANDDIR(nn), where nn is the number of directory blocks you want to add. The PDS command then comes back with a prompt, listing which members would have to be moved, and asks if you want to continue. If you reply "Y" or "YES" to the prompt, PDS moves the members, reformats the additional directory blocks as you requested, and reports the new number of free directory blocks that the pds now has. So much for IBM's limitation. ADDING A NEW DATASET EXTENT, AND OTHER JOBS I mentioned that the "PDS" package will do other things that IBM says you can't. One of them, is to add a new extent to a dataset, no matter what the FORMAT 1 DSCB (i.e. VTOC entry) says about how much the secondary space of the dataset is set to. Even if the dataset is marked that the secondary space is zero tracks, you can add a new extent as big as you want. You simply point the PDS command to the dataset as mentioned before, and enter the subcommand: FIXPDS ADDTRK(nn) or FIXPDS ADDCYL(mm), and PDS will obediently add a new dataset extent of nn tracks or mm cylinders, as it was told. PDS doesn't have to run authorized to do any of this. It does some other tricks, most of which you could probably also do, if you "misuse" JCL. Suppose you've pointed the PDS command to a dataset. You can enter FIXPDS RECFM(xx) or FIXPDS LRECL(rr) or FIXPDS BLKSIZE(bbbb), and the PDS command will listen to you, after you've answered "YES" to its prompt. These alterations to a dataset sometimes have to be done, under some special circumstances, and I'll show you one. This modern example involves FTP. I've discovered that I can FTP to an MVS computer site that has an Internet connection, from my home pc. I can often get to MVS by telling the pc FTP program my TSO userid and password. Suppose now, that someone has FTP'ed a downloaded pds to me, that's in TSO XMIT format, which has to be LRECL 80, and I want to upload that pds to this MVS system. I simply FTP from my pc (through the pc's FTP program) to the MVS TSO account, and upload the file. It's not so simple. In order for the TSO RECEIVE command (the opposite of TRANSMIT, or XMIT) to reconvert the file into a pds that's the image of the original pds from the sending system, the file has to be LRECL 80. RECEIVE only "understands" an XMIT file with LRECL 80. However, my pc FTP program only sends the file to TSO in blocks of 4160 bytes, and the resulting file is marked on MVS as having LRECL 4160 and BLKSIZE 4160. 4160 is a multiple of 80, and actually, all the data is intact on MVS. Only the "official LRECL" or "marked record length" of the data is wrong. As we said, RECEIVE can't restore this file as it's marked. However, we just point the PDS command at the file, and say: FIXPDS LRECL(80). Voila, the data is marked LRECL 80, BLKSIZE 4160, and it's usable by the RECEIVE command. Quick and straightforward. Wow! MORE ON CHANGING DATASET ATTRIBUTES There's another free utility that can change dataset attributes. This one is called CDSCB (or "Change the DSCB"), and it is a TSO command that must run authorized. CDSCB can be found on the CBT Tape on File 300. CDSCB has to run authorized, because it zaps VTOC entries directly, as opposed to the PDS command, which works by writing a dummy addition to a dataset while forcing DCB attributes to the dataset, like you can do using JCL. CDSCB was written by Bill Godfrey, with the idea that if you're changing a dataset's attributes by zapping the VTOC, you want to be safe, and not change the wrong VTOC fields. CDSCB makes the process more foolproof. CDSCB can also be run under TSO-in-BATCH. You can get the APF authorization in batch, by running CDSCB from an authorized library, and mentioning that library as a single STEPLIB dataset. I've used CDSCB to add larger amounts of secondary space to a whole volume full of IBM datasets. As most of you probably know, IBM's shipped dataset allocations only contain barely enough space to hold their shipped data. If you have a lot of maintenance to APPLY or ACCEPT, you can get many annoying utility failures due to inadequate secondary space and inadequate allocation of directory blocks in the IBM datsets on the DLIB and TARGET packs. Through using CDSCB and the PDS command under TSO-in-BATCH, I can get a mass SMP/E APPLY or ACCEPT job to run, even though a lot of material has to be added to the target libraries or the DLIBs. Here's how. Obtain a list of all the datasets on the DLIB or TARGET pack. Then edit the list of names, to say the syntax: CDSCB 'SYS1.whatever' SPACE(30) ALLOC(TR) VOL(volser) for each dataset name. This will force the "official" secondary space allocation to be 30 tracks for all the datasets. If the dataset happens to be large, or to need much additional space, you can edit the settings in CDSCB for that dataset to be larger. If you want to force secondary allocation in cylinders, just substitute SPACE(2) ALLOC(CY) for SPACE(30) ALLOC(TR). If CDSCB ran successfully, it will display the message: "CHANGED" after each invocation. Otherwise it will say "NOTHING CHANGED". To add more directory blocks to all the datasets on the pack, you can run the PDS command under TSO-in-BATCH. The proper commands will take up at least 2 lines per dataset. The first line will state: PDS 'SYS1.whatever' . The second line could state: FIXPDS EXPANDDIR(30) to add 30 directory blocks to each of the datasets. Under TSO-in-BATCH, PDS answers the "YES" prompt automatically. You could add a third line for some of the datasets that don't have enough space: FIXPDS ADDTRK(60) , which would physically create a new extent of 60 tracks for that dataset, and not just mark the potential size of a future new extent, as the CDSCB "SPACE" keyword does. At the end of this process, you should have a whole pack full of adequately allocated system datasets, and your mass APPLY and mass ACCEPT troubles will be solved, or will be much more easily handled. Of course, make sure that there is enough actual free space on the whole volume, so your system datasets have room to expand, if necessary, during the SMP/E run. A JES2 EXIT LOADER Anybody who writes JES2 exits, knows that IBM says you have to recycle JES2, or IPL, in order to change which VERSION of a particular JES2 exit you are running. IBM does supply a system command to ENABLE or DISABLE a particular JES2 exit. But if you DISABLE and then re-ENABLE one particular exit, you always get the same version. You can't plug in a new version of a particular JES2 exit, unless you bring JES2 down and up again, or re-IPL. As least IBM says you can't! Who has a problem with this? The system programmer who is testing a new JES2 exit, or is modifying one. To try out a new fix, you have to disturb everyone on that particular system by recycling JES2 or IPLing. Even if you're testing your exit on a test system, there may be many other programmers testing their stuff at the same time, and you'll be disturbing their work. If you know JES2 internals to some extent, the situation is not insurmountable at all. The reason why you can't change versions of an exit, is that JES2 points to its load modules (including the modules belonging to the various exits) with an address table, called the LMT, or Load Module Table. The LMT contains address entries, which point to the entry points of all the JES2 modules. IBM simply doesn't provide a facility to re-point an LMT entry to a different module, without a restart of JES2. If you could write a program to create a new copy of the JES2 exit program in the proper environment: the JES2 address space, or the CSA or LPA areas of common storage, and re-point the LMT entry to the new copy, you've basically solved the problem, minus a few details. You could code your program as a JES2 Exit 5 routine (JES2 command modification), so it could be invoked from the console as a new JES2 command. IBM has refused all suggestions to release a "dynamic JES2 exit loader program". I'm not sure why. One guess would be that IBM doesn't want to take responsibility that someone might irresponsibly disturb production processing by altering the version of an exit that's running. That doesn't seem to be so likely, because even today, an operator can disable any JES2 exit with a command. In any case, IBM has left the poor system programmers who code JES2 exits high and dry. Not any more. There's a partially effective JES2 exit loader program on File 196 of the CBT Tape. That (File 196) exit loader will load a new version of any JES2 exit that runs in the JES2 address space environment (which includes many of them). Until now, the public didn't have an exit loader available, that would work for exits in all JES2 environments--CSA and LPA included. Now, an expert JES2 programmer, Bob Break, has written a fully functional JES2 exit loader program, which is currently on the JES2 SHARE Tape (from Jack Schudel of the University of Florida - schudel@ufl.edu) and which will shortly be on Version 418 of the CBT Tape, soon to be released as of this writing. Our problems are solved! At this point, before closing, I'd like to add that there are many more things that IBM says you can't do, but which you can. If you have such a question, look at the CBT Tape documentation on the web, or subscribe to the IBM-MAIN newsgroup (see this column, Apr 98), and ask your question. With persistence, you'll find someone who can point you in the right direction. Good luck. See you next month.