Donald Likens wrote: > What I don't understand fills volumes and when I think I understand something > I am often wrong. One of the things I don't understand is SRBs. I know this > because what I am doing is not working! Note: When I use the option to turn > off SRB processing and call (BALR) the SRB routine, instead of scheduling it, > it works great. > > I schedule my SRB with the following macro: > > IEAMSCHD EPADDR=SRBRTN,PRIORITY=ENCLAVE,ENCLAVETOKEN=WKETKN, X > PARM=ISELPARM,SYNCH=YES, X > PURGESTOKEN=WKTKN,PTCBADDR=WKTOLD, (SAME AS PSATOLD) X > SYNCHCOMPADDR=ISELCOMP,SYNCHCODEADDR=ISELCODE, X > SYNCHRSNADDR=ISELRSN > > In all my reading SRBs are work that runs in parallel to the scheduling > program but the SYNCH documentation states: > > SYNCH=YES The SRB is to be scheduled and synchronized with the callerâs > work unit; the callerâs work unit is suspended until the SRB completes, is > purged, or ends abnormally. > > My interpretation of SYNCH=YES is that the scheduling program waits for the > SRB to complete. It my reading it also says that I need to use wait and post. > I reason that wait and post is an alternate way to do what SYNCH does. My SRB > terminates by branching to register 14. When it terminates I expect my code > to resume. Correct? > > I read somewhere that storage reference by an SRB had to be in common > storage. I reasoned that storage referenced by the SRB had to be in common > storage if the SRB runs in another address space. The parm I pass points to > storage in my address space, I believe this should work because this SRB runs > in my address space (ENV=HOME). Am I correct? > > I also read that storage obtained by an SRB had to be in SQA. The Authorized > Assembler Services Guide does not say this, so I do not believe it. Am I > correct? > > When I first started testing everything looked great. My jobs were scheduling > the SRB and running to completion. But as it turned out the SRB was abending > and disappearing so I added the following options: > > PURGESTOKEN=WKTKN,PTCBADDR=WKTOLD, (SAME AS PSATOLD) X > SYNCHCOMPADDR=ISELCOMP,SYNCHCODEADDR=ISELCODE, X > SYNCHRSNADDR=ISELRSN > Now when my SRB fails I know it because I display a message like the > following: > > SRB SCHEDULING RC=28 COMP=08 CODE=000C4000 > > I am not sure why but I still did not get a dump (I thought the task recovery > routines would create a dump but they didnât) so I added the following code > to my SRB: > > SETFRR A,FRRAD=FRRA,EUT=YES,MODE=FULLXM,WRKREGS=(R1,R2) > > FRR DS 0H > USING FRR,R15 > ST R14,FRRSAVE > LR R3,R15 > DROP R15 > LR R4,R1 > *C TAKE A DUMP > USING FRR,R3 > SDUMPX HDR='SRB ERROR',BRANCH=YES, > SDATA=(NOSQA,RGN,CSA) > *C RETURN TO FRRRETRY > L R2,FRRRETRY > SETRP RC=4,REMREC=YES,RETREGS=YES,FRESDWA=YES, > DUMP=YES,WKAREA=(R4),RETADDR=(R2) > L R14,FRRSAVE > BR R14 > > Now I get a dump but I donât know how to read it. I do not see any RMT2 > information or any control blocks that give me the registers and PSW at the > time of error. I looked in the Diagnostic reference manual but I did not see > what I needed. Can anyone direct me to the proper documentation or at least > tell me where to look in the dump for the registers and PSW at time of error > in a SRB?
Everything you need to know and the answers to all your questions are in the Authorized Services Guide and Reference manuals. Also the MVS data area manuals are useful if you don't know the format of the SDWA. Henry > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
