We did not get an MIH message either. IBM identified it from the SNAPDUMP we did for the LOGOFF/FORCE PENDING. Apparently OSAs are not supposed to have MIH problems, but...
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, February 28, 2008 3:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VSWITCH/OSA Problem That looks to be a potential problem. I cannot directly tie my problem to it. We had no MIH message and no users are/were in LOGOFF/FORCE PENDING. However, it may be that ours is the same problem, but with different symptoms. Thanks, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI) > Sent: Thursday, February 28, 2008 11:49 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VSWITCH/OSA Problem > > We took an MIH hit on an OSA. IBM is developing APAR # > VM64398. You might consider doing an AST on it as it also > was responsible for a LOGOFF/FORCE pending condition. > > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Thursday, February 28, 2008 2:41 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VSWITCH/OSA Problem > > > Nobody logs on to the controller, so it was likely not a > MORE/HOLDING event. It was early in our day (the 16:xx:xx > time is GMT), so we were not at a peak. The controllers have > a REL 3000 share with QUICKDSP on. > We rarely hit over 50% cpu utilization on the system, so > their being starved of cpu is not the answer. The controllers > show numbers like > this: "CPU 00: Ctime=4 01:44:28 Vtime=0 00:00:01 Ttime=0 > 00:00:41" in response to IND USER uid EXP, so they obviously > do not consume cpu. We are not memory constrained. We seldom > see any paging. > > I guess that the cause will remain a mystery. Maybe I should > blame it on the OSA card :-) We are still using DTCVSW2 with > F00 as the backup device, so it remains an unknown. > > Regards, > Richard Schuh > > > > > -----Original Message----- > > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > > On Behalf Of Alan Altmark > > Sent: Thursday, February 28, 2008 11:21 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: VSWITCH/OSA Problem > > > > On Tuesday, 02/26/2008 at 06:12 EST, "Schuh, Richard" > > <[EMAIL PROTECTED]> > > wrote: > > > > > 16:12:32 HCPSWU2843E A stall was detected for TCP/IP > > Controller DTCVSW1. > > > HCPSWU2843E It was managing device 0F00 for VSWITCH > SYSTEM VM3SW1. > > > 16:12:32 HCPSWU2830I VSWITCH SYSTEM VM3SW1 status is in > > error recovery. > > > HCPSWU2830I DTCVSW2 is new VSWITCH controller. > > > 16:12:33 HCPSWU2831E CP Controller error 5 for DTCVSW1. 16:12:33 > > > HCPSWU2830I VSWITCH SYSTEM VM3SW1 status is ready. HCPSWU2830I > > > DTCVSW2 is VSWITCH controller. > > > > > > There was a daylong stream of DTCOSD246I and DTCOSD247I > > messages. The > > > only other messages from the controller were: > > > > > > OSA 0F00 DETACHED DTCVSW1 0F00 BY DTCVSW1 OSA 0F01 > DETACHED DTCVSW1 > > > 0F01 BY DTCVSW1 OSA 0F02 DETACHED DTCVSW1 0F02 BY DTCVSW1 > > > > For whatever reason, CP was unhappy with the controller. Perhaps > > your system is loaded down and the controller is > being starved > > of resources or something is driving it crazy with NETSTATs > or it is > > sitting in MORE/HOLDING or CP READ? > > The book says to ignore "error 5" (so why display it?). > > > > Alan Altmark > > z/VM Development > > IBM Endicott > > > -------------------------------------------------------- > > This message w/attachments (message) may be privileged, > confidential or proprietary, and if you are not an intended > recipient, please notify the sender, do not use or share it > and delete it. Unless specifically indicated, this message is > not an offer to sell or a solicitation of any investment > products or other financial product or service, an official > confirmation of any transaction, or an official statement of > Merrill Lynch. Subject to applicable law, Merrill Lynch may > monitor, review and retain e-communications (EC) traveling > through its networks/systems. The laws of the country of each > sender/recipient may impact the handling of EC, and EC may be > archived, supervised and produced in countries other than the > country in which you are located. This message cannot be > guaranteed to be secure or error-free. This message is > subject to terms available at the following link: > http://www.ml.com/e-communications_terms/. By messaging with > Merrill Lynch you consent to the foregoing. > -------------------------------------------------------- > -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. --------------------------------------------------------
