Network Problem?
At 9:57 local time, I sent a reply to something on the list. I just received, at 13:50, a notice that said Delivery delayed for the note. Is anybody else getting this kind of response? Assuming that this note reaches its destination, which may be a bad assumption. Regards, Richard Schuh
Re: Network Problem?
No, no such problems here. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Wednesday, July 01, 2009 4:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Network Problem? At 9:57 local time, I sent a reply to something on the list. I just received, at 13:50, a notice that said Delivery delayed for the note. Is anybody else getting this kind of response? Assuming that this note reaches its destination, which may be a bad assumption. Regards, Richard Schuh Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Network Problem?
Schuh, Richard wrote: At 9:57 local time, I sent a reply to something on the list. I just received, at 13:50, a notice that said Delivery delayed for the note. Is anybody else getting this kind of response? Assuming that this note reaches its destination, which may be a bad assumption. Regards, Richard Schuh I noticed some messages arriving out of order today. Replies that came before the message they replied to. The list must be in some kind of a time warp today. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Network Problem?
A time warp it might be. The fact that it took nearly 4 hours to get a message saying that delivery of a message was delayed seems sort of ironic. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Stephen Frazier Sent: Wednesday, July 01, 2009 3:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Network Problem? Schuh, Richard wrote: At 9:57 local time, I sent a reply to something on the list. I just received, at 13:50, a notice that said Delivery delayed for the note. Is anybody else getting this kind of response? Assuming that this note reaches its destination, which may be a bad assumption. Regards, Richard Schuh I noticed some messages arriving out of order today. Replies that came before the message they replied to. The list must be in some kind of a time warp today. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Network Problem?
Just received a similar notice here, on a reply to a different mailing list. Also hosted at UARK.EDU. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of Schuh, Richard Sent: Wednesday, July 01, 2009 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Network Problem? At 9:57 local time, I sent a reply to something on the list. I just received, at 13:50, a notice that said Delivery delayed for the note. Is anybody else getting this kind of response? Assuming that this note reaches its destination, which may be a bad assumption. Regards, Richard Schuh
Weird Network Problem .. also posted on the LINIX-390 list
I visited a customer yesterday, and they mentioned a weird problem: They have a z/Linux guest that's acting as an SNA gateway for some VSE users. So it's dual-homed: a virtual NIC (vNIC) for incoming TCP/IP traffic, and a real OSA for outgoing SNA (to the VSE guest(s) -- not sure what happens there, whether one is a gateway or what). So this all works, BUT every so often -- like a couple of times an hour -- IP traffic to/from the gateway machine starts going over the real OSA. This seems to mean (based on observed behavior) that IP stuff originating FROM that machine works, but external stuff (say, SNMP requests) don't. It also means that their SNA users get dropped *sometimes*. Fooling around on the guest with ping and traceroute using -I proved to my satisfaction that this is what's happening (though of course I'm always happy to be proven wrong). And after a few minutes, it all goes back to normal. route -nNvee and with no operands seems to support that no visible routing changes are occurring. Note that when things are switched, I can't even ping the gateway using the vNIC interface! It feels like something is deciding that the real OSA is better -- faster? shinier? less virtual? -- and deciding to use that, but then for some other reason switches back. But that's a SWAG. Ideas? Output of various commands is below. Oh, one other thing: I've never seen some of the output from Q V OSA below (the INP + 01 stuff). But then, I'm not used to fooling with real OSAs attached to guests. I didn't see anything about this output in the HELP file for QUERY VIRTUAL OSA. Thanks... ...phsiii === * QUERY VIRTUAL OSA output OSA 0300 ON NIC 0300 UNIT 000 SUBCHANNEL = 0004 0300 DEVTYPE OSA CHPID 00 OSD 0300 QDIO-ELIGIBLE QIOASSIST-ELIGIBLE OSA 0301 ON NIC 0300 UNIT 001 SUBCHANNEL = 0005 0301 DEVTYPE OSA CHPID 00 OSD 0301 QDIO-ELIGIBLE QIOASSIST-ELIGIBLE OSA 0302 ON NIC 0300 UNIT 002 SUBCHANNEL = 0006 0302 DEVTYPE OSA CHPID 00 OSD 0302 QDIO ACTIVE QIOASSIST ACTIVE 0302 0302 INP + 01 IOCNT = 01028525 ADP = 010 PROG = 000 UNAVAIL = 118 0302 BYTES = 0B9345BF 0302 OUT + 01 IOCNT = ADP = 000 PROG = 000 UNAVAIL = 128 0302 BYTES = 0302 OUT + 02 IOCNT = ADP = 000 PROG = 000 UNAVAIL = 128 0302 BYTES = 0302 OUT + 03 IOCNT = 09718461 ADP = 000 PROG = 128 UNAVAIL = 000 0302 BYTES = 0001125268FC 0302 OUT + 04 IOCNT = ADP = 000 PROG = 000 UNAVAIL = 128 0302 BYTES = OSA 0800 ON OSA 0873 SUBCHANNEL = 0800 DEVTYPE OSA CHPID F3 OSD 0800 QDIO-ELIGIBLE QIOASSIST-ELIGIBLE OSA 0801 ON OSA 0874 SUBCHANNEL = 0001 0801 DEVTYPE OSA CHPID F3 OSD 0801 QDIO-ELIGIBLE QIOASSIST-ELIGIBLE OSA 0802 ON OSA 0875 SUBCHANNEL = 0002 0802 DEVTYPE OSA CHPID F3 OSD 0802 QDIO ACTIVE QIOASSIST ACTIVE 0802 0802 INP + 01 IOCNT = 45963134 ADP = 009 PROG = 000 UNAVAIL = 119 0802 BYTES = 0003F4EF805D 0802 OUT + 01 IOCNT = ADP = 000 PROG = 000 UNAVAIL = 128 0802 BYTES = 0802 OUT + 02 IOCNT = ADP = 000 PROG = 000 UNAVAIL = 128 0802 BYTES = 0802 OUT + 03 IOCNT = 27987274 ADP = 000 PROG = 128 UNAVAIL = 000 0802 BYTES = 000157AA76F9 0802 OUT + 04 IOCNT = ADP = 000 PROG = 000 UNAVAIL = 128 0802 BYTES = * ifconfig output eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:03 inet addr:172.17.3.192 Bcast:172.17.255.255 Mask:255.255.0.0 inet6 addr: fe80::200:0:300:3/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1067812 errors:0 dropped:0 overruns:0 frame:0 TX packets:9720081 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:160032156 (152.6 Mb) TX bytes:4600399128 (4387.2 Mb) eth1 Link encap:Ethernet HWaddr 02:00:41:00:01:01 inet6 addr: fe80::200:4100:0:101/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:49295490 errors:0 dropped:0 overruns:0 frame:0 TX packets:28034759 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14727109133 (14044.8 Mb) TX bytes:5765808842 (5498.7 Mb) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6021 errors:0 dropped:0 overruns:0 frame:0 TX packets:6021 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:432783 (422.6
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
