Disaster Recovery Dump Tool/Utility(DR Dump). (01-Feb-2010)
In today’s global economy it is essential for customers to process at their data centers with minimal interruption. Customers need access to their data and resources in real time, and to manage data continually. In a perfect world, processing would never e interrupted, and data would always be available. Unfortunately, extenuating factors can influence or disrupt data access or data management. For example, natural disasters (acts of god), or overt disasters, deliberately caused to data centers. As a result, it is critical that customers have a Disaster Recovery (DR) solutions or methodology's in place. . Therein lies the issue; current solutions are often less than desirable and not easily implemented when needed. Many customers have implemented Disaster Recovery strategies, although, the implementation of DR process is not always fluid. The main problem is that there is not one complete and outlined method documented on how to do this process. Current documentation is minimal and fragmented amongst several manuals depending on which SW component the customer is using. . The target of this discloser is to simplify the implementation of the customer’s full production environment at a Disaster Recovery (DR) site. Again, customers working at a DR site or needing to transfer operations to a DR site often run into issues where processing is not fluidly transferred, or not implemented in a reasonable amount of time to effectively demonstrate that the DR process has successfully been implemented. . The basic intent is to avoid any processing disruptions for an extended period of time. The current solution is to manually set up the disaster recovery site by setting up all necessary parameters and to initialize all hardware as necessary. As a result, the customer may run into unexpected issues where implementation of their production environment at the DR site. As stated earlier, current DR solutions are not complete. Documentation is not forthcoming and clear on what is needed to bring up operations at a DR site, and again, it often takes a longer than desired time to implement and get the DR site to complete function within a reasonable time frame. Currently, there is no one given solution for DR or a complete methodology for how DR is done in a mainframe environment.
Disaster Recovery Dump Tool/Utility(DR Dump).
The DR dump tool is an automated method to capture a collective of duplicated datasets necessary for the emulation of a customers mainframe production environment at a disaster recovery site.
Note.
This tool could be a feature of z/OS or a licensed product. If the customer decided to purchase the tool or integrate this feature, then setup on the customers systems would be needed. The customer would have to decide what functional datasets the customer deems as vital to overall production at their Disaster Recovery (DR) site. So some initial setup would be necessary when tailoring the DR dump for their needs.
.
This is how the DR dump tool works:
On a basic level, the DR dump tool would be setup to capture all essential dataset and configuration information needed to run in the customer's primary production environment. The captured configuration and working datasets can then be used at a DR location, fully emulating the production setup. This would be a two phase process, recovery and implementation.
.
Here's how the DR tool would work in the recovery phase:
The Disaster Recovery Dump function is setup to capture all essential datasets and configuration settings from the customer's primary production environment. This can range from a single system to a SYSPLEX. This information would then be taken to a Disaster Recovery environment and easily perform recovery procedures from the production environment with fewer complications and in a shorter amount of time.
.
The actual implementation procedures of this invention would need to be performed in two separate phases. Each phase would be completed in sequence, initiated from the host environment and brought back up on the disaster recovery environment. Generally these two environments are in two different geographic regions, for example the production system could reside in New York while the Disaster Recovery environment resides in Oregon.
.
The initial phase, which begins on the host environment, could be commenced/ setup from three different options. The three ways this phase can be initiated are by command line, by automation setup, and by a failure. Each of these different variations would have some common parameters and also unique parameters, for example the by automation would have a parameter to set the frequency to perform a Disaster Recovery Dump. The three different variations will be invoked at different events and that is the difference between them.
.
By Command
The by command method would be performed by a user either in a TSO session or from an operator console. This event would then initiate the DR Dump process involved in the first phase. When this command is specified it will
1
have a multitude of different parameters to interact with various components. Such parameters would be specific datasets that would need to be included along with special configuration settings....
Find More Documents Like This
Download this Disclosure
Click here if you want to sign-in now.
