Oppolzer - Informatik / Blog

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.

C.


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
>
> Bernd
>
>
>
>Am 06.03.2012 19:09, schrieb J.G.:
>> C.'s view is mine too.   Ass he suggests without quite saying, the combination
>>
>> AMODE(31)/RMODE(24)
>>
>> 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
>>
>> AMODE(31)/RMODE(31)
>>
>> 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.
>>
>> J.G.