COBOL programs and non-COBOL programs can call and be called by PL/I, FORTRAN, and assembler language programs. From your point of view as a COBOL programmer, the coding is the same when you call a program written in another language as when you call another COBOL program.

If your COBOL program is calling, use a CALL statement with a USING phrase that points to the items that will constitute the parameter list. Control is returned to your program at the next statement after the CALL (unless the called program or any program called by it terminates the run unit).

If your COBOL program is being called with parameters, you need a USING phrase on the PROCEDURE DIVISION statement, and a Linkage Section that describes the parameters to be received. Your program can return control with a GOBACK statement (or it can terminate the run unit with a STOP RUN statement). One consideration for you, as a COBOL programmer, is the matching of the parameter lists. If your program is calling a non-COBOL program or service, you must understand what it expects in the way of input, and set up your data items accordingly. If your program is being called, you must know what will be passed, and set up your Linkage Section to accept it. Another consideration for you, as a COBOL programmer, is the treatment of the RETURN-CODE special register. If the called program is a non-COBOL program and does not use register 15 as a return code when returning, then the calling COBOL program's RETURN-CODE special register may be updated with an invalid value. When the RETURN-CODE special register contains an invalid value, it is recommended that you set the RETURN-CODE special register to a meaningful value before your COBOL program returns control to the operating system. Otherwise, an invalid return code will be passed back to the system.

Dynamic calls to the same non-COBOL program using alternative entry points or alias names require the called program to be link-edited with either the RENT or REUS link-edit attributes. When COBOL and non-COBOL programs are to be executed together in a single run unit, the following considerations apply:

COBOL does not permit calling a program that has been called already, but has not yet terminated (that is, executed a COBOL statement or a CICS command for normal termination). It is, therefore, not valid to recall such an active program after an abend has occurred. However, a run unit that has terminated abnormally may be called again, as long as the run-time option NOSTAE has not been specified.

To execute properly, the abend interception mechanism of the non-COBOL program must be ESTAE to be compatible with COBOL. If it is not, unpredictable results may occur in the event of an abend. Also, an abend may result. If a VS COBOL II subprogram is loaded and deleted by a non-COBOL program while the run unit executes, then the COBOL subprogram must be reentrant.

A COBOL program that is dynamically loaded and invoked by a non-COBOL program is treated differently than if it were dynamically called by COBOL. In this case, if the COBOL subprogram was compiled with the REENTRANT option and is also dynamically called by another COBOL program, a separate working storage area is acquired. The program's last-used state will depend on how it. was called. In addition, the COBOL run-time environment will not delete the subprogram at run unit termination.

A non-COBOL program should not invoke a COBOL main program more than once, unless the COBOL program is in initial state when entered. The COBOL main program is in initial state when entered under these circumstances:

  • If the COBOL main program is RENT, it is reinitialized when reentered.
  • If the COBOL main program is NORENT, it is entered in initial state if you:
    • Put it in a separate load module from the invoker,
    • Load it-before entry, and then
    • Delete and reload it before reentry

Multiple run units within the same task are supported by VS COBOL II, as long as all the COBOL programs are compiled with the RESIDENT compiler option. The first run unit within a task starts when the first COBOL program is initialized. A new run unit starts with the first program executed after a LINK. The first COBOL program in each run unit is a main program, unless a reusable run-time environment has been created. When a reusable run-time has been created, the first COBOL program in the first run unit only is treated as a subprogram.

Multiple tasks within the same region are supported for RESIDENT run units only under C1CS. Multiple OS tasks within the same region are not supported by COBOL in conjunction with the Library Management feature (RES option). COBOL does not preclude multitasking if the run units are compiled with NORES. However, any restrictions and conventions of multitasking imposed by the operating system, access methods, and so on, must be observed.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Mainframe Topics