RE: READE behavior question

Hi Vern,


<snip>
At any rate, it seems that the behavior is, in essence, to READ the next record and check for equality - not that it actually does it that way, it is just how it seems to come out.
</snip>

I believe it would be a READ, followed by a check for equality. But the READ could be done against an index (logical) or the PF. It depends what you have in your F-spec. If it is a READ of an index then the RRN is retrieved from the index row and the appropriate page (containing the full row) is then retrieved. If it is a sequential READ of the PF you have already retrieved the full row so nothing more is required.

In this scenario it is easy to see why a sequential READ on the PF would conceivably out-perform a READE by index.
(Of course, this is also why SQL can be quicker and why you should specify fields in a select list (not *) when using SQL - if all the fields you want are on the index SQL uses then SQL can choose whether to bother going to get the full row as there may simply no need for the other data)

The RLA access can lead to some unexpected results:

1) Say you use setgt to position on a file AFTER the last row for the given key.
2) There are rows after the current cursor position (you are not at EOF) but they are (necessarily) of a higher key.
3) If you READE using your current key and you use a lock on your READE you will try to lock the next row when you READE it, even though you actually don't want it.

So, the READE needs to read (and possibly lock!) the next record to check equality and then releases it if it doesn't match.

This can catch a developer out as a user can be put on a lock-wait because another user is working with a DIFFERENT set of rows - just one higher in the key. This is an infrequent but possible bug, and I have seen it happen.

This behavious is documented in the RPG reference under READE. The relevant info is below:

Note: If a file is defined as update and the N
operation extender is not specified, occasionally a READE operation will be
forced to wait for a temporary record lock for a record whose key value does
not match the search argument. Once the temporary lock has been obtained,
if the key value does not match the search argument, the temporary lock is
released.
In most cases, RPG can perform READE by using system support
that does not require obtaining a temporary record lock to determine whether
there is a matching record. However, in other cases, RPG cannot use this support,
and must request the next record before it can determine whether the record
matches the READE request.
Some of the reasons that would require RPG
to obtain a temporary lock on the next record for a READE operation are:
the key of the current record is not the same as the search argumentthe current record is not the same as the requested recordthere are null-capable fields in the filethe file has end-of-file delay
Of course, I am sure it is MUCH more complicated than that.

Hope this helps a little.

Cheers
Larry Ducie