Hi Greg,
Is there a reason this cannot be tied to a DB2 address space that will clean
it up when it terminates?
The APAR even said
"This occurs because the MVS service
aid tracking is done based on the HOME ASID at the time of the
GETMAIN. In actuality, the storage gotten is being tracked and
managed by the corresponding DB2 PRIMARY ASID.
It seemed that DB2 could just do the STORAGE OBTAIN and specify
OWNER=PRIMARY if that is what they wanted ownership to reflect.
,OWNER=HOME
,OWNER=PRIMARY
,OWNER=SECONDARY
,OWNER=SYSTEM
Specifies the entity to which the system will assign ownership of requested
CSA, ECSA, SQA, and ESQA
storage. The system uses this ownership information to track the use of
CSA, ECSA, SQA and ESQA
storage. This parameter can have one of the following values:
HOME The home address space
PRIMARY The primary address space
SECONDARY The secondary address space
SYSTEM The system (the storage is not associated with an address space);
specify this value if you expect the requested storage to remain allocated
after termination of the job that obtained the storage.
The default value is OWNER=HOME. The system ignores the OWNER keyword
unless you specify a CSA, ECSA, SQA, or ESQA subpool on the SP parameter.
Storage tracking is available as of MVS/SP release 4.3. However, programs
that issue the STORAGE OBTAIN macro with the OWNER parameter can run on any
MVS system from MVS/SP 3.1 to the current release.
It really seems like the owner should be a real DB2 address space and not a
DB2 monitor and not SYSTEM which should be reserved for things like SRB
pools, resource managers, etc. owned by components that don't have an
address space and "live" in every space in the system where they are
invoked.
Thanks,
Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
I cannot forecast to you the action of Russia. It is a riddle wrapped in a
mystery inside an enigma. - Sir Winston Leonard Spencer Churchill
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Greg Dyck
Sent: Tuesday, September 06, 2005 12:12 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: VSMLIST OWNCOMM DETAIL
> DB2 open PK10031 and close it with the following comment:
<snip>
> This apar is being closed USE ( user error ). Users should
> not be using MVS service aid information as a basis for direct
> commands against storage. The actual reporting of DB2 storage
> as 'orphaned' is considered an inaccuracy in the service aid
> reporting or monitor display itself and not a code error in DB2.
<snip>
Roland, the response is both right and wrong. It is right in stating that
owner gone status is service aid information and not an absolute to be
relied upon, but wrong that it should not **eventually** be fixed. I do not
think fixing this in an APAR is appropriate, but *do* think it should have
been closed as SUG and fixed in the next release. I will get that done, but
keep in mind that all that will happen is that the storage will become
"system owned".
Greg
<>
====================
This email/fax message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution of this email/fax is prohibited. If
you are not the intended recipient, please destroy all paper and electronic
copies of the original message.
----------------------------------------------------------------------
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
