This thread comes at a pivotal point for us because we're looking at the
same sort of CEC swap-out in the near future. When we conducted our first
DR test 10 years ago, we experienced very much the same problem: fully
mirrored couple data sets were convinced that we had somehow left the old
CFs offline despite having new CFs connected, fully functional, and happily
populated with all requisite structures. While it's true that we muddled
through the test with chronic XCF complaints that did not seem to affect
system operation, it looked ugly and would be hard to explain in a *real*
DR having to live forever with all that whining and moaning, however
non-life-threatening.
Our solution for DR was this set of Draconian measures:
1. Don't bother retaining the production CFRM couple data set at all. We
don't even mirror it now.
2. In preparing the DR environment from the 'driving' system, create a
fresh CFRM couple data set and prime with it a 'default' policy named in
COUPLExx.
3. IPL the first sysplex member pointing to the new CFRM couple data set
while using mirrored copies of the others.
4. Reply 'yeah, OK' to several (but not a lot of) WTORs demanding to know
if we have any idea what we're doing.
5. IPL the other sysplex members normally. No complaints or rude questions
from them.
I had thought that shutting systems down normally and cleanly would
circumvent this rocky road when we come back up with everything else intact
but for the CFs. OP's experience suggests otherwise. I now have to rethink
the whole process.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Cwi Jeret
<[EMAIL PROTECTED]
COM> To
Sent by: IBM IBM-MAIN@BAMA.UA.EDU
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Cleanup a unconnected Coupling
Facility
05/11/2008 09:34
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
In our case, of course the CF phisically does NOT exist because the Machine
Type has changed.
On the other hand I don't want to SETXCF FORCE,STR,STRNAME=xxx
because the Structures are active in production and are located on the
alternative CF's ...
Cwi Jeret .
----------------------------------------------------------------------------
-
On Sun, 11 May 2008 08:26:51 -0400, Knutson, Sam <[EMAIL PROTECTED]>
wrote:
>Contact IBM support.
>
>OK if you have to proceed without direct advice from IBM an excellent
>session given at SHARE in Orlando might help
>
>2876 - Successful Installation or Upgrade of a Coupling Facility (CF)
>Speakers: Mark Brooks (IBM Corporation)
>
>In this session, the speaker will describe the proper sequence of events
>when installing, removing, or replacing a Coupling Facility (CF) in your
>Sysplex. He will explain how z/OS uses the Coupling Facility Resource
>Manager (CFRM) policy to manage the coupling facilities, structures, and
>structure connectors in a Sysplex. When you perform the necessary
>fundamental operational procedures and configuration changes in the
>proper sequence, you will have success. Failure to perform this work in
>the correct order, at the right time can cause confusion, and in the
>worst case, outages for one, some, or all systems in a Sysplex. The
>speaker will describe the behavior of z/OS when a CF is not installed
>properly, and provide some techniques for resolving the various problems
>that then arise. This is a new session for Orlando.
>
>
>http://shareew.prod.web.sba.com/proceedingmod/abstract.cfm?abstract_id=1
>7311&conference_id=17
>
>or
>
>http://tinyurl.com/5yzh5q
>
>
>His summary advice on this was
>
>Fix: Structures Not Removed.
>
>If CF still exists:
>- Reconnect it
>- Initiate application processes as needed to perform
>recovery for failed-persistent connectors
>- As needed, finish removing structures from CF
>* Preferred solution because:
>- Avoids/recognizes loss of data
>- Allows applications to complete their recovery
>- Allows CFRM to resolve pending deletes cleanly
>
>* If CF no longer physically exists:
>- SETXCF FORCE,STR,STRNAME=xxx
>* To be avoided because:
>- Potential loss of data
>- Applications may require more elaborate recovery
>- Space in policy consumed with pending deletes that
>cannot be resolved
>These pending deletes do not impact applications
>You do not need to make them "go away"
>
>
>z/OS V1R9.0 MVS Setting Up A Sysplex, SA22-7625 may have some more
>advice.
>
>
> Best Regards,
>
> Sam Knutson, GEICO
> System z Performance and Availability Management
> mailto:[EMAIL PROTECTED]
> (office) 301.986.3574
>
>"Think big, act bold, start simple, grow fast..."
>
>
>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
>Behalf Of Cwi Jeret
>Sent: Sunday, May 11, 2008 2:48 AM
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: Cleanup a unconnected Coupling Facility
>
>We migrated our 2094 to 2097 .
>We prepared A new CFRM policy containing the new 2097 definition on the
>two
>CF lpars, CF2 and CF3.
>Now, after the migration we have CF3 defined on 2097 with active
>structures,
>but CF2 has still definitions of the old structures and remained pending
>with its
>2094 definition and with "NO SYSTEMS CONNECTED to this CF"
>
>How can we CLEANUP the remaining Structures in CF2 so that the new 2097
>difinition will take place so that we will be able to use the CF ??
>
>C. Jeret Bank- Hapoalim T.A.
----------------------------------------------------------------------
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
