Re: VM64152 Re: Performance Toolkit
Kurt Acker wrote: Greetings Perfkit users and ListServ followers, PERF440 PACKMOD has been placed back on the FTP with the other mods. For our records, we would still like customers to open PMR's at all release levels. Please also note that the r440 version will not become an official part of APAR VM64152 due to its end of service classification. We plan to make this a local mod, that will most likely be downloaded from: http://www.vm.ibm.com/related/perfkit/ We will of course add an official follow up post once that has taken place. I probably read some notes out of chronological order, but is this still the plan, to post unsupported local mods for V4R4 customers on the web page for the product? Thanks and Best Regards, Kurt Acker Thanks, Nick
Re: Extracting MACLIB members
Try MOVEFILE. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tony Thigpen Sent: Wednesday, January 17, 2007 8:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Extracting MACLIB members I don't work with maclibs very much. I have a maclib full of members that I want to extract to individual members on a cms disk. I can't seem to find the right command. For one or two, I usually just do a maclist and xedit the members to save them but in this case, I need to extract about 100. If it makes any difference, my reason for moving them is so I can ftp them to a non-vm system. If something in the FTP server allows access to maclib members, that would be better. -- Tony Thigpen If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Extracting MACLIB members
Use the member option of XEDIT and then file it away. Tony Thigpen [EMAIL PROTECTED] To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Extracting MACLIB members 01/17/2007 08:32 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I don't work with maclibs very much. I have a maclib full of members that I want to extract to individual members on a cms disk. I can't seem to find the right command. For one or two, I usually just do a maclist and xedit the members to save them but in this case, I need to extract about 100. If it makes any difference, my reason for moving them is so I can ftp them to a non-vm system. If something in the FTP server allows access to maclib members, that would be better. -- Tony Thigpen
Re: Extracting MACLIB members
that worked. thanks. Tony Thigpen -Original Message - From: Stracka, James (GTI) Sent: 01/17/2007 08:43 AM Try MOVEFILE. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tony Thigpen Sent: Wednesday, January 17, 2007 8:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Extracting MACLIB members I don't work with maclibs very much. I have a maclib full of members that I want to extract to individual members on a cms disk. I can't seem to find the right command. For one or two, I usually just do a maclist and xedit the members to save them but in this case, I need to extract about 100. If it makes any difference, my reason for moving them is so I can ftp them to a non-vm system. If something in the FTP server allows access to maclib members, that would be better.
Re: Extracting MACLIB members
You can also use: PIPE MEMBERS fn ft fm member member a -- Original message -- From: Tony Thigpen [EMAIL PROTECTED] I don't work with maclibs very much. I have a maclib full of members that I want to extract to individual members on a cms disk. I can't seem to find the right command. For one or two, I usually just do a maclist and xedit the members to save them but in this case, I need to extract about 100. If it makes any difference, my reason for moving them is so I can ftp them to a non-vm system. If something in the FTP server allows access to maclib members, that would be better. -- Tony Thigpen
Extracting MACLIB members
I don't work with maclibs very much. I have a maclib full of members that I want to extract to individual members on a cms disk. I can't seem to find the right command. For one or two, I usually just do a maclist and xedit the members to save them but in this case, I need to extract about 100. If it makes any difference, my reason for moving them is so I can ftp them to a non-vm system. If something in the FTP server allows access to maclib members, that would be better. -- Tony Thigpen
Re: z/VM 5.2 conversion IP problem
I'm still having problems after last nights tests... Where Miguel says you don't have to have a HOST entry, when I leave it out, I don't get connected. When I put one in, I do get connected (but routing is still off). I'm now using the IUCV connection to a SLES9 31 bit with SP 1 machine that was working when we were under z/VM 5.1. For now, I'm setting the VSE/ESA 2.3 machines aside as it is all unsupported code and there might be some outstanding PTFs that now come into play. (Of course that could also be true with only SP 1 being applied on the Linux side.) So with the following HOME statements: HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 HOST ; HOST PRODUCES: DTCPAR123I LINE 211: UNKNOWN LINK NAME IN HOME CMD 192.168.099.227 255.255.255.000 LLINUX27 ; 192.168.099.227 255.255.255.252 LLINUX27 ; 192.168.099.227 255.255.255.000 LLINUX27 ; 192.168.099.227 255.255.255.240 LLINUX27 Any one that has a mask specified, connects. When I ftp from DOS to Linux27, I get the VM banner. IFCONFIG shows the device is up. When I ftp from Linux27 to VM, IFCONFIG shows that it received packets, but shows 0 transmitted for that device. It seems to me that I can send packets to VM over the IUCV connection, but IP isn't routing them back out. On the GATEWAY side, I tried: GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - ; 205.235.227 255.255.255.0 = QDIO11500 ; 192.168.099.024 255.255.255.0 = LNEWESA4 1500 ; 192.168.099.000 255.255.255.240 = LY2KESA2 1500 192.168.099.227 HOST= LLINUX27 9216 ; 192.168.099.227 255.255.255.000 = LLINUX27 9216 ; 192.168.099.227 255.255.255.252 = LLINUX27 9216 ; 192.168.099.227 255.255.255.000 = LLINUX27 9216 ; 192.168.099.227 255.255.255.252 = LLINUX27 9216 ; 192.168.099.227 255.255.255.255 = LLINUX27 9216 ; 192.168.099.000 255.255.255.255 = LLINUX27 9216 ; 192.168.099.000 255.255.255.000 = LLINUX27 9216 ; 192.168.099.000 255.255.255.000 = LLINUX27 1500 ; 192.168.099.227 255.255.255.000 = LLINUX27 1500 First I commented out all other links. Just deal with one. For LLINUX27, the oldest statement is at the bottom. 1st tried the IP address. Then tried it as a subnet address. Then changed the MTU to match what IFCONFIG said from the Linux side. Nothing provided routing back to the Linux machine. I left it at the statement that is simular to what was used in the z/VM 5.1 side, which was: 192.168.099.227 = LLINUX27 1500 HOST Just in case, I'm attaching the entire configuration file. Perhaps I'm looking only at the HOST and GATEWAY statements, and I really have a problem somewhere else (between the ears). Thanks for any insight. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/16/2007 9:00 AM On Tuesday, 01/16/2007 at 08:22 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: OK, so I took out the statements in the HOME area. When I did that, VSE (via VCTCA, or the sole Linux image that is still using IUCV) wouldn't connect anymore. Sorry for not being clearer: - You must have a HOME entry for each interface - You may not duplicate any IP address in the HOME list. Each must be unique. - You should put each VM--VSE connection in its own .252 subnet. To the extent you are using host routes - You must have a HOST entry in the GATEWAY for each p2p peer. (Hmmm...Miguel: Do you still have to do that if you use a .252 subnet?) Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
I believe Alan brought this up yesterday, but I'll mention it again...the IP address on you VM system (in your HOME statement) *MUST* be different from the IP address on your linux system (i.e. the IP address on the HOST GATEWAY route): HOME 192.168.099.227 255.255.255.000 LLINUX27 GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 192.168.099.227 HOST= LLINUX27 9216 Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
It is different. But we might be talking about different things: HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 HOST ; HOST PRODUCES: DTCPAR123I LINE 211: UNKNOWN LINK NAME IN HOME CMD 192.168.099.227 255.255.255.000 LLINUX27 The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. So, I'm confused. What isn't different about them? Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/17/2007 11:53 AM I believe Alan brought this up yesterday, but I'll mention it again...the IP address on you VM system (in your HOME statement) *MUST* be different from the IP address on your linux system (i.e. the IP address on the HOST GATEWAY route): HOME 192.168.099.227 255.255.255.000 LLINUX27 GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 192.168.099.227 HOST= LLINUX27 9216 Regards, Miguel Delapaz z/VM TCP/IP Development
Re: VM64152 Re: Performance Toolkit
Folks, R440 is OUT OF SERVICE, and if you want extended service for R44 0 then let us know and we can get someone to contact you. Thie particular PERFKIT R440 fix is something we discussed quite a bit 'in-house' and thought it was the 'right thing' to make this availabl e to our Perfkit R440 customers, as they are migrating to R5x0. We *will not* be continueing this, meaning making COR available for the R440 of Perfkit, as R440 is 'out of service'. This is a 1 time thing tha t we felt we should fix, since we do have alot of you folks still running R440 while migrating to R510/R520, and without this fix your Perfkit coul d very well be dead in the water. We would really like to know about you R440 customers out there, which is the reason Kurt asked to be notified when you get the Perfkit R440 fix. I expect these fixes to TIMEOUT from our WEBSITE in the near future, at which time the PTF should be available. However, the R440 will probably be made available as an 'unsupported local mod/circ' for this, off of the PERFKIT WEB page only, at www.vm.ibm.com/related/perfkit (which I am sur e all you PERFKIT users have marked!). We will provide updates when this takes place. Of course, any concerns please call into the support center! Thanks for working with us on this one. Best Regards, Roger Lunsford (IBM PERFKIT Level2/Level3)
Re: z/VM 5.2 conversion IP problem
You see the HOME statement. You see the 192.168.099.227 in the HOME statement. That must not be the same as the address of the Linux system. It is the same. I must be different. Two people have told you this. Maybe, if three do you will believe it. [EMAIL PROTECTED] wrote: It is different. But we might be talking about different things: HOME 205.235.227.74 255.255.255.000 QDIO1 192.168.099.227 255.255.255.000 LLINUX27 The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. So, I'm confused. What isn't different about them? Tom Duerbusch THD Consulting -- 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: z/VM 5.2 conversion IP problem
On Wednesday, 01/17/2007 at 11:32 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: I'm still having problems after last nights tests... Where Miguel says you don't have to have a HOST entry, when I leave it out, I don't get connected. When I put one in, I do get connected (but routing is still off). I'm now using the IUCV connection to a SLES9 31 bit with SP 1 machine that was working when we were under z/VM 5.1. For now, I'm setting the VSE/ESA 2.3 machines aside as it is all unsupported code and there might be some outstanding PTFs that now come into play. (Of course that could also be true with only SP 1 being applied on the Linux side.) So with the following HOME statements: HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 HOST ; HOST PRODUCES: DTCPAR123I LINE 211: UNKNOWN LINK NAME IN HOME CMD You can't put HOST in the HOME statement. Just subnet masks. If you get errors in your PROFILE, it's hard to tell what worked and what didn't. You gotta have a clean startup. 192.168.099.227 255.255.255.000 LLINUX27 As I said previously, you put only VM IP addresses in the HOME list, not other hosts' IP addresses. What is VM's IP address w.r.t. LLINUX27? You MUST choose a unique IP address for the VM TCP/IP end of EVERY p2p connection, whether it's CTC or IUCV. You need to define a subnet that contains both VM and LLINUX27. This is why the choice of subnet mask 255.255.255.252 -- it defines a subnet with exactly two (and only two) hosts in it. Unfortunately, a /30 subnet can't have .227 as a host address because it's the broadcast address for the the .224/30 subnet (only .225 and .226 can be assigned). Now, if you broaden the mask to /29 (255.255.255.248), then you can have them both in the same subnet. GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 192.168.099.227 HOST= LLINUX27 9216 That entry looks good, AFTER you create a subnet mask that allows it and the matching HOME IP address to coexist in the same subnet. The presence of the HOST route will enable you to use that /29 to cover multiple p2p pairs. The .224 network will be located behind VM TCP/IP in all cases, but the host routes will tell the stack which interface to use. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
Hi Ed, not a problem. I might be intelligent in some areas, but I'm hitting a brick wall with a dense head, here G. I wish I was hung over or something in order to have a valid excuse on this one. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/17/2007 1:17 PM Two people have told you this. Maybe, if three do you will believe it. Wow Stephen, are you having a bad day or what? Cut Tom some slack here. He is an intelligent guy who is having a problem. Just because YOU get what he needs to change doesn't mean he does. Haven't you ever had difficulty understanding something? I'm surprised you would be so negative, that doesn't seem like you. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: VM64152 Re: Performance Toolkit
Even though I do not run R440, I applaude your efforts in releasing this PERFKIT fix. Having such a useful component of my system dead in the wat er during a migration would leave a very bad feeling towards the vendor. Congradulations on doing the right thing. /Tom Kern On Wed, 17 Jan 2007 10:10:13 -0600, Roger Lunsford wrote: Folks, R440 is OUT OF SERVICE, and if you want extended service for R4 40 then let us know and we can get someone to contact you. Thie particular PERFKIT R440 fix is something we discussed quite a bit 'in-house' and thought it was the 'right thing' to make this availab le to our Perfkit R440 customers, as they are migrating to R5x0. We *will not* be continueing this, meaning making COR available for the R440 of Perfkit, as R440 is 'out of service'. This is a 1 time thing th at we felt we should fix, since we do have alot of you folks still running R440 while migrating to R510/R520, and without this fix your Perfkit cou ld very well be dead in the water. We would really like to know about you R440 customers out there, which is the reason Kurt asked to be notified when you get the Perfkit R440 fix. I expect these fixes to TIMEOUT from our WEBSITE in the near future, at which time the PTF should be available. However, the R440 will probably be made available as an 'unsupported local mod/circ' for this, off of th e PERFKIT WEB page only, at www.vm.ibm.com/related/perfkit (which I am su re all you PERFKIT users have marked!). We will provide updates when this takes place. Of course, any concerns please call into the support center! Thanks for working with us on this one. Best Regards, Roger Lunsford (IBM PERFKIT Level2/Level3) = ===
Re: z/VM 5.2 conversion IP problem
Hi Stephen Since VM/ESA 370 mode, I don't think I ever had HOME statements for anything other than my VM system. That includes last week when we were on z/VM 5.1. Now, I think I'm being told that I need a HOME statement for each link statement. And now told that these few dozen HOME statements, all need IP addresses that don't duplication any of my HOSTs. So I'm really being dense here How, or what matches up the IP address in the HOME entry to the IP address used by the HOST? And if there is nothing that matches the two together, why have the entry in the HOST section to begin with? It's really going to be a eureka moment, if and when I understand this. G Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/17/2007 12:42 PM You see the HOME statement. You see the 192.168.099.227 in the HOME statement. That must not be the same as the address of the Linux system. It is the same. I must be different. Two people have told you this. Maybe, if three do you will believe it. [EMAIL PROTECTED] wrote: It is different. But we might be talking about different things: HOME 205.235.227.74 255.255.255.000 QDIO1 192.168.099.227 255.255.255.000 LLINUX27 The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. So, I'm confused. What isn't different about them? Tom Duerbusch THD Consulting -- 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: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 1:58 PM, Tom Duerbusch wrote: I wish I was hung over or something in order to have a valid excuse on this one. Could be arranged. For tomorrow, anyway. Come on over. I'm expecting to knock off work about five today. Adam
Re: z/VM 5.2 conversion IP problem
I wish I was hung over or something in order to have a valid excuse on this one. Could be arranged. For tomorrow, anyway. Come on over. I'm expecting to knock off work about five today. Can I come too please? Maybe I can learn to tone down my reaction to listserv posts. Sorry I jumped all over you in public Stephen. That was intended to be a private email, but of course I sent it to the entire list. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: z/VM 5.2 conversion IP problem
On Wednesday, 01/17/2007 at 02:10 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: Since VM/ESA 370 mode, I don't think I ever had HOME statements for anything other than my VM system. That includes last week when we were on z/VM 5.1. Now, I think I'm being told that I need a HOME statement for each link statement. And now told that these few dozen HOME statements, all need IP addresses that don't duplication any of my HOSTs. So I'm really being dense here How, or what matches up the IP address in the HOME entry to the IP address used by the HOST? And if there is nothing that matches the two together, why have the entry in the HOST section to begin with? Just so you don't think you're going crazy, z/VM 5.2 tightened up the rules for the PROFILE. The rules have always been there, but the stack was forgiving and it worked in spite of itself. - HOME identifies all of *your* IP addresses. - GATEWAY HOST entries identify all of your p2p *peers* You know the old saying, One man's HOME is another man's HOST. Kinda like cross-coupling CTC pairs. OK, not really like it at all, but there is a ... symmetry ... in the configuration of p2p links. Your HOME address on the CTC or IUCV link will be configured as the peer IP address on the other host. Likewise, your HOST entry will be in the local interface configuration of the peer. As you've discovered in spades, getting those guests to a level that can use Guest LAN or VSWITCH is, like, a bazillion times better than hacking up (as you would a furball) a bunch of p2p configs. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
Hi Allen I'm starting to see where you are coming from with this. Obviously, historically, there have been multiple ways of coding these entries. And I have been able to get away with my way for a couple decades (not bad, huh?) But it may be time to pay the piper on this one. It didn't last quite long enough. As within 18 months, the VM stack won't have any routing functions as everything would have (or should have been) converted to vswitch. Vswitch seems to be a much cleaner/easier solution. Good stuff. So, in the latest post towards Miguel: 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? 2. The IP statement on the HOME statement: a. Cannot duplicate any other IP address in the network b. Must be in the same subnet as the IP address for the host (Linux27) c. Each link, will have its own subnet which contains the IP address of the link and the IP address of the host. d. I can't have sequential IP addresses (incremented by 1) for my Linux hosts. e. The subnet address associates the IP address on the link with the IP address for the guest. 3. My GATEWAY statement seems to be correct On a tangent, vswitch. I am using sequential IP addresses for my Linux machines on the vswitch. And they are working, even under z/VM 5.2. Am I going to be facing future problems here. Would it be advisable to start using addresses on different .252 subnets? I do believe that vswitch is a switch and the VM stack was a router and they may be more dis-similar than similar. But in the areas where they are similar On a side note for those people that wrote the TCP/IP Planning and Customization manual. All the references and examples are big shop environments. Multiple real adapters (TR1, ETH1, FDDI1, SNA1, etc). Not really much for guest machines running under VM (CTCA, IUCV). True an adapter (real or virtual) is an adapter. And now the manual may be written more for real adapters as vswitch replaces CTCA and IUCV. Anyway, assuming the above interpretation of what you said is correct, it is time to dig thru the manual to see what I didn't read over and see what else I didn't read G. Thanks Tom Duerbusch THD Consulting
Re: z/VM 5.2 conversion IP problem
Perhaps now would be a good time for IBM to release a tutorial for the pre-5.2 - 5.2+ migrations. Lots of real-life examples and examples of migration from oldder network architectures to the new GuestLans/Vswitch architectures and then onto the VLAN stuff. Please remember that most of the VM audience now are NOT TCPIP GURUs. Explanations, pictures and lots of r eal examples will help pass your knowledge onto us. /Tom Kern On Wed, 17 Jan 2007 15:58:00 -0500, Alan Altmark wrote: ...snipped... Just so you don't think you're going crazy, z/VM 5.2 tightened up the rules for the PROFILE. The rules have always been there, but the stack was forgiving and it worked in spite of itself. - HOME identifies all of *your* IP addresses. - GATEWAY HOST entries identify all of your p2p *peers* You know the old saying, One man's HOME is another man's HOST. Kinda like cross-coupling CTC pairs. OK, not really like it at all, but there is a ... symmetry ... in the configuration of p2p links. Your HOME address on the CTC or IUCV link will be configured as the peer IP address on the other host. Likewise, your HOST entry will be in the loc al interface configuration of the peer. As you've discovered in spades, getting those guests to a level that can use Guest LAN or VSWITCH is, like, a bazillion times better than hacking up (as you would a furball) a bunch of p2p configs.
Re: z/VM 5.2 conversion IP problem
Quoting Tom Duerbusch [EMAIL PROTECTED]: Hi Stephen Since VM/ESA 370 mode, I don't think I ever had HOME statements for anything other than my VM system. That includes last week when we were on z/VM 5.1. Now, I think I'm being told that I need a HOME statement for each link statement. And now told that these few dozen HOME statements, all need IP addresses that don't duplication any of my HOSTs. So I'm really being dense here How, or what matches up the IP address in the HOME entry to the IP address used by the HOST? And if there is nothing that matches the two together, why have the entry in the HOST section to begin with? It's really going to be a eureka moment, if and when I understand this. G Tom Duerbusch THD Consulting I hope I can say it in a way that will look clearer. Assume a network that looks like this: linuxvmvse The VM is actually on two different nets, the one connecting it to linux, and the one connecting it to VSE. Inside VM's TCPIP it needs to know what is MY name for every network VM talks on. So in this case VM will need, in its HOME section, two different addresses. You said: The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. But actually, VM *must* have TWO IP addresses here, one on the 205.235.227. net and one on the 192.168.99. net. AFAIK, there ain't no way a host calling itself 192... will talk to another one calling itself 205... over one wire unless you have a router in between. so let's say VM is 205.235.227.74 *and* 192.168.99.240. HOME 205.235.227.74 VSENIC 192.168.099.240 LNXNIC (That HOME is not your adapter names, but I hope you understand the basic idea: one IP address for THIS computer - VM - on EACH network). Then we need to tell TCPIP where to find various outside systems. So, we tell it the IP address and mask of the network with the linux, and also the IP address/mask of the network with VSE. GATEWAY 205.235.227.120 255.255.255.0 = VSESYS 192.168.099.227 255.255.255.0 = LNXSYS (Making up a different IP for VSE). That way when it wants to communicate with VSE it knows what network adapter to use and how to identify itself, by finding the HOME line that meets the IP/mask criteria of VSE's network. Same for the linux... I probably didn't say this exactly according to Alan's definitions of things, but it is how I understand stuff. HTH, Shimon
Re: z/VM 5.2 conversion IP problem
Of course this throws things off even more as on the z/VM 5.1 system, I only had the single HOME entry (for 205.235.227.74) and I had (working correctly) about 3 dozen other interfaces. Attached is the old config file for z/VM 5.1. I agree that I may have gotten away with things that now, the newer code won't let me. And that may be a great part of my confusion. Looking at the config file, and the IFCONFIG output you've added, I see what you're trying to do. If this *exact* same configuration worked on z/VM 5.1, I'm not sure that we've *explicitly* changed anything to prevent it from working now. That's not to say we haven't made changes that cause it not to work because we very well may have. Note that you're really running (or trying to run) with an invalid configuration, and this is why it's important to have pictures of the network and a decent understanding of what all of the information on your network picture corresponds to. Below, I'll draw a basic diagram of what I understand your network to look like based on what you've told us and explain why your configuration doesn't make sense. -- | Linux | | Guest | -- o - Linux Guest's IUCV interface (IP address: 192.168.99.227) | | | | | o - VM System's IUCV interface (IP address: ???) -- | VM| | System | -- o - VM System's QDIO interface (IP address: 205.235.227.74) | | | | --- | Outside Network| --- So...based on this picture, 192.168.99.227 has no *real* direct connection to 205.235.227.74. It may be possible (depending on how strict the IP stack's implementation is) to trick this configuration into working. But relying on such a trick to continue working in the future is probably not a great idea. The only way to truly ensure connectivity is to assign an IP address to the VM System's IUCV interface(s). 1. Do I need a HOME statement for each interface? It seems that on z/VM 5.2, if I don't have one, I can't connect to the adjecent host. To really be a *valid* configuration, yes you do. 2. If I need a HOME statement for each interface, can the IP address for that interface be any unused IP address? One that is on the same class C network (such as 192.168.99.1xx for the 2xx hosts)? Or do I need to spread out the HOST addresses out so that a .252 subnet can address a unique network along with a single unique host (that is, instead of consequitive IP addresses for hosts, every 4th IP address)? It depends. If you're running a dynamic router (MPRoute) on VM, you're most likely going to have to resort to the .252 subnets (a good reason to think about ditching the point to point links and start implementing guest LANs). If you're not running a dynamic router, you can go with a less drastic trick and, like you said, use 192.168.99.1xx IP address on your VM system. If you do this, you should probably NOT put a subnet mask on the HOME statement for the IUCV links. Since they aren't really on the same subnet (physically), you don't want a subnet route for them. Simply add the appropriate HOST routes to your GATEWAY statement. 3. Then on the GATEWAY side. What I got use to (or got away with) on z/VM 5.1, was the first parm being the IP address of the HOST I was going to. The manual says that this isn't an IP address, but rather as subnet address. Getting those confused is part of my mistake. But it worked. Why? Is this a case of the code being tighten? However, as I now reread the manual, the first parm is the IP address of the host that is on the destination network and HOST is used to specify a host entry. So I would seem that my GATEWAY entry: 192.168.099.227 HOST= LLINUX27 9216 is correct. Yes, this is correct. If you read further in the description of the first operand the doc says: Alternatively, ipv4_dest can be specified as the IP address, in dotted-decimal form, of any host that is on the destination network. Which is really what applies in this case. Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
Tom, See the attached PDF diagram -- it might help you to understand the overall approach. All the white circles in the diagram need to have unique IP addresses, and the ones on the ends of the CTC/IUCV links need addresses in the same subnet. 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? All the interfaces defined ON THE VM STACK need a HOME interface.
Re: z/VM 5.2 conversion IP problem
My other post goes into more detail on the answers to these...but I'll reiterate here 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? Essentially, yes. 2. The IP statement on the HOME statement: a. Cannot duplicate any other IP address in the network True b. Must be in the same subnet as the IP address for the host (Linux27) True c. Each link, will have its own subnet which contains the IP address of the link and the IP address of the host. True if you're running a dynamic router...otherwise, not necessarily d. I can't have sequential IP addresses (incremented by 1) for my Linux hosts. True if you're running a dynamic router...otherwise, not necessarily e. The subnet address associates the IP address on the link with the IP address for the guest. True 3. My GATEWAY statement seems to be correct Yes Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 2:58 PM, Tom Duerbusch wrote: So, in the latest post towards Miguel: 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? If you have VCTCs hanging off each of them, yes. 2. The IP statement on the HOME statement: a. Cannot duplicate any other IP address in the network True. b. Must be in the same subnet as the IP address for the host (Linux27) Well, presuming that Linux27 is only *one* of those links. And using host here is confusing. Anything with an IP stack is a host. The IP address of the VM side of the point-to-point link is in the same /30 subnet as the other side of the point-to-point link. c. Each link, will have its own subnet which contains the IP address of the link and the IP address of the host. Yes. Each netmask will be 255.255.255.252. In a /30 network (i.e., that netmask) there are four addresses. The bottom one is the network address. The top one is the broadcast address. That leaves two real addresses, one for each end of the link. d. I can't have sequential IP addresses (incremented by 1) for my Linux hosts. Not if they're on different CTCs, because that will violate subnetting. But if you have Linux hosts then why are you screwing around with VCTC at all? Just put them on a VSWITCH or Guest LAN segment and let them use (virtual) Ethernet adapters as God intended, and then you can have a nice roomy /24 (or whatever) subnet and not have to worry about it. Put them up against each other if you like. e. The subnet address associates the IP address on the link with the IP address for the guest. sort of. The VM and Other sides of the link have to be in the same /30 subnet. 3. My GATEWAY statement seems to be correct I didn't see anything wrong here. On a tangent, vswitch. I am using sequential IP addresses for my Linux machines on the vswitch. And they are working, even under z/VM 5.2. Am I going to be facing future problems here. Would it be advisable to start using addresses on different .252 subnets? I do believe that vswitch is a switch and the VM stack was a router and they may be more dis-similar than similar. But in the areas where they are similar No. Your Linux guests on a virtual LAN segment can have adjacent addresses and behave just like Linux machines on any other network anywhere in the real world. You want to get away from crazy subnetting by doing away with VCTC and IUCV connections in so far as possible. Adam
Re: z/VM 5.2 conversion IP problem
On Wednesday, 01/17/2007 at 03:11 CST, Thomas Kern [EMAIL PROTECTED] wrote: Perhaps now would be a good time for IBM to release a tutorial for the pre-5.2 - 5.2+ migrations. Lots of real-life examples and examples of migration from oldder network architectures to the new GuestLans/Vswitch architectures and then onto the VLAN stuff. Please remember that most of the VM audience now are NOT TCPIP GURUs. Explanations, pictures and lots of real examples will help pass your knowledge onto us. The VM sysprog is not expected to be an IP guru. S/he is, however, expected to consult with one when appropriate, as you have been doing here. (We just aren't getting our cut of your fee! :-) ) As I've said on many occasions, IBM manuals are, first and foremost, descriptions of how to configure or manage the product. They are not intended to be primers or treatises on the underlying technology. People go to school to become network engineers or architects. You or someone you have access to are expected to have an understanding of IP addressing and subnetting. Lack of knowledge can lead you down the Path of Darkness, where technicians-with-wirecutters reside and designers-with-attitude rule. It's easy once you know how! Collections of real-world network pictures and their matching configs would be an excellent candidate for the Wiki. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
Collections of real-world network pictures and their matching configs would be an excellent candidate for the Wiki. Where is this Wiki???
Re: z/VM 5.2 conversion IP problem
See the attached PDF diagram -- it might help you to understand the overall approach. All the white circles in the diagram need to have unique IP addresses, and the ones on the ends of the CTC/IUCV links need addresses in the same subnet. Blech. The attachment got stripped by the mailing list software. Find it here at: http://www.sinenomine.net/node/571
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 4:10 PM, Tom Duerbusch wrote: Hi Adam That might be doable Thursday. I have an AA meeting tonight...just kidding. Got a favorite watering hole in mind? My living room was what I had in mind...I rarely go out to drink: see the first panel of http://www.fsf.net/~adam/Brown_and_White/ for why. But, failing that, maybe Schlafly Bottleworks in Maplewood? Or there's a bar on the bottom floor of the Dorchester on Skinker just south of Wash. U. that seemed like a pleasant, quiet, not totally smoky place. Amy can remember its name when she gets in. It has Thursday night fried chicken specials that are supposed to be excellent, although I went last week and found it pretty mediocre. Maybe it was an off week. Adam
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 4:10 PM, Tom Duerbusch wrote: Hi Adam That might be doable Thursday. I have an AA meeting tonight...just kidding. Got a favorite watering hole in mind? John's Town Hall is the place I was thinking of with the fried chicken. Adam
Re: z/VM 5.2 conversion IP problem
You mean people actually get paid for this? To be more realistic, I have been able to configure two OSA driven VSWITCHes for separate inside/outside linux servers and to do cross-LPAR communications via a hipersocket, but it is still rather simplistic compared to a raft of point-to-point connections with lots of different subnets. A basic picture with sample IP addresses on each end of a connection followed by a corresponding configuration file explaining all of the required fields would go a long way to solving these problems. So, I reiterate your (and DB's) recommendation to post a network diagram when asking for help with a configuration problem. /Tom Kern --- Alan Altmark [EMAIL PROTECTED] wrote: The VM sysprog is not expected to be an IP guru. S/he is, however, expected to consult with one when appropriate, as you have been doing here. (We just aren't getting our cut of your fee! :-) ) As I've said on many occasions, IBM manuals are, first and foremost, descriptions of how to configure or manage the product. They are not intended to be primers or treatises on the underlying technology. People go to school to become network engineers or architects. You or someone you have access to are expected to have an understanding of IP addressing and subnetting. Lack of knowledge can lead you down the Path of Darkness, where technicians-with-wirecutters reside and designers-with-attitude rule. It's easy once you know how! Collections of real-world network pictures and their matching configs would be an excellent candidate for the Wiki. Alan Altmark z/VM Development IBM Endicott Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
