Our D.R. situation (was:RE: Changing an IODF in batch)

-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@xxxxxxxxxxx] On Behalf Of R.S.
Sent: Monday, February 27, 2006 6:00 PM
To: IBM-MAIN@xxxxxxxxxxx
Subject: Re: Changing an IODF in batch


<snip>


Ok, I get it now. In fact I didn't even think about such scenario, I
mean "unpredictable" DR site.
BTW: Here, in Poland we don't have almost any "third party" DR sites.
All (few!) DR sites are maintained by companies who own primary site
also. That's why I'm biased.

BTW: 3494 Library ID is not hardcoded in metal. It can be
easily changed
from operator panel (although requires Service logon). It is
quick and
easy. Is it the option for you to chaneg LIB ID instead of IODF ?

I can ask. But I doubt that Sungard will modify their procedures for me.
I don't know how difficult it is to change the LIBRARY ID.


BTW2: AFAIR It is not required to code LIB ID in IODF at all.
Having ID
is more convenient, but not required. I don't remmeber
details, I always
code the ID.

I was considering this. But this means that I need an "extra" ATL and
VTS in my IODF. I don't want to leave the fields blank for our actual
production ATL and VTS. To me, it is not a big deal, but if the
libraries were "off line" during IPL, it requires an ACTIVATE to get
them back. Management here is reluctant to allow this as a standard
operating procedure. I won't get into why, I get "tacky".


BTW3: What is the advantage from running your application far
away from
"home" ? Who will maintain it, who will use it ? How the
tapes come to
Arizona ? Do you have proper connectivity to the system
assured as well
? Just curious.

Philadelphia is in Pennsylvania. We are close to Dallas, Texas. From
what I understand, we moved from the Los Colinas (another city near
Dallas) to Philly because the hardware (VTS & ATL 3592 drives) only
exist in Philly (well a Sungard site with those drives, that is).
Sungard supplies a "work area recovery" site so that people can work on
the system, using their equipment. This is in another near-Dallas city,
Grand Prairie.

They also supply Internet connectivity, so people can use our Microsoft
Terminal Services servers and VPN servers to work from where ever they
happen to be.

The Sungard people, with our documentation, are capable of restoring our
basic z/OS system. They have done this. At that point, there had better
be some IT employees who survived the disaster, because our "Production
Control" people do all the forward recovery. Supposedly, that process is
well enough documented so that anybody who is familar with our software
(CA-1, CA-11, etc) can use our documentation to actually do the forward
recovery. But this documentation has not been "tested" using people who
are not already familar with our system.

I will say that it is likely that if a disaster manages to "take out"
our two buildings here during normal working hours (like a bomb or
really powerful tornado), then the company will likely fail due to too
many people being gone. But, with the documentation that is off-site,
the State Board of Insurance should be able to get another insurance
company to "take over" the policies and administer them. That would mean
that our policy holders would be covered until the policies were taken
over by another company.

Of course, the most likely disaster is just the hardware being damaged,
with little loss of life. In that case, the company would do very well
running at a Sungard site. And our normal employees either working at
the Grand Prairie works site or via the Internet.


Regards
--
Radoslaw Skorupka
Lodz, Poland


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.