Client was running REORG reload phase against copies of the target DB dependent areas, but forgot to code DD overrides in JCL for the reload phase, therefore the Reload phase accessed the live dependent areas based on DSNames in DMCL, AND even though the Areas were locked by the CV REORG updated them.
This is due to processing described under the REORG setup parameter SHARE.
https://docops.ca.com/ca-idms-ref/19/en/utilities/utility-statements/reorg#REORG-Parameters If you do not code SHARE, REORG Locks ALL relevant areas in the Source database during the Unload Phase and therefore expects them to still be locked when reload phase runs and does not attempt to lock the areas at that time.
If you code the SHARE parm, REORG does not lock the source DB areas and therefore during reload phase WILL attempt to lock each area involved.
So the SHARE parm would have alerted the client to the mistake in the JCL.
Another precaution to be sure DMCL DSNames are not used during this utility is to code SYSIDMS parm
LOCAL_DYNAMIC_ALLOCATION=OFF
OFF directs a local CA IDMS batch job to ignore any DSN information that is defined in the DMCL for database files, and requires that the DSN information be included in the JCL to access a database file.
NOTE: SE created IDMS 5508 PTF SO07705 to change how REORG does area locking to attempt to avoid the serious consequences caused by this kind of mistake.
This PTF will alter the locking process if SHARE is not specified in the initial REORG parameters.
All target and dependent areas will be locked during the unload phase but released at the end of the unload phase.
Area locks will be reset at the beginning of the reload phase. If an area is found to already have its in-use flag
set the REORG utility jobs will end with a DC002352 message.