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