Filter
Top Products
Record Locking
Record Locking
When a record is read by a program, it is read in one of two modes: input or
update. If a program reads a record for update, a lock is placed on that record.
Another program cannot read the same record for update until the first program
releases that lock. If a program reads a record for input, no lock is placed on the
record. A record that is locked by one program can be read for input by another
program.
In RPG IV programs, you use an update file to read records for update. A record
read from a file with a type other than update can be read for inquiry only. By
default, any record that is read from an update file will be read for update. For
update files, you can specify that a record be read for input by using one of the
input operations CHAIN, READ, READE, READP, or READPE and specifying an
operation code extender (N) in the operation code field following the operation code
name.
When a record is locked by an RPG IV program, that lock remains until one of the
following occurs:
the record is updated.
the record is deleted.
another record is read from the file (either for inquiry or update).
a SETLL or SETGT operation is performed against the file
an UNLOCK operation is performed against the file.
an output operation defined by an output specification with no field names
included is performed against the file.
Note: An output operation that adds a record to a file does not result in a
record lock being released.
If your program reads a record for update and that record is locked through another
program in your job or through another job, your read operation will wait until the
record is unlocked (except in the case of shared files, see “Sharing an Open Data
Path” on page 277). If the wait time exceeds that specified on the WAITRCD
parameter of the file, an exception occurs. If your program does not handle this
exception (RNX1218) then the default error handler is given control when a record
lock timeout occurs, an RNQ1218 inquiry message will be issued. One of the
options listed for this message is to retry the operation on which the timeout
occurred. This will cause the operation on which the timeout occurred to be re-
issued, allowing the program to continue as if the record lock timeout had not
occurred. Note that if the file has an INFSR specified in which an I/O operation is
performed on the file before the default error handler is given control, unexpected
results can occur if the input operation that is retried is a sequential operation,
since the file cursor may have been modified.
Note: Subprocedures do not get inquiry message, and so this situation should be
handled by using an error indicator on the read operation and checking for
status 1218 following the read.
If no changes are required to a locked record, you can release it from its locked
state, without modifying the file cursor, by using the UNLOCK operation or by proc-
essing output operations defined by output specifications with no field names
276 ILE RPG for AS/400 Programmer's Guide