views:

546

answers:

1

On the mainframe using Enterprise Cobol for z/OS, is it possible to dynamically CALL a Cobol Dyamic link library (DLL) program from a cobol program that has been compiled with NODLL?

+2  A: 

There are a number of ways to do what you want.

If, by "dynamically CALL", you mean call via a data definition variable, I don't think you can do this with the linker/binder since the binder needs to know the target functions at bind time. You have to specifically dllload the DLL load module, dllqueryfn the function and call it that way.

To use the linker/binder, I believe the following steps are required (P1 is the NODLL COBOL program doing the calling, P2 is the DLL program being called):

  • P2 must be compiled and bound with the DLL option.
  • P1 must be compiled with NODYNAM and bound with DLL.
  • P1 must contain "CALL 'dll-func' (i.e., literal calls only).
  • When binding P1, SYSLIB must first point to the P2 location.

This will cause the binder to incorporate both P1 and P2 into a single load module which is not exactly DLL calling but I don't think there's any way around that other than the dllload/dllqueryfn solution.

I've used the older-style dll-functions but, if you're at a high-enough level, there are also the newer dlopen/dlsym C helper functions.

This page seems to provide support for my contention that NODLL/DLL programs can only call each other if bound into a single load module. You still have to use static calls however.

This page seems to offer up another option where you can put the DLL program into the same load module as the calling program and use static calls to get to it. It seems that the DLL program can call other DLL programs not in that load module. So it may be possible to provide a static gateway function in the DLL program that can dynamically call a DLL function not in the load module. This is beyond anything I've ever done on the big iron so you'll have to experiment.

Both those pages are from the publib-boulder sites which everyone using an IBM product should know about (along with the redbooks/redpapers site as well).

Me, I prefer the dllload/dllqueryfn solution since that's what I'm used to from AIX and other UNIXes and it seems to provide maximum flexibility.

paxdiablo
@Pax: Thank you for your good answer. +1 and green mark.
Kb