I fully agree with the sentiment that you should not take it upon yourself
to free common storage that someone else obtained unless you (somehow) are
able to know 100% that it is not used. And I fully agree that "unowned"
does not mean "unused".
Let me go a bit further, however, since "unowned" is not a category that
the system has chosen to delineate.
The categories that VSM supports are:
owner=system
owner=some-active-space identified at time of obtain
owner gone
The rule that we intended, and told everyone about, and tried
(unsuccessfully in some cases) to get people to implement was:
There should be no owner-gone storage.
That meant that if you obtained common storage that needed to persist
beyond the life of the obtainer, then it should not be owned by that space,
but should be owner=system. Otherwise, you are wasting the space that the
system must maintain in order to keep track of the fact that this now-gone
space still owns storage.
I personally would complain to a product owner who ended up with owner gone
storage. They might blow you off, but perhaps they would (in my mind) fix
("improve") their product. TSO/E was mentioned as one that obtains, and
leaves stuff. Whether they do this or not, and whether they use
OWNER=SYSTEM or not, I have no idea. But if they do that obtain, and do not
specify OWNER=SYSTEM, then they could be prodded to update their code.
Note that in z/OS 1.8, we implemented OwnerASID as an additional option to
Home or Primary or Secondary or System to make it more likely that a server
space, obtaining common storage while running within a client space (for
example) could target the proper owning space.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
