MVS TOOLS AND TRICKS OF THE TRADE September 1990 Sam Golob MVS Systems Programmer sbgolob@cbttape.org SMP/E HACKING EXAMPLE - REGRESSING VTAM, PART 2 This month, I'd like to continue with last month's topic that we had to split between two issues. I personally do not like to split a topic. Our column has two specific goals at all times. I feel that a division of one topic into two pieces must not interfere with these two central goals that we have set. First goal: this column is here to provide self-contained solutions to specific problems. If a reader picks up an issue of the magazine that has the second installment of a split, there is the danger that he or she might be missing essential information that was in the first installment. Thus, our objective of providing "the practical and whole solution" would not be achieved properly. I believe that in our specific case, we have minimized this problem. The second goal of the column is: THAT ANY SYSTEMS PROGRAMMER FROM ANY MVS SHOP SHOULD BE ABLE TO GAIN SOMETHING FROM LOOKING AT THIS "MVS TOOLS" COLUMN, ANY MONTH. To illustrate, this goal made a difference during the month we talked about spool browsing tools. I mentioned SDSF and the QUEUE and IOF products for JES2, but our goal required that we shouldn't exclude programmers from the JES3 shops. Therefore I was forced to write about the magnificent JES3 "Spool Display Facility" product, which is available for FREE on the JES3 SHARE Tape (from Alan Field, (612) 828-4979.) Sticking to this requirement as much as possible, is part of our public service. Now, let's return to the topic at hand. We began last month, to explain how to regress a "too high" version of VTAM from our new CBIPO-generated MVS/XA 2.2.3 system. Our shop needed to use the version of VTAM that we had on our old MVS/370 1.3.5 system. We knew, by asking IBM, that the older version would also run under XA 2.2.3. We were not willing to pay the extra money for a newer version of VTAM. IBM refused to ship us the older VTAM with the CBIPO. The older VTAM was still supported, however. Our problem was to first install the CBIPO with a newer VTAM on free trial, and then remove the new VTAM to replace it with the VTAM version from our old MVS/370 system. Why would a programmer at a "richer" shop want to know this stuff? I've chosen to write about such SMP activity, because I feel that the skills required in performing this action are a necessary part of the MVS system programmer's repertoire. One has to know how different components interface with the operating system as a whole. The activity of "regressing releases" of a component such as VTAM lends invaluable insight into its interfacing structure. Regressing is a better learning experience than merely installing, SIMPLY BECAUSE IT IS NOT AUTOMATIC, the way a straight install would be. One learns a lot more through the manual intervention. At this point we should state that a knowledgeable reader of EITHER last month's or this month's issue can actually accomplish the entire procedure by himself. A reader of last month's installment could see THE ENTIRE PROCEDURE IN OUTLINE FORM, BY LOOKING AT THE SIDEBAR ILLUSTRATION. The text of last month's column served to provide an explanation of the underlying fundamental principles. THE SAME SIDEBAR ILLUSTRATION IS ALSO PRINTED THIS MONTH, but the accompanying text and further figures will explain specific details of the procedure, plus the few "gotchas" to watch for in carrying it out. The complete story is told in both issues taken together, but a full outline of steps has been included in either issue separately. So, we can resume our discussion where we left it last time. WHAT HAD TO BE DONE? We start our scene with two sets of SMP/E zones and the libraries they control. One set is our old MVS/370 system, and the other set is our new MVS/XA CBIPO-installed system. VTAM 2.2 (fmid HVT2202) is installed on the MVS/370 system. VTAM 3.2 (fmids HVT3205 and JVT3215) is installed on the MVS/XA system. Our job is to transplant VTAM 2.2 from the MVS/370 system to the MVS/XA system after having gotten rid of VTAM 3.2 first. We stated last time that there are physical modules belonging to each VTAM version. These are stored in libraries. There are corresponding SMP/E control entries in the SMP/E VSAM "zones". Their purpose is to account for each piece, or element, of the VTAM component in each SMP environment. Both the physical VTAM modules and their SMP/E control counterparts must be faithfully transplanted from the 370 environment to the XA environment. We must make sure that VTAM 2.2 will work as IBM designed it to work under XA, and its SMP/E control entries appear as though they were installed together with XA. The process is complicated by the fact that VTAM is not a stand-alone product; it interfaces with other components of the operating system. Those components, and the way they fit together, are different in MVS/370 and in MVS/XA. We must therefore decide how the old VTAM 2.2 should interact with the new MVS/XA components. Our method of action may be summarized by the following principle: Any stand-alone "pure VTAM" load module will have the same structure under XA as it had under 370. This is because that piece DOES NOT INTERACT with non-VTAM components which have changed. On the other hand, any part of VTAM which is linkedited together with non-VTAM components THAT MAY HAVE CHANGED FROM MVS/370 TO XA, should have its corresponding pieces from VTAM 2.2 FITTED INTO THE NEW LINKEDIT PATTERN. This is so that the rest of the operating system components, exclusive of the VTAM part, may behave exactly as they had behaved before the transplant. HOW DID WE ACTUALLY DO IT? The key to our actions is in the SIDEBAR outline. There are fifteen general steps to the procedure. These steps can be followed as stated. The rest of this article will merely supply "fill-in" details and comments, as we feel they are needed for clarity. Step 1, ACCEPT processing on the old system, may have to be done. The transplanted VTAM component will be constructed from elements in the distribution libraries, so these must be at maintenance levels consistent with the level of the target libraries. If necessary, we must run an ACCEPT job on the old system. This will make sure that the distribution libraries have their building blocks at a level consistent with the level of the working target library system. Step 2, creating pack backups and/or dataset backups, is always sound policy when dealing with SMP-controlled systems. One should back up both the 370 and the XA SMP environments. Probably, full pack backups are the easiest to restore if needed. Steps 3 and 3A, SMP/E "UNLOAD" processing, put the SMP/E element structure of the respective VTAM versions into transportable form. The actual zone entries are reduced to UCLIN statements that can be reloaded into another SMP/E zone later. All this is accomplished by the SMP/E UNLOAD process, as directed to the entries in each zone, for the respective VTAM fmids. Please note that since we are moving the VTAM 2.2 entries, we do not really need the VTAM 3.2 entries. But it is best to have them for safety, since after VTAM 3.2 is deleted, their source will be gone. Steps 4 and 5 need to be detailed more. The output of the SMP/E GENERATE in the case of VTAM consists of two parts: a COPY part and a LINKEDIT part. Further, the LINKEDIT part is broken into several JOBS, each of which updates ONE LIBRARY only, such as LINKLIB, LPALIB, NUCLEUS, and VTAMLIB. There's a small "gotcha" here. In order for the GENERATE job to produce proper DDNAMES for its output jobstream, all DDNAMES have to have been defined to each zone by means of DDDEFs. Defining the DDNAMES in a hard-coded JCL "SMP procedure" will not work. GENERATE can only formulate DD statements out of the DDDEF entries in the ZONE. Fortunately, it is quick and easy to construct a batch job that will accurately define necessary DDDEF entries in each ZONE (via UCLIN). After the GENERATE jobs in Steps 4 and 5 have been run, two sets of two decks should be available: a COPY stream and a LINKEDIT stream from the old VTAM (HVT2202), and a COPY stream and LINKEDIT stream from the new VTAM (HVT3205 and JVT3215). In step 11, which is the crucial step, we shall produce a combined COPY deck merged from BOTH COPY DECKS. We shall also produce a combined LINKEDIT deck made out of pieces of both LINKEDIT decks. Now look at Figure Four which shows the dummy FUNCTION DELVT32 that will delete both FMIDs for VTAM 3.2. This FUNCTION, when APPLYed, will delete all VTAM-based elements (modules) from the entire operating system, wherever they reside in the TARGET libraries. In the APPLY utility report for DELVT32, LINKEDIT output showing REPLACE cards for the VTAM modules in IEANUC01, SVCs 34, 93, and 94, and other mixed-FMID load modules will appear. Examination of equivalent VTAM 2.2 modules will show that identical module names from the earlier VTAM release could slip into all of the old VTAM module slots in the mixed-FMID load modules. (It helps to have this information for the crucial Step 11 later.) ACCEPT processing for DELVT32 will wipe the XA DLIBs completely bare of all VTAM modules. These VTAM modules will be the release 3.2 versions. Keep this ACCEPT report around, but it is not needed as much as the APPLY report for our purposes. I did Step 7 to guarantee that I'd copy ALL the necessary DLIB members for VTAM 2.2 from the 370 system DLIBs to the XA DLIBs. My method for accomplishing this has its dangerous aspects, and there is probably a better way. I'd appreciate if a reader would inform me of an better method of determining exactly the correct DLIB elements, discovering possible ALIAS conditions, and accomplishing the physical transfer exactly. I'm about to submit a SHARE requirement to SMP/E development so that SMP/E itself might be made to produce its own "FORFMID library reports" in the future. Step 7 involves doing an APPLY CHECK of a dummy FUNCTION DELVT22. This FUNCTION is RECEIVEd in the 370 SMP GLOBAL ZONE. It aims to delete VTAM 2.2 (HVT2202) and is therefore dangerous. It must not be run for real. Its purpose is to obtain a list of all element names in HVT2202, together with the name of the DLIB that each element resides in. This is of course, a fake delete. A real delete of VTAM 2.2 would be disastrous. Figure Six shows part of a copy job which I derived from this report. This job copies exactly the correct elements from the 370 DLIBs to the XA DLIBs. Remember though, that SMP ELEMENT listings do not show any aliases, and the presence of aliases must be determined by other methods. I used the "PDS" product to make sure that none of the DLIBs had alias members that belonged to VTAM 2.2. I did this by making a member list under ISPMODE consisting of the VTAM 2.2 modules for each DLIB, and then entering option "5" from the PDS(/E) memlist. This picks up all aliases of members in the group, if any. In our case there were none. Look also at Figure Five. Step 9 actually deletes VTAM 3.2 from the XA system. As I stated, the most important report produced is the utility report from the APPLY job, which has the linkedits of the load modules with "mixed FMID". Step 10 has to be done so the UNLOAD UCLIN from the 370 DLIB and TARGET ZONES will slip smoothly into the XA DLIB and TARGET ZONES. In the XA system, there is a SYSMOD entry for HVT2202 in both the TARGET ZONE and the DLIB ZONE showing HVT2202 as having been deleted by HVT3205. These "bad" SYSMOD entries must be deleted with UCLIN, so that the real SYSMOD entries for the actual FUNCTION HVT2202 can be inserted later. Step 11 is the most crucial step. The problem is to determine how a VTAM 2.2 install would have fitted into the XA system. The main principle to follow is this: VTAM 2.2 load modules which stand alone, and are not mixed with modules from any other FMID, will go into the new system as they went into the old one. Therefore "pure" VTAM 2.2 JCLIN comes only from the 2.2 GENERATE output. The "mixed FMID" JCLIN has to look like the 3.2 GENERATE output, because that output will reflect both the MVS/XA system load modules and the higher version of TSO/E in the XA system. Therefore, I spliced the two sets of decks together cautiously and carefully according to this principle. Again, see Figures Six and Seven. The pieces of linkedit GENERATE coming from the NEW system should correspond exactly with the APPLY utility report that deleted VTAM 3.2 from the NEW system. The rest should come from the OLD system. In Step 12 I physically copied the VTAM 2.2 elements from 370 DLIBs to the now stripped XA DLIBs. In Step 13 I ran the actual hybrid COPY and LINKEDIT decks to create the TARGET modules out of the DLIB modules. This created the physical modules for VTAM 2.2 within the XA system, and the XA libraries would actually be usable in an IPL at this stage. But SMP in the XA system would not yet know about VTAM 2.2. Step 14 would now have to be carried out to load SMP with VTAM 2.2 information. The UCLIN-format module information from the DLIB ZONE UNLOAD from 370, is now UCLINed into the DLIB ZONE of the XA SMP system. Similarly, the UNLOAD deck from the old TARGET system is UCLINed into the XA TARGET ZONE to inform it about all of its VTAM 2.2 elements. Finally our composite hybrid GENERATE deck reflecting how the VTAM 2.2 load modules will fit into XA, is JCLINed into the XA TARGET ZONE. The JCLIN processing will inform SMP about the linkedit structure of all load modules involving VTAM-owned parts. At this point, SMP in the XA system now "knows" about VTAM 2.2 at its present maintenance level. You must check carefully for errors at each step and fix them as they occur. I had to revise some of my original methods because of errors that occurred while those things were being done. Well that's about it for now. Ponder these items carefully. They take a good deal of thought to understand properly. Good luck. See you next month. * * * * * * * * * * * * * * * * * * * * * * * SIDEBAR. Procedure steps to accomplish the replacement of VTAM 3.2 on an MVS/XA system with VTAM 2.2 transplanted from our previous MVS/370 system. 1. Do ACCEPT processing on the 370 system for all HVT2202 PTFs that have been APPLYed. This will load the DLIBs with the VTAM 2.2 elements at the highest "clean" levels. 2. Back up all disk packs involved. (This goes without saying.) 3. UNLOAD from the old system: the DLIB zone FORFMID(HVT2202) and the TARGET zone FORFMID(HVT2202). See Figure One. 3A. Optionally do the same FORFMID(HVT3205,JVT3125) off the new system, just to have the decks for reference. In our case these decks will not be used. 4. Run GENERATE FORFMID(HVT2202) from the MVS/370 system. See Figure Two for an example. 5. Run GENERATE FORFMID(HVT3205,JVT3215) from the XA system. See Figure Three. 6. Create a dummy FUNCTION to run on the XA system, that will DELETE(HVT3205,JVT3215). Call this FUNCTION DELVT32. This FUNCTION will actually be APPLYed and ACCEPTed. Figure Four will show an example. 7. Create a dummy FUNCTION to run on the 370 system, that will DELETE(HVT2202). Call this FUNCTION DELVT22. This FUNCTION will only be APPLY CHECKed. DON'T APPLY IT-- PLEASE!! REJECT it as soon as you've finished with it, just to be safe. The ELEMENT report from the APPLY CHECK listing for this FUNCTION will be used to create a COPY JOB to copy all DLIB elements from the old system's DLIBs to the new system's DLIBs. 8. Create the COPY JOB for the DLIB elements by either editing the APPLY CHECK report for DELVT22, or by using my COBOL program GIMELMNQ as a service aid. GIMELMNQ is not publicly distributed yet. Figure Five shows the output it produces. 9. APPLY and ACCEPT the delete FUNCTION DELVT32 on the new XA system. SAVE THE REPORTS. The utility report for the APPLY will contain crucial linkedits. 10. Use UCLIN to delete the SYSMOD entry for HVT2202 in both the TARGET and DLIB zones of the new system. This entry had been marked as deleted by HVT3205, and it must be gotten rid of in both zones of the XA SMP/E system. DEL SYSMOD(HVT2202) . is the UCLIN statement required in both zones. *** 11. Edit the GENERATE jobs for both VTAMs to produce one correct hybrid deck that we will actually use. Details will follow on how to do this. This step is the heart of the matter. See Figures Six and Seven. The GENERAL RULE: Self-contained VTAM modules follow the old (2.2) pattern while modules interfacing with other components follow the new (3.2) pattern. 12. Copy all HVT2202 ELEMENTs (and their aliases, if any) from the "370" DLIBs to the XA DLIBs. The XA DLIBs have now been stripped of VTAM elements by the ACCEPT of DELVT32. Figure Eight shows a part of my copy job created for this step. 13. Actually run the hybrid GENERATE copy job and linkedit jobs that you had created in Step 11. This will load the TARGET libraries with the correct load modules. 14. Now bring SMP/E into sync. UCLIN the DLIB UNLOAD of HVT2202 into the DLIB ZONE of the XA system. UCLIN the TARGET LIB UNLOAD of HVT2202 into the TARGET ZONE of the XA system. Then JCLIN the hybrid GENERATE deck into the XA system. Figures Nine and Ten illustrate these processes. 15. Check all jobs for clean return codes, and fix all errors, if any. Move the modules to an IPL-able pack, and IPL. We should have a "runnable" installed product at this stage. Voila. * * * * * * * * * * * * * * * * * * * * * * * FIGURE FOUR. Illustration of DUMMY FMID DELVT32 which is used to delete VTAM 3.2 from the MVS/XA SMP/E system. ++FUNCTION (DELVT32). ++VER(Z038) /* DELETES VTAM 3.2 FUNCTIONS WHICH CAME WITH THE CBIPO FOR MVS/XA 2.2.3, BUT WHICH WE DO NOT INTEND TO RUN IN PRODUCTION. S. GOLOB - 04/03/90 */ DELETE( HVT3205 JVT3215 ). * * * * * * * * * * * * * * * * * * * * * * * FIGURE FIVE. Illustration of output from my GIMELMNQ Service Aid which produces the following ELEMENT listing from an SMP/E APPLY CHECK of the DELVT22 FUNCTION. This listing is sorted by the DLIB name in columns 44-51 and edited to produce IEBCOPY SELECT MEMBER statements. After I have made sure that these members have no ALIASES, this IEBCOPY job is used to accurately move all DLIB members from the MVS/370 DLIBs to the MVS/XA DLIBs. AMDUSRFD /*MOD DELETED AOS24 */ CHANGE /*MAC DELETED AMACLIB */ CLSDST /*MAC DELETED AMACLIB */ COS /*MAC DELETED AMACLIB */ ------------ DATA MISSING FOR BREVITY ----------- GTDEVSIZ /*MAC DELETED ATSOMAC */ IHASU1 /*MAC DELETED AMODGEN */ IHASU34 /*MAC DELETED AMODGEN */ IHASU35 /*MAC DELETED AMODGEN */ IHASU40 /*MAC DELETED AMODGEN */ IHASU54 /*MAC DELETED AMODGEN */ IHBRDWRA /*MAC DELETED AMACLIB */ IKTASCII /*MOD DELETED AOST3 */ IKTASTPT /*MOD DELETED AOST3 */ ------------ DATA MISSING FOR BREVITY ----------- IKT3270O /*MOD DELETED AOST3 */ IKT3767I /*MOD DELETED AOST3 */ IKT3767O /*MOD DELETED AOST3 */ IKT93EST /*MOD DELETED AOST3 */ INQUIRE /*MAC DELETED AMACLIB */ INTAB /*MAC DELETED AMACLIB */ INTRPRET /*MAC DELETED AMACLIB */ ISTACBEX /*MAC DELETED AMACLIB */ ISTACB1 /*MAC DELETED AMACLIB */ ISTACCAN /*MOD DELETED AOS26 */ ISTACCAP /*MOD DELETED AOS26 */ ------------ DATA MISSING FOR BREVITY ----------- * * * * * * * * * * * * * * * * * * * * * * * FIGURE SIX. Hybrid IEBCOPY Job that was created out of the GENERATE against VTAM 2.2 and the GENERATE against VTAM 3.2. VTAM 2.2 was used for most of the "combined" job, except for copies from AMODGEN to the new TARGET macro library, MODGEN. //TSTBCOPY JOB (TS,2322),'MARIANNE', // NOTIFY=TSTBSSG, // CLASS=M,MSGCLASS=T,MSGLEVEL=(1,1) /*LREG*/ //* //JOBLIB DD DSN=TSX1.LINKLIB,DISP=SHR, // UNIT=3380,VOL=SER=VEND02 //COPYSTEP EXEC PGM=IEBCOPY EXECCPY //SYSUT3 DD UNIT=SYSDA, SYSUT3 // SPACE=(6160,(230,760)) SYSUT3 //SYSUT4 DD UNIT=SYSDA, SYSUT4 // SPACE=(6160,(230,760)) SYSUT4 //SYSPRINT DD SYSOUT=* DEFAULT //AMACLIB DD DSN=TSX1.AMACLIB, AMACLIB // DISP=(SHR) AMACLIB //AMODGEN DD DSN=TSX1.AMODGEN, AMODGEN // DISP=(SHR) AMODGEN //ASAMPLIB DD DSN=TSX1.ASAMPLIB, ASAMPLIB // DISP=(SHR) ASAMPLIB //ATSOMAC DD DSN=TSX1.ATSOMAC, ATSOMAC // DISP=(SHR) ATSOMAC //VTAMLIB DD DSN=TSX1.VTAMLIB, ATSOMAC // DISP=(SHR) ATSOMAC //LPALIB DD DSN=TSX1.LPALIB, MACLIB // DISP=(SHR) MACLIB //MACLIB DD DSN=TSX1.MACLIB, MACLIB // DISP=(SHR) MACLIB //MODGEN DD DSN=TSX1.MODGEN, MODGEN // DISP=(SHR) MODGEN //SAMPLIB DD DSN=TSX1.SAMPLIB, SAMPLIB // DISP=(SHR) SAMPLIB //AOS24 DD DSN=TSX1.AOS24, SAMPLIB // DISP=(SHR) SAMPLIB //AOS26 DD DSN=TSX1.AOS26, SAMPLIB // DISP=(SHR) SAMPLIB //SYSIN DD * DEFAULT COPY OUTDD=MACLIB,INDD=AMACLIB TYPE=MAC S M=CHANGE FMID=HVT2202 S M=CLSDST FMID=HVT2202 S M=COS FMID=HVT2202 S M=COSEND FMID=HVT2202 ------------ DATA MISSING FOR BREVITY ----------- S M=SENDCMD FMID=HVT2202 S M=SESSIONC FMID=HVT2202 S M=SETLOGON FMID=HVT2202 S M=SIMLOGON FMID=HVT2202 S M=SOLICIT FMID=HVT2202 S M=STRTMODE FMID=HVT2202 S M=TERMSESS FMID=HVT2202 S M=USSCMD FMID=HVT2202 S M=USSEND FMID=HVT2202 S M=USSMSG FMID=HVT2202 S M=USSPARM FMID=HVT2202 S M=USSTAB FMID=HVT2202 COPY OUTDD=MACLIB,INDD=ATSOMAC TYPE=MAC S M=GTDEVSIZ FMID=HVT2202 S M=IKTTCAST FMID=HVT2202 S M=IKTTSBX FMID=HVT2202 S M=IKTTVWA FMID=HVT2202 S M=STFSMODE FMID=HVT2202 S M=STLINENO FMID=HVT2202 S M=STTRAN FMID=HVT2202 COPY OUTDD=SAMPLIB,INDD=ASAMPLIB TYPE=SRC S M=ISTINCNO FMID=HVT2202 COPY OUTDD=LPALIB,INDD=AOS24 TYPE=MOD S M=AMDUSRFD FMID=HVT2202 S M=ISTORMAF FMID=HVT2202 COPY OUTDD=VTAMLIB,INDD=AOS26 TYPE=MOD S M=ISTDVCRC FMID=HVT2202 S M=ISTINCDT FMID=HVT2202 S M=ISTORFPO FMID=HVT2202 S M=ISTRACCR FMID=HVT2202 S M=ISTINCTS FMID=HVT2202 S M=ISTORFPX FMID=HVT2202 S M=ISTRACTI FMID=HVT2202 COPY OUTDD=MODGEN,INDD=AMODGEN TYPE=MAC (MODGEN is a new S M=IHASU1 FMID=HVT3205 library in the S M=IHASU34 FMID=HVT3205 MVS/XA System.) S M=IHASU35 FMID=HVT3205 S M=IHASU40 FMID=HVT3205 S M=IHASU54 FMID=HVT3205 /* //******** GENERATE END OF JOB DEFAULT * * * * * * * * * * * * * * * * * * * * * * * FIGURE SEVEN. Part of the "Hybrid LINKEDIT Job" constructed from the GENERATE of VTAM 2.2 combined with the GENERATE of VTAM 3.2. Notice that "mixed FMID" linkedits were created from the VTAM 3.2 JCL, whereas all other linkedits were created from VTAM 2.2 JCL. I was careful to check for the existence in release 2.2 of all VTAM module names used in the "mixed FMID" linkedit JCL. //TSTBLPA JOB (TS,2322),'MARIANNE',NOTIFY=TSTBSSG, // CLASS=M,MSGCLASS=T,MSGLEVEL=(1,1) /*LREG*/ //* //JOBLIB DD DSN=TSX1.LINKLIB,DISP=SHR, // UNIT=3380,VOL=SER=VEND02 //LINK0001 EXEC PGM=IEWL, EXECLNK // PARM=('RENT', // 'SIZE=(1024K,128K),NCAL,LIST,LET,XREF') //SYSPRINT DD SYSOUT=* DEFAULT //SYSLMOD DD DSN=TSX1.LPALIB, AOS26 // DISP=(SHR) AOS26 //SYSUT1 DD UNIT=SYSDA, SYSUT1 // SPACE=(6160,(230,760)) SYSUT1 //AOSB3 DD DSN=TSX1.AOSB3, AOSB3 // DISP=(SHR) AOSB3 //AOST3 DD DSN=TSX1.AOST3, AOST3 // DISP=(SHR) AOST3 //AOS24 DD DSN=TSX1.AOS24, AOS24 // DISP=(SHR) AOS24 //AOS26 DD DSN=TSX1.AOS26, AOS26 // DISP=(SHR) AOS26 //SYSLIN DD * DEFAULT ------------ DATA MISSING FOR BREVITY ----------- ALIAS IEAVTABG,IEAVTABQ,IEAVTABR ALIAS IEAVTRG2,IEAVTRGB,IEDAY802 ENTRY IEAVTRG2 INCLUDE AOST3(IKTAY8) FMID=HVT3205 INCLUDE SYSLMOD(IGC0001C) NAME IGC0001C(R) <=== This module is mixed FMID! Notice the (R). ORDER IEE0003D ORDER IEE0303D ORDER IEE5403D ORDER IEE0403D ORDER IEE7503D ORDER IEE5603D ORDER IEE5903D ORDER IEE6703D ORDER IEE7703D ORDER IEE6803D ORDER IEE6903D ORDER IEE6303D ORDER IEE6403D ALIAS IGG2103D,IGC0503D,IEE2103D,IEE0503D ALIAS IEE7603D ALIAS IEAVEMRQ ENTRY IEE0003D INCLUDE AOSB3(ISTCFF3D) FMID=HVT3205 INCLUDE SYSLMOD(IGC0003D) NAME IGC0003D(R) <=== This module is mixed FMID! Notice the (R). INCLUDE AOS26(ISTZBM0K) FMID=HVT2202 NAME IGE0004{ ALIAS ISTZBM0J INCLUDE AOS26(ISTZBM0J) FMID=HVT2202 NAME IGE0010F ------------ DATA MISSING FOR BREVITY ----------- * * * * * * * * * * * * * * * * * * * * * * * FIGURE EIGHT. ELEMENT COPY Job to move all DLIB Elements from the MVS/370 DLIBs to the corresponding MVS/XA DLIBs. This job was created by editing the GIMELMNQ output from Figure Five. //TSTB$MO$ JOB (TS,2322),'TECH.SUPP-MARIANNE',CLASS=M,NOTIFY=TSTBSSG, // MSGLEVEL=(1,1),MSGCLASS=T TYPRUN=HOLD //* //COPYSTEP EXEC PGM=IEBCOPY,REGION=5500K //SYSUT3 DD UNIT=SYSDA,SPACE=(6160,(230,760)) //SYSUT4 DD UNIT=SYSDA,SPACE=(6160,(230,760)) //SYSPRINT DD SYSOUT=* //AGENLIBI DD DSN=TSY2.AGENLIB,DISP=SHR //AGENLIBO DD DSN=TSX1.AGENLIB,DISP=SHR //AMACLIBI DD DSN=TSY2.AMACLIB,DISP=SHR //AMACLIBO DD DSN=TSX1.AMACLIB,DISP=SHR //AMODGENI DD DSN=TSY2.AMODGEN,DISP=SHR //AMODGENO DD DSN=TSX1.AMODGEN,DISP=SHR //ASAMPLII DD DSN=TSY2.ASAMPLIB,DISP=SHR //ASAMPLIO DD DSN=TSX1.ASAMPLIB,DISP=SHR //ATSOMACI DD DSN=TSY2.ATSOMAC,DISP=SHR //ATSOMACO DD DSN=TSX1.ATSOMAC,DISP=SHR //AOSB3I DD DSN=TSY2.AOSB3,DISP=SHR //AOSB3O DD DSN=TSX1.AOSB3,DISP=SHR //AOST3I DD DSN=TSY2.AOST3,DISP=SHR //AOST3O DD DSN=TSX1.AOST3,DISP=SHR //AOST4I DD DSN=TSY2.AOST4,DISP=SHR //AOST4O DD DSN=TSX1.AOST4,DISP=SHR //AOS24I DD DSN=TSY2.AOS24,DISP=SHR //AOS24O DD DSN=TSX1.AOS24,DISP=SHR //AOS26I DD DSN=TSY2.AOS26,DISP=SHR //AOS26O DD DSN=TSX1.AOS26,DISP=SHR //SYSIN DD * COPY OUTDD=AGENLIBO,INDD=AGENLIBI SELECT MEMBER=SGIKT400 AGENLIB SELECT MEMBER=SGIKT410 AGENLIB ------------ DATA MISSING FOR BREVITY ----------- SELECT MEMBER=SGIST511 AGENLIB SELECT MEMBER=SGIST513 AGENLIB COPY OUTDD=AMACLIBO,INDD=AMACLIBI SELECT MEMBER=CHANGE AMACLIB SELECT MEMBER=CLSDST AMACLIB SELECT MEMBER=COS AMACLIB SELECT MEMBER=COSEND AMACLIB ------------ DATA MISSING FOR BREVITY ----------- SELECT MEMBER=USSCMD AMACLIB SELECT MEMBER=USSEND AMACLIB SELECT MEMBER=USSMSG AMACLIB SELECT MEMBER=USSPARM AMACLIB SELECT MEMBER=USSTAB AMACLIB ------------ DATA MISSING FOR BREVITY ----------- COPY OUTDD=AOST4O,INDD=AOST4I SELECT MEMBER=IKTIIOM AOST4 SELECT MEMBER=IKTLOGFF AOST4 SELECT MEMBER=IKTLOGR AOST4 SELECT MEMBER=IKTRPLXT AOST4 SELECT MEMBER=IKTXINIT AOST4 SELECT MEMBER=IKTXLOG AOST4 COPY OUTDD=AOS24O,INDD=AOS24I SELECT MEMBER=AMDUSRFD AOS24 SELECT MEMBER=ISTAICPT AOS24 SELECT MEMBER=ISTAPC33 AOS24 ------------ DATA MISSING FOR BREVITY ----------- SELECT MEMBER=ISTSDCND AOS24 SELECT MEMBER=ISTSDCNF AOS24 SELECT MEMBER=ISTSDCOD AOS24 SELECT MEMBER=ISTZRM01 AOS24 COPY OUTDD=AOS26O,INDD=AOS26I SELECT MEMBER=ISTACCAN AOS26 SELECT MEMBER=ISTACCAP AOS26 SELECT MEMBER=ISTACCAQ AOS26 ------------ DATA MISSING FOR BREVITY ----------- SELECT MEMBER=ISTTSC3R AOS26 SELECT MEMBER=ISTTSC3S AOS26 SELECT MEMBER=ISTVTLOD AOS26 SELECT MEMBER=ISTZBM0J AOS26 SELECT MEMBER=ISTZBM0K AOS26 ------------ DATA MISSING FOR BREVITY ----------- /* // * * * * * * * * * * * * * * * * * * * * * * * FIGURE NINE. UCLIN Job to load VTAM 2.2 entries into the XA DLIB ZONE and the XA TARGET ZONE. These entries had been UNLOADed from respective ZONEs of the MVS/370 SMP/E system. //TSTB$MO$ JOB (TS,2322),'TECH.SUPP-MARIANNE',CLASS=M,NOTIFY=TSTBSSG, // MSGLEVEL=(1,1),MSGCLASS=T TYPRUN=HOLD //* //BLDDEFD EXEC SMPEMXA,REGION=4096K,AC=, <=== MVS/XA SMP/E Procedure // COND=(0,NE) //SMPCNTL DD * SET BOUNDARY(M22DLB). (Insert MVS/370 DLIB UNLOAD deck for HVT2202 here) /* //BLDDEFT EXEC SMPEMXA,REGION=4096K,AC=, <=== MVS/XA SMP/E Procedure // COND=(0,NE) //SMPCNTL DD * SET BOUNDARY(M22TGT). (Insert MVS/370 TARGET UNLOAD deck for HVT2202 here) /* // * * * * * * * * * * * * * * * * * * * * * * * FIGURE TEN. JCLIN of the Hybrid COPY Deck and the Hybrid LINKEDIT Deck into the SMP/E system for MVS/XA. //TSTBJCLN JOB ,'TECH.SUPP-SAM.GOLOB',CLASS=M,NOTIFY=TSTBSSG, // MSGLEVEL=(1,1),MSGCLASS=T TYPRUN=HOLD //******************************************************************// //* SMP/E - JCLIN OF HYBRID "GENERATED" JCL - COPY *// //******************************************************************// //JCLINC EXEC SMPEMXA,AC= <=== MVS/XA SMP/E Procedure //SMPCNTL DD * SET BDY(M22TGT) . JCLIN. /* //SMPJCLIN DD DISP=SHR,DSN=TSX1.INSTLIB(VTM22CPY), // UNIT=3380,VOL=SER=VEND02 //******************************************************************// //* SMP/E - JCLIN OF HYBRID "GENERATED" JCL - LINKEDIT *// //******************************************************************// //* //JCLINL EXEC SMPEMXA,AC= <=== MVS/XA SMP/E Procedure //SMPCNTL DD * SET BDY(M22TGT) . JCLIN. /* //SMPJCLIN DD DISP=SHR,DSN=TSX1.INSTLIB(VTM22LNK), // UNIT=3380,VOL=SER=VEND02 //