EZ-Reorg/RSTU


24x7 Availability for CA-IDMS


Many sites strive for 24/7 systems availability. Quite often, business circumstances dictate that loss of availability be minimal or non-existent. Many users can quantify in financial terms what each hour or minute of down time costs their business in lost revenue or lost opportunity.


Through its evolution CA-IDMS has gradually introduced many 24/7 features. Release 12.0 addressed many of the important aspects of 24/7 operation (for example dynamic file allocation and dynamic DMCL modification).


One area not addressed by CA, but critical to many users, is that of database maintenance including database reorganisation and restructure. For sites requiring 24x7 availability, the required down-time to perform an Unload/Reload in particular is a major problem. Depending on the sizes of the affected areas, it is not uncommon for reorg's to take a whole week-end to complete. Often, they are planned months in advance, for instance to coincide with long-weekends. They can be expensive in terms of system down-time and staff overtime. Because of the time criticality, there is no margin for error. If things go wrong, it may be necessary to give up, meaning that many months may go by before there is another opportunity to implement crucial maintenance.

Though a database restructure typically does not take as long as a database reorg, it is still a requirement that the database be offline while the restructure takes place. Execution of database restructures has become increasingly problematic for 24/7 users.


Even for non-24/7 shops, the ability to schedule reorg's and restructures during normal working hours (with the affected areas still fully available to end users) gives CA-IDMS users an unprecedented degree of flexibility in terms of scheduling and implementation of routine database maintenance.


EZ-Reorg/RSTU Operation


With EZ-Reorg/RSTU, these problems become a thing of the past. EZ-Reorg/RSTU allow CA-IDMS users to perform database reorganizations and restructures while the affected areas are still available for update by the production system.


In simple terms, this is achieved as follows:


  • Take an in-flight backup of the affected area(s) - production remains up

  • Perform restructure and/or reorganisation against copy - production remains up

  • Feed the off-loaded journals into EZ-Reorg/RSTU “catch-up” process. This process analyses the off-loaded journals and issues the required DML against the restructured/reorganised database, until all off-loaded journals are processed - production remains up.

  • Shutdown production. Off-load the “active” journal and feed into EZ-Reorg/RSTU “catch-up” process - production down.

  • Optionally, take back-up- production down.

  • Start-up system using newly restructured/reorganised area(s).


A comparison of the implementation of a database reorganization with and without EZ-Reorg/RSTU is shown in the following figure:

Stacks Image 131