Record existence

35 pts.
AS/400 Records
How do you know if a record exists without doing a READ and CHAIN?

Answer Wiki

Thanks. We'll let you know when a new response is added.


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).


Martin Gilbert.

Use SETLL in conjunction with %EQUAL built in function

Key SETLL file
If %EQual
* a matching record has found

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.

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!

Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • GreenleeB
    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.
    95 pointsBadges:
  • Sloopy
    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
    2,195 pointsBadges:
  • Gilly400
    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.
    23,730 pointsBadges:
  • TomLiotta MUST unlock the record,... But seriously, how hard is it to code UNLOCK (or UNLCK) after doing a CHAIN? In any case, SETLL will perform significantly faster than CHAIN over a series of operations. I have no idea where those "IBMers" got their info. For single-record tests, there's virtually no difference. (Unless your CHAIN runs into a lock itself!) Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: