ca.portal.admin

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

volumes.



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

tape

after several days.



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

do

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...

and

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.



Thanks.

Jon Gocher
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: JVM
"Bob,

We haven't done it but are reasonably certain that something can be =
cobbled
together but it won't be easy to make it production ready. The ROI =
would
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 =
from,
a DC task. =20

With that said you should be able to start a separate TCB in the DC =
region
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 =
and
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 =
files,
etc from a DC task. You would still need to use an ECB to coordinate =
with
an interface routine that would make the PC from its own TCB. This has =
the
same issues as above but is a little more manageable because you keep =
all
the JVM crud (the word I would use in mixed company) out of the DC =
region.

Both of the above approaches leave much to be desired. First, if you =
aren't
careful you may just find yourself writing your own DC like service. =
That
seems silly. In addition, making it robust for production, with good
performance characteristics as well as manageable, will be real =
challenge
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 =
task
cross memory. Either of these approaches would be much more manageable =
than
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.

Cheers,

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

=A0

Outcomes