If you file (PF or LF) is defined as an “U”pdate file in your F specs, A Read or Chain operation will automatically lock the record untile it is released.
To avoid this, you can use the op code of N. So your instruction would be Chain(N) or Read(N).
An Update or use of the REL op codes will also release the record.
Problem most occurs when doing an update with a DSPF. The record is retrieved and sent to the screen for the user to update. Until the operator does the update, your record is locked. SO to get around that, you use the (N) on the initial retrieve. Save a copy of the record. Display it on the screen. Now when the user wants to update, you need to retrieve the record again without the (N). You should compare it to the initial saved version of the record to ensure that no other program has already updated it becuase you would overlay that with this update.
CharlieBrowne has the basics exactly right. It should be emphasized that when you retrieve the record the second time and it shows differences from your saved copy, you need to go back to the user and let him/her know that the update isn’t allowed. To do that, you need to release the record lock first.
Since you have to do screen I/O again, and you apparently want to avoid locks during interaction with the display user, you will want to release the lock and show the new version of the record to your user. The new version should then replace the copy that you saved earlier.
The user can then decide if an update still needs to be made. The changes will be typed into the new version of the record, and your program will go back through the process of retrieving the record with lock, and the comparison must be made again to see if another change was made during this latest screen I/O.
IMO, it’s probably better to have timeouts on display interaction. When a timeout occurs, simply set the screen format back to the starting point and release the record. You can use the UNLOCK op-code against the file to release record locks.