Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Bruce Hewson]

IBM's reply contained this:-

If you take a look at OA53355, you'll see the full description of the   
healthcheck and how you can adjust it or reset.   Here is the portion   
that you'd be interested in:

Add the following new Health check: 

ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM 
Description:
This check determines if any usage of user key common   
storage was detected on the system. 
Reason for check:   
Allowing programs to use user key common creates a  
security risk because common storage can then be
modified by any unauthorized program. This check
provides advanced warning of this potential security
risk so the system programmer can take appropriate action.  
z/OS releases the check applies to: 
z/OS V2R1 and later.
Parameters accepted:
The following parameters are supported to control WTOs  
produced by exception messages when a new user key common   
storage usage attempt is detected:  
PARM('ALL') 
Exceptions should be issued if there are any user   
key common storage usage attempts made on this  
system since the last IPL.  
==> PARM('NEW(text value)')   <===  
Exceptions should only be issued for user key common
storage usage attempts that are detected after this 
parameter is set. The 'text value' is   
free-form and is not used by health check   
processing. It should contain text to help the user 
uniquely identify this particular parameter set.
The following are examples of PARM specifications for   
ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM:
PARM('NEW(/mm/dd hh:mm)')   
PARM('ALL') 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[David Hom]

Hello Barbara/Bruce,


>parm(new) did the trick! This bit of information must have been buried in all 
>the RUCSA stuff that I skipped over because it doesn't apply to us.<

Yes, OA56180 had quite a bit of documentation, but this trick was actually 
buried in the OA53355 documentation :-)


>On one system the HealthCheck triggered, saying event started in middle of 
>March. review of all SMF data through March found no culprits. IBM support 
>suggested to find the first IGVH114E in OPERLOG for the system. I found one in 
>April. Review of April SMF located the bad boy.<

I want to add one more (possibly obvious) tip.  When you find the first 
instance of IGVH114E, you only need to look at SMF data from the past hour (or 
whatever the health check interval is set to, the default interval setting is 
an hour).  For example, if the first IGVH114E was issued on April 16, 2019 at 
8:47am, you only need to review SMF data starting at April 16, 2019 at 7:47am.  
This could save you from having to go over a half a month of SMF data in your 
scenario.


>I read over the apar text of oa56180. I didn't see that it talks about 
>correcting the audit flag not being set correctly. I must have again 
>overlooked something.<

You are right.  We'll add this to the APAR text.  As you can tell, OA56180 is 
sort of a followup to OA53355.  The problem was found during OA56180 
development.

Regards,
David Hom

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

Hi Bruce,

>I have the same query open with IBM at the moment.
Well, it helps that I am not alone with that question. :-) 

>If you could provide an example of a RESET command I would most appreciate.
I didn't use it. All I did was go into sdsf and then scroll to the extreme 
right of the health check line. There is the parm for each check. I just 
overtyped it with what David specified. On pressing return the check moved from 
the top of my list (I have them sorted by severity) to the alphabetical place 
where it belongs, I didn't even have to refresh the check.

I read over the apar text of oa56180. I didn't see that it talks about 
correcting the audit flag not being set correctly. I must have again overlooked 
something.

Regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Bruce Hewson]

Hello Babara/David,

hints enough in your 2 posts to locate the manual:-

PARM('NEW(text value)')
Exceptions should only be issued for user key common storage usage attempts 
that are detected
after this parameter is set. The 'text value' is free-form and is not used by 
health check
processing. It should contain text to help the user uniquely identify this 
particular parameter set.

The following are examples of PARM specifications for 
ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM:

PARM('NEW(/mm/dd hh:mm)')
PARM('ALL')

before UPDATE command:- IGVH113I Use of user key common storage was not 
detected since  03/28/2019 13:47:36

F HZSPROC,UPDATE,CHECK(IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM),parm=('new(reset 
04/16/2019)') 

after UPDATE command:-IGVH113I Use of user key common storage was not detected 
since 04/16/2019 02:14:44  

timely posts.

Thanks
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Bruce Hewson]

Hi Barbara/David,

I have the same query open with IBM at the moment.

