Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-16 Thread 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:

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-16 Thread 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

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-16 Thread 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

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-16 Thread 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.

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-16 Thread 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

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-15 Thread 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

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2019-04-15 Thread 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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-05-18 Thread Michael Babcock
sistant 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 Discu

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-05-18 Thread Jousma, David
: 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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-05-18 Thread Michael Babcock
53.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 >

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-05-17 Thread Jousma, David
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 ALLOWUSERKEY

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

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-04-09 Thread 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,

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

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.

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

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

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

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

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

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

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" (

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

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

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-04-06 Thread Dyck, Lionel B. (TRA)
ame 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_USERKEYC

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-04-06 Thread Jim Mulder
nTek 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_USE

Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-04-06 Thread Dyck, Lionel B. (TRA)
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 - Unkn

Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

2018-04-06 Thread 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) wrote: > IBM provides a