There is an LE User Handle Function that should allow you to insert what you want to do.
Otherwise, this seems to be a question better for IBM LE to respond to. Lots of knowledge on the lists, but this may wander closer to internal IBM information on how LE would work in this case. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Peter Hunkeler > Sent: Wednesday, December 21, 2016 3:34 AM > To: [email protected] > Subject: Using the Binder to hook into an LE runtime module. > > Cross-posted to IBM-Main and Assembler-List > > This thread is actually about hooking into existing load modules using the > Binder's CHANGE and REPLACE funtions. It's been long time since I had to use > the Binder to manipulate modules, so please bear with me. > > > > A bit of information on why I want to do this is provided for the ones > interested. > > > *However*, the reason for posting is mainly to understand if my idea how to > manipulate load modules using the Binder should work the way I think it does. > > > Please keep this thread related to the subject. Thanks. > > > > > > I'm back to the quest for the code that sets the decimal overflow mask bit in > the PSW causing S0CA abends later on (see "How to Identify modules as C/C++ or > Cobol, or ASM from dump (SYSMDUMP)" thread started late November). > > > Environment is Cobol V4 & V5. All CALLs are dynamic. Some hundred modules may > well be loaded when the problem occurs. Modifying the to help diagnosing is > not an option. > > > I understand that LE has two sections of code dealing with dynamic CALLs: > > o IGZCFCC for pre V5.x Cobol > o IGZXFCA1 for Cobol V5.x and later > > > Those functions are always seen in a LE trackback at point where Cobol code > makes dynamic CALLs. > > > What I'm trying to do is to hook into those functions, and have some of my own > code running before forwarding the call to either IGZCFCC or IGZXFCA1. My code > would make an entry into an instorage wrap around trace table that I could > investigate when the S0CA happens. > > > I found IGZCFCC to be a CSECT in runtime module IGZCPAC, and IGZXFCA1 to be an > ENTRY in CSECT IGZ@DCS2 in load module IGZXLPKA. IGZXFCA1 is being referred to > from a couple of places. > > > > Using the Binder I want to have all references to IGZXFCA1 be redirected to my > code, say #PHUFCA1. The code in #PHUFCA1 has a V-con to IGZXFCA1 so that it > can forward the call later. > > I think I cannot simply CHANGE IGZXFCA1 to #PHUFCA1, because that would also > change the reference to IGZXFCA1 in my own code, and this is not what I want. > I currently think I need three Binder runs as follows: > > > 1. Remove Csect IGZ@DCS2 from IGZXPLKA and at the same time change references > to IGZXFCA1 to #PHUFCA1 by specifying: > > REPLACE IGZ@DCS2 > CHANGE IGZXFCA1(#PHUFCA1) > INCLUDE SYSLIB(IGZXPLKA) > NAME IGZPLKA#(R) > > > and run the binder with NCAL, because some references to labels in IGZ@DCS2 > other than IGZXFCA1 will stay unresolved. SYSLIB is CEE.SCEERUN, SYSLMOD is my > own load library. > > > 2. Extract Csect IGZ@DCS2 from IGZXPLKA: > > REPLACE IGZ@INI2 > ... > REPLACE CEEBINT > INCLUDE SYSLIB(IGZXPLKA) > NAME IGZ@DCS2(R) > > > One REPLACE for each Csect in IGZXPLKA, except from IGZ@DCS2. > Again run with NCAL and libraries as in step 1. > > > > 3. Create new IGZXPLKA including my code in the ASMACL job: > > INCLUDE SYSLIB(IGZXPLK#) from step 1 > INCLUDE SYSLIB(IGZ@DCS2) from step 2 > object deck from the assembly creating #PHUFCA1 NAME IGZXPLKA(R) > > > SYSLIB and SYSLMOD is my own load library. > > > > I'm not getting the desired result. I'm getting abends before my code is > invoke, so I be missing something or missinterpreting how the binder works. > > -- > Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
