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
