Difference between Record and File locks
I had always thought that record and file locking where terms used interchangeably. I searched the web and couldn't validate my assumpition. Is there anyway in RPG you can lock a specific record (record lock) in a file without locking the entire file (file lock)?
Software/Hardware used:
Software/Hardware used:
ASKED:
April 13, 2009 4:48 PM
UPDATED:
October 6, 2011 7:30 AM
Answer Wiki:
Hi GTank
Yes, these are very different although you might see both happening at about the same time.
File locks like other types of object locks are locks on the entire object.
An RPG F spec with Update will lock the file member to Shared - Update status when the file is opened.
It can also be locked with the ALCOBJ command.
Other processes can use the member for input, output, update but no process can establish an exclusive lock or an exclusive allow read lock or delete the object while that lock is in place. The lock from the F-spec will be in place from the time the file is opened until it's closed.
Record locks are an entirely different process.
Your F-spec or open command opens the file for update but doesn't lock a record.
The read or chain locks a record (on a file open for update), unless the read or chain uses (n) - no lock.
The single record remains locked until
- an unlock is issued
- an update or delete is issued
- another read or chain is issued.
- the file is closed or *inlr set on.
Record locks will remain longer with commitment control.
The program will be prevened from allocating a record that is locked by another process.
An RPG-f spec with input mode will lock the file member as Shared-read but will not lock any records.
Shared-read will allow any use of the file by other processes except those that requre exclusive locks or that delete the file.
Phil
To see all answers submitted to the Answer Wiki: View Answer History.
I’ve been wondering about this also. Have some good books on programming, but neither the COBOL/400 or RPGLE books show real world examples of record locking.
One would not want to lock the file (if you have multiple personnel doing data entry and changing records in various locations, you would want to prevent two persons from trying to change the same record at the same time or approximately the same time. Be it warehouse locations, inventory locations of one type or another. I recently checked out a book on RPGIII, and it mentioned multi-programming applications, but showed no examples. In the real world you have to provide for these possibilities.
Unless OS/400 or i5/OS or IBM i provides for this, then the programmer has to provide for these contingencies.
Here’s a 3-part article about handling and preventing record locks:
http://www.mcpressonline.com/tips-techniques/rpg/techtip-preventing-record-lock-part-1.html
http://www.mcpressonline.com/tips-techniques/rpg/techtip-preventing-record-lock-part-2.html
http://www.mcpressonline.com/tips-techniques/rpg/techtip-preventing-record-lock-part-3.html
The coding examples used are “old school” RPG syntax , which I don’t recommend, but the methods presented are useful. (Think /Free format – much better).
The clue is in the name
a file lock affects the file – a batch update may need to ensure that no changes take place whilst it, say, strikes the daily balances figures.
a record lock locks a record, so only one program updates it at one time.
read the IBM DB2 programming manual from the infocentre
When does a record becomes a file?
When does a record becomes a file?
Never.
Files are containers. A file might be empty. Files contain records.
As for the original question, file-level locks are different from record-level locks. One program might have a record-level lock on record #1 in a file, and a second program might have a lock on record #10,000. The two programs generally are not interfering with each other.
Note that both programs will also have locks at the file-level for the file at the same time. Those won’t interfere either.
A file-level lock is an ‘object lock’. Object locks have degrees of locking. Many programs can have locks on the same ‘object’ without interfering with each other, as long as the degree of locking is a ‘shared’ lock. If any program obtains an ‘exclusive’ lock, though, other programs will have to wait to access any part of that object.
When a program is holding a ‘shared’ lock, that will prevent any other program from obtaining an ‘exclusive’ lock.
Programs that update database files generally use ‘shared’ object locks. This lets many programs apply updates concurrently. It also forces processes like backups that require ‘exclusive’ locks to wait until all updating programs finish.
Tom