Re: compile+link Fujitsu Linux

On Feb 1, 7:49 pm, Robert <n...@xxxxxx> wrote:
On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Feb 1, 4:23 pm, Robert <n...@xxxxxx> wrote:
On Thu, 31 Jan 2008 11:47:51 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Jan 31, 7:23 pm, Robert <n...@xxxxxx> wrote:
On Wed, 30 Jan 2008 20:46:28 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Jan 31, 4:38 pm, Robert <n...@xxxxxx> wrote:
when I try to execute I see my first DISPLAY and then it crashes:
BEGIN MYMAIN
cobol-rts:: HALT: JMP0015I-U [PID:0000763D TID:002516C0] CANNOT CALL
PROGRAM 'MY
SUB1'. ./MYMAIN: undefined symbol: MYSUB1 PGM=MYMAIN
Aborted

I am running on Red Hat Enterprise, and Fujitsu support say they will
only support:
* Red Hat Linux 7.2, Locale C
* Red Hat Linux 7.3, Locale C
* Red Hat Linux Advanced Server 2.1, Locale C

I am hoping that someone here has figured out how to compile and line
on less ancient versions of Linux.

Try '-l MYSUB1' (lower case el) on the compilation of MYMAIN. As written, MYMAIN has no
way of knowing the library name.

I think that you fail to understand what 'Dynamic Load' means.

There is no Cobol syntax to specify a library name. You can only specify an entry point
name. When you do a CALL, Unix doesn't search every library in the library path. That
would be hopelessly slow. It searches only the libraries named in the executable's ELF
header.

Libraries normally contain many programs and entry points. They are not one-for-one like
the example here.

[the usual insults snipped]

As usual you think that pointing out where you are wrong and
correcting you is an 'insult'.

No, I think name calling is insulting.

With Fujitsu Cobol the DLOAD directive tells the system that CALLs
might be dynamic. In these cases there is no need for the library
containing the called routine to be known to the ELF binary, there is
no need for a -l, nor for the library to even exist at link (ld) time.

Normal Unix binding, outside Cobol, is to enter the names of called libraries in the
executable's header, using -l . Doing so does NOT mean they are statically linked as the
term is understood by mainframers and others from the Old School. It means the library
files will be loaded (if not already in memory) when the executable starts.

I have no idea what "mainframers and others from the Old School" may
understand, but if the library is loaded when the application starts
then it is not 'dynamic' as was required by Charles.

You are confusing people with the term 'static linking'.

You may be confused, even though you used the term yourself, but what
evidence do you have that anuone else is ?

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.

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.

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).


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.

If there is a requirement to ensure that the libraries do exist at
start of run, then yes, you can statically link them, or do an initial
CALL, but that was _NOT_ the stated requirement, you were, as usual,
answering the wrong question.

The requirement is to have dynamic loading.

Why is Cobol the only language with a pressing need for dynamic linking? Huge bodies of
code written in C and other languages get by without it.

Why do you think that "Cobol is the only language" ? I use several
that also do dynamic loading. I have even done dynamic loading in C.
You seem rather limited.


As Charles discovered, when you link in a shared library it prevents
the CANCEL working. I tested this by taking the working set of
Charles's programs and adding a -l to the ld. The test then showed
the CANCEL did not work. Removing the -l and retesting showed the CALL
and CANCEL to work correctly.

The NETCobol for Linux User's Guide says the same in Chapter 7.

I am pleased to see that you are doing some research even if it is
rather belated.


Cobol can, and I believe should, use the normal Unix binding mechanism. There are several
advantages and no good reason not to.

There are some _VERY_GOOD_ reasons why dynamic loading is used. The
fact that you don't understand them does not mean they are not
entirely valid.

CANCEL was created in the days of limited memory, same as overlays. Cobol dropped overlays
when they were no longer needed. It should have dropped CANCEL at the same time.

Many would disagree with you.

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' ?

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.

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.

'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.

It would be cleaner to
package his hundreds of programs into one or a few libraries that are linked to the main
executable.

Only if you fail to understand why dynamic loading is used and the
advantages it bestows on the system.

