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
