That depends on the exit. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי
________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Colin Paice <colinpai...@gmail.com> Sent: Tuesday, November 21, 2023 3:59 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BAKR/PR and Linkage Convenction I've had to work with exits which do not have a save area on entry so you need a BAKR... then allocate storage... and use that for the standard save areas. On Tue, 21 Nov 2023 at 20:13, Jon Perryman <jperr...@pacbell.net> wrote: > No one discusses the down side of BAKR and Linkage stack versus standard > savearea chains. > > Tom says that he uses BAKR to save registers for each CSECT called and > savearea for each call within the CSECT. I personally don't see the upside > with this philosophy. My recommendation would be to follow Peter's > recommendation of using standard save areas. > > 1. 99% of programs require a workarea. It's simple to add an additional > 72/144 bytes for a save area which places the workarea and savearea > together. I personally prefer getmain a large area so that no getmain is > required for subsequent calls. > > 2. Complicates dump analysis. For simple programs not a big deal but > having R13 point to the save area chain allows you to quickly and easily > display the call sequence where R14 points to the called code where in my > case always has an eyecatcher. I believe the Linkage stack is the LSSD > which I could never find a mapping macro making it a little difficult to > run the LSSD entries. I must profess that I didn't look very hard because I > only needed it for my active PC routines. > > 3. Abend recovery can be more difficult. It's been a long time but if I > remember correctly, ESTAE creates a linkage stack entry and an abend causes > linkage stack entries to be flushed up to the ESTAE entry thus limiting > recovery to the CSECT which requires setting up recovery environment for > each point that requires recovery. Not unsurmountable but can be funky when > implementing things like the z/XDC abend trapping where in Tom's case would > require every CSECT setup an ESTAE and handle percolation causing z/XDC to > be invoked multiple times for a single abend. > > For inexperienced assembler programmers, carefully consider how you > implement BAKR. I suspect that the documentation for the linkage stack > mentions the negative impacts. > > On Sat, 18 Nov 2023 13:09:56 +0000, Peter Relson <rel...@us.ibm.com> > wrote: > > >Tom M wrote: > > > >> This is documented in chapter 2 of the Assembler Services Reference. > > > >Tom meant the Assembler Services Guide. And he probably feels bad about > that mis-reference because he helped write that section. > > > >This is the Linkage Conventions section. > > > >If you're saving only the low halves of the GRs, an 18-word save area > provided by the caller is recommended. > >If you're saving only the 64-bit GRs, a 36-word save area is recommended. > >If you're also saving access registers, the standard convention is to use > the linkage stack > >(there are mapped approaches that use a larger save area that can hold > both GRs and ARs). > > > >Do note that there are limits to the number of entries you get by default > on the linkage stack. > >And keep in mind that ESTAE-type recovery routine retry is sensitive to > the linkage stack level when the routine is established. > > > >Peter Relson > >z/OS Core Technology Design >
