Hi,
IBM appears to be very aware of VSCR concerns and is providing both large and
small pieces of relief in each z/OS release. A useful option on z/OS 1.9 we
have leveraged with relative ease is moving the LCCA and PCCA above the line.
This nets about 3k for each processor. I have this running in every LPAR that
z/OS 1.9 is implemented into here. We did it at the same time we rolled out
z/OS 1.9 so as to leverage all the testing and validation we did for that large
project. I knew we could always defer moving this change forward if we ran
into a product that we could not get updated in time.
In a nutshell add CBLOC VIRTUAL31(IHALCCA,IHAPCCA) to your DIAGxx
specifications and insure that you have all the fixes applied to OEM or IBM
products that need updating.
Some OEM Products require updates. A typical result of a missing update is
ABEND 0C4 with 31 bit address truncated to 24 bit or failure in authorization
of software CPU key. Here are the ones I found I expect there are others.
SyncSort 1.3 operated correctly EW zaps needed for 1.2 (EW6384, EW6393, EW6400
and EW6464)
BMC Sort Engine (BPJ0163)
CA Common Services R11 SP08
$AVRS (S51BF144)
BMC IMS database utilities (BPQ2681, BAQ2971)
PREFERENCE/PHOENIX zaps S791007 and S791008 are needed
You need to query all your vendors if they support this specific option of z/OS
1.9 and TEST carefully and in a non-production environment first.
Reference: DIAGxx in z/OS V1R9.0 MVS Initialization and Tuning Reference
More background:
Physical Configuration Communication Area (PCCA) is located in SP245 common
storage 548 bytes. Logical Configuration Communication Area (LCCA) is located
in SP239 common storage.
A PCCA and LCCA will be allocated for @ on-line logical processor including
zIIP and zAAP processors. Vector tables point to areas allocated for each CP.
CVTPCCAT --> PCCAVT ---> PCCA @ processor
CVTLCCAT --> LCCAVT --> LCCA @ processor
Always located in < 16M prior to z/OS 1.8 approximately 3K for @ processor
Released when processors are varied offline
Obtained when processors are varied online
Very few OEM products today should be accessing these areas directly if they
are they need to be prepared to find 31 bit addresses. z/OS Monitor products or
other system software may still have a need to access these areas. Bad data
must be handled a recent example APAR OA19440 (07/03/31) LCCAWTIM INVALID
LARGE NEGATIVE VALUE - X'FF00XXXX XXXXXXXX'
Uses for which better supported techniques today might be to obtain information
about CPUs for license enforcement. Using the System Information Service
CSRSI or SYSEVENT QVS might be a better approach today
IBM identified this as an opportunity for VSCR and enabled customers to
optionally move them > 16M recently.
z/OS 1.8 from IBM included an undocumented diagnostic option to implement the
change so that this could be tested outside IBM development
z/OS 1.9 includes this new function as a documented supported part of the base
product with minor syntax changes from the introduction for testing in 1.8
SYS1.PARMLIB(DIAGxx) contains the controls to set the location of these control
blocks
Default is 24-bit storage same as it has always been
1.9 > 16M CBLOC VIRTUAL31(IHALCCA,IHAPCCA)
1.9 > 16M VIRTUAL24(IHALCCA,IHAPCCA) or omit
1.8 > 16M CBLOC VIRTUAL31() 24 bit omit
Behavior if you put it in both lists is “undocumented” but it seems last entry
is the one honored
D DIAG command will show current settings
IGV007I 11.59.54 DIAG DISPLAY 083
VSM TRACK CSA(ON) SQA(ON)
VSM TRACE GET(OFF) FREE(OFF)
VSM CHECKREGIONLOSS(300K,10M)
VSM ALLOWUSERKEYCSA(NO)
CBLOC
VIRTUAL24()
VIRTUAL31(IHALCCA,IHAPCCA)
REUSASID(NO)
I used commands setup in batch job (I used CA-OPSMVS OPSCMD you could use any
facility to issue commands) to document current state and implement or backout
for each LPAR
OC C(D DIAG) WAIT(10)
OC C(SET DIAG=05) WAIT(10)
OC C(D DIAG) WAIT(10)
OC C(SET OPT=99) WAIT(10)
OC C(D M=CPU) WAIT(10)
OC C(CF CPU(00),OFFLINE) WAIT(10)
OC C(CF CPU(00),ONLINE) WAIT(10)
OC C(CF CPU(01),OFFLINE) WAIT(10)
OC C(CF CPU(01),ONLINE) WAIT(10)
OC C(D M=CPU) WAIT(10)
OC C(SET OPT=B1) WAIT(10)
OC C(D M=CPU) WAIT(10)
I decided to toggle off IRD VARYCPU and then turn it back on so that the
backout or implementation always did exactly the same thing. OPT member with
VARYCPU=NO was set before doing the CF CPU commands.
/* VARY CPU MANAGEMENT ENABLED BY DEFAULT */
VARYCPU=NO
You might consider putting some comments in your DIAGxx to explain the entry
/********************************************************************/
/* CBLOC VIRTUAL31(IHALCCA,IHAPCCA) 1.8 31 bit */
/* CBLOC VIRTUAL31() 1.8 24 bit omit */
/* Locate LCCA and PCCA above the line available in 1.8 documented */
/* in 1.9 and the VIRTUAL24 keyword support added */
/* */
/* CBLOC [VIRTUAL24(structure1,structure2, ...)] */
/* [VIRTUAL31(structure1,structure2, |...)] */
/* | ||VIRTUAL24 |Provides the names of structures to be located in */
/* 24-bit virtual storage. | |VIRTUAL31 |Provides the names of */
/* structures to be located in 31-bit virtual storage. | |Structure */
/* names: ||IHALCCA |When a CPU is brought online, the location of */
/* its LCCA is determined |by which list includes IHALCCA. If */
/* neither of the lists includes IHALCCA, |the LCCA is in 24-bit */
/* virtual storage. If both lists include IHALCCA, the |resulting */
/* location is undocumented. The LCCA of the IPL CPU is built in */
/* 24-bit |storage before DIAGxx is processed. |If additional CPUs */
/* are brought online |later in the IPL process, the IPL CPU is */
/* automatically configured offline |and back online, with its LCCA */
/* located according |to the CBLOC specification. */
CBLOC VIRTUAL31(IHALCCA,IHAPCCA)
IBM did the right thing by making the default the old behavior but I hope that
in a release or two they can change the default behavior to locate the areas
above the line and let the minority of installations that need it below specify
that in DIAGxx.
I talked about this at SHARE in San Jose on Friday but I thought it might be
useful for some other folks here too since discussion about VSCR has been a
recurring theme. If you find other OEM or IBM products that require updates
please share here.
Best Regards,
Sam Knutson, GEICO
System z Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
====================
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
