Cobol - compile+link Fujitsu Linux

Author

compile+link Fujitsu Linux

charles.goodman@bell.ca

2008-01-30, 6:56 pm

I am evaluating Fujitsu NetCOBOL for Linux.
I am having problems getting CALL/CANCEL to work.
Here are two simple programs, first the main program then the called
program:

IDENTIFICATION DIVISION.
PROGRAM-ID. MYMAIN.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 ACPT PIC X.
PROCEDURE DIVISION.
OPEN-PARA.
DISPLAY "BEGIN MYMAIN".
CALL 'MYSUB1'.
DISPLAY "THE END - ACCEPTING ONE BYTE".
ACCEPT ACPT.
STOP RUN.

IDENTIFICATION DIVISION.
PROGRAM-ID. MYSUB1.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 ACPT PIC X.
PROCEDURE DIVISION.
OPEN-PARA.
DISPLAY "BEGIN MYSUB1 - ACCEPTING ONE BYTE".
ACCEPT ACPT.
EXIT PROGRAM.

The two source programs are saved as MYMAIN.CBL and MYSUB1.CBL.
We want dynamic linkage since our real application consists of dozens
of C programs and hundreds of COBOL programs.

I tried compiling with:
cobol -M -dy -WC,"BINARY(BYTE),DLOAD" -o MYMAIN MYMAIN.CBL
cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB1.so MYSUB1.CBL

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.

---Charlie

Robert

2008-01-30, 9:57 pm

On Wed, 30 Jan 2008 15:00:14 -0800 (PST), charles.goodman@bell.ca wrote:

>I am evaluating Fujitsu NetCOBOL for Linux.
>I am having problems getting CALL/CANCEL to work.
>Here are two simple programs, first the main program then the called
>program:
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. MYMAIN.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 ACPT PIC X.
> PROCEDURE DIVISION.
> OPEN-PARA.
> DISPLAY "BEGIN MYMAIN".
> CALL 'MYSUB1'.
> DISPLAY "THE END - ACCEPTING ONE BYTE".
> ACCEPT ACPT.
> STOP RUN.
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. MYSUB1.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 ACPT PIC X.
> PROCEDURE DIVISION.
> OPEN-PARA.
> DISPLAY "BEGIN MYSUB1 - ACCEPTING ONE BYTE".
> ACCEPT ACPT.
> EXIT PROGRAM.
>
>The two source programs are saved as MYMAIN.CBL and MYSUB1.CBL.
>We want dynamic linkage since our real application consists of dozens
>of C programs and hundreds of COBOL programs.
>
>I tried compiling with:
>cobol -M -dy -WC,"BINARY(BYTE),DLOAD" -o MYMAIN MYMAIN.CBL
>cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB1.so MYSUB1.CBL
>
>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. Also, make sure your current directory is in
LD_LIBRARY_PATH, either as .: or explicitly.

Richard

2008-01-31, 3:55 am

On Jan 31, 12:00 pm, charles.good...@bell.ca wrote:
> I am evaluating Fujitsu NetCOBOL for Linux.
> I am having problems getting CALL/CANCEL to work.
> Here are two simple programs, first the main program then the called
> program:
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. MYMAIN.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 ACPT PIC X.
> PROCEDURE DIVISION.
> OPEN-PARA.
> DISPLAY "BEGIN MYMAIN".
> CALL 'MYSUB1'.
> DISPLAY "THE END - ACCEPTING ONE BYTE".
> ACCEPT ACPT.
> STOP RUN.
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. MYSUB1.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 ACPT PIC X.
> PROCEDURE DIVISION.
> OPEN-PARA.
> DISPLAY "BEGIN MYSUB1 - ACCEPTING ONE BYTE".
> ACCEPT ACPT.
> EXIT PROGRAM.
>
> The two source programs are saved as MYMAIN.CBL and MYSUB1.CBL.
> We want dynamic linkage since our real application consists of dozens
> of C programs and hundreds of COBOL programs.
>
> I tried compiling with:
> cobol -M -dy -WC,"BINARY(BYTE),DLOAD" -o MYMAIN MYMAIN.CBL
> cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB1.so MYSUB1.CBL
>
> 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 tried that and it worked fine on my machine.

All it seems to need is the directory where the .so is located to be
on the LS_LIBRARY_PATH

