Re: VSWITCH/network problem
Sorry, we got a new release of Groupwise. I use to be able to cut and paste from Extra to an email, and it would go out in text mode. Now, it seems, the paste are graphic images. Also, what I have seen is if I paste one line, it is imbedded in the email. If I paste multiple lines, they seem to be moved to separate attachments. I'll resend when I can get our email person to help me reset my defaults to straight text mode. Sorry about that Tom Duerbusch THD Consulting Alan Ackerman [EMAIL PROTECTED] 3/23/2007 1:10 AM Several somethings are missing from you post. I see nothing after any of these colons: From SYSTEM CONFIG: From USER DIRECT: The controllers don't specify anything for a particular machine: BTW, what we see on the console when the batch update fails is the IP disconnect message: On Wed, 21 Mar 2007 10:24:38 -0500, Tom Duerbusch [EMAIL PROTECTED] wrote: I have a weird/flacky problem. I'm looking for thoughts on directions I can take on this. We have a MS/Access application that access DB2/VSE over a DRDA connection. The VSE that hosts the DB2 engine is connected to the network via VSWITCH and we go out to the world via an OSA card on the z/890. There are two types of functions this application does, transactional and a monthly batch update. We upgraded from z/VM 5.1 to z/VM 5.2 Service Level 0602 on January 13, 2007 and apparently the batch update function stopped working at that time. The user that does the batch processing was out on a medical leave so we didn't know there was a problem until she got back in late February. And me, being very busy, made a lot of changes to VSE in those couple months. So it has been very difficult to backtrack the VSE side to find where things broke. Well, the broken part is not in VSE. The broken production system STLESA2 also has a test system STLESA2F which is a flash copy of the origional system. Only the IP address in the IPINIT00 CONFIG is different. That system was flashed on February 23. And the user has always been able to run the batch updates on this test system. Well, over the weekend, I backed up to take the STLESA2F system, and then flashed STLESA2 to STLESA2F and brought up STLESA2F. Other than the IP address, they are both identical. She can't do the batch updates on STLESA2 but still can on STLESA2F. So, the problem resides outside of VSE. The users PC and software are obviously the same, so the problem must lie in the network, or rather some configuration item in the network that is different for STLESA2 vs STLESA2F. And that is what I need help on. 1. Is there any VM commands, other then Q VSWITCH that will show me some/all configuration items that may be set for a particular connection? q vswitch detail VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 8Maxconn: INFINITE PERSISTENT RESTRICTEDPRIROUTER Accounting: OFF VLAN Unaware State: Ready IPTimeout: 5 QueueStorage: 8 Portname: UNASSIGNED RDEV: 2000 Controller: DTCVSW2 VDEV: 2000 Portname: UNASSIGNED RDEV: 2003 Controller: DTCVSW2 VDEV: 2003 BACKUP VSWITCH Connection: RX Packets: 2949792Discarded: 120Errors: 0 TX Packets: 4208954Discarded: 0 Errors: 0 RX Bytes: 405358583TX Bytes: 2002478169 Device: 2002 Unit: 002 Role: DATA Adapter Owner: STLESA2 NIC: 0800 Name: THD390 RX Packets: 105Discarded: 0 Errors: 0 TX Packets: 112Discarded: 0 Errors: 0 RX Bytes: 7338 TX Bytes: 8080 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.5 MAC: 02-00-00-00-00-04 Adapter Owner: STLESA2F NIC: 0800 Name: THD390 RX Packets: 3329 Discarded: 0 Errors: 0 TX Packets: 9765 Discarded: 0 Errors: 0 RX Bytes: 786073 TX Bytes: 1160926 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.6 MAC: 02-00-00-00-00-07 From
VSWITCH/network problem try #3
Try #3, this time, in text mode. I have a weird/flacky problem. I'm looking for thoughts on directions I can take on this. We have a MS/Access application that access DB2/VSE over a DRDA connection. The VSE that hosts the DB2 engine is connected to the network via VSWITCH and we go out to the world via an OSA card on the z/890. There are two types of functions this application does, transactional and a monthly batch update. We upgraded from z/VM 5.1 to z/VM 5.2 Service Level 0602 on January 13, 2007 and apparently the batch update function stopped working at that time. The user that does the batch processing was out on a medical leave so we didn't know there was a problem until she got back in late February. And me, being very busy, made a lot of changes to VSE in those couple months. So it has been very difficult to backtrack the VSE side to find where things broke. Well, the broken part is not in VSE. The broken production system STLESA2 also has a test system STLESA2F which is a flash copy of the original system. Only the IP address in the IPINIT00 CONFIG is different. That system was flashed on February 23. And the user has always been able to run the batch updates on this test system. Well, over the weekend, I backed up to take the STLESA2F system, and then flashed STLESA2 to STLESA2F and brought up STLESA2F. Other than the IP address, they are both identical. She can't do the batch updates on STLESA2 but still can on STLESA2F. So, the problem resides outside of VSE. The users PC and software are obviously the same, so the problem must lie in the network, or rather some configuration item in the network that is different for STLESA2 vs STLESA2F. And that is what I need help on. 1. Is there any VM commands, other then Q VSWITCH that will show me some/all configuration items that may be set for a particular connection? q vswitch detail VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 8Maxconn: INFINITE PERSISTENT RESTRICTEDPRIROUTER Accounting: OFF VLAN Unaware State: Ready IPTimeout: 5 QueueStorage: 8 Portname: UNASSIGNED RDEV: 2000 Controller: DTCVSW2 VDEV: 2000 Portname: UNASSIGNED RDEV: 2003 Controller: DTCVSW2 VDEV: 2003 BACKUP VSWITCH Connection: RX Packets: 2949792Discarded: 120Errors: 0 TX Packets: 4208954Discarded: 0 Errors: 0 RX Bytes: 405358583TX Bytes: 2002478169 Device: 2002 Unit: 002 Role: DATA Adapter Owner: STLESA2 NIC: 0800 Name: THD390 RX Packets: 105Discarded: 0 Errors: 0 TX Packets: 112Discarded: 0 Errors: 0 RX Bytes: 7338 TX Bytes: 8080 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.5 MAC: 02-00-00-00-00-04 Adapter Owner: STLESA2F NIC: 0800 Name: THD390 RX Packets: 3329 Discarded: 0 Errors: 0 TX Packets: 9765 Discarded: 0 Errors: 0 RX Bytes: 786073 TX Bytes: 1160926 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.6 MAC: 02-00-00-00-00-07 From SYSTEM CONFIG: DEFINE VSWITCH VSW1 RDEV 2000 2003 PRIROUTER MODIFY VSWITCH VSW1 GRANT TSTESA5 MODIFY VSWITCH VSW1 GRANT TSTESA5F VMLAN MACPREFIX 030001 From USER DIRECT: USER TSTESA5F ~~ NICDEF 800 TYPE QDIO LAN SYSTEM VSW1 The controllers don't specify anything for a particular machine: q controller Controller DTCVSW2 Available: YES VDEV Range: * Level 520 Capability: IP ETHERNET VLAN_ARP SYSTEM VSW1 Primary Controller: * VDEV: 2000 SYSTEM VSW1 Backup Controller: * VDEV: 2003 Controller DTCVSW1 Available: YES VDEV Range: * Level 520 Capability: IP ETHERNET VLAN_ARP
Re: VSWITCH/network problem
Several somethings are missing from you post. I see nothing after any of these colons: From SYSTEM CONFIG: From USER DIRECT: The controllers don't specify anything for a particular machine: BTW, what we see on the console when the batch update fails is the IP d isconnect message: On Wed, 21 Mar 2007 10:24:38 -0500, Tom Duerbusch [EMAIL PROTECTED] .com wrote: I have a weird/flacky problem. I'm looking for thoughts on directions I can take on this. We have a MS/Access application that access DB2/VSE over a DRDA connecti on. The VSE that hosts the DB2 engine is connected to the network via VSWITCH and we go ou t to the world via an OSA card on the z/890. There are two types of functions this application does, transactional an d a monthly batch update. We upgraded from z/VM 5.1 to z/VM 5.2 Service Level 0602 on January 13, 2007 and apparently the batch update function stopped working at that time. The user that does the batch processing was out on a medical leave so we didn't know there was a problem until she got back in late February. And me, being very bu sy, made a lot of changes to VSE in those couple months. So it has been very difficult to backtrack the VSE side to find where things broke. Well, the broken part is not in VSE. The broken production system STLES A2 also has a test system STLESA2F which is a flash copy of the origional system. Only the IP address in the IPINIT00 CONFIG is different. That system was flashed on February 23. And the us er has always been able to run the batch updates on this test system. Well, over the weekend, I backed up to take the STLESA2F system, and the n flashed STLESA2 to STLESA2F and brought up STLESA2F. Other than the IP address, they are bo th identical. She can't do the batch updates on STLESA2 but still can on STLESA2F. So, the problem resides outside of VSE. The users PC and software are obviously the same, so the problem must li e in the network, or rather some configuration item in the network that is different for STLES A2 vs STLESA2F. And that is what I need help on. 1. Is there any VM commands, other then Q VSWITCH that will show me som e/all configuration items that may be set for a particular connection? q vswitch detail VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 8Maxconn: INFINITE PERSISTENT RESTRICTEDPRIROUTER Accounting: OFF VLAN Unaware State: Ready IPTimeout: 5 QueueStorage: 8 Portname: UNASSIGNED RDEV: 2000 Controller: DTCVSW2 VDEV: 2000 Portname: UNASSIGNED RDEV: 2003 Controller: DTCVSW2 VDEV: 2003 BACKU P VSWITCH Connection: RX Packets: 2949792Discarded: 120Errors: 0 TX Packets: 4208954Discarded: 0 Errors: 0 RX Bytes: 405358583TX Bytes: 2002478169 Device: 2002 Unit: 002 Role: DATA Adapter Owner: STLESA2 NIC: 0800 Name: THD390 RX Packets: 105Discarded: 0 Errors: 0 TX Packets: 112Discarded: 0 Errors: 0 RX Bytes: 7338 TX Bytes: 8080 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.5 MAC: 02-00-00-00-00-04 Adapter Owner: STLESA2F NIC: 0800 Name: THD390 RX Packets: 3329 Discarded: 0 Errors: 0 TX Packets: 9765 Discarded: 0 Errors: 0 RX Bytes: 786073 TX Bytes: 1160926 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.6 MAC: 02-00-00-00-00-07 From SYSTEM CONFIG: From USER DIRECT: The controllers don't specify anything for a particular machine: BTW, what we see on the console when the batch update fails is the IP disconnect message: But buffer length can be different values but seem to always be between 2000 and 3500. Right now, I've pretty well cleared DB2/VSE and VSE/ESA 2.7 as being the problem. The only other change in the communication path was the z/VM update. That is my current target. Thanks for any
VSWITCH/network problem
I have a weird/flacky problem. I'm looking for thoughts on directions I can take on this. We have a MS/Access application that access DB2/VSE over a DRDA connection. The VSE that hosts the DB2 engine is connected to the network via VSWITCH and we go out to the world via an OSA card on the z/890. There are two types of functions this application does, transactional and a monthly batch update. We upgraded from z/VM 5.1 to z/VM 5.2 Service Level 0602 on January 13, 2007 and apparently the batch update function stopped working at that time. The user that does the batch processing was out on a medical leave so we didn't know there was a problem until she got back in late February. And me, being very busy, made a lot of changes to VSE in those couple months. So it has been very difficult to backtrack the VSE side to find where things broke. Well, the broken part is not in VSE. The broken production system STLESA2 also has a test system STLESA2F which is a flash copy of the origional system. Only the IP address in the IPINIT00 CONFIG is different. That system was flashed on February 23. And the user has always been able to run the batch updates on this test system. Well, over the weekend, I backed up to take the STLESA2F system, and then flashed STLESA2 to STLESA2F and brought up STLESA2F. Other than the IP address, they are both identical. She can't do the batch updates on STLESA2 but still can on STLESA2F. So, the problem resides outside of VSE. The users PC and software are obviously the same, so the problem must lie in the network, or rather some configuration item in the network that is different for STLESA2 vs STLESA2F. And that is what I need help on. 1. Is there any VM commands, other then Q VSWITCH that will show me some/all configuration items that may be set for a particular connection? q vswitch detail VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 8Maxconn: INFINITE PERSISTENT RESTRICTEDPRIROUTER Accounting: OFF VLAN Unaware State: Ready IPTimeout: 5 QueueStorage: 8 Portname: UNASSIGNED RDEV: 2000 Controller: DTCVSW2 VDEV: 2000 Portname: UNASSIGNED RDEV: 2003 Controller: DTCVSW2 VDEV: 2003 BACKUP VSWITCH Connection: RX Packets: 2949792Discarded: 120Errors: 0 TX Packets: 4208954Discarded: 0 Errors: 0 RX Bytes: 405358583TX Bytes: 2002478169 Device: 2002 Unit: 002 Role: DATA Adapter Owner: STLESA2 NIC: 0800 Name: THD390 RX Packets: 105Discarded: 0 Errors: 0 TX Packets: 112Discarded: 0 Errors: 0 RX Bytes: 7338 TX Bytes: 8080 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.5 MAC: 02-00-00-00-00-04 Adapter Owner: STLESA2F NIC: 0800 Name: THD390 RX Packets: 3329 Discarded: 0 Errors: 0 TX Packets: 9765 Discarded: 0 Errors: 0 RX Bytes: 786073 TX Bytes: 1160926 Device: 0802 Unit: 002 Role: DATA Options: IPv4 VLAN Unicast IP Addresses: 192.168.99.6 MAC: 02-00-00-00-00-07 From SYSTEM CONFIG: From USER DIRECT: The controllers don't specify anything for a particular machine: BTW, what we see on the console when the batch update fails is the IP disconnect message: But buffer length can be different values but seem to always be between 2000 and 3500. Right now, I've pretty well cleared DB2/VSE and VSE/ESA 2.7 as being the problem. The only other change in the communication path was the z/VM update. That is my current target. Thanks for any suggestions. Tom Duerbusch THD Consulting
