I have now had several exchanges with Peter Relson about this topic, and I am unsatisfied with the outcome.
I prefer to put tables of any significant size that that are to be shared by many address spaces above the bar. Moreover, many of these tables are compound ones. An obvious example is a tabular function T = f(x,y,z) comprised of four tables, one for each of the arguments x, y, z and one for the value T. In my practice these four tables may be, in general are, generated by different macros; and each of the argument tables may itself be compound, contain table extensions that are sometimes required and generated and sometimes not required and not generated. The program object containing them thus contains a number of addresses, some of them specified as vanilla external ones and some of them specified as WXTRNs. All of these addresses are to locations that are 1) within the program object and 2) above the bar. Now it is clear that these addresses (or null pointers) must be doubleword, AMODE(64) ones and that executables that access them and make use of these addresses must also be AMODE(64). These executables can of course be RMODE(31) or even, I suppose, RMODE(24), although I have not myself written more than a few lines at a time of such code in many years. It is and has been my contention that to mark such table objects as AMODE(x) when x is not 64 is hubristic at best. It would now, I think, be perverse to do so. They can be loaded below the line (sic). They cannot usefully be accessed by other than AMODE(64) code, wherever they may be resident. Some part of the problem here is, I think, terminological. For an atomic table of arithmetic constants---38-equivalent-decimal-digit extended-precision BFP values of pi, e and the like, say---both AMODE and RMODE are irrelevant. For compound, read-only, refreshable tables that contain ADCONs things are not so simple; and the current definitions are inadequate. Worse, they suggest bad practices. I know, of course, that my table-generation practices are not and are unlikely to become common; but the practice of putting to-be-shared tables containing ADCONs above the bar offers so many practical advantages over the available alternatives to it that it is likely to be used increasingly, particularly by ISVs; and it is important that this usage be clarified. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