On one system the HealthCheck triggered, saying event started in middle of 
March. review of all SMF data through March found no culprits. IBM support 
suggested to find the first IGVH114E in OPERLOG for the system. I found one in 
April. Review of April SMF located the bad boy.

The IBM support had mentioned RESET of the Health Check, so I had asked for an 
example.
So far no response to that question.

If you could provide an example of a RESET command I would most appreciate.

Thanks
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

Hello David,

parm(new) did the trick! This bit of information must have been buried in all 
the RUCSA stuff that I skipped over because it doesn't apply to us.
We don't have oa56180 applied yet, so that explains why the audit bit wasn't on 
in some cases.

I feel much more confident now to implement allowuserkeycads(no) and NUCLABEL 
ENABLE(IARXLUK2) to prevent usage on all systems.

Thanks a lot, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[David Hom]

Hello Barbara,

Q1) 
The supporting code for APAR OA53355 turns on the audit flag.  The audit flag 
is used to indicate that the supporting code to detect user key common usage is 
installed and that the other bits are meaningful.  There was an issue where 
some SMF type 30 records did not have the audit flag on even with OA53355 
installed.  That issue was resolved with APAR OA56180.

Q2) 
Yes, the health check checks back to the time of the last IPL and reports on 
that.  This changes if you reset the health check using PARM('NEW(text 
value)').  At that point, it checks back to the time of the last 'reset' and 
reports on that.   A health check reset is recommended after all offenders are 
'fixed' so that the health check will stop 'complaining' about 'fixed' 
offenders.  See the IBM Health Checker for z/OS User's Guide for more details 
on how to reset this health check.

Regards, David Hom

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

I know we've been through a few iterations of this, and I still have questions:
We had one offender that was using a key=8 CADS. They have since provided a 
release where they use a system key for their CADS, and that release has been 
installed on all sysplexes/systems. 

I was really astonished when the health check *still* complains about user key 
common storage. We have been running with ALLOWUSERKEYCSA(NO) just about 
forever and had this one offender which got remedied dynamically *after* the 
last IPL. I spent the past two days over SMF records, and while the audit flag 
is mostly on, the only time I saw one of the other flags on (thanks MXG!) was 
exactly for that one, now fixed offender. Every other SMF30 records with a bit 
on in the flags section  does NOT at the same time have the audit flag on, so 
according to the doc that record doesn't count as usage.

Q1: What exactly turns the audit flag on or off (leftmost bit in the flag byte)?

Q2: Is it true that the health check actually checks back to the time of the 
last IPL and reports on that? That would fit with the fact that the production 
system has the check run successfully. But that system was IPL'd after the 
offender got fixed.

Thanks in advance, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Michael Babcock]

Yep, that worked for me as well.

