Hi,
OA2729 is a very interesting APAR and one that early adopters of z/OS 1.10
probably want to be aware of. DIAGxx option NUCLABEL ENABLE|DISABLE(IGVGPVTN)
provides an immediate option for relief.
Best Regards,
Sam Knutson, GEICO
System z Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
(cell) 301.996.1318
"Think big, act bold, start simple, grow fast..."
APAR Identifier ...... OA27291 Last Changed ........ 08/12/08
ABEND0C4 OR VARIOUS OTHER ABENDS, OVERLAYS, OR UNEXPLAINED
PROBLEMS IN Z/OS R1.10 WHEN STORAGE NOT CLEARED ON GETMAIN
Symptom ...... AB ABEND0C4 Status ........... OPEN
Severity ................... 1 Date Closed .........
Component .......... 5752SC1CH Duplicate of ........
Reported Release ......... 750 Fixed Release ............
Component Name 5752 VIRT STOR Special Notice
Current Target Date ..09/01/31 Flags
SCP ...................
Platform ............
Status Detail: DESIGN/CODE - APAR solution is being designed
and coded.
PE PTF List:
PTF List:
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
A change was made in Virtual Storage Manager in z/OS r1.10
HBB7750 which results in different behavior when storage is
getmained for user private subpools both below and above the
line. This change can have a very negative effect in some
cases. The following have changed:
1. Getmained storage which was previously cleared to binary
zeros may not be cleared now. Programs which were counting
on this without clearing the storage before use may exhibit
unexpected behaviors. Depending on the contents of the
uncleared storage and how it is used, this might result in
abend0Cx, overlay of storage, or a variety of other problems.
2. Storage is now allocated from the bottom of the page up
rather than the top of the page down. Programs that depended
on the previous method for allocating storage may be
adversely affected.
3. Newly gotten DQEs are merged with adjacent DQEs of the same
subpool and key which are owned by the same task. Programs
may be affected if they depend on the previous way DQEs were
allocated, which is: A new DQE is obtained for each user
private subpool getmain. The size is rounded up to the next
full page size for any getmain which is not a full page
increment.
Also, those examining VSMDATA associated with problem
diagnosis or other activities for which the previous pattern
of DQE allocation is expected may be impacted because no
conclusion can be drawn about a getmain size by the DQE
size, FQE size, or DQE/FQE pattern because merging of DQEs
hides these clues.
Despite possible problems as a result of this change, there are
certain environments, such as DB2 address spaces, which may
benefit from the way VSM works in r1.10. DB2 or other
applications which have previously experienced performance
impact from getmain and freemain taking a relatively long time
because DQE chains have become extremely long which may benefit
from merge DQEs resulting in shorter chains.
The potential performance enhancement as a result of merging
DQEs may not be significant in those environments which do not
typically have extremely long DQE chains for user private
subpools.
The fix to this APAR will restore the pre-release 1.10 behavior
as the default to prevent impact to the unsuspecting program
or user. A new DIAGxx trap will be documented by which
those environments which will benefit from the new means of
allocating storage for user private subpools can easily
implement it -- and knowingly be aware of the possible impact to
other programs.
LOCAL FIX:
To reset the r1.10 getmain behavior back to that used in
previous releases until the PTF for this APAR is available, the
following should be inserted in the running DIAGxx member of
parmlib:
NUCLABEL ENABLE(IGVGPVTN)
When you issue SET DIAG=xx DQE merging will no longer be done,
which is the pre-r1.10 behavior.
To re-enable DQE merging again, put the following in DIAGxx
and issue SET DIAG=xx again.
NUCLABEL DISABLE(IGVGPVTN)
====================
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
