And FWIW there is another overlapping complexity here besides AMODE 64 -- speaking in theory only, because there is no reality of 64-bit COBOL.
There are really *three* kinds of module: those that are AMODE 64, those that are AMODE 31 but use and/or count on the high halves of registers, and those that are "pure" 31/32-bit. That middle case is a problem child. A program could be AMODE 31 but either destroy the high halves of a caller's registers and/or expect a called program to preserve the high halves of its registers. (There are many common uses of all 64 bits of a register outside of AMODE 64.) The whole save area thing has gotten to be a little bit of a pile IMHO. It used to be the first two commandments: thou shalt do a STM 14,12,12(13) on entry and thou shalt provide an 18-word save area to callees. Now I am often in doubt and have to look up the rules and then I am still in doubt. How many formats of save areas are there now? IMHO if IBM was going to go to a new linkage convention -- which in itself was a great idea -- they should have addressed 64-bit compatibility. I think AMODE 64 was very much on the horizon before XPLINK ever saw the light of day. I would think they might have come up with a convention that was almost as efficient as current XPLINK(31) but provided for straightforward calling among the three types of programs I listed above. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Marchant Sent: Wednesday, October 17, 2018 2:51 PM To: [email protected] Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote: >It is only available in 31-bit. > >An interesting question to ask is: if it were available in 64-bit but mixing >and matching 31- and 64-bit modules was not possible (i.e., you would have to >recompile all modules in an application), would that be interesting? Or is it >the case that it is vital to be able to selectively compile modules (in 64-bit >mode) and mix and match? Thank you for asking. While I was a COBOL programmer for several years, I have not worked in that role for decades. AMODE(64) COBOL could be a valuable tool for for applications that could benefit from very large tables. In many cases, such a conversion could be made by changing a relatively small number of modules if they could easily interoperate between AMODE(31) and AMODE(64) modules. The decision that was made that LE would support AMODE(64) only using XPLINK-64 made such interoperability difficult and expensive. XPLINK was invented to solve a particular problem, that C has a propensity for creating very small subroutines. XPLINK reduces the overhead in calling such subroutines somewhat. At the same time, it makes it rather expensive to call programs that use standard linkage. In addition, XPLINK-64 was designed in a way that makes it incompatible with 31-bit XPLINK. COBOL programs typically do a considerable amount of I/O to data sets, often using GET and PUT, which require standard linkage. If COBOL were to implement AMODE(64) in such a way that the standard FxSA save areas were used, it could more easily allow the interoperability of AMODE(64) with AMODE(31) programs without such additional overhead. PL/I already supports AMODE(64) to some extent, but only for applications that are entirely AMODE(64). The reason is XPLINK-64. As far as I know, it has not been adopted in any significant way, if at all. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
