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 <charl...@mcn.org> 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
