True, but my understanding is that BAKR is quite slow compared to normal save area chaining processes, especially for frequently-used subroutines.
I could be wrong about that, and obviously as the hardware changes IBM can improve the performance of BAKR, but that was the last advice concerning use of BAKR / PR that I remember seeing. Peter -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Ituriel do Neto Sent: Wednesday, October 7, 2020 12:00 PM To: [email protected] Subject: Re: Register saving formats Hi, Maybe i didn't understand correctly, but if you use BAKR and PR, don't need to worry about saveareas sizes. It takes care of everything including PSW, AR. Regards Ituriel Em sexta-feira, 2 de outubro de 2020 09:44:40 BRT, Peter Relson <[email protected]> escreveu: <snip> ...but the problem is that none of them are backwardsly compatible with the standard 72-byte save area. </snip> Totally untrue. The documented 144-byte (and 216-byte) save areas can be passed just fine to a routine that uses a 72-byte save area. That is why they were designed the way they were. The one thing that you lose is the ability to "chain forward" when reading info in a dump. That has never been reliable. <snip> but it is because with the 64-bit save area formats for amode 31 programs you are saving your low-halves in the caller-provided save area as normal, but you save the high-halves in *your* save area.] </snip> The "because" is not a valid conclusion. And in only some linkage conventions do you save the high-halves in your save area. <snip> Is there really no possible way that it could be accomplished? </snip> Read the manual. Peter Relson z/OS Core Technology Design This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
