COBOL routines and VISION:Results Release 6.0
search cancel

COBOL routines and VISION:Results Release 6.0

book

Article ID: 27200

calendar_today

Updated On:

Products

Vision:Results

Issue/Introduction

VISION:Results 6.0 applications invoking COBOL subroutines which execute successfully under prior releases may terminate with S0C4 / U4088 / U0299 abends. These abends occur if the default DYLINSTL parameters are used and the COBOL subroutine was compiled using a compiler that is not compliant with LE (IBM's Language Environment).

 

Resolution

The default settings in R6.0 for the DYLINSTL site parameters LE and COBENV changed from the prior release to reflect the norm in shops adopting to current technology. However, if the VISION:Results application invokes a COBOL routine that is non-LE compliant, the job will abnormally terminate due to that conflict. There are 2 ways to resolve this problem:

  • Recompile the COBOL routine with an LE compliant compiler.
    This is the recommended solution.

  • Change the site parameters:
    The DYLINSTL site parameters may be set as they were for the prior release as LE=N,COBENV=Y using the CUSTMJCL job delivered with the installation SOURCE library. Since the parameters LE and COBENV are mutually exclusive, this combination precludes the default use of LE for all CA VISION:Results 6.0 applications utilizing loadlibs with this site parameter configuration.

    If this method is implemented and there are applications that could benefit from LE, then the OPTION statement may be used to add the LE parameter to the application SYSIN code. Adding the LE parameter automatically turns off COBENV, overriding the DYLINSTL LE and COBENV settings. ( NOTE: The converse is not true; adding NOLE to the OPTION statement will not turn on COBENV.)

SPECIAL CONSIDERATIONS for RESTORE Jobs Upgrading from Release 4.0 or earlier

If the problem job consists of the statement "OPTION RESTORE modulename", then the program is executing a module created using the FREEZE feature. (See the Toolkit Reference Guide, Chapter 3 for a discussion of the FREEZE / RESTORE feature)

The CDA00 driver program which determines LE usage was totally rewritten under Release 5.0. CDA00 is included in the frozen module, so if you want to take advantage of LE, modules frozen under release 4.0 or earlier must be refrozen to pick up the new CDA00. If a COBOL routine is invoked that was regenerated with an LE compliant compiler, but the module was not refrozen, LE will still not be available. The RESTORE job will fail when the COBOL routine seeks the LE environment.

In the release 5.0 Getting Started Manual where LE support was first announced, it stated:
Programs frozen under releases prior to VISION:Results 5.0 must be refrozen using Release 5.0 or later for this parameter to take effect.

The following migration path is recommended for upgrading from Release 4.0 or earlier to take advantage of LE:

Make a table with which COBOL routines are accessed in each RESTORE job.

Run CUSTMJCL using values of LE=Y,COBENV=N as the site standard.
You can omit these from the CUSTMJCL input as they are the default values delivered with the product..

Run CUSTMJCL again with settings LE=N,COBENV=Y and point the resulting DYLPCPS module to a new loadlib.
Concatenate this custom loadlib prior to the VISION:Results loadlib within the STEPLIB or JOBLIB for RESTORE jobs that have not been refrozen and reference non-LE compliant COBOL routines.

As COBOL routines are recompiled with an LE compliant COBOL compiler, all RESTORE jobs that refer to those COBOL routines must have the source refrozen, and the STEPLIB pointing to the old parms must be removed from the RESTORE job.

Eventually, no jobs will be left with the STEPLIB pointing to the custom loadlib with the old parameter values.

SPECIAL CONSIDERATIONS for RESTORE Jobs Upgrading from Release 5.0

The migration path recommended above for releases 4.0 and earlier is also valid for customers upgrading from release 5.0 with a notable exception. As they recompile their COBOL routines, they may simply delete the reference to customized loadlib with the old parameters. Customers upgrading from r5 do not need to refreeze their applications.