On Fri, May 18, 2018 at 9:28 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Although a SET DIAG=00 when coding the same parm without the VSM on the
> front of it. And a D DIAG shows
>
> IGV007I 10.27.59 DIAG DISPLAY 034
> VSM TRACK CSA(ON) SQA(ON)
> VSM TRACE GET(OFF) FREE(OFF)
> VSM CHECKREGIONLOSS(665K,50M)
> VSM ALLOWUSERKEYCSA(YES)
> VSM BESTFITCSA(NO)
> VSM USEZOSV1R9RULES(YES)
> TRAPS NAME()
> CBLOC
>   VIRTUAL24()
>   VIRTUAL31()
> REUSASID(YES)
> ALLOWUSERKEYCADS(NO)
> AUTOIPL SADMP(NONE) MVS(NONE)
> FREEMAINEDFRAMES(YES)
> FF31HIGH(YES)
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546
> <https://maps.google.com/?q=1830+East+Paris,+Grand+Rapids,+MI%C2%A0+49546=gmail=g>
> MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Friday, May 18, 2018 10:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Yes, failed for me on V2.3
>
> IEE252I MEMBER DIAG00   FOUND IN SYS1.PARMLIB
> ASA003I SYNTAX ERROR IN PARMLIB MEMBER=DIAG00 ON LINE 31, 018
> POSITION 6: ALLOWUSERKEYCADS WAS SEEN, WHERE ONE OF
> (DETECT PROTECT CHECKREGIONLOSS TRACE
> TRACK PRIVATEBUFFER ALLOWUSERKEYCSA USEZOSV1R9RULES
> BESTFITCSA)
> WOULD BE CORRECT.
> DETECTING MODULE IS IGVDITMS. INPUT LINE:
>  VSM ALLOWUSERKEYCADS(NO)
> IEE536I DIAG VALUE 00 NOW IN EFFECT
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546
> <https://maps.google.com/?q=1830+East+Paris,+Grand+Rapids,+MI%C2%A0+49546=gmail=g>
> MD RSCB2H p 616.653.8429 f 616.653.2717
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Michael Babcock
> Sent: Friday, May 18, 2018 10:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> This keyword was not accepted by my z/OS 2.2 system when I did a SET DIAG=
>
> VSM ALLOWUSERKEYCADS(NO)
>
> On Fri, May 18, 2018 at 6:06 AM Jousma, David <
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Thanks Jim!
> >
> > _
> > Dave Jousma
> > Manager Mainframe Engineering, Assistant Vice President
> > david.jou...@53.com
> > 1830 East Paris, Grand Rapids, MI  49546
> > <https://maps.google.com/?q=1830+East+Paris,+Grand+Rapids,+MI%C2%A0+49
> > 546=gmail=g>
> > MD RSCB2H
> > p 616.653.8429
> > f 616.653.2717
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jim Mulder
> > Sent: Thursday, May 17, 2018 6:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> >It was  implemented in z/OS 1.11, and disclosed it to the ISVs, but
> > it was not documented at that time because it would not be useful to
> > customers until software vendors had time to get their products into
> compliance.
> >
> > Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> > Poughkeepsie NY
> >
> > IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
> > 05/17/2018 06:58:28 AM:
> >
> > > From: "Jousma, David"
> > > <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Date: 05/17/2018 06:35 PM
> > > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> > > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> > >
> > > Jim,
> > >
> > > You said:
> > >
> > > On any currently supported release of z/OS,  in

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jousma, David]

Although a SET DIAG=00 when coding the same parm without the VSM on the front 
of it. And a D DIAG shows

IGV007I 10.27.59 DIAG DISPLAY 034   
VSM TRACK CSA(ON) SQA(ON)   
VSM TRACE GET(OFF) FREE(OFF)
VSM CHECKREGIONLOSS(665K,50M)   
VSM ALLOWUSERKEYCSA(YES)
VSM BESTFITCSA(NO)  
VSM USEZOSV1R9RULES(YES)
TRAPS NAME()
CBLOC   
  VIRTUAL24()   
  VIRTUAL31()   
REUSASID(YES)   
ALLOWUSERKEYCADS(NO)
AUTOIPL SADMP(NONE) MVS(NONE)   
FREEMAINEDFRAMES(YES)   
FF31HIGH(YES)   

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 18, 2018 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Yes, failed for me on V2.3

IEE252I MEMBER DIAG00   FOUND IN SYS1.PARMLIB 
ASA003I SYNTAX ERROR IN PARMLIB MEMBER=DIAG00 ON LINE 31, 018 
POSITION 6: ALLOWUSERKEYCADS WAS SEEN, WHERE ONE OF   
(DETECT PROTECT CHECKREGIONLOSS TRACE 
TRACK PRIVATEBUFFER ALLOWUSERKEYCSA USEZOSV1R9RULES   
BESTFITCSA)   
WOULD BE CORRECT. 
DETECTING MODULE IS IGVDITMS. INPUT LINE: 
 VSM ALLOWUSERKEYCADS(NO) 
IEE536I DIAG VALUE 00 NOW IN EFFECT   

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Babcock
Sent: Friday, May 18, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This keyword was not accepted by my z/OS 2.2 system when I did a SET DIAG=

VSM ALLOWUSERKEYCADS(NO)

On Fri, May 18, 2018 at 6:06 AM Jousma, David < 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks Jim!
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546
> <https://maps.google.com/?q=1830+East+Paris,+Grand+Rapids,+MI%C2%A0+49
> 546=gmail=g>
> MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jim Mulder
> Sent: Thursday, May 17, 2018 6:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
>It was  implemented in z/OS 1.11, and disclosed it to the ISVs, but 
> it was not documented at that time because it would not be useful to 
> customers until software vendors had time to get their products into 
> compliance.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
> IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
> 05/17/2018 06:58:28 AM:
>
> > From: "Jousma, David" 
> > <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/17/2018 06:35 PM
> > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> >
> > Jim,
> >
> > You said:
> >
> > On any currently supported release of z/OS,  in DIAGxx, you can 
> > specify
> >
> > ALLOWUSERKEYCADS(NO)
> >
> >
> > I don't see that in Init & Tuning?   Is this an undocumented option?
> >
> > _
> > Dave Jousma
> > Manager Mainframe Engineering, Assistant Vice President 
> > david

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jousma, David]

Yes, failed for me on V2.3

IEE252I MEMBER DIAG00   FOUND IN SYS1.PARMLIB 
ASA003I SYNTAX ERROR IN PARMLIB MEMBER=DIAG00 ON LINE 31, 018 
POSITION 6: ALLOWUSERKEYCADS WAS SEEN, WHERE ONE OF   
(DETECT PROTECT CHECKREGIONLOSS TRACE 
TRACK PRIVATEBUFFER ALLOWUSERKEYCSA USEZOSV1R9RULES   
BESTFITCSA)   
WOULD BE CORRECT. 
DETECTING MODULE IS IGVDITMS. INPUT LINE: 
 VSM ALLOWUSERKEYCADS(NO) 
IEE536I DIAG VALUE 00 NOW IN EFFECT   

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Babcock
Sent: Friday, May 18, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This keyword was not accepted by my z/OS 2.2 system when I did a SET DIAG=

VSM ALLOWUSERKEYCADS(NO)

On Fri, May 18, 2018 at 6:06 AM Jousma, David < 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks Jim!
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 
> <https://maps.google.com/?q=1830+East+Paris,+Grand+Rapids,+MI%C2%A0+49
> 546=gmail=g>
> MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jim Mulder
> Sent: Thursday, May 17, 2018 6:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
>It was  implemented in z/OS 1.11, and disclosed it to the ISVs, but 
> it was not documented at that time because it would not be useful to 
> customers until software vendors had time to get their products into 
> compliance.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
> IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
> 05/17/2018 06:58:28 AM:
>
> > From: "Jousma, David" 
> > <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/17/2018 06:35 PM
> > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> >
> > Jim,
> >
> > You said:
> >
> > On any currently supported release of z/OS,  in DIAGxx, you can 
> > specify
> >
> > ALLOWUSERKEYCADS(NO)
> >
> >
> > I don't see that in Init & Tuning?   Is this an undocumented option?
> >
> > _
> > Dave Jousma
> > Manager Mainframe Engineering, Assistant Vice President 
> > david.jou...@53.com
> > 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> > 616.653.2717
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or 
> disseminate it in any manner. If you are not the intended recipient, 
> any disclosure, copying, distribution or use of the contents of this 
> information is prohibited. Please reply to the message immediately by 
> informing the sender that the message was misdirected. After replying, 
> please erase it from your computer system. Your assistance in correcting this 
> error is appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Michael Babcock]

This keyword was not accepted by my z/OS 2.2 system when I did a SET DIAG=

VSM ALLOWUSERKEYCADS(NO)

On Fri, May 18, 2018 at 6:06 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks Jim!
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546
> <https://maps.google.com/?q=1830+East+Paris,+Grand+Rapids,+MI%C2%A0+49546=gmail=g>
> MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jim Mulder
> Sent: Thursday, May 17, 2018 6:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
>It was  implemented in z/OS 1.11, and disclosed it to the ISVs, but it
> was not documented at that time because it would not be useful to customers
> until software vendors had time to get their products into compliance.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
> IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
> 05/17/2018 06:58:28 AM:
>
> > From: "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/17/2018 06:35 PM
> > Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> >
> > Jim,
> >
> > You said:
> >
> > On any currently supported release of z/OS,  in DIAGxx, you can
> > specify
> >
> > ALLOWUSERKEYCADS(NO)
> >
> >
> > I don't see that in Init & Tuning?   Is this an undocumented option?
> >
> > _
> > Dave Jousma
> > Manager Mainframe Engineering, Assistant Vice President
> > david.jou...@53.com
> > 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> > 616.653.2717
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jousma, David]

