On Thu, Sep 28, 2023 at 08:37:02PM -0500, Jon Perryman wrote: > 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:
Unless something major has changed (which would break lots of things), only the EXEC PGM= module has to be AC(1). Here's an abstract from the UCLA/IPC linked: // EXEC LKED,PARM.LKED='RENT,REUS,XREF,LIST,LET,NCAL,MAP' //LKED.SYSLMOD DD DISP=SHR,DSN=SYS1.IPCAPF,UNIT=,SPACE= //LKED.IPCMOD DD DISP=SHR,DSN=SYS9.IPCMOD //LKED.SYSIN DD * ..several include statments.. ..several order statements.. ENTRY IPCMAIN SETCODE AC(1) NAME IPCMAIN(R) -- IPC STC/TASK ROUTINE(S) ..several include statments.. ..several order statements.. ENTRY IPCINIT NAME IPCINIT(R) -- IPC SUBSYSTEM INIT ROUTINE // EXEC LKED,PARM.LKED='XREF,LIST,LET,NCAL,MAP' //LKED.SYSLMOD DD DISP=SHR,DSN=SYS1.IPCAPF,UNIT=,SPACE= //LKED.IPCMOD DD DISP=SHR,DSN=SYS9.IPCMOD //LKED.SYSIN DD * ..several include statments.. ..several order statements.. ENTRY IPCGCA *** ENTRY POINT AT OFFSET 0 *** NAME IPCCSA(R) -- IPC CSA MODULE (SVC/SRB RTNS) This worked and the IPCMAIN routine received control authorized. No other modules are AC(1). Issuing loads on the other modules which are not AC(1) but are in an authorized library worked just fine. > 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. If the search program fetch does finds the module in a non-authorized library it will issue an abend. A concatenation can not have any non-authorized libraries in it and remain authorized. > >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 ? > 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. Be extra careful with this desciption as it likely only applies to a single job step. (The job pack queue of modules is related to the job step task. There's likely more than one in the TSO address space related to this discussion...) > 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 LOAD requests are tied to the TCB issuing them however the module is fetched into the job pack area anchored to the jobstep task (and has a JPQ use count). At some point in task termination all the modules loaded by the terminating task get unloaded. This decreases the use count for each of the modules which were loaded by this task in the JPQ too. I'd expect that task termination causes each RB on the TCB to exit which frees any module requested via ATTACH/LINK/ATTACH as these requests (and use counts) normally get lowered by normal exit. For more information which is slightly outdated see: SY28-0764-0_OS_VS2_System_Logic_Library_Vol_4_Rel_3.7_Jul76.pdf https://archive.org/details/bitsavers_ibm370OSVSystemLogicLibraryVol4Rel3.7Jul76_23459458 A lot can change in 47 years but not everything... > 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. They are likely freed when the use counts get to zero. As above load requests are tied to the task issuing load. The use counts for LINK/ATTACH/XCTL are tied to the RB created for that transfer of control and are released when the RB exits (or issues XCTL which is similar to exit as far a module usage goes). Abnormal termination likely walks the RB chain and points all the saved PSW instruction pointers to EXIT so they all go away. The last RB calling exit is end of task. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
