<snip> However, I believe I see some conflict in that if a CSECT has AMODE 64 and a declared ENTRY to a data area, not executable code, on a even boundary, an ADCON referencing that will improperly have bit 63 set. </snip> Not correct. ADCON's do not intrinsically indicate AMODE unless you tell them to. And you should not do so for a case like this. The case that is a "conflict" is if you have an 8-byte ADCON to an odd address. You cannot distinguish that from an 8-byte AMODE-64-defining ADCON to an even address. And the answer to that conundrum is: don't do that, if you need to differentiate those cases. This has been well known since the advent of z/Architecture.
<snip> And how does AMODE 64 code branch to an AMODE 31 CSECT? To an AMODE 24 CSECT? Can an initiator directly ATTACH an AMODE 64 program which expects a 144-byte save area? </snip> I'd guess that you know the answer to all of these questions. AMODE 64 code branches to an AMODE 31 CSECT by a normal branch instruction or branch-and-save-type. If there needs to be an AMODE switch, then it uses BSM or BASSM. The same is true for an AMODE 24 CSECT target. If you have a "pointer-defined AMODE 64 address" then you do not use that as a target of a branch or branch-and-save. And if you use BSM or BASSM to give control in AMODE 64 then the target routine is expected not to rely on that address for use as a base reg unless it first clears bit 63. Yes, an initiator can ATTACH an AMODE 64 program. The target of the EXEC PGM=ATTACH has gotten a 144-byte savearea for over 15 years. <snip> We've adopted "eight bytes of foxes" as an end marker for variable-length parameter lists that use 64-bit pointers </snip> Another oft-used approach is to have the first parameter be the number of parameters that follow. <snip> C also makes a similar assumption, namely that an address greater than that of any object can be used as a list terminator. </snip> No such address in the 64-bit space comes to mind. Unless, as Ed Jaffe pointed out, RSM officially reserves the high page/segment/region of the 64-bit virtual space. It might well already do so. But if you chose you could use the page that is already never mapped in the 31/64-bit virtual space starting at 00000000_7FFFF000. This page works just as well (or just as poorly, depending on your point of view) in AMODE 64 as AMODE 31. Not so well/poorly in AMODE 24. If we subsequently do some work with the nucleus building, we might also unmap the page starting at 00FFF000 so that use of an address of 7FFFF000 as something to blow up upon reference will work regardless of AMODE. Peter Relson z/OS Core Technology Design
