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 <IBM-MAIN@LISTSERV.UA.EDU> wrote on 04/06/2018 10:46:48 AM: > From: "Dyck, Lionel B. (TRA)" <lionel.d...@va.gov> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 04/06/2018 11:18 AM > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > 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:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Lou Losee > Sent: Friday, April 06, 2018 9:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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) <lionel.d...@va.gov> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN