Long ago someone at Parkrink showed rigorously that the problem of determining the currently active (dynamically descendent) PL/I execution-time ON unit from a determination of the statically descendent by one (by examining source programs or invoking IGGDEITY) was recursively unsolvable. This problem, the same one in a slightly different guise, is thus insoluble in general too.
This is not to say that for certain very well-behaved source programs---Those one has written oneself---something useful can never be done. One can always make one's own conventions. The availablility of, e.g., the unprivileged SAMxx--SAM24|SAM31|SAM64--instructions does, however, make well-behaved a heroic assumption in any other situation. When this issue is important at execution time two tactics, viz., 1) a TAM followed by appropriate branches to (in general) different code sequences for any of AMODE(24), AMODE(31), or AMODE(64) that may be relevant in context, or 2) a TAM, followed by save-result, SAMxx to set desired AMODE, . . . <whatever>. . . , and SAM<save-result value> to restore the status quo ante AMODE, are always available, 2) usually the being preferable one. I am suspicious--John McKown has already made this point in different terms--of wish-fulfillment schemes that seek to impose premature binding times. Addressing mode is, finally, execution-time bound, sometimes although not always in a data-dependent way; attempts at its assembly-time or link-time resolution will thus sometimes fail; and they will never be robust/idiot-proof. John Gilmore, Ashland, MA 01721 - USA
