The RTEREUS option causes the LE runtime environment to be initialized for reusability when the first COBOL program is invoked.

The LE runtime environment remains initialized (all COBOL programs and their work areas are kept in storage) in addition to keeping the library routines initialized and in storage. This means that, for subsequent invocations of COBOL programs, most of the runtime environment initialization will be bypassed. Most of the runtime termination will also be bypassed, unless a STOP RUN is executed or unless an explicit call to terminate the environment is made (Note: using STOP RUN results in control being returned to the caller of the routine that invoked the first COBOL program, terminating the reusable runtime environment).

Because of the effect that the STOP RUN statement has on the runtime environment, you should change all STOP RUN statements to GOBACK statements in order to get the benefit of RTEREUS. The most noticeable impact will be on the performance of a non-COBOL driver repeatedly calling a COBOL subprogram (for example, a non-LE-conforming assembler driver that repeatedly calls COBOL applications). The RTEREUS option helps in this case.

However, using the RTEREUS option does affect the semantics of the COBOL application: each COBOL program will now be considered to be a subprogram and will be entered in its last-used state on subsequent invocations (if you want the program to be entered in its initial state, you can use the INITIAL clause on the PROGRAM-ID statement). This means that storage that is acquired during the execution of the application will not be freed. Since the storage is not freed, RTEREUS cannot be used with SVC LINK since after return from the SVC LINK, the program LINKed to will be deleted by the operating system, but the COBOL control blocks will still be initialized and in storage. Therefore, RTEREUS may not be applicable to all environments. Start of changeRTEREUS cannot be used with z/OS UNIX process or with programs running in AMODE 64. The usage under IMS is not recommended and should be avoided.End of change

Performance considerations using RTEREUS (measuring CALL overhead only): One testcase (a non-LE-conforming Assembler calling COBOL) using RTEREUS was 99% faster than using NORTEREUS.

Note: This test measured only the overhead of the CALL (i.e., the subprogram did only a GOBACK); thus, a full application that does more work in the subprograms may have different results.
Start of change64-bit considerationsEnd of change
Start of changeThe COBOL legacy runtime reuse option is not supported in 64-bit programs. To establish a reusable runtime environment, use the LE Preinitialized Environment feature.End of change

related topics
Upgrading applications that use an assembler driver (Enterprise COBOL for z/OS® Migration Guide)

Related references
RTEREUS (COBOL only) (z/OS Language Environment Programming Reference)
RTEREUS (COBOL only) (z/OS Language Environment Customization)
COBOL and Language Environment® runtime options comparison (z/OS Language Environment Runtime Application Migration Guide)