Dynamic Link in PL/I and Language Environment

[Maik Opitz]

Hi there!

can someone tell me about Dynamic Linking in PL/1. I work on an S/390
with LE-Compiler. I tried the FETCH and RELEASE. FETCH and CALL worked
fine, but RELEASE gave an U4039 abend. Someone told me about some new
functions for dynamic linking in LE. How can I do an dynamic call
under LE? Is there a way to call COBOL dynamic without a bridge.

Thanks

[S Comstock]

Maik Opitz writes ...

First, it's hard to tell about the failure of the RELEASE without more
information, especially including what programming languages (and compiler
levels) are involved. Generally, it is the presence of a FETCH or RELEASE
statement in a PL/I program that makes calls to the module(s) named in the
FETCH or RELEASE be dynamically loaded. You don't have to actually execute
either statement!

Second, be aware the latest PL/I compilers allow FETCH from a FETCHed module -
something new. What's also new, then, is mixing modules compiled using PL/I for
MVS & VM with modules compiled using Visual Age PL/I for OS/390 & VM; the rule
is: don't do that (although you can sometimes get away with it, you can't count
on it).

Also, the VA PL/I compiler also supports DLL linkages, a new [for the
mainframe] kind of dynamic linkage.

Yes, if you use current COBOL and PL/I compilers, you can call across languages
directly.

<all ads all the time>

There are all kinds of options / features / facilities in LE-level compilers
and products. You can get up to speed (with hands on practice) very quickly by
having us come to your shop and teach our three day course "Inter-Language
Communication in OS/390".

This is a multilingual course (Assembler, COBOL, PL/I, and C) describing how to
accomplish various tasks in each language and how to communicate across
programs written in different languages. Topics include:

Declaring Elementary Data Items
Working with null-terminated strings
Defining Data Aggregates
Working with Halfword-Prefixed strings
Accessing PARM data and setting the return code
Calling subroutines statically
Object code
Passing arguments and receiving returned values
Receiving parameters and setting retur values
The lInkage editor
Alternate entry points
External data
Calling subroutines dynamically
AMODE/RMODE issues
GOFF - the Generalized Object File Format
More about the Program Binder
Multi-Tasking and program reusabiity
DLLs - Dynamic Link Libraries

For more information, check out:

http://www.trainersfriend.com/m220descr.htm

---------------

Related courses that may be of interest:

Application Development Using LE Services (OS/390)
at http://www.trainersfriend.com/m212descr.htm
or
Using LE Services in z/OS
at http://www.trainersfriend.com/m512descr.htm

Visual Age PL/I Differences
at http://www.trainersfriend.com/e204descr.htm

Our LE curriculum is described here:

http://www.trainersfriend.com/lecurric.htm

</all ads all the time>

Kind regards,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com
email: st...@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA

[Maik Opitz]

Dynamic linking with only fetch works fine. But now I have the problem
of the 7 characters modulnames. Our standard are 8 character
membernames. And so the dynamic modul would not be found when
fetching. If I take an 8 character modulname, the compiler gives a lot
of warnings. On the other hand the dynamic call itself works. Is there
any workaround for that?

kind regards

[S Comstock]

Maik Opitz writes...

>Dynamic linking with only fetch works fine. But now I have the problem
>of the 7 characters modulnames. Our standard are 8 character

Pardon me, but that seems a rather strange standard. PL/I has had a maximum of
7 character module names for decades, since it generates separate CSECTs for
instructions and data and gives them names based on the mdoule name + 1
character. Is PL/I new in your shop?

>membernames. And so the dynamic modul would not be found when
>fetching. If I take an 8 character modulname, the compiler gives a lot
>of warnings. On the other hand the dynamic call itself works. Is there
>any workaround for that?

Aside from not requiring 8 character module names? I don't think so.

[Mark Yudkin]

On VA PL/I (aka Enterprise PL/I), use the EXTNAME suboption of the LIMITS
option.

"S Comstock" <scom...@aol.com> wrote in message
news:20020607154803...@mb-bh.aol.com...

[Maik Opitz]

Sorry, I did not make the standards. PL/1 is the old language in our
bank. New standard language is COBOL. It's not a very nice language,
but for banking-applications its enough. We have a lot of old PL/1
programs and have a lot of problems with the static linking of PL/1.
Since you must recompile all main programs, if you change one modul.
And the static link against COBOL-Modules is a problem too. So I tied
to implement dynamic linking. We have no-one, who tied it out before.
So I am the one. And I was looking for a little help on that.
Mark Yudkin told something about EXTNAME option. I've never hear
about. Can someone tell me more?

kind regards

[S Comstock]

Maik Opitz writes ...

Well, it's supported in the compiler Mark mentioned: Visual Age PL/I for
OS/390. There is a later compiler out, Enterprise PL/I for z/OS.

But it sounds like you may be a little down level in your compilers. You need
to be at least at PL/I for OS/390 & VM to be supported, I think.

<ad>
Here is some training we offer along the lines of this thread:

Application Design Using LE Services (3 days)

details at: http://www.trainersfriend.com/m212descr.htm

Using LE Services in z/OS (3 days) - the z/OS version of the above course

details at: http://www.trainersfriend.com/m512descr.htm

-------

InterLanguage Communication in OS/390 (3 days) - requires one of the two
courses above as a prerequisite

details at: http://www.trainersfriend.com/m220descr.htm

