🚀 go-pugleaf

I think I solved this puzzle.

In the assembler routine causing the problem, I carelessly specified the csect name in the END
statement even though the assembler program was a called routine and not a main program.
(Apparently it "started out in life" as a main program (during the initial writing and testing)
and evolved into a called subroutine.)    Apparently, the PRELINK step will generate a CEESTART
csect only if none of the other csects processed by the PRELINK had an END statement specifying an
entry point (which makes obvious sense).

----- Original Message -----
From: "William H. Blair" <WmHBlair@houston.rr.com>
To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Sent: Thursday, September 29, 2005 9:38 PM
Subject: Re: Strange prelink phenomenon


> John Krew wrote:
>
>  > and the CEESTART csect is at a nonzero offset within the resultant
> load module.
>
> Do you think this causes any problem? If so, what and why? What is the entry point (address)
assigned to the load module by the binder?
>
> Do the resulting, combined programs (object decks), once bound into a
> load module, actually work successfully? If not, what happens? (Some
> sort of ABEND, such as an S0C1, perhaps?)
>
> What do you think the problem is with the binder including CEESTART from
> SYSLIB? (Or, maybe I'm reading too much into your question.)
>
> Can you reproduce this problem with a small, trivial example? Or is it
> already small and trivial? Can you post the assembler and C source code
> which will exhibit the problem, if so?
>
> Does the "simple C program" invoke any function (SD or LD) in the
> assembler program(s)? In other words, what is the relationship between
> the "simple C program" and the assembler programs? (I assume the "simple
> C program" has a main function which is intended to be the main entry
> point of the load module. Right?)
>
> --
> WB
>