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
**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.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
>
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 <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
>
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
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
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
, 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
>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
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
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
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" (
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
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
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
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
22 matches
Mail list logo
