Re: [open-cobol-list] PROGRAM-ID, source name and entry points

[Roger While]

Sergey,
The renaming is rather interesting. I did not realize the implications
here. For MF, this only applies when creating ".int" or ".gnt" modules
as presumably, they carry extra info. It does not work when creating
".so" modules (cob -z, for MF SE, not available for Object Cobol)

IF we would want to support your "CALL 'D'" scenario, how would we
specify the "default" entry to the runtime?

Yes, of course, when a module is actually loaded, all it's entry points
become known.

(Incidentally, have implemented COB_PRE_LOAD environment variable;
 more when I post CVS update notification).

Roger

> Roger,
>
> > Question is what, if anything, should we be doing here ?
>
> I don't think it's critical if we should do anything at all, but that what 
> MFocus is doing:
> At the compile time if P-ID != surce file name (all converted to 
> uppercase), it inserts both names in export list.
> In runtime, it's looking for the filename of the CALL statement (.gnt or 
> .dll or ... depending on platform) and than it's looking for the entry 
> point with the same name.
> If it  doesn't find it, it calls the first one (ignoring the name at all).
> After that ALL the names of this module became known for runtime.
> i.e. I'm compiling program A.cbl with program id B and additional entry C.
> I'm renaming the resulting A.dll into D.dll.
> Than I'm doing CALL "D" from the main program.
> After that, the entry points A,B,C and D will be known for runtime so the 
> subsequent CALLs to A,B and D will call the same primary entry of the 
> program and CALL "C" will call additional entry point.
> You can't compile the program which has ENTRY with the name of source file.
>
> Regards,
> Sergey
>
> ----- Original Message ----- From: "Roger While" <address@hidden>
> To: <address@hidden>
> Cc: <address@hidden>
> Sent: Sunday, January 29, 2006 3:15 AM
> Subject: [open-cobol-list] PROGRAM-ID, source name and entry points
>
>
> > When calling a program for the first time either
> > explicitly with "CALL" or implicitly with a driver
> > program (MF - cobrun, ACU - runcbl, OC - cobcrun),
> > the runtime system tries to locate a loadable module
> > with this name plus an extension (MF - .so, .int, .gnt;
> > ACU - .out; OC .so).
> > The runtime system then tries to locate an entry point
> > within this module with the respective name.
> > The default entry point of a program is the PROGRAM-ID
> > (After accounting for AS clause, numeric first character,
> >  non-printable characters, etc).
> >
> > Let's consider an actual example from the Cobol85 test
> > suite - NC127A.CBL
> > This is a program that is all lower case except for
> > required literals. This includes the PROGRAM-ID
> > which is nc127A.
> > (Hmm, Why isn't the 'A' lower case ?)
> >
> > What MF and ACU (per default options) do is to fold
> > the PROGRAM-ID to upper case.
> > (Which is not what the MF SE doc says!)
> > And therefore module name = entry point.
> >
> > OC does not do this so that attempting a
> > "cobcrun NC127A" leads to "entry not found".
> >
> > Question is what, if anything, should we be
> > doing here ?
> >
> > One possibility would be to insert the module
> > name as an entry point if != P-ID and != ENTRY.
> > Another would be to (optionally) fold the P-ID.
> >
> > Note we could have a completely different P-ID/ENTRY,
> > eg in the OC tests where we have a "callee" program with
> > P-ID "hello" and an ENTRY "bye".
> >
> > Thoughts ?
> >
> > Roger