How do I prevent a Cobol program from going into an infinite loop if no match found on 2 flat files?

A Cobol program reads a record from a first flat file and compares it to the first record on a second flat file. However, because the first record from the first flat file does not match any records on the second f开发者_Python百科lat file, the Cobol program goes into an infinite loop. How do I fix it?

Smells like a logic error somewhere in the program. Hard to say what that might be. But I do have a few ideas...

Possible causes of an infinite loop:

• Failure to check end-of-file conditions
• Not reacting to the end-of-file properly
• Testing for end-of-file but assuming all other conditions are 'successful' reads

End of file is sometimes determined by testing the File Status after each I/O operation. File Status is an optional 2 character data item associated with the file being read/written. It is specified in the FILE-CONTROL paragraph of your program. For example:

   SELECT file-name ASSIGN TO dd-name FILE STATUS fstatus

where: file-name is the name you refer to in OPEN/READ/WRITE/CLOSE statements. dd-name is the external file name (the DDNAME from your JCL). fstatus is a two character data item declared under WORKING-STORAGE.

The File Status is set on every file I/O operation. For example:

    READ file-name

sets the fstatus to end-of-file if there were no more records to read. Note that the File Status variable is not actually referenced on the READ, but it is set.

File Status values are two characters and are defined in the ISO COBOL standard, they should be the same for all COBOL implementations. The exception being File Status values where the first character is a '9', these are implementation dependant. Here is a link to the IBM Enterprise COBOL File Status values The value for end-of-file is: '10' - which should be the same for all COBOL implementations.

It is my guess that your program has a File Status for each of the input files, but is not checking it or reacting to it appropriately. For example, your program may only check for end-of-file but not other conditions:

   IF fstatus = '10'
      PERFORM END-OF-FILE-LOGIC
   ELSE
      PERFORM NORMAL-LOGIC
   END-IF

The problem with this approach is that it treats normal returns (fstatus = '00') and all non-end-of-file error conditions as if the READ was successful. Better to have something like:

   EVALUATE fstatus
       WHEN '10'
           PERFORM END-OF-FILE-LOGIC
       WHEN '00'
           PERFORM NORMAL-LOGIC
       WHEN OTHER
           PERFORM UNEXPECTED-ERROR
   END-EVALUATE

There is an imperative form of the READ statement that specifies what to do when the end of file is reached. It goes something like:

   READ file-name AT END PERFORM END-OF-FILE-LOGIC END-READ

Again, if a File Status was specified in the FILE-CONTROL section for file-name and a non-end-of-file error occurred, your program would attempt to continue with 'normal' logic - exactly the wrong thing to be doing.

At end-of-file, the last record read stays in the record area. So if you don't check for an end-of-file situation, your program will not stop running by itself.

For a typical sequential file match at the end of each loop you need to read one of more records.

• If first key >= second key then read from the second file.
• if second key > first key then read from the first file.

There are many variations depending on the one to n relationship between the two files. However you must read something at the end of the loop!