Thanks Jim!

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Mulder
Sent: Thursday, May 17, 2018 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

   It was  implemented in z/OS 1.11, and disclosed it to the ISVs, but it was 
not documented at that time because it would not be useful to customers until 
software vendors had time to get their products into compliance.
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
05/17/2018 06:58:28 AM:

> From: "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/17/2018 06:35 PM
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> Jim,
> 
> You said:
> 
> On any currently supported release of z/OS,  in DIAGxx, you can 
> specify
> 
> ALLOWUSERKEYCADS(NO)
> 
> 
> I don't see that in Init & Tuning?   Is this an undocumented option?
> 
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 
> 616.653.2717



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jim Mulder]

   It was  implemented in z/OS 1.11, and disclosed it to the ISVs, but it 
was 
not documented at that time because it would not be useful to customers
until software vendors had time to get their products into compliance.
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
05/17/2018 06:58:28 AM:

> From: "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/17/2018 06:35 PM
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> Jim,
> 
> You said:
> 
> On any currently supported release of z/OS,  in DIAGxx, you can specify
> 
> ALLOWUSERKEYCADS(NO)
> 
> 
> I don't see that in Init & Tuning?   Is this an undocumented option?
> 
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jousma, David]

Jim,

You said:

On any currently supported release of z/OS,  in DIAGxx, you can specify

ALLOWUSERKEYCADS(NO)


I don't see that in Init & Tuning?   Is this an undocumented option?

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Mulder
Sent: Wednesday, May 16, 2018 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On any currently supported release of z/OS,  in DIAGxx, you can specify

ALLOWUSERKEYCADS(NO)

  This will cause a 01D-xx0015xx  abend when an attempt is made to obtain a 
user key (8-15) SCOPE=COMMON data space. 

On z/OS 2.3 (but not on lower releases),  in DIAGxx,  you can specify

NUCLABEL ENABLE(IARXLUK2)

  This will cause a 08F-1C abend when an attempt is made to use CHANGKEY to 
change subpool 247 or 248 common storage to  a user key (8-15).


 I will look into getting this documentation added to APAR OA53355.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


>From: Tom Conley <pinnc...@rochester.rr.com>
>Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>Date: Fri, 6 Apr 2018 12:54:20 -0400

>IBM messed this up in at least three ways.

.

>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.




>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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jim Mulder]

On any currently supported release of z/OS,  in DIAGxx, you can specify

ALLOWUSERKEYCADS(NO)

  This will cause a 01D-xx0015xx  abend when an attempt is made
to obtain a user key (8-15) SCOPE=COMMON data space. 

On z/OS 2.3 (but not on lower releases),  in DIAGxx,  you can specify

NUCLABEL ENABLE(IARXLUK2)

  This will cause a 08F-1C abend when an attempt is made to use
CHANGKEY to change subpool 247 or 248 common storage to
 a user key (8-15).


 I will look into getting this documentation added to APAR OA53355.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


>From: Tom Conley 
>Reply-To: IBM Mainframe Discussion List 
>Date: Fri, 6 Apr 2018 12:54:20 -0400

>IBM messed this up in at least three ways.

.

>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.




>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

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Tim Hare]

I'm catching up late here, but in connection with the original poster's 
statement, couldn't the health check "go hunting" and report the offenders?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Peter Relson]

If you can use the SLIP trap with A=TRACE that is mentioned in the APAR, 
then changing
TRDATA=(STD,REGS) 
to
TRDATA=(STD,REGS,0R?,+7) will, for the CADS event type, also capture the 
data space name. The extra 8 bytes won't have anything useful or 
identifiable for the other two cases.

That's probably easier for most than doing what Barbara N did.

I would expect that the CADS name would contain the owner's module prefix 
so should be pretty easy to attribute to a particular vendor (be that IBM 
or someone else).

We're looking to see about getting the APAR text updated with that info.


Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

Brian,

>I would think your RASP dump would only be a point in time view of User Key 
>Common at the instant of taking the dump. User Key Common that didn't exist at 
>the time you took the dump wouldn't appear, right?