Visual Age PL/I Differences (2 days)

details at: http://www.trainersfriend.com/e204descr.htm

--------

We'd love to come and teach some mix of these courses for you.

</ad>

[Shmuel (Seymour J.) Metz]

In <30b071e4.02060...@posting.google.com>, on 06/09/2002

at 03:32 PM, opitz...@arcor.de (Maik Opitz) said:

>Since you must recompile all main programs, if you change one modul.

Only if you're going to a new release of the resident library.

>EXTNAME

I would assume that you use that option if you plan to link into a
PDSE rather than a PDS, and that it allows external symbol names
longer than 8 characters.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action. I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Maik Opitz]

Hi there,

I have tried out the option LIMITS(EXTNAME(8)). In the IBM-Bookshelf I
found some information too. But the result: I think this option is not
supported by out compiler. The LIMITS option will be ignored. Seems
our compiler is a bit to old.

kind regards

[Mark Yudkin]

Going back to an old compiler (please post your compiler and version to make
things easier for us to help you), and trying to understand what you're
trying to do (also not very clear).

Possibility 1: You are trying to call a COBOL routine whose name has 8
chars. You need to define the entry as OPTIONS(COBOL) from the PL/I side. In
this case, OS PL/I and PL/I for MVS supports 8 character external names (see
under "Invoking Cobol or Fortran from PL/I" in the PL/I Programming Guide,
e.g. for OS PL/I V2.3: SC26-4307, p412).

Possibility 2: You are trying to declare a PL/I routine declared in a PDS
member whose name has 8 chars. This is possible, but you will nevertheless
need to restrict the name on the PROC declaration to 7 chars. You may need
to alter the JCL for the link-edit step to assist it locate the member.

Possibility 3: You are trying to invoke a PL/I routine whose name has 8
chars. Unless you're using VA PL/I or Enterprise PL/I, this is not
"possible", as you cannot create such a PL/I routine - its external name
will be mangled down to 7 chars. Since this will occur on both sides, your
code will work, but the external name will be 7 chars on both sides.

- Mark Yudkin

"Maik Opitz" <opitz...@arcor.de> wrote in message
news:30b071e4.02061...@posting.google.com...

[Maik Opitz]

I tried to call a PL/1 module in a PDS with an 8 chars membername. I
also tried to call a COBOL-module with an 8 chars name. Now I fetched
and called this modules with its 8 chars name. And the entry of the
PL/1-module I gave an 7 chars name. And it works. So theres not longer
a problem. The only thing I now have, are lots of compilerwarnings.
The first is IEL0983I because of the 8 chars external names. I think
this should not be a problem. The second is IEL0670I 'The address-mode
of non-automatic argument X may conflict with fetched entry XXXXXXXX'.
As long as all programs run in AMODE 31, this should also be no
problem. I can't resolve this message, because I have pointers as
arguments. This pointers are PCB's for database-calls. Is there any
way to get the messages out?
Our compiler is IBM PL/I for MVS & VM Ver 1 Rel 1 Mod 1.

kind regards

[Mark Yudkin]

AFAIK, there is no way you can get the IEL06701 warning out, but it's
harmelss if you're sure it doesn't conflict and the callee can process
32-bit arguments. By default, the caller (fetcher) cannot tell if the callee
is 24-bit or 31-bit, hence it warns that there may be a problem.

"Maik Opitz" <opitz...@arcor.de> wrote in message

news:30b071e4.0206...@posting.google.com...

[Maik Opitz]

Best Thanks for the fast help. Now all works fine. The warning is OK,
because all our programs run in AMODE 31.

I have one last question: If I call COBOL-modules, is there any way to
give the arguments by content or by reference. In COBOL I can give by
content and the callee can not change my arguments. Can I do this in
PL/1 too?

Kind Regards

[Mark Yudkin]

Feature was introduced with VA PL/I / Enterprise PL/I. Your compiler is too
old. BTW, Cobol also used to be this way - it seems you upgraded your Cobol
compiler, but not your PL/I compiler.

"Maik Opitz" <opitz...@arcor.de> wrote in message

news:30b071e4.02061...@posting.google.com...

[S Comstock]

Maik Opitz writes ...

>
>I have one last question: If I call COBOL-modules, is there any way to
>give the arguments by content or by reference. In COBOL I can give by
>content and the callee can not change my arguments. Can I do this in
>PL/1 too?

I haven't been following all the parts of this thread, but if you have PL/I for
MVS & VM you can fullword fields BY VALUE (must declare the function as ASM,
not COBOL).

Otherwise, you need to build your own copy and pass the copy. [or go to the
Enterprise or VA compilers].

[James J. Weinkam]

Although the BYVALUE attribute is a recent innovation only implemented in
contemporary compilers, all versions of PL/I that I have seen, including the
DOS version, always create a dummy argument for any argument which is an
expression involving either operations or parentheses. This gives the effect
of call by value (or content as the original poster had it). Therefore it
suffices simply to enclose any variable you wish to pass by value in
parentheses.

[Mark Yudkin]

Unfortunately, yiour suggestion is incorrect. Passing an expression creates
a dummy, but passes that dummy by reference. The question concerned calling
a non-PL/I module (here Cobol) with parameters declared as being by value.
This uses a different calling sequence.

"James J. Weinkam" <j...@cs.sfu.ca> wrote in message
news:3D0CF425...@cs.sfu.ca...