Cobol - Linking Problem

Author

Linking Problem

hdumoulin@ups-scs.com

2005-05-25, 3:55 pm

I work in an environment where we compile a program on one machine and
then simply take the .int files and move them to another machine that
has a different directory structure. This used to work fine until we
upgraded to MicroFocus Server Express Version4. According to MicroFocus
in order for an executable to be portable it would have to run on a
machine that has the same directory structure as the original machine.

We were told that if we do not want to port source code that we could
port .int programs and then use the cob command to relink them on the
destination machine. We tried this but the destination machine is still
looking for the original location.

Please advise. Thanks.

Simon Tobias

2005-05-25, 3:55 pm

Hi.

You may be better off registering on the Micro Focus forum at
http://www.cobolportal.com/ to get a response to this, but I'm curious as to
which platform you're running on.

Some platforms, such as HP-UX PA-RISC in 32-bit mode, have linker options
which can effectively hardcode the search path used at build-time for
resolving symbols. This can mean that at execution time, if you don't have
the same directory structure on the target machine to resolve those same
symbols, you could get unresolved symbol errors.

If you've got an example program also, I'd suggest posting that to the forum
also, so we can investigate further.

SimonT.

Richard

2005-05-25, 8:55 pm

> According to MicroFocus
> in order for an executable to be portable it would have to run on a
> machine that has the same directory structure as the original machine.

That has just taken MicroFocus off my list of usable development
systems.

They seem to have foergotten that the whole purpose of .int is that it
will be portable between different _types_ of systems. One should be
able to compile to a .int on, say, Windows and run it on Unix.

William M. Klein

2005-05-25, 8:55 pm

Check out the INTLEVEL compiler directive. At least it USED to provide this
support and as I read the current documentation, it would (semi-)surprise me if
it doesn't still do so.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117048273.281347.320170@o13g2000cwo.googlegroups.com...
>
> That has just taken MicroFocus off my list of usable development
> systems.
>
> They seem to have foergotten that the whole purpose of .int is that it
> will be portable between different _types_ of systems. One should be
> able to compile to a .int on, say, Windows and run it on Unix.
>

Wiggy

2005-05-26, 3:55 am

Richard wrote:
>
>
> That has just taken MicroFocus off my list of usable development
> systems.
>
> They seem to have foergotten that the whole purpose of .int is that it
> will be portable between different _types_ of systems. One should be
> able to compile to a .int on, say, Windows and run it on Unix.

Richard,

I'd like to get further information on this statement (as in the exact
context, and whom it came from), though my understanding is that this
refers to linked executable files, rather than .int or .gnt code formats.

I can state that applications communicating to RDBMS's are *not*
int-code portable, due to byte-ordering requirements of the code
generated by precompilers (I've had this confirmed from both IBM and
Oracle).

That aside, then per Bill's email regarding the INTLEVEL compiler
directive, and other Micro Focus documentation on creating portable
applications, applications should be int-code portable across platforms.

SimonT.

Richard

2005-05-26, 3:55 am

> I'd like to get further information on this statement (as in the exact
> context, and whom it came from), though my understanding is that this
> refers to linked executable files, rather than .int or .gnt code formats.

I recall having an argument with a Microsoft sales person. She insisted
that I needed to recompile on a target machine and thus would need to
buy another compiler and I told her she was an idiot (or parhaps I was
a little more agressive). I EMailed an extract from the brochure that
indicated that .int could be run an any system within a processor type
(eg Windows to Intel Unix) and she actually rang back and appolgised.

> I can state that applications communicating to RDBMS's are *not*
> int-code portable, due to byte-ordering requirements of the code
> generated by precompilers (I've had this confirmed from both IBM and
> Oracle).

I can see that as both may need COMP-5 to be their way around. However,
what happens when a client program talks to a server and they are not
on the same architecture ?

> That aside, then per Bill's email regarding the INTLEVEL compiler
> directive, and other Micro Focus documentation on creating portable
> applications, applications should be int-code portable across platforms.

Should be yes. In some cases .gnt are too such as between Intel Unix
and Linux.

Richard

2005-05-26, 3:55 am

> Microsoft

Ooops, MicroFOCUS

Wiggy

2005-05-26, 8:55 am

Richard wrote:

> I EMailed an extract from the brochure that
> indicated that .int could be run an any system within a processor type
> (eg Windows to Intel Unix) and she actually rang back and appolgised.

I'll have to check that out -- do you recall where you'd read this?

>
>
> I can see that as both may need COMP-5 to be their way around. However,
> what happens when a client program talks to a server and they are not
> on the same architecture ?

Differences between the client and server architecture aren't really an
issue (to the best of my knowledge). Oracle, for example, expects any
parameters to its' APIs to be passed with a specific byte ordering. They
themselves document this on their MetaLink site, as on Intel- and Alpha-
based platforms, getting this wrong can lead to execution errors.

What I was referring to -- and I apologise for not being clear here --
was (say) precompiling a Pro*COBOL application on Linux Intel, and
attempting to execute the int code on Solaris SPARC. As the
architectures between the two *client* systems differ, you would have to
re-precompile -- and therefore COBOL compile -- on the target client
platform, as the precompilers on those respective platforms generate
different code.

SimonT.

Michael Wojcik

2005-05-26, 3:55 pm

[Reordered for clarity, and missing attribution restored.]

In article <1117068153.402450.316240@g14g2000cwa.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
>
> In article <d731q2$q9b$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, "Wiggy" <wignomore@btopenworld.com> wrote:
>
> I EMailed an extract from the brochure that
> indicated that .int could be run an any system within a processor type
> (eg Windows to Intel Unix) and she actually rang back and appolgised.

I don't believe there's any disagreement here. While many processors
these days can run in either big-endian or little-endian byte ordering
mode, in practice I'm not aware of any pair of platforms currently
supported by Micro Focus using the same CPU but different byte order-
ing. So "within a processor type", the byte-ordering issue Wiggy
mentions doesn't apply, and (given the proper INTLEVEL directive) int-
code should be portable among OSes.

(If we do currently support a pair of platforms with the same CPU but
running in different ordering modes, then there could be byte-ordering
issues in transferring int-code between such systems.)

If a program doesn't have byte-ordering issues (either explicitly or
because of precompilation), then often the int-code produced from it
can be moved even among systems with different processors.

And as Richard notes, this is even possible in some cases with the
same processor family and gnt-code (that is, native code compiled to
a loadable MF COBOL module).

In any event, the OP was complaining about a different issue - hard-
coded paths for dynamic-load module resolution in code compiled to a
native standalone executable - as far as I can tell. As Wiggy noted
in another post, this may be an OS restriction; some Unix platforms
are, in their default mode, particularly aggressive about sticking
path information into executables. I've never seen a case where this
couldn't be corrected in the development environment, and I suspect
the OP may have received some misleading information, but without
more detail it's impossible to say.

--
Michael Wojcik michael.wojcik@microfocus.com

Only the obscene machine has persisted
jerky and jockeying and not knowing why
I have never existed. Nor should. -- George Barker

Richard

2005-05-26, 8:55 pm

> I'd like to get further information on this statement (as in the exact
> context, and whom it came from),

MF site has .pdf brochures which contain statements about .int
portability, such as:

http://www.microfocus.com/000/Datas..._tcm21-2300.pdf

Russell

2005-05-26, 8:55 pm

Wiggy <wignomore@btopenworld.com> wrote in news:d731q2$q9b$1
@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:

> Richard wrote:
>
I haven't tried this with Unix, but you can move an int from the old
workbench 3.1 to Net Express with no problems, even without INTLEVEL. I
suppose that their might be some sort of syntax that could cause trouble,
but I haven't gone looking.

> Richard,
>
> I'd like to get further information on this statement (as in the exact
> context, and whom it came from), though my understanding is that this
> refers to linked executable files, rather than .int or .gnt code
formats.
>
> I can state that applications communicating to RDBMS's are *not*
> int-code portable, due to byte-ordering requirements of the code
> generated by precompilers (I've had this confirmed from both IBM and
> Oracle).
>
> That aside, then per Bill's email regarding the INTLEVEL compiler
> directive, and other Micro Focus documentation on creating portable
> applications, applications should be int-code portable across
platforms.
>
> SimonT.
>
>

Richard

2005-05-26, 8:55 pm

> I haven't tried this with Unix,

You do need to ensure that external names are in the correct format for
the OS being run on, but all my file names, for example, are held in a
system control file so that this is never a problem for me.

Also there are different routines supplied with different run-times so
there are many thinks which could stop .int s from being portable; or
actuall stop source code from creating portable applications.

> even without INTLEVEL.

The defaul seems to be INTLEVEL"2" which is probably maximum
portability.

Russell

2005-05-26, 8:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in news:1117142101.207854.323030
@o13g2000cwo.googlegroups.com:

>
> You do need to ensure that external names are in the correct format for
> the OS being run on, but all my file names, for example, are held in a
> system control file so that this is never a problem for me.
>
> Also there are different routines supplied with different run-times so
> there are many thinks which could stop .int s from being portable; or
> actuall stop source code from creating portable applications.
>
>
> The defaul seems to be INTLEVEL"2" which is probably maximum
> portability.
>
>

Both Workbench 3.1 and Net Express run on Intel, so COMP-5 is okay
on both. I have mostly tried this by accident - I have never tried to
depend on it working. And GNT's do NOT work.

If you did try to get by with compiling to an INT on one system, and
running on another, note that INT's are quite slow. It does not matter
much when dealing with the user interface, but the difference in speed is
quite amazing.

Richard

2005-05-26, 8:55 pm

> note that INT's are quite slow. It does not matter
> much when dealing with the user interface, but the difference in speed is
> quite amazing.

Many years ago I measured performance on CPU bound work and found a 3 x
difference. This may vary with what is being done. As you say, it
doesn't matter much when dealing with UI, nor does it when dealing with
disk or SQL access.

I used .int when running several users on a 1 megabyte RAM 8086 6MHz
machine with Concurrent-DOS. The runtime was shared code and using
..int could get 4 users running. Making it .gnt reduced this to 3 (or 2)
with no noticable difference in performance even on batch jobs.

Moving to 386 and 486 multiuser machines I could get a 3 fold
improvement by changing the disk cluster size from 2Kb to 8Kb on FAT
disk systems.

Richard

2005-05-31, 3:55 am

Michael Wojcik

2005-05-31, 3:55 pm

In article <Xns9662B232731C1rws0203comcastnet@216.196.97.131>, Russell <rws0203nospam@comcast.net> writes:
>
> If you did try to get by with compiling to an INT on one system, and
> running on another, note that INT's are quite slow.

A rule of thumb used by some people who study performance is that on
contemporary general-purpose processors, the worst case for micro-
interpreted code (such as MF COBOL INT code, Java bytecode, UCSD P-
System, etc) is about an order of magnitude performance hit. That
would be for CPU-bound code with a broad instruction spectrum, and
is due largely to cache penalties incurred by having to perform a
table lookup for each byte.

In practice, the actual performance cost for CPU-bound code is
typically significantly smaller (because the instruction spectrum of
typical code is smaller, CPU-bound code is often running in tight
loops that are cache-friendly, interpreted code isn't often used for
processing huge data sets that might stress the data cache, etc).
It's more likely to be a factor of 3-5.

With MF COBOL you have the option of compiling to INT, moving the INT
to your target platform, testing it there, and then compiling it to
native code, of course. This recompile-portable-form-to-native-form
approach is similar to what the OSF was trying to do with ANDF - a
good idea that never really got off the ground. JIT compilation is
flashier, but all-at-once recompilation is a lot more efficient.

--
Michael Wojcik michael.wojcik@microfocus.com

Even though there may be some misguided critics of what we're trying
to do, I think we're on the wrong path. -- Reagan

Russell

2005-05-31, 3:55 pm

mwojcik@newsguy.com (Michael Wojcik) wrote in
news:d7hu2k02q33@news4.newsguy.com:

>
> In article <Xns9662B232731C1rws0203comcastnet@216.196.97.131>, Russell
> <rws0203nospam@comcast.net> writes:
>
> A rule of thumb used by some people who study performance is that on
> contemporary general-purpose processors, the worst case for micro-
> interpreted code (such as MF COBOL INT code, Java bytecode, UCSD P-
> System, etc) is about an order of magnitude performance hit. That
> would be for CPU-bound code with a broad instruction spectrum, and
> is due largely to cache penalties incurred by having to perform a
> table lookup for each byte.
>
> In practice, the actual performance cost for CPU-bound code is
> typically significantly smaller (because the instruction spectrum of
> typical code is smaller, CPU-bound code is often running in tight
> loops that are cache-friendly, interpreted code isn't often used for
> processing huge data sets that might stress the data cache, etc).
> It's more likely to be a factor of 3-5.
>
> With MF COBOL you have the option of compiling to INT, moving the INT
> to your target platform, testing it there, and then compiling it to
> native code, of course. This recompile-portable-form-to-native-form
> approach is similar to what the OSF was trying to do with ANDF - a
> good idea that never really got off the ground. JIT compilation is
> flashier, but all-at-once recompilation is a lot more efficient.
>

That is very true. This avoids the trouble of maintaining source
code on every platform. So long as you keep differences straight (path
names, delimiters, byte order, etc.), than copying the INT only can work
very well. An example of code that works very poorly on Intel Cpu's in INT
code is COMP-5. It flies in GNT, but is VERY slow in INT. At least last
time I checked.

Odd note - Barring the odd tight loop, I have noticed that the
performance gain a program gains from gnt seems to be proportional to the
size gain. A screen bound (character mode) GNT might be almost the same
size as the INT version. But unless you are sloppy, you might as well use
GNT everywhere. INT code does handle some sloppyness better, such as
uninitilized variables. I suppose the fact that MF has been dealing with
this format (INT code) for so many years pays off.

One trick I have been using, which would be handy when using INT code
to handle multiple platforms, without physically copying the source code,
is to check the linkage, and if the linkage is wrong (eg you expect 3
items, but got only two), display a few status items, such as compile date,
target operating system, etc. Using "plain" display without ADIS increases
the probablility that the user will see the message during normal
operation.

Bill Yarnall

2005-06-11, 3:55 pm

Moving INT's to a different machine should be working with no problems. In
the worst case scenerio you might be required to use a specific INTLEVEL
when compiling (just depends on the build version of COBOL and the target
Micro FOcus run time environment)

There shouldn't be any directory structure or pathname issues unless you
have hardcoded directory names in the application.

If you can't get this to work then - You should definately contact Micro
Focus Supportline at 1-800-632-6265 and open a support incident, this should
be working.

<hdumoulin@ups-scs.com> wrote in message
news:1117031303.742945.135800@g43g2000cwa.googlegroups.com...
>I work in an environment where we compile a program on one machine and
> then simply take the .int files and move them to another machine that
> has a different directory structure. This used to work fine until we
> upgraded to MicroFocus Server Express Version4. According to MicroFocus
> in order for an executable to be portable it would have to run on a
> machine that has the same directory structure as the original machine.
>
> We were told that if we do not want to port source code that we could
> port .int programs and then use the cob command to relink them on the
> destination machine. We tried this but the destination machine is still
> looking for the original location.
>
> Please advise. Thanks.
>

Sponsored Links