Historically, CA Easytrieve has had a bug which caused the compiler to use zero as the address of a parsing-related control block. This block was only used when a field definition contained both a VALUE clause as well as a MASK. This resulted in the value at address X'00000016' being tested for various Easytrieve settings by the DEFINE statement parser. Up until the new z9 processors, that byte always contained a value of zero which allowed proper parsing of the DEFINE statement. Now, with the z9 and z10 processors, the address is being used by the operating system and no longer contains a '0' value which causes unpredictable results within the parser routines. The most common results are a system 0C4 abend within the EZTPA22 module or a syntax error (B027) during compilation.
Other Relevant Information
There is an apar for this problem, QO72665, which is available on Support Online. It is written for CA Easytrieve Plus 6.4 0311. Since this bug has always been in our compiler, older versions of CA Easytrieve will encounter the abend or B027 error as well. That is why you must upgrade to Easytrieve Plus 6.4 0311 to be able to apply the apar.
It is important to mention that CA Easytrieve does not have any hooks into the operating system nor does it have any hardware dependencies, so upgrades to either of these are not a problem. This fix was written to correct a bug in our compiler that was, coincidently, uncovered with the new z/9 processor and also applicable to the z/10 processor.