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
