>Not a big fan of EUT FRRs Your right. I prefer to examine my environment and chose to use an ESTAEX instead of a FRR unless required. The FRR stack is limited to 2 uses. So when forced to use an FRR, I extend the FRR stack by replacing the prior FRR and restoring it upon exit. Using an EUT=YES FRR creates restraints for code that doesn't need them. If you need the FRR, you have the restraints anyway. But if you don't need it and use an EUT=YES FRR, you just placed a whole bunch of restrictions. And I never use SVCs in any PC code.
>I know that R14 points to the EXIT service call Your right again. This is an oversimplification that I didn't bother to elaborate. >It’s a real pain when you want to retry into 64 bit addresses However, I support releases prior to 1.13 so I choose a method that works to the lowest common denominator. I retry to a 31 bit stub that loads the 64 bit address and does a BSM. Your point is well taken. I should refrain from expressing opinions in this forum. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Relson Sent: Thursday, October 03, 2013 7:14 AM To: [email protected] Subject: Re: FRR Recovery Routine Environment >Not a big fan of EUT FRRs. That's a curious statement. As with most things, EUT FRRs solve a problem. If you have the problem, you need them. If you don't have the problem, you don't need them. It seems that it is really not a question of being a fan or not. Maybe you're not a fan of using FRRs in environments where you could use an ESTAEX for such reasons as you want to be able to issue an SVC from your recovery routine or you do not want your recovery to get control with locks obtained by the mainline in such cases. >I know that R14 points to the EXIT service call That is not true for FRRs. >It’s a real pain when you want to retry into 64 bit addresses Given that you have gone to the real pain of using RMODE 64 apparently for many cases that are not supported, I'm surprised to see this statement. You can set your 64-bit address with bit 63 on into the register 15 retry slot of the SDWA (SDWAG6415), use SETRP with RETRY=64,RETRY15=YES , and identify a retry address of CVTBSM0F. I'd call that a relatively minor inconvenience; perhaps that's a real pain to you. This has been available since z/OS 1.13 which is the first release where RMODE 64 of enabled code was tolerated. 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
