I'm looking at example #1 here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa100/iea3a1_Description18.htm#dylpaxm
What I'm thinking of is in regards to a subsystem (SSI) initialization which occurs after IPL (i.e. not via the IEFSSNnn member of PARMLIB). The above seems like a decent way to add the required code from a "steplib" into the running LPA so that it is usable, even if the initialization address space terminates for some reason. The basic logic that I'm looking at is to do something like (really stripped down): 1) Determine if the subsystem is already running & terminate if so. 2) Determine if the required module(s) are already in LPA & if not load them as above. 3) Determine if the subsystem is defined & if not then use IEFSS* macros to define it. 4) Set up the subsystem (IEFSS* macros) and continue. Now, my question is "Will the module added with the CSVDYLPA continue to be valid even if the initialization address space terminates?". The documentation doesn't indicate that it will "go away", so I am hoping that it continues to be usable even if the address space terminates. But I am somewhat concerned due to the fact that in a Share presentation on the SSI it had a strong emphasis that "LOADTOGLOBAL" should only be used on the IEFSSVT macro if one can be certain that the address space will _never_ terminate. I'm guessing that LOADTOGLOBAL literally means "LOAD GLOBAL=YES,EOM=YES" is specified within the IEFSSVT processing. Which, of course, makes me wonder why it doesn't do a CSVDYLPA to load the module into CSA instead. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
