Have we seen this in practice?
Because of the way the CTC driver is structured, one address is input
and one is output if you're speaking IP over it. It's not like using
CTC for RSCS where each address is bidirectional. So if only one of
the pair is there, I'd say that it's broken and you shouldn't try to
use it as a network device. Now if it comes up later, it would be
nice to autodetect that and tell that you now had a CTC pair and try
to start the interface...but that might be a lot more trouble than
it's worth. If your CTCs are flapping, something's clearly pretty
wrong already.
Adam
Not 100% sure Adam.. Bastian may have a point here..
Assuming the CTC pair (comprising the link to a TCP/IP virtual machine
or as a hercules means to talk outside) could be defined dynamically at
run time, I see where a problem may exist.
1st, when running under VM, CTCs have to be defined one after the other
(CP DEFINE CTC 0A00#CP DEFINE CTC 0A01 - followed by the appropriate
'couple' commands)
2nd under hercules, you either attach both CTCs as a group such as
"attach 0A00.2 CTCI ..." or independently (attach 0A00 CTCI .. attach
0A01 CTCI ...)
In any case, the CRWs are going to be made pending and presented one
after the other.. Any hotplugging technology will then receive a report
for the 1st instance followed by a report for the 2nd instance.
So it's clearly a possibility for a time window to exist for only the
first of the 2 exposures to either 'exist' or be known to the operating
system aven though the second exposure will eventually get there.
I doubt using some time lapse will do either.. This definitely doesn't
cover the fact of manually defining each CTC independently and manually.
This is only an issue for devices that start to exist *AFTER* IPL
(hotplugged devices).
(just my $.02..)
--Ivan