Re: Vswitch problem on z/VM 5.2.0?
On Mon, 6 Mar 2006 18:40:11 -0500, Alan Altmark [EMAIL PROTECTED] wrote: From the book, The defvid defines the default VLAN ID to be associated with untagged frames received and transmitted by the Virtual Switch. Th is is also known as the native VLAN id in the switch. They must match. I will check to see what the native VLAN id in the real switch is and make my vswitch default VLAN ID match it. I didn't see anywhere in the zVM manuals where this was stated as a requirement. Did I miss it or doe s the doc need updating? How has the vswitch behavior changed from zVM 4.4.0 as a result of the introduction of the defvid? I find it confusing that the public IP addresses on VLAN 2 work fine with my current definitions. Do not use DEFINE VSWITCH VLAN xx to avoid SET VSWITCH GRANT VLANs. I had no intent to. As I posted earlier, every SET VSWITCH GRANT include s the VLAN parameter. And unless you want VM TCP/IP to route between VLANs on the same OSA trunk, I recommend not to use a VLAN-aware configuration in PROFILE TCPI P. The Network folk insist on using VLANs to the z/890. Since I give TCPIP dedicated OSA addresses I don't think I have a choice but to make TCPIP VLAN-aware at least for that link. Am I wrong? Are you recommending tha t I connect TCPIP to a vswitch with a GRANT for the VLAN ID rather than having TCPIP VLAN-aware directly to the OSA? Brian Nielsen
NICDEF Question- a little courious is all
Title: NICDEF Question- a little courious is all I used a NICDEF directory statement very similiar to the example below from the CP Planning and Admin guide. The VSWITCH is defined in the SYSTEM CONFIG file I do not have a MODIFY VSWITCH GRANT statement for this user. When the user logs on I get an error saying he is not authorized to couple to the VSWITCH. I know it is easy enough to fix that with the SET VSWITCH command, but I was under the impression that this was not necessary if the NICDEF was used in the directory (even without a MODIFY VSWITCH GRANT), as opposed to a DEFINE VSWITCH command. Did I miss something or are the old brain cells in need of a PTF or two? Define a simulated QDIO adapter using I/O devices 0500-0507 (eight devices) which will be coupled to the SYSTEM-owned INEWS LAN during LOGON processing: NICDEF 500 TYPE QDIO DEV 8 LAN SYSTEM INEWS __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: NICDEF Question- a little courious is all
Title: RE: NICDEF Question- a little courious is all VSWITCHes are always protected, even with a NICDEF directory card. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Huegel, Thomas Sent: Tue 3/7/2006 11:59 AM To: VMESA-L@LISTSERV.UARK.EDU Subject: NICDEF Question- a little courious is all I used a NICDEF directory statement very similiar to the example below from the CP Planning and Admin guide. The VSWITCH is defined in the SYSTEM CONFIG file I do not have a MODIFY VSWITCH GRANT statement for this user. When the user logs on I get an error saying he is not authorized to couple to the VSWITCH. I know it is easy enough to fix that with the SET VSWITCH command, but I was under the impression that this was not necessary if the NICDEF was used in the directory (even without a MODIFY VSWITCH GRANT), as opposed to a DEFINE VSWITCH command. Did I miss something or are the old brain cells in need of a PTF or two? Define a simulated QDIO adapter using I/O devices 0500-0507 (eight devices) which will be coupled to the SYSTEM-owned INEWS LAN during LOGON processing: NICDEF 500 TYPE QDIO DEV 8 LAN SYSTEM INEWS __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Vswitch problem on z/VM 5.2.0?
On Mon, 6 Mar 2006 18:40:11 -0500, Alan Altmark [EMAIL PROTECTED] wrote: From the book, The defvid defines the default VLAN ID to be associated with untagged frames received and transmitted by the Virtual Switch. Th is is also known as the native VLAN id in the switch. They must match. I checked with the Network group and according to them they do not have any native VLAN id set up - they do not want any untagged traffic in the network. What would I use in my DEFINE SWITCH for the defvid in this case? Is an unused VLAN number acceptable? Brian Nielsen
Re: Vswitch problem on z/VM 5.2.0?
You should be able to just leave the VLAN parameter off and let it default to VLAN UNAWARE. Rick Barlow Systems Engineering Consultant Nationwide Services Co., Enterprise Business Intelligence Services Mainframe, z/VM and zSeries Linux Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU wrote on 03/07/2006 02:40:29 PM: VMESA-L@LISTSERV.UARK.EDU On Mon, 6 Mar 2006 18:40:11 -0500, Alan Altmark [EMAIL PROTECTED] wrote: From the book, The defvid defines the default VLAN ID to be associated with untagged frames received and transmitted by the Virtual Switch. This is also known as the native VLAN id in the switch. They must match. I checked with the Network group and according to them they do not have any native VLAN id set up - they do not want any untagged traffic in the network. What would I use in my DEFINE SWITCH for the defvid in this case? Is an unused VLAN number acceptable? Brian Nielsen
Re: Vswitch problem on z/VM 5.2.0?
On Tuesday, 03/07/2006 at 02:58 CST, Brian Nielsen [EMAIL PROTECTED] wrote: So the problem is the vswitch interfering with the packets when it thinks VLAN 7 is for untagged traffic. I'll be taking Alan's advice and changing my vswitch definitions to use a defvid of 1. Presumably any unused VLAN would work in my case since there is no untagged traffic on the network. I recommend that the default VLAN id on the VSWITCH to match the native VLAN id on the physical switch since trunked switches are supposed be configured to use the same native VLAN. On Cisco switches, VLAN 1 is the default native VLAN id. Alan Altmark z/VM Development IBM Endicott
IBM System z9 zSeries Tech Conference: 20-24 March-Duesseldorf
Posted to VM, IBM-MAIN, and Linux for the attention of IBM mainframe enthusiasts across the board. Here's the next opportunity for a week of IBM Technical Education focused on System z, z/OS, z/VM, Linux on System z and Storage: IBM System z9 zSeries Technical Conference(plus Expo) 20-24 March 2006 Dusseldorf, Germany Hilton Dusseldorf Visit the web site for the list of sessions, abstracts, and enrollment information. http://www.ibm.com/training/conf/europe/zos (IBMers please enroll via IBM Global Campus) - Attendance is open to customers, partners, and IBMers (those interested in learning more about System z) - The event is held at the Hilton Dusseldorf - Format includes traditional lectures and also hands-on-labs - All sessions are presented in English by members of the z community including IBMers, Partners, ISV's, customers. Enroll today: http://www.ibm.com/training/conf/europe/zos We look forward to meeting you in Dusseldorf. Regards, Pam Christina P.S. The next one in the US is Oct 9-13 in Orlando
Re: connection timeout with VSE-FTP
First off, I would cross-post this to the VSE-L newsgroup. You'll probably get more eyes looking at it. Second, I just recently battled a VERY similar problem: inbound to VSE was more-or-less fine, outbound, ridiculously bad; retransmits, SWS, but it eventually got through unlike yours just timing out. Things to try: In VSE add this to your config: DYNAMIC_ROUTE OFF (default is ON) Try a SET MAX_SEGMENT=1492 (default is 32767) Also, try adding a direct route to your your FTP target. Other troubleshooting: DIAG PERF DIAG SWS DIAG STALL (DIAG -PERF to turn off) Analyze result of the DIAG's with the Installation Guide, Performance section and follow guidance.
