>BAKR is quite slow compared to normal save area chaining processes This remains true. BAKR has more to do. So does PR. If performance is your goal, STM(G)/STAM is faster.
BAKR/PR is likely a good choice for initial entry to an application (especially one where you cannot change the caller to provide a large enough save area). It is not such a good choice for module to module linkage within an application. ESTAEX (and other things) are sensitive to the linkage stack level current when established which can (for example) make retrying to the right linkage stack level complicated. Peter Relson z/OS Core Technology Design