Either add this to the LD_LIBRARY_PATH (eg:

LD_LIBRARY_PATH=./:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH
MYMAIN

or put the .so into one of the directories in that list.

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

I have no problem on Mandrake.

Richard

2008-01-31, 3:55 am

On Jan 31, 4:38 pm, Robert <n...@e.mail> wrote:
> On Wed, 30 Jan 2008 15:00:14 -0800 (PST), charles.good...@bell.ca wrote:
>
>
>
>
>
>
>
>
> 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.

> Also, make sure your current directory is in
> LD_LIBRARY_PATH, either as .: or explicitly.

Yes, it does need that.

Robert

2008-01-31, 3:55 am

On Wed, 30 Jan 2008 20:46:28 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Jan 31, 4:38 pm, Robert <n...@e.mail> wrote:

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

charles.goodman@bell.ca

2008-01-31, 6:56 pm

Thanks for the tips.
Yes I needed to add my curent directory to LD_LIBRARY_PATH
I also nneded to add "-L./" to the cobol command to compile the main
program.
My compile commands, that work are:
cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB1.so MYSUB1.cbl
cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB2.so MYSUB2.cbl
cobol -M -dy -WC,"BINARY(BYTE),DLOAD" -o MYMAIN -L./ -lMYSUB1 -lMYSUB2
MYMAIN.cbl

I am able to compile and execute. My simple programs are designed to
allow me to see the functioning of CALL and CANCEL.....

However the results is NOT exactly what I want. Using -l does not
allow for proper functioning of the CANCEL verb (see pg 77 of user's
guide). Once a subprogram is loaded with a CALL statement, it remains
in memory regardless of CANCEL statements. The working-storage of the
sub-program is not reinitialized upon a second CALL.

---Charlie

Richard

2008-01-31, 9:56 pm

On Feb 1, 6:48 am, charles.good...@bell.ca wrote:
> Thanks for the tips.
> Yes I needed to add my curent directory to LD_LIBRARY_PATH
> I also nneded to add "-L./" to the cobol command to compile the main
> program.
> My compile commands, that work are:
> cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB1.so MYSUB1.cbl
> cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB2.so MYSUB2.cbl
> cobol -M -dy -WC,"BINARY(BYTE),DLOAD" -o MYMAIN -L./ -lMYSUB1 -lMYSUB2
> MYMAIN.cbl
>
> I am able to compile and execute. My simple programs are designed to
> allow me to see the functioning of CALL and CANCEL.....
>
> However the results is NOT exactly what I want. Using -l does not
> allow for proper functioning of the CANCEL verb (see pg 77 of user's
> guide). Once a subprogram is loaded with a CALL statement, it remains
> in memory regardless of CANCEL statements. The working-storage of the
> sub-program is not reinitialized upon a second CALL.

Robert is completely wrong. You do not need a -l or a -L. These will
turn the CALLs into a static load and, as you say, the CANCEL will not
work as expected.

Go back to using your original compiles and links _without_ the -l or -
L.
It was only the LD_LIBRARY_PATH change that was required.

I am not sure how you determined that the CANCEL did not work but I
modified your programs to add a 2nd CALL and a CANCEL followed by a
3nd CALL in MYMAIN and then added a check for 'first time in' into
MYSUB1 and it worked as _I_ expected.

IDENTIFICATION DIVISION.
PROGRAM-ID. MYMAIN.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 ACPT PIC X.
PROCEDURE DIVISION.
OPEN-PARA.
DISPLAY "BEGIN MYMAIN".
CALL 'MYSUB1'.
CALL 'MYSUB1'.
CANCEL 'MYSUB1'.
CALL 'MYSUB1'.
DISPLAY "THE END - ACCEPTING ONE BYTE".
ACCEPT ACPT.
STOP RUN.

IDENTIFICATION DIVISION.
PROGRAM-ID. MYSUB1.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 ACPT PIC X.
01 FIRST-IN PIC X VALUE "Y".
PROCEDURE DIVISION.
OPEN-PARA.
IF FIRST-IN = "Y"
DISPLAY "First Time In"
ELSE
DISPLAY "Been here before"
END-IF
MOVE "N" TO FIRST-IN

DISPLAY "BEGIN MYSUB1 - ACCEPTING ONE BYTE".
ACCEPT ACPT.
EXIT PROGRAM.

As expected I got (ignoring your displays and accepts):

First Time In
Been here before
First Time In

So the CANCEL worked exactly as it should.

Richard

2008-01-31, 9:56 pm

On Jan 31, 7:23 pm, Robert <n...@e.mail> wrote:
> On Wed, 30 Jan 2008 20:46:28 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
> 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.

Robert, you really should try to understand the problem and its
solution _before_ you show your complete lack of understanding of what
is happening.

I had already said that the code and compiles as given in the first
message _worked_ on my machine and that the only change required was
to the LD_LIBRARY_PATH which is the environment variable used for
_dynamic_ loads.

I had actually compiled and ran these programs to ensure that what I
said was correct and that I was not giving bad or wrong advice. I had
indicated, gently, to you that you were not on the right track.

I have used dynamic loading of Cobol with mainframes, with Micro Focus
since CIS Cobol, on RM, Fujitsu and others since the days of CP/M and
with Unix, DOS, Windows and Linux. I have even done dynamic loading
with C.

You have made several claims above which are FACTUALLY WRONG and show
that you, as I said before, completely fail to understand dynamic
loading, or even that it is possible.

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.

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.

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.

Robert

2008-01-31, 9:57 pm

On Thu, 31 Jan 2008 11:47:51 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Jan 31, 7:23 pm, Robert <n...@e.mail> wrote:

[the usual insults snipped]
[color=darkred]
>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. 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. It also allows useful diagnostics to be run before
starting a long batch job.

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. In addition to the advantages given above, one
specific to Cobol is non-proliferation of program files, which I'll explain below.

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

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 find that
ugly and, from a deployment point of view, clunky and amateurish. It would be cleaner to
package his hundreds of programs into one or a few libraries that are linked to the main
executable.

How many third-party apps have you seen that came with hundreds of libraries or dlls?

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

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.

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. If you want to be hackerish, issue the CANCEL 100 times. Each
call to dlopen() subtracts 1 from the user count. 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.

Robert

2008-01-31, 9:57 pm

On Thu, 31 Jan 2008 09:48:48 -0800 (PST), charles.goodman@bell.ca wrote:

>Thanks for the tips.
>Yes I needed to add my curent directory to LD_LIBRARY_PATH
>I also nneded to add "-L./" to the cobol command to compile the main
>program.

-L is used to override the user's LD_LIBRARY_PATH. It shouldn't be necessary on your own
machine.

>My compile commands, that work are:
>cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB1.so MYSUB1.cbl
>cobol -dy -shared -WC,"BINARY(BYTE)" -o libMYSUB2.so MYSUB2.cbl
>cobol -M -dy -WC,"BINARY(BYTE),DLOAD" -o MYMAIN -L./ -lMYSUB1 -lMYSUB2
>MYMAIN.cbl
>
>I am able to compile and execute. My simple programs are designed to
>allow me to see the functioning of CALL and CANCEL.....
>
>However the results is NOT exactly what I want. Using -l does not
>allow for proper functioning of the CANCEL verb (see pg 77 of user's
>guide). Once a subprogram is loaded with a CALL statement, it remains
>in memory regardless of CANCEL statements. The working-storage of the
>sub-program is not reinitialized upon a second CALL.

I answered Richard before reading this reply. Failure of the CANCEL means Fujitsu figured
out the library (.so) had not been dynamically loaded, so did not issue a dlclose(). If
you want the program initialized every time, use the INITIAL clause on PROGRAM-ID.

See my comments to Richard about the di

vantage of hundreds of little libraries.

Richard

2008-02-01, 3:55 am

On Feb 1, 4:33 pm, Robert <n...@e.mail> wrote:
> On Thu, 31 Jan 2008 09:48:48 -0800 (PST), charles.good...@bell.ca wrote:
>
> -L is used to override the user's LD_LIBRARY_PATH. It shouldn't be necessary on your own
> machine.

Geez, Robert, yet more misinformation. You are _WRONG_ yet again. ld
does _NOT_ follow the LD_LIBRARY_PATH. It follows the LIBPATH. You can
add the current directory to LIBPATH or use the -L _IF_ you want to
link the dynamic libraries statically.

I actually ran a _test_ (you may want to look up what this word might
refer to) by adding the -l MYSUB1 without the -L while having the
LD_LIBRARY_PATH. As I expected it failed, just as Charles reported.

>
>
>
> I answered Richard before reading this reply. Failure of the CANCEL means Fujitsu figured
> out the library (.so) had not been dynamically loaded, so did not issue a dlclose().
> If
> you want the program initialized every time, use the INITIAL clause on PROGRAM-ID.

The INITIAL clause is _also_ BAD and WRONG advice. The INITIAL clause
means that the subprogram is reset on _EVERY_ CALL. It is not a
substitute for CANCEL.

If you want CANCEL to work then don't do stupid stuff like statically
linking a dynamic library. If you want to statically link then do so
with -c on the compile and -o NAME.o then link that.

> See my comments to Richard about the di

vantage of hundreds of little libraries.

The only 'di

vantage' that you could dream up was an entirely
subjective 'it is ugly' and similar. There are no _actual_
di

vantages and many significant advantages.

Robert

2008-02-01, 3:55 am

On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Feb 1, 4:23 pm, Robert <n...@e.mail> wrote:
>
>As usual you think that pointing out where you are wrong and
>correcting you is an 'insult'.

No, I think name calling is insulting.

>
>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'. Fujitsu's terminology is pretty
good:

static linking Old School, everything in one executable
dynamic program structure Unix style libraries linked with -l
dynamic link structure Cobol style Load On Demand

>
>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'. Makes you wonder why they didn't grey it out.

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

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

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

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

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

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

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

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

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

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

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

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

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

Richard

2008-02-01, 3:55 am

On Feb 1, 4:23 pm, Robert <n...@e.mail> wrote:
> On Thu, 31 Jan 2008 11:47:51 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
>
> [the usual insults snipped]

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

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

>
> It will first look for the symbol NAME already loaded. If not found THEN it will load
> libNAME.so.

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

Robert

2008-02-01, 3:55 am

On Thu, 31 Jan 2008 21:02:58 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Feb 1, 4:33 pm, Robert <n...@e.mail> wrote:
>
>Geez, Robert, yet more misinformation. You are _WRONG_ yet again. ld
>does _NOT_ follow the LD_LIBRARY_PATH. It follows the LIBPATH. You can
>add the current directory to LIBPATH or use the -L _IF_ you want to
>link the dynamic libraries statically.
>
>I actually ran a _test_ (you may want to look up what this word might
>refer to) by adding the -l MYSUB1 without the -L while having the
>LD_LIBRARY_PATH. As I expected it failed, just as Charles reported.

In the bad old days, each flavor of Unix had its own name for the library path searched by
ld and dlopen. AIX used LIBPATH (same as z/OS), HPUX used SHLIB_PATH, OS X used
DYLD_LIBRARY_PATH.

In the late '90s POSIX became the Unix standard. The POSIX name, LD_LIBRARY_PATH, works
on all versions of Unix.

For badkward compatibility, the various Unixen merge their old name with LD_LIBRARY_PATH,
eliminating duplicates, and use the result.

If your test failed, you ran it on an obsolete AIX. Charles reported that LD_LIBRARY_PATH
worked for him.

>
>The INITIAL clause is _also_ BAD and WRONG advice. The INITIAL clause
>means that the subprogram is reset on _EVERY_ CALL. It is not a
>substitute for CANCEL.
>
>If you want CANCEL to work then don't do stupid stuff like statically
>linking a dynamic library.

It's not a static link; it's a dynamic program structure.

>If you want to statically link then do so
>with -c on the compile and -o NAME.o then link that.

That would be turning the clock back 20 years. Some vendors, such as Micro Focus, have
dropped support for static linking.

>
>The only 'di

vantage' that you could dream up was an entirely
>subjective 'it is ugly' and similar. There are no _actual_
>di

vantages and many significant advantages.

User memory management makes it easy to return to MS-DOS. Is that the advantage?

Richard

2008-02-01, 6:56 pm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>
>
> 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.
>
>
> Not if the dll is 'bound'.

Richard

2008-02-01, 6:56 pm

On Feb 1, 9:13 pm, Robert <n...@e.mail> wrote:
> On Thu, 31 Jan 2008 21:02:58 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
> In the bad old days, each flavor of Unix had its own name for the library path searched by
> ld and dlopen. AIX used LIBPATH (same as z/OS), HPUX used SHLIB_PATH, OS X used
> DYLD_LIBRARY_PATH.
>
> In the late '90s POSIX became the Unix standard. The POSIX name, LD_LIBRARY_PATH, works
> on all versions of Unix.
>
> For badkward compatibility, the various Unixen merge their old name with LD_LIBRARY_PATH,
> eliminating duplicates, and use the result.
>
> If your test failed, you ran it on an obsolete AIX. Charles reported that LD_LIBRARY_PATH
> worked for him.

You are

yet again.

LD_LIBRARY_PATH is used to load dynamic libraries at run time. When
Charles _ran_ MYMAIN originally (with no -l), it failed to find
libMYSUB1.so until its directory was on the LD_LIBRARY_PATH. I
confirmed this with my tests.

When the -l MYSUB1 was added to the compile it failed to find "-
lMYSUB1" _even_with_ the current directory on the LD_LIBRARY_PATH. My
testing showed this to be the case. Charles added -L . to get ld to
look in the current directory.

I tested this and found exactly that. In a shell script I changed
LD_LIBRARY_PATH to point to the current directory as :.:./: and
explictly with the full path and ld failed to find MYSUB1. Adding -
L . (as Charles did) made it work.

ls, as I said, does not use LD_LIBRARY_PATH.

And BTW Mandrake is Red Hat based and not on 'an obsolete AIX'.

>
>
>
>
>
>
> It's not a static link; it's a dynamic program structure.
>
>
> That would be turning the clock back 20 years. Some vendors, such as Micro Focus, have
> dropped support for static linking.
>
>
>
> User memory management makes it easy to return to MS-DOS. Is that the advantage?

It is not done for "User memory management", that is why you fail to
understand the advantages.

Richard

2008-02-01, 6:56 pm

On Feb 1, 7:49 pm, Robert <n...@e.mail> wrote:
> On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
>
>
>
> No, I think name calling is insulting.

You leave me mystified, I went back through the message looking for
where I did any "name calling".

I had said that you made statements that were factually wrong, where
you made errors, and that you misunderstood as well as misinformed.

None of that is "name calling".

You seem to use the claim of "ad hominem" or "insults" as a means of
deflecting the very real criticism of your wrong and bad advice.

I am reminded of a self-assessment survey at the company I worked for
some decades ago. It was set by some trick-cyclist and for each
question gave two extreme statements and the employee had to put a
grade of 1 to 5 where 1 was agreeing with the left hand statement and
5 agreed with the right hand.

One of the '1' statements was "Takes criticism of work done as a
personal affront".

Pete Dashwood

2008-02-01, 6:56 pm

"Richard" <riplin@azonic.co.nz> wrote in message
news:5da53026-0d26-49cf-8951-3b001fa65b84@l32g2000hse.googlegroups.com...
> On Feb 1, 7:49 pm, Robert <n...@e.mail> wrote:
>
> You leave me mystified, I went back through the message looking for
> where I did any "name calling".
>
> I had said that you made statements that were factually wrong, where
> you made errors, and that you misunderstood as well as misinformed.
>
> None of that is "name calling".
>
> You seem to use the claim of "ad hominem" or "insults" as a means of
> deflecting the very real criticism of your wrong and bad advice.
>
> I am reminded of a self-assessment survey at the company I worked for
> some decades ago. It was set by some trick-cyclist and for each
> question gave two extreme statements and the employee had to put a
> grade of 1 to 5 where 1 was agreeing with the left hand statement and
> 5 agreed with the right hand.
>
> One of the '1' statements was "Takes criticism of work done as a
> personal affront".
>
I have followed this thread with interest, and learned a few things.

Maybe the problem here is that you both are experts with in-depth knowledge
and experience, but it may be in different areas.

Certainly what Richard has outlined matches my understanding (and use of)
dynamic linkage with Fujitsu, but I claim no expertise whatsoever with Unix
or derivatives thereof.

If it's any consolation Robert, I haven't issued a COBOL CANCEL for decades,
on ANY platform, and I haven't seen any for a long time, either.

Nevertheless, different folks use different strokes and there may well be
places where CANCEL is still used.

I have to admit that my first impulse was also to suggest using INITIAL but
I stifled it and did some thinking instead :-). I came to the same
conclusion that Richard did: INITIAL does not meet exactly the same
requirement as CANCEL

