Monday, 28 July 2014


In today's tutorial, you will learn CALL VERB. CALL statement in COBOL is used to call the sub-program from the main program. You will recall that structured programs should consist of a series of independent modules that are executed from the main module. So, without wasting time lets start with the tutorial.

What is CALL VERB or CALL Statement in COBOL?

The CALL verb is used to transfer control (program execution) to an external, independently compiled subprogram or a contained subprogram. When the subprogram terminates, control reverts to the statement after CALL. 

Why Use a CALL Statement?

Modules within a program can be viewed as subroutines that are called or executed from the main module. But a program may also CALL or reference independent subprograms stored in a library that are entirely separate from the main program itself. The main program that references or calls a subprogram is referred to as the calling program. The subprogram that is linked and executed within the main program is referred to as the called program.

Main (or user or source) program: Calling program

Subprogram: Called program

The called program would need to be compiled, debugged, and catalogued or stored in a library so that it may be called when needed. Typical subprograms that may be used by numerous calling programs include edit routines, error control checks, standard calculations, and summary and total printing. Some programming languages use the term "external subroutines" to refer to these; the term "subprogram" is used in COBOL.

Format of the CALL VERB / CALL Statement.

CALL literal-1 [USING identifier-1 . . .]


Avoids duplication of effort: When modules need to be included in more than one program, it is best to write them separately and call them into each program as needed.

Improves programmer productivity: Programmers can "specialize" or code modules that make use of their specific talents or skills.

Provides greater flexibility: Subprograms may be written in any programming language; they are typically written in a language best suited to the specific task required.

Changes to the called program can be made without the need to modify the calling program.

Results in greater standardization.


When testing a program that updates an indexed file, it is best to always begin the test run with a "clean" copy of the initial indexed file. In this way, you can manually determine what the updated file should look like and debug your program accordingly until the actual results obtained are as expected. If you create the initial indexed file and update it in a test run, and then test the program again with the changed file, it is more difficult to know what the initial values were and what the end results should be.

It is, therefore, good practice to include a CALL statement in the update program during the debugging phase that creates a clean copy of the initial indexed file. If this CALL is always executed before an update test run, then you always know what the starting values are in that indexed file. Once the update program is fully debugged, you can remove the CALL statement.

No comments:

Post a comment