It does have the appearance of being a bug, but probably not one in RSCS. I think that the SHUTDOWN QUICK is really a circumvention of an MVS or VTAM bug. I know that an NJE link with RSCS at either end has no such problem. Would a requirement to enhance RSCS to circumvent a bug in another system be likely to be approved?
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of A. Harry Williams > Sent: Wednesday, August 09, 2006 11:16 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Signal support > > > On Wed, 9 Aug 2006 14:10:05 -0400 Alan Altmark said: > >On Wednesday, 08/09/2006 at 11:02 MST, "Schuh, Richard" > <[EMAIL PROTECTED]> > >wrote: > >> Maybe on VM it has, but I have found that a clean shutdown > of RSCS goes > >a long > >> way toward preventing operational headaches when trying to > reconnect to > >z/OS or > >> MVS systems. Before I created a SHUTDOWN EXEC that tells RSCS to > >SHUTDOWN > >> QUICK, many of our MVS systems would have to drain the > link and restart > >it. > >> Sometimes, there were time dependencies - a link would have to be > >drained on > >> both the MVS system and on VM; then the start order needed to be VM > >first, JES > >> next. Following the SHUTDOWN QUICK, we have only one > problem link and it > >is > >> consistent. It does start after about 15 minutes. > > > >I'm not sure that you're aren't describing a bug somewhere, but is it > >technical problem that you say can be reasonably avoided by orderly > >shutdown. So I'd say: write up an RSCS requirement to support signal > >shutdown. > > It may be a bug, but it's a persistent bug. We've had the "problem" > for years. Therapy helped, as did banging our heads on the > concrete wall > outside. We finally settled on Netview automation on the MVS side to > look for the problem, drain and restart the link. A lot less > blood on the > floor. > > /ahw > > > > >Alan Altmark > >z/VM Development > >IBM Endicott >
