Using Gen 8.x with COBOL V5 or COBOL V6 compiler
search cancel

Using Gen 8.x with COBOL V5 or COBOL V6 compiler

book

Article ID: 30151

calendar_today

Updated On:

Products

Gen Gen - Host Encyclopedia Gen - Run Time Distributed Gen - Workstation Toolset

Issue/Introduction

Both COBOL 5.x and 6.x have been certified for use with Gen 8.5 and Gen 8.6 Host Encyclopedia (HE) and Implementation Toolset (IT). This document explains the requirements to use each COBOL version with each Gen release.

Note that after upgrading the Gen COBOL compiler library to COBOL 5.x or 6.x, customers experienced compile problems such as insufficient region and/or insufficient temporary dataset sizes. These problems are a result of the increase of compile-time storage requirements in COBOL 5.x and 6.x compared to prior versions of Enterprise COBOL. This document will discuss the PTFs and changes necessary to use COBOL 5.x or 6.x as the Gen compiler as well as document workarounds and fixes.

In order to use COBOL 6.x with either Gen 8.5 or 8.6, you will need to apply the IBM PTFs for Language Environment to support COBOL 6.x. 

If COBOL 5.x or 6.x are to be used with Gen 8.6, no Gen PTFs are necessary unless using tools that need symbolic debug information. 

If COBOL 5.x or 6.x are to be used with Gen 8.5, some Gen PTFs are required.  

Environment

Gen 8.x
IBM COBOL 5.x and COBOL 6.x compilers

Resolution

Gen PTFs for COBOL 5 or 6
The Gen support for COBOL 5.x was added in 8.0 (HE) with the following PTFs:
RO68840, RO68841, RO81026, RO83289
NOTE: There is no support for the 8.0 IT with COBOL 5.x and above.  The 8.0 IT supports COBOL 4.2 and versions below.
NOTE: GEN release 8.0 has reached End Of Service and is no longer supported.

The Gen support for COBOL 5.x or 6.x was added in 8.5 (HE and IT) with the following PTFs:
RO69161, RO69163, RO69164, RO74326, RO74327, RO78374, RO80998, RO83428
NOTE: GEN release 8.5 has reached End Of Service and is no longer supported.

For 8.6: No PTFs are required to use either COBOL 5.x or 6.x with Gen release 8.6 unless using tools that need symbolic debug information.
GEN does not have any enhancements that would benefit from using COBOL v6.3 AMODE 64. GEN 8.6 GA Runtime was built with COBOL v5.1.1 while Upgrade PTFs LU01883-LU01889 and LU01908 recompile Gen Runtime using COBOL v6.2 and only uses 31-bit.

However, the following changes must still be made to update the TIRC2LIB and TIRC2VER values.
Steps needed for Gen 8.0, 8.5, and 8.6 with COBOL 5.x or 6.x:

1. Locate your TIUPARML dataset
2. Edit member TIRHE for Host Encyclopedia, and/or TIRIT for the IT.
3. Repeat the following steps for each member you edit.
4. Locate the line that contains TIRC2LIB= parm pointing to your COBOL compiler library name.
5. Insert the following line, replacing x,y, and z as noted.   
    TIRC2VER=VxRyMz  where x= compiler version, y= compiler release, and z= compiler mod -typically 0.
          Examples:  TIRC2VER=V5R1M0 (for COBOL 5.1)
                             TIRC2VER=V4R2M0 (for COBOL 4.2)
                             TIRC2VER=V6R1M0 (for COBOL 6.1 in CA GEN releases 8.5/8.6)
    Please ensure that the statement begins in column 1 of the inserted line.
NOTE: The above examples are to show how to code the parameter. The values used do not mean that these versions are supported, reference Tech Docs for supported versions.   
6. This will allow host construction to select the correct configuration for your COBOL compiler version.
7. You must perform this update before using host construction with the new COBOL release, regardless of your compiler level.     


IBM COBOL 5.x
Please note that IBM has published the following APARS which relate to COBOL 5.x memory or CPU consumption:
1. http://www-01.ibm.com/support/docview.wss?uid=swg1PI07531
- A large program is unable to complete compiling.
- No amount of adjusting options OPT, MAXPCF, SIZE, NOXREF or job statement's REGION helps.
- Sometimes many warnings are seen prior to the IGYCB7145-U insufficient memory in the compiler to continue compilation.
- Other times only a short list of the compile options are seen. 

2. http://www-01.ibm.com/support/docview.wss?uid=swg1PI25083(this link is no longer available)
- Version 5 CPU usage for problem using opt(2) increased by over 30 times compared with Version 4 using OPT(FULL).

 
Missing TIRC2VER parameter error
If the TIRC2VER parameter is missing from the PARMLIB members TIRHE or TIRIT, a compile of the RI Triggers will receive the following error:
IF &SUBSTR(2,) LE 4 THEN
IKJ56545I THIS STATEMENT HAS AN INVALID &SUBSTR RANGE OR EXIT CODE EXPRESSION
And a compile of the application code will receive the following error:
***** INTERNAL ERROR ******
PRESS ENTER KEY TO CONTINUE.
After this error, the <userid>..IEF.TISYSPRT  will show the following:
TICIBLD: vget failed for TIRC2VER. RC = 84       


IGYPG5062-U and IGYCB7145-U compile errors
Both IGYPG5062-U and IGYCB7145-U compile errors have been experienced after upgrading to COBOL 5.
To resolve these, look at the compiler SIZE parameter (TIRCBLSZ) in the TIRHE or TIRIT PARMLIB member as well as the TSO region.
If no value is specified, the Gen default for COBOL 5.1 compiler SIZE parameter (TIRCBLSZ) is SZ(8192K).
The SIZE parameter for COBOL 5.2 parameter is listed in the Invocation Parameters, but it is ignored and you will receive the following warning:  
        IGYOS4013-I The "SZ" option is no longer supported.
It is recommended to use this default for TIRCBLSZ unless getting an IGYPG5062-U error.  If this error occurs, try to find a TIRCBLSZ value that allows all phases of the compiler to execute.  Avoid setting this value higher than necessary since this can lead to the IGYCB7145-U error by depriving the later phases of the compiler of the memory they need.  The compiler requires a minimum of 200M REGION size to run, so it is possible that enough REGION is not acquired to run all phases of the compiler. If the IGYCB7145-U error is received, increase the TSO region (for foreground compiles) or set the REGION=0M for batch compiles.
NOTE:  Depending upon your site’s logon parameters, you may not acquire the requested region. Verify that you are acquiring the requested region. Look at your TSO session for the requested region. If you were not able to acquire the requested region, you may get a warning similar to:
WARNING - REGION ATTEMPTED IS GREATER THAN PRIVATE AREA

 

IGYCSIMD abend SB37-X'4' or Errors due to insufficient temporary dataset sizes
Compile errors may also occur due to insufficient temporary dataset sizes. To avoid these errors, temporary dataset allocations may need to be increased significantly in member TIUHE/TIUIT.  
Variables defining the primary and secondary block allocations for temporary files are described below:                                                                                      
* TICATRMP  SYSTERM,ALL FUNCTIONS:            PRIMARY 
* TICATRMS                                    SECONDARY
* TICAPR2P  SYSPRINT, COBOL FOR z/OS OUTPUT:  PRIMARY 
* TICAPR2S                                    SECONDARY
* TICAPUNP  SYSPUNCH, CICS PRECOMPILE:        PRIMARY 
* TICAPUNS                                    SECONDARY
* TICACINP  SYSCIN, DB2 PRECOMP OUTPUT:       PRIMARY 
* TICACINS                                    SECONDARY
* TICALINP  SYSLIN, COBOL FOR z/OS OUTPUT:    PRIMARY 
* TICALINS                                    SECONDARY
* TICACICP  SYSPRINT, CICS PRECOMPILE:        PRIMARY 
* TICACICS                                    SECONDARY
* TICADB2P  SYSPRINT, DB2 PRECOMPILE:         PRIMARY 
* TICADB2S                                    SECONDARY
* TICALKDP  SYSPRINT, NCAL LINK-EDIT:         PRIMARY 
* TICALKDS                                    SECONDARY
* TICASUTP  SYSUT1-15,SYSMDECK,ALL FUNCTIONS: PRIMARY 
* TICASUTS                                    SECONDARY
*                                                      

Increase the above said variables to larger values, For example the primary [TICA___P] to 7000 and the secondary [TICA___S] to 5000, as shown below:
TICATRMP=7000
TICATRMS=5000
TICAPR2P=7000
TICAPR2S=5000
TICAPUNP=7000
TICAPUNS=5000
TICACINP=7000
TICACINS=5000
TICALINP=7000
TICALINS=5000
TICACICP=7000
TICACICS=5000
TICADB2P=7000
TICADB2S=5000
TICALKDP=7000
TICALKDS=5000
TICASUTP=7000
TICASUTS=5000

NOTE:
1) These values are suggestions, they could be less or more depending on the size of the Models in your environment
2) Above variables are used during the compilation and NCAL link edit of a COBOL program   
              
If space errors happen when the model is constructed in the background, allocations for the temporary datasets can be increased either by modifying the corresponding values in PARMLIB(TIUHE), PARMLIB(TIUIT) or alternatively space allocations can be overridden using the DD cards in the background construction job.
For example:  If the job fails with below error
IEC030I B37-04,IFG0554A,KV13536C,STEP1,TICCIN,E728,DW0062,  562  

Then, space allocations can be increased for SYSPARM member variables (this example TICACINP, TICACINS) OR space allocations can be increased through the addition of this DD card 
 //TICCIN     DD SPACE=(CYL,(99,10),RLSE)

The DD name is derived by replacing those first 3 chars of SYS with TIC, for SYSPRINT it is TICPRINT, for SYSTERM it is TICTERM, etc.
 
