What is the difference between a DYNAMIC and STATIC call in
COBOL?
- 2 Answers
- 12412 Views
- I also Faced
- E-Mail Answers
Answer Posted / pratul singh
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.
Static CALLs
In COBOL, you normally call a subroutine like this:
CALL 'A' USING arguments
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 subroutine.
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 than necessary.
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.
Dynamic CALLs
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 invoked.
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 executable..
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 DLLs.
It's possible to mix versions of your DLLs. This can be a
problem both with distributing your application and with
end-users installing updates improperly.
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 subordinate modules.
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.
| Is This Answer Correct ? | 10 Yes | 1 No |
Post New Answer View All Answers
1.Is it possible to move the data from 99.99 to 99v99? 2.What is the CICS-vsam Compilation process? 3.In My GDG 5 generation will be there GDG3 got an abend what will happen? 4.In my GDG first generation is +1 And I want to add the new generation what will happen previous generation? 5.How can you give the PIC clause below conditions A). s9 (reddy), B). s9 (5) occurs 5 times? 6.How override the proc from a particular step? and what is symbolic and override Procs?
Differentiate between structured cobol programming and object-oriented cobol programming.
How do you reference the following file formats from cobol programs?
how do you reference the variable unblock file formats from cobol programs
How do you get the data to code the BMS macro?
What is the difference between PIC 9.99 and 9v99 in COBOL?
How to use the same COBOL program in Batch and CICS on lines? explain with an example
What is a report item?
What is the difference between goback, stop run and exit program in cobol?
Is it possible that the redefines clause has different picture clauses compared to the one it redefined?
how do you reference the esds vsam file formats from cobol programs
Program A (Normal COBBAT) calling a B Program (DB2COBOL, COBBATDB which is using a VSAM file. its a dynamic call. How we will handle VSAM file decleration in our from JCL from where we are running A PGM. And should we have PLAN for A pGM also. if possible can some one post a sample JCL. Thanks for help in advance.
how we sort two input files based on a common column and giving one o/p file please send me the coding logic?
What is amode(24)?
Define static linking and dynamic linking.
