Joseph, I have to comment...many of your initial posts over the months you have posted on this list lack enough detail for anyone to help you without requesting more information.
As others have pointed out many times, it is better to: 1) Only post on this list after you have done thorough desk-checking of your code first 2) Read and understand all doc on the facility you are trying to use 3) Clearly state the problem you are having 4) Show your code when you post Based on the power of the z/OS facilities you are trying to use, you should have a trusted and knowledgeable person checking and/or testing your code...you can crater a z/OS system quickly if you are not careful... Opinions expressed are my own... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Apr 27, 2022, 10:33 AM Joseph Reichman <[email protected]> wrote: > Yes that’s because I had a bad ptr for the IARV64 so my first abend was > for D02 when I did my retry all I was attempting to do was to go somewhere > in my SRB and set reg 15 with a bad ie non zero return code > > However as the documentation points out if your recovery is a FRR and in > using IEAMSCHD it is that then stack entries made by a PC rtn have to be > accounted for > > I have one more question which I’m sure only you can answer > > When I do an Estae and my SDWAGR registers are corrupted > > This typically happens in the case above where thru my carelessness I pass > a bad ptr to an IBM service SVC or PC in that case I can always rely on > SDWASR regs who’s values are right after I issue Estae since I do this all > the way in the beginning of the program before I have a chance to make an > error > > I the case of IEAMSCHD both of those registers sets seem to be the same > > In which case I have no choice but to percolate. Good news though even > though I percolate I still get back control after the IEAMSCHD macro and > SYNCHCOMPADDR is equal to 8 SYNCHCODEADR and SYNCRSNADDR then have > SDWAABBCC and SDWACRC respectively right ? > > > On Apr 27, 2022, at 9:30 AM, Peter Relson <[email protected]> wrote: > > > > To be clear: are you saying that when you did not specify SDWALSLV at > all you get 60D-14, and when you specified it with a value of 1 you did not? > > > > <snip> > > This what I see for 60d .... > > </snip> > > > > It is just ridiculous that you continually ignore what someone writes, > and then post only what you think matters instead of everything. > > > > The "explanation" is one piece of the information in the documentation. > There are also the "actions". They are relevant too. Read them. In > particular the one I referred to. > > > > You never described the order of SETFRR (or implied SETFRR if you > scheduled the SRB to be given control with an FRR) vs BAKR vs PC. That must > be understood. > > > > If the order is > > SETFRR A > > BAKR > > PC to IARV64 > > PR > > PR > > > > Then if you want to retry within the BAKR code you would need SDWALSLV = > 1. If you want to retry prior to code running without that linkage stack > level, then SDWALSLV should be left 0. > > > > If the order is > > BAKR > > SETFRR A > > PC to IARV64 > > PR > > SETFRR D > > PR > > > > It would be 100%y WRONG for you to retry with SDWALSLV=1. That would be > considered a system integrity error. > > The retry address has to be owned by you and the retry has to be at the > linkage stack level associated with that address. > > > > 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 > > ---------------------------------------------------------------------- > 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
