Jürgen Weber wrote:
Hi,
this certainly isn't the first posting with this subject, but after reading
the old postings I still have a question:
As I understand, the linker allows you to use either dynamic calls or DLL
calls. You can combine the call types if you have the linker create dynamic
calls and code a DLL call yourself using the dllload C runtime library
function. There is a sample for this in the cobol enterprise programming guide:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/4.3.7.3?SHELF=&DT=20050628164603&CASE=
But 4.3.7.2 Calling DLLs from non-DLLs
(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/4.3.7.2?SHELF=&DT=20050628164603)
also speaks about combining a dynamic (NODLL) program (A) and a DLL program
(B) into one load module and have A call statically B. I assume A can make
dynamic calls to other load modules and B can make DLL calls to DLLs.
So, my question is, how do you build the load module containing A+B ?
OK. So let's look at the pieces one step at a time.
You realize these are the possibilities for calling subroutines from
a COBOL program:
1. Static call - the subroutine will be bound (linked) into
the load module of the caller.
To accomplish this, you must compile with the NODYNAM option
_and_ do your CALLs of the form the doc calls "CALL literal",
that is: CALL 'subroutine' [using ... ]; note that whether
you use DLL or NODLL compile option does not matter here.
2. Dynamic, non-DLL call - the subroutine is separately compiled
and bound in its own load module.
To accomplish this, you must either:
a. compile with option DYNAM, in which case all CALLs are
dynamic, non-DLL
b. compile with option NODYNAM but use the form "CALL data-item"
for dynamic calls and "CALL literal" for static - so you can
have some dynamic and some static linkages in the same
calling program
3. DLL calls - which can be accomplished in one of three ways:
a. Implicit DLL calls; simply CALL the subroutine in a DLL;
in this case you must have compiled with DLL (which forces
RENT, NODYNAM)
in this case, you must provide a definition side deck [or
definition side file] at program bind time that is used to
build control blocks for the system regarding where to find
the DLL module when it's needed
b. Explicit DLL service calls; use the helping C functions
* call dllload to cause the DLL to be loaded and get
back a pointer to the DLL module
* call dllqueryfn to get back a pointer to the specific
DLL function you want to call
then calling the DLL subroutine pointed at by this pointer
c. Explicit DLL service calls; use the new helping C functions
* call dlopen to cause the DLL to be loaded and get
back a pointer to the DLL module
* call dlsym to get back a pointer to the specific
DLL function you want to call
then calling the DLL subroutine pointed at by this pointer
If you use these last two approaches, you can compile your calling
program with NODLL, NODYNAM (and PGMNAME(LONGMIXED)); this way your
calls to the C helping functions are static, but your call to the
DLL is a dynamic DLL linkage. And, if you do call a subroutine
using "CALL data-name", it will be dynamic, non-DLL. However, the
DLL itself will not be bound into your load module.
If you compile your calling program with NODLL, NODYNAM, RENT
and call your DLL using "CALL literal", the DLL will be statically
bound to your calling program's load module; calls to the DLL will
be static; calls using "CALL dataname" will be dynamic; the calling
program cannot call any DLLs using DLL linkages; but calls from the
DLL subroutine can be static, dynamic non-DLL or dynamic DLL.
calls from
Hope that makes sense.
With static calls, the statically called subroutine is automatically
included in the load module using the AUTOCALL feature of the bind
step (the SYSLIB DD statement must point to library or directory
where the DLL and other subroutines are found).
Especially, how do you build it under Unix using cob2?
maybe
export SYSLIB='/u/myid/mypgms' <-- assuming this is
where your DLL is
cob2 -o mycobpgm -q"nodynam,nodll,rent" -b"nodll" mycobpgm.cbl
[need to know more about your environment: where are the programs,
etc.]
If you are running z/OS 1.7 or 1.8, you could use the
ld command to build an executable from your already
compiled and bound programs.
(Coming from a Unix
background I have been writing and porting C++ under USS for about a year,
but still haven't touched TSO/MVS/JCL and hope to continue avoiding it ;-).
Why do you insist on limiting yourself? I grew up [technically] thinking
UNIX was the enemy; now I can do both the UNIX and the traditional
mainframe tasks, using whatever tools seem appropriate to the work
at hand.
<ad>
The DLL and CALL stuff is all discussed in our 3.5 day course
"Secrets of InterLanguage Communication in z/OS"; check out:
http://www.trainersfriend.com/Language_Environment_courses/m520descr.htm
The cob2, ld, and related UNIX commands are discussed in our
3 day course "Developing Applications for z/OS UNIX", details at:
http://www.trainersfriend.com/UNIX_and_Web_courses/u520descr.htm
</ad>
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
http://www.trainersfriend.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
