Rob, Forgive me, I strongly agree and advocate what you've stated but ....
Strobe runs (for the most part) in key 2. Further, key 2 used to be used by VSCR (in the good ol' days) but, IIRC, IMS is (or has) ramping up with key 2 usage. Worthless bit of trivia perhaps but .. just thought I'd put it out there. Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-327-7333 (res / wrk) [email protected] (pvt email) -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Scott Sent: Saturday, July 11, 2015 4:55 PM To: [email protected] Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA I spend quite a lot of time writing code for software products that have to do things beyond the scope of normal problem state. The problem with going to key0 is pretty much always not what you intended to do - but what happens when your code goes wrong (and everyone's code goes wrong) or when your caller passes you something bad by error or by design. This is why I avoid key0 as much as I possibly can - and the way to do that if you are writing system software is take advantage of a SCHEDxx PARMLIB setting and declare your server jobstep program as running in *another* system key. Of the remaining seven keys, two of them (key2 and key4) seem to not be used by any well-known current software products. Once your server jobstep program is running non-key0 system key, most of the authorized services can be called without having to switch to key0 - and this can only be good news for your code and your customers systems. Client code, of course, should always run in problem state and use a well-defined and secure method to communicate to your server (for example a space-switch PC). Anyone writing authorized code should read and understand the system integrity issues and there are some very good presentations given by Karl Schmitz out there on the internet. I think that what is lacking in the Authorized Programming manuals is a really well written example of how to implement a client server application. While the descriptions of the services and their parameters are well documented, a decent working example would really help the community understand the issues and prevent the proliferation of public domain code with (how shall I put it?) non-optimal designs. Rob Scott Principal Software Engineer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Blaicher, Christopher Y. Sent: Saturday, July 11, 2015 5:02 PM To: [email protected] Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA 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 ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – [email protected] Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6081 / Virus Database: 4392/10208 - Release Date: 07/11/15 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6081 / Virus Database: 4392/10208 - Release Date: 07/11/15 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
