MVS TOOLS AND TRICKS OF THE TRADE July 1994 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer TWO TOPICS: THE REBIRTH OF IEHMOVE, AND USING A JES2 EXIT LOADER. Sometimes IBM gives up on one of its old tools. It's a "pig", they say. (Its performance is not very good.) It is hard to use; it has very awkward control cards. We sell something better to perform the intended purpose of this original tool (and so does somebody else). Therefore, perhaps we should give up, and drop support for this old piece of junk. All of this is true, concerning the old IBM utility called IEHMOVE. It is very slow and consumptive of CPU and I/O resources. Its control cards are next to impossible to tame. IBM sells something much better for the intended purpose of moving multiple datasets from one pack to another (DFDSS copy). And a competitor also sells something much better for carrying out IEHMOVE's original purpose (FDRCOPY). So should IBM trash it's old piece of junk? We will answer with a resounding "NO". IEHMOVE has a reason to live. We have fully entered the PC age. The topic of saving mainframe-type datasets to diskette, is often brought up. All kinds of schemes for diskette downloading of mainframe files have been brought forward. And IEHMOVE has turned out to be an excellent tool to accomplish this modern-day task. The saving feature which IEHMOVE has, turns out to be its amazing ability to convert many MVS-supported dataset types into sequential card-image format. Sequential fixed block 80-byte card image files are ideally suited for downloading to a PC file. And if the IEHMOVE-converted card file is downloaded without translation (leaving out the ASCII and CRLF keywords), it can be PKZIP-ed and stored in a relatively small PC file. For reloading to mainframe, the file need only be PKUNZIP-ed on the PC, uploaded without translation to a (FB-80, blocksize 800) mainframe file, and good old IEHMOVE will re-convert this file into exactly its original format, without any distortion, and doing all the dynamic allocations necessary. What an idea! It works very nicely. See Figures 1 and 2 for sample JCL to use IEHMOVE for this purpose. Figure 1 shows how to convert a PDS to IEHMOVE sequential fixed block format. Please be reminded that IEHMOVE control cards and ddnames are very strange, but this JCL has been tested to work. Also remember that the blocksize of the sequential dataset always has to be the antiquated value of 800 bytes per block. There is an additional restriction that the target sequential file cannot reside on an SMS-managed volume, although the original file or pds can be managed by SMS. Figure 2 shows how to use IEHMOVE to load the sequential card-image dataset back into its original form. The original pds can even contain load modules or variable blocked data, and IEHMOVE does the format conversion and dataset allocation automatically. I am very impressed with this technique. My initial exposure to it was when someone made a contribution to the CBT Tape on a diskette that was in this format. Load and source libraries were faithfully reproduced from the diskette which I received. Downloading and uploading distortion was nonexistent, because there was no character translation, and the 80-byte card images are downloaded and uploaded nicely by most PC-to-mainframe connections. IEHMOVE is far more reliable than IEBCOPY for this purpose, because the variable blocked IEBCOPY unload records do not download and upload reliably to the PC. It looks as though IEHMOVE has found its niche in this modern age. We should all try and lean heavily on IBM not to drop support for IEHMOVE, our new-found friend. And now to the next subject. USING A JES2 EXIT LOADER. Many shops run JES2 with user exits. In fact, JES2 exits are the "official" IBM way of getting around the headaches caused by installations creating their own mods to JES2 main code. IBM's practice of providing exit points in many strategic places during JES2 processing, has made life relatively easier for systems programmers working in this general area. For one thing, you don't have to refit your mods whenever IBM changes their large main routines. Usually, your exit programs are smaller, and they are self-contained. Although some of the user exits might be dependent on other exits at your installation, all of the "user-stuff" is found together. It can therefore be modified in a concentrated effort when changing JES2 releases. That doesn't mean that life is peaches and cream during JES2 release conversions. JES2 exit coding techniques are far from being release-independent. For example, when IBM changed the format of the JES2 Load Module Table, any exits which looked at the LMT during their processing, had to change their mode of access. Similar considerations would apply for any other JES2 control blocks that might change (and many of them do change). Two notable recent examples are the Network Job Header (NJH) and the Remote Destination Table (RDT). The systems programmer who writes or modifies JES2 exits must be aware of many issues involving JES2 internal functioning, and must be awake to all major re-architecting that was done for a new JES2 release. That is why IBM emphasizes that novices in JES2 should not be coding JES2 exits unless they proceed very carefully, and with the advice of more advanced personnel. One major fact about JES2 that systems programmers should know, is that different parts of JES2 function in different arenas. Much JES2 code operates in the JES2 address space. Some JES2 code runs in common storage, such as the Link Pack Area. Still other JES2 code runs in the user's address space. There is communication between these parts by various mechanisms. However, the relevant point is that when one codes a JES2 exit, one must be extremely aware of the surroundings and environment in which this particular exit operates. Each environment has its own rules. The JES2 Customization manual is the place to look for such information. Nowadays, in the later JES2 releases, this is taken a bit further. You can specify in JES2 startup parms, whether a particular exit module is to be loaded in the JES2 address space, or in LPA, or in CSA. This gives the user an added piece of control. We now come to our main question. What happens when a JES2 exit doesn't work properly? Ideally, we would like to plug in a new version without disturbing any other JES2 operations. We don't have that from IBM, at present. The current IBM mechanism allows for enabling or disabling of any exit routines. For example, if you have an Exit 5 Routine (which does JES2 command modification) installed, you have the choice of keeping it in (enabling) or taking it out (disabling). If you have two Exit 5 routines, you must either enable them both, or disable them both. You don't have the ability to disable or modify one routine. To actually change the version of one Exit 5 routine, you have to stop the JES2 address space, change the routine in the Link List, refresh LLA, and then Hot-Start JES2. This can be very upsetting to a shop's operation, and it is usually done only in a crippling emergency situation. The situation is even worse for LPA- or CSA-loaded exits. These exits need a complete IPL to make changes. There is currently a SHARE requirement for IBM to create an "exit loader" command, whereby one can refresh a single JES2 exit module with a new copy. IBM now has no such thing. However, the user community has a partial solution which works very well. For user exits that operate in the JES2 address space or in the converter subtask, there is a program which supports dynamic exit refreshes. This program itself is a JES2 exit. (It happens to be an Exit 5 routine.) And it can piggyback nicely with any other JES2 Exit 5 routines you happen to be running. When this program is operational, the operator (or preferably the systems programmer) enters a $LOAD command, followed by a fill character and the load module name of your exit routine. If the JES2 Load Module Table "knows" about the module name you entered, the current Link List will be searched for a fresh copy, and that version will be plugged in and used instead of the previous copy. If the module name is not in the JES2 LMT, you get a console error message, and no action is taken. This is the result that we want. The new version of the module becomes usable immediately. INSTALLING THE EXIT LOADER. Where can this program (the Exit Loader) be found, and how is it installed? The answer is that it depends on the version of JES2 you are running. Various versions of the JES2 Exit Loader can be found on several files in the CBT MVS Utilities Tape. You can obtain a copy of the CBT Tape from NaSPA. For JES2 Version 4, there is a suitable version of the Exit Loader on File 196 of the CBT Tape. A JES2 Version 2.2.0 level of the Exit Loader is on File 381 of the CBT Tape. The Exit Loader, being a JES2 exit itself, must be assembled against your current level of the SMPMTS and SYS1.HASPSRC, as well as against the current SYS1.MACLIB and SYS1.MODGEN. After it is placed into a Link List library (preferably as an SMP usermod), the JES2PARM JES2 initialization deck has to be modified with LOADMOD and EXIT(5) statements, as in Figure 3. When JES2 is then brought up after an IPL, you can issue a $DEXIT5 command to display if the proper exit routines are being used. In JES2 Version 4, you can also use a command $DMODULE(J005LOAD) to see if your preferred level of the Exit Loader (or any other JES2 module) is currently being used. LIMITATIONS OF THE EXIT LOADER. The JES2 Version 4 levels of the Exit Loader are not intended to load CSA- or LPA-resident JES2 exits. Coding for that type of exit loading is considerably trickier than what we have here. Of course, we would prefer if IBM completely supported the process of dynamic exit loading. The SHARE requirement for this has high priority, because for 24-hour operation of a data center, it would be very helpful to have complete dynamic replaceability of JES2 exit code. But it isn't here yet, folks. We have to do what we can now, using our own Exit 5 routine. And we have to keep up our pressure on IBM, especially through the SHARE organization. The SHARE JES2 requirements coordinator is David Dyche, 713-596-2466, and his Internet address is dd@chevron.com . CONCLUSION. IBM, as a software service organization, gets considerable input from innovative users of their software offerings. Today, we have seen two examples showing why it is up to us, as users, to prevail upon IBM's thinking. In the first case, who knows whether IBM would ever tout IEHMOVE as an aid to diskette preservation of mainframe data (and fix some of its inefficiencies). In the second case, a glaring omission in JES2 exit functionality for the current day and age, has clearly shown itself. Let's raise our glasses (after we write our letters to the SHARE JES2 Requirements coordinator) in the hope that IBM wakes up to these valid customer needs. Meanwhile without IBM's further help, we've got a bunch of new ideas to think about and add to. Good luck in the thinking and adding activities. See you next time. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. This is IEHMOVE JCL to unload a cataloged partitioned dataset into IEHMOVE format, ready for downloading to PC. For an uncataloged pds, you have to consult your DFP Utilities manual. I've tried this JCL, and miraculously, it works. To put a sequential dataset into FB-80 format, use the keyword "COPY DSNAME" instead of "COPY PDS". //SBGCSCR JOB (A006,SYTM,99,99),S-GOLOB,REGION=8M, // CLASS=S,MSGCLASS=V,NOTIFY=&SYSUID /*DIST ROOM-25 //* --------------------------------------------------------------- *// //* -- JCL TO UNLOAD A PARTITIONED DATASET TO AN IEHMOVE -- *// //* -- FORMAT SEQUENTIAL DATASET THAT IS FIT TO -- *// //* -- BE DOWNLOADED TO A PC HARD DISK OR FLOPPY. -- *// //* --------------------------------------------------------------- *// //MOVE EXEC PGM=IEHMOVE,PARM='POWER=4' //SYSPRINT DD SYSOUT=* //* //DD1 DD DISP=SHR,DSN=SBGCSC.A.LOAD //* DD1 is "FROM" PDS and can even be on an SMS-MANAGED volume. //* //DD2 DD DISP=SHR,DSN=SBGCSC.A.DATA //* DD2 is cataloged dataset on a NON-SMS-MANAGED volume, //* where the TARGET DATASET is to reside. //* //SYSUT1 DD DISP=SHR,DSN=SBGCSC.A.DATA //* SYSUT1 is a cataloged dataset which determines a volume //* where the WORK DATASET resides. //* //SYSIN DD * COPY PDS=SBGCSC.A.LOAD,UNLOAD, X TO=3390=ACS001,RENAME=SBGCSC.A.LOAD.IEHMOVE,CATLG /* * * * * * * * * * * * * * * * * * * * * * * * Figure 2. This is IEHMOVE JCL that takes an unloaded dataset in IEHMOVE format, and converts it into an exact copy of the original dataset or pds, blocksize and all. //SBGCSCR JOB (A006,SYTM,99,99),S-GOLOB,REGION=8M, // CLASS=S,MSGCLASS=V,NOTIFY=&SYSUID /*DIST ROOM-25 //MOVE EXEC PGM=IEHMOVE //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,UNIT=SYSDA,VOL=SER=ACS001 //FROMDD DD DISP=SHR,DSN=SBGCSC.FILE183.IEHMOVE //TODD DD UNIT=SYSDA,VOL=SER=ACS001,DISP=SHR //SYSIN DD * COPY DSNAME=SBGCSC.FILE183.IEHMOVE,FROMDD=FROMDD,TO=3390=ACS001, X RENAME=SBGCSC.FILE183.PDSIN /* * * * * * * * * * * * * * * * * * * * * * * * Figure 3. These are sample user exit statements that must be added to the JES2 startup parm deck. The LOADMOD statements instruct JES2 to look in a link list library to find load modules having the given names. The EXIT(nn) statements tell JES2 to look in the loaded modules and find entry points matching the stated names. In a JES2 module, an entry point is coded as a label to a $ENTRY macro. For instance, the load module J005LOAD has a $ENTRY macro coded, whose label name is E005LOAD. LOADMOD(JES2X04) /* Exit 4 - JCL and JECL scan */ LOADMOD(JES2X05) /* Exit 5 - JES2 command mods */ LOADMOD(J005LOAD) /* Exit 5 - Jes2 Exit Loader */ EXIT(4) ROUTINE=EXIT4, STATUS=ENABLED, TRACE=NO EXIT(5) ROUTINES=(EXIT5,E005LOAD), STATUS=ENABLED, TRACE=NO