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:
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
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 ch
I 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/2
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
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 impleme
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
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 w
half 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 em
: 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
-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
53.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,ZOSMIG
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
.
Poughkeepsie NY
IBM Mainframe Discussion List 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_USERKEYC
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
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 ENABL
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
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 pro
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,
I
>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
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
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 ef
, 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
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.
---
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'.
--
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 e
>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 app
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 addre
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 20
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
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_A
mt=2
Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
From: Jim Mulder
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
SMF type
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
lder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
IBM Mainframe Discussion List wrote on
04/06/2018 10:46:48 AM:
> From: "Dyck, Lionel B. (TRA)"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/06/2018 11:18 AM
> Subject: Re: [EXTERNAL] Re: IBMVSM,ZOSMI
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 Stupidit
th 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
>
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 lik
37 matches
Mail list logo