AW: Re: deduce program language
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: IBM-MAIN@listserv.ua.edu
@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 wrote:
> In article t1cmgbfaka497yhff...@mail.gmail.com> 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
> sas...@sas.com (919) 531-5637 Cary, NC 27513
>
> --
> 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
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: deduce program language
> Does LE have stricter requirements with CEESTART in C programs? It might. That's what you are seeing. Or it might just be something about your particular C program. LE is a little bit of a thing of mystery. Despite the "vendor interfaces" book, it is not designed such that it is one big generally usable programming interface. LE works as a library and so forth for the supported languages, generally fairly well. Beyond that you are on your own. BTW, be sure to test C++ as well. LE C++ is quite different "under the covers" from C. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Chapman Sent: Wednesday, October 2, 2019 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: deduce program language 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: deduce program language
I've only written LE programs in C and assembler. I would have guessed that COBOL had the same requirements for DLLs having the CEESTART entry point, but it's not something I've looked into. Sorry. Tom Ross can answer if he sees this. In article you wrote: > 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 wrote: > > In article > t1cmgbfaka497yhff...@mail.gmail.com> 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 sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: deduce program language
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 wrote: > In article t1cmgbfaka497yhff...@mail.gmail.com> 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 > sas...@sas.com (919) 531-5637Cary, NC 27513 > > -- > 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
Re: deduce program language
In article 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 sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
deduce program language
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
