Is it possible that you have DROP'd R13 before you've finished with the DYNAMIC area?
If so, the USING on R1 will resume but R1 will no longer contain the correct address. === > Date: Wed, 6 Jun 2012 09:41:13 -0700 > From: [email protected] > Subject: Getmain question > To: [email protected] > > Guys: > > I am issuing a : > > LA R0,DYNSIZE dynamic area size to R0 > GETMAIN RU,LV=(0),SP=229 getmain dynamic area > LTR R15,R15 Do we have a zero return code ? > BNZ GETVERR No bailout with a msg > USING DYNAMIC,R1 Getmain - good > ST R13,SAVEAREA+4 save caller's savearea address > ST R1,8(R13) save our savearea address > LR R13,R1 our savearea address to R13 > DROP R1 > USING DYNAMIC,R13 > LA R1,IDFWORK > ST R1,PARMLIST > OI PARMLIST,X'80' > > This is being issued in IRREVX01, DYNSIZE is about 1000 bytes. A customer > reported a S0C4-11 but they had > > DIAG00 in SYS1.PARMLIB as > DIAG > VSM TRACK CSA(ON) SQA(ON) > VSM TRACE > GETFREE(OFF) > VSM ALLOWUSERKEYCSA(YES) > > What we saw in a trace is getmains for subpool 230...we arent using 230, if > sp229 didnt have enough storage i know this is > Private High, would i see a S0C4-11...? > > Whats even more interesting, onely one customer out of about 300+ are seeing > this on z/OS 1.11 > One of the reasons I am asking, there seems to be a lot of issues with the > DIAG parameter: > > > VSM ALLOWUSERKEYCSA(YES) > > > > Am i all wet or am i thinking right .... > > Regards, > > Scott J Ford > Software Engineer > http://www.identityforge.com
