For Batch programs we can use Dynamic, static calls. Static call is advisable when less storage is needed i.e., subprogram is called few times. Otherwise use Dynamic call.
Dynamic called program will be loaded into storage when it is called where static called program will be loaded regardless of when it is called.
I am not sure, but I heard, Online Programs (CICS) will prefere only static call.
Joined: 23 Feb 2006 Posts: 305 Location: Hyderabad,India
The main difference between static and dynamic call is the time at which the load module of a subroutine gets invoked or gets attached to the load module of its main program. To get a better picture, let us take an example.
Let A be the Main Program, and this main program invokes the subroutines X, Y and Z. We would have coded the modules X, Y, Z and would have compiled it before executing A.
Static Call:
Now, a static call to the modules X, Y and Z means attaching the load modules of X, Y, Z to the load module of A. It?s like creating a single pack which contains all the load modules needed to execute a higher level program which calls many other programs. This can be done by specifying the compiler option "NODYAM" while compiling the program.
All the load modules of sub routines are embedded within the load module of the main progam.
Dynamic Call:
A dynamic call to the modules X,Y and Z means that you will not attach the load modules of X,Y, Z to the load module of A. The load modules of X,Y and Z will lie in a separate library and the load module of A will lie in a separate library. You will just refer to the library in which the load modules of X,Y and Z lie, while executing the program A. So when ever the subroutines X or Y or Z are invoked in the program A, the library which is specified will be searched for the load modules. By mistake, if the library of the subroutine does not contain the referred program, the system standard library will be searched. If the program is not found in standard library too, the programs will abend. This can be done by specifying the compiler option "DYNAM" while compiling the program.
Performance Comparison of Static Call and Dynamic Call:
Both Static call and Dynamic Call are advantageous depending on various parameters.
1) If your subroutines involve frequent changes, then static call will be a burden. Since the load module of the subroutine is embedded inside the load module of the main program, when ever you recompile the subroutine, you should relink(Process of replacing the old load module with new one) the main program. This surely will be a burden.
In dynamic call, it?s enough if you recompile the sub-routine and put it in the specified library. The new load module will be invoked automatically from the library specified.
2) On the other hand, statically called programs take less time to execute. The overload of searching the library and then invoking the required load is not present in case of static calls.
So, depending on our application need both static calls and dynamic calls are advantageous.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
The exaggeration of time required to LOAD dynamically linked modules has caused many shops to stay with the MF-DOS mentality of statically linked modules. With RUN-UNITs of short duration, one can see an extra nanosecond or two, but with long running programs, this 'OVERHEAD' is obviated thru the ease of maintainance. Change a module in a dynamically linked environment, you only have to compile and relink the module in question, without the 'OVERHEAD' of relinking the complete RUN-UNIT. Plus, you never really know what module will be CALLed in a static environment - depends on when the RUN-UNIT was last linked.
You do not have to make your sub-modules into DLL's. Though that hyperlink provided by viv was very informative, it stressed the DLL and made little or no mention of simple dynamic COBOL CALLs. Code a CALL with a reference (containing the CALLed modules name) instead of hardcoding the module name in the CALL and you are sure of a dynamic CALL. Sub-modules are linked as dynamic (link and compile parms).
I have consulted to more than 20 shops since the 1980's, which was the last time I dealt with the MF-DOS statically linked RUN-UNIT convention.
With the availability of the COBOL CALL from within a CICS module, statically linking the COBOL portion of the load unit is not advised. I have been part of projects that wrote the business logic with dynamically CALLed COBOL modules (from CICS modules that performed the front end - msging, screen processing, etc..). The business logic entailed 1000+ modules, which could be used - without change - by batch drivers.
If possible, I would stay away from static CALL design.
.jpg)
