On Thu, 28 Sep 2023 01:30:05 -0400, Joseph Reichman <reichman...@gmail.com> wrote:
Another problem with your code dawned on me. Your IRB routine and passed storage could be freed while the IRB is still executing. The IRB routine only does a LOAD but the I/O time could be long enough for the originating program to end and possibly the TCB. Remember you are running sup key 0 which makes you the destroyer of worlds. >The one glaring thing that was happening was that > load was indeed abending you said linking it with ac=1 would solve that issue I don't have access to z/OS. Joseph, can you run a simple test to find out if this is a problem because others say it's not. Assemble, link (with AC=1) and run from JCL the following prog: YREGS , TESTPGM CSECT , BAKR R14,0 Save regs on the stack without destroying R13 LR R12,R15 USING TESTPGM,R12 WTO 'TESTPGM SETTING MODE' MODESET MODE=SUP,KEY=ZERO WTO 'TESTPGM PERFORMING LOAD' LOAD EP=IEFBR14,ERRET=LOADFAIL WTO 'TESTPGM LOAD SUCCESS' SR R15,R15 RC=0 success RC PR , Return LOADFAIL EQU * WTO 'TESTPGM LOAD FAILED' LA R15,16 RC=16 failed RC PR , Return Can you let me know if the load failed? It's been a long time but I vaguely recall problems loading unauthorized programs from an authorized program. >I don’t understand your suggestion about doing a storage obtain > and load to the obtained area isn’t storage also tied into the TCB ? Freeing storage depends upon the type of storage being used which is controlled by the subpool specified in STORAGE OBTAIN. https://www.ibm.com/docs/en/zos/2.1.0?topic=summary-storage-subpools has a column called OWNER. Using a subpool owned by the job step will be freed at step termination. A subpool owned by the address space will be freed at asid termination. System owned will never be automatically freed. Be sure the storage is obtained with the correct key you need. LOAD to storage address is only freed according to the subpool owner. Be aware that another LOAD to this program will not reference this storage. You must keep a pointer to the module (e.g. named token). >And your suggestion about identify I mean if I gave it an alternate name on >the fly > that would insure the load module remains in core once the running TCB goes > away ? A RENT/REUS load module is shared by all TCB's and not freed when the TCB goes away. Instead, it is loaded to jobstep storage and when it's use count goes to 0 (no TCB is using it), the module is freed. I'm guessing that IDENTIFY increments the use count to keep the alternate name around for the life of the job. Since I don't have access to a system, you will need to test this. You can test this by using identify in a program from the ISPF 6 (TSO command) and then exit ISPF. Try the name specified in the identify as a TSO command. If you get command not found, then it's deleted at TCB termination instead of job termination. >Regardless of a module use count I thought once the TCB in control while the > load was done goes away so would all the resources tied into that TCB go away > such as storage and load module When a TCB terminates, cleanup is performed. TCB storage is freed. I don't know the specifics for how load modules. I assume load module cleanup occurs during TCB termination but it would make more sense that RB termination does this cleanup so that load modules are freed after they have been used instead of waiting for the TCB to terminate. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN