LINK-EDITING PROGRAMS THAT USE CALLS - IBM Mainframe

Whether you use static or dynamic calls, and whether you request reentrant code, determine the options you will use to compile your programs. The RENT, RESIDENT, and DYNAM compiler options have special uses for subprogram linkage.

Resolution of External Names and References

Each time an entry point is specified in a VS COBOL II program, an external name is defined. An external name can be referred to by another separately compiled or assembled program. An external reference is a reference to a symbol that is defined as an external name in another separately compiled or assembled program.

  • With NORESIDENT - There are external references to all library routines required.
  • With RESIDENT - There is one external reference to a library routine.
  • With NODYNAM - There are external references to any statically called subprograms and no external references to any dynamically called subprograms.   
  • With DYNAM - There are NO external references to any called subprograms, because all calls are dynamic.

NORESIDENT (always NODYNAM)       

The main program, all subprograms, and all library routines they reference are link-edited into a single load module for execution. For the called/calling situation the COBOL Library Management Feature is not in effect, and all CALL statements result in static calls that must be resolved by the linkage editor. Dynamic calls are not supported with the NORESIDENT option, except through the use of the MIXRES run-time option and the IGZBRDGE macro. Compile each program, then link-edit. Only one load module is produced. The NORESIDENT/NODYNAM set of options should be used only when the user does not intend to use the CALL identifier or CANCEL statements or the Library Management Feature. If either a CALL identifier or a CANCEL statement appears in any one program, the Library Management Feature will be put in effect for that program only. This situation may result in an error, thereby causing unpredictable results. Do not intermix RESIDENT and NORESIDENT programs in a run unit.

RESIDENT and NODYNAM

The program, one library routine, and any subprograms called by CALL literal statements are link-edited into a single load module. (Any subprograms called by CALL identifier statements should be in separate load modules in a library that is accessible at run time.) When RESIDENT and NODYNAM are specified a dynamic situation can nevertheless occur because of the inclusion of CALL identifier in the calling programs. That is, because the name of the called subprogram is not available until run time, a static call could not be used. The programs are compiled and link-edited. The CALL literal statements included in program result in static calls that must be resolved by the linkage editor. Therefore, the program units are linked as a single module. However, with the COBOL Library Management Feature in effect, linkage to the library is dynamic. That is, most of the required COBOL object-time library routines are not link-edited, but linkage is effected dynamically at object time.

RESIDENT and DYNAM

The program and one library routine are link-edited into a single load module. (Any called subprograms should be in separate load modules in a library that is accessible at run time.) When both RESIDENT and DYNAM are specified for the called and calling programs, the main program is compiled and link-edited, and each of the subprograms is compiled and link-edited separately, thereby producing separate load modules.

Link-Edit Attribute Requirements

If the load module will contain COBOL program(s), all of which have been compiled with the RENT compiler option, link-edit with the RENT link-edit attribute. (Use the REUS link-edit attribute instead if the toad module will also contain any non-COBOL programs that are serially reusable.)

If the load module will contain any COBOL program that is compiled with the NORENT compiler option, do not link-edit with either the RENT or REUS link-edit attributes. (The non-serially reusable option is needed to ensure that the CANCEL statement will guarantee a fresh copy of the program upon any subsequent CALL.)

Calls to Alternate Entry Points

Static calls to alternate entry points work without restriction. Dynamic calls to alternate entry points require:

    • NAME or ALIAS linkage editor control statements.
    • The NAME compiler option.
    • An intervening CANCEL for dynamic calls to the same program at differing entry points. CANCEL will cause the program to be invoked in initial state when it is called at a new entry point.                  

Enhancing Performance

You can enhance the performance of your program in several ways. These include using the L1BKEEP run-time option, invoking top-level programs as subprograms, using COBOL program stubs, and others. LIBKEEP is a- run-time option used by the OS RES environment (only) to maintain the partition level of the run-time environment between calls to COBOL main programs. This level of the environment is maintained from invocation of the first COBOL program in a task until the task is terminated. The partition level contains the partition level control blocks, portions of the thread level control block, and all the library routines that have been loaded at that time. LIBKEEP is specifiable only via the IGZEOPD installation default options module.

Invoking Top-Level Programs as Subprograms - Within a single run unit in anon-CICS environment, you can invoke your 'top-level' processing programs as subprograms to improve performance. This can be done either by:

  • Placing a COBOL program stub as the first program in your application
  • Creating a reusable run-time environment with:
  • The RTEREUS run-time option
  • The IGZERRE run-time library routine
  • The ILBOSTPO run-time library routine.

When you use any of these methods to invoke top-level programs as subprograms, these restrictions apply:

  • The programs must be written to expect re-invocation in their last-used state. That is, they must be self-initializing.
  • The programs cannot be deleted and reloaded between invocations.
  • The main storage required by the programs is not released upon return (until the run unit is terminated) and will accumulate when multiple top-level processing programs are invoked.
  • To maintain this form of environment, do not use STOP RUN. You should use GOBACK instead. When a LINK SVC is issued (under MVS only), a new secondary run unit is created. The top-level program of this new run unit is treated as a main program rather than as a subprogram. Therefore, when this program is re-entered (after a GOBACK), it is re-entered in initial state rather than in last-used state. A LINK SVC does not propagate any reusable run-time environment that may have been created.

If the LIBKEEP function is in effect, it is not canceled. However, it is superseded by whatever method is being used to invoke the top-level program as a subprogram for as long as that method is in use. In the RES environment, if you use any of the methods (a COBOL stub program, RTEREUS, IGZERRE. or ILBOSTPO), and if a COBOL program is invoked prior to the invocation of SORT, it cannot be re-invoked from a SORT exit. Also, if a COBOL program is invoked from within a SORT exit, then it cannot be re-invoked after the SORT terminates. For the above reasons, it may not be suitable to invoke top-level programs as subprograms in some environments.

When RTEREUS, IZGERRE, or ILBOSTPO is used to create areusable run-time environment, the non-COBOL caller will act like the main COBOL program, " STOP RUN is executed, control returns to the caller of this non-COBOL program. The program where control is returned must follow the requirements of any program that calls a COBOL program.


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

IBM Mainframe Topics