Static and Dynamic Subroutine CALLs
Keep in mind as you read this, that some compilers let you set options that
will override the calling mechanisms shown below. Therefore, even if your
program is coded to call a program statically, the compiler can convert it to
the dynamic form of CALL if you set (or don't set) the correct compiler options.
This is something to beware of, because it can cause problems for you if you
don't understand the issues.
In COBOL, you normally call a subroutine like this:
The static form of the CALL statement specifies the name of the subroutine as
a literal; e.g., it is in quotes.
This is the static form of a subroutine call. The compiler generates
object code for this which will cause the linker to copy the object module a.obj
into your executable when it is linked.
So, if you modify "A" and recompile it, you must also relink all of
the executables that call "A", because the each of the executables
contains its own copy of "A".
Good Things About Static CALLs
- Fewer files are needed to distribute your application because your
application can be built into a single EXE file, or perhaps an EXE for your
main, and a couple of DLLs for subordinate modules. This generally
makes it simpler to distribute and/or upgrade your end users.
- No risk of mixing/matching different versions of your called subroutines,
because they are bundled into your main program.
Bad Things About Static CALLs
- You must relink all of the EXE and DLL files in your application that use
a statically linked subroutine in order to use the newer version of the
- If your application contains DLLs that call a subroutine statically, each
DLL will have its own copy of the subroutine, including the storage defined
in the subroutine. As a result, your application uses more storage
- If your application has multiple DLLs that use the same statically named
subroutine, each DLL has its own copy of that subroutine and its
storage. Therefore, if you set a value in the subroutine in one of the
DLLs, it's local to that DLL. The copy linked to the other DLLs will
not know about this. This can be either a Good Thing or a Bad Thing,
of course, but it's definitely a trap for the unwary.
In COBOL, the dynamic form of a subroutine call is coded like this:
01 SUBROUTINE-A PIC X(8) VALUE 'A'.
CALL SUBROUTINE-A USING arguments
The dynamic form of the CALL statement specifies the name of the subroutine
using a variable; the variable contains the name of the subroutine to be
The difference is that the name of the subroutine is found in the variable
SUBROUTINE-A. The compiled code will cause the operating system to load
the subroutine when it is required instead of incorporating it into the
Note that you can also load a module dynamically by including it in a DLL and
then linking it using the import library for that DLL!
Good Things About Dynamic CALLs
- You don't need to relink your application if you change something in your
subroutine; only the subroutine DLL needs to be relinked.
- All executables that call this subroutine will share the same DLL; both
the code and data. Since your application only loads one copy of a
dynamically called subroutine, it uses less memory.
- Changes in values contained within the dynamically called subroutine are
available to all the DLLs that use it, because they all share the same copy
of the subroutine.
- You can free memory that a dynamically called subroutine was using by
CANCELing the subroutine. This is, however, not generally of much use
in the 32-bit Windows virtual-memory environment, since Windows will 'page
out' inactive data from the computer's real memory pool anyway.
Bad Things About Dynamic CALLs
- Every dynamically called subroutine must be linked as a DLL (unless you
use an import library to expose other entry points in
a DLL). Therefore, if you application consists of hundreds of subroutines
and they're all called dynamically, you will need to distribute hundreds of
- It's possible to mix versions of your DLLs. This can be a problem
both with distributing your application and with end-users installing
- If one of your DLLs is missing, you may not know about it until the user
exercises some facility that tries to call that DLL. At that point,
your application will terminate abnormally unless you handle this situation.
- If you CALL a DLL, CANCEL it, then CALL it again, you incur more I/O
because the routine needs to be reloaded if you CANCEL it. This can
slow down an application because it requires more disk activity.
Again, in the Windows environment this is usually unnecessary because
Windows does an excellent job of managing memory.
- If you mix and match static and dynamic calls to the same subroutine, your
software might have several different versions in memory at once.
Guess how much fun it will be trying to debug THAT mess?
Which is better, Static or Dynamic CALLs?
The answer is, it depends.
- Static subroutines are nice, because your application can be built into a
single EXE file, or perhaps an EXE for your main, and a couple of DLLs for
- Dynamic subroutines are nice because you can manage memory differently and
you can update a portion of your application by shipping a newer DLL instead
of the entire application.
You really need to consider the pros and cons and how they affect your own
application. For what it's worth, though, we favor using a minimum of
executable modules because it reduces headaches with mismatched or lost pieces
of an application.
Dynamic CALLs via an Import Library
It's possible to create a DLL that contains many
subroutines, but which is accessed as though the subroutines are statically
linked. This is a very neat trick that uses the best features of static
and dynamic linking.