Re: IXC102D and REPLY DOWN

Some further clarification: To partition a system from the sysplex, XCF must isolate or fence the target system from the channel subsystem, in order to ensure that it is no longer capable of initiating I/O and thus can no longer affect resources (CF structures, data bases, etc.) shared by

Re: IXC102D and REPLY DOWN

On Sun, 27 Apr 2008 08:45:49 -0400, Mike Myers wrote: Hi: I'm looking to get clarification on whether or not the z/OS console IXC102A message requesting that the operator confirms that a member of a sysplex bas been reset always appears when a member is removed from the sysplex. The message I am

Re: IXC102D and REPLY DOWN

On Sun, 27 Apr 2008 12:50:29 -0700, Skip Robinson [EMAIL PROTECTED] wrote: I put this question to IBM recently and learned a difference between parallel sysplex (with CF) and basic sysplex (without). With CF supporting XCF, other systems are notified when one member is truly down. Without a CF,

Re: IXC102D and REPLY DOWN

On Mon, 28 Apr 2008 08:23:53 -0500, Mark Zelden [EMAIL PROTECTED] wrote: On Sun, 27 Apr 2008 12:50:29 -0700, Skip Robinson [EMAIL PROTECTED] wrote: I put this question to IBM recently and learned a difference between parallel sysplex (with CF) and basic sysplex (without). With CF supporting XCF,

Re: IXC102D and REPLY DOWN

On Mon, 28 Apr 2008 08:52:52 -0500, Mark Zelden [EMAIL PROTECTED] wrote: I want to make sure I have these 2 points correct... For a planned removal (V XCF,sysname,offline) in a parallel sysplex OR basic sysplex, you will not see IXC102A if you have an active and properly configured SFM policy.

Re: IXC102D and REPLY DOWN

On Mon, 28 Apr 2008 09:20:37 -0500, Bill Neiman [EMAIL PROTECTED] wrote: On Mon, 28 Apr 2008 08:52:52 -0500, Mark Zelden [EMAIL PROTECTED] wrote: I want to make sure I have these 2 points correct... For a planned removal (V XCF,sysname,offline) in a parallel sysplex OR basic sysplex, you will

Re: IXC102D and REPLY DOWN

On Mon, 28 Apr 2008 10:06:21 -0500, Mark Zelden [EMAIL PROTECTED] wrote: Bill, Thanks for the clarification. So why doesn't (can't) SFM prevent IXC102A after VARY XCF,sysname,OFFLINE if there is an active system in the same sysplex on the same CPC? It it just a SMOP, or is there a technical

Re: IXC102D and REPLY DOWN

@BAMA.UA.EDU Subject: Re: IXC102D and REPLY DOWN There is work in progress now to design more effective and consistent mechanisms for removing a system from the sysplex without operator intervention. It is highly desirable to eliminate operator prompting in this situation, because a great many

Re: IXC102D and REPLY DOWN

It is highly desirable to eliminate operator prompting in this situation, because a great many outages have occurred over the years when either (1) the operator or automation replies DOWN prematurely and data base corruption occurs as I described earlier, or (2) no one ever replies DOWN, and

Re: IXC102D and REPLY DOWN

On Mon, 28 Apr 2008 14:07:46 -0500, Bill Neiman [EMAIL PROTECTED] wrote: On Mon, 28 Apr 2008 10:06:21 -0500, Mark Zelden [EMAIL PROTECTED] wrote: Bill, Thanks for the clarification. So why doesn't (can't) SFM prevent IXC102A after VARY XCF,sysname,OFFLINE if there is an active system in the

IXC102D and REPLY DOWN

Hi: I'm looking to get clarification on whether or not the z/OS console IXC102A message requesting that the operator confirms that a member of a sysplex bas been reset always appears when a member is removed from the sysplex. The message I am referring to is: IXC102A XCF IS WAITING FOR

Re: IXC102D and REPLY DOWN

Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU IXC102D and REPLY

Re: IXC102D and REPLY DOWN

I'm looking to get clarification on whether or not the z/OS console IXC102A message requesting that the operator confirms that a member of a sysplex bas been reset always appears when a member is removed from the sysplex. No. In order for it NOT to appear, 1. You must have a parallel sysplex