This article describes the benefits and drawbacks of using RETRIEVAL NOLOCK in IDMS.
What are the PROS and CONS of using RETRIEVAL NOLOCK?
CA IDMS, all supported releases.
The PRO of using RETRIEVAL NOLOCK is better performance for a retrieval only transaction, because it requires no locking overhead. Also this setting may reduce waits or deadlocks.
The CON of using RETRIEVAL NOLOCK is the possibility of false abends.
These happen when the database is being updated concurrently by other tasks, and the retrieval program accesses records whose prefixes (set pointers) are in the midst of being updated. These abends include error-statuses 0360, 0361 and abend codes 1116, 1117, 1143 and 1153 among others.
This is a balancing act. If a sysgen setting of RETRIEVAL NOLOCK results in too many false abends on a particular transaction, you may want to consider having that transaction ready the area in update mode. This would force the transaction to set currency locks. Changing the SYSGEN option will change it for all programs in the CV, not just one program.
Another consequence of running RETRIEVAL NOLOCK is that occasionally retrieval-only dialogs may read uncommitted data. This "dirty read" situation occurs when Program-A obtains a record and updates it, then before Program-A has issued a COMMIT, Program-B reads the updated version of the record, then Program-A rolls back its previous update. In this situation the user executing Program-B is unaware that the data being presented is not valid. For this reason, RETRIEVAL NOLOCK is not recommended for mission-critical applications, or any application where absolute accuracy of each data item is required. It is most useful for applications reporting on overall trends or for applications that will confirm data before any critical processing occurs.
Optional Bit 216 in RHDCOPTF can be used to convert some of the more common abend codes mentioned above into an xx57 error-status which an application program can intercept and take appropriate action.