Xref: utzoo comp.software-eng:2687 comp.misc:7692
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!eru!luth!sunic!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Linkers
Message-ID: <563@enea.se>
Date: 17 Dec 89 01:14:25 GMT
References: <530@enea.se) <7226@ficc.uu.net) <547@enea.se> <7277@ficc.uu.net>
Organization: Enea Data AB, Sweden
Lines: 75

Peter da Silva (peter@ficc.uu.net) writes:
>> )In which case the routine would be referenced in the *database*, and so
>> )would be linked in.
>
>> Eh? You link relational databases with your executeable?
>
>Database != relational database. In this case it just means a table of
>function names and locations.

Peter, if you think you are clairvoyant, I've bad news for you.
There is something disturbing your reception. I introduced this
thread, including the database. So maybe you should try to under-
stand what I'm talking about instead of deciding that on your own.
The database I'm talking of is an RDB database, and last time I
look R stood for relational. That it is relational is beside the
point, but point is that does not conatin any information on function 
locations.

In short: the thing is a generic menu handler. The user enters a
code or a number which is looked up the database. What you get is
the *name* of the function to call. You also get some information
what access rights the user has to this particular function.
The menu handler then calls function which is application specific.
  The menu handler has it own set of menues for maintenance. For
adding or modifying users, but also to add or modify function entries.
For instance if there is a function which only one customer have
paid for, only in the menu database for that customer that function
is availble. The others have it in the executeable, but cannot access
it. (Unless they know the name of function in which case they add
it. That is less likely with our crude name standards.)

>> To make it simple, you link both routines with your executeable,
>> and the contents in the menu databases at the customer site decide
>> which variant they will run.
>
>Say what? You have an external relational database containing absolute
>addresses in your executable? What happens when you want to ship them a
>new version of the program? They have to rebuild the database?

No. Who said that were any absolute addresses in the database, Peter?
Certainly not me. You made that up yourself. I even told the trick
in my first article, and I have mentioned it before. But let's take 
it again:

    Routine PIC X(32).
    ...
    CALL Routine USING ...

If you didn't recignize it, this is Cobol. Peter is probably stuck in
C thinking, thereof his talk of absolute addresses. Anyway, Routine is
a string variable, into which we load the contents of the database entry.
Then we call the function with the name Routine contains. If there is
no such routine (on VMS at least this has to be another Cobol procedure) 
we get a run-time error. (Which is handled by the menu handler.)

Yes, somewhere there is a coupling function name <-> address, but
that is handled by the Cobol compiler and the Cobol run-time library.

My original comment to the linker discussion was that the menu
handler wouldn't work with a linker that removed unreferenced
modules, since the routines called by the menu handler are neiher
compile-time nor link-time references, but run-time references
and beyond the linker's horizon.
  Of course this doesn't mean that a linker shouldn't be allowed
to remove unreferenced routines, but that you need a mechanism
to tell such a linker that it should include a routine no matter
whether it's referenced or not.

(Some people may question the wise of making everything one big
executeable, as we do. We are heading for a better solution.
We're making every function a shareable image of its own to 
be activated by LIB$Find_image_symbol. This means that the
main executeable will only be the menu handler.)
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Mail me your votes on comp.lang.cobol.