(Repost from August 13, 2019)
A reminder about an important upgrade action for z/OS V2.4. Don't overlook it!
You might know that I try to alert everyone to "big migs" they need to pay attention to when upgrading z/OS. This is one I've been talking about for quite a while, but it seems that there are still lots of questions! I hope this information might help address those questions, and I'll keep it extremely straightforward in hopes that more people will be made aware of it.
Of course, if you want full details, you'll need to refer to the z/OS V2.4 Upgrade Workflow (which you can find here, or exported in readable format at the bottom here.).
What is being removed in z/OS V2.4 when you hear "user key common removal"?
There are three items which encompass this removal.
- The ability to have user key storage in CSA/ECSA.
- The ability to change common ESQA storage to a user key (with CHANGKEY)
- Support of user-key SCOPE=COMMON data spaces is removed
Each of those three removals should reviewed now to make sure you are fine for upgrading to V2.4.
#1 User key storage in CSA/ESA
How to see if you are doing this on V2.1, V2.2, or V2.3? Make sure DIAGxx for VSM ALLOWUSERKEYCSA is set to NO. If it is set to NO (or which is defaulting to NO), you are good with this specific removal. However, if it is YES - and when setting to NO results in abends - you need to either change the programs causing the YES (so you have have NO), or use RUCSA.
Don't we have a health check for ALLOWUSERKEYCSA? We do. It's been around for a very long time, IBMVSM,VSM_ALLOWUSERKEYCSA. We've been checking that you've had NO for a long time, we've warned against setting it to YES. There is also a more general health check called IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM, which is for detecting user key common usage.
What is RUCSA? Restricted Use Common Service Area is a new function added to V2.1, V2.2, and V2.3, with APAR OA56180 . This is a free function in z/OS V1.2, V2.2, and V2.3. If you continue to use RUCSA in z/OS V2.4, it is a priced feature that you must enable in IFAPRDxx according to the normal terms associated with priced features. IBM strongly encourages you to not continue to need RUCSA as of z/OS V2.4, but if you need it (because you don't have source code, for example), it will continue to work just as it has on V2.1, V2.2, and V2.3 as long as you have enabled it.
#2 Change common ESQA storage to a user key
How to see if you are doing this on V2.3? Make sure DIAGxx has NUCLABEL ENABLE(IARXLUK2), and IPL. This will abend any attempt to CHANGKEY subpool 247 or 248 common storage to a user key (8-15). Fix the program that is doing he CHANGKEY.
How to see if you are doing this on V2.1, or V2.2? See below "...knowing more about what is causing problems".
Will RUCSA help with this #2 removal? No.
#3 Removal of user-key SCOPE=COMMON data spaces
How to see if you are doing this on V2.1, V2.2, or V2.3? Make sure DIAGxx has ALLOWUSERKEYCADS set to NO. (Sadly, the default is YES.) If you have a DIAGxx setting of YES, fix the program that is using user key SCOPE=COMMON data spaces
Will RUCSA help with this #3 removal? No.
What about knowing more about what is causing problems?
Look at some fields in SMF 30, which include:
- SMF30_UserKeyCsaUsage
- SMF30_UserKeyChangKeyUsage
- SMF30_UserKeyCadsUsage
There are two SLIPs documented in the Workflow. The Workflow also suggests some correction that could be made to fix the problems.
I hope that this has helped be clearer on what is happening both pre-V2.4, and as of V2.4.
Comments
Post a Comment