GENERIC browse and NOTFND

[orojas]

1) STARTBR GENERIC EQUAL

2) READNEXT (Normal)
first keylen positions of RIDFLD contains the same generic key

3) idem than 2) for several records

4) READNEXT (Normal)
but!!! content of RIDFLD is not the generic key.

I expected NOTFND in that circumstances.
If not what is the purpose of a GENERIC EQUAL option?

Bye, Oscar Rojas.

 

[harisnair]

NOTFND error comes for the end of the file.

 

[orojas]

Thanks for your answer, that clarifies me that if it is not end-of-file I can't expect NOTFND.

But... my concern still is valid... when the group (generic key) is exhausted and there are more records in the file, CICS returns NORMAL, ie, it is no notification about the fact that the generic key has changed. So, the programer must test for both: NOTFND (CICS conditon) and RIDFLD not equal to the browse key (data condition). Not a big deal, but then I don't see any advantage in using generic keys for browsing.

 

[harisnair]

Let me go a little bit more on NOTFND. NOTFND usually comes when u move high-values to ur browse key and do a READNEXT..and to the funnier side, I dont find it reasonable or logical for anyone to do this way...So i dont think u have to look for NOTFND condition. Instead u can look for ENDFILE.

As orojas has said, except comparing the RIDFLD with browse key always, I dont see any method to find out the end of ur browse key records in the file (when the group (generic key) is exhausted).

Then we must use Generic keys to search a file if we dont know the full key...so i cant agree to ur statement "but then I don't see any advantage in using generic keys for browsing."

let me know if any contradications....

 

[gregsimpson]

In general I agree with the above POSTSA but I think there is some confusion here between a file browse and a direct read. It is possible to get a NOTFND from a direct read, although I appreciate this doesn't particularly help you in your Browse routine

Suppose TSTFILE contains two records beginning with A, no records beginning with B, and one record beginning with C. Suppose also that the search argument for the file is set up in this way.

IF the following READ command with the EQUAL option is executed the NOTFND condition will be raised. This tells your program that no record beginning with B is on the file.

EXEC CICS
READ
INTO(WORK-AREA)
LENGTH(RECORD_LENGTH)
DATASET(TESTFILE)
RIDFLD(KEY-B)
GENERIC
KEYLENGTH(GENERIC-KEY-LENGTH)
EQUAL
END-EXEC

On the other hand if GTEQ is substituted for EQUAL in the same command, the record beginning with C will be returned.

Returning to the browse processing, if the equal parameter had been specified as above as part of a STARTBR, NOTFND would also be returned in this instance.

I hope that has cleared up the confusion, it doesn't stop you from having to do your comparison to the RIDFLD but does explain when you get NOTFND from a GENERIC read.


Cheers
GREG

 

[ciczman]

Oscar,
Kind of late but just in case...

To answer the last question, why you would not receive a notfnd response. There are several conditions that could arise, but initialy I would verify the value of your RID. It would depend on if you were using a generic RID and if you adjusted the keylength to correspond to the RID if going from a generic to the full RID.

Another gotcha could be the timing of when the RID is updated.

The generic equal search is a oxymoron anyway. Because generic processing is for positioning to prepare for retrieving the next record for obtaining the information that your really interested in. If you knew the key you would have supplied the whole key and search for that in the first place.

Bottom line is it's always best to code for anything and everything that could occur, because at some point in time it does.

Hope this helps!