Re: Linking Problem


[Reordered for clarity, and missing attribution restored.]

In article <1117068153.402450.316240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, "Richard" <riplin@xxxxxxxxxxxx> writes:
>
> In article <d731q2$q9b$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, "Wiggy" <wignomore@xxxxxxxxxxxxxxx> wrote:
> >
> > 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 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@xxxxxxxxxxxxxx

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