On 4/6/2018 12:10 PM, Martin Packer wrote:
And Marna Walle and I discussed this in our Podcast Episode (18) "What We
Won't Have In Common Anymore" (
https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/Mainframe_Performance_Topics_Podcast_Episode_18_What_We_Won_t_Have_In_Common_Anymore?lang=en
)
Which is one of the reasons why we're listening to this thread right now.
Anyone got feedback or follow up on that item? We'd gladly entertain it -
for the next episode.
Thanks, Martin
Martin Packer
Martin,
IBM messed this up in at least three ways.
1. The fact that VSM_ALLOWUSERKEYCSA(NO) was thought to be the only way
to get user key common is now blown out of the water. There is almost
no explanation in the APAR that this is now the case. I'm sure those
who created the APAR understood this, but I only understood it after
opening a PMR to find out WTF the health check was firing on my
VSM_ALLOWUSERKEYCSA(NO) system.
2. The new user key common exploits WERE NOT given DIAGxx traps to
prevent their exploitation. You can apparently stop them with SLIP
TRAPs that create unsightly abends.
3. The new health check buries the information in the new SMF 30 record
fields (which is only documented in the APAR and not the manual). The
APAR says we all need to write our own code to parse this data for this
health check. Great idea to have hundreds of IBM customers write their
own code to access this data. And when those customers report
inconsistent data back to IBM or the ISV's violating user key common?
No biggie.
Deal with any or all three of these. We'll likely have to submit RFE's
to get DIAG traps that should have been GA with the APAR.
Regards,
Tom Conley
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
