Re:Second Data Center for Disaster Recovery

Discussion created by ca.portal.admin on Nov 5, 2009
Dear Listers :

We will be opening a new Disaster Recovery Center in less than a year.

We will be replicating all data to this center from our primary

operations using an IBM product called

""Global Mirror"".

All data is replicated at the DASD block level in real time for all


The primary and secondary sites are not expected to be more than a

minute or

two out-of-sync during the heaviest of processing.

All our archive journals are written to disk and then migrated off to


after several days.

Also, every day, we do a FLASHCOPY of the entire mainframe complex and


nightly tape backups of the Flashed volumes.

This also captures all database, disk journals, and journal archives.

With all databases, journals, and even journal archives on disk...


In a true disaster, it seems that recovery is as simple as starting an

instance of IDMS at the DR site and

let it go through WARMSTART.

Am I correct about this, or is it more complicated than that?

And if more complicated, I'll have the archives replicated if I have to

do more.


Jon Gocher
IDMS Public Discussion Forum



We haven't done it but are reasonably certain that something can be =
together but it won't be easy to make it production ready. The ROI =
have to be pretty compelling to go down that path.

The bigger question is why?

I know you already know this but mention it for completeness. Unless CA
delivers a DC version of the Java Runtime, do not try to run it as, or =
a DC task. =20

With that said you should be able to start a separate TCB in the DC =
as long as it is running something you can normally run in a MVS region,
including the execution of Java routines. To do that you'll need to
implement a POST and WAIT protocol, using a DC ECB between your DC task =
the TCB. This way your DC task can return control to IDMS DC until the
service, now running in its own TCB, completes work and posts the ECB.
Given that, it should work. =20

Another approach would be to load the JMV in another region and execute
Program Calls to use the JVM in the other region. Again, don't make =
that PC
directly from a DC task. It's bad for the same reasons we don't open =
etc from a DC task. You would still need to use an ECB to coordinate =
an interface routine that would make the PC from its own TCB. This has =
same issues as above but is a little more manageable because you keep =
the JVM crud (the word I would use in mixed company) out of the DC =

Both of the above approaches leave much to be desired. First, if you =
careful you may just find yourself writing your own DC like service. =
seems silly. In addition, making it robust for production, with good
performance characteristics as well as manageable, will be real =
and the place where you will spend A LOT time.

Other options would depend on what other software is available. If
WebSphere for z/OS is available, there are ways to make a Program Call =
to a
Web Service. Or if you have CICS you can do the same to invoke a CICS =
cross memory. Either of these approaches would be much more manageable =
the raw approaches above. There are other products that might be used =
but I
don't want to get into trouble here listing them.

Last and not least if the Java routines are doing database activity
elsewhere, it would be a good idea to enlist both transactions in the
resource manager.

Call me if you would like to brainstorm. You know how to reach us.


Tom Hebert
ObjEx. Inc.
Office: +1 908 813 2866
Mobile: +1 973 479 2374