Interesting question that I haven't really thought too much about because when 
I have to do something special, generally it is key 0.

With that said, in a previous life I wrote utilities for DB2.  For those we got 
into key 7 as the default because that is what DB2 runs in.  There are ways to 
attach a task in a key other than 8, but that is another topic.  In the 
processing of the utilities we still had to get to key 0 and get back, so it 
was no different, except that the base key was different.

In the Diagnosis Manual, in the Storage section, there is a brief list of the 
storage keys and what system functions use them.

Basically, use the key of the function that you are working with.  You use 
non-key 8 storage for data structures that you don't want user code to change, 
and sometimes even look at.  There are only limited sub-pools that are fetch 
protected, meaning that you have to be in the key of the storage to look at it. 
 Most sub-pools are not fetch protected, meaning anyone can look at the 
storage, but they can't change it unless they are executing in the matching key.

I think most of CICS runs in key 8, but most of IMS runs in key 7.  One of the 
nice things about key 0 is you don't have to worry what key the storage was 
allocated as because key 0 gives you the keys to the city.  You only have to be 
careful when you are allocating storage that someone else is going to try and 
modify.

There are so many 'it depends' that go with this area of discussion, anything 
more than that what I said needs a definition of what you are trying to do.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: [email protected]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of [email protected]
Sent: Saturday, July 11, 2015 4:09 PM
To: [email protected]
Subject: SYSTEM KEY Programming Was: IVSK and SPKA

As Tony Harminc stated "Key controlled protection is there for a reason."
.
.
Being a CICS & MQ Systems Programmer I rarely get the oppurtunity to write code 
in a system key. For those times that I needed to, It was easier to simply 
switch to KEY 0, execute the few instructions needed and switch back. Granted 
this may not be proper coding technique.
.
Tonys comment got me thinking, and after some little research I was unable to 
find any publications or documents or even SHARE presentaions, That discuss 
coding programs in a SYSTEM key Other than Key 0.
.
.
Is anyone Aware of a presentaion or documntaion that discuss this ?
Coding programs in a System Key 1-7.
What are the considerstions involved ?
What are the recommended techniques ?
.
.
Paul D'Angelo






---------- Original Message ----------
From: Tony Harminc <[email protected]>
To: [email protected]
Subject: Re: IVSK and SPKA
Date: Wed, 8 Jul 2015 18:38:51 -0400

On 8 July 2015 at 17:09, michelbutz <[email protected]> wrote:

> I know that a S0C4 reason 4 occurs anytime the storage key doesn't
> match the PSW key bits 8 - 11

Uh, no.

>  Would IVSK. R1,R2 and SPKA 0(R11) prevent this

It's highly unlikely. Perhaps if you set R11... But I can hardly overemphasise 
how bad an approach all this is. Key controlled protection is there for a 
reason.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO IBM-MAIN

________________________________



ATTENTION: -----

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to