Re: High halves, ARs and old vs. new expectations (Was "WTO")
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? Let's be precise. Neither C nor COBOL expects exactly what you wrote. They expect what the linkage conventions say they can expect. So, for example, they expect that high halves 2-14 and ARs 2-14 to be preserved (and they expect that low halves 2-13 are preserved). The z/OS function, whatever it is, will conform to its documentation which in turn relies on the base being what the linkage conventions say. I think that by "alter" you mean both that it alters and also that it does not restore. No function would change to do so. That would be incompatible. New functionality could choose to do so (and document so). Then it would be up to the exploiter of that new function to accommodate that. Here too no harm is done to code that is ignorant of high halves (in this case, code using the new function cannot be considered to be ignorant). 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
Re: High halves, ARs and old vs. new expectations (Was "WTO")
On Mon, Nov 11, 2019 at 8:45 AM Charles Mills wrote: > Sure, there are lots of solutions (assuming the shop is not mortally > afraid of touching 1993 assembler code, has a budget and staff to do so, > and can find the source). > > My thought is why would the shop expect a problem? Why would a routine > that has been working since 1993 be a suspect in an obscure > high-halves-in-compiled-code problem? > I guess we'll just have to say "times change". Or, if we want to be "nasty", we could say "What isn't specifically saved is subject to being changed." Of course, this means a code review when something significant changes, such as from 32 bit registers to 64 bit registers. Your code might not have changed, but IBM's might have. Ergo, all use of an API used in code _should_ be reviewed. Of course, who has time for that? Curiously, at least around her, that would be another bullet in the "z/OS is junk" argument, despite the fact that Windows has historically had even worse problems. > > Charles > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High halves, ARs and old vs. new expectations (Was "WTO")
Sure, there are lots of solutions (assuming the shop is not mortally afraid of touching 1993 assembler code, has a budget and staff to do so, and can find the source). My thought is why would the shop expect a problem? Why would a routine that has been working since 1993 be a suspect in an obscure high-halves-in-compiled-code problem? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 11, 2019 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: High halves, ARs and old vs. new expectations (Was "WTO") On Mon, Nov 11, 2019 at 7:52 AM Charles Mills wrote: > > 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 > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > IMO, don't do a static "call" to the assembler. I don't know off hand if it is possible, but I'd try to make the HLASM's calling code use the equivalent of a z/OS LINK macro. If that's not possible, then I'd make a slight change to the z/OS HLASM to save the 64 bit GRs and the ARs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High halves, ARs and old vs. new expectations (Was "WTO")
On Mon, Nov 11, 2019 at 7:52 AM Charles Mills wrote: > > 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 > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > IMO, don't do a static "call" to the assembler. I don't know off hand if it is possible, but I'd try to make the HLASM's calling code use the equivalent of a z/OS LINK macro. If that's not possible, then I'd make a slight change to the z/OS HLASM to save the 64 bit GRs and the ARs. -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
High halves, ARs and old vs. new expectations (Was "WTO")
> 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 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? 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
