On 2015-08-19, at 08:42, Steve Smith wrote: > Speaking of RMODE 64, I see that HLASM supports it, but the Binder doesn't > on z/OS. So it's unclear if LOAD supports RMODE 64 yet. Assuming support > is added someday, I presume LINK will not. > Does this mean that one can't create a data module to be loaded above-the-bar? One must obtain STORAGE and copy into it? Can one IDENTIFY an address above- the-bar?
> However, assuming the Binder is consistent and requires AMODE 64 on an > RMODE 64 module, LOAD will always return an odd address, although you can't > directly use it for anything! (Based on the assumption that above-the-bar > execution is still not supported). > That matter seems moot if the Binder (or anything else) can't create an RMODE 64 object. If it did, it could still be used for data. A while back I heard in these fora that one could branch to code above- the-bar provided interrupts were disabled; interrupts above-the-bar were lethal. More recently that interrupts are supported, but no (few?) system services can be invoked from above-the-bar. > On Wed, Aug 19, 2015 at 7:47 AM, Peter Relson <rel...@us.ibm.com> wrote: >> >> Might the programmer declare an odd address as an ENTRY for the >> purpose of accessing data at that address? >> This becomes smbiguous with AMODE(64). >> That is an interesting question. I wonder how IBM handled the case. >> >> Yes they might. We chose not to "handle" it. In a word (well, 3 words), >> "don't do that". >> Again, for data, what about RMODE(64) AMODE(24) to avoid overlaying bit 32 (as by AMODE 31) or bit 63 (as by AMODE 64)? The corresponding problem doesn't occur for RMODE(31) because bit 0 of a fullword address is not used for addressing (except to select addressing mode in some branch instuctions.) -- gil
