I want to thank everyone who responded. We now have redundant connections
for all three CTCA interfaces between the two systems, and shouldn't have to
worry if this ever comes up again....

Also, Alan:

The ISFC links do show as one being up and the other down. Do you know if it
will automatically switch to the back-up connection should the first one
fail, or will it take manual intervention?

For anyone interested, here are queries of the three connection sets...

q islink
Link: E242               Type: CTCA
Node:  POLAR        Bytes Sent:          87043
State: Up           Bytes Received:      60631
Buffer Count:  16   Status: Idle
Link: E342               Type: CTCA
Node:               Bytes Sent:          20732
State: Down         Bytes Received:      20732
Buffer Count:  16   Status: Idle
Ready; T=0.01/0.01 14:37:13
smsg rscs q group polar
Ready; T=0.01/0.01 14:42:22
Group                                                 Alternate
Name     --------------- Primary Links -------------- Link
POLAR    CTC1     CTC2     ...      ...      ...      ...
smsg rscs q links
Ready; T=0.01/0.01 14:42:30
Link                         Line
Name     Status     Type     Addr LU Name  Logmode  Queueing
CTC1     connect    NJE      E240 ...      ...      priority
CTC2     connect    NJE      E340 ...      ...      priority
*NOTHERE inactive   NOTIFY   0000 ...      ...      FIFO
*UNKNOWN inactive   NOTIFY   0000 ...      ...      FIFO
*LPRHOLD inactive   NOTIFY   0000 ...      ...      FIFO
*UFTHOLD inactive   NOTIFY   0000 ...      ...      FIFO
6 links found
smsg pvm q system
Ready; T=0.01/0.01 14:44:14
08/17/10 14:44:14 DVMQRY080I The local node is GRIZZLY, Users 0, PVM
2.1.1901, built 10/26/99 14:12:10
08/17/10 14:44:14 DVMQRY081I Link CTC1     Type CTCA     Address  141
Users 1 CONNECT  Group POLAR
08/17/10 14:44:14 DVMQRY081I Link CTC2     Type CTCA     Address  241
Users 0 CONNECT  Group POLAR


-- 
Robert P. Nix          Mayo Foundation        .~.
RO-OC-1-18             200 First Street SW    /V\
507-284-0844           Rochester, MN 55905   /( )\
-----                                        ^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."



On 8/17/10 10:17 AM, "Alan Altmark" <alan_altm...@us.ibm.com> wrote:

> On Tuesday, 08/17/2010 at 09:52 EDT, RPN01 <nix.rob...@mayo.edu> wrote:
>> I?m going to dig into the manuals in a moment, but can anyone quickly
> tell me 
>> if the CTCA connections used by the various parts of CSE can have
> redundant 
>> sets of connections? (I?m about to lose the set I?m using to a POR, and
> I need 
>> to know if I should switch to a second set, or do a better job of
>> implementing...)
>> 
>> RSCS uses a set, PVM uses a set, and we have one set for ISFC. Can any
> or all 
>> of these have duplicate paths across a second set of CTCAs?
> 
> ISFC does not allow a redundant connection.  If memory serves, you can
> configure them, but the duplicate will not be activated.  You have to
> deactivate one before another can go active.  If you have alternate paths,
> then you will still maintain the integrity of the cluster while you take
> the links down/up.  Just do them one at a time.
> 
> RSCS and PVM allow redundant paths, but you have to ensure that you have
> created groups and/or routing tables to handle them.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott

Reply via email to