It strikes me that this is possibly the wrong question, as is the question about passing a parameter to the FRR.
The answer to the subject's question is: the same value that is in R2 on entry to the SRB when you have requested that the system establish the FRR, namely the address of a 24-byte area associated with the FRR (as is true for any FRR). You don't generally need to "pass a parameter to the FRR", you put data into the FRR parameter area on entry to the SRB, just as you would if you set the FRR yourself instead of having the system set it for you. Remember that there is always a window after you set the FRR and before you get a chance to fill in its parameter area where, in theory, you could blow up. In the SRB case, if the FRR gets control and no data has been placed in the parameter area, then the SRB blew up before, basically, your first instruction. For the most part that is not realistic unless you have asked that entry to your SRB have a cross memory environment that might not be valid, or a machine check has occurred that is not under your control. A better question might be "is there anything initialized into the FRR parameter area set by the system for an FRR identified to IEAMSCHD (or to SCHEDULE for that matter)" -- requesting an FRR via IEAMSCHD is analogous to setting the SRBFRRA field in the SRB area passed to SCHEDULE. The answer to "is anything initialized" is: if and only if the SRB is being ABENDed before it is given control then -- the first word of the FRR parameter area contains the SRBPARM value -- the second contains the SRB address if the SRB is user-managed (as it is for SCHEDULE, for example) In any case, the SRB's FRR should be aware of this and react accordingly. Typically, one might save the SRBPARM address (in R1 on entry to the SRB) into the FRR parmarea (R2 on entry to the SRB) as the first statement of the SRB routine so that the FRR has access to that data whenever possible. And if you blow up "before that", then curse the fates or yourself, depending on where the fault lies, if you really needed to do something for a problem that occurred in that window. Perhaps the SRB's FRR should avoid using the first word or first 2 words of the 24 bytes for anything other than the SRBPARM/SRB addresses to avoid a conflict. FWIW, the only cases I can find where the "SRB is being ABENDed" applies are -- processor affinity not available (this can no longer happen, as requests for such affinity are no longer honored, as of z/OS 1.11 I believe) -- SSRB has a CML (this cannot happen for the initial dispatch of an SRB since it cannot hold a CML on initial dispatch). I'm not sure what you get if XM environment has been requested but is not available. It must be an 058 abend. That case does not appear to set anything into the FRR's parameter area. If that would be a concern, then don't request that processing. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
