Re: compile+link Fujitsu Linux

On Fri, 1 Feb 2008 12:58:23 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:

On Feb 1, 7:49 pm, Robert <n...@xxxxxx> wrote:
On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:

Fujitsu's terminology is pretty
good:

static linking Old School, everything in one executable

Not 'Old School' at all. Old School would be trying to fit everything
in 640Kb, or even 64Kb of CP/M.

That's why CANCEL was created.

dynamic program structure Unix style libraries linked with -l

And the objects are loaded (statically) at start up time, though the
CALLs are not necessarily linked to the routines.

Loading at start up time is faster and safer. You can specify -z lazyload to make it load
libraries when first called.

dynamic link structure Cobol style Load On Demand

Exactly, they are _loaded_ dynamically. The requirement was stated as
being the last: "dynamic linkage" which does dynamic loading. You
should have noticed that the DLOAD directive was used and thus the -l
was inappropriate (see table in manual).

Fujitsu works with DLOAD and dynamic program structure, because dlopen() finds programs
already resident. If the program is NOT resident then it loads from disk. The only
downside is Fujitsu will not CANCEL programs bound at start up time.

If any cannot
be found, the program will not start, which guarantees the program will not abort mid-run
because a called program is missing.

The CALL can check whether it has failed to find the program with an
ON EXCEPTION, or it can be checked for in other ways, there is no need
for the program to abort.

True. How many programs have a graceful fallback? Ok, if called from a menu, they say
'Function not available'.

It would seem to me that Charles' programs may well form an
interactive menu driven application. Gracefull fallback is what these
systems should do.

Makes you wonder why they didn't grey it out.

Perhaps because that would require searching the disk every time the
menu is displayed.

In Micro Focus, one can say SET procedure-pointer TO ENTRY 'MYPROG1'.
If the pointer is null, the program doesn't exist.
Cobol doesn't allow definition of weak externs, so you can either tell ld -z nodefs to
allow undefined symbols, or put MYPROG1 in a variable.

Fujitsu has no equivalent feature. You'd have to call all programs at initialization time
and remember which are invalid.

The problem with dynamic binding in Cobol is that Cobol has no concept of library FILE
NAME, it only knows about entry point names, which are essentially the same as program
names. Thus, Charles' application with "hundreds of COBOL programs", if packaged for
dynamic call, will have HUNDREDS OF LIBRARY FILES, each named libPROGRAM.so.

I am not sure why you think that is a 'problem'.

It is not a problem to me at all, nor to any of my clients.

It complicates deployment, makes the system less reliable and slows execution.

What _evidence_, other than 'researching your keyboard', can you
provide for these unsupported assertions. Certainly a dynamic load
takes a few milliseconds when a menu item is selected, but in what way
would it be 'less reliable' ?

There are more files that can be deleted or overwritten.

Actually, to those that use this, it _simplifies_ deployment,
especially in bespoke systems where I operate. If a single program
requires changes then only that file is tested and redistributed. In
any rational development all deployments would be fully tested. If you
link several programs into one library the all those in the library
need to be retested. If they are all linked to one executable then
everything needs to be retested.

There is no reason to re-test an unchanged program just because it is in the same library
with other programs. You could use the same argument to require re-testing every
application on the machine.

Changes in one program can't cause errors in other programs unless they share global data.
In a rational environment, data is shared between parent and child, not between siblings
and certainly not with stranger programs. You should never make a decision in program A,
store it in an indicator or database, and take action on that decision in program B.
That's bad design.

If you DO make that mistake, putting programs A and B in separate files is no more
protection than putting them in the same library. Even running them on separate machines,
as remote procedures, is no protection.

And the CALL dataname feature is invaluable as it means that the menu
program can use a data file to define what is available in a
particular application, or even to the particular user, and this can
be extended by changing the data file (and issuing the programs)
without changing the menu program at all.

Now you're advocating home-grown security. I've seen hundreds of home-grown security
systems and not one of them was secure. Most can be defeated by editing a cleartext
database or text file.

In any case, this is irrelevant to program load mechanism. The same bad security will work
with dynamic program structure.

'One off' or special programs can be deployed individually and
executed with the application framework by typing their name into the
menu program (given that the user has adequate permissions), there is
no need to redeploy the whole system.

Create a few dummy 'stub' programs for this purpose. Or use versioning, so ONEOFF 1.1 does
one repair and ONEOFF 1.2 does another. See documentation for dlvsym().

As you should be able to tell from the results in charles' 2nd message
your BAD and WRONG advice has meant that his program does not work as
he expected. He statically linked the dynamic library which will cause
the CANCEL to fail to unload it and thus a reload does not find a new
copy but reuses the old.

Wrong. If Cobol issues a dlclose() on libMYSUB1.so, even though it was 'statically' linked
with -l, it will be unloaded .. and reloaded the next time he calls it.

Charles results and my testing show that you are WONG once again.

I said IF Cobol issues a dlclose(). Fujitsu does not. It could.

So, you would agree that your 'Wrong' was Wrong then. Charles and I
both described the results of testing. You said this was 'wrong' on
the basis that it _could_ have been different if Fujitsu did it
differently, but they don't.

I'll give you that win. A hardcore programmer would do it by calling dlclose() and
dlopen() directly from Cobol. :)


.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... Red Hat Linux 7.2, Locale C ... It searches only the libraries named in the executable's ELF ... Why is Cobol the only language with a pressing need for dynamic linking? ... the CANCEL did not work. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... Red Hat Linux 7.2, Locale C ... It searches only the libraries named in the executable's ELF ... Why is Cobol the only language with a pressing need for dynamic linking? ... the CANCEL did not work. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... Red Hat Linux 7.2, Locale C ... It searches only the libraries named in the executable's ELF ... the CANCEL did not work. ... Cobol can, and I believe should, use the normal Unix binding mechanism. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... in memory regardless of CANCEL statements. ... I answered Richard before reading this reply. ... See my comments to Richard about the disadvantage of hundreds of little libraries. ...
    (comp.lang.cobol)