IBM Support

Manual intervention during migration

Question & Answer


Question

Does conversion from CA-Easytrieve or CA-Easytrieve Plus® to COBOL require any manual intervention, or does the IBM Migration Utility handle everything?

Answer

IBM Migration Utility (IMU) converts CA-Easytrieve or CA-Easytrieve Plus® programs automatically. That is, IMU reads program source from SYSIN and does the conversion, initiates compiling and linking as most compilers do.

IMU provides a utility that automatically makes required JCL changes for you, eliminating the need to make manual JCL changes that would otherwise be necessary to make the resulting COBOL program work. These automated JCL changes have to with replacing the original Easytrieve libraries with the IMU libraries.

There are a few issues that can arise from Easytrieve programs which run (or appear to run) correctly, and which are flagged when converting using IMU. These issues fall into two categories, with examples shown below:

1. Incomplete Easytrieve statements

Incomplete syntax issues are due to Easytrieve compilers assuming defaults in absence of certain parameters while IMU needs those missing parameters to ensure an accurate conversion. In such cases the corrective action is to add the missing information, which is very simple to do.

Example:

Problem
I/O error, FILE-STATUS = 39. File definition in the Easytrieve Plus is not compatible with the actual file in use.
Solution
File definition must be changed to match the actual file attributes, for example, when a KSDS VSAM file is not defined as a VSAM file in the program:
EZT definition: FILE VSAMFILE
IMU definition: FILE VSAMFILE VS



2. Real logic errors in Easytrieve programs

Easytrieve allows some sub-standard programming practices to be used which can result in unpredictable or incorrect results, and does not "flag" these issues. IMU does check for these conditions and flags them, pointing out the errors.

Example #1:

Problem
Subscript or index is pointing beyond array range. This Easytrieve Plus demonstrates the problem:

  DEFINE FIELDA  W  10 A OCCURS  55
  DEFINE SUB1    W   2 B VALUE ZERO
   
  DO WHILE SUB1 < 66
      SUB1 = SUB1 + 1
      DISPLAY FIELDA (SUB1)
  END-DO   		

In the above code, logic would attempt to display slot # 66 of FIELDA which obviously does not exist.


EZT Plus would ignore the problem and display incorrect results. COBOL would issue an error if PROCESS SSRANGE is in effect, catching the error that Easytrieve would not.

Solution
66 must be changed to 55.


Example #2:

Problem
MU issues "File &ddname is out of sequence message" on Synchronized file job.
Solution
Files must be sorted prior to using them in Synchronized Jobs. Note that since EZT Plus allows
running with files out of sequence, the outcome is unpredictable, and is likely to be inaccurate. Files out of sequence cannot be matched, therefore MU correctly issues an error. By forcing a sort before synchronized file processing, IMU ensures that the program will provide the correct result when run.

[{"Product":{"code":"SSY4B9","label":"IBM Migration Utility for z\/OS"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Migration Utility","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"4.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
15 June 2018

UID

swg21061098