OK - I see where you could have gone awry. Unless the limit has changed: you may have 4 CHPIDs type IQD for hipersockets. You can still have up to 1024 usable hipersockets. If CHPID FE is IQD and CHPID FD is IQD and both have usable hipersockets you CANNOT directly connect devices on FE to FD. You can of course route them via a TCPIP stack. You can directly connect devices within a CHPID type IQD. For example FEF0 - FEF2 on one lpar can directly connect to FEA0-FEA2 on the other LPAR. Still not certain of your network configuration but if you wanted to have 2 hipersockets per guest and you can negotiate getting up to 4 CHPIDs you can achieve these maximums.
________________________________ From: Linux on 390 Port on behalf of Seader, Cameron Sent: Thu 12/2/2004 10:36 AM To: [EMAIL PROTECTED] Subject: Re: 127 device limitation for hipersockets Yeah somewhere our IODF is messed up i think, and we need to take a look at it. It does not make sense that we can only have 127 devices. This would limit us on how many of our guests could have hipersockets, and we want all of them to have hipersockets, and we want to go well over 50, and 127 won't work for 50 guests. -Cameron -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Kreuter Sent: Thursday, December 02, 2004 08:31 To: [EMAIL PROTECTED] Subject: Re: 127 device limitation for hipersockets Operating systems reach out to IODFs which contain i/o definitions. One IODF can define up to 65,536 devices. z/VM can have *WAY* more than 4 chpids - not sure where this restriction in your environment is coming from. Could be that the z/VM LPAR's IODF at your shop only has 4 CHPIDs defined. Beg or plead for more if you are truly at your device limitation. A virtual machine can also have up to 65k virtual devices defined. The z/OS message could indicate an error somewhere in the way I/O devices have been defined. Don't know. Some devices to be useful require multiple addresses, like QDIO. It requires 3 devices: read, write, and data. Other devices require one address, like DASD. 256 devices per chpid is correct. On z990 technology you can also have multiple sets of IODFs, up to 3 I think. David ________________________________ From: Linux on 390 Port on behalf of Seader, Cameron Sent: Thu 12/2/2004 9:19 AM To: [EMAIL PROTECTED] Subject: Re: 127 device limitation for hipersockets Where is some good documentation on setting this up? Currently I have real devices defined for each guest for hipersockets, so I am losing 4 addresses per guest. Is there another way of doing this? Which ways are there of doing this? I have read documentation that seems to indicate that you should be able to have 256 addresses per channel and with z/VM you get 4 channels, so you should be able to get about 1024 addresses, is this correct? If this is correct then how are you able to use these 1024 addresses. We are getting messages on our consoles after we do an IPL on our z/OS and such that we have basically over defined the amount of addresses on an LPAR. Can you specify more than 127 addresses in your IODF per channel. Where is this limitation coming from? Something is amiss. -Cameron Seader -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Kreuter Sent: Wednesday, December 01, 2004 19:10 To: [EMAIL PROTECTED] Subject: Re: 127 device limitation for hipersockets To cross the partition border from VM LPAR to z/OS LPAR you can use hipersockets, which you are doing, or OSA devices (they can be shared), or real CTCAs - different types of chpids can be configured as CTCAs - and you can get a bunch of CTCAs from one channel. If you are running into hipersocket limitations consider sharing your FDR traffic with your other traffic. NICDEFs and SPECIAL statements refer to using guest lans - a completely virtual network - the lan is virtual and so are the adapters. Setup via CP commands and/or directory statements. TCPIP is TCPIP is TCPIP - doesn't know or care that the network is virtual - Every effort should be made to connect virtual machines within one LPAR via guest lans. It's not virtual IP addressing - that's another topic. Hope this helps - send a picture of your network offline if you like. David ________________________________ From: Linux on 390 Port on behalf of Ranga Nathan Sent: Wed 12/1/2004 9:07 PM To: [EMAIL PROTECTED] Subject: Re: 127 device limitation for hipersockets __________________________________________ Ranga Nathan / CSG Systems Programmer - Specialist; Technical Services; BAX Global Inc. Irvine-California Tel: 714-442-7591 Fax: 714-442-2840 Adam Thornton <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[EMAIL PROTECTED]> 12/01/2004 05:16 PM Please respond to Linux on 390 Port To: [EMAIL PROTECTED] cc: Subject: Re: 127 device limitation for hipersockets On Dec 1, 2004, at 7:09 PM, Ranga Nathan wrote: > currently we have two hipersockets defined per guest, one with 64k mtu > block size and one with 8k mtu block size. We use the one smaller mtu > size > hipersocket to talk among the other guests from guest to guest and to > do > authentication to a USS LDAP server under MVS. The 64k mtu block size > hipersocket is being used for backups through fdr upstream on the mvs > side > and notice a nice improvement on speed for backups. The problem we are > running into is the 127 device limitation. > I dont recall this limitation. Is this a Hipersockets limitation? Do > you > mean 127 x 4 addresses? Um, you mean you're using a real Hipersockets dedicated per guest? Don't do that. Define them as SPECIALS or with NICDEF and virtualize 'em. I am losing you. For each Linux guest we had to allocate distinct addresses and aliased them like so, for hipersockets to work: 'ATT EC08 * EC00 ' 'ATT EC09 * EC01 ' 'ATT EC0A * EC02 ' 'ATT ED08 * ED00 ' 'ATT ED09 * ED01 ' 'ATT ED0A * ED02 ' Thus for each guest we needed 8 addresses plus 4 for z/VM itself. The nicdef in DTCPARMS seems to be an appendix. There are big gaps in my understanding. Help appreciated. Adam ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. A1. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. A1. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
