Richard,
In just about all Remote Copy designs there are three things that you must
consider:
1. Point in Time Consistency
2. Point in Time Consistency
3. Point in Time Consistency
I should also mention Point in Time Consistency, as this can be important
also. From the System Programming perspective you need to consider those
things on your primary system that can become a problem when you try to
restart your system on the remote site.
For example, you may be copying a clutch of volumes with the critical
datasets you need to IPL your system and start your major subsystems, but
what about the catalogs? And do your catalogs have the same Point in Time as
the volumes and VVDS that they reference?
Seemingly minor issues, but I have seen sites that run batch on Asynchronous
while the UCAT volumes are on Synchronous, and then wonder why they have all
sort of Dataset not found and orphaned VVR/NVR problems during a DR drill.
Two phase commit is another thing that many sites seem to ignore or forget.
Restart of the business requires some thought to how losing the point in
time across a federated transaction will affect you going forward. Sites
that have different points in time for DB2 and CICS/VSAM need to consider
the impact to the application, even though they successfully restart the
subsystems.
As a System Programmer you need to consider the things that require
consistency across many volumes and make sure you deliver that point in time
that allows systems and applications to restart.
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Richard Jackson
> Sent: Thursday, 8 September 2005 10:43 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: PPRC Implementation for z/OS and resources.
>
> We are preparing to implement an asynchronous PPRC hardware solution
> between
> our production site and our disaster recovery site using the IBM ESS800
> series subsystems for a tier 4 DR solution. I have found plenty of
> resources
> regarding the configuration of the hardware and communication, but have
> found information covering the implementation from a z/OS systems
> programmers perspective difficult to find. No redbooks either. Our initial
> test is to mirror just the required system volumes on a test system which
> is
> in the production sysplex. How do such solutions affect my sysplex
> configuration and the XCF datasets, what master and usercat issues need to
> be considered, are there any issues with USS (HFS's and ZFS's), and so
> forth? Has anyone dealt with these issues? As mentioned there seems little
> documentation from the software end. Any pointers on these issues and
> directions to some useful documentation is greatly appreciated.
>
> R. Jackson
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
