(I assume you're quoting me without attribution.) On Sat, 28 Aug 2021 10:20:17 -0400, Peter Relson wrote:
><snip> >If all callers access the GLOBAL module using LINK or ATTACH, CSV should be >able >to maintain use count and clean up when it reaches 0. ></snip> > IOW, "GLOBAL" isn't entirely global. I suppose that's a good thing.. If I were able to publish my own code as IEFBR14 GLOBAL I would have the same power as if I could modify authorized libraries. I could imagine allowing another address space to use my GLOBAL module only if that job had the library from which I did the LOAD GLOBAL first in its search order. Too complicated. (But that's akin to the way UNIX shell builtins work.) >The case of LINK or ATTACH is uninteresting because that had to come from >the address space (and jobstep) that did the LOAD in order to use the copy >that was loaded to global. >The "automatic cleanup" will happen after the >task issuing LINK or ATTACH has terminated (or at the very tail end of >that termination). >The GLOBAL module is represented by a CDE on the loader's job pack queue. >There is no "global" use count that could be accessed from some other >address space. Such a global use count exists only for modules in LPA. And >that use count is "useless"; it has no intrinsic meaning (since LPA >modules can be "used" without LOAD). > ><snip> >A programmer must not cause an object to be fetched with LINK then BALR to >it in a concurrent thread. ></snip> > >This is good advice but there are protocols that could be used if that >(for some bizarre reason) was needed. >The same could be said to be true with LOAD for a thread that is not a >subtask of the loading task. >It is the programmer's responsibility to make sure that the "owner task" >does not terminate while there could still be a "user task". -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
