A data-only module has the same restrictions as a code module. You can put it above the bar with either move or directed load. However, you must manage the module/storage yourself. Since there is no CDE any other code that uses the module will have to be provided it's address because the address cannot be obtained by issuing a LOAD for it. No IDENTIFY support.
The interrupts disabled thing was true prior to z/OS 1.13. In 1.13 and above the interrupt handlers/dispatcher save the state properly so this is no longer true. A discussion of AMODE for a data-only module has no value. Chuck Arney Arney Computer Systems Web: http://zosdebug.com Facebook: http://www.facebook.com/arneycomputer -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, August 19, 2015 11:30 AM To: [email protected] Subject: Re: LOADING An AMODE64 Program 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 <[email protected]> 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