After increasing temporary datasets, if SB37 continue to occur for SYSPRINT DD in the link-edit step, customizations can be made to the CEHBCLS0(TICINSTX) SYSPRINT space allocations. 
After changing CLIST TICINSTX, logoff and login again in order for the HE to pick up the changed values. For example:  In TICINSTX, increase the SPACE parameter to SPACE(500,600).
ALLOC FI(SYSPRINT) NEW &UNIT SPACE(200,40) RECFM(F B A) +
      LRECL(121) BLKSIZE(4840) BLOCK(4840) 


Problem when using tools that need symbolic debug information (e.g., IBM Debug Tool or Fault Analyzer)
After applying the Gen COBOL 5 PTFs one problem occurs when attempting to use tools that need symbolic debug information. In the Gen COBOL 5 PTFs, the Gen program TICCMPD was changed to use the IBM COBOL 5 compiler ddname list. The SYSDEBUG ddname is no longer used by the IBM COBOL 5 compiler, therefore the SYSDEBUG ddname is no longer available in our TICCMPD program. This causes a problem when attempting to use tools that need symbolic debug information, since the debug tools require the SYSDEBUG ddname when compiling COBOL code. If using the COBOL 4.x compiler with tools that need symbolic debug information, then revert back to using the GA version of the Gen 8.0 or 8.5 TICCMPD program. This will allow access to the SYSDEBUG ddname and continued use of tools that need symbolic debug information.

The usage of the SYSDEBUG ddname was added back by IBM in the COBOL 6.2 compiler.  Gen 8.6 PTF SO15712 modified the TICCMPD program to make the SYSDEBUG ddname available again.  With the Gen 8.6 PTF SO15712 applied, the SYSDEBUG ddname is available for use by the COBOL 4.x, COBOL 6.2, and newer compilers.


PTFs required to use the TIUDEBUG trace option
After applying the Gen COBOL 5 PTFs, another problem can happen if enabling the TIUDEBUG trace option.
In order to use the TIUDEBUG trace option, the following PTFs must be applied:
Gen 8.0: PTF RO81026
Gen 8.5: PTF RO80998
Gen 8.6: No PTFs are required to date.
Without these PTFs for Gen releases 8.0/8.5, the following S806 abend will occur:
     CSV003I REQUESTED MODULE TICCMPTV NOT FOUND 
     CSV028I ABEND806-04 JOBNAME=CGIEF#GN STEPNAME=STEP1 
     IEA995I SYMPTOM DUMP OUTPUT 731 
     SYSTEM COMPLETION CODE=806 REASON CODE=00000004 
This abend occurs whether the customer is using the COBOL 5.x, COBOL 4.x or any earlier COBOL compiler.  


PTFs to address increased memory use when Compatibility (CMP) modules are compiled with COBOL 5
Gen 8.0: PTF RO83289
Gen 8.5: PTF RO83428
Gen 8.6: No PTFs required to date.


IBM Documentation for COBOL 5 changes
For information regarding the COBOL 5 changes please reference “Changes in compiling with Enterprise COBOL Version 5.1” which is in IBM’s Enterprise Cobol for z/OS Migration Guide Version 5.1.1: https://publibfp.dhe.ibm.com/epubs/pdf/igy5mg11.pdf
Also: https://www.ibm.com/docs/en/cobol-zos/6.3?topic=cicecv5v6-jcl-packaging-changes-enterprise-cobol-version-5-version-6

Additional Information

1. For current supported COBOL versions with Gen 8.6 please see Gen™ 8.6 > Technical Requirements > Third-Party Software Version which itself references the Gen Compatibility Matrix

2. NOTE: Gen 8.6 PTFs LU01883-LU01889 and LU01908 ("UPGRADE C, C++, COBOL AND DB2 FOR GENERATORS AND RUNTIMES") provide new versions of Gen generators and runtimes that were built with COBOL 6.2. However, to use the Gen 8.6 supported COBOL 6.x it is not a requirement to install those PTFs to use those runtimes or even to regenerate applications if they are applied. That is because of backward compatibility and LE runtime support for multiple versions of language compilers.
The statement on this page covers it in more detail: Host Encyclopedia Construction > DLLs, Compatibility, and Application Migration in HE
===
Changes Made in Gen 8.6 that Impact Migration

This section contains information that enables applications to migrate to Gen 8.6. Some of these Gen applications may have been built by Gen releases that are no longer supported. This information is intended to move these applications to a supported release and in no way implies a change in Support Policy.

Gen 8.6 GA created runtime DBRMs using Db2 V11. Gen 8.6 Upgrade PTFs (LU01883-LU01889 and LU01908) use Db2 V12 to create DBRMs. RPROF runtime is affected by this change.

Gen 8.6 GA COBOL runtime is compiled with Enterprise COBOL V5.1.1 and requires Language Environment runtime support for COBOL V5. Gen 8.6 Upgrade PTFs deliver Gen runtime that is compiled with COBOL V6.2 and requires LE runtime support for COBOL V6.2. However, Gen generated applications that were previously built using a supported version of Enterprise COBOL do not need to be rebuilt to be able to use Gen 8.6 COBOL runtime. Because of backwards compatibility and LE runtime support for multiple versions of language compilers, Gen applications continue to work with existing or rebuilt Gen 8.6 runtime. Gen generated applications and runtime DLLs must reside in the PDSE libraries.
...
===