I was trying to avoid too much in the way of specifics without refreshing my
memory, but one function that ISTR as always triggering RMODE(24) [I think it
was 'R' and not 'A'] is certain forms of STREAM I/O. I don't recall which form
it was. The problem, as I recall, is the resident library routine was never
fixed because IBM didn't think there were enough users to be worth the effort.
I do know for a fact, looking at the EPA data, that there are at least 140
CSECTS with names starting with IBM* in the z/OS V1.13 SCEERUN library that are
RMODE(24). These would definitely require that they be loaded into 24-bit space
at run-time. Interestingly, there are no RMODE(24) nor AMODE(24) IBM* components
in SCEELKED that would force a user module to be RMODE(24) at link time. So,
anything forced to 24-bit by the linker/binder would be because of:
* Something the compiler sees that causes it to force 24-bit.
* Some other component besides an IBM* component that is
included in the module.
Sorry, I've already spent more time looking at this than I have time for at the
moment. Maybe more later when I have a bit of extra time.
On Tue, 6 Mar 2012 19:50:23 +0100, Bernd Oppolzer wrote:
> We had 2.3 PL/1 modules in production use for a very long time (until 2006),
> and we always linked them AMODE(31) / RMODE(ANY) - which in fact means RMODE(31).
> The only exception IMO were modules that needed to be linked together with
> AMODE(24) / RMODE (24) ASSEMBLER CSECTs - but that were some very rare
> exceptions; old ASSEMBLER modules, which have not yet been migrated to AMODE/RMODE 31,
> and some vendor software, which was only available in AMODE 24 versions
> at that time.
> Kind regards
>Am 06.03.2012 19:09, schrieb J.G.:
>> C.'s view is mine too. Ass he suggests without quite saying, the combination
>> may well be/have been generated in certain unusual circumstances. I
>> suspect, however, 1) that the two procedures in question are instances
>> of unwise tampering with compiler output and 2) that [re]specifying
>> would be unproblematic. Worth noting is that their inclusion marked
>> RMODE(24) in an executable has the disagreeable consequence of forcing
>> it below the line.