Oppolzer - Informatik / Blog

Maybe, but this was not a problem in our case, because stream I/O was forbidden
on our site due to site regulations (only allowed in test environment, had to be
switched off in last compile before transport into production). And the forms we
used in test never had such a problem.

(the problematic forma could have been some variants of PUT SKIP EDIT or PUT
with implicit loops, because we never used these forms - people just didn't know
about them)

The forms of stream I/O we used in test didn't make use of the resident library,
so the modules could reside above, anyway.

Kind regards

Bernd



Am Dienstag, 6. März 2012 21:13 schrieben Sie:
> 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.
>