Yes, we have run extended tests. Yes, the CBU-test ten-day limit comes into play. We have burned more than one CBU for a given DR test to accommodate our current DR folks' requirements. (Interestingly, if you CBU your specialty engines, they can't automatically downgrade you if you have an active LPAR based solely on them . . . and I won't say anything else about that; they definitely downgrade you automatically otherwise. Though they will call you about the expired entitlement when the code prevents the downgrade.)
On 3, we don't have any issues, as far as I know; we haven't switched actual prod to the DR infrastructure. I don't think any of our contracts would prohibit it, and I don't think any of our vendors would frown on it. Perhaps it's wishful thinking, but I think most mainframe ISVs are pretty mature about it and know their customers largely are not cheating. We've paid extra for CUoD for special events to be fair and honest to our vendors; no one should have to pay for a legitimate DR test, in my very humble opinion. If something goes very wrong, and you get stuck at DR for a while, I suppose that would be different . . . . First Tennessee Bank Mainframe Technical Support -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 07, 2019 4:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DR Failover [External Email] (Resurrecting an old thread) We're being 'urged' to demonstrate that we can fail over to our internal DR site, run for a while, then fail back. As I indicated previously, we've done countless short tests but never allowed production to run in DR; hence no need to fail back. My question here is not technical. Our DR site (self-owned and managed) runs normally with a single CP supported by enough CBU to run production. We have purchased several full power tests to enable up to 10 days of testing per outing. If you have a similar setup, 1. Have you performed an extended full-power test? 2. Does the 10-day testing limit come into play? 3. From our perspective, we are only testing, but we would be dealing with real production data in and out. Will this lead to a contractual conundrum? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of van der Grijn, Bart (B) Sent: Monday, June 5, 2017 5:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DR Failover The people doing the MF recovery vary by test. It's typically someone on the operational side of the house, with the folks that maintain the procedures riding shotgun. Our sysprog team is geographically dispersed (US/NL/PRC) so chances are there's someone left that wasn't swallowed by the giant crater. Bart -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Thursday, June 01, 2017 6:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DR Failover Never got traction on two of my questions, which are independent of technology. -- During a failover (test I would presume), who actually performs the DR procedure whatever it is? Sysprogs, operators, production control folks, or someone else? Has anyone dared to bring in a non-technical person like a manager? This question is crucial to business resiliency because, depending the reason for failover, your top technical folks may be indisposed for an extended duration. -- If you stayed in the DR environment long enough to have captured/updated live customer data, how did you eventually return to the production environment? This question is crucial to business resiliency because at some point down the line, you have to return or, as the poem goes, settle in for a long winter's nap. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
