> Sigh... I am writing a service routine called by clients that must not > see the error-time registers. The SDWA is completely reallocated for > the transition between FRR and ESTAE processing, with only the SDWACOMU > copied to the new SDWA from the old SDWA. However, the client won't care > about that field. The client ESTAE routines are not mine. > > My FRR is established under a stacking PC routine. I cannot use an ARR > to muck with the SDWA, because RTM will reallocate the SDWA upon > subsequent percolations due to storage key changes. My ARR will get a > key zero SDWA. Subsequent client ESTAE routines get a key 8 SDWA.
Peter or Jim or another IBM-er may correct me, but I think that any changes you make in the (register) contents of the SDWA are passed along on percolation, regardless of key transitions. The only place that doesn't hold is for percolation from (RTM1) the oldest FRR to (RTM2) the newest non-FRR. And in that case you can use SDWACOMU to set a footprint. If your PC has an ARR, then by definition that's always the newest non-FRR and it will be given control if your FRR elects to percolate. In that case you could use SDWACOMU to tell yourself to rearrange the SDWA appropriately so your caller's recovery does not see anything it shouldn't. Here we're assuming you're going to percolate. I would suggest your strategy should be to have your ARR clean up and retry directly to a PR instruction. That PR would pop the PC entry and guarantee that your caller always gets their key, state and registers put back together correctly. At worst they would just get a nasty return code. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