Robert, on this occasion I don't believe Richard was using ad hominem
attacks; in fact, considering his frustration over what certainly looked
like "bad" advice, I think he was quite restrained :-)

Given that Richard actually took the trouble to do compiles and tests and
published the results here, it might have been wise to pay some attention to
the results...:-)

Having said that, I know that Robert was actually trying to help. Sometimes,
when we are really close to things the old adage about not seeing the wood
for the trees can be applied. I couldn't help wondering how much Robert's
recent immersion and experience with ELF headers and Unix in general, was
affecting his perception and judgement of what was properly a COBOL problem.

My opinion remains that both of you are extremely valuable people to have in
this forum :-)

Pete.
--
"I used to write COBOL...now I can do anything."

C Goodman

2008-02-01, 6:56 pm

Pete Dashwood wrote:
>
Big Snip

> My opinion remains that both of you are extremely valuable people to have in
> this forum :-)
>
> Pete.

Well said Pete.

I have found the discussion of great value. Thanks to all who have
participated.

The original application was written for mini-computers that have long
since disappeared. Much of the code is also written in C.

The application is considered to be of very great value to our clients.

A little background....

The application I am working with has an installed base of hundreds of
installations. Almost all are using executables compiled with an old
version of MicroFucus and are running within an old version of SCO.