Completely true. On the other hand: In my experience, user key common (CADS, 
IARV* shared, even Unix shared) has always been set up for long(er) durations, 
so in 99.9% of the cases it should not matter. But those pesky 0.1%!!! 

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Brian Peterson]

>Which brings me to my question: Do I still have to set slip traps or >can I be 
>sure to have caught everything?

Barbara

I would think your RASP dump would only be a point in time view of User Key 
Common at the instant of taking the dump. User Key Common that didn't exist at 
the time you took the dump wouldn't appear, right?

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

Replying to several posts:

When I activated OA53355 on my z/OS 2.3 system, I activated that check. It 
tripped immediately and gave me the possibilities (other than what the diag 
trap we've been running with already excluded):
- SCOPE=ALL data space  
- IARVSERV SHARE   
- IARV64 GETSHARED  
- z/OS UNIX shared memory 

Then I did what I always do in these situations: I dumped the RASP address 
space and its data spaces and used IPCS to go hunting (being the impatient sort 
 I didn't want to go the slip route). I used several incantations of IPCS 
RSMDATA, and voila, there was the offender: A common access data space used by 
EMCs GDDR product. None of the other situations seemed to apply to my system. 
Also, DEVMAN and JES2AUX did not show up.

Which brings me to my question: Do I still have to set slip traps or can I be 
sure to have caught everything?

(We were told by EMC that it will take until the next z/OS release until they 
will provide a fix for this.)

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Peter Relson]

The environments in which (mis)use of userkey common occurs make tracking 
via generic tracker generally not possible. 

It has been possible to reject these situations for well over 10 years. 
And much of z/OS testing does exactly that. 

The PER IF SLIP trap approach that is provided is a very effective way to 
capture anomalous cases, particularly once you have gotten to the point 
where these are exceptions, not business as usual.
If you're going to ask someone (IBM or otherwise) to "prove" if they are 
or are not the culprit, you are likely going to have to run with this SLIP 
trap to catch (and then identify) the culprit.

You should consider running with the SLIP trap. When/If it catches 
something, identify it (and get a fix underway), set up a SLIP trap to 
ignore that one, repeat.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jousma, David]

Should be easier.   I used Omegamon to display that.   We have just one lonely 
user of it, that we are working to retire.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Peterson
Sent: Saturday, April 07, 2018 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I hope folks don't misunderstand my point. User Key Common is a scurge and we 
can't be rid of it soon enough.

However, IBM needs to understand that their current offering of a PER IF SLIP 
trap / GTF trace is not a user-friendly way to identify the culprit.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Brian Peterson]

I hope folks don't misunderstand my point. User Key Common is a scurge and we 
can't be rid of it soon enough.

However, IBM needs to understand that their current offering of a PER IF SLIP 
trap / GTF trace is not a user-friendly way to identify the culprit.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Tom Conley]

On 4/7/2018 1:35 PM, Brian Peterson wrote:

On my system, JES2AUX and DEVMAN are both flagged.  "I" suspect they are 
innocent, but perhaps I should just open PMRs and have those components prove it.


If I wasn't laughin', I'd be cryin'.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Brian Peterson]

On my system, JES2AUX and DEVMAN are both flagged.  "I" suspect they are 
innocent, but perhaps I should just open PMRs and have those components prove 
it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Peter Relson]

>RAX_SMF30_SAPFlags 

This information is captured in the SMF30 records as of the APAR that 
introduced this health check (OA53355), in the byte at offset 178 (x'B2') 
in the Storage and Paging section of the SMF 30 record mapped by DSECT 
SMF30SAP in macro IFASMFR3.

And information about that appears to be presented in the health check 
message buffer which the OP did not completely include in his post. (At 
least I can see that it is defined; I did not view the actual output of 
the check)

It should look something like this:

Please report this problem to the system programmer.  In the SMF Type 30 
records, 
the SMF30_UserKeyCsaUsage, SMF30_UserKeyCadsUsage and 
SMF30_UserKeyChangKeyUsage flags in the Storage and Paging 
section can be used in conjunction with fields in the Identification 
section to identify all 
job steps that use user key common storage. Change the affected software 
to support having the 
user key common areas of virtual storage protected in a system key, or 
change the affected software to support the 
storage not be common to all address spaces. Some alternatives for sharing 
storage instead of having storage 
common to all address spaces include the following options: 
 
  - Use a SCOPE=ALL data space to share data space storage 