The advantage disappeared when we broke the 640K barrier.

Showing once again that you fail to understand why dynamic loading is
used and the
advantages it bestows on the system.


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.

You would have to agree that are testing results are 'RIGHT' then.


Instead of simply assumnming that what you 'know' is everything that
is possible to know you should actually try testing stuff out.

Fair enough. If this gets any deeper, I'll install Fujitsu for Linux.

Wow, forcing you into a situation where you actually test something.
You must have gone past repeating the misinformation more than 3 times
then.


If it is packaged in a library with a hundred other programs, the whole library might be
unloaded, because the handle for NAME is the handle for libMYSUBS.so. Or Fujitsu might be
smart enough to know it wasn't dynamically loaded. If he really needs initial values, he
should use the Cobol INITIAL clause.

A CANCEL is not just for regaining initial values, it also frees the
memory. But not only that it caters for a fresh copy to be loaded.
Actual dynamic is dynamic. I can put a new version of a program into
the directory, get the main program to CANCEL and CALL and the new
code will be running.

I reload with four keystrokes: esc, ctrl-P, Enter.

But that (presumably) reloads the whole application. How inefficient.


Incidentally, CANCEL is not guaranteed to unload the program your way, either. A
dynamically loaded library can only be unloaded when its user count is zero. If another
developer happens to be using the same called program, CANCEL will fail, and Cobol has no
way of checking for that.

Geez, Robert, don't you _EVER_ test anything before spouting out what
will or will not happen ?

I just ran a test here to confirm what _I_ expected to happen based on
a few decades of using actual dynamic loading in Cobol.

What you completely failed to notice is that the _data_area_ is not
part of the library, but is created in the main program run-unit. When
the CANCEL is done the data areas created in the run-unit are dumped,
a subsequent CALL will recreate a new set of data areas regardless of
whether the code area still exists in a loaded library or a new
library has to be loaded.

That's not under the control of Unix. If Fujitsu does that, why doesn't it free the data
area of a dynamic program structure the same way?

Ask them.

In fact I just ran another test. I started one program until it
CALLed the subroutine. I then on another console changed the source to
add a display, recompiled and ran a 2nd copy. It loaded a new version
even though the first was still in the middle of the subroutine.
Running through the CANCEL and CALL on that loaded the new routine
exactly as _I_ expected.

That's not normal Unix behavior. I'd need hands-on to figure out why it loaded a second
copy.

Exactly. Your guesses were just misinformation.

Your grasp of this is tenuous at best. Probably this is because you've
never done it the right way.

My grasp is based on writing large make files and knowledge of Unix internals.

Which didn't address the area under discussion at all it seems.


If you want to be hackerish, issue the CANCEL 100 times. Each
call to dlopen() subtracts 1 from the user count.

Geez, Robert, when you are WRONG you do it in spades. The main program
can only reduce the user count if it is _still_connected_ to the
library. The first CANCEL causes a disconnect and the rest do nothing
at all.

Unix doesn't know who is connected to a shared library. All it knows is the user count.

What you also failed to notice that you got WRONG with your assertion
is that it isn't "dlopen(name)" that "subtracts 1", that would add 1.
It is dlclose(handle) that would subtract and the handle would be
destroyed by the dlclose() (ie it would be disconnected) and a
subsequent dlclose() would be with an invalid handle.

As I say, you get some things wrong in spades.


Perhaps Fujitsu ignores CANCEL on a program that doesn't have a data segment.

The second problem is that a dll in memory will be used in preference
to loading from disk. The FreeLibrary may make it disappear from
memory, but that is irrelevant to this topic.

Not if the dll is 'bound'.

.

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 ... I have used dynamic loading of Cobol with mainframes, ...
    (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
    ... That's why CANCEL was created. ... libraries when first called. ... Fujitsu works with DLOAD and dynamic program structure, ... be extended by changing the data file ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... Red Hat Linux 7.2, Locale C ... There is no Cobol syntax to specify a library name. ... It searches only the libraries named in the executable's ELF ... Libraries normally contain many programs and entry points. ...
    (comp.lang.cobol)
Loading