We need to modernize to a more recent Unix. Obvious choice is some
variety of Linux. We have experimented with AcuCOBOL and are now
experimenting with Fujitsu NetCOBOL. We are keeping a single code base.
All programs must compile and function correctly, without source
changes, on both MF and the new compiler.

---Charlie

Robert

2008-02-01, 9:56 pm

On Sat, 02 Feb 2008 00:41:05 GMT, C Goodman <foxgrove@shaw.ca> wrote:

>Pete Dashwood wrote:
>Big Snip
>
>
>Well said Pete.
>
>I have found the discussion of great value. Thanks to all who have
>participated.
>
>The original application was written for mini-computers that have long
>since disappeared. Much of the code is also written in C.
>
>The application is considered to be of very great value to our clients.
>
>A little background....
>
>The application I am working with has an installed base of hundreds of
>installations. Almost all are using executables compiled with an old
>version of MicroFucus and are running within an old version of SCO.
>
>We need to modernize to a more recent Unix. Obvious choice is some
>variety of Linux.

I concur.

> We have experimented with AcuCOBOL

Bad choice, soon to be obsolete and unsupported.

> and are now
>experimenting with Fujitsu NetCOBOL.

That's reasonable. Micro Focus would be a better choice. It is supported on Red Hat and
SuSE.

> We are keeping a single code base.
> All programs must compile and function correctly, without source
>changes, on both MF and the new compiler.

Your clients did not say no source changes; they said modernize. No source changes was
your decision and seems contrary to the project objective of modernizing.

Richard

2008-02-02, 3:55 am

On Feb 2, 1:41 pm, C Goodman <foxgr...@shaw.ca> wrote:
> Pete Dashwood wrote:
>
> Big Snip
>
>
>
> Well said Pete.
>
> I have found the discussion of great value. Thanks to all who have
> participated.
>
> The original application was written for mini-computers that have long
> since disappeared. Much of the code is also written in C.
>
> The application is considered to be of very great value to our clients.
>
> A little background....
>
> The application I am working with has an installed base of hundreds of
> installations. Almost all are using executables compiled with an old
> version of MicroFucus and are running within an old version of SCO.
>
> We need to modernize to a more recent Unix. Obvious choice is some
> variety of Linux. We have experimented with AcuCOBOL and are now
> experimenting with Fujitsu NetCOBOL. We are keeping a single code base.
> All programs must compile and function correctly, without source
> changes, on both MF and the new compiler.

Generally it is possible to get the code between Micro Focus and
Fujitsu to be the same, BUT NetCobol for Linux 7 does not have SCREEN
SECTION or any of the X/Open Screen Handling.

If your programs have been using ACCEPT/DISPLAY .. AT or ACCEPT/
DISPLAY FROM/UPON CRT or similar then NetCobol 7 for Linux won't do
that.

It seems that NetCobol 9 for SPARC does have X/Open that will do Micro
Focus style ACCEPT/DISPLAY. It would be nice if Fujitsu did a NetCobol
9 for Linux.

In the meantime Fujitsu on Linux is fine where the front end is
something else, eg: Web Server or SP/2.

Robert

2008-02-02, 9:58 pm

On Fri, 1 Feb 2008 14:46:35 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Feb 1, 7:49 pm, Robert <n...@e.mail> wrote:
>
>You leave me mystified, I went back through the message looking for
>where I did any "name calling".
>
>I had said that you made statements that were factually wrong, where
>you made errors, and that you misunderstood as well as misinformed.
>
>None of that is "name calling".

People come here s

ing information about Cobol. They don't care about me, you nor any
other individual. If a fact is wrong, in your opinion, state the correct fact, preferably
with substantiation.

Flaming is disrespectful not only to the target but even more to other readers, because
you're wasting their time.

Robert

2008-02-02, 9:58 pm

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

>On Feb 1, 7:49 pm, Robert <n...@e.mail> wrote:
[color=darkred]
>
>
>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.

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

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

>
>It would seem to me that Charles' programs may well form an
>interactive menu driven application. Gracefull fallback is what these
>systems should do.
>
>
>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.

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

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

Robert

2008-02-02, 9:58 pm

On Fri, 1 Feb 2008 13:24:40 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Feb 1, 9:13 pm, Robert <n...@e.mail> wrote:
>
>You are

yet again.
>
>LD_LIBRARY_PATH is used to load dynamic libraries at run time. When
>Charles _ran_ MYMAIN originally (with no -l), it failed to find
>libMYSUB1.so until its directory was on the LD_LIBRARY_PATH. I
>confirmed this with my tests.
>
>When the -l MYSUB1 was added to the compile it failed to find "-
>lMYSUB1" _even_with_ the current directory on the LD_LIBRARY_PATH. My
>testing showed this to be the case. Charles added -L . to get ld to
>look in the current directory.
>
>I tested this and found exactly that. In a shell script I changed
>LD_LIBRARY_PATH to point to the current directory as :.:./: and
>explictly with the full path and ld failed to find MYSUB1. Adding -
>L . (as Charles did) made it work.

The general rule is that Unix, both ld and dlopen, searches LD_LIBRARY_PATH. If yours
isn't doing that, there is something abnormal in your configuration.

