Problem:
The Micro Focus compiler issued error COBCH118E for this code:
MOVE WS-SKU68-TBL-ROW (WS-SKU55-TBL-IDX) TO WS-SKU68-REC
But this code was not flagged:
MOVE WS-SKU68-TBL-ROW (WS-SKU68-TBL-IDX) TO WS-SKU68-REC
This code was fine on the mainframe. The Micro Focus Cobol compiler does not like using an index for one table as an index for another table. The IBM Cobol compiler does not care. There is a potential for a significant amount of code changes.
Resolution:
Yes, we agree. There is an unknown amount of code written this way, but it is not reliable coding and we are flagging it for good reason so it should be changed as soon as you find it. Please let me explain.
There are actually two errors you may see:
COBCH0399W Index-name belongs to different table
COBCH1118E Index-name belongs to different table
The index used to subscript a table item is not one used in the INDEXED BY clause for this table. The results are unpredictable.
They are documented in our Help:
Micro Focus Enterprise Developer 2.3 for Eclipse > Micro Focus Enterprise Developer 2.3 for Eclipse > General Reference > Error Messages, Syntax Checking Error Messages
At first they seem to be redundant messages, but there is a subtle difference. Error message 399 is a WARNING level message because our Compiler has found an index defined for 'table1' was used to reference 'table2' but both tables are of the same size so we should not have any problems referencing items outside the bounds of either table but there is a possibility of placing an entry into the wrong occurrence of either table so Micro Focus is warning the programmer of this coding. Error message 1118 is an ERROR level message because the index being referenced is for a different table and both tables are defined with different sizes. The potential for a storage overlay or an abend is very real. Attached to this KB article is a zipfile including two compiler listings from Micro Focus and two Compile/Link/Go batch jobs ran on our mainframe for the same program. You will notice that we flag the use as previously stated, but IBM does not flag anything even when it is passed the IBM Enterprise Cobol Compiler Option of RULES(LXPRF) which seems to have defaulted to the same setting as RULES (all sub-options were placed into effect, which is good). But IBM ran the program without error. IBM issued no compiler warnings or errors as well as no runtime errors . But then when IBM is passed the Compiler Option of SSR (SSRANGE), we again see no compiler warnings or errors yet the program abends at runtime and IBM then issues their runtime error:
IGZ0006S The reference to table TBLENT1 by verb number 01 on line 000027 addressed an area outside the region of the table.
When forced to check, IBM checks only at runtime and then tells the programmer that the program has referenced an area outside of the defined boundaries for a table. It is much more cost effective and user friendly to stop a bad compile rather than to let it run wild and abend at who knows when in the application and after an unpredictable amount of processing. Micro Focus flags the bad code during the compile allowing the programmer to correct the coding immediately.
But despite this being bad coding, we understand there are times when one has to realize it is bad and press on for a short time. So if you review the second Compiler listing from Micro Focus, you will see that we allow one to change the ERROR to a WARNING with the CHANGEMESSAGE directive, but be very cautious because that does not mean we now generate 'good code'. We will just allow the code to be generated for whatever the programmer has chosen and let it run. And that means the user program stands a good chance of abending in the Micro Focus environment.
The attached zipfile, Sameidx.Zip, contains these files:
Sameindex.Cbl Cobol source
SameIdxList1.Txt Micro Focus Compiler listing using defaults, both messages are output
SameIdxList2.Txt Micro Focus Compiler listing using CHANGEMSSAGE(1118 W)
ZOSCLG1.TXT IBM Compile, Link, Go job passing RULES(LXPRF) but showing no errors and apparent good output
ZOSCLG2.TXT IBM Compile, Link, Go job passing SSR, program abends and a dump is taken
So please remember, just because it 'runs on the mainframe', it does not mean it ran correctly.
#EnterpriseDeveloper
#MFDS
