MVS TOOLS AND TRICKS OF THE TRADE March 1989 Sam Golob MVS Systems Programmer ISPF COMMAND TABLE, LPA LOADING AT IPL, THE ABE EDITOR This monthly column is for sharing practical advice and techniques which can be employed in your shop. I hope that every reader will come away with something practical that can be immediately used. Our aim is to help MVS shops implement time-saving techniques that are not hard to do, but which not everybody knows about. Readers are encouraged to contribute to this column. We depend on you for its continued success! Contributions can be sent through NASCOM, or you can write to me care of the Editor. The contributor's name will be mentioned when his technique is printed in this column. When software tools are required for any of the techniques, we will try to use tools that are available to the public. Of course, if a vendor product suffices for a particular user, that is fine, too. There is a tremendous public domain literature of MVS tools. Many useful tools can be found on NaSPA's own V.I.P. tapes, and we will draw heavily from the Connecticut Bank and Trust MVS Utilities tape, known as the CBT tape (online at www.cbttape.org). A list of sources for MVS tools can be found in the January issue of "Technical Support". This month, our first technique will concern ISPF COMMAND TABLE ADDITIONS. These simple-to-make upgrades will greatly improve the efficiency of ISPF sessions. With ISPF version 2, it is possible to do five, ten, or more separate functions in the two ISPF splits, or even in one split. You don't have to lose a screen split just to allocate a file or do a dataset list. The technique is primarily for releases of ISPF version 2, because these releases of ISPF will support RECURSIVE EDITs and RECURSIVE BROWSEs. The concept of recursive edits is very simple. Suppose you are in the middle of editing a file. From the command line, you execute a CLIST or a command that calls another ISPF function to run inside the same split of the screen. If the called command or CLIST invokes the ISPF EDIT function to do its work, it is clear that the EDIT function was called TWICE FOR THE SAME SPLIT. In ISPF version 2, this will work, because multiple EDIT control blocks are created for each split. In ISPF version 1, an abend will result. A similar principle applies for a call of the ISPF BROWSE function in the same split as a BROWSE which is already being done. Version 2 can handle it. Version 1 can't. It is possible to RUN MANY ISPF FUNCTIONS AT THE SAME TIME by taking advantage of the recursive ISPF invocations. The question is now, how can we recursively invoke a new ISPF function? One answer is in using the ISPF COMMAND TABLE. The command tables are part of your ISPF session. Commands in the command table are executed when they are entered from the command line of an ISPF session. COMMANDS CAN DUPLICATE ANY FUNCTION WHICH IS SELECTABLE FROM A PANEL. Our technique, then, is TO MAKE COMMANDS to invoke frequently used PANELS directly, on top of the current screen. This has the advantage that upon END from the invoked panel, you're still in the screen that was being used before. How do we do this? A command table is a pds member allocated to the ddname ISPTLIB or the ddname ISPTABL. ISPTLIB is used for output, and ISPTABL is used for input, so if you plan to update a table, it must be in a library allocated to ISPTABL. Command table names adhere to the convention "applid"+CMDS. In other words, the name of the command table member is the name of the applid suffixed by the string "CMDS". ISPF option 3.9 is used for editing command tables. It assumes that your desired table is in a PDS allocated to ddname ISPTABL, and that it IS NOT CURRENTLY BEING USED by any session. Therefore, you must update a COPY of the real table, and not one that is in use. The ISPF 3.9 entry panel asks for the name of the command table member, minus the "CMDS" suffix. The normal default ISPF command table members are called ISPCMDS and ISRCMDS, which we cannot edit directly, so let's assume we have made copies of them in an ISPTABL library, called XSPCMDS and XSRCMDS. To edit XSPCMDS, we enter XSP on the ISPF 3.9 entry panel screen, and we proceed to add or change entries to the table. After the table is saved by using the END key, we can replace the ISPCMDS member by the XSPCMDS member, get out of ISPF entirely, and then back into ISPF. The new entries should now be effective on our ISPF session. A lot of people know about ISPF command tables, so why are we writing about them here? The suggestion is as follows: Take ALL THE ISPF 3.x UTILITY FUNCTIONS and make COMMANDS to execute them ON TOP OF WHAT WE'RE DOING NOW. Then you can do a dataset allocation or a dataset list or a SUPERC, or even a command table edit, and not lose your current screen which contains the work you're doing. For example, I'm doing an EDIT now, and I want to allocate a new file. I simply go to the command line and type DAT (for DATaset), a command that I've set up. Instantly the ISPF 3.2 prompt screen comes up. After I've allocated (or deleted) the dataset, I get out of that function, and I'm back in my original EDIT, on the same split of the screen. Here are some hints on how to make the table entries. Use the SELECT statements in the PROC section of your ISRUTIL (ISPF 3) panel, to determine the correct statements to put into the command table for the 3.x functions. Panels are allocated to the ddname ISPPLIB in your session. This info should be of help in locating your current panel whose name is ISRUTIL. Just write the word SELECT, and copy the select statements exactly, without the quotes, just as they appear in the ISRUTIL panel. You can alternatively copy the entries from my sample table additions (which are for ISPF v2.3). Please be aware that the utility invocations for ISPF v2.2 may be slightly different from mine. Here's another hint in the process of exploring for commands: The name of the panel currently being used can be displayed by entering the command PANELID on the command line. The actual name of the panel will be displayed in the upper left corner of the screen. PANELID OFF turns the panel name display off. COMMANDS CAN BE MADE TO SELECT ANY SCREEN. I've included a sample of some command table additions I've made. Anyone can get very creative with this, and really ease the burdens in his everyday work. Further assistance can be obtained from the IBM ISPF manuals. One should create a TSO HELP member called "CMDTABLE", which keeps the names of the extra commands handy in case you forget them. To get really fancy, the help can be in the form of a new panel that is selected by a new command in the command table. Good luck with your own command table additions. Because of lack of space in this column, I have to eliminate extra detail, but the included sample has extra hints and tips embedded right within it. Please examine it carefully. (Please note the corrections to the following material, which are appended to the end of this member. Do not read the next few paragraphs without referring to the correction. ) Now we go to topic number two, which was suggested by Bruce Leland of Hitachi in California. This concerns the peculiarities of the Link Pack Area loading process, which loads system programs and routines into the Link Pack Area (or LPA) at IPL time. Knowing one detail about this process can save much grief. (Please look at the postscript for correct answers in this topic. Do not look in the following paragraphs. Thank you.) The detail concerns load modules which have alias entries in the SYS1.LPALIB pds directory, and there are many such load modules for any level of the MVS operating system. An alias directory entry in a pds LOAD MODULE directory will contain a field that has the name of its MAIN MEMBER, and another field which has the displacement of the alias' entry point from the beginning of the listed main member. Suppose we had a situation where load module MAINMEMB had aliases ALIASA and ALIASB in SYS1.LPALIB. Normally, all three directory entries IN THE DISK PDS DIRECTORY for these three names would point to the same actual disk location, which is ONE disk copy of the module. The LPA loader respects this condition also, and loads ONE COPY of the module into virtual storage, with three entry points pointing to it IN THE LPA DIRECTORY IN VIRTUAL STORAGE. Our USUAL perception of alias handling comes from how the IEBCOPY DISK COPYING PROGRAM handles them. In a normal case situation, let us say we are installing MAINMEMB and its aliases ALIASA and ALIASB into SYS1.LPALIB from another library. We select members MAINMEMB, ALIASA, and ALIASB in ONE IEBCOPY operation, and they get copied together. That is, ONE COPY of the load module and three directory entries pointing to it, are created. If LATER, however, we do a SECOND IEBCOPY RUN to SYS1.LPALIB, selecting ONLY MAINMEMB and not the aliases, a SECOND COPY of the main member will be copied to SYS1.LPALIB. The alias directory entries will STILL POINT TO THE ORIGINAL DISK COPY, whereas the new MAINMEMB entry will point to the new copy. What does the LPA Loader do when it sees this situation at IPL time? It figures as follows: THE ALIASES ARE PROBABLY RIGHT. The new main member is probably a different version of the program. Since we want to have complete consistency in SYSTEM OPERATION, and since a failure can only be corrected by a new IPL, which means a system outage, the LPA Loader uses only the disk copy pointed to by the ALIAS members, and CONSTRUCTS A MAIN MEMBER ENTRY in the LPA directory in virtual storage that is consistent with THE COPY POINTED TO BY THE ALIASES. THE ISOLATED MAIN MEMBER IS THROWN OUT, and a message is issued to the operator console (often missed by the operators) that this has been done. It doesn't take much imagination to realize that problems can occur if we try to INCORE ZAP this module in LPA. The standard incore zap program looks at the disk copy of the module to determine its structure, and then goes to the core copy to make the changes. If they are in fact different versions, we can get very confused. A good preventive solution would be an overall diagnosis of SYS1.LPALIB to find these inconsistencies BEFORE IPL TIME. Fortuately, a good tool is available for this in the PDS PROGRAM PRODUCT on the CBT tape, file 182. The PDS subcommand called "VERIFY" will check for all inconsistencies connected with load modules and their aliases. If one points the PDS program to the currently used SYS1.LPALIB and issues a VERIFY command for all members, the abnormalities displayed may be quite shocking. I know. I've tried it. This small step can cure multiple mysterious system problems in advance. You must, of course, use your head, and your understanding of MVS, in dealing with what you find. That's what System Programmers get paid their high salaries for. However, the fact of discovery is a good eye opener. Time has grown short for this month. In ending our current session, I'd like to inform our readership of the existence of an excellent, though complicated FULL SCREEN EDITOR PRODUCT. It is called ABE, for "A Better Editor". ABE is written in PL1. It requires the Transient Library of the PL1 Optimizing Compiler in order to run. It has enormous capability. It is therefore not easy to learn, but it has two advantages. First, it is free. Second, it does very complicated functions, and it runs in batch also, although its normal functioning is under TSO. The ABE editor is not for everyone. MVS installations which do not have ISPF may be interested in looking at it. People who use editors in complicated ways may also be interested. For those who want a look, ABE may be found on a V.I.P tape in the near future, or it can be obtained from Tom G. Smith at Kimberly-Clark in Neenah, Wisconsin. * * * * * * * * * * * * * * * * * * * * * * FIGURE 1. SAMPLE EXTENSIONS TO THE ISPF COMMAND TABLE COMMAND TABLE - XSRCMDS -------------------------------------- ROW 1 OF 52 COMMAND ===> SCROLL ===> CSR INSERT, DELETE, AND CHANGE COMMAND ENTRIES. UNDERSCORES NEED NOT BE BLANKED. ENTER END COMMAND TO SAVE CHANGES OR CANCEL TO END WITHOUT SAVING. (Author's note. T stands for command truncation, number of chars valid) 0 means that the command cannot be shortened. VERB T ACTION DESCRIPTION '''' ISPPREP 0 SELECT PGM(ISPPREP) NEWAPPL INVOKING PREPROCESSED PANEL UTILITY IN INTERACTIVE MODE '''' PDF 0 SELECT PANEL(ISR@PRIM) NEW PRIMARY LAYER OF ISPF '''' LIBRARY 3 SELECT PGM(ISRUDA) PARM(ISRUDA1) ISPF 3.1 LIBRARY UTILITY '''' DATASET 3 SELECT PGM(ISRUDA) PARM(ISRUDA2) ISPF 3.2 DATASET UTILITY '''' CPYLIBS 3 SELECT PGM(ISRUMC) ISPF 3.3 COPY UTILITY '''' DSLIST 3 SELECT PGM(ISRUDL) PARM(ISRUDLP) ISPF 3.4 DATASET LIST UTILITY '''' SPFSTATS 4 SELECT PGM(ISRURS) ISPF 3.5 ISPF STATS PANEL '''' HRDCOPY 3 SELECT PGM(ISRUHC) ISPF 3.6 HARDCOPY OUTPUT PANEL '''' OUTLIST 4 SELECT PGM(ISRUOLP) ISPF 3.8 OUTPUT LIST PANEL '''' CMEDIT 3 SELECT PANEL(ISPUCMA) ISPF 3.9 COMMAND TABLE EDIT FACILITY '''' CNVERT 3 SELECT PGM(ISRQCM) PARM(ISRQCMP) ISPF 3.10 CONVERT OLD FORMAT MENUS AND PANELS '''' FRMATDEF 3 SELECT PGM(ISRFMT) ISPF 3.11 FORMAT DEFN FOR FORMATTED DATA ED/BRWSE '''' SUPERC 4 SELECT PGM(ISRSSM) ISPF 3.12 SUPERC COMPARE UTILITY '''' SUPDETAL 4 SELECT PGM(ISRSEPRM) NOCHECK ISPF 3.13 DETAILED SUPERC COMPARE '''' SRCHFOR 4 SELECT PGM(ISRSFM) ISPF 3.14 SEARCH FOR - ISPF UTILITY '''' TSOP 0 SELECT PGM(ISRPTC) ISPF 6 INVOKE TSO OPTION 6 PANEL RECURSIVELY '''' CN 0 SELECT CMD(CN) INVOKE CONSOLE SIMULATOR FROM FILE 25 - CBT TAPE '''' PDSD 0 SELECT PGM(PDS83) PARM(PDS83 &ZPARM ISPMODE) INVOKE PDS VERSION 8.3 RECURSIVELY - CBT FILE 182 '''' SECURE 3 SELECT PGM(SECURE) TSO COMMAND TO PREVENT ACCESS TO THIS TERMINAL '''' Z1 0 SELECT PGM(ZAP) FULL SCREEN ZAP PROGRAM FROM FILE 300 - CBT TAPE '''' TMSINQ 3 SELECT CMD(%TMSALOC) NEWAPPL(U01) TMS (CA-1) TAPE MGMT SYSTEM - ISPF INQUIRY/UPDATE '''' ASIDSE2 3 SELECT PGM(ASIDSE2) DISPLAY ADDRESS SPACE DATA FOR ACTIVE ADDR SPACES '''' COMPAR 0 SELECT PANEL(COMPR#P) COMPARE WITH YALE COMPARE PGM - EXTENDED '''' SYNCSORT 4 SELECT PANEL(OLSPOLS) NEWAPPL(OLSD) SYNCSORT RELEASE 3.2 ONLINE INTERFACE '''' PANVALET 3 SELECT PGM(PLF3) PANVALET ISPF FULL-SCREEN INTERFACE - CBT FILE 353 May 1989 MVS Tools and Tricks of the Trade POSTSCRIPT: I have to report a subsequent development and a retraction. The retraction is about a mistake I made in my March column. The subsequent development concerns our current article. I will describe what happened when IBM fixed the "ACCEPTED" PTF in error which I had "backed off". This month's subject first. IBM's bad PTF which I had ACCEPTED, number UY31933, had affected module APSQDEQ, which I had replaced with the base level of that module, calling the fix by the APAR sysmod number of AZ19870. My APAR "fixing sysmod" AZ19870 was given a PRE of the bad sysmod, UY31933. At the time, I had figured that IBM WOULD REPLACE THE BAD MODULE APSQDEQ when it would come out with a fixing PTF to supersede my APAR fix called AZ19870. IBM crossed me up. When they corrected the problem described by APAR AZ19870, they fixed a completely different module to solve the problem. The new PTF from IBM ASSUMED THAT MODULE APSQDEQ WOULD REMAIN AT RMID LEVEL UY31933. If I would have APPLYed IBM's NEW PTF, then the module APSQDEQ WOULD STILL BE AT BASE LEVEL, and WOULD BE INCOMPATIBLE with THE OTHER MODULE THAT GOT FIXED. My solution was simple, but it shows that any tampering with IBM's scheme of fixes must be done very carefully. All that needed to be done was to RESTORE MY APAR SYSMOD AZ19870 (which unAPPLYs it). This action would return module APSQDEQ back to its original RMID level that would be compatible with THE OTHER MODULE WHICH IBM ACTUALLY REPLACED. We back out our fix FIRST, and this accomplishes what IBM intended. Our tampering is removed, and IBM's fix is properly put in its place. The danger lies in APPLYing IBM's fixing PTF blindly, before undoing our own tampering. IBM's PTF would have superseded our APAR number, making it impossible for us to RESTORE it afterwards, and the two modules in the system would remain at incompatible levels. In retrospect, it may have been better NOT TO ASSIGN IBM's APAR NUMBER to our tampering SYSMOD; we would later be able to RESTORE it off. But the problem would still be that we would never have gotten an ID CHECK to alert us when we tried to put on IBM's fix, no matter what number we had assigned. That is because IBM ACTUALLY FIXED A DIFFERENT MODULE THAN THE ONE IN ERROR. THE RMID OF IBM's FIXED MODULE WOULD NOT INTERACT, UNDER SMP, WITH THE RMID OF OUR BACKED-OFF MODULE. Because we had no way of knowing what IBM would do, we could never have second-guessed that occurrence in advance. The moral of the story is: YOU MUST ALWAYS BE CAREFUL WHEN IT COMES TO SMP. Now to my mistake in the March column. This concerns what I had said regarding how MVS System Initialization loads the Pageable Link Pack Area, or PLPA, at IPL time, when a load module in SYS1.LPALIB does not correspond to its aliases. Please be assured that it is still very important to check SYS1.LPALIB to make sure that all main modules correspond to their aliases. "Orphaned aliases" or "apparent aliases" may still cause problems, and these problems should be eliminated in advance. As I said in the original March column, a "VERIFY" run on SYS1.LPALIB using the public-domain PDS command processor (CBT Mods Tape file 182) before IPL of the system, is probably the best preventive of any trouble. The PDS VERIFY will flag all "bad situations" so they can be fixed. See POSTSCRIPT FIGURE ONE for an illustration of a VERIFY run. My mistake was in my explanation of what MVS system initialization does if there is a lack of correspondence between a module in SYS1.LPALIB and its aliases. The correct scenario follows, and I thank Bruce Leland for helping me here. At this point, I urge you to refer to POSTSCRIPT FIGURE TWO, which displays a load module alias directory entry. This will crystallize the situations in your mind. THE CORRECTED PRINCIPLE IS: THE PLPA LOADING ONLY LOADS MAIN MEMBERS, AND ALIASES ARE ONLY REFERRED TO BY THE DISPLACEMENT FROM THE ENTRY LOAD POINT LOCATION OF THE MAIN MEMBER. THE ALIAS ENTRY POINT IS DERIVED BY ADDING THE DISPLACEMENT AMOUNT (FROM FIELD PDS2EPA) TO THE LOAD POINT OF THE MAIN MEMBER. Now to describe some cases. CASE 1A. Module A1 is an alias. Its real member, indicated in the PDS2MNM field of the directory, does not exist in SYS1.LPALIB. System Action: The alias is not loaded into PLPA, and its name is discarded. Messages are issued (IEA301I and IEA356I on my system) that the alias will be discarded. CASE 1B. Module A1 is an alias. Its real member, indicated in the PDS2MNM field of the directory, exists, but is marked as an alias in SYS1.LPALIB. System Action: The alias is not loaded into PLPA, and its name is discarded. Messages are issued (IEA301I and IEA356I on my system) that the alias will be discarded. CASE 2A. A1 is a real member of SYS1.LPALIB. A2 thru A9 are its aliases. If A1 is renamed using TSO RENAME or ISPF 3.1 RENAME, the main member fields in the directory entries of A2 thru A9 are unchanged by the rename of their main member. Thus it appears that A2 thru A9 do not have a main member. (The RENAME function that comes with the "PDS" product, will not fall into this pitfall and will adjust the PDS2MNM fields of all aliases when the main member is renamed.) System Action: These aliases are not loaded into PLPA, and the names A2 thru A9 are discarded. Messages are issued (IEA301I and IEA356I on my system) that these aliases will be discarded. This situation is pretty pernicious, because probably nobody will notice the messages at IPL time. CASE 2B. A1 is a real member of SYS1.LPALIB. A2 thru A9 are its aliases. If A2 thru A9 are renamed using TSO RENAME or ISPF 3.1 RENAME, the main member field of each of them is unchanged. System Action: Since the main member A1 still exists, LPDE (Link Pack Directory Entry) entries will be created for the renamed aliases under their new names. This may or may not be what you want. CASE 3. A1 is a real member of SYS1.LPALIB. A2 thru A9 are its aliases. A1 is recompiled from different source and relinked into SYS1.LPALIB, but without ALIAS control cards for the eight aliases A2 thru A9. System Action: THIS IS THE MOST PERNICIOUS CASE OF ALL. Since the main member exists for all of the aliases, NO WARNING MESSAGES ARE ISSUED. However, since the main member was compiled from different source, the ACTUAL ALIAS ENTRY POINTS MAY BE AT DIFFERENT DISPLACEMENTS THAN THOSE INDICATED BY THE PDS2EPA FIELDS OF EACH ALIAS. When an attempt is made to access the module through an alias name, the point of attempted entry may actually not be an entry point, and a "mysterious abend" or other mishap will result. I hope this sets the record straight. The reader is referred to the "MVS System Initialization Logic" manual for his system, and also to the fiche for module IEAVNP05, which does the PLPA loading. * * * * * * * * * * * * * * * * * * * * POSTSCRIPT FIGURE ONE: THIS IS AN ILLUSTRATION OF A PDS (version 8.2) VERIFY RUN. The actual output is shown. - DSN=SYS1.LPALIB,VOL=SER=MVSRES MEM=: >c 'sys1.lpalib' DISP UNIT RECFM LRECL BLKSIZE ALLOCTRK FREETRK SECONDARY FREEDIR SHR 3380 U 0 19069 1X 300 91 120 TRK 353 ENTER OPTION -- DSN=SYS1.LPALIB,VOL=SER=MVSRES MEM= >ver : ** VERIFY IGC0107B MEMBER IS AN ALIAS BUT NO MAIN MEMBER EXISTS THE ALIAS DIRECTORY ENTRY NOTES THE MAIN ENTRY NAME AS IGC0007B ** VERIFY IFG0193C MEMBER IS AN ALIAS BUT NO MAIN MEMBER EXISTS THE ALIAS DIRECTORY ENTRY NOTES THE MAIN ENTRY NAME AS OMODVOL1 ** VERIFY IFG0553C MEMBER IS AN ALIAS BUT NO MAIN MEMBER EXISTS THE ALIAS DIRECTORY ENTRY NOTES THE MAIN ENTRY NAME AS EMODVOL1 ** VERIFY $EFACTRT MEMBER IS AN ALIAS BUT NO MAIN MEMBER EXISTS THE ALIAS DIRECTORY ENTRY NOTES THE MAIN ENTRY NAME AS IEFACTRT ** VERIFY IGE0001H THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY IGG019OA THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY ICBVIN02 THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY IGC0008B THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY IGC0108B THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY IGC0508B THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY IGG0197N THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY ** VERIFY IGCT005G THE DIRECTORY RLD/CONTROL COUNT DOES NOT MATCH THE FIRST RLD ENTRY END OF DATA SET 7,069 PHYSICAL BLOCKS WERE INPUT 18,432 CHARACTERS IN THE LARGEST PHYSICAL BLOCK 658 CHARACTERS PER AVERAGE PHYSICAL BLOCK 1 TRACKS COULD BE REGAINED BY COMPRESSING THIS DATA SET 1,351 MEMBERS WERE CHECKED 854 MEMBERS RMODE24; SIZE IS 4,075K 5 MEMBERS RMODEANY; SIZE IS 6K * * * * * * * * * * * * * * * * * * * * POSTSCRIPT FIGURE TWO. This is an actual PDS (version 8.2) "DIRENTRY" display of an ALIAS entry of a load module. Fields of the directory entry are described below the hexadecimal display. The fields PDS2MNM (at +24 in this example) and PDS2EPA (at +1B in this case) concern us the most. - DSN=TSTBSSG.LOAD,VOL=SER=TSO001 MEM= >DIRENTRY ASMBLR ASMBLR DIRECTORY ENTRY, LENGTH=50 0000 C1E2D4C2 D3D94040 006E23B3 006E2800 *ASMBLR .>...>..* 0010 00000000 C2E20017 50175000 00009800 *....BS..&.&...q.* 0020 01000000 C9C5E5F9 F0404040 00877048 *....IEV90 .g..* 0030 0100 *..* LOC NAME VALUE DESCRIPTION --- ---- ----- ----------- 00 PDS2NAME ASMBLR MEMBER NAME 08 PDS2TTRP 006E23 TTR OF FIRST BLOCK OF DATA 0B PDS2INDC B3 ALIAS; 1 TTRS FOLLOW; 19 HALFWORDS OF DATA 0C PDS2TTRT 006E28,00 TTR OF FIRST TEXT BLOCK 10 PDS2TTRN 000000,00 (NOT USED FOR THIS MEMBER) 14 PDS2ATR1 C2 REENTRANT; REUS; NOT OVERLAY; NOT TEST NOT ONLY LOAD; NOT SCATTER; EXEC; NOT 1 TEXT 15 PDS2ATR2 E2 NOT DC; TEXT ORG=0; EP=0; HAS RLDS EDIT; NOT TEST; LKED F; NOT REFRESHABLE 16 PDS2STOR 5,968. TOTAL CONTIGUOUS MAIN STORAGE REQUIRED 19 PDS2FTBL 5,968. LENGTH OF FIRST BLOCK OF TEXT 1B PDS2EPA 000000 ENTRY POINT ADDRESS 1E PDS2FTB1 98 PROCESSED BY OS/VS LINKAGE EDITOR SSI INFORMATION IS PRESENT APF INFORMATION IS VALID 1F PDS2FTB2 00 RMODE 24; ALIAS AMODE 24; MAIN AMODE 24 20 PDS2FTB3 01 RLD/CONTROL RECORDS AFTER FIRST TEXT BLOCK 21 PDS2EPM 000000 ENTRY POINT OF MAIN MEMBER 24 PDS2MNM IEV90 MEMBER NAME OF MAIN MEMBER 2C PDSSSIWD 00877048 SSI INFORMATION 30 PDSAPFCT 01 LENGTH OF PROGRAM AUTHORIZATION CODE 31 PDSAPFAC 00 PROGRAM AUTHORIZATION CODE