John, You didn't read widely enough. What you read is correct, necessary, but not sufficient. In the Authorized Assembler Services Reference book, in the section on the LOAD services, for the keyword GLOBAL=YES, is this text: "Note: A load request with the GLOBAL=YES, (YES,P), or (YES,F) option does not cause the loaded module to be implicitly known to other address spaces. The loaded module can be accessed by other address spaces, however, only the task that loaded the module may delete it."
LOADing a module somehow other than GLOBALly does cause the loaded module to be implicitly known to other address spaces, because the operating system adds such implicit knowledge into its control block structure for all loaded modules that will be findable through the published rules by which the LOAD service works. But other tasks in other address spaces cannot even find a GLOBALly loaded module implicitly (i.e., through system services), nor may they delete it (meaning they cannot use the DELETE service and thus reduce the load/responsibility count). All they can do is find it somehow (through some structure known to all the developers who are either LOADing the module or else explicitly finding and using it) and branch into it. The note says nothing about any requirements upon the module that does the deletion, such as knowing that it is still being used by 50 other address spaces and thus not deleting it for a while. The task that LOADed it may DELETE it at any time it wants to with no sharing of such knowledge with its users, which may then suffer S0C4s or other unpredictable ABENDs. Some might say this is a design flaw, even though it is what Paul Gilmartin would like to be able to do with externalized data sets so that z/OS will behave like some other operating system. It's not a design flaw if all the developers involved understand all the rules and then some developer invents a scheme for managing the continued existence and usability of the load module in question. E.g., users of the load module might all ENQ on some esoteric resource name before attempting to find the module and branch to it. Or maybe the load module itself can increment a use count when it is first entered reentrantly by any address space and then decrement the use count when it exits. The use count must obviously be stored somewhere in commonly addressable storage with known rules for accessing and managing the use count field. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Gilmore Sent: Thursday, November 29, 2012 2:46 PM To: [email protected] Subject: Re: "New" way to do UCB lookups Shmuel has urged me, rudely, to RYFM. Doing so, I find <begin extract> The LOAD macro is used to bring the load module containing the specified entry name into virtual storage, if a usable copy is not available in virtual storage. Control is not passed to the load module; instead, the load module's entry point address is returned in GPR 0. LOAD services places the load module in storage above or below 16 megabytes depending on the module's RMODE. The responsibility count for the load module is increased by one. The load module remains in virtual storage until the responsibility count is reduced to 0 through task terminations or until the effects of all outstanding LOAD requests for the module have been canceled (using the DELETE macro), and there is no other requirement for the module. <end extract> (taken from z/OS MVS Assermbler Services Reference, ABEND-HSPSERV) This is exactly what I described, with a single, I think unimportant, exception: I spoke of invocation or usage counts,. and this text speaks of responsibility counts. For that lapse: mea minima culpa. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
