Another view of the diff between Static & Dynamic calls

Hari Koteswararao · New User Joined: 09 Mar 2010 Posts: 1 Location: Kolkata

After reading a very old thread, Difference between Static Call and Dynamic Call in COBOL,
I am going to explain with an example: Main program:PROGA, sub prog:PROGB.

1.In this case if you use CALL PROGB USING A,B,C; It is call static call
if you move sub prog name to some WS variable and
CALL WS-VAR USING A,B,C---It is called Dynatmic.
2. in static call if you made any changes in sub program you have to compile all the programs. but in Dynamic call need to compile only the changed programs.
3.in static call all the sub modules are link edited with main load module
where as in Dynamic call created different loadmodules.

Karthikeyan Subbarayan · New User Joined: 24 Feb 2008 Posts: 62 Location: Boston

I dont think calling a Sub program with some WS variable is a Dynamic call.
some additional info.
Dynamic
1) If the subprogram undergoes change. Recompile of sub program is enough
2) Sub routine picked during run time form load library
3) Program will be in the initial state every time.
4) Size of load module will be less.
Static
1) If the subprogram undergoes change. Recompile of sub program & main program is required
2) Sub module link edited with main module
3) Program won’t be in the initial state.
4) Size of the load module will be more

dick scherrer · Posted: Thu Mar 11, 2010 11:14 pm

Hello,

Terry Heinze · Posted: Fri Mar 12, 2010 9:36 am

Note also that the DYNAM compiler option will cause a CALL literal to be a dynamic CALL instead of a static CALL. See Programming Guide for details.

Ronald Burr · Posted: Fri Mar 12, 2010 10:02 pm

Note, too, that in a STATIC call environment, if you change and re-compile a sub-program it is really not necessary to re-COMPILE the MAIN program, it is only necessary to re-LINK ( re-bind ) the main program - to replace the (obsolete) sub-program in the statically-linked executable.

Additionally, in a DYNAMIC call environment, a sub-program will not necessarily be in its initial state on every call unless a) a CANCEL statement has been issued prior to each CALL, or b) the sub-program has been compiled with the INITIAL attribute. In fact, there is no guarantee that the sub-program will be in its initial state even on the first call, if the sub-program was compiled with the RECURSIVE attribute, since there could be a "used" copy of the module in-core at the time of the call.