Tony Thigpen wrote "stuff". The opinions in that post do not reflect the requirements of an interface provider.
It is irrelevant what your routine is called from. The caller is responsible for meeting the interface, whether that be save area or parameter list or other data or environment. And if they don't, the problem is on them. And if they are not able to meet the interface, and you feel it important that they be able to do so, then you have not provided a suitable interface. And just about everything else in that post is similarly off key. The post does not show understanding of the intent of the information at offset 4. And that is surprising since this has been discussed so many times. No approach requiring the caller to identify something could have been done compatibly. And compatibility matters. A lot. Dave Clark wrote "Because how is the callee supposed to know how to treat the caller's savearea unless the callee knows how long the caller's savearea is?" Because they have no need to do so. How many times do we have to go through this? . It's a fully proper question to inquire how long is the R13 area provided by Rexx on a call. That should be clearly documented. Dave Clark wrote "OK, so what you're saying is that I should do the standard updates to the caller's 72-byte save area and then do the BAKR instruction to save everything. Finally, I only have to do RP to return to program based on the saved stack values. Correct?" No, not correct. Unless you like to waste cycles. And you do not use "RP". I could not tell if you mean "PR" or truly "RP". You can use BAKR and not do the STM/LM at all. Part of the z/OS linkage conventions explains what you can do if your caller is not known to be providing a 144-byte save area yet you want/need to save high halves too. That situation/approach surely applies to zVSE too. Peter Relson z/OS Core Technology Design
