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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to