Splitting an Oversized REORG SHRLEVEL CHANGE Job
Your Db2 13 subsystem has a 1.4 TB PBR table space with 200 partitions. Partitions 1-150 are read-only history; partitions 151-200 are active and receive 70% of updates. A weekly REORG SHRLEVEL REFERENCE on all partitions takes 11 hours, but the batch window is 5 hours. The team tries REORG SHRLEVEL CHANGE with INLINE COPY on all 200 partitions. After 4 hours it fails with a log shortage warning, and SMS reports 180 inline copy data sets allocated but only 60 tape volumes available. The job also holds drains on active partitions for 90 seconds, causing CICS timeouts. You have a 6-hour window this weekend. The business requires that active partitions remain available and that every partition has a recoverable image copy. The tape pool can be expanded only by 40 volumes.
1. Why did the all-partition SHRLEVEL CHANGE job fail, and which constraints were actually violated?
Read the worked answer
Three constraints were violated at once. SHRLEVEL CHANGE logs changes for every partition being reorganized, and applying that to all 200 partitions, including the 50 active ones, can exhaust the log even if the history partitions are read-only. INLINE COPY allocates copy data sets per partition, so 200 partitions produced more tape allocations than the 60 available volumes. Finally, the job needed drains on active partitions; a 90-second drain caused CICS timeouts. The failure is not solved by raising only one limit. Treating read-only history and active data as one utility job mixes incompatible availability and log requirements.
2. Design a phased utility plan for the 6-hour window that preserves active-partition availability and recoverability.
Read the worked answer
Split the work by partition state and by resource impact. Reorganize the 50 active partitions in smaller groups, for example 10 to 20 partitions at a time, using SHRLEVEL CHANGE with INLINE COPY and COPYDDN to the available tape pool. Keep the groups small enough to bound log consumption and copy allocations. For the 150 read-only history partitions, use SHRLEVEL REFERENCE and take inline or separate image copies; availability is less critical for history, but recoverability is still mandatory. Use partition-level REORG with explicit PART ranges rather than an all-partition job. Expand the tape pool by the allowed 40 volumes and schedule the history groups after the active groups. Monitor log space and drain waits between groups, and stop before the next group if the log threshold is reached.
3. How would you reduce CICS timeout risk and prove that every partition has a valid recovery copy?
Read the worked answer
For the active partitions, use SHRLEVEL CHANGE with a controlled DRAIN_WAIT and MAXRO setting so the utility does not wait indefinitely for a drain and does not hold one for 90 seconds. Schedule the active groups during the lowest CICS arrival rate, and test the drain behavior in a test LPAR with production-like transaction rates. Do not run all active partitions in one group. After each group, check SYSCOPY for the inline copy records, confirm that the copy data sets are cataloged and readable, and run a recovery report against the affected partitions. If any active partition lacks an inline copy, take a separate COPY with SHRLEVEL CHANGE before the window closes. Do not declare the window successful until every reorganized partition has a recorded image copy and no copy-pending state remains.