Record existence
AS/400 records, CHAIN
How do you know if a record exists without doing a READ and CHAIN? Question
AS/400 records, CHAIN
How do you know if a record exists without doing a READ and CHAIN? 
Subscribe to Alerts! Get questions and answers delivered to your Inbox.
Answer Wiki (Improve, edit or add to this answer)
RATE THIS ANSWER
+1
Click to Vote:
+1
Click to Vote:
- 1
0
Hi,
I'm assuming you're using RPG.
If you have an exact key, you can use SETLL and check the equal indicator returned. Or you can use an sql SELECT COUNT(*) FROM FILE INTO :COUNT and check whether :COUNT isn't zeros (although I wouldn't go down this route unless you need SQL in your program for something else).
Regards,
Martin Gilbert.
Use SETLL in conjunction with %EQUAL built in function
Key SETLL file
If %EQual
* a matching record has found
END
Hi from PGMBOB
If you do not care about keys and have a CLP program running before your RPG.
RTVMBRD - Retrieve member description can return the record count in the file.
check the value and skip the program if it is zero.
ALSO
the file informational data structure has informatiooon but you might need to read a record before the statistics are available in the program. Check the specifications. The information for different file types is in different locations.
Good Luck!
PGMBOB
Browse more Questions and Answers on AS/400.
Looking for relevant AS/400 Whitepapers? Visit the Search400.com Research Library.
Discuss This Answer
You must be logged-in to discuss a question. Log-in/Register
GreenleeB | Jul 23 2008 3:52PM GMT
You don’t explain what you are doing or your objection to doing a CHAIN. I think this operation is probably the best bet. I used to adhere to the SETLL because logically you’d think that the SETLL by itself would not move data like the CHAIN would and would be more efficient but I was told by IBM some years ago that there really isn’t much difference performance-wise. The SETLL won’t replace data that already in the buffer, though. So, whatever you’re most comfortable with. It really depends on what you need to do.
Sloopy | Jul 24 2008 2:29PM GMT
There may not be much difference between CHAIN and SETLL, performance-wise, but still I would recommend using SETLL, just because you are not reading data into your program, and not locking the record.
Especially if the file you are CHAINing to is opened for update in the program - then, if you find the record but were only doing an existence check, you MUST unlock the record, or make sure that you used the (N) extender on the CHAIN opcode (or ‘N’ in the half-adjust column if you are using RPG/400).
I have found in some legacy code that most ‘mysterious’ errors involving locked records are caused by unneccessary CHAINs holding unneccessary locks; and the buggy code can be hard to find.
Regards,
Sloopy
Gilly400 | Jul 24 2008 2:47PM GMT
Hi,
One extra thing to bear in mind (adding to Sloopy’s comments on record locks) - If you’re using commitment control and READing/CHAINing a lot of records, your job will keep ALL of these records locked for UPDATE until they’ve been released/unlocked or your changes have been committed.
Not only can the fact that the records are locked cause plenty of problems with other processes, but it can have a severe performance impact as your job will need to use more and more storage to manage all the locks.
Regards,
Martin Gilbert.
