My recent acrimonious dispute with Shmuel here about these macros led me to re-examine and instrument the uses I had made of them in the past.
As some regular IBM-MAIN participants know, one of my preoc-cupations for perhaps too many years has been with table generation, table-driven processing, and the shared, concurrent use of single copies of a (static, reassemble-to-change)) table in the same and different address spaces. In my use of them these tables are packaged as refreshable program objects, but they are not executed. They are instead examined. This use of them has made me particularly dependent upon LOAD and DELETE. (Read-only tables cannot be ATTACHed; or, perhaps better, they cannot be ATTACHed successfully; and I mark them OL to ensure that they cannot be.) Options are available for LOADing such tables into the [E]CSA, from which they can be accessed from, in principle, any address space; and I will confine myself here to talking about this case. Looking first at the time line for a single table AS1TL AS2TL AS2TD AS1TD -------|----------|---------------|-------------|--- t0 t1 t2 t3 makes it clear that the statement in the IBM z/OS MVS Authorized Assembler Services manual) Any module loaded by a task will not be removed from virtual storage unless the task that loaded the module invokes the DELETE macro or terminates. that Shmuel made so much of is for this case a truism. The successive responsibility counts following times t0, t1, t2, t3 are just 1, 2, 1, 0. The scheme of incrementing the responsibility count by one for a LOAD, real or virtual, and decrementing this count by one for a DELETE ensures that no load module or program object LOADED by a task can be physically deleted until that task DELETEs it (or terminates). Consider now a second time line AS1TL AS2TL AS1TD AS2TD -------|----------|---------------|-------------|--- t0 t1 t2 t3 Here the DELETE for the first, real LOAD precedes that for the second, virtual LOAD. Nevertheless the object is not deleted because there has not yet been a matching DELETE (or termination) for the second, virtual LOAD. For this case too—It is the only other one of interest—the statement quoted above is a truism. What this statement, which Shmuel quoted so vociferously, comes down to is that an object LOADed by a task will remain in storage until either 1) that task DELETEs it or 2) that task terminates. I concede this, whatever that may mean in this context since I also asserted it. What is important about such matched pairs of LOADs and DELETEs (or terminations) is that they ensure that a single copy of a sharable resource, a table or reentrant executable, can in fact be shared among tasks. I have here oversimplified things by talking only about task terminations. For a LOAD macro instructions that specifies GLOBAL=YES, thus targeting the CSA, the value of the EOM= key-word parameter complicates things. For EOM=YES the termination referenced is that of the address space. Only for EOM=NO is this termination task termination. Shmuel is very experienced and knowledgeable, but I have the impression---It is only that---that he no longer actually writes and tests much code. His dependence upon documentation then sometimes puts him at a disadvantage. It may even, as here, lead him astray. RYFM can be a helpful stricture, but what the manuals say needs to be refracted through current practice. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN