TASKLIB on ATTACH is one reason that pops to mind; given you dont have source code, can you do GTF trace to confirm that ATTACH has occurred? There are probably several similar scenarios possible if not doing TASKLIB.
On Fri, Dec 6, 2019 at 6:49 AM Charles Mills <charl...@mcn.org> wrote: > Program A issues a successful IDENTIFY for entry point ABC and then > transfers control to program XYZ. (I have no source code for nor ability to > fully understand the logic of program XYZ, nor to modify it.) Program XYZ > subsequently invokes entry point ABC but ends up with a new copy loaded > from > STEPLIB rather than using the IDENTIFY entry address. > > Why would that be? > > The documentation for IDENTIFY states that the entry point is always > treated > as RENT. The Services Guide says > > All reenterable modules (modules designated as reenterable using the > linkage > editor) from any library are completely reusable. Only one copy is normally > placed > in the link pack area or brought into your job pack area, and you get > immediate > control of the load module. However, there might be circumstances beyond > your > control that can cause an additional copy to be placed into your job pack > area. The > control program might do this, for example, to preserve system integrity. > > Can anyone elaborate? > > Charles > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
