Record Locking using a COBOL program

Application development
From a COBOL program I an reading a random access file and occasionally try to read a locked record. What can I do to speed up the read so I can just present a popup screen that tells the user he is trying to access a locked record. Right now it takes 60 secs to time out from the read attempt before I can present this screen. BY then many users simply kill their session out of frustration. Any help would be appreciated.

Answer Wiki

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

(1) If doing a Cobol READ, you can avoid the question of locks by using READ WITH NO LOCK.

(2) If doing an SQL SELECT, you can avoid the question of locks by using WITH NC as the last clause.

(3) In various OSes, you can set your general commitment level to read without locking, or set your timeout to some arbitrarily low value, such as 0. Setting the timeout to 0, in most systems, means that you will not wait for a record at all. Watch out. In some, it means to wait forever. You can always set your timeout to a very low nonzero number, through.

Discuss This Question: 5  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.
  • Jadima
    You can change the file that is accessed to a lower wait time limit. This can be done using the CHGPFM command waitrcd keyword to a value -let's say 5 seconds instead of 60 seconds.
    0 pointsBadges:
  • Acjitk
    If you need to keep the 60-second wait time for record locking in place and you also need to read the file for update in your current application, you can implement "soft lock" processing as follows: 1) Add the field "Locked By User Id" to the file 2) Every time the program reads the file for update, add the user id to this field 3) Every time the user has finished updating, remove the user-id from this field 4) Add a statement before the read for update step (which is holding up the users for 60 seconds) that reads without update so that the wait time for record lock is not in effect. 5) Check for a soft lock - check if the "Locked by User Id" field is not blanks. If not blanks, display the User Id in a meesage on the screen letting the current user know who is locking it. This will display instantly rather than the file wait time. 6) The only problem with this approach is that the soft lock remains on the record if a job is cancelled before the soft lock is removed. You will need to provide the users an override when the soft lock exists which means that they can try to update anyway (usually after they check with the user in the message to see if they are really locking the record). You can do this by making the message display in a window which gives them the option to read for update regardless of the warning that the record is locked. If they decide to override the soft lock warning, the worst that will happen is that they will have to wait 60 seconds if the record is truly locked just like they did before.
    0 pointsBadges:
  • Centex
    If you cannot change the physical file wait time, you can also override the record wait time with an OVRDBF before opening the file with your program. We normally change it to *NONE in this situation so you get an immediate signal back to the program.
    0 pointsBadges:
  • Pbrown0108
    Thank you all for your responses. I was finally able to use the OVRDBF command to change the amount of time that would be used trying to read a locked record. Again thanks to all of you.
    0 pointsBadges:
  • TomLiotta
    A nice aspect of the override is that it applies only in that job. It doesn't change the file, and that means it doesn't mess with timings in other jobs. An override can tune the behavior for each individual job. 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: