Checking for record locks

[gregwga50]

I have an interactive program in which that I want to display an error message when the user presses a certain CF key and there is a record lock on the file. Is there a way to check and see if the file has a record lock without trying to read another record from it. I don't want to change the contents of any of the fields in the event there is not a record lock.

[JonBoy]

I guess you could use an API/SQL approach to determine if any locks were held. But it would be simpler to try to do a read using a DS as the target for the operation - that way the even if the record is read you don't change the regular fields.

I'm having trouble though understanding how this circumstance could occur anyway (other than as a result of programming error) - where are these locks coming from? You should not really be holding a record lock when a record is displayed for update - too many things can go wrong if you do that.

[Rocky]

What's wrong with chaining to the record - and testing the feedback data structure if there's an error? If it's successful using SETLL to remove the lock?

[JonBoy]

What's wrong with chaining to the record - and testing the feedback data structure if there's an error? If it's successful using SETLL to remove the lock?

Because if it succeeded it would result in a change the field contents and the OP said "I don't want to change the contents of any of the fields in the event there is not a record lock." - that's why I suggested doing the CHAIN/READ/whatever using a target DS for the result.

[Rocky]

IF you're using RPGLE you can CHAIN it into a DS - specify a qualified DS that doesn't effect the fields in question....

[Rocky]

(which is what you just said...)

[tomliotta]

Because a record lock should only be very short duration (when done properly), you might find a record lock; but the lock might be released almost as soon as you get to the next instruction. Does that matter? And how long of a record-wait will you use before a lock is signalled?