On Wed, Dec 15, 2010 at 1:22 PM, Lorne Dudley <dudl...@queensu.ca> wrote:
> I'm having problems getting the following batch program to run correctly. > It's running from an authorized library and abends with 0C4, reason code 4. > > The book says "the key of the storage area that the running program tries > to access is different from that of the running program". > > Data Areas for CVT says > Storage Attributes: Subpool: Nucleus > Key: 0 > Residency: Below 16M line > > Any ideas appreciated. > Ok. "Don't do it". It is basically a bad idea. While that field was originally intended for "user" (i.e. "customer") use, in practice it is unusable. If you want to be able to anchor something globally then you should probably use some common storage and create a global name/token pair to point to it. > LR R9,R15 .SET UP ADDRESSABILITY > USING Y,R9 .SET UP ADDRESSABILITY > USING CVT,R2 .CVT DSECT > * > MODESET KEY=ZERO,MODE=SUP > * > L R2,CVTPTR LOAD UP CVT ADDRESS > L R3,CVTUSER LOAD CVTUSER ADDRESS > If you wanted to alter the contents of CVTUSER (a bad idea remember) then you should use "LA R3,CVTUSER" > * move 4 characters to CVTUSER > MVC R3(4),=C'TEST' > RETURN (14,12),RC=0 .RETURN TO CALLER > Not to be harsh, but you obviously don't know what you're doing. Unfortunately what you're doing is potentially harmful. As it is you would get the contents of CVTUSER (i.e. zero) in R3 and your subsequent move would fail with a S0C4-4, but only because the hardware provides low address protection. Almost anywhere else you'd clobber whatever happened to be there. What problem (other than just playing around) are you really trying to solve? -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html