Do you have an ld configuration file? To find out, run crle or look at /etc/ld.so.conf.

Are you using Linux Security? If so, it will only search secure directories in
LD_LIBRARY_PATH. Your home directory is not one of them.

Did you forget to export or setenv LD_LIBRARY_PATH? If so, ld running as a child process
of your script, doesn't see it.

Here's a quote from the ld man page:

"The default set of paths searched (without being specified with -L) depends on which
emulation mode ld is using, and in some cases also on how it was configured."

The linker uses the following search paths to locate required shared libraries:
1.

Any directories specified by -rpath-link options.

2.

Any directories specified by -rpath options. The difference between -rpath and
-rpath-link is that directories specified by -rpath options are included in the executable
and used at runtime, whereas the -rpath-link option is only effective at link time.
Searching -rpath in this way is only supported by native linkers and cross linkers which
have been configured with the --with-sysroot option.

3.

On an ELF system, if the -rpath and "rpath-link" options were not used, search the
contents of the environment variable "LD_RUN_PATH". It is for the native linker only.

4.

On SunOS, if the -rpath option was not used, search any directories specified using -L
options.

5.

For a native linker, the contents of the environment variable "LD_LIBRARY_PATH".

6.

For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared
library are searched for shared libraries needed by it. The "DT_RPATH" entries are ignored
if "DT_RUNPATH" entries exist.

7.

The default directories, normally /lib and /usr/lib.

8.

For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list of
directories found in that file.

http://linux.die.net/man/1/ld

Actually, it's more complicated than that. There 4-6 obscure environment variables that
can 'front end' the search path. They are used to 'overload' system libraries.

>ls, as I said, does not use LD_LIBRARY_PATH.

It should have. Every Unix machine I've ever worked on did.

>And BTW Mandrake is Red Hat based and not on 'an obsolete AIX'.

I suspect you got LIBPATH from this erroneous man page:

If ld is called with any number of occurrences of -L, as
in:

ld ... -Lpath1 ... -Lpathn ...

then the search path ordering is:

dirlist1 path1 ... pathn dirlist2 LIBPATH
http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?ld+1

Robert

2008-02-02, 9:58 pm

On Sat, 2 Feb 2008 12:36:36 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>I have followed this thread with interest, and learned a few things.
>
>Maybe the problem here is that you both are experts with in-depth knowledge
>and experience, but it may be in different areas.

We have different approaches to problem solving. An analogy is scientists, who are divided
into theoriticians and experimenters. A theoritician predicts outcomes based on abstract
principles; an experimenter observes outcomes in reality.

When I want to know what a program is doing, I instinctively read source code. Some of my
colleagues' first approach is to run test cases. I wonder how they WRITE programs. Do they
use a million monkeys generating random code, then find the one that works by eliminating
the ones that don't?

I find it troubling when a programmer regards the program as a black box. Testers are
supposed to think that way, not programmers.

>Certainly what Richard has outlined matches my understanding (and use of)
>dynamic linkage with Fujitsu, but I claim no expertise whatsoever with Unix
>or derivatives thereof.
>
>If it's any consolation Robert, I haven't issued a COBOL CANCEL for decades,
>on ANY platform, and I haven't seen any for a long time, either.

Neither have I. I've only used CANCEL when the machine was short on memory.

I have long advocated late binding. In VSE days, I wrote my own memory manager to get it
under CICS because IBM's functionality was inadequate. But, when I wanted to replace a
program in memory with a fresh copy, I did it with a system tool, not with a Cobol CANCEL.

>Nevertheless, different folks use different strokes and there may well be
>places where CANCEL is still used.

Application code shouldn't be managing memory or versioning; that's the domain of systems
software.

>I have to admit that my first impulse was also to suggest using INITIAL but
>I stifled it and did some thinking instead :-). I came to the same
>conclusion that Richard did: INITIAL does not meet exactly the same
>requirement as CANCEL

It seems wrong to use the loader for initialization. I don't use VALUE and often
allocate/initialize working-storage structures at execution time. In OO terms,
working-storage is like making every object static.

>Robert, on this occasion I don't believe Richard was using ad hominem
>attacks; in fact, considering his frustration over what certainly looked
>like "bad" advice, I think he was quite restrained :-)
>
>Given that Richard actually took the trouble to do compiles and tests and
>published the results here, it might have been wise to pay some attention to
>the results...:-)

I pay attention, but test results do not ALWAYS prove a general rule. In this case, they
reflect a configuration error.

>Having said that, I know that Robert was actually trying to help. Sometimes,
>when we are really close to things the old adage about not seeing the wood
>for the trees can be applied. I couldn't help wondering how much Robert's
>recent immersion and experience with ELF headers and Unix in general, was
>affecting his perception and judgement of what was properly a COBOL problem.

INITIALIZE is the Cobol way to initialize structures, not CANCEL. Unfortunately, it
doesn't load VALUEs and the '02 option to do so has not been implemented on most
compilers.

Richard

2008-02-03, 3:55 am

On Feb 3, 3:31 pm, Robert <n...@e.mail> wrote:
> On Fri, 1 Feb 2008 12:58:23 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
> That's why CANCEL was created.
>
>
>
> Loading at start up time is faster and safer.

That is your opinion. It doesn't agree with mine at all, and I have
been using dynamic load when required for some some decades.

> You can specify -z lazyload to make it load
> libraries when first called.

It may be that for a batch run checking that all required modules are
available at start-up would be useful. However, for an interactive
system with several applications and many modules it would be _slower_
on start up to load all modules simply because many will not be run on
any particular day.

As for 'safer', you have that completely wrong, too. If a particular
module is missing then it would prevent anyone doing anything if the
startup failed because of that, but it may be a module that is not
actually required that day.

As I never have had an issue where any system was 'unsafe' because I
had separate dynamic loaded programs then I can't see how you can
claim 'safer' than that.

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

No. The downside is that the user has to completely close the
application, update the libraries, and then restart the application if
a new program, or an updated one, or a one-off, is required.

If it is Windows then the library cannot be replaced until all users
have closed the application because you cannot overwrite an open file.

With dynamic loading, and a suitable framework in place (which I had
developed many years ago), it is only necessary to drop the new
program in and select it.

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

Actually in MF Cobol since Level II there is a special CALL x"91"
function 15 that will tell you if the program exists.

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

No, I don't have to do that, I have the menu program tell the user if
a program is unavailable when they actually try to run it.

>
>
>
>
>
> There are more files that can be deleted or overwritten.

As I have never had a program file "overwritten or deleted" then no
other mechanism can be 'more reliable'. If you do have a library file
deleted then with your mechanism _no_one_ can do anything with the
system because it fails to load up at all (according to what you have
said).

With my system if a file is deleted or overwritten then unless it is
one of a small number of essential core modules the applications will
run, but possibly one or more modules could become unavailable. Of
course it is possible that module is not required at that time anyway.

