Normally, when invoking ELIPS (or the utility) from a CLIST or a program, ELIPS must execute under the APPLID of LIB@, with NEWPOOL specified, so that ELIPS can be called recursively or the CLIST or program can be called from in ELIPS. Thus, NEWAPPL(LIB@) and NEWPOOL are specified when invoking ELIPS. However, when control is passed back to the CLIST or program, the ISR shared variable pool is in effect as it was before calling ELIPS and the ELIPS shared pool was deleted.
To maintain the ELIPS shared variable pool while invoking ELIPS from a CLIST, you can front-end your CLIST with another CLIST that calls your CLIST. In doing so, the front-end CLIST executes under the ISR APPLID. The called CLIST executes under the LIB@ APPLID, which maintains the LIB@ variable pool. Similarly, a program can call another program to maintain both variable pools.
For example, a front-end CLIST named CLIST1 can call CLIST2 as follows:
ISPEXEC CMD(CLIST2) APPL(LIB@) NEWPOOL
and CLIST2 can execute ELIPS and VGET variables from the LIB@ pool as follows:
ISPEXEC PGM(ELIPS) ISPEXEC VGET(variable)
Once CLIST2 passes control back to CLIST1, CLIST1 has no access to the LIB@ shared pool that CLIST2 and ELIPS used.
Note: On invocation of ELIPS, variable contents are updated in the ISPF function pool. If a CLIST is invoked from within ELIPS edit which invokes ELIPS, the later invocation overwrites the updates to the ISPF function pool variables which were made during the prior invocation of ELIPS. Therefore, when the later ELIPS is exited, the prior ELIPS retrieves invalid values from the ISPF function pool. This produces erroneous results.
|
Copyright © 2003 CA.
All rights reserved.
|
|