> The interesting scenario is the case of the "know something" caller > calling a "know nothing" target which in turn calls a "know something" > target.
I've been thinking about that one for a couple of days. My scenario is this: a recently-compiled C or COBOL program calling a homegrown assembler function untouched since 1993 calling an MVS service, which now of course is a z/OS V2R4 service. The C or COBOL expects high halves and ARs to be preserved. The assembler routine is ignorant of them. It calls a z/OS function which alters some high halves. Is there a problem? I am tending to think not. The z/OS function (hopefully!) does not alter anything that the modern C or COBOL expects to be preserved. Am I right? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, November 11, 2019 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO <snip> Does code written at a time before "high halves existed", or perhaps even before ARs existed, and depending only on OS behavior documented at such a time, continue to operate correctly? </snip> I can't think of a case where it wouldn't. Because such code would not have known anything about AMODE 64 or high halves. It would not have had any instructions or behavior that could have been affected by data in any high half (or any AR). That is why (at least "old") services (even with newer support that deals with 64-bit regs) are not supposed to look at data in high halves if the caller is not AMODE 64. That is why old services are not supposed to look at ARs if the caller is not AMODE 31. Going back to MVS/XA, that is why old services are not supposed to look at the high byte of an address if the caller is not AMODE 31 (and, now, is not AMODE 64). Services created after the advent of a new function (be that 64-bit GRs, ARs, or whatever) might always require the user to be cognizant of those new functions. The interesting scenario is the case of the "know something" caller calling a "know nothing" target which in turn calls a "know something" target. The "know nothing" target would not have any code to preserve high halves (or ARs if it went that far back). This is behind the asymmetry in the linkage convention for GRs (high half of GR14 is preserved, low half of GR14 is not for the AMODE 31 case). I'll leave it as an exercise to the reader of how this could be important. For AMODE 64 cases, that asymmetry does not exist. I'd bet that there are (likely many) branch-entry services that do not follow this convention; almost all get away with it just fine (if you're PC-entered or even if you use BAKR to save regs, you're pretty much safe because the PR restores the saved reg 14). Using the high half of GR14, when not AMODE 64, for saving "something" and expecting that to be preserved across a branch-entry interface is counter-intuitive (even if the linkage convention says you can do so). I'd guess that almost no one codes to such an expectation. But then I'd have guessed the same would be true for the high halves of GR0 and GR1 and GR15 (and AR1 and AR15) where they should have known better. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
