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
