On Friday, 06/09/2006 at 08:48 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > I never saw the problem on a 3088 - we had a 9088 that apparently did the right > thing when it received the IPL reset signal :) In any event, this applies to > anything that causes an interrupt when the stand-alone program has been ipled > and is waiting for the console interrupt.
In the Dark Ages (stone knives and bear skins), CTCs were problematic for SA programs because the interrupts are generated by the system on the *other* end. The various SA programs that still depend on an I/O interrupt in addition to, or instead of, LOADPARM were changed in the Middle Ages (represented by the invention of Sense ID) to examine more closely the cyberDNS of interrupting device. 3088s exacerbated the problem because it was so easy to fully interconnect the attached systems. Or someone decided that *now* would be good time to ENABLE one of the adapters. :-) For a 3088/CTC, the channel reset only affects *this* system's I/O status. The other side can still restart the link and annoy your SA program. If you find an SA program that gets confused by random interrupts and cannot be overridden by LOADPARM, you should probably call it in. With the XA I/O architecture there are all kinds of interrupts that can come in that have nothing to do with "a tape was mounted" or "somebody flipped the test/normal switch on the 3278" or "Attention was pressed on the 3215". Alan Altmark z/VM Development IBM Endicott
