IDMS REORG reload updates locked dependent areas
search cancel

IDMS REORG reload updates locked dependent areas

book

Article ID: 127267

calendar_today

Updated On:

Products

IDMS IDMS - Database

Issue/Introduction

A REORG was being executed where an error had been made such that dynamic allocation was ON and there was no DD statement in 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.

The same scenario was tested 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: All supported releases.

Resolution

The reload phase of the REORG was being run against copies of the target database dependent areas, but the necessary DD overrides in JCL were inadvertently omitted, and therefore the reload phase accessed the live dependent areas based on the DSNames in the 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

If SHARE is not coded, 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 SHARE is coded, REORG does not lock the source database areas and therefore during the reload phase will attempt to lock each area involved. So the SHARE parm would have alerted the user 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, which directs a local mode 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: PTF SO07705 was created to change how REORG does area locking to attempt to avoid the serious consequences caused by this kind of procedural error. 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 DB002352 message.