> I have posted two coded fragments from a program I found on the Internet.
> -----------------------------------------------------------------------
>          L     R3,0(,R1)               PARAMETER POINTER                
> 00009800
>          LA    R3,0(,R3)               ZERO BIT 31                      
> 00009900
<snip>>          IPK   ,                       Get PSW Key in R2                
00010200
>          LR    R11,R2                  SAVE PSWKEY                      
> 00010300
<snip>>          SPKA  X'70'                   Switch Into Key 7                
00013900
>          XC    EPNAME,EPNAME                                            
> 00014000
>          LR    R0,R4                   COPY LENGTH TO R0                
> 00014100
>          LR    R1,R11                  COPY SOURCE KEY TO R1            
> 00014200
>          MVCSK EPNAME,2(R3)            COPY EPNAME                      
> 00014300
>          OC    EPNAME,=CL8' '          FORCE UPPERCASE AND BLANKS       
> 00014400
>          SPKA  0(R11)                  Switch Back To Original PSW Key  
> 00014500
<snip>> 
> So Why is it necessary to use MVCSK instruction in the second code fragment 
> and its not necessary in the first code fragment ?
You would typically use the MVCSK/MVCDK instructions to move parameter data 
between a privileged function's working storage and a (potentially 
non-privileged) caller's working storage in a different key without requiring 
the privileged function to switch to key zero. The actual move is done using 
the key you specify, the point being (a) that you don't need to run in key 0 to 
move data between disparate keys and (b) that if your caller does not have key 
controlled access to that storage then the move will fail, thereby preventing 
the privileged function from violating key-controlled integrity rules. In this 
case, the source of the move is a (presumably caller supplied) parameter and 
the destination is working storage obtained (in key 7) by the called function. 
We can assume the overall environment is APF authorized because the MODESET to 
supervisor state requires it, so the purpose is simply to move data from a 
(probably key 8) caller to the key 7 function and there isn't really an 
integrity concern because both "sides" are authorized anyway.
Editorial comment: the swapping around of keys in this manner is potentially 
problematic - something I generally look at as a source of problems down the 
road. But in this case, at least with the code you have shared, it is 
innocuous. The MVCSK is being done correctly and for a valid reason - assuming 
there is a valid reason the function needs to run in a different key than its 
caller, which is always debatable in these cases. 
CC



                                          

Reply via email to