How do _you_ measure reliability ? Let us say one file has been
deleted:

a) NOTHING WORKS AT ALL until the programmer fixes the problem.

b) Applications function as normal except one module is unavailable
(which may not be required)

I would say the b) would rate as 'more reliable'.

>
> There is no reason to re-test an unchanged program just because it is in the same library
> with other programs.

Yes, there is. Any program that is re-issued must pass testing. It may
be that other programs in that library have been modified (by someone
else) but are not completed and ready for distribution.

If you lump a dozen programs into a library then you need to re-test
and re-issue those dozen.

In fact that is a point against using a library if you are not
retesting because there is a risk that may affect the system's
reliability.

> You could use the same argument to require re-testing every
> application on the machine.

Why ? Are you re-issuing new versions of every application ?

> Changes in one program can't cause errors in other programs unless they share global data.

You are changing one program and then collecting a dozen, or several
dozen into one library file and re-issuing it. How do you ensure that
the other dozens have not been changed but are not ready for issuing
yet ?

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

Why are you talking irrelevancies here ? You are just making up straw
men.

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

'Home-grown' or application security does not prevent other security
systems being used. In fact having each program separately in its own
file can be used to give greater granularity to the security.

In any case, in my systems, users don't have access to the application
security files except by running the application control system and
that is protected. And, no, they can't just edit a text file.

So you are inventing straw man arguments yet again.

If I want some programs, such as month end, to be entirely secure I
can make put them in a special group and only have specific users in
that group. Make them readable by that group only and no one else can
run them even if they break the application security.

With your mechanism:

1) You would have to make the whole library special group only (OK so
you could reorganize and re-issue).

2) the application would fail to start for everyone else because the
library was unavailable.

But thank you for pointing out yet another advantage of how I do the
systems.

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

Where did the 'bad security' come from ? Oh, I know, you made that up.

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

I am quite happy with the way the system works, why are you attempting
to impose your unrequired ideas on my systems when there is no problem
at all ?

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

So the score remains at about 10 to nothing then ?

Richard

2008-02-03, 3:55 am

On Feb 3, 3:31 pm, Robert <n...@e.mail> wrote:
> On Fri, 1 Feb 2008 14:46:35 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
> People come here s

ing information about Cobol. They don't care about me, you nor any
> other individual. If a fact is wrong, in your opinion, state the correct fact, preferably
> with substantiation.

And where have I _not_ done that ?

Where is your substantiation for "insults", "name calling" or, in
fact, where I have not "stated the correct fact _with_
substantiation" ?

> Flaming is disrespectful not only to the target

In what way is saying that you are wrong, and providing the correct
facts, with substantiation, considered to be 'flaming' ?

OK, granted, _you_ call it that, but who else would ?

> but even more to other readers, because
> you're wasting their time.

No, Robert, what _is_ a waste of time is when bad advice is given and
factual inaccuracies are repeated. This is especially a waste of time
when the 'answers' don't even address the problem requirements.

Richard

2008-02-03, 3:55 am

On Feb 3, 3:31 pm, Robert <n...@e.mail> wrote:
> On Sat, 2 Feb 2008 12:36:36 +1300, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
>
>
> We have different approaches to problem solving. An analogy is scientists, who are divided
> into theoriticians and experimenters. A theoritician predicts outcomes based on abstract
> principles; an experimenter observes outcomes in reality.

If hypotheses are not tested then it is not science.

> When I want to know what a program is doing, I instinctively read source code. Some of my
> colleagues' first approach is to run test cases. I wonder how they WRITE programs. Do they
> use a million monkeys generating random code, then find the one that works by eliminating
> the ones that don't?
>
> I find it troubling when a programmer regards the program as a black box. Testers are
> supposed to think that way, not programmers.

I find it troubling when a programmer doesn't test.

>
>
> Neither have I. I've only used CANCEL when the machine was short on memory.
>

Exactly, you haven't investigated its other benefits.

> I have long advocated late binding. In VSE days, I wrote my own memory manager to get it
> under CICS because IBM's functionality was inadequate. But, when I wanted to replace a
> program in memory with a fresh copy, I did it with a system tool, not with a Cobol CANCEL.
>
>
> Application code shouldn't be managing memory or versioning; that's the domain of systems
> software.

When an application framework has been created it is the 'system
software' for the underlying applications and their programs. The
framework can be portable and independent of what system it is running
on.

>
> It seems wrong to use the loader for initialization. I don't use VALUE and often
> allocate/initialize working-storage structures at execution time. In OO terms,
> working-storage is like making every object static.

In OO Terms Working-Storage is the object attributes and the performed
paragraphs may be the methods (depending on how it is written).

>
>
> I pay attention, but test results do not ALWAYS prove a general rule. In this case, they
> reflect a configuration error.
>
>
> INITIALIZE is the Cobol way to initialize structures, not CANCEL. Unfortunately, it
> doesn't load VALUEs and the '02 option to do so has not been implemented on most
> compilers.

'initializing structures' is another straw-man.

2008-02-03, 3:55 am

In article <qv6aq3l08m7r14k0jsvpiqf4ftkvi8up9t@4ax.com>,
Robert <no@e.mail> wrote:

[snip]

>If a fact is wrong, in your opinion, state the correct fact, preferably
>with substantiation.

This is fascinating. Given that a fact is 'a done/made thing' (factum)
under what circumstances could it be wrong? To use definitions from
http://m-w.com : how can 'something that has actual occurrence' have 'the
state of being mistaken or incorrect'?

'Under conditions called 'one earth normal' and in the absence of opposing
forces this object was measured as falling with an acceleration caused by
gravity of 32ft/sec/sec.'

'No, that measurement was mistaken or incorrect. Here is the correct
fact:...'

Now... what would 'the correct fact' look like?

DD

Richard

2008-02-03, 6:56 pm

On Feb 2, 3:41 pm, Robert <n...@e.mail> wrote:
> On Sat, 02 Feb 2008 00:41:05 GMT, C Goodman <foxgr...@shaw.ca> wrote:
>
>
>
>
>
>
>
>
>
>
>
> I concur.
>
>
> Bad choice, soon to be obsolete and unsupported.
>
>
> That's reasonable. Micro Focus would be a better choice. It is supported on Red Hat and
> SuSE.
>
>
> Your clients did not say no source changes; they said modernize. No source changes was
> your decision and seems contrary to the project objective of modernizing.

My understanding of what Charles said differs from yours.

It appears to me that no one said "the current source must not be
changed" as you seem to think. The 'single code base' will be the
modernized system and this must not change between being compiled to
run on the old SCO/old MF and being compiled on the new OS/Compiler.

I do have systems that can be compiled for either MF or Fujitsu, but I
have a pre-process step that changes the comments on a small number of
lines of code that are marked (in columns 1-6) as being specific to
one or the other compiler.

These programs are Web-based or SP2 based for their user interactions
so didn't present a problem that use of ADIS would give.

