File status 23 on READ after START

Question

My question is pertaining to a file status 23, which according to MicroFocus means that upon my attempt to READ from a .DAT file:

"Indicates no record found."

or

"Indicates a duplicate key condition. Attempt has been made to store a record that would create a duplicate key in the indexed or relative file or a duplicate alternate record key that does not allow duplicates."

I have eliminated the fact that the latter is my issue because I'm allowing duplicates in this case.

The reason I'm stumped is that I'm using a START to navigate to the record inside of my .DAT file, and when I execute a READ just after the START has positioned my file pointer, I get the file status 23.

Here is my code:

900-GET-INST-ID.
OPEN INPUT INST-MST.
MOVE FALL-IN-INST TO INST-NAME-REC.
   START INST-MST 
       KEY EQUAL TO INST-NAME-REC
           INVALID KEY
               DISPLAY "RECORD NOT FOUND"
           NOT INVALID KEY
               READ INST-MST
               MOVE INST-ID-REC TO WS-INST-ID
   END-START.
   CLOSE INST-MST.

So when I am running this code my START successfully runs and goes into the NOT INVALID KEY block, and then the very next line executes and my read is null. How can this be if my alternate key (INST-NAME-REC) is actually found inside the .DAT?

I have ensured that my FD picture clauses match exactly in the ISAM Build program and in this program (the reading program).

Answer 1

The second reason you show is excluded not because you allow duplicate keys, but because that error message with that file-status is for a WRITE, and your failure is on a READ.

Here's your problem:

READ INST-MST

Here's how you fix it:

READ INST-MST NEXT

In COBOL 85, the READ statement has two formats. Format 1 is for a sequential read and Format 2 is for a keyed (random) read.

Unfortunately, the minimum READ syntax for both sequential and keyed reads is:

READ file-name

Which means if you use READ file-name the compiler will implicitly treat it as Format 1 or Format 2 depending on your SELECT statement.

READ file-name NEXT RECORD is identical to READ file-name NEXT.

Consult your actual documentation for a full explanation and discovery of possible Language Extensions from the vendor. If you consult closely, the behaviour of READ file-name with no further option depends on the type of file. With a keyed file, the default is a keyed READ. You key field (luckily) does not contain a key that exists, so you get the 23.

Even if it didn't work like that, what would be the point of not using the word NEXT? The compiler always knows what you tell it (which sometimes is not what you think you tell it), but in a situation like this, the human reader can be very unsure. The last thing you want to do when bug-hunting is break off to look at the manual to discover exactly how that behaves, and then try to work it if that behaviour was the one sought by the original coder. The bug? A bug? Intended, but sloppy, code? No-one wants to spend that time, and look, even now, it is you.

A couple of comments on your code.

Look up the FILE STATUS clause of the SELECT. Use it. One field per file. Check after each IO. It'll save you grief.

Once using the FILE STATUS, ditch the imperative parts of the IO statements (the something/NOT something) and replace by tests of the file-status field (using 88s).

It looks like you are OPENing and CLOSEing your look-up file all the time. Please don't. OPEN and CLOSE can be very heavy and time-consuming, so do them once per program per file. If you've done that because of a problem, find a correct resolution to that problem, don't use a hack.

Drop the full-stops/periods except where they are needed. This is COBOL 85, which means for 30 years the number of full-stops/periods required in the PROCEDURE DIVISION have been greatly reduced. Get modern, and take advantage of that, it'll save you Gotcha!s as you copy/paste code, leaving the one which shouldn't be there and changing the way the program behaves.