Linking Problem

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.

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.

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

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

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.

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

> Microsoft

Ooops, MicroFOCUS

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.

[Reordered for clarity, and missing attribution restored.]

In article <1117068153.402450.316240@g14g2000cwa.googlegroups.com>, "Richard" <riplin@Azoni
c.co.nz> writes:
>
> In article <d731q2$q9b$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, "Wiggy" <w
ignomore@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

> 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