Enscribe Programmer's Guide

Reading Deleted Records
If transaction T1 deletes a record and another transaction T2 attempts to read the same record
while T1 is still active, then:
• If T2's request is a FILE_READ64_/READ call following exact positioning through the alternate
file, the request fails with an error 1 (end-of-file) irrespective of the locking mode specified.
• If T2's request is a FILE_READ64_/READ call following exact positioning through the primary
file, the request either fails with an error 73 (file or record is locked) if reject locking mode is
in effect or it waits for T1 to complete if normal locking mode is in effect.
• If T2's request is a FILE_READUPDATE64_/READUPDATE call, the request either fails with an
error 73 (file or record is locked) if reject locking mode is in effect or it waits for T1 to complete
if normal locking mode is in effect. This behavior is true if the exact positioning is through the
primary file. If the exact positioning is through the alternate file, the request waits for T1 to
complete irrespective of locking mode.
Batch Updates
When programming for batch updating of audited files, you should either have the transaction
lock an entire file at a time by using the FILE_LOCKFILE64_/LOCKFILE procedure or carefully keep
track of the number of locks held. If you do not use FILE_LOCKFILE64_/LOCKFILE, the disk process
sets implicit locks as:
• When a new record is inserted into an audited file, the disk process implicitly locks that record.
• When a record is deleted from an audited file, the disk process implicitly retains a lock on
that record.
These locks are not released until the transaction is either committed or aborted and backed out.
This means that transactions doing batch updates to audited files can acquire too many locks if
the transaction involves deleting, updating, or inserting a large number of records. The absolute
maximum number of locks that can be acquired by each transaction is 5000. Any attempt to
exceed the maximum number of locks will result in an error 33, 35, or 37.
If a TMF transaction calls FILE_LOCKFILE64_/LOCKFILE for a primary file,
FILE_LOCKFILE64_/LOCKFILE is automatically applied to any associated alternate-key files. This
prevents primary file updates from causing the alternate-key files to obtain record locks.
158 File and Record Locking