Re: compile+link Fujitsu Linux
- From: Richard <riplin@xxxxxxxxxxxx>
- Date: Thu, 31 Jan 2008 20:41:29 -0800 (PST)
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'.
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.
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.
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.
It also allows useful diagnostics to be run before
starting a long batch job.
Unfortuanatly, as you completely failed to notice, it also makes the
program not work correctly and thus _REQUIRING_ disgnostics.
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.
Your advice was BAD, the results of following your advice was WRONG.
When will you accept that you completely fail to understand dynamic
loading ?
A Windows dll works almost exactly the same as a Unix library (.so).
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.
In addition to the advantages given above,
Which are irrelevant.
one
specific to Cobol is non-proliferation of program files, which I'll explain below.
Which is also completely irrelevant.
Dynamic binding is the alternative. A running program can ask the OS to load an additional
library by specifying its FILE NAME. Technically, this is done with a call to dlopen() (or
LoadLibrary() on Windows). The OS first checks to see whether the library is already
loaded in memory, either because it was in the program's own header or because some other
running process is using it. If not, it searches the library path looking for the file
name and loads it. In either case it returns a handle to THE FILE that the program can use
to search for a specific entry point or the file's default entry point (with the dlsym()
function).
Yeah, yeah, _WE_ know all that.
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.
I find that ugly and, from a deployment point of view, clunky and amateurish.
You finding something as 'ugly' is probably a good reason to use it.
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.
How many third-party apps have you seen that came with hundreds of libraries or dlls?
Several, many even.
At run time a dynamic call will look for a file called libNAME.so
along the LD_LIBRARY_PATH, where NAME is that in the CALL, and it will
load that and find the required entry point.
It will first look for the symbol NAME already loaded. If not found THEN it will load
libNAME.so.
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.
Instead of simply assumnming that what you 'know' is everything that
is possible to know you should actually try testing stuff out.
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.
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.
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.
Your grasp of this is tenuous at best. Probably this is because you've
never done it the right way.
Instead of prattling on with more and more misinformation based on
guesswork just try doing this and see what _actually_ happens.
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.
Then listen for cursing from the next
cubicle. :) The reason Windows installers want you to reboot is because they don't have a
reliable way of deleting old dlls they just replaced. The solution is to call FreeLibrary
until it disappears from memory.
With Windows (which is a completely different issue and unrelated to
this topic) there are _two_ problems. The first is that a file cannot
be deleted or overwritten when it is open (Unix with its inode
structure can unlink a file that is open and it will disappear when it
is closed). Thus if a dll is in use, and it remains open, the
replacement must be deferred until it can be guaranteed that it is not
open, such as during a boot.
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.
This discussion is going along exactly as every one with you has:
Robert gives WRONG and/or BAD advise.
I point out it is wrong and show results of testing.
Robert reiterates his BAD and WRONG advice and claims he is right.
I point out where it is wrong and why.
Robert claims I am insulting him and (obviously having researched)
write screeds of irrelevant and obvious material that is mostly
unrelated.
I point out where it is irrelevant and wrong and show results of
testing.
.
- Follow-Ups:
- Re: compile+link Fujitsu Linux
- From: Robert
- Re: compile+link Fujitsu Linux
- References:
- Re: compile+link Fujitsu Linux
- From: Robert
- Re: compile+link Fujitsu Linux
- Prev by Date: Re: help with tables
- Next by Date: Re: compile+link Fujitsu Linux
- Previous by thread: Re: compile+link Fujitsu Linux
- Next by thread: Re: compile+link Fujitsu Linux
- Index(es):
Relevant Pages
|
