IDMS REORG reload updates locked dependent areas
Article ID: 127267
Updated On:
Products
CA IDMS
CA IDMS - Database
CA IDMS - ADS
Issue/Introduction
Client had an issue when running REORG where they had made an error in which dynamic allocation was ON and they had not put a DD statement into the JCL to override a dynamically allocated file.
The file involved was a dependent file and NOT specified as one of the areas in the REORG statement.
This dependent file was allocated and in update mode on the live CV.
Even though the file was locked and allocated to the CV, REORG accessed the file anyway and updated it as it would any dependent file. In this case, pointers were being changed.
This amounted to a local mode job changing a file that is live to an active CV.
Local mode batch utilities/jobs should not be able to do that.
ClientI tested the same scenario using the UNLOAD/RELOAD utilities and found that the RELOAD abended with an 0966 when it tried to update a dependent area that was locked.
Is it the case that REORG will update dependent areas whether they are locked or not?
The file involved was a dependent file and NOT specified as one of the areas in the REORG statement.
This dependent file was allocated and in update mode on the live CV.
Even though the file was locked and allocated to the CV, REORG accessed the file anyway and updated it as it would any dependent file. In this case, pointers were being changed.
This amounted to a local mode job changing a file that is live to an active CV.
Local mode batch utilities/jobs should not be able to do that.
ClientI tested the same scenario using the UNLOAD/RELOAD utilities and found that the RELOAD abended with an 0966 when it tried to update a dependent area that was locked.
Is it the case that REORG will update dependent areas whether they are locked or not?
Environment
Release: IDADSO00100-18.5-ADS-for CA-IDMS
Component:
Component:
Resolution
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.
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.
Feedback
Powered by
