Jesse 1 Robinson wrote:
Good advice for the sandbox. However, identifying the offender is only the
first step. Fixing the problem may turn out to be a long and painful journey
through the whole enterprise.
<snip>
Well, you might have more than one offender. Also, one or more
offenders might not be running in your sandbox environment. Flipping
the switch in production before knowing who the offenders are and
getting them fixed first might be bad. Continuing to allow user key CSA
to be used might also be bad.
A friendly RSM developer (thanks, Steve!) tells me SMF30s can be used to
identify any number of offenders after putting on the very same PTF you
installed for OA53355, which also adds the SMF30_UserKeyCsaUsage field.
This is in the APAR text, and I'm told it's in the DOC HOLD, but I
didn't find it in the z/OS V2.3 SMF book (we will work on fixing that).
It's hard to imagine anyone excluding the ever-useful SMF30 records
from collection, but to process them you would need to turn them on, if
they were off.
Then, you have to run long enough to collect and process the records to
show whether you will break something you care about when you flip the
DIAGxx switch, and get the necessary offenders fixed before the flip.
The risk avoidance aspect of this approach has to be balanced against
the risk of allowing user key CSA until you finish.
The APAR text is here:
https://www-01.ibm.com/support/docview.wss?rs=63&uid=isg1OA53355
Happy hunting...
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
