Record locking: suggested best practices

1) Always use commitment control in programs that insert/update/delete
non-work files (i.e., any file you can easily recreate without changing
master files). Batch and interactive!
2) STRCMTCTL LCKLVL(*CHG) CMTSCOPE(*JOB)
3) For crying out loud: use ILE, not OPM, languages and compilers. You've
had plenty of time to learn ILE!
4) Do not use the default activation group.
5) In SQL service programs, EXEC SQL SET OPTION CLOSQLCSR =
*ENDACTGRP, COMMIT = *CHG, EXTIND = *YES, DATFMT = *ISO, TIMFMT = *ISO;
otherwise EXEC SQL SET OPTION CLOSQLCSR = *ENDMOD, COMMIT = *CHG, EXTIND =
*YES, DATFMT = *ISO, TIMFMT = *ISO;
6) In non-SQL programs you have to update, unlock, or ROLBK to release a
record lock.
7) In SQL programs, to cancel a pessimistic lock, you have to EXEC SQL
ROLLBACK (which closes the cursor as well). Otherwise, the locks are
released after the EXEC SQL UPDATE *and* EXEC SQL COMMIT. Note that EXEC
SQL COMMIT has parameters which can be handy in some situations.
8) Use OVRDBF WAITRCD() in batch programs to soften the impact of record
lock conflicts.
9) Use display file timeouts in interactive programs to handle user
walk-aways.
10) For extra credit, trap 01218 (non-SQL) and SQLSTT='57033' record lock
exceptions and handle them gently (system operator inquiry message,
system-generated e-mail). In non-SQL programs, the process holding the
lock is in the exception message in the PSDS.
11) Adopt good designs and/or standard design practices to eliminate
"deadly embrace" situations.