Is it possible that for certain environments a special routine has to be
inserted between the PL/1 initialization and the main routine, for example IMS?
This could have been done this way; the address at PLIMAIN+0 is switched to
PLIMAIN+4, there is a routine, that calls the intermediate routine, which, in
turn, calls the PL/1 main routine.
Just an idea ...
That would make the analysis of the real entry of the main routine more
Another question: I had the same problem just last week; is it possible that
with today's EP compilers, the address of the main routine is at PLIMAIN+4, not
at PLIMAIN+0 ? I had the impression. How valid is this approach? I need it only
for main routines, not for DLLs etc.
Am 04.03.2012 14:04, schrieb P.F.:
> On 3/4/2012 5:52 AM, P.D. wrote:
>> Hello all. A plea for help here:
>> I'm presently looking at the load modules belonging to a system with a
>> lot of PL/I, all compiled with V2.3 of the PL/I Optimising Compiler.
>> Mainly I'm able to identify these modules fairly well, but I've run into
>> a few with a nasty (from my point of view) quirk I've not seen before.
>> I should point out that I load the modules into main storage (by
>> emulating the loader) and then "look" into the resulting storage.
>> Anyway, in these modules, the main entry point is CSECT PLISTART. CSECT
>> PLISTART offset x'2C' points to CSECT PLIMAIN. In most cases I've seen,
>> PLIMAIN offset zero points to the "true" entry point for the compiled
>> code. But in these few, PLIMAIN offset 0 points to PLIMAIN offset 4.
>> It's a valid address, and holds an STM instruction (X'90') - so it's odds-on
>> that this is by design!
>> Does anyone know what this stay-in-PLIMAIN structure signifies, and how I
>> can usefully identify which piece of code *really* gets control at run
>> time using a reasonably simple analysis?
> According to the Execution Logic for 3.2, PLIMAIN+4 is supposed to be
> zero, however, PLIMAIN+0 is supposed to always be the address of the
> primary entry point.