Robert

2008-02-03, 6:56 pm

On Sun, 3 Feb 2008 07:29:41 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <qv6aq3l08m7r14k0jsvpiqf4ftkvi8up9t@4ax.com>,
>Robert <no@e.mail> wrote:
>
>[snip]
>
>
>This is fascinating. Given that a fact is 'a done/made thing' (factum)
>under what circumstances could it be wrong? To use definitions from
>http://m-w.com : how can 'something that has actual occurrence' have 'the
>state of being mistaken or incorrect'?

A general principle inferred from an anomalous fact is incorrect. For instance, the
assertion that LD_LIBRARY_PATH is not used to search for called programs is incorrect
99.9% of the time.

>'Under conditions called 'one earth normal' and in the absence of opposing
>forces this object was measured as falling with an acceleration caused by
>gravity of 32ft/sec/sec.'
>
>'No, that measurement was mistaken or incorrect. Here is the correct
>fact:...'
>
>Now... what would 'the correct fact' look like?

At sea level, vt ~= 90 * d**.5, where vt is terminal velocity and d is diameter. It
shows that a mouse can survive a fall from any height but a human cannot. Mass is also a
factor. vt ~= mg / b shows that a motorcycle coasts downhill faster than a bicycle (b is
the viscosity of air).

Robert

2008-02-04, 3:55 am

On Sat, 2 Feb 2008 21:33:22 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Feb 3, 3:31 pm, Robert <n...@e.mail> wrote:
[color=darkred]
>
>That is your opinion. It doesn't agree with mine at all, and I have
>been using dynamic load when required for some some decades.
>
>
>It may be that for a batch run checking that all required modules are
>available at start-up would be useful. However, for an interactive
>system with several applications and many modules it would be _slower_
>on start up to load all modules simply because many will not be run on
>any particular day.
>
>As for 'safer', you have that completely wrong, too. If a particular
>module is missing then it would prevent anyone doing anything if the
>startup failed because of that, but it may be a module that is not
>actually required that day.
>
>As I never have had an issue where any system was 'unsafe' because I
>had separate dynamic loaded programs then I can't see how you can
>claim 'safer' than that.

It happens to me often, because I frequently change environments. If the right .profile or
..login doesn't get sourced in, the library path will be blank or incorrect. I find it
helpful to know in advance that a program or batch job will not run, instead of having it
abort in the middle.

Others reached the same conclusion, which is why dynamic program structure is THE NORM in
the Unix and Windows worlds.

>
>No. The downside is that the user has to completely close the
>application, update the libraries, and then restart the application if
>a new program, or an updated one, or a one-off, is required.

An application can do that with versioning. If it calls foo.1.3 and foo.1.2 is already in
memory, the loader will not use 1.2, it will load 1.3.

The benefit is that you won't accidentally get a library installed by another application.
This a common problem on Windows, known as 'DLL hell'. The di

vantage is inability to
upgrade a library without upgrading the calling program.

Version binding is normally done by the linker; it is normally not coded into the calling
program, thus you don't have to recompile the caller to change its binding, but you do
have to reload it. However, versioning can be controlled by the program by using the
dlvsym() function.

>If it is Windows then the library cannot be replaced until all users
>have closed the application because you cannot overwrite an open file.

Dynamically loaded dlls have the same problem. All users have to CANCEL before the dll can
be replaced.

The Unix solution is to put the version number into the file name. The library name with
no version is a symbolic link to the current library file. You can change symbolic links
at any time because the file system doesn't track whether they are in use.

>With dynamic loading, and a suitable framework in place (which I had
>developed many years ago), it is only necessary to drop the new
>program in and select it.

Sounds like a golden opportunity for hackers.
mv login.so login.bkp
cp mylogin.so login.so
echo Ready for unauthenticated login.
.....
mv login.bkp login.so

>
>Yes, there is. Any program that is re-issued must pass testing. It may
>be that other programs in that library have been modified (by someone
>else) but are not completed and ready for distribution.

>
>You are changing one program and then collecting a dozen, or several
>dozen into one library file and re-issuing it. How do you ensure that
>the other dozens have not been changed but are not ready for issuing
>yet ?

That's what version control is for. Untested programs don't get moved to the trunk
(production).

>
>'Home-grown' or application security does not prevent other security
>systems being used. In fact having each program separately in its own
>file can be used to give greater granularity to the security.
>
>In any case, in my systems, users don't have access to the application
>security files except by running the application control system and
>that is protected. And, no, they can't just edit a text file.
>
>So you are inventing straw man arguments yet again.
>
>If I want some programs, such as month end, to be entirely secure I
>can make put them in a special group and only have specific users in
>that group. Make them readable by that group only and no one else can
>run them even if they break the application security.
>
>With your mechanism:
>
>1) You would have to make the whole library special group only (OK so
>you could reorganize and re-issue).
>
>2) the application would fail to start for everyone else because the
>library was unavailable.

My mechanism is oriented around data, not programs. If I want to protect month-end figures
in the accounting system, for example, I protect those numbers in the database.
Unauthorized users cannot change them by running the monthend program, by writing their
own program nor by running a database utility. Your notion of security by controlling
access to programs was obsolete twenty years ago.

If I DID want to limit access to a program function, the security check would be in the
function, not the file it is packaged in nor the calling program. Relying on Unix file
system to do application security is weak. For example, if the setgroupid bit of a program
file is set, it executes under the owner's group id rather than the user's.

Robert

2008-02-04, 3:56 am

On Sun, 3 Feb 2008 10:26:16 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:

>On Feb 2, 3:41 pm, Robert <n...@e.mail> wrote:
>
>My understanding of what Charles said differs from yours.
>
>It appears to me that no one said "the current source must not be
>changed" as you seem to think. The 'single code base' will be the
>modernized system and this must not change between being compiled to
>run on the old SCO/old MF and being compiled on the new OS/Compiler.
>
>I do have systems that can be compiled for either MF or Fujitsu, but I
>have a pre-process step that changes the comments on a small number of
>lines of code that are marked (in columns 1-6) as being specific to
>one or the other compiler.
>
>These programs are Web-based or SP2 based for their user interactions
>so didn't present a problem that use of ADIS would give.

MF offers conditional compilation with syntax close to the '02 standard. Fujitsu does not,
although it will ignore conditional compilation statements (it thinks they are debugging
lines). Thus, conditional compilation can exclude Fujitsu-specific source code from a MF
compilation, but not to exclude MF-specific code from a Fujitsu compilation.

I think your precompiler approach is a good one. Another would be to put the MF code in
copyboods that are empty during a Fujitsu compilation.

Richard

2008-02-04, 3:56 am

On Feb 4, 7:35 pm, Robert <n...@e.mail> wrote:
> On Sat, 2 Feb 2008 21:33:22 -0800 (PST), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
> It happens to me often, because I frequently change environments. If the right .profile or
> .login doesn't get sourced in, the library path will be blank or incorrect. I find it
> helpful to know in advance that a program or batch job will not run, instead of having it
> abort in the middle.

