A quick test of performance shows that BAKR/PR is about 14 times as expensive as STM/LM.
I would say that in in initialization/termination code using BAKR/PR isn't going to hurt you, but I would totally avoid it in record level code. Chris Blaicher Technical Architect Mainframe Development P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com Syncsort Incorporated 2 Blue Hill Plaza #1563 Pearl River, NY 10965 www.syncsort.com Data quality leader Trillium Software is now a part of Syncsort. -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, May 29, 2018 2:00 PM To: MVS List Server 2 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Subject: Re: BAKR Instruction *Any* choice of linkage conventions imposes a dependency between the caller and the callee. BTW, this is an example of why I prefer to encapsulate such things in macros. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Peter Relson <rel...@us.ibm.com> Sent: Monday, May 28, 2018 5:57 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: BAKR Instruction Some things to think about: -- Recovery routines and retry points are tied to specific linkage stack levels in the general case. Use of BAKR as a linkage can complicate that. -- BAKR/PR is slower than using a typical savearea linkage. -- You might find that use of BAKR by the caller poses an unnecessary dependency between the caller and the callee. Consider the alternative of calling via BASR, and the callee deciding whether to save/restore regs via BAKR/PR or via STMG(+STAM)/LMG(+LAM). Peter Relson z/OS Core Technology Design
