#764 INPUT not reserved word in DEBUGGING MODE

[Edward Hart]

INPUT is not recognised as a reserved word when DEBUGGING MODE is specified and the reserved word DEBUG-NAME is enabled. Example code:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DB104A.

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER. GNU-Linux WITH DEBUGGING MODE.

       PROCEDURE DIVISION.
           OPEN INPUT GEN-FILE
       .

Expected output is an error that GEN-FILE does not exist. Actual output is an syntax error saying INPUT (or other OPEN modes) is expected.

This bug is causing some of the NIST tests to fail.

A first look shows that INPUT and DEBUG-NAME are given keys 39 and 38, respectively, in the reserved word table, suggesting an off-by-one error.

[Edward Hart]

Fixed in [r4355].

The issue is due to DEBUG-NAME and INPUT having the same hash. DEBUG-NAME is saved first into the reserved word table (with key 38). INPUT is saved after (with key 39, since 38 is taken by DEBUG-NAME). When DEBUG-NAME was removed after parsing DEBUGGING MODE, 38 is now a valid key for INPUT. However, the reserved word info for INPUT was still at 39 and had not been adjusted.

The fix was to check all entries (up to the next NULL) following a deleted entry and move them, if needed, to the empty key.

[Arnold Trembley]

When you check all the subsequent entries, do you also check each subsequent entry to see if it is already in its correct hash key location?

Is there a risk that a reserved word could be moved up to an incorrect key location?

Hash table collision is an interesting problem that does not come up in typical COBOL applications programming!
https://en.wikipedia.org/wiki/Hash_table#Collision_resolution

Kind regards,