There is a FRR parm on the IEAMSCHD Isn’t the SETFRR done on your behalf when issuing the IEAMSCHD macro ?
> On Apr 27, 2022, at 12:34 PM, Mike Shaw <techsupp...@quickref.com> wrote: > > 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 <reichman...@gmail.com> >> 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 <rel...@us.ibm.com> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
