On Tuesday, 02/26/2008 at 04:36 EST, "Schuh, Richard" <[EMAIL PROTECTED]> 
wrote:
> This morning, the following was displayed on the console of one of our 
VSWITCH 
> controller machines (DTCVSW1 and DTCVSW2):
> 
> 16:12:32 DTCOSD020E VSWITCH-OSD device VM3SW10F00DEV: Unexpected SIOCC 3 
from Read operation on 0F00 
> 16:12:32 DTCOSD082E VSWITCH-OSD shutting down: 
[...]                                           
> 16:12:32 DTCOSD102I VSWITCH-OSD device VM3SW10F00DEV: Restarting device 
0F00 through AUTORESTART     
> 16:12:33 DTCOSD045E VSWITCH-OSD device VM3SW10F00DEV: Error getting XA 
subchannel id for device 0F00 
> 16:12:33 DTCOSD082E VSWITCH-OSD shutting down:
[...]                    
> 16:12:33 DTCOSD361I VSWITCH-OSD link removed for 
VM3SW10F00DEV                                       
> 16:13:03 DTCIUC031I TCP/IP server connected to *VSWITCH system service   
 
> 
> The machine having the problem was DTCVSW1. Both DTCVSW1 and DTCVSW2 are 
logged 
> on; however, no OSA device is now attached to DTCVSW1. The commands Q 
VSWITCH 
> and Q OSA yield these results:
> 
> q 
vswitch                                                                    
 
> VSWITCH SYSTEM VM3SW1   Type: VSWITCH Connected: 81   Maxconn: 
INFINITE      
>   PERSISTENT  RESTRICTED    NONROUTER                 Accounting: 
OFF        
>   VLAN 
Unaware                                                               
>   State: 
Ready                                                               
>   IPTimeout: 5         QueueStorage: 
8                                       
>   Portname: UNASSIGNED RDEV: 0F00 Controller: DTCVSW2  VDEV:  0F00 
BACKUP    
>   Portname: UNASSIGNED RDEV: 1800 Controller: DTCVSW2  VDEV:  
1800           
> 
> q osa                                                                
> OSA  0F00 ATTACHED TO DTCVSW2  0F00 DEVTYPE OSA         CHPID 00 OSD 
> OSA  0F01 ATTACHED TO DTCVSW2  0F01 DEVTYPE OSA         CHPID 00 OSD 
> OSA  0F02 ATTACHED TO DTCVSW2  0F02 DEVTYPE OSA         CHPID 00 OSD 
> OSA  1040 ATTACHED TO TCPIP    1040 DEVTYPE OSA         CHPID 0C OSD 
> OSA  1041 ATTACHED TO TCPIP    1041 DEVTYPE OSA         CHPID 0C OSD 
> OSA  1042 ATTACHED TO TCPIP    1042 DEVTYPE OSA         CHPID 0C OSD 
> OSA  1800 ATTACHED TO DTCVSW2  1800 DEVTYPE OSA         CHPID 0D OSD 
> OSA  1801 ATTACHED TO DTCVSW2  1801 DEVTYPE OSA         CHPID 0D OSD 
> OSA  1802 ATTACHED TO DTCVSW2  1802 DEVTYPE OSA         CHPID 0D OSD   
> 
> Being semi-illeterarte in matters VSWITCH, I have a couple of questions: 

> 
> What happens if the 18xx devices have a problem?
The VSWITCH will go back to Fxx.

> What is the status of devices Fxx? 
They are idle, eligible to be backup.

> Can they be safely taken from DTCVSW2? 
Only via SET VSWITCH RDEV to exclude them.  Do not try to DETACH them from 
DTCVSW2.

> Is there any good way to see if the Fxx devices are in need of a CE's 
tender 
> touch? Assuming that they can be taken from DTCVSW2, would varying them 
offline 
> and back on be sufficient to see if this was a transient error, or is 
there 
> some other test that can be done?.
> In other words, what should be done?

Check your operator's console log.  I suspect that you have messages re: 
DTCSVS1, F00, or chpid 0.

> 16:13:03 DTCIUC031I TCP/IP server connected to *VSWITCH system service 

If it connected, that implies that it was previously disconnected.  A 
disconnected controller will upset CP to no end and he will failover the 
controller and take the OSAs with it.  Someone logged onto the controller 
sitting in MORE/HOLDING would be sufficient cause.  But you should also 
see more errors earlier in the controller's console log.

Alan Altmark
z/VM Development
IBM Endicott

Reply via email to