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 +0000, Seymour J Metz <sme...@gmu.edu> wrote:

>Even on a S/360 that code is inefficient, but still valid.
>
>         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
>         SR   R1,R1
>         IC    R1,RBOPSWB2    Key and flags
>         N    R1,=XL4'F0'     Isolate PSW KEY 
>*        ST    R1,KEY              STORE CALLER KEY
>         DC    H'0'                    FORCE ABEND
>
>As a matter of style I would probably have written
>
>         USING RBBASIC,R5          SVRB address set on entry
>         L    R7,RBLINK          CALLER's RB
>CALLER   USING RBBASIC,R7         
>         SR   R1,R1
>         IC    R1,CALLER.RBOPSWB2    Key and flags
>         N    R1,=XL4'F0'     Isolate PSW KEY 
>*        ST    R1,KEY              STORE CALLER KEY
>         DC    H'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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
>Peter Relson <rel...@us.ibm.com>
>Sent: Wednesday, May 1, 2024 8:55 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: finding callers key in svc
>
><snip>
>         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'00F00000'    ONLY PSW KEY
>         SRL  R1,16              SHIFT TO 000000K0
>*        ST    R1,KEY              STORE CALLER KEY
>         DC    H'0'                    FORCE ABEND
></snip>
>
>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

Reply via email to