As far as I remember a program linked with the RENT option will be loaded in SP 252 Key 0. Now lookig at the source code this particular program is linked edit with the following options: 'REFR,AMODE=31,RMODE=24,AC=1'
Paul D'Angelo ---------------------------------------------------------------------- Pure guess on my part on this. But from my limited knowledge, the literal pool is part of the actual load module. Load modules are placed in memory which is __NOT__ fetch protected. The now, the MVCSK instruction is likely used because the programmer felt that the source of the data __might possibly__ be set as fetch protected. Fetch protected memory can only be read when the key in storage matches the PSW key or the PSW key is 0. >From looking here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2v2b0/1.8.3 It appears that most storage subpools are fetch protected. My main problem is that I can't find where it is documented whether a program is loaded into fetch protected memory or not. On Sat, 2011-01-01 at 18:13 +0000, [email protected] wrote: > I have posted two coded fragments from a program I found on the Internet. > ----------------------------------------------------------------------- > * > 00009700 > L R3,0(,R1) PARAMETER POINTER > 00009800 > LA R3,0(,R3) ZERO BIT 31 > 00009900 > * > 00010000 > MODESET MODE=SUP > 00010100 > IPK , Get PSW Key in R2 > 00010200 > LR R11,R2 SAVE PSWKEY > 00010300 > SPKA X'70' Switch To PSW Key 7 From address > 00010400 > * > 00010500 > STORAGE OBTAIN, OBTAIN WORKAREA > X00010600 > LENGTH=WORKLEN, > X00010700 > CALLRKY=YES, > X00010800 > LOC=BELOW, > X00010900 > SP=129 > 00011000 > MVC 4(4,R1),=CL4'F1SA' INDICATE LINKAGE STACK USED > 00011100 > LR R13,R1 > 00011200 > USING WORKAREA,R13 > 00011300 > * > 00011600 > SPKA 0(R11) Switch Back To Original PSW Key > 00011700 > -------------------------------------------------------------------------------- > > In the Above snipet of code A Storage Obtain is issued for Subpool 129 with > the CALLRKY=YES. It is my understanding that PSW Key had been previously set > to Key 7 by the SPKA instruction. > > -------------------------------------------------------------------------------- > DLM8 DS 0H > 00013800 > 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 > -------------------------------------------------------------------------------- > In a second code fragment (Above) the author again sets the PSW Key to Key 7, > then prepares to issue an MVCSK instruction to move some data from R3 to the > storage Obtained in the first code fragment. > I am assuming the "MVCSK" instruction is the proper method for moving data > between > two different keys, when Not in Key 0. > > Register 3 contained the address of the MVS PARMS data from the EXEC DD > Statement. > > -------------------------------------------------------------------------------- > * > 00037100 > WORKAREA DSECT , KEY 7 WORKAREA > 00037200 > SAVEAREA DS 18F > 00037300 > STECB DS 1F ECB ADDRESS FOR ATTACH > 00037400 > STTCB DS 1F TCB ADDRESS RETURNED BY ATTACH > 00037500 > EPNAME DS CL8 EPNAME FOR ATTACH EPLOC= > 00037600 > LATT DS XL(LATTL) ATTACH WORK AREA > 00037700 > RACROUTE DS XL(MFLROUTL) WORKAREA FOR RACROUTE > 00037800 > SAFWK DS XL512 WORKAREA FOR SAF > 00037900 > WORKLEN EQU *-WORKAREA > 00038000 > * > 00038100 > -------------------------------------------------------------------------------- > > So Why is it necessary to use MVCSK instruction in the second code fragment > and its not necessary in the first code fragment ? > > > Paul D'Angelo -- John McKown Maranatha! <><