with select units of work in select address spaces. 
  - Use IARVSERV SHARE to share below the bar storage with 
select address spaces. 
  - Use IARV64 GETSHARED to share above the bar storage with 
select address spaces. 
  - Use z/OS UNIX shared memory to share below the bar or 
above the bar storage with select address spaces. 

I did notice that the message text for IGVH114E itself is not available in 
the KC documentation (the check itself is). I have asked the ID folks to 
remedy that situation.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Tom Conley]

On 4/6/2018 10:51 PM, Brian Peterson wrote:

Tom, good points.

However, I've been working with the SMF data, and have to say it's not very 
helpful. Similar in fact to the system-level health check. The SMF record only 
says that User Key common storage was allocated by some program in this address 
space.

But which program in this address  space did it? The SMF record doesn't say.

We have third party vendor code who's programs run in a variety of address spaces. Is it 
the address space flagged by the SMF record, or is the culprit actually a third party 
product that interjects it's code into the "victim" or target address space? 
The SMF record doesn't say.

Back some years ago, when we were cleaning up obsolete/ancient console 
identifiers, I seem to recall a console tracker facility that gave us actual 
honest to god program names.

How about something like that?

Brian



Brian,

OMG, this is even better!!  You waste time writing a program to parse 
the SMF type 30's, and you still don't get the data you need.  ROTFLMFAO!


Your second point is awesome, this is a job for the Generic Tracker. 
How 'bout it Marna?


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Martin Packer]

Without wishing to open a can of worms, I can say there are several
program-related items I’d love to see in SMF 30 (or similar).

For example, today we have the Top TCB Program Name and Percent in SMF 30.
I’d love to have “top 3” or “top 5”.

But I digress... :-)

Sent from my iPad

> On 7 Apr 2018, at 03:52, Brian Peterson
 wrote:
>
> Tom, good points.
>
> However, I've been working with the SMF data, and have to say it's not
very helpful. Similar in fact to the system-level health check. The SMF
record only says that User Key common storage was allocated by some program
in this address space.
>
> But which program in this address  space did it? The SMF record doesn't
say.
>
> We have third party vendor code who's programs run in a variety of
address spaces. Is it the address space flagged by the SMF record, or is
the culprit actually a third party product that interjects it's code into
the "victim" or target address space? The SMF record doesn't say.
>
> Back some years ago, when we were cleaning up obsolete/ancient console
identifiers, I seem to recall a console tracker facility that gave us
actual honest to god program names.
>
> How about something like that?
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Brian Peterson]

Tom, good points.

However, I've been working with the SMF data, and have to say it's not very 
helpful. Similar in fact to the system-level health check. The SMF record only 
says that User Key common storage was allocated by some program in this address 
space.

But which program in this address  space did it? The SMF record doesn't say.

We have third party vendor code who's programs run in a variety of address 
spaces. Is it the address space flagged by the SMF record, or is the culprit 
actually a third party product that interjects it's code into the "victim" or 
target address space? The SMF record doesn't say.

Back some years ago, when we were cleaning up obsolete/ancient console 
identifiers, I seem to recall a console tracker facility that gave us actual 
honest to god program names.

How about something like that?

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Tom Conley]

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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Martin Packer]

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: martin_pac...@uk.ibm.com

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 <d10j...@us.ibm.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/04/2018 16:25
Subject:    Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



  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_SAPFlagsDS 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)  <
> 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)
> > S

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Dyck, Lionel B. (TRA)]

Jim - this is all great info but it requires each installation to write their 
own code for the analysis - could you provide code in samplib or for download 
to do it for us?

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer - RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Mulder
Sent: Friday, April 06, 2018 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

  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_SAPFlagsDS 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)  <
> 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)  <
> > Mainframe Systems Programmer - RavenTek Solution Partners Service 
> > Operations - 

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Jim Mulder]

  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_SAPFlagsDS 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)  <
> 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)  <
> > 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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Dyck, Lionel B. (TRA)]

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)  <
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)  <
> 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Lou Losee]

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)  <
> 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Dyck, Lionel B. (TRA)]

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)  <
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