IBM Mainframe Discussion List <[email protected]> wrote on 09/05/2007
10:46:21 PM:
> >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.
>
> This does rankle me a bit. Even if the storage is marked
> OWNER=SYSTEM, the CSA tracker should STILL retain the ownership
information
> (i.e., who obtained it). All too often, there is system owned
> storage that is involved in some CSA problem, be it an overlay or system
> malfunction. Knowing which address space obtained the storage
> originally (even if now gone) may assist in determining the component or
ISV
> product involved in the problem.
>
> There is another capability that would be desirable and that is the
> concept of an ownership TRANSFER. A program that has obtained CSA
> may terminate abnormally, be restarted, and reuse the CSA that
> wasn't cleaned up when it failed, thereby making the storage no longer
> "owner-gone," but it will still be marked so, as there is no way to
> transfer the ownership.
I wrote down my wish list of VSM common storage tracking enhancements
a few years ago, and actually did implement items 1 and 4 in z/OS 1.8.
The things you are requesting look like items 2 and 3 on my list.
I am currently trying to work on my Standalone Dump wish list, but
maybe I will get back to my VSM list someday.
1. Owner=Asid
2. A "Persistant" attribute. This would be a new bit in the GQE,
specified by the obtainer, to say that this storage is expected
to remain after the owner terminates. Such storage would not be
considered to be "owner gone".
3. STORAGE TRANSFER,ADDR=area,LENGTH=length,OWNER=(new owner designation)
This would look for a GQE which matches ADDR/LENGTH, and if
it finds it, transfer ownership of the GQE from its current
CAUB to the designated CAUB (i.e. subtract length from the
current CAUB, add the length to the designated CAUB, and point
the GQE to the designated CAUB. This function would require the
caller to be authorized, and might be implemented only
on the LINKAGE(SYSTEM) form of STORAGE (to save a bit of
implementation cost).
If no matching GQE is found, give a bad return code or
ABEND (To Be Determined).
This would be used by a component which terminates
and restarts in a new address space to transfer ownership of
persistant storage to the new address space.
4. A way to designate that the OWNER spcification should apply
to the address space CAUB, (today we always use the current
CAUB, which may be a job CAUB in an initiator address space).
I have seen some cases where storage is obtained while a job
CAUB is current which really belongs to the address space,
and thus is flagged as "owner gone" when the job terminates.
5. In CPOOL, save the owning ASID in some CPOOL control block,
and use this with OWNER=ASID when obtaining storage for a new
extent (saw this issue not too long ago for some JES2 use of
CPOOL).
6. Maybe add the proposed Persistant option to CPOOL BUILD.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
----------------------------------------------------------------------
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
