Cheers! We have tested an early version of a fix to resolve this issue, and it
appears to work just fine. My thanks to ASG for their efforts to resolve this
issue.
Our tech LPAR is still running VSM ALLOWUSERKEYCSA(NO) - 16 days and
counting - I'm starting to think we might really be
Peter Relson wrote:
Dreaming, I'm afraid, Ed.
If storage protect override exists on the machine, the PKM will
start
as
tcbkey+key9 and will be maintained that way.
If id does not exist, it would start as just tcbkey and stay that
way.
I searched the archives to see if this had
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Craddock, Chris
Sent: Sunday, July 29, 2007 8:17 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: KEY8 CSA: Pro/JCL and Info/XE
/snip/
It may be the case that I'm just having a senior moment
The point I was making was that the PKM for a newly-attached TCB did not
include key 9. Yet, after recovering from an abend via ESTAE, the key 9
bit in the PKM was magically added!
Was I dreaming that? Didn't it work that way just a few years ago?
Dreaming, I'm afraid, Ed.
If storage protect
For a job, your key is the key you get control in which is the TCB key.
If you are authorized enough to get into supervisor state, once there you
can of course switch to any key. And the system will happily let you get
storage in that key, prior to the check for preventing user key csa,
Peter Relson wrote:
Dreaming, I'm afraid, Ed.
If storage protect override exists on the machine, the PKM will start as
tcbkey+key9 and will be maintained that way.
If id does not exist, it would start as just tcbkey and stay that way.
I searched the archives to see if this had been
On Sat, 2007-07-28 at 14:54 -0700, Edward Jaffe wrote:
I guess Chris and I both had the same dream. Weird!
So you're asserting both you and Craddock are weird ???.
Can't see anyone arguing ... ;0)
Shane ...
(been away for a few days - must go back and see what this (thread) was
all about.)
D'oh - previous mail was supposed to go to Jaffe.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
-- snip --
:Ed Jaffe asks...
: Out of curiosity, which software products allocate CSA in keys A-
: F?
:I know of one major vendor's storage management product that right up
:until the last time I looked (more than a year ago) ran in key 10
:(X'A0') and used a bunch of CSA in key 10. The
Peter Relson wrote:
IIRC, the PKM (PSW Key Mask) starts at x'0080' and gets changed to
x'00C0' after an abend. Weird.
You're not remembering correctly. It starts as TCB key plus key 9. Plus
key 9 is always done on current machines.
You're right. I should have said TCB key. Obviously,
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of David Andrews
Sent: Friday, July 27, 2007 8:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: KEY8 CSA: Pro/JCL and Info/XE
On Thu, 2007-07-26 at 15:39 -0400, Jim Mulder wrote:
A V=R (ADDRSPC=REAL
On Thu, 2007-07-26 at 15:39 -0400, Jim Mulder wrote:
A V=R (ADDRSPC=REAL) job step is assigned a key from the 10-15 range.
I think Bob Rogers mentioned a handful of shares ago (maybe Dallas?)
that he was considering optimizing it out; he left the impression that
V=R was a short timer. Are there
IIRC, the PKM (PSW Key Mask) starts at x'0080' and gets changed to
x'00C0' after an abend. Weird.
You're not remembering correctly. It starts as TCB key plus key 9. Plus
key 9 is always done on current machines.
That's why I never use MODESET MODE=PROB, because the stupid SVC clobbers
the PKM to
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Binyamin Dissen
Sent: Thursday, July 26, 2007 1:34 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: KEY8 CSA: Pro/JCL and Info/XE
On Thu, 26 Jul 2007 01:31:10 -0400 Craddock, Chris
[EMAIL
Binyamin Dissen wrote:
On Thu, 26 Jul 2007 01:31:10 -0400 Craddock, Chris [EMAIL PROTECTED]
wrote:
:Ed Jaffe asks...
: Out of curiosity, which software products allocate CSA in keys A-
: F?
:I know of one major vendor's storage management product that right up
:until the last time I looked
On Jul 26, 2007, at 2:34 AM, Binyamin Dissen wrote:
Doesn't VTAM OWN Kex x'0a ?
Ed
While I don't condone it, I don't see the exposure (unless the
standard zOS
problem state key mask includes key 10).
--
Binyamin Dissen [EMAIL PROTECTED]
http://www.dissensoftware.com
Director, Dissen
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/26/2007
03:34:06 AM:
On Thu, 26 Jul 2007 01:31:10 -0400 Craddock, Chris
[EMAIL PROTECTED]
wrote:
:Ed Jaffe asks...
: Out of curiosity, which software products allocate CSA in keys A-
: F?
:I know of one major vendor's
On Thu, 26 Jul 2007 01:31:10 -0400 Craddock, Chris [EMAIL PROTECTED]
wrote:
:Ed Jaffe asks...
: Out of curiosity, which software products allocate CSA in keys A-
: F?
:I know of one major vendor's storage management product that right up
:until the last time I looked (more than a year ago) ran
On Tue, 24 Jul 2007 17:26:16 -0400, Bob Rutledge [EMAIL PROTECTED] wrote:
For the first part,
IP VERBX VSMDATA 'GLOBal SUMMary'
followed by
F '/ 8'
might be easier to deal with.
Bob
Perhaps it is a little more readable. I still liked doing a find on
KEY 8 better because using '/ 8' you
Ed Jaffe asks...
Out of curiosity, which software products allocate CSA in keys A-
F?
I know of one major vendor's storage management product that right up
until the last time I looked (more than a year ago) ran in key 10
(X'A0') and used a bunch of CSA in key 10. The developers thought it was
On Fri, 20 Jul 2007 12:03:16 -0400, Jim Mulder wrote:
The default was changed to ALLOWUSERKEYCSA(NO) in z/OS 1.9.
Now I've got some work to do.
Hopefully there's a recommendation and procedure to check for this prior to
making the jump ??? Something non-catastrophic that doesn't require
Dave Kopischke wrote:
On Fri, 20 Jul 2007 12:03:16 -0400, Jim Mulder wrote:
The default was changed to ALLOWUSERKEYCSA(NO) in z/OS 1.9.
Now I've got some work to do.
Hopefully there's a recommendation and procedure to check for this prior to
making the jump ??? Something
On Tue, 24 Jul 2007 12:47:25 -0500, Dave Kopischke
[EMAIL PROTECTED] wrote:
On Fri, 20 Jul 2007 12:03:16 -0400, Jim Mulder wrote:
The default was changed to ALLOWUSERKEYCSA(NO) in z/OS 1.9.
Now I've got some work to do.
Hopefully there's a recommendation and procedure to check for this
On Tue, 24 Jul 2007 13:28:52 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:
You can use do it with a monitor like MXI (very easy using MXI) or use IPCS.
Check the archives.
So I searched the archives... and I couldn't find anything on using IPCS
to do this (cookbook approach). So what would one
For the first part,
IP VERBX VSMDATA 'GLOBal SUMMary'
followed by
F '/ 8'
might be easier to deal with.
Bob
Mark Zelden wrote:
...
So I searched the archives... and I couldn't find anything on using IPCS
to do this (cookbook approach). So what would one do if they didn't have
MXI or
If your intention is to pre-empt ALLOWUSERKEYCSA(NO) problems, then you
should consider the possibility that something may be allocating CSA in a user
key other than 8. Because it is so easy to allocate key 8 CSA accidentally,
that is by far the most likely one you are going to find. However, I
Andy Wood wrote:
If your intention is to pre-empt ALLOWUSERKEYCSA(NO) problems, then you
should consider the possibility that something may be allocating CSA in a user
key other than 8. Because it is so easy to allocate key 8 CSA accidentally,
that is by far the most likely one you are going
On Tue, 24 Jul 2007 13:28:52 -0500, Mark Zelden wrote:
The default was changed to ALLOWUSERKEYCSA(NO) in z/OS 1.9.
Hopefully there's a recommendation and procedure to check for this prior to
making the jump ??? Something non-catastrophic that doesn't require an IPL
to get out of ???
You can
On Tue, 24 Jul 2007 15:55:34 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
Key 10? Do you mean key x'A0' i.e., b'1010', which really is a user
key? Or do you mean key x'10' i.e., b'0001' which isn't a user key
at all. Out of curiosity, which software products allocate CSA in keys A-F?
Dave Kopischke wrote:
On Tue, 24 Jul 2007 13:28:52 -0500, Mark Zelden wrote:
You can use do it with a monitor like MXI (very easy using MXI) or use IPCS.
Check the archives. You can implement and backout via SET DIAG=xx. If
you are already running z/OS 1.8 you can do it now. Even before
Andy Wood wrote:
Decimal 10 or X'0A', which will show up in some places as X'A0'. By my way
of thinking, key X'10' is an invalid key rather than a way of describing
key 1.
Understood. I was confused because storage keys are often (usually?)
presented as two hex digits. For example, in
why can't SERVERPACK be shipped with an initial value of NO?
Stay with NO. I'll be glad to help anyone who can't figure out how to change it
to YES.
Bob Shannon
--
For IBM-MAIN subscribe / signoff / archive access
On Fri, 2007-07-20 at 16:48 -0400, Jim Mulder wrote:
I still wanted to move to a default of NO quickly, as the
slow progress in eliminating user key CSA convinced me that
the sledgehammer approach was required. Hopefully, having
to explain to security auditors why use of product X requires
*EXCELLENT* attitude. Should be more of it - let's hope you have more wins
Jim.
I agree.
But, there's nothing to stop us, as customers, from changing the defaults.
YES, I know we may have problems.
But, we will also have opportunities.
-
Too busy driving to stop for gas!
Based upon my own experience attempting to negotiate with vendors over
whether it is good or bad that they use Key 8 CSA in their code, and if
it was bad, whether they would actually fix their code, this sledgehammer
is ABSOLUTELY REQUIRED.
Thank you, Jim. Once again, you've made another huge
On Thu, 19 Jul 2007 23:04:50 -0500, Brian Peterson
[EMAIL PROTECTED] wrote:
I think it will help us all significantly when IBM makes ALLOWUSERKEYCSA(NO)
the default, if only to encourage our vendors to redouble their efforts to
fix this bad bad programming practice. I sure hope this default
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/20/2007
12:04:50 AM:
I think it will help us all significantly when IBM makes
ALLOWUSERKEYCSA(NO)
the default, if only to encourage our vendors to redouble their efforts
to
fix this bad bad programming practice. I sure hope
On Thu, 19 Jul 2007 23:04:50 -0500, Brian Peterson
[EMAIL PROTECTED] wrote:
I think it will help us all significantly when IBM makes ALLOWUSERKEYCSA(NO)
the default, if only to encourage our vendors to redouble their efforts to
fix this bad bad programming practice. I sure hope this default
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/20/2007
02:50:03 PM:
On Fri, 20 Jul 2007 12:03:16 -0400, Jim Mulder [EMAIL PROTECTED]
wrote:
The default was changed to ALLOWUSERKEYCSA(NO) in z/OS 1.9.
Wow! I am surprised that the default is being changed so soon
-snip--
I originally wanted to start right out with a default of NO
in 1.8, but Bob Rogers talked me out of it, so I instead settled
for stern language in the description of the parameter in
Initialization and Tuning Reference. Even there, the
Our tech LPAR has been running VSM ALLOWUSERKEYCSA(NO) since last
Saturday. In the dark days (like six months ago), I never thought I'd see
the day when we'd have even one LPAR IPL successfully with this option
set.
It took us a measly hour after setting allowuserkeycsa to no 'on the fly' in a
Your story sounds very familiar. I had an almost identical experience (more
than once), prior to this most recent go-round with our third party software
updates. Earlier, I had flipped the switch, and almost immediately was
swamped with dumps. Had to IPL right away, and I slunk back into my
We recently reported an issue with ASG for their Pro/JCL and Info/XE products
regarding their use of Key 8 CSA.
As a result of our problem report, I believe the vendor is looking into what it
would take for them to fix this.
If you are interested in the resolution of this issue for these
43 matches
Mail list logo
