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