This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RM/COBOL :- File Status = 9847 for Sequential File

Hi - 

I have huge Sequential file. Containing Binary data. One of the record is causing 9847 File Status. 

Problem is :- I cannot delete the record.  This is regular occurrence. Is there any way can I ignore this record and continue processing to next record ?


  • Please show/attach the SELECT statement and the record description.  (you can delete the data names for privacy, but we need to see the structure.)

  • Thanks Tom.

    <<Please show/attach the SELECT statement and the record description.>>

                  ASSIGN TO DISC


    01 AUD--REC. |
        03 AUD--RECNAME   PIC X(12).
        03 AUD--TERMNO     PIC X(2).
        03 AUD--DATE           PIC 9(6) COMP-6.
        03 AUD--TIME            PIC 9(6) COMP-6.
        03 AUD--FUNC          PIC X.
        03 AUD--USER          PIC X(12).
        03 AUD--RELKEY      PIC 9(6) COMP-6.
        03 AUD--DATA            PIC X(4058).

  • OK, thank, Swapnil.

    It is a binary sequential, variable record length file.

    The structure of these files is:
           4 octet binary record length
           binary data for record
           4 octet binary record length

    The record length is both before and after the data record; this allows both READ and READ PREVIOUS.

    My guess is that, for this particular record , something has corrupted the record length counts so they do not match.  If the counts are not equal then the structure of the file is not correct for variable-length binary sequential ==> 98 errror.  Since the structure is unreliable, there is no way to read beyond the record using normal COBOL I/O.

    Depending on how valuable this data might be, you can write a COBOL program to recover the data one byte at a time, using a select/file description of a fixed-length, binary file with record length = 1.  With a bit of COBOL logic, you can read through the file to check the binary record lengths (read 4 records, which determines the number of reads to pass the record, then read 4 more records, to compare the record lengths.  At some point, you will come to a record where the 4-octet record lengths do not match.  Depending on what you see, you can devise some means to pass the record, or rewrite (one byte at a time) the corrupted record length.

    Good luck!

  • In fact, you can determine the exact place in the file where the structure error occurs .  Using the REC-LEN value returned after each READ, you can calculate the zero-relative disk address in the physical file.  Just accumulate all the REC-LEN values, and adding 8 for each record read.  When you get the 98 error, your accumulated value is the address.  If you have some sort of binary file dump capability, you may be able to inspect the file contents directly.

  • Thanks Tom.  This record is not useful for me but I cannot fix this file. As File is shared. Would it be possible to reopen and restart reading from next record. I know the record number where failure is happening.

  • You can not READ forward through this error because the structure is not valid.  However you can do an OPEN...REVERSED and then READ...PREVIOUS and try to 'back into' the same record from the EOF.  (I have never, ever tried this.  It may not work.)

  • REVERSED seems not to be supported on sequential files.

    My previous suggestion was intended to fix the record length counts on the bad record, so that you can read through the record.  There is no random positioning available for sequential files.