Re: Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape
Thanks Mike. I read you e-mail earlier but didn't have a chance to reply. You're correct. I used a spxtape to backup of nss files from 5.2 system and found that it used much more space than necessary about 13% when I loaded them the 5.2 syste. I than IPL'ld and it dropped to 3%. So its not just between releases. SPXTAPE 5.2 is bad. Your comments made me comfortable to proceed with the spxtape load. I just added an additional 3 spool volumes to the 4 I had. Hans -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Mike Hammock Sent: March 5, 2006 6:16 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape I can't help much, but may be able to 'reinforce' your experience. I was helping a customer install one of our systems and migrate their 4.4 system to it and change to 5.2. When we loaded the SPXTAPE spool files they seemed to occupy 2 to 3 times as much space as they had on the 4.4 system. We had to add a new spool volume to be able to load them all. But, when we re-IPL'ed, the 'missing space' reappeared and the correct amount of spool space/cylinders was allocated. It looks like there may be some kind of SPXTAPE problem on 5.2 Mike C. M. (Mike) Hammock Sr. Technical Support zFrame IBM zSeries Solutions (404) 643-3258 [EMAIL PROTECTED] Janice Calder [EMAIL PROTECTED] mber.ca To Sent by: VM/ESA VMESA-L@LISTSERV.UARK.EDU and z/VM cc Discussions [EMAIL PROTECTED] Subject .UARK.EDUProblem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape 03/05/2006 02:23 PM Please respond to VM/ESA and z/VM Discussions [EMAIL PROTECTED] .UARK.EDU When loading spool files using spxtape we appear to be using up a lot of spool pages that are not identified or associated with regular spool entries but are flagged as in use. VMspool identifies them as Other in the sysuse screen. I tried loading by userid only, issuing Q ALLOC SPOOL command frequently and the number of spool pages loaded was about 1/3 the number being used up. The spxtape dump on 3.1 dumped approx 11,000 files using about 800,000 pages which looks fine. The loading appears to be the problem. Problem has been report to IBM but this problem does not appear in their database. More help from them tomorrow but I like to get a work around today. Any comments or suggestions would be appreciated. Thanks Hans Rempel / Janice Calder [This E-mail scanned for viruses]
Installing Debian Linux
Hi, I was wondering if maybe someone here has experience installing Debian linux 31r1? I recently downloaded it - debian-31r1-s390-binary-1.iso - and tried to install, but the procedure fails because I don't give it the address of an ftp or http host holding the installation CD. The messages I get are: 13:14:27 Please select the file download protocol. If unsure,select http; it is less prone to problems involving firewalls. 13:14:27 Protocol for files download: 13:14:27 1. http [*] 2. ftp 13:14:27 Prompt: '?' for help, default=1 What I *did* do, was set up an nfs host, as I have done to install linux in the past, but this time that doesn't seem to work. I know the nfs is OK, because from another linux on the same subnet (which successfully pinged both the debian installer and the nfs host) I *was* able to perform the mount: linux02:~ # mount -t nfs 10.1.20.20:/cdrom temp linux02:~ # ls temp . DEBIAN DOC MD5SUM.TXT POOLREADME.TXTREADME_M.TXT _DISK .. DISTS INSTALL PICSREADME.HTM README_M.HTM TOOLS linux02:~ # But on the Debian installer I could not access the nfs. I tried dropping into a shell to set up the NFS mount: BusyBox v1.00-pre10 (Debian 20040623-1) Built-in shell (ash) Enter 'help' for a list of built-in commands. ~ # mkdir cdrom ~ # mount -t nfs 10.1.20.20:/cdrom /cdrom mount: Mounting 10.1.20.20:/cdrom on /cdrom failed: No such device ~ # And even if I did the mount, how would I get the installer to use it? I asked these questions last week on Debian-390, but that list seems a bit sleepy, and no one responded. Thank you for any help! Shimon
Re: Installing Debian Linux
On Mar 6, 2006, at 5:28 AM, Shimon Lebowitz wrote: ~ # mkdir cdrom ~ # mount -t nfs 10.1.20.20:/cdrom /cdrom mount: Mounting 10.1.20.20:/cdrom on /cdrom failed: No such device ~ # And even if I did the mount, how would I get the installer to use it? I asked these questions last week on Debian-390, but that list seems a bit sleepy, and no one responded. The S/390 Debian port, to the best of my knowledge, only does http or ftp installs, not NFS. If your machine cannot reach the outside world, you could set up a mirror of the Debian pool on an internal machine. It is our intention to produce a VM installer for Sarge as we did for Woody, which turns one of your S/390 guests into the installation server; however, this one will come on 2 DVDs instead a whole bunch of CDs. It's not ready yet--I've been very busy with other higher-priority projects--but if you'll write me offlist I can see whether a) I can just ship you a DVD copy of the installation pool and give you some help configuring a machine to serve it up, or b) I can try to help you through a regular network install if you can get to the external network from your s390. Adam
Re: Installing Debian Linux
First, thank you Adam for your quick response. Since various fluids will congeal in some strange places before our mainframe sees a public network, I will need to forgo option b. regarding a, I don't know of any dvd I can use, the only one I have access to at work in on the HMC. That leaves the original suggestion, setting up a mirror on an internal machine. When you say that I can use a s390 as an installation server, does that mean that my VM FTP server could do it?? I don't really see VM understanding that CD very well. What if I ftp up the ISO image, can that be mounted -loop by the debian starter system? Thanks, Shimon On 6 Mar 2006 at 9:11, Adam Thornton wrote: On Mar 6, 2006, at 5:28 AM, Shimon Lebowitz wrote: ~ # mkdir cdrom ~ # mount -t nfs 10.1.20.20:/cdrom /cdrom mount: Mounting 10.1.20.20:/cdrom on /cdrom failed: No such device ~ # And even if I did the mount, how would I get the installer to use it? I asked these questions last week on Debian-390, but that list seems a bit sleepy, and no one responded. The S/390 Debian port, to the best of my knowledge, only does http or ftp installs, not NFS. If your machine cannot reach the outside world, you could set up a mirror of the Debian pool on an internal machine. It is our intention to produce a VM installer for Sarge as we did for Woody, which turns one of your S/390 guests into the installation server; however, this one will come on 2 DVDs instead a whole bunch of CDs. It's not ready yet--I've been very busy with other higher-priority projects--but if you'll write me offlist I can see whether a) I can just ship you a DVD copy of the installation pool and give you some help configuring a machine to serve it up, or b) I can try to help you through a regular network install if you can get to the external network from your s390. Adam
Re: Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape
We do have a whole DASD defined in SYSTEM CONFIG as: CP_Owned Slot 5 VMDUMP DUMP that's on our: z/VM Version 5 Release 1.0, service level 0501 (64-bit) Each night after running VM:Spool to backup out SDFs and dump files, we programmatically issue: 'CP QUERY DUMP' 'CP SET DUMP OFF' 'CP SET DUMP DASD' it replied last night: DASD 0923 dump unit CP IPL pages 51805 No dump unit - Dump function is SET OFF DASD 0923 dump unit CP IPL pages 51032 So, SPXTAPE is still leaving extra SPOOL pages allocated when it ends at z/VM 5.1 (even with dedicated DUMP space), but that is easily accommodated by the set of those 3 commands. But that said, the SPXTAPE DUMP issue reported is different than the issue reported, which describes additional pages allocated when LOADing SDFs. Still, it certainly would not hurt to try the command sequence after a LOAD, as well. Hans, let us know the results of your PMR, please. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Schmiedge, Ronald [EMAIL PROTECTED] Sent by: VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU 03/06/2006 10:27 AM Please respond to V/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU To VMESA-L@LISTSERV.UARK.EDU cc Subject Re: Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape We find on our z/VM 4.4 system there are a lot of spool pages used when we do our daily spool offloads. We opened an ETR with IBM and found out that SPXTAPE is doing this, and it is working as designed. Do you have DUMP set to DASD? Do you have a SPOOL volume dedicated to DUMP? If DUMP is set to DASD, you could try this: Q DUMP Q ALLOC SPOOL Do some of your SPXTAPE loads Q DUMP again SET DUMP OFF SET DUMP DASD Q ALLOC SPOOL IBM suggested two things to us - set aside dedicated DUMP space (since SPXTAPE seems to be using the DUMP file for working storage) or set DUMP OFF and back to DASD after each SPXTAPE. Ron Schmiedge CGI Group Inc -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Hans Rempel Sent: Monday, March 06, 2006 5:26 AM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape Thanks Mike. I read you e-mail earlier but didn't have a chance to reply. You're correct. I used a spxtape to backup of nss files from 5.2 system and found that it used much more space than necessary about 13% when I loaded them the 5.2 syste. I than IPL'ld and it dropped to 3%. So its not just between releases. SPXTAPE 5.2 is bad. Your comments made me comfortable to proceed with the spxtape load. I just added an additional 3 spool volumes to the 4 I had. Hans -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Mike Hammock Sent: March 5, 2006 6:16 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape I can't help much, but may be able to 'reinforce' your experience. I was helping a customer install one of our systems and migrate their 4.4 system to it and change to 5.2. When we loaded the SPXTAPE spool files they seemed to occupy 2 to 3 times as much space as they had on the 4.4 system. We had to add a new spool volume to be able to load them all. But, when we re-IPL'ed, the 'missing space' reappeared and the correct amount of spool space/cylinders was allocated. It looks like there may be some kind of SPXTAPE problem on 5.2 Mike C. M. (Mike) Hammock Sr. Technical Support zFrame IBM zSeries Solutions (404) 643-3258 [EMAIL PROTECTED] Janice Calder [EMAIL PROTECTED] mber.ca To Sent by: VM/ESA VMESA-L@LISTSERV.UARK.EDU and z/VM cc Discussions [EMAIL PROTECTED] Subject .UARK.EDU Problem moving spool files from z/vm 3.1 to z/vm 5.2 using spxtape 03/05/2006 02:23 PM Please respond to VM/ESA and z/VM Discussions [EMAIL PROTECTED] .UARK.EDU When loading spool files using spxtape we appear to be using up a lot of spool pages that are not identified or associated with regular spool entries but are flagged as in use. VMspool identifies them as Other in the sysuse screen. I tried loading by userid only, issuing Q ALLOC SPOOL command frequently and the number of spool pages loaded was about 1/3 the number being used up. The spxtape dump on 3.1 dumped approx 11,000 files using about 800,000 pages which looks fine. The loading appears to be the problem. Problem has been report to IBM but this problem does not appear in their database. More help from them tomorrow but I like to get a work around today. Any comments or suggestions would be appreciated. Thanks Hans Rempel / Janice Calder [This E-mail scanned for viruses] The information contained in this e-mail and any accompanying documents
Re: Installing Debian Linux
There's no PC with a DVD drive anywhere on the network? There's no laptop you can attach to the network with a DVD drive? They've been pretty standard in most PCs for the last three or four years now. Read government agency, lowest bidder, etc... (and stick in 'low in the food chain') Alternativelyis there a PC running Linux that is both attached umm.. a PC running WHAT?? Sorry.. *I* have the local linux systems... an old woody (which I was replacing with sarge, I thought), and an older Suse-7. (I have erased the antique Marist distribution). I think I will skip down to: How soon do you need this? It isn't at all urgent... don't worry about it. Thanks! Shimon === to the network and able to see the mainframe? You could build the installation pool in place on it. I can give you a one-line rsync command to do that (You can probably do this under Windows just as well, but I don't know much about Windows web servers.) In which case: whatever PC you connect to your mainframe from also probably connects to the network, right? Does it have 10GB of free disk? Build the repository mirror on it, set up a Web server (this is where you fall afoul of your company's policies) and install from there. That leaves the original suggestion, setting up a mirror on an internal machine. When you say that I can use a s390 as an installation server, does that mean that my VM FTP server could do it?? I don't really see VM understanding that CD very well. Nope. But a Linux/390 image could. However, the CD isn't really helpful to you. It contains a very basic system, and not enough of a package repository to be very useful. Honestly you're just as well off getting the kernel, parmfile, and initrd from the Debian site and doing a network install. The problem is doing the initial network installation, since you don't have a machine you can see that can function as the package repository. Hence the suggestion to use a Linux-running PC: hook it up to the network. Use rsync to build a local mirror of the package repository. Turn on Apache and configure it so that it can serve the package repository. Then do a network installation on your s390 using that Linux-running PC as your package repository. Solving this problem is what our Woody CD set was meant to do, and what the Sarge DVD set, if I am given time to finish it, will do: I'll supply, in addition to a package repository, a CMSDDR image of a minimal Linux instance, which you IPL. Then you transfer the installation repository to it (ftp, scp, rsync, whatever). Then you use THAT as your installation source. How soon do you need this? I can probably come up with something that would work (I'd rather NOT do a 14-gazillion CD set, but it could be done) for you, but I basically have to do it in my spare time, which is nonexistent-and-then-some right now. What if I ftp up the ISO image, can that be mounted -loop by the debian starter system? It could be but I don't think that's going to help you any. Adam
Vswitch problem on z/VM 5.2.0?
This weekend I upgraded from z/VM 4.4.0 to 5.2.0 and ran into an unexpected problem with connectivity through vswitches to the external network. I'm trying to figure out if the problem is in my vswitch definitions or if it's a reportable issue. At the moment it appears that private IP address ranges (eg 192.168.xxx.xxx, 10.xxx.xxx.xxx, 172.16.64.xxx) which worked fine through a vswitch in 4.4.0 do not work at all through a vswitch on 5.2.0. Private IP addresses in the same subnet, on the same VLAN, on the same vswitch couldn't ping each other or their external gateway. The public I P addresses on the same vswitch had no trouble pinging their external gateway. Private IP addresses with direct OSA conections had no problems either. I was able to confirm it was a vswitch related problem through testing with my z/VM TCPIP stack. Normally it has a dedicated OSA connection and a private IP address of 172.16.64.3 on VLAN 7. On zVM 5.2 I was able to PING its external gateway at 172.16.64.1. When I changed the TCPIP stack s network connection from a dedicated OSA to a virtual NIC on the vswitch the ping failed. My vswitch was defined in z/VM 4.4.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 PORTNAME PT0500 PTF804 and in 5.2.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 VLAN 7 PORTNAME PT0500 PTF804 For testing the TCPIP NIC on the vswitch it was authorized with: SET VSWITCH SWITCH02 GRANT TCPIPVLAN 7 In both cases, PROFILE TCPIP includes: LINK ETH0 QDIOETHERNET [EMAIL PROTECTED] VLAN 7 Changing TCPIP's GRANT to include PORTTYPE TRUNK, and verifying the chang e with Q VSWITCH ALL DETAILS, had no effect. On the exact same switch, SWITCH02, other Linux guests on VLAN 2 with public IP addresses (eg 164.165.57.xxx) had no trouble communicating with the network outside the z/890. They are authorized to the vswitch with: SET VSWITCH SWITCH02 GRANT userid VLAN 2 The problem also manifested itself on the other vswitch carrying traffic on private IP addresses for other VLANs (3 and 4). Is there something I've overlooked in the changes to vswitches from 4.4.0 to 5.2.0? Or is this a reportable problem? Brian Nielsen P.S. The problem has been temporariliy circumvented by connecting the userids with priviate IP address on VLAN 7 to a guest LAN and using the zVM TCPIP stack to route their traffic to the OSA. (Yuck, but it works.)
Re: Vswitch problem on z/VM 5.2.0?
had a similar problem on 5.2. See if ptf UM31613 APAR VM63895 are on your system. It corrected our problem. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Brian Nielsen Sent: Mon 3/6/2006 3:17 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Vswitch problem on z/VM 5.2.0? This weekend I upgraded from z/VM 4.4.0 to 5.2.0 and ran into an unexpected problem with connectivity through vswitches to the external = network. I'm trying to figure out if the problem is in my vswitch definitions or if it's a reportable issue. At the moment it appears that private IP address ranges (eg 192.168.xxx.xxx, 10.xxx.xxx.xxx, 172.16.64.xxx) which worked fine through= a vswitch in 4.4.0 do not work at all through a vswitch on 5.2.0. Private IP addresses in the same subnet, on the same VLAN, on the same = vswitch couldn't ping each other or their external gateway. The public I= P addresses on the same vswitch had no trouble pinging their external gateway. Private IP addresses with direct OSA conections had no problems= either. I was able to confirm it was a vswitch related problem through testing = with my z/VM TCPIP stack. Normally it has a dedicated OSA connection and= a private IP address of 172.16.64.3 on VLAN 7. On zVM 5.2 I was able to = PING its external gateway at 172.16.64.1. When I changed the TCPIP stack= s network connection from a dedicated OSA to a virtual NIC on the vswitch = the ping failed. My vswitch was defined in z/VM 4.4.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 PORTNAME PT0500 PTF804 and in 5.2.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 VLAN 7 PORTNAME PT0500 PTF804= For testing the TCPIP NIC on the vswitch it was authorized with: SET VSWITCH SWITCH02 GRANT TCPIPVLAN 7 In both cases, PROFILE TCPIP includes: LINK ETH0 QDIOETHERNET [EMAIL PROTECTED] VLAN 7 Changing TCPIP's GRANT to include PORTTYPE TRUNK, and verifying the chang= e with Q VSWITCH ALL DETAILS, had no effect. On the exact same switch, SWITCH02, other Linux guests on VLAN 2 with public IP addresses (eg 164.165.57.xxx) had no trouble communicating with= the network outside the z/890. They are authorized to the vswitch with: SET VSWITCH SWITCH02 GRANT userid VLAN 2 The problem also manifested itself on the other vswitch carrying traffic = on private IP addresses for other VLANs (3 and 4). Is there something I've overlooked in the changes to vswitches from 4.4.0= to 5.2.0? Or is this a reportable problem? Brian Nielsen P.S. The problem has been temporariliy circumvented by connecting the userids with priviate IP address on VLAN 7 to a guest LAN and using the = zVM TCPIP stack to route their traffic to the OSA. (Yuck, but it works.)=
Re: Vswitch problem on z/VM 5.2.0?
I think the problem is your VLAN ID on the DEFINE VSWITCH. That value needs to match the management VLAN ID for the switch to which your OSA is connected. The normal default is 1. Your installation may have changed the value. You will need to talk to the group that configures your switch hardware. 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/06/2006 03:17:23 PM: VMESA-L@LISTSERV.UARK.EDU This weekend I upgraded from z/VM 4.4.0 to 5.2.0 and ran into an unexpected problem with connectivity through vswitches to the external network. I'm trying to figure out if the problem is in my vswitch definitions or if it's a reportable issue. At the moment it appears that private IP address ranges (eg 192.168.xxx.xxx, 10.xxx.xxx.xxx, 172.16.64.xxx) which worked fine through a vswitch in 4.4.0 do not work at all through a vswitch on 5.2.0. Private IP addresses in the same subnet, on the same VLAN, on the same vswitch couldn't ping each other or their external gateway. The public IP addresses on the same vswitch had no trouble pinging their external gateway. Private IP addresses with direct OSA conections had no problems either. I was able to confirm it was a vswitch related problem through testing with my z/VM TCPIP stack. Normally it has a dedicated OSA connection and a private IP address of 172.16.64.3 on VLAN 7. On zVM 5.2 I was able to PING its external gateway at 172.16.64.1. When I changed the TCPIP stacks network connection from a dedicated OSA to a virtual NIC on the vswitch the ping failed. My vswitch was defined in z/VM 4.4.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 PORTNAME PT0500 PTF804 and in 5.2.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 VLAN 7 PORTNAME PT0500 PTF804 For testing the TCPIP NIC on the vswitch it was authorized with: SET VSWITCH SWITCH02 GRANT TCPIPVLAN 7 In both cases, PROFILE TCPIP includes: LINK ETH0 QDIOETHERNET [EMAIL PROTECTED] VLAN 7 Changing TCPIP's GRANT to include PORTTYPE TRUNK, and verifying the change with Q VSWITCH ALL DETAILS, had no effect. On the exact same switch, SWITCH02, other Linux guests on VLAN 2 with public IP addresses (eg 164.165.57.xxx) had no trouble communicating with the network outside the z/890. They are authorized to the vswitch with: SET VSWITCH SWITCH02 GRANT userid VLAN 2 The problem also manifested itself on the other vswitch carrying traffic on private IP addresses for other VLANs (3 and 4). Is there something I've overlooked in the changes to vswitches from 4.4.0 to 5.2.0? Or is this a reportable problem? Brian Nielsen P.S. The problem has been temporariliy circumvented by connecting the userids with priviate IP address on VLAN 7 to a guest LAN and using the zVM TCPIP stack to route their traffic to the OSA. (Yuck, but it works.)
Re: ZVM 5.2, Z890, and I/O
without any other workload analysis: 6g central 2g xstore. on a z/9 we have not experienced or noticed 2g i/o issues. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Hughes, Jim - OIT Sent: Mon 3/6/2006 4:23 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: ZVM 5.2, Z890, and I/O Is there a problem with ZVM 5.2 and a Z890 when doing I/O over the 2 gig line? We are probably getting a Z890 with 8 gig of main storage. Any suggestions for carving up the main storage(xstore, cache, etc.) ___ Jim Hughes 603-271-5586 Impossible is just an opinion.
Re: ZVM 5.2, Z890, and I/O
First, you don't have 8 GB. You will loose at least 768 MB for microcode etc. Second, how many LPARs? Third, in each LPAR, you need to determine what operating system you will run. Fourth, if you are running VM, how much central and how much xstore you need. Fifth, bug management on buying another 8 GB (rumor has it that storage is running about half price now a days). The Z8, replacement for the Z890, may have 16 GB increments. (Is it April yet?) Tom Duerbusch THD Consulting [EMAIL PROTECTED] 3/6/2006 3:23 PM Is there a problem with ZVM 5.2 and a Z890 when doing I/O over the 2 gig line? We are probably getting a Z890 with 8 gig of main storage. Any suggestions for carving up the main storage(xstore, cache, etc.) ___ Jim Hughes 603-271-5586 Impossible is just an opinion.
Debian S390 Etch
Adam Thornton, I noticed you were talking about installing Sarge and Woody but you didn't mention Etch. Have you or anyone else done a network install of Etch? I am looking for a good set of directions on that. Thank you, -- 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: Vswitch problem on z/VM 5.2.0?
On Monday, 03/06/2006 at 02:51 CST, Brian Nielsen [EMAIL PROTECTED] wrote: It is my understanding from the manuals that the VLAN ID on the DEFINE VSWITCH only sets up the default VLAN ID to be used by guests that do not include a VLAN ID on the SET VSWITCH GRANT command. All of the guests GRANTed access to the vswitch include the VLAN parameter for their specific VLAN ID. The external gateway (a CISCO 6509) is expecting (and restricting) communications with the z/890 on VLANs 2, 7, 3, and 4. 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. Do not use DEFINE VSWITCH VLAN xx to avoid SET VSWITCH GRANT VLANs. In the future we will separate the native VLAN ID from the default authorization VLAN id. Only another switch (real or virtual) should be given access to the native VLAN id. This is the VLAN used by switches to talk to each other. 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 TCPIP. So, DEFINE VSWITCH ... VLAN 1 (if the 6509's native VLAN ID hasn't been changed). Grant TCPIP access to VLAN 7 with a virtual *access* port. Alan Altmark z/VM Development IBM Endicott
