Re: Testdriving svc in key 9 (was: finding callers key in svc)
If he's using the binder then requesting REFR will also set RENT, which will get him SP252, and hence key 0. REFRPROT is an unrelated mechanism. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Friday, May 3, 2024 7:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Testdriving svc in key 9 (was: finding callers key in svc) I managed to show now that the code in the svc is correct, it indicated that the caller was in key 9. Perhaps share, to help others not make the system mistake, what had led you to believe that the code was not doing what you wanted. I've solved the testdriver issue now by marking that routine as REFReshable and put it in SYS1.LINKLIB. This behavior, when marking the module as refreshable, applies only when the REFRPROT option of PROGxx is active. That applies system-wide. As long as that is OK, and you have control of setting REFRPROT, have at it. 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
Re: Testdriving svc in key 9 (was: finding callers key in svc)
Erik, The source is in github : https://github.com/rscott-rocket/mxe There was a matching Share presentation from Dallas 2020 that goes with it : Session 26556 z/OS Cross-Memory Server Code Walkthrough The main purpose was to show how to write a PC-ss and is probably way more than you need, but it will show the basics of what is required. I hope this helps - (warning I use IBM structured programming macros and some folks don’t like 'em). Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Erik Janssen Sent: Friday, May 3, 2024 4:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Testdriving svc in key 9 (was: finding callers key in svc) EXTERNAL EMAIL Hello Rob, It is a user SVC that has been on our system for a long time and it is used by a number of applications. So unfortunately our best (short time) option is to secure the SVC. I will contact you of list if that is ok about the sample code for a pc routine. Kind regards, Erik. On Fri, 3 May 2024 12:12:03 +, Rob Scott wrote: >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). -- 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
Re: Testdriving svc in key 9 (was: finding callers key in svc) -- History stuff
Erik: This was being done in CICS (v3?) long before CICS/TS. This was back when MVS/XA was still in support just before MVS/SP4 (as I recall) had come out. . IBM PROLOG for 370 (based on PROLOG that ran under VM) could run under CICS but I think it was found that it needed to run in a subsystem so that it did not lockup CICS while doing all the processing needed to get an answer. And so this is what the Cross Mem Charge back SMF record was created for -- reporting CPU use and the like for handling a query in the Prolog subsystem. So IBM PROLOG for 370 needed to use storage keys beyond Key8 for stack/heap control. We had set up to use Key9 for our SVC as I recall, when we were contacted and asked if we could change (this was by CICS dev). So we did. Alas, it appears that IBM Prolog for 370 went into the dust bin about 1996. I know that a large user of it was a manufacturer in Europe. They had been using the VM version and I think they wanted an MVS version. Steve Thompson On 5/3/2024 10:41 AM, Farley, Peter wrote: I am not a CICS person, but I thought that normal transactions are discouraged from issuing SVCs (happy to be corrected if not so). True for original-flavor CICS transactions that run on the QR (quasi-reentrant) TCB. Newer code designed to run on the “Open” TCB pool do not have that restriction, so long as they only use CICS services that do not require the QR TCB (and there are fewer and fewer of those as Hursley gets around to updating them). Peter From: IBM Mainframe Discussion List On Behalf Of Rob Scott Sent: Friday, May 3, 2024 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Testdriving svc in key 9 (was: finding callers key in svc) 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 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) 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 +, Peter Relson 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 afte
Re: Testdriving svc in key 9 (was: finding callers key in svc)
I loaded some registers with values and then used a DC H'0' instruction to force a 0C1 abend and when I looked at the contents of the registers I assumed it abended inside the SVC, while actually it abended with the 0C4 in the calling routine. One of the registers had a value of 0x0080 which led me to believe that this was the key I found in the request block, while it was actually the result from a IPK instruction I had inserted into my calling program before doing the SPKA x'90'(0) instruction. Sometimes walking the dog for a moment gives me the clarity to understand what has happend :-) Kind regards, Erik. On Fri, 3 May 2024 11:59:23 +, Peter Relson wrote: > >I managed to show now that the code in the svc is correct, it indicated that >the caller was in key 9. > >Perhaps share, to help others not make the system mistake, what had led you to >believe that the code was not doing what you wanted. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Testdriving svc in key 9 (was: finding callers key in svc)
Hello Rob, It is a user SVC that has been on our system for a long time and it is used by a number of applications. So unfortunately our best (short time) option is to secure the SVC. I will contact you of list if that is ok about the sample code for a pc routine. Kind regards, Erik. On Fri, 3 May 2024 12:12:03 +, Rob Scott wrote: >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). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Testdriving svc in key 9 (was: finding callers key in svc)
>> I am not a CICS person, but I thought that normal transactions are >> discouraged from issuing SVCs (happy to be corrected if not so). True for original-flavor CICS transactions that run on the QR (quasi-reentrant) TCB. Newer code designed to run on the “Open” TCB pool do not have that restriction, so long as they only use CICS services that do not require the QR TCB (and there are fewer and fewer of those as Hursley gets around to updating them). Peter From: IBM Mainframe Discussion List On Behalf Of Rob Scott Sent: Friday, May 3, 2024 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Testdriving svc in key 9 (was: finding callers key in svc) 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 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) 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 +, Peter Relson 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received th
Re: Testdriving svc in key 9 (was: finding callers key in svc)
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 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 +, Peter Relson 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 prohibite
Re: Testdriving svc in key 9 (was: finding callers key in svc)
I managed to show now that the code in the svc is correct, it indicated that the caller was in key 9. Perhaps share, to help others not make the system mistake, what had led you to believe that the code was not doing what you wanted. I've solved the testdriver issue now by marking that routine as REFReshable and put it in SYS1.LINKLIB. This behavior, when marking the module as refreshable, applies only when the REFRPROT option of PROGxx is active. That applies system-wide. As long as that is OK, and you have control of setting REFRPROT, have at it. 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
Testdriving svc in key 9 (was: finding callers key in svc)
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 +, Peter Relson 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
Re: finding callers key in svc
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
Re: finding callers key in svc
Use the ATTACHX macro with KEY=NINE to attach a key 9 subtask. That's what CICS does. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY >Is there a way to force the program to go to subpool 244 for example, that is >not fetch protected? >I'm trying to create an easy test program that could simulate the situation >where the svc is called from a cics task running in key 9 trying to access key >8 storage. That case would fail if I start using MVCSK en MVCDK, and perhaps I >can add an ESTAE to do recovery in that scenario. First thing I >would like to try is to create an ESTAE that would just WTO the 0C4 situation, >for example 'task running in key xx tried to access storage in key yy' . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
I can see in the dump that my program is in subpool 251 and this is fetch protected, so it explains the abend I guess. SUBPOOL 251 KEY 08 OWNED BY TCB 008D2AA0 ADDRESS 2000 LENGTH 2000 FREE AREA 2000 LENGTH 00A8 Is there a way to force the program to go to subpool 244 for example, that is not fetch protected? I'm trying to create an easy test program that could simulate the situation where the svc is called from a cics task running in key 9 trying to access key 8 storage. That case would fail if I start using MVCSK en MVCDK, and perhaps I can add an ESTAE to do recovery in that scenario. First thing I would like to try is to create an ESTAE that would just WTO the 0C4 situation, for example 'task running in key xx tried to access storage in key yy' . The dump shows: IEA995I SYMPTOM DUMP OUTPUT 223 SYSTEM COMPLETION CODE=0C4 REASON CODE=0004 TIME=04.50.16 SEQ=00035 CPU= ASID=0029 PSW AT TIME OF ERROR 079D A0B0 ILC 2 INTC 04 ACTIVE MODULE ADDRESS=_20A8 OFFSET=0008 NAME=SVCNORM DATA AT PSW 20AA - B20A0090 1BFF 07FEC3C9 GR 0: 0064 1: 6FF8 2: 0040 3: 008DBD64 4: 008DBD40 5: 008FB058 6: 008C9FC8 7: 00FB5000 8: 008FD608 9: 008D2CB0 A: 01DAFB00 B: 0001 C: A0A8 D: 6F60 E: 80FD7B30 F: A0A8 Kind regards, Erik. > >The issue is in my test program that does the switch to key 9. >The SPKA x'90'(0) instruction properly gets translated to a B20A 0090 and from >the abend I can see in the psw that it does have key 9. >The abend I get is a 0C4 abend, which surprised me, but I'm guessing it just >cannot read the next instruction anymore since that is in key 8 storage? Or is >there something else I'm missing. >It I'm correct, how does one switch to another key and keep executing code? > >The code is: > >SVCNORM CSECT >SVCNORM AMODE 31 >SVCNORM RMODE ANY > LR R12,R15 > USING SVCNORM,R12 > SPKA x'90'(0) > DC H'0' > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
I took your advises to heart, started using RBLINKB instead of RBLINK. I wasn't aware I could use a label on a using and use that for reference. We have an existing SVC that reads from a given memory location and I want to secure it to use MVCDK and MVCSK, thus my need to find the caller's key. It is used by quite some application programs, so removing it is not an option on the short term unfortunately. The issue is in my test program that does the switch to key 9. The SPKA x'90'(0) instruction properly gets translated to a B20A 0090 and from the abend I can see in the psw that it does have key 9. The abend I get is a 0C4 abend, which surprised me, but I'm guessing it just cannot read the next instruction anymore since that is in key 8 storage? Or is there something else I'm missing. It I'm correct, how does one switch to another key and keep executing code? The code is: SVCNORM CSECT SVCNORM AMODE 31 SVCNORM RMODE ANY LR R12,R15 USING SVCNORM,R12 SPKA x'90'(0) DC H'0' Thank you all for your responses. Kind regards, Erik. On Wed, 1 May 2024 13:52:15 +, Seymour J Metz wrote: >Even on a S/360 that code is inefficient, but still valid. > > USING RBBASIC,R5 POINT TO REQUEST BLOCK > LR7,RBLINK LOAD CALLER RB IN REG 7 > DROP R5 DROP SVC RB MAPPING > USING RBBASIC,R7 AND NOW MAP CALLER RB > SR R1,R1 > ICR1,RBOPSWB2Key and flags > NR1,=XL4'F0' Isolate PSW KEY >*STR1,KEY STORE CALLER KEY > DCH'0'FORCE ABEND > >As a matter of style I would probably have written > > USING RBBASIC,R5 SVRB address set on entry > LR7,RBLINK CALLER's RB >CALLER USING RBBASIC,R7 > SR R1,R1 > ICR1,CALLER.RBOPSWB2Key and flags > NR1,=XL4'F0' Isolate PSW KEY >*STR1,KEY STORE CALLER KEY > DCH'0'FORCE ABEND > >I would take a closer look at the SPKA code. > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >From: IBM Mainframe Discussion List on behalf of >Peter Relson >Sent: Wednesday, May 1, 2024 8:55 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: finding callers key in svc > > > USING RBBASIC,R5 POINT TO REQUEST BLOCK > LR7,RBLINK LOAD CALLER RB IN REG 7 > DROP R5 DROP SVC RB MAPPING > USING RBBASIC,R7 AND NOW MAP CALLER RB > LR1,RBOPSW GET CALLER PSW AND PUT IN REG 1 > NR1,=X'00F0'ONLY PSW KEY > SRL R1,16 SHIFT TO 00K0 >*STR1,KEY STORE CALLER KEY > DCH'0'FORCE ABEND > > >If your SVC is a type 2/3/4 SVC, the code works. >I can't speak to how you are debugging or what you are seeing in a dump >because you have not shared any of that information. > >You could even try this without needing your own SVC by having your code in a >LINK target, at least to verify that you are seeing the PSW of the SVC issuer >(SVC 6 in the simplest LINK case). You wouldn't have R5 set on input but can >easily pick that up via (IHAPSA) PSATOLD -> (IKJTCB) TCBRBP. > >It is in general poor form to use RBLINK rather than RBLINKB unless AMODE 24, >but in your case you would know that the caller's RB is not waiting so the >high byte will have a 0 wait count so can get away with using the 4-byte name. > >These days, the L/N/SRL has many better alternatives, such as >LLC (of the 2nd byte of RBOPSW) / NILL (to clear the low 4 bits if for some >reason you need to do so). > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
No; the dispatcher gets the PSW from the top RB and the registers from the TCB. NB: where are the 12 new FP registers and the non-overlapping vector registers. The PSW at the time of entry is in the caller's RB and the registers at the time of entry are in the new RB. Thus it ever was. Out of curiosity, what are the fields for the GR top halves? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Austin Sent: Wednesday, May 1, 2024 4:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding callers key in svc I believe the PSW will be in the PRB rather than the SVRB; the registers will be in the SVRB. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Erik Janssen Sent: Tuesday, April 30, 2024 6:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding callers key in svc I must be doing something wrong, because if I do that it indicates key 0. I was expecting key 9 somewhere... On Tue, 30 Apr 2024 08:50:13 -0500, Wayne Driscoll wrote: >If you are in a Type 2, 3 or 4 SVC, the PSW at the time of the SVC >instruction is in the SVRB whose address is in R5 upon entry, that is >the RBOPSW you would want to interrogate. Your code is looking at the >PSW at the time the callers RB was created, mostly via a LINK or ATTACH >SVC, since it was a problem program. >Wayne Driscoll >Note: all opinions are strictly my own. > >On Tue, Apr 30, 2024 at 4:02 AM Erik Janssen < >062c999269e8-dmarc-requ...@listserv.ua.edu> wrote: > >> >> > >> >As to the initial question, as pointed out, it depends on the type >> >of the >> SVC. The SVC owner knows what type it is (because they defined it) >> and can look in the right place for that type of SVC, just as they >> look in the right place for the caller's regs (for which the answer >> is different than the psw/key, but similarly depends on the type of the >> SVC. >> > >> >> >> I had the idea that this code in the SVC would give me the key the >> SVC caller was executing in: >> >> USING RBBASIC,R5 POINT TO REQUEST BLOCK >> L R7,RBLINK LOAD CALLER RB IN REG 7 >> DROP R5 DROP SVC RB MAPPING >> USING RBBASIC,R7 AND NOW MAP CALLER RB >> L R1,RBOPSW GET CALLER PSW AND PUT IN REG 1 >> N R1,=X'00F0' ONLY PSW KEY >> SRL R1,16 SHIFT TO 00K0 >> STR1,KEY STORE CALLER KEY >> DCH'0'FORCE ABEND >> >> However, when I call this SVC from an problem program the switches to >> key >> 9 before the call: >> >> SPKA X'90'(0) SWITCH TO KEY 9 >> SVC 255 >> >> I see that R1 has a value of x'0080' (key 8) at the time of the >> abend, where I was expecting x'0090'. >> Is see that it is possible that there are more request blocks. I'm I >> not looking at the right one, and if so, how do you know if you >> reached the top RB, or is my approach really wrong? >> >> Kind regards, >> >> Erik Janssen. >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >> > > >-- >Wayne Driscoll >Software Engineer | Mainframe Software Division Broadcom Software > >*Office: *630-300-1931* Mobile:* 630-247-1632 >wayne.drisc...@broadcom.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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
Re: finding callers key in svc
Even on a S/360 that code is inefficient, but still valid. USING RBBASIC,R5 POINT TO REQUEST BLOCK LR7,RBLINK LOAD CALLER RB IN REG 7 DROP R5 DROP SVC RB MAPPING USING RBBASIC,R7 AND NOW MAP CALLER RB SR R1,R1 ICR1,RBOPSWB2Key and flags NR1,=XL4'F0' Isolate PSW KEY *STR1,KEY STORE CALLER KEY DCH'0'FORCE ABEND As a matter of style I would probably have written USING RBBASIC,R5 SVRB address set on entry LR7,RBLINK CALLER's RB CALLER USING RBBASIC,R7 SR R1,R1 ICR1,CALLER.RBOPSWB2Key and flags NR1,=XL4'F0' Isolate PSW KEY *STR1,KEY STORE CALLER KEY DCH'0'FORCE ABEND I would take a closer look at the SPKA code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Wednesday, May 1, 2024 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding callers key in svc USING RBBASIC,R5 POINT TO REQUEST BLOCK LR7,RBLINK LOAD CALLER RB IN REG 7 DROP R5 DROP SVC RB MAPPING USING RBBASIC,R7 AND NOW MAP CALLER RB LR1,RBOPSW GET CALLER PSW AND PUT IN REG 1 NR1,=X'00F0'ONLY PSW KEY SRL R1,16 SHIFT TO 00K0 *STR1,KEY STORE CALLER KEY DCH'0'FORCE ABEND If your SVC is a type 2/3/4 SVC, the code works. I can't speak to how you are debugging or what you are seeing in a dump because you have not shared any of that information. You could even try this without needing your own SVC by having your code in a LINK target, at least to verify that you are seeing the PSW of the SVC issuer (SVC 6 in the simplest LINK case). You wouldn't have R5 set on input but can easily pick that up via (IHAPSA) PSATOLD -> (IKJTCB) TCBRBP. It is in general poor form to use RBLINK rather than RBLINKB unless AMODE 24, but in your case you would know that the caller's RB is not waiting so the high byte will have a 0 wait count so can get away with using the 4-byte name. These days, the L/N/SRL has many better alternatives, such as LLC (of the 2nd byte of RBOPSW) / NILL (to clear the low 4 bits if for some reason you need to do so). 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
Re: finding callers key in svc
USING RBBASIC,R5 POINT TO REQUEST BLOCK LR7,RBLINK LOAD CALLER RB IN REG 7 DROP R5 DROP SVC RB MAPPING USING RBBASIC,R7 AND NOW MAP CALLER RB LR1,RBOPSW GET CALLER PSW AND PUT IN REG 1 NR1,=X'00F0'ONLY PSW KEY SRL R1,16 SHIFT TO 00K0 *STR1,KEY STORE CALLER KEY DCH'0'FORCE ABEND If your SVC is a type 2/3/4 SVC, the code works. I can't speak to how you are debugging or what you are seeing in a dump because you have not shared any of that information. You could even try this without needing your own SVC by having your code in a LINK target, at least to verify that you are seeing the PSW of the SVC issuer (SVC 6 in the simplest LINK case). You wouldn't have R5 set on input but can easily pick that up via (IHAPSA) PSATOLD -> (IKJTCB) TCBRBP. It is in general poor form to use RBLINK rather than RBLINKB unless AMODE 24, but in your case you would know that the caller's RB is not waiting so the high byte will have a 0 wait count so can get away with using the 4-byte name. These days, the L/N/SRL has many better alternatives, such as LLC (of the 2nd byte of RBOPSW) / NILL (to clear the low 4 bits if for some reason you need to do so). 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
Re: finding callers key in svc
I believe the PSW will be in the PRB rather than the SVRB; the registers will be in the SVRB. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Erik Janssen Sent: Tuesday, April 30, 2024 6:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding callers key in svc I must be doing something wrong, because if I do that it indicates key 0. I was expecting key 9 somewhere... On Tue, 30 Apr 2024 08:50:13 -0500, Wayne Driscoll wrote: >If you are in a Type 2, 3 or 4 SVC, the PSW at the time of the SVC >instruction is in the SVRB whose address is in R5 upon entry, that is >the RBOPSW you would want to interrogate. Your code is looking at the >PSW at the time the callers RB was created, mostly via a LINK or ATTACH >SVC, since it was a problem program. >Wayne Driscoll >Note: all opinions are strictly my own. > >On Tue, Apr 30, 2024 at 4:02 AM Erik Janssen < >062c999269e8-dmarc-requ...@listserv.ua.edu> wrote: > >> >> > >> >As to the initial question, as pointed out, it depends on the type >> >of the >> SVC. The SVC owner knows what type it is (because they defined it) >> and can look in the right place for that type of SVC, just as they >> look in the right place for the caller's regs (for which the answer >> is different than the psw/key, but similarly depends on the type of the >> SVC. >> > >> >> >> I had the idea that this code in the SVC would give me the key the >> SVC caller was executing in: >> >> USING RBBASIC,R5 POINT TO REQUEST BLOCK >> L R7,RBLINK LOAD CALLER RB IN REG 7 >> DROP R5 DROP SVC RB MAPPING >> USING RBBASIC,R7 AND NOW MAP CALLER RB >> L R1,RBOPSW GET CALLER PSW AND PUT IN REG 1 >> N R1,=X'00F0' ONLY PSW KEY >> SRL R1,16 SHIFT TO 00K0 >> STR1,KEY STORE CALLER KEY >> DCH'0'FORCE ABEND >> >> However, when I call this SVC from an problem program the switches to >> key >> 9 before the call: >> >> SPKA X'90'(0) SWITCH TO KEY 9 >> SVC 255 >> >> I see that R1 has a value of x'0080' (key 8) at the time of the >> abend, where I was expecting x'0090'. >> Is see that it is possible that there are more request blocks. I'm I >> not looking at the right one, and if so, how do you know if you >> reached the top RB, or is my approach really wrong? >> >> Kind regards, >> >> Erik Janssen. >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >> > > >-- >Wayne Driscoll >Software Engineer | Mainframe Software Division Broadcom Software > >*Office: *630-300-1931* Mobile:* 630-247-1632 >wayne.drisc...@broadcom.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
I must be doing something wrong, because if I do that it indicates key 0. I was expecting key 9 somewhere... On Tue, 30 Apr 2024 08:50:13 -0500, Wayne Driscoll wrote: >If you are in a Type 2, 3 or 4 SVC, the PSW at the time of the SVC >instruction is in the SVRB whose address is in R5 upon entry, that is the >RBOPSW you would want to interrogate. Your code is looking at the PSW at >the time the callers RB was created, mostly via a LINK or ATTACH SVC, since >it was a problem program. >Wayne Driscoll >Note: all opinions are strictly my own. > >On Tue, Apr 30, 2024 at 4:02 AM Erik Janssen < >062c999269e8-dmarc-requ...@listserv.ua.edu> wrote: > >> >> > >> >As to the initial question, as pointed out, it depends on the type of the >> SVC. The SVC owner knows what type it is (because they defined it) and can >> look in the right place for that type of SVC, just as they look in the >> right place for the caller's regs (for which the answer is different than >> the psw/key, but similarly depends on the type of the SVC. >> > >> >> >> I had the idea that this code in the SVC would give me the key the SVC >> caller was executing in: >> >> USING RBBASIC,R5 POINT TO REQUEST BLOCK >> L R7,RBLINK LOAD CALLER RB IN REG 7 >> DROP R5 DROP SVC RB MAPPING >> USING RBBASIC,R7 AND NOW MAP CALLER RB >> L R1,RBOPSW GET CALLER PSW AND PUT IN REG 1 >> N R1,=X'00F0' ONLY PSW KEY >> SRL R1,16 SHIFT TO 00K0 >> STR1,KEY STORE CALLER KEY >> DCH'0'FORCE ABEND >> >> However, when I call this SVC from an problem program the switches to key >> 9 before the call: >> >> SPKA X'90'(0) SWITCH TO KEY 9 >> SVC 255 >> >> I see that R1 has a value of x'0080' (key 8) at the time of the abend, >> where I was expecting x'0090'. >> Is see that it is possible that there are more request blocks. I'm I not >> looking at the right one, and if so, how do you know if you reached the top >> RB, or is my approach really wrong? >> >> Kind regards, >> >> Erik Janssen. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > >-- >Wayne Driscoll >Software Engineer | Mainframe Software Division >Broadcom Software > >*Office: *630-300-1931* Mobile:* 630-247-1632 >wayne.drisc...@broadcom.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
If you are in a Type 2, 3 or 4 SVC, the PSW at the time of the SVC instruction is in the SVRB whose address is in R5 upon entry, that is the RBOPSW you would want to interrogate. Your code is looking at the PSW at the time the callers RB was created, mostly via a LINK or ATTACH SVC, since it was a problem program. Wayne Driscoll Note: all opinions are strictly my own. On Tue, Apr 30, 2024 at 4:02 AM Erik Janssen < 062c999269e8-dmarc-requ...@listserv.ua.edu> wrote: > > > > >As to the initial question, as pointed out, it depends on the type of the > SVC. The SVC owner knows what type it is (because they defined it) and can > look in the right place for that type of SVC, just as they look in the > right place for the caller's regs (for which the answer is different than > the psw/key, but similarly depends on the type of the SVC. > > > > > I had the idea that this code in the SVC would give me the key the SVC > caller was executing in: > > USING RBBASIC,R5 POINT TO REQUEST BLOCK > L R7,RBLINK LOAD CALLER RB IN REG 7 > DROP R5 DROP SVC RB MAPPING > USING RBBASIC,R7 AND NOW MAP CALLER RB > L R1,RBOPSW GET CALLER PSW AND PUT IN REG 1 > N R1,=X'00F0' ONLY PSW KEY > SRL R1,16 SHIFT TO 00K0 > STR1,KEY STORE CALLER KEY > DCH'0'FORCE ABEND > > However, when I call this SVC from an problem program the switches to key > 9 before the call: > > SPKA X'90'(0) SWITCH TO KEY 9 > SVC 255 > > I see that R1 has a value of x'0080' (key 8) at the time of the abend, > where I was expecting x'0090'. > Is see that it is possible that there are more request blocks. I'm I not > looking at the right one, and if so, how do you know if you reached the top > RB, or is my approach really wrong? > > Kind regards, > > Erik Janssen. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne Driscoll Software Engineer | Mainframe Software Division Broadcom Software *Office: *630-300-1931* Mobile:* 630-247-1632 wayne.drisc...@broadcom.com -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
> >As to the initial question, as pointed out, it depends on the type of the SVC. >The SVC owner knows what type it is (because they defined it) and can look in >the right place for that type of SVC, just as they look in the right place for >the caller's regs (for which the answer is different than the psw/key, but >similarly depends on the type of the SVC. > I had the idea that this code in the SVC would give me the key the SVC caller was executing in: USING RBBASIC,R5 POINT TO REQUEST BLOCK L R7,RBLINK LOAD CALLER RB IN REG 7 DROP R5 DROP SVC RB MAPPING USING RBBASIC,R7 AND NOW MAP CALLER RB L R1,RBOPSW GET CALLER PSW AND PUT IN REG 1 N R1,=X'00F0' ONLY PSW KEY SRL R1,16 SHIFT TO 00K0 STR1,KEY STORE CALLER KEY DCH'0'FORCE ABEND However, when I call this SVC from an problem program the switches to key 9 before the call: SPKA X'90'(0) SWITCH TO KEY 9 SVC 255 I see that R1 has a value of x'0080' (key 8) at the time of the abend, where I was expecting x'0090'. Is see that it is possible that there are more request blocks. I'm I not looking at the right one, and if so, how do you know if you reached the top RB, or is my approach really wrong? Kind regards, Erik Janssen. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
is there any logic behind why MVC uses the actual byte count and MVCSK uses the 'number of bytes to the right'? As Wayne D pointed out, for MVC the user codes "n" and the instruction text uses "n-1". This is almost certainly for effectiveness. Having 8 bits of instruction text lets you cover a range of 1-256 bytes instead of 0-255 bytes. You would have been very unhappy if you could only move 255 bytes with a single MVC if moving a long string (particularly in the days before MVCL). FWIW, this is why if you EXecute an MVC, the value you put into the register is "n-1". For MVCSK/MVCDK, the user does not code a length, and the length is not in the instruction text. The length is in a register. So the user puts the value there by a separate instruction. So both actually use "number of bytes to the right" (or, as I think of it, "length minus one"). You could ask "for MVCSK/MVCDK, since the length is in a register, why did you go with n-1 in the register instead of n?". I don't recall exactly but it was likely for either (or both) of consistency with MVC (such as the execute case) or for cost savings (perhaps being able to share part of the implementation). As to the initial question, as pointed out, it depends on the type of the SVC. The SVC owner knows what type it is (because they defined it) and can look in the right place for that type of SVC, just as they look in the right place for the caller's regs (for which the answer is different than the psw/key, but similarly depends on the type of the SVC. 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
Re: finding callers key in svc
MODEST. An SVC that calls another SVC. ... Multithreading would normally involve multiple TCBs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 26, 2024 6:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding callers key in svc On Fri, 26 Apr 2024 21:36:36 +, Seymour J Metz wrote: >NO! Use RBOPSW; the caller might not be in the PSW key. > >-- Could you explain in what situation that happens? Is that when the task is multihreaded and another thread has changed the key in the psw in between the call to the svc and the time of looking at the psw? Thank you all for the quick reponses by the way :-) -- 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
Re: finding callers key in svc
On Fri, 26 Apr 2024 21:36:36 +, Seymour J Metz wrote: >NO! Use RBOPSW; the caller might not be in the PSW key. > >-- Could you explain in what situation that happens? Is that when the task is multihreaded and another thread has changed the key in the psw in between the call to the svc and the time of looking at the psw? Thank you all for the quick reponses by the way :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
NO! Use RBOPSW; the caller might not be in the PSW key. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 26, 2024 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: finding callers key in svc It is a type 3 svc. I also saw an example that uses the TCBPKF field to determine the key. So I guess that is also an option? On Fri, 26 Apr 2024 20:20:26 +, Seymour J Metz wrote: >What type of SVC? The SVRB only exists for 3, 3 and 4. > >-- -- 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
Re: finding callers key in svc
It is a type 3 svc. I also saw an example that uses the TCBPKF field to determine the key. So I guess that is also an option? On Fri, 26 Apr 2024 20:20:26 +, Seymour J Metz wrote: >What type of SVC? The SVRB only exists for 3, 3 and 4. > >-- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding callers key in svc
What type of SVC? The SVRB only exists for 3, 3 and 4. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 26, 2024 3:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: finding callers key in svc Hello List, Is there way to determine the key that the caller of a SVC is executing in? For a PC routine doing an ESTA and some shifting seems to be the way to find the key, but I'm unsure how the same could be done from a user SVC. Is it somewhere in the SVRB? Also, I see this example in the authorized code scanner: https://www.ibm.com/docs/en/zos/2.4.0?topic=fixes-fetch-vulnerability-example vulnerable: LA R3,copyparms MVC 0(4,R3),0(R2) fixed: LHI R3,1 ESTA R0,R3 SRDL R0,48 LHI R0,3 LA R3,copyparms MVCSK 0(R3),0(R2) I noticed that the length loading in R0 for the MVCSK is 3, while in the vulnerable mvc example the length is 4. The POP for MVCSK says: L specifies the number of bytes to the right of the first byte of each operand. Therefore, the length in bytes of each operand is 1-256, corresponding to a length code in L of 0-255. Is there any logic behind why MVC uses the actual byte count and MVCSK uses the 'number of bytes to the right'? Kind regards, Erik Janssen. -- 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
Re: finding callers key in svc
The key is in the RBOPSW of the callers RB. As for the byte count, MVCSK uses the same format of the length in the register as you would use in EX instruction, 1 less than the actual length. Also, if you look at the assembly listing for an MVC, for example MVC 0(8,R3),0(R8) the assembler will generate D207 3000 8000, so it uses the a length of 1 less than the length. Wayne Driscoll Note: All opinions strictly my own. On Fri, Apr 26, 2024 at 2:21 PM Erik Janssen < 062c999269e8-dmarc-requ...@listserv.ua.edu> wrote: > Hello List, > > Is there way to determine the key that the caller of a SVC is executing > in? For a PC routine doing an ESTA and some shifting seems to be the way to > find the key, but I'm unsure how the same could be done from a user SVC. > Is it somewhere in the SVRB? > Also, I see this example in the authorized code scanner: > > https://www.ibm.com/docs/en/zos/2.4.0?topic=fixes-fetch-vulnerability-example > > vulnerable: >LA R3,copyparms >MVC 0(4,R3),0(R2) > > fixed: > LHI R3,1 > ESTA R0,R3 > SRDL R0,48 > LHI R0,3 > LA R3,copyparms > MVCSK 0(R3),0(R2) > > I noticed that the length loading in R0 for the MVCSK is 3, while in the > vulnerable mvc example the length is 4. > The POP for MVCSK says: > L specifies the number of bytes to the right of the first > byte of each operand. Therefore, the length in bytes > of each operand is 1-256, corresponding to a length > code in L of 0-255. > > Is there any logic behind why MVC uses the actual byte count and MVCSK > uses the 'number of bytes to the right'? > > Kind regards, > Erik Janssen. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne Driscoll Software Engineer | Mainframe Software Division Broadcom Software *Office: *630-300-1931* Mobile:* 630-247-1632 wayne.drisc...@broadcom.com -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
finding callers key in svc
Hello List, Is there way to determine the key that the caller of a SVC is executing in? For a PC routine doing an ESTA and some shifting seems to be the way to find the key, but I'm unsure how the same could be done from a user SVC. Is it somewhere in the SVRB? Also, I see this example in the authorized code scanner: https://www.ibm.com/docs/en/zos/2.4.0?topic=fixes-fetch-vulnerability-example vulnerable: LA R3,copyparms MVC 0(4,R3),0(R2) fixed: LHI R3,1 ESTA R0,R3 SRDL R0,48 LHI R0,3 LA R3,copyparms MVCSK 0(R3),0(R2) I noticed that the length loading in R0 for the MVCSK is 3, while in the vulnerable mvc example the length is 4. The POP for MVCSK says: L specifies the number of bytes to the right of the first byte of each operand. Therefore, the length in bytes of each operand is 1-256, corresponding to a length code in L of 0-255. Is there any logic behind why MVC uses the actual byte count and MVCSK uses the 'number of bytes to the right'? Kind regards, Erik Janssen. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
