Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-05-18 Thread 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

2018-05-18 Thread 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

2018-05-18 Thread 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

2018-05-18 Thread 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" <000001a0403c5dc1-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

2018-05-18 Thread 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

2018-05-17 Thread 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

2018-05-17 Thread 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

2018-05-16 Thread 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: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-04-08 Thread 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

2018-04-08 Thread 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

2018-04-07 Thread 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

2018-04-07 Thread 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

2018-04-07 Thread 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

2018-04-07 Thread 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

2018-04-07 Thread 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

2018-04-07 Thread 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

2018-04-06 Thread 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

2018-04-06 Thread 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

2018-04-06 Thread 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

2018-04-06 Thread 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

2018-04-06 Thread 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

2018-04-06 Thread 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) 
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