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 zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: [email protected] Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/ or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Jim Mulder <[email protected]> To: [email protected] Date: 06/04/2018 16:25 Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM Sent by: IBM Mainframe Discussion List <[email protected]> SMF type 30 records are address space specific. And there is a RAX (mapped by SYS1.MODGEN(IARRAX), pointed to by ASCBRSME) for each address space. RAX_SMF30_SAPFlags DS BL1 SMF Type 30 Storage and Paging * Flag byte @0EA RAX_UserKeyCommonAuditEnabled EQU X'80' Bit indicating that auditing * of user key common storage usage * attempts was enabled for this * address space - Set by SMF @0EA RAX_UserKeyCsaUsage EQU X'40' Bit indicating that * attempts were made to obtain * user key CSA storage for * this address space @0EA RAX_UserKeyCadsUsage EQU X'20' Bit indicating that * attempts were made to create * a user key CADS for * this address space @0EA RAX_UserKeyChangKeyUsage EQU X'10' Bit indicating that * attempts were made to change the * key of common ESQA storage to * a user key (via CHANGKEY) * for this address space @0EA Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List <[email protected]> wrote on 04/06/2018 10:46:48 AM: > From: "Dyck, Lionel B. (TRA)" <[email protected]> > To: [email protected] > Date: 04/06/2018 11:18 AM > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM > Sent by: IBM Mainframe Discussion List <[email protected]> > > Lou - you may be right but if they can record it in SMF records then > they can expose it in some way that doesn't require each individual > installation to write code to analyze the records. If they can > detect it then one would hope they can at least tell which address > space did it. > > -------------------------------------------------------------------------- > Lionel B. Dyck (Contractor) <sdg>< > Mainframe Systems Programmer ? RavenTek Solution Partners > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected] > ] On Behalf Of Lou Losee > Sent: Friday, April 06, 2018 9:43 AM > To: [email protected] > Subject: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM > > Lionel, > Couldn't it be the case that IBM knows where the use of common > storage occurred but not who the offender is? > > Lou > > -- > Artificial Intelligence is no match for Natural Stupidity > - Unknown > > On Fri, Apr 6, 2018 at 9:31 AM, Dyck, Lionel B. (TRA) <[email protected]> > wrote: > > > IBM provides a new Health Check - > > IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM > > > > But it is worthless (see below) - it tells me we have an issue that is > > HIGH *BUT* it does not tell me who/what. If you can detect it then > > provide more info otherwise it's a near useless health check - it's > > like going to the Doctor who tells you that you have a problem but > > refuses to tell you what your problem is but if you really want to > know then go to a specialist. > > > > IBM - you detected the issue and you won't tell me the specifics - ARG! > > > > CHECK(IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM) > > SYSPLEX: AUSTIN1 SYSTEM: SYP > > START TIME: 04/06/2018 09:01:46.169645 CHECK DATE: 20170807 CHECK > > SEVERITY: HIGH CHECK PARM: ALL > > > > > > * High Severity Exception * > > > > IGVH114E Use of user key common storage detected since > > 03/04/2018 02:37:42 > > > > > > ---------------------------------------------------------------------- > > ---- > > Lionel B. Dyck (Contractor) <sdg>< > > Mainframe Systems Programmer - RavenTek Solution Partners Service > > Operations - Infrastructure Operations Office of Information and > > Technology, IT Operations and Services > > Office: 512-326-6173 > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
