Optimizing COBOL calls by VISION:Builder, VISION:Two, VISION:Inform, VISION:Transact
search cancel

Optimizing COBOL calls by VISION:Builder, VISION:Two, VISION:Inform, VISION:Transact

book

Article ID: 31054

calendar_today

Updated On:

Products

Vision:Builder Vision:Inform VISION:Transact VISION:Transact for IMS Vision:Two

Issue/Introduction

Summary:

If the first program in an application is not COBOL, there can be significant degradation if COBOL is repeatedly invoked as a subprogram since the COBOL environment must be initialized and terminated each time a COBOL main program is invoked.  This is the case each time VISION:Transact, VISION:Builder, VISION:Two or VISION:Inform calls a COBOL subroutine via a CALL statement. (Hereafter the 4 products will be referred to as VISION:suite)     

 

Instructions:

The overhead can be reduced by using any one of the following methods:                                                                           

·        Use the run-time option LIBKEEP.  The LIBKEEP option maintains the partition level of the run-time environment between calls to COBOL main programs (or calls to COBOL routines from a non-COBOL program).  LIBKEEP is specifiable only via the IGZEOPD IBM installation default option macro.     

·        Use the run-time option RTEREUS to initialize the COBOL environment for reuse which makes all COBOL programs which are called by VISION:suite subprograms.  RTEREUS initializes the run-time environment for reuse when the first COBOL program is invoked by the VISION:suite application.  RTEREUS can be specified only by the IBM IGZEOPD installation default option macro or the    IGZOPT application specific run-time option macro.  If RTEREUS is specified via IGZOPT for a program other than the first COBOL program invoked, it will be ignored.  This option recommends all COBOL  STOP RUN  statements be changed to GOBACK in order to get the benefits of RTEREUS.  Also, this option affects the semantics of a VS COBOL II main program, meaning that storage acquired when the application executes will not be freed.  Main programs are considered subprograms entered in the last used state.      

·        Call ILBOSTPO from the first program (VISION:suite) to make it appear as the COBOL main program.  Calling ILBOSTPO is provided for compatibility with OS/VS COBOL; calling IGZERRE is preferred over calling ILBOSTPO in COBOL II.  

·        Call IGZERRE from the first program to make it appear as the COBOL main program and to initialize the COBOL environment for reuse. Thus, the VISION:suite application would call IGZERRE before any other COBOL subroutines were called.  IGZERRE must be called with specific register contents as documented in the IBM VS COBOL II Application Programming Guide.  A COBOL  STOP RUN  statement returns control to the caller of the routine that invoked the IGZERRE initialization (VISION:suite).  Calling IGZERRE affects the semantics of a COBOL II main program which means that storage acquired when the application executes will not be freed.  Main programs are considered subprograms entered in the last used state. 

·        Call the first program (VISION:suite) from a COBOL stub program.  The COBOL stub program only contains a call statement to the first program (VISION:suite).

·        Compile the COBOL routines as RENT and NODYNAM and link as RENT and REUSE. The assembler interface linked with both AMODE and RMODE 24.                                                      

Refer to the VS COBOL II Application Programming Guide sections, 'Calling COBOL from a non-COBOL program', 'Calling IGZERRE', 'CALL ILBOSTPO' and 'Initializing the Run-Time Environment for Reuse'.  

Also note that when an application is running under IMS, preloading the application program and the COBOL library routines can help to reduce the load/search overhead as well as reducing the I/O activity.    

Environment

Release:
Component: V:BLDR