During the compile/link process of any given program, a requirement has come up to extract the list of all copybooks (component name and type) from the ChangeMan ZMF package. Looking at #VARLIST, it was found that the PDSTGTBL ISPF table is available, which is the Package Driven Stage Table.
When one does a ")DOT PDSTGTBL" to find all copybooks (using ")SEL &STGLIKE EQ C"), it does destruction of values across various variables used in the compile/link skeletons. For example, COBOL program ABC123.SRC may be staged with certain user options, etc. When ISPF file tailoring begins, values are set as follows:
- &CMPNAME is "ABC123"
- &CMPTYPE is "SRC"
- &LNGNAME is "COBOL"
- etc.
The issue is that once the whole PDSTGTBL ISPF table is looped through via ")DOT PDSTGTBL", the various variables (&CMPNAME, &CMPNAME, &LNGNAME, &PROC, &USEROP1, &CUSR011, etc.) are set to the last entry / component within PDSTGTBL.
In order to effectively to perform a ")DOT PDSTGTBL" without worry about ISPF variable value destruction, one must save the values of all variables used in staging ISPF file tailoring that the PDSTGTBL table references, then use the PDSTGTBL ISPF table, and then restore all the variables with the values associated with the target component being staged. Since PDSTGTBL contains 59 fields, there around 59 variables that must have their values saved before PDSTGTBL is used, and after PDSTGTBL is used these variables will need to be restored.
As a specific example, we have a package that contains the following components:
STAGE: UAS 000123 Components Row 1 to 2 of 2
Command ===> Scroll ===> PAGE
Name + Type Status Changed Procname User Request
TEST00 SRC ACTIVE 20240814 194657 CMNCOBEP STD50
TEST00C CPY ACTIVE 20240515 141949 STD50
******************************* Bottom of data ********************************
When TEST00.SRC is staged, here is part of the CMNWRITE job step:
//*)IM CMN$$WRT
//WRITE EXEC PGM=CMNWRITE, *** PARSE/EXPAND COMPONENT TEST00
// COND=(4,LT),
// PARM=('SUBSYS=I,USER=STD50',
// '')
...
CMP=TEST00.SRC
LNG=COBOL
PKG=UAS 000123
Some time after the CMN$$WRT skeleton, the PDSTGTBL ISPF table is processed via a "Do Table."
In the FAILURE job step, one can see that a the copybook component (TEST00C.CPY) is referenced instead of the target component that was staged (TEST00.SRC):
//FAILURE EXEC PGM=CMNBATCH, *** NOTIFY USER PROCESS HAS FAILED
// COND=(EVEN,(0,EQ,CHKCOND)),
// PARM='SUBSYS=I,USER=STD50'
...
//SYSIN DD *
UAS #Ä LIB=CPY
UAS #Ä CNM=TEST00C
UAS #Ä FUN=90,TID=STD50
Rather, in the FAILURE job step, it should be "LIB=SRC" and "CNM=TEST00".
In any case, the above shows an example of how the PDSTGTBL ISPF table will destruct the values of &CMPNAME, &CMPTYPE, and many others.
As implied, it is true that it's op to the ZMF admin person customizing the ChangeMan ZMF product to ensure that these ISPF variables are saved and restored; however, there are quite a few variables that need to be saved and restored. Additionally, what if more same-named variables are added to the staging file tailoring process and the PDSTGTBL ISPF table in a future ZMF version? It would make an ZMF upgrade a little more error-prone to ensure that these new ISPF variables are saved and restored.
It would seem that a simple (and sensible) solution would be to have the PDSTGTBL ISPF table contain the target component being staged to be the last entry in the PDSTGTBL table. This way, even though processing various rows of PDSTGTBL will cause destruction of various &CMPNAME, &CMPTYPE, etc. variables, when the last entry within PDSTGTBL is processed, it will effectively restore the ISPF file tailoring variables associated with the target component being staged. Thus, there would be no need to save and restore a multitude of ISPF variables to ensure that staging ISPF file tailoring continues to generate JCL reliably.
-- Ron Palaniuk
#ZMF
#ReduceCustomizations
#Build
