i would Look if the c Program is Compiled with the Rent Option enabled. If so, simply calling at CEESTART will not Work.
Kind regards Bernd --- Original-Nachricht --- Von: Brian Chapman Betreff: Re: deduce program language Datum: 02.10.2019, 16:27 Uhr An: [email protected] @font-face { font-family: telegrotesk-medium_normal; src: url("file:///android_asset/fonts/telegrotesk_normal.ttf");}html,body { font-family: "telegrotesk-medium_normal"; font-size: medium; color: #4b4b4b; width: 100%;} Don, Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I guess I need to dig deeper. With all of my test with COBOL and Assembler have been successful. However, it always abends when I intercept a C program; usually with the CEE3550 message. Occasionally it is a 0C4 in the intended program. Does LE have stricter requirements with CEESTART in C programs? Thank you, Brian Chapman On Tue, Oct 1, 2019 at 1:23 PM Don Poitras <[email protected]> wrote: > In article <CA+oOHRgTC_6bbFLib5c5d8rArQbHs= > [email protected]> you wrote: > > I created a trace facility to intercept external interface calls (MQ, > DB2, > > IMS, etc) and dynamic calls. > > For dynamic calls, I intercept the load request and replace the entry > point > > address with an entry point address of my own program. I then save the > > original entry point address to later branch to the intended program. The > > interception works for assembler and COBOL programs, but it fails for C > > programs. When intercepting a C program, the process abends with a 4038 > > (CEE3550S The DLL cannot be loaded because it does not contain a > CEESTART > > CSECT). > > Is there a write-up on how the program load point is mapped and how to > > deduce the loaded program's language? > > I hoped to clone my assembler intercept program and create a second copy > > that includes the CEESTART macro to resolve this issue. However, I read > > that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an > > assembler program because it will produce unpredictable behavior. Must I > > write a C program? > > Thank you, > > Brian Chapman > > I'm not sure how COBOL is working for you as it's an LE program the same > as C, but perhaps you're not using standard LE DLL's for your COBOL > programs. CEESTART is not a macro, it's a module/CSECT that gets linked > from the LE bind library when you compile an LE program or DLL. It's > always linked as the entry point as that's where the WSA is allocated > and other housekeeping before the user code is called (either main() or > the DLL function). LE doc is kind of spread all over the place, but > for writing an assembler front-end as you're doing, I think the LE > Vendor Interfaces book is something you should look at. > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/abstract.htm > > -- > Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive > [email protected] (919) 531-5637 Cary, NC 27513 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ------------------------------------------------------------------------ Gesendet mit der Telekom Mail App <https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
