Prev: help with tables
Next: S0C4 x'4' abend while reading VSAM KSDS file
From: Richard on 1 Feb 2008 16:24
On Feb 1, 9:13 pm, Robert <n...(a)e.mail> wrote:
> On Thu, 31 Jan 2008 21:02:58 -0800 (PST), Richard <rip...(a)azonic.co.nz> wrote:
> >On Feb 1, 4:33 pm, Robert <n...(a)e.mail> wrote:
> >> On Thu, 31 Jan 2008 09:48:48 -0800 (PST), charles.good...(a)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.
>
> >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.

You are confused 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'.


> >> >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.
>
> >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.
>
> >> See my comments to Richard about the disadvantage of hundreds of little libraries.
>
> >The only 'disadvantage' that you could dream up was an entirely
> >subjective 'it is ugly' and similar. There are no _actual_
> >disadvantages and many significant advantages.
>
> 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.



From: Richard on 1 Feb 2008 17:46
On Feb 1, 7:49 pm, Robert <n...(a)e.mail> wrote:
> On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <rip...(a)azonic.co.nz> wrote:
> >On Feb 1, 4:23 pm, Robert <n...(a)e.mail> wrote:
> >> On Thu, 31 Jan 2008 11:47:51 -0800 (PST), Richard <rip...(a)azonic.co.nz> wrote:
> >> >On Jan 31, 7:23 pm, Robert <n...(a)e.mail> wrote:
> >> >> On Wed, 30 Jan 2008 20:46:28 -0800 (PST), Richard <rip...(a)azonic.co.nz> wrote:
> >> >> >On Jan 31, 4:38 pm, Robert <n...(a)e.mail> wrote:
> >> >> >> >when I try to execute I see my first DISPLAY and then it crashes:
> >> >> >> >BEGIN MYMAIN
> >> >> >> >cobol-rts:: HALT: JMP0015I-U [PID:0000763D TID:002516C0] CANNOT CALL
> >> >> >> >PROGRAM 'MY
> >> >> >> >SUB1'. ./MYMAIN: undefined symbol: MYSUB1 PGM=MYMAIN
> >> >> >> >Aborted
>
> >> >> >> >I am running on Red Hat Enterprise, and Fujitsu support say they will
> >> >> >> >only support:
> >> >> >> > * Red Hat Linux 7.2, Locale C
> >> >> >> > * Red Hat Linux 7.3, Locale C
> >> >> >> > * Red Hat Linux Advanced Server 2.1, Locale C
>
> >> >> >> >I am hoping that someone here has figured out how to compile and line
> >> >> >> >on less ancient versions of Linux.
>
> >> >> >> Try '-l MYSUB1' (lower case el) on the compilation of MYMAIN. As written, MYMAIN has no
> >> >> >> way of knowing the library name.
>
> >> >> >I think that you fail to understand what 'Dynamic Load' means.
>
> >> >> There is no Cobol syntax to specify a library name. You can only specify an entry point
> >> >> name. When you do a CALL, Unix doesn't search every library in the library path. That
> >> >> would be hopelessly slow. It searches only the libraries named in the executable's ELF
> >> >> header.
>
> >> >> Libraries normally contain many programs and entry points. They are not one-for-one like
> >> >> the example here.
>
> >> [the usual insults snipped]
>
> >As usual you think that pointing out where you are wrong and
> >correcting you is an 'insult'.
>
> No, I think name calling is insulting.

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

From: Pete Dashwood on 1 Feb 2008 18:36


"Richard" <riplin(a)azonic.co.nz> wrote in message
news:5da53026-0d26-49cf-8951-3b001fa65b84(a)l32g2000hse.googlegroups.com...
> On Feb 1, 7:49 pm, Robert <n...(a)e.mail> wrote:
>> On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <rip...(a)azonic.co.nz>
>> wrote:
>> >On Feb 1, 4:23 pm, Robert <n...(a)e.mail> wrote:
>> >> On Thu, 31 Jan 2008 11:47:51 -0800 (PST), Richard
>> >> <rip...(a)azonic.co.nz> wrote:
>> >> >On Jan 31, 7:23 pm, Robert <n...(a)e.mail> wrote:
>> >> >> On Wed, 30 Jan 2008 20:46:28 -0800 (PST), Richard
>> >> >> <rip...(a)azonic.co.nz> wrote:
>> >> >> >On Jan 31, 4:38 pm, Robert <n...(a)e.mail> wrote:
>> >> >> >> >when I try to execute I see my first DISPLAY and then it
>> >> >> >> >crashes:
>> >> >> >> >BEGIN MYMAIN
>> >> >> >> >cobol-rts:: HALT: JMP0015I-U [PID:0000763D TID:002516C0] CANNOT
>> >> >> >> >CALL
>> >> >> >> >PROGRAM 'MY
>> >> >> >> >SUB1'. ./MYMAIN: undefined symbol: MYSUB1 PGM=MYMAIN
>> >> >> >> >Aborted
>>
>> >> >> >> >I am running on Red Hat Enterprise, and Fujitsu support say
>> >> >> >> >they will
>> >> >> >> >only support:
>> >> >> >> > * Red Hat Linux 7.2, Locale C
>> >> >> >> > * Red Hat Linux 7.3, Locale C
>> >> >> >> > * Red Hat Linux Advanced Server 2.1, Locale C
>>
>> >> >> >> >I am hoping that someone here has figured out how to compile
>> >> >> >> >and line
>> >> >> >> >on less ancient versions of Linux.
>>
>> >> >> >> Try '-l MYSUB1' (lower case el) on the compilation of MYMAIN. As
>> >> >> >> written, MYMAIN has no
>> >> >> >> way of knowing the library name.
>>
>> >> >> >I think that you fail to understand what 'Dynamic Load' means.
>>
>> >> >> There is no Cobol syntax to specify a library name. You can only
>> >> >> specify an entry point
>> >> >> name. When you do a CALL, Unix doesn't search every library in the
>> >> >> library path. That
>> >> >> would be hopelessly slow. It searches only the libraries named in
>> >> >> the executable's ELF
>> >> >> header.
>>
>> >> >> Libraries normally contain many programs and entry points. They are
>> >> >> not one-for-one like
>> >> >> the example here.
>>
>> >> [the usual insults snipped]
>>
>> >As usual you think that pointing out where you are wrong and
>> >correcting you is an 'insult'.
>>
>> No, I think name calling is insulting.
>
> 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."



From: C Goodman on 1 Feb 2008 19:41
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

From: Robert on 1 Feb 2008 21:41
On Sat, 02 Feb 2008 00:41:05 GMT, C Goodman <foxgrove(a)shaw.ca> wrote:

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

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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: help with tables
Next: S0C4 x'4' abend while reading VSAM KSDS file