Erik. >> In the current implementation of the SVC that would work fine, since it is >> all doing the MVC's in key 0, but if I change that to MVCSK and MVCDK >> instructions I might get the 0C4 abend.
Whilst I applaud your desire to implement MVCDK/SK, I think the word "fine" is doing some heavy lifting in the above. 😊 Using MVC in key0 to read/write non-Key0 memory is obviously a risk to system integrity. A couple of other minor observations : (o) Is this SVC part of new development? If so, perhaps consider using PC-cp instead - I am some sample code that could help in this endevour if you are interested. You will require a resource owning ASID to house the PC routine, but it can be limited function in design. (o) I am not a CICS person, but I thought that normal transactions are discouraged from issuing SVCs (happy to be corrected if not so). Rob Scott Rocket Software -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Erik Janssen Sent: Thursday, May 2, 2024 6:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Testdriving svc in key 9 (was: finding callers key in svc) EXTERNAL EMAIL Hello Peter, My apologies for not changing the subject. I managed to show now that the code in the svc is correct, it indicated that the caller was in key 9. I've solved the testdriver issue now by marking that routine as REFReshable and put it in SYS1.LINKLIB. I saw an old thread about this that gave this option, the module now gets loaded into subpool 252, which is not fetch protected. I'm testing this on a personal ZPDT machine, so in this case it is a fair way to get the job done easily, without having to figure out how to do ATTACHX programming. I just would like to simulate the situation where a cics transaction running in key 9 would access a storage area it provided to the svc with key 8. In the current implementation of the SVC that would work fine, since it is all doing the MVC's in key 0, but if I change that to MVCSK and MVCDK instructions I might get the 0C4 abend. That was also where my confusion (bias) was, I was thinking (expecting) the 0C4 was triggered in the SVC, while actually it was my test program that abended on not being able to get the next instruction from the fetch protected subpool 251 my program was loaded in. Next stop is to see if I can get an ESTAE in the routine to give a message about this situation and after that perhaps make it more intelligent to allow a switch to key 8 in this situation. I've not done a lot of assembler programming over the years, so it always takes me some time to get used to it again, and these routines are of course not the easiest to handle. But I like taking on such a challenge, because the amount of stuff you learn is always very satisfying. Kind regards, Erik Janssen. On Thu, 2 May 2024 14:07:25 +0000, Peter Relson <rel...@us.ibm.com> wrote: >Please try to have different threads with suitable subjects for each. The 0C4 >is unrelated to the subject. > >Since the code shown for the SVC routine is correct for type 2/3/4 yet you say >that you do not find the right data, then prove it: >Show the definition of the SVC, show extracts from IPCS looking at the dump >storage. > >If you are blowing up at the instruction right after the SPKA to a different >key, regardless of what that instruction was, then your program is in key 8 >fetch-protected storage so unless your new key is 0, you will not be able to >access the instruction. Requirements for placing a reentrant program into key >0 non-fetch-protected storage depend on authorization and various system-wide >options, along with the possibility of doing an ATTACHX with the KEY=NINE >parameter (which will place into key 0 storage without relying on >authorization). > >Peter Relson >z/OS Core Technology Design > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ■77 Fourth Avenue, Waltham MA 02451 ■Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
