Detecting Record Lock

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
jyoung
Posts: 656
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Detecting Record Lock

Post by jyoung » Fri Feb 08, 2019 4:54 am

Is there anyway to detect that a record is locked when you fetch it?

We have a case where a user used a 5250 screen to view a record. That user then went into our VLF-ONE app and tried to change the record only to have the app eventually crash seeming because of the lock.

Question is then, how do you determine if a record is locked before you update it?
This way we can tell the user that its locked and cannot be saved.

Thanks,
Joe

EDIT
I'm not interested in managing the locking myself. I just need to know if it is locked.

Pablo
Posts: 47
Joined: Wed Dec 02, 2015 10:35 am

Re: Detecting Record Lock

Post by Pablo » Fri Feb 08, 2019 6:59 am

Hi Joe,

try an UPDATE with check_only(*Yes) ... if the record is locked you should be able to tell in the error status.

See https://docs.lansa.com/14/en/lansa015/i ... CHECK_ONLY

Regards,
Pablo

Pablo
Posts: 47
Joined: Wed Dec 02, 2015 10:35 am

Re: Detecting Record Lock

Post by Pablo » Fri Feb 08, 2019 7:07 am

There is actually a Delete check only(*yes) ...

MarkD
Posts: 630
Joined: Wed Dec 02, 2015 9:56 am

Re: Detecting Record Lock

Post by MarkD » Fri Feb 08, 2019 8:55 am

I don’t think you can’t actually tell that it’s locked. What happens is that the DBMS layer waits for a specified period, typically 60 seconds, for the record to become unlocked. If it does not unlock then your program gets signalled an I/O error. So, in update code (say) you need to use something like this:

Code: Select all

* Attempt the update
Update Fields(#xEmployeeAge) In_File(xEmployee) With_Key(23) Io_Error(*NEXT) Val_Error(*NEXT)
* Something went wrong - possibly a record lock - but either way, the update failed to complete
If_Status Is_Not(*OKAY)
Message Msgtxt("Unable to update the record at this time. Try again later")
Return
Endif
There’s always a UX problem here in that the UPDATE command will freeze up for 60 seconds (typically) on an IBM I server until the lock is released, or not, confusing the user. The wait period can be changed with the WAITRCD() parameter of they CRTPF or CHGPF commands.
Capture.PNG
Capture.PNG (41.13 KiB) Viewed 2072 times

As an aside ......... IBM has always recommend that RPG (or any other) programs should never lock records for what they call ‘long waits’ – such as waiting for 5250 user's interaction. Doing that causes the obvious chaos with coffee breaks, lunch breaks, leaving for the day, etc, etc.

KevinW
Posts: 28
Joined: Thu May 26, 2016 11:18 am

Re: Detecting Record Lock

Post by KevinW » Fri Feb 08, 2019 9:24 am

Special system variable *DBMS_RECORD_LOCKED is available for your use to distinguish between other I/O errors and a record locked condition. So taking MarkD's sample code and adding this:

Code: Select all

* Attempt the update
Update Fields(#xEmployeeAge) In_File(xEmployee) With_Key(23) Io_Error(*NEXT) Val_Error(*NEXT)
* Something went wrong - possibly a record lock - but either way, the update failed to complete
If_Status Is_Not(*OKAY)
If Cond(*DBMS_RECORD_LOCKED = Y)
* Deal with record locked however your site determines
Else
Message Msgtxt("Unable to update the record at this time. Try again later")
Return
Endif
Endif  

jyoung
Posts: 656
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: Detecting Record Lock

Post by jyoung » Fri Feb 08, 2019 9:28 am

Digging through the docs and I found the *DBMS_RECORD_LOCKED System Variable.

https://docs.lansa.com/14/en/lansa015/i ... 4_0115.htm

On the the surface this appears that it could be the answer.

The docs https://docs.lansa.com/14/en/lansa015/c ... ists_2.htm use it after an update with a GOTO. (Are GOTOs still a thing?!)

Any thoughts on this System Variable?

Long term, I think the best option may be to set the IO_ERROR(*NEXT), check the status and handle accordingly.

-----
Was typing as Kevin responded.

Post Reply