BLKIREC() was not immediately checking the next record when the current record failed the blocking condition. Instead it was waiting for the next change. The logic has been corrected so that, when a record fails the blocking condition in BLKIREC(), it immediately attempts to read the next record or previous record, depending on the opcode passed to BLKIREC().
When a record did not pass the BLKIREC filter, it attempted to read the next record. If the current record was not read in full, the next record read could fail with error 893. In this situation it is desirable to return the length of the current record to the caller so the caller can read the current record in full, then call BLKIREC again. The client code now passes the record length back to the caller in case of error 893 on a BLKIREC call.
When BLKIREC tried to read the next record because the current record failed the filter condition, it changed the opcode to read next. When BLKIREC needed to wait on the system queue after such a retry, it needed to restore the opcode to the original opcode so that it performed the original record read operation after notification informed BLKIREC that the file had changed. The logic has now been modified to behave accordingly.
A call to BLKIREC() that specified a blocking condition was leaving a record locked if it acquired a lock when reading the record and then found that the record did not meet the blocking condition. The logic has been modified to correct this.