You might want to try disassembling the LE initialization modules beginning at the entry point and follow the logic. Some of the CEE CSECT's are included from SCEELKED while the compiler generates others specific to the module's requirements (e.g., stack storage, application code entry point).
I once ran into a problem where one program linked in a different program's CEESTART (I think it was) which resulted in S0C4's. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Eric Erickson Sent: Tuesday, July 11, 2023 2:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: C DLL abend CEE3350S I know, but the CEESTART CSECT is included in the program object. On another DLL, which is just 1 module with multiple functions, the CEESTART CSECT is listed in the load map as such. 0 CEESTART * CSECT B0 SYSLIB 03 CEESTART In my problem DLL its listed as: A48 CEESTART * CSECT B0 SYSLIB 03 CEESTART Not sure what is going on here. Its my first foray into C DLLs and I wonder if mixing in the C LE Assembler routines is causing an issue? If I don't but the Entry statement into the deck, I get one what looks to be the module with the first alphabetically marked as the entry point. ---------------------------------------------------------------------- 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