Oppolzer - Informatik / Blog

Well, Bernd, actually, you cannot run without components from the 'Resident
Library'... This is just one problem with IBM's naming terminology. ;-) The
"Resident Library" is, officially, the name of the library that contains all of
the stubs, etc., that are included via AUTOCALL when a PL/I program is linked.

What you are 'not using' is, officially, the "Shared Library" collection of
"Transient Library" components that would normally be loaded dynamically at
run-time. By creating a "Shared Library" package, you could:

1) Load that package into the LPA and reduce the address
   space requirements in the user Region.

2) Save time at run-time, because the initialization would
   only receive the address of the modules in LPA rather
   than actually loading the components one at a time.

I do believe you may be correct about the EDIT-Directed I/O being the culprit
that forced xMODE(24). Again, there were only certain functions that actually
created a problem for 31-bit. I just don't recall exactly what they were.

Your use of STREAM only for testing is not uncommon. The issue we used to see
was when the PUTs were not removed from the program as they were supposed to be.
Thus, the EPA has an External Analyzer that searches all load modules to find
any use of STREAM I/O. This tool came about when one of our users discovered
some of those debugging comments being generated in production CICS/IMS regions,
but could not identify which of the thousands of transactions had the PUTs still
in the code. It caused a real problem when the PUTs created enough messages to
fill up the output queue. Of course, no one would own up to, "Oh, I guess that
may have been my program..."

C.


On Wed, 7 Mar 2012 08:31:02 +0100, Bernd Oppolzer wrote:

> 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.