APAR Identifier ...... PK24960 Last Changed ........ 06/09/12
VSMDATA SAYS STORAGE IS "OWNER GONE" (OG)
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 4 Date Closed ......... 06/07/17
Component .......... 5655L8200 Duplicate of ........
Reported Release ......... 000 Fixed Release ............ 999
Component Name WEBS MQ FOR ZOS Special Notice
Current Target Date ..06/10/04 Flags
SCP ...................
Platform ............
Status Detail: SHIPMENT - Packaged solution is available for
shipment.
PE PTF List:
PTF List:
Release 000 : UK16225 available 06/09/12 (1000 )
Parent APAR: PK11489
Child APAR list:
ERROR DESCRIPTION:
VEBRX VSMDATA 'OWNCOMM DETAIL' lists some storage as "owner
gone", but the storage should be listed as "active"
LOCAL FIX:
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All users of Websphere MQ for z/OS Version 6 *
* using common storage tracking. *
****************************************************************
* PROBLEM DESCRIPTION: IPCS VERBX 'OWNCOMM' report flags MQ *
* storage that is still in use as 'OG' *
* (Owner Gone) when MQ pool storage *
* extensions were required by a connected *
* address space which has now ended. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The storage management routines in the MQ QMGR do not specify
OWNER= on their GETMAIN macros - so the 'owner' defaults to the
address space in control at the time. MQ storage pools can be
extended by the MSTR address space or any connected address
space and remain in use by MQ even after the requestor has
terminated. This gives a false view of the storage in the CSA
tracker data - since the 'OG' storage is in fact reallocated
and is in use by other users of the MQ subsystem
PROBLEM CONCLUSION:
Modules CSQSFBK CSQSFPL CSQSGMN CSQSVBK CSQSVPL CSQYAGCS
have been changed to specify OWNER=SECONDARY on their GETMAIN
macros for global storage.
Code has been added to ensure that the MQ MSTR address space
is SECONDARY when the ?CSQSGBLK macros (for obtaining cpool
storage) are executed in the following modules.
CSQWARDS, CSQWVSMT, CSQWVZCK, CSQWVZSA, CSQWVZSS,
CSQ3AM00, CSQ3EXT0 and CSQ3GCAB
000Y
CSQSFBK
CSQSFPL
CSQSGMN
CSQSVBK
CSQSVPL
CSQWARDS
CSQWVSMT
CSQWVZCK
CSQWVZSA
CSQWVZSS
CSQYAGCS
CSQ3AM00
CSQ3EXT0
CSQ3GCAB
TEMPORARY FIX:
COMMENTS:
MODULES/MACROS: CSQSFBK CSQSFPL CSQSGMN CSQSVBK CSQSVPL
CSQWARDS CSQWVSMT CSQWVZCK CSQWVZSA CSQWVZSS CSQYAGCS CSQ3AM00
CSQ3EXT0 CSQ3GCAB
SRLS: NONE
RTN CODES:
CIRCUMVENTION:
MESSAGE TO SUBMITTER:
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Schiradin,Roland HG-Dir itb-db/dc
Sent: Sunday, June 25, 2006 7:11 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Orphaned CSA/SQA Storage
Well IBM Hursley done a good job to elimiate such "orphaned CSA/SQA
storage"
PK11489 for 5.3 (I run a usermod for several months without any problem)
PK24690 fot 6.0 (still open)
DB2 development close PK10031 as SUG. Requiere BCP support
Roland Schiradin
====================
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
