IDMS: Unexpected database errors in REORG

Products

• IDMS

Issue/Introduction

The REORG utility is abending with an unexpected non-zero error-status.

This is likely indicated by UT000027 and/or DC329009 messages in the REORG job output.

Environment

Release : All supported releases.
Component : IDMS

Cause

The database file definitions were being overridden by ddname assignments in the JCL.

This can be dangerous in REORG unless great care is taken to ensure that all submitted slice jobs actually run during the phase in which they were intended to run.

When a subordinate REORG job is submitted to process an individual slice, typically it has only the text "REORG;" in the SYSIPT, so it has no knowledge of specifically which phase it is expected to execute. The job simply examines the control file to see what tasks are available to be executed, and it then chooses one to run depending upon the phase the REORG has reached.

It is feasible that a job may have been submitted to run as part of an UNLOAD but may not actually execute until the RELOAD is being run. (This could happen for operational reasons unrelated to the REORG.) If that UNLOAD job was coded with JCL overrides pointing to the "old" database - then you could have a RELOAD task being executed against the old database.

Any number of unexpected database errors could result.

Resolution

Avoid using JCL ddname overrides in REORG jobs.

1. Set up distinct unload and reload segment and DMCL definitions with unique ddnames and dataset names. Then it does not matter if a REORG job eventually runs in a different phase than intended. It will always access the correct database because it is under the control of REORG alone.

2. If unloading and reloading back into the same physical database, use one segment and DMCL definition. Use "STOP AFTER UNLOAD", and after the unload, FORMAT the database before submitting the RELOAD.

If it is absolutely necessary to use database ddname overrides in the JCL, be sure that every REORG job runs as part of the phase it is supposed to. As in option 2 above, you must ensure that after the UNLOAD is complete, there are no more REORG jobs either running or waiting in the input queue.