Why can't you ensure that the environment is set correctly before it
runs. In any case if the run won't find anything because the paths are
set wrongly (which doesn't happen to me) then my core routines won't
be found either and the program won't start either.

But your point was about files being deleted or corrupted. Now you try
to change to having stuff mixed up.

> Others reached the same conclusion, which is why dynamic program structure is THE NORM in
> the Unix and Windows worlds.

I am not sure why you are attempting to change the way that I (and, it
seems, Charles) have been working for years. The way I do things
things works 100% safe and reliable. You cannot claim anything better
than that, _plus_ I get flexability thay your mechanism doesn't give.

I was was doing batch jobs then maybe I would do that, or even
static. But I don't so what batch jobs do is of no interest.

>
>
>
>
> An application can do that with versioning. If it calls foo.1.3 and foo.1.2 is already in
> memory, the loader will not use 1.2, it will load 1.3.

<shrug> I don't need multiple concurrent versions. The way I do it
works 100%.

> The benefit is that you won't accidentally get a library installed by another application.

I never will because all my files are held in a structure of
directories that will never be used by anything else.

Why do you keep coming up with entirely spurious arguments and straw-
men ?

> This a common problem on Windows, known as 'DLL hell'. The di

vantage is inability to
> upgrade a library without upgrading the calling program.

Your point being ?

Again you create a spurious argument and a straw-man.

> Version binding is normally done by the linker; it is normally not coded into the calling
> program, thus you don't have to recompile the caller to change its binding, but you do
> have to reload it. However, versioning can be controlled by the program by using the
> dlvsym() function.

Why do you think that relevant ? I haven't recompiled 'the calling
program' for years.

>
> Dynamically loaded dlls have the same problem. All users have to CANCEL before the dll can
> be replaced.

You weren't paying attention. I did an _actual_test_ and all users
_did_not_ have to CANCEL before replacement (but then this isn't
Windows).

> The Unix solution is to put the version number into the file name. The library name with
> no version is a symbolic link to the current library file. You can change symbolic links
> at any time because the file system doesn't track whether they are in use.
>
>
> Sounds like a golden opportunity for hackers.
> mv login.so login.bkp
> cp mylogin.so login.so
> echo Ready for unauthenticated login.
> ....
> mv login.bkp login.so

What makes you think that users have write access to the program
directory ? _I_ can drop in another program.

Just another straw-man.

>
>
>
>
> That's what version control is for. Untested programs don't get moved to the trunk
> (production).
>
>
>
>
>
>
>
>
>
>
>
>
> My mechanism is oriented around data, not programs. If I want to protect month-end figures
> in the accounting system, for example, I protect those numbers in the database.
> Unauthorized users cannot change them by running the monthend program, by writing their
> own program nor by running a database utility. Your notion of security by controlling
> access to programs was obsolete twenty years ago.

Just change the subject then. You were trying to say that using
libraries was 'more secure'. You tried to say that 'home-grown' was
not secure.

Now you just change the subject to something different because you
failed to establish your unsupported and flawed assertions.

In fact this change seems to be after I pointed out that your
mechanism _couldn't_ use the unix file system security because it
would stop your applications from starting.

There is nothing in using dynamic loading that prevents the
application from using any other security mechanism.

In fact my system does implement field level security within the
system, but I don't run Banks or Stock Exchanges. The level of
security that I use is exactly correct for the businesses that use my
applications.

> If I DID want to limit access to a program function, the security check would be in the
> function, not the file it is packaged in nor the calling program. Relying on Unix file
> system to do application security is weak. For example, if the setgroupid bit of a program
> file is set, it executes under the owner's group id rather than the user's.

Another straw-man. Why would I have setgroupid set ?

But as you _should_ have noticed I don't need to "Rely on Unix file
system". I have the 'home-grown' application security that you said
was useless, and now you say that Unix is useless and you would use
'home-grown'.

You really are struggling (and failing) to score any wins here at all.

The point is that with the high granularity I _can_ use Unix file
system security (and have it work) as well as the application
security.

2008-02-04, 6:56 pm

In article <b35cq35fcshvv49jdft98vn0k2viob8mqf@4ax.com>,
Robert <no@e.mail> wrote:
>On Sun, 3 Feb 2008 07:29:41 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>A general principle inferred from an anomalous fact is incorrect.

Mr Wagner, your statement - and my question which followed it - are about
a fact, not a principle or an inference.

DD

Robert

2008-02-04, 6:56 pm

On Mon, 4 Feb 2008 15:16:33 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <b35cq35fcshvv49jdft98vn0k2viob8mqf@4ax.com>,
>Robert <no@e.mail> wrote:
>
>Mr Wagner, your statement - and my question which followed it - are about
>a fact, not a principle or an inference.

It is unclear which fact you are referring to. I stated the fact I was referring to in the
next sentence. "For instance, the assertion that LD_LIBRARY_PATH is not used to search
for called programs is incorrect 99.9% of the time. "

2008-02-04, 6:56 pm

In article <tileq3lh7q6tr6dqk2bekguc46mcmgkrbt@4ax.com>,
Robert <no@e.mail> wrote:
>On Mon, 4 Feb 2008 15:16:33 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>It is unclear which fact you are referring to.

I am referring to the fact which is defined as 'a done/made thing'
('factum' or the result of 'facere').

DD

Robert

2008-02-04, 9:59 pm

On Mon, 4 Feb 2008 19:23:11 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <tileq3lh7q6tr6dqk2bekguc46mcmgkrbt@4ax.com>,
>Robert <no@e.mail> wrote:
>
>I am referring to the fact which is defined as 'a done/made thing'
>('factum' or the result of 'facere').

Your question that followed it was this:

>'Under conditions called 'one earth normal' and in the absence of opposing
>forces this object was measured as falling with an acceleration caused by
>gravity of 32ft/sec/sec.'

>'No, that measurement was mistaken or incorrect. Here is the correct
>fact:...'

>Now... what would 'the correct fact' look like?

I was told in school that Galileo stood on top of the Tower of Pisa, dropped a cannon ball
and musket ball (bullet), observed they hit the ground at the same time This proved the
acceleration of gravity was invariant to mass.

Did you believe that?

There are a few problems with the story:

... The answer is simply wrong. The heavier ball lands first.

... Galileo never said they landed at the same time; he said the heavier ball lands first.

... The experiment probably never happened in the way described. Galileo was blind at the
time. Galileo never said it happened, one of his biographers did. Galileo described
similar experiments conducted in a lab decades earlier. Again, he reported the heavier
ball landed first.

Today I asked Russian and Yugoslavian colleagues whether they had been taught this fable.
Both said no. The Russian said they had been told that happens in a vacuum.

The first artificial vacuum was created by Torricelli in 1643, one year after Galileo's
death.

Technically the smaller ball initially pulls ahead because it has a lower coef