I've got a bit of an interesting situation here. I have built a C DLL which is working just fine. Now I needed to add a couple of LE C Assembler routines to it in order to access a Log Stream service routine we've written. But as soon as I add the first assembler routine, which uses EDCPRLG for the entry code, trying to call any routine in the DLL results in a CEE3350S Abend. When looking at the DLL I can see that CEESTART is not set as the Entry Point, its set to the first of my EDCPRLG Assembler modules with the lowest name (according to standard collating sequence).

CEE3550S DLL XXXUTILS does not contain a CEESTART CSECT.
If I don't include any of my Assembler routines in the DLL then the binder sets the CEESTART as the entry point. When I do include any of the Assembler routines, which use EDCPRLG as its entry code, then the one that ends of first in the sort order of names becomes the entry point instead of CEESTART. For example, if I have the following routines: XXXCLOGR - Assembler with EDCPRLG entry code XXXCUTIL - LE C Code XXXLOGR - Assembler code - no EDCPRLGXXXCLOGR gets set as the entry pointIf the routines areXXXCUTIL - LE C Code XXXLOGR - Assembler code - no EDCPRLGthen CEESTART gets set as the entry point. Obviously, I need all the routines, as the CLOGR is the interface between CUTIL and LOGR (CUTIL->CLOGR->LOGR)When I include the assembler routines that don't have EDCPRLOG then CEESTART gets set as the entry point.

I tried adding an ENTRY CEESTART to the binder instructions and that sets the entry point, but does not resolve the CEE3350S abend on the first call.

I can see that CEESTART is included in the load module, so I'm totally confused as to what is going on here.

hi Eric,

Could you help clarify, are you trying to create a DLL, but it also seems you want to have a startup routine in the DLL, which implies a main entry point ("main" in C/C++ terms). Those two are contradictory. If this is intended as a pure DLL (a library that is called from other modules or libraries), then CEESTART is not needed. If it is intended as a main program itself, then it should not be a DLL itself, though of course it use the DLL option to enable using DLL's.  Without the binder options, we can't tell if you are trying the latter or the former.

thanks

I've got a bit of an interesting situation here. I have built a C DLL which is working just fine. Now I needed to add a couple of LE C Assembler routines to it in order to access a Log Stream service routine we've written. But as soon as I add the first assembler routine, which uses EDCPRLG for the entry code, trying to call any routine in the DLL results in a CEE3350S Abend. When looking at the DLL I can see that CEESTART is not set as the Entry Point, its set to the first of my EDCPRLG Assembler modules with the lowest name (according to standard collating sequence).

CEE3550S DLL XXXUTILS does not contain a CEESTART CSECT.
If I don't include any of my Assembler routines in the DLL then the binder sets the CEESTART as the entry point. When I do include any of the Assembler routines, which use EDCPRLG as its entry code, then the one that ends of first in the sort order of names becomes the entry point instead of CEESTART. For example, if I have the following routines: XXXCLOGR - Assembler with EDCPRLG entry code XXXCUTIL - LE C Code XXXLOGR - Assembler code - no EDCPRLGXXXCLOGR gets set as the entry pointIf the routines areXXXCUTIL - LE C Code XXXLOGR - Assembler code - no EDCPRLGthen CEESTART gets set as the entry point. Obviously, I need all the routines, as the CLOGR is the interface between CUTIL and LOGR (CUTIL->CLOGR->LOGR)When I include the assembler routines that don't have EDCPRLOG then CEESTART gets set as the entry point.

I tried adding an ENTRY CEESTART to the binder instructions and that sets the entry point, but does not resolve the CEE3350S abend on the first call.

I can see that CEESTART is included in the load module, so I'm totally confused as to what is going on here.