Here is where the limitation is comeing from on the 127 devices. If you look at 
ios577I which gives reference to

IOS577I IQD INITIALIZATION FAILED, COMPLETION TABLE FULL � SET IQD
       PARAMETERS FAILED � FEATURE NOT INSTALLED                  

We are have the problem with the Completion table being full. If you read 
further about this problem it states and i Quote "COMPLETION TABLE FULL: There 
is an MVS implementation limit for the number of IQD devices that can be online 
at one time (currently 127).
Online IQD devices may be varied offline, so that completion vector  
slots can be freed and the offline IQD devices can be brought online."

IBM has told us also that this limitation also applies to z/VM, This is per 
LPAR. so i am limited to 127 devices online at one time. How have people 
overcome this limit, If i want to have hipersockets on all of my linux guests 
and i want more than 40 guests we have a problem here houston. This limitation 
really sucks. Is there a way to get around this. Is there some way to define 
virtual hipersockets without real addresses? What can we do? I can't setup a 
Guest lan, because i need all of my guests to talk to z/OS since we have an 
LDAP server we authenticat to over on that side.

-Cameron

-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Mark Wheeler
Sent: Thursday, December 02, 2004 08:57
To: [EMAIL PROTECTED]
Subject: Re: 127 device limitation for hipersockets


Cameron,

I just set up real hipersockets myself recently. Initially, 256 devices on
chpid xx cuadd 0. I should be able to add another 256 on cuadd 1
eventually, and another 256 on cuadd 2, etc.

I dedicate 3 addresses per Linux guest, allocated sequentially (potential
for 85 servers over 255 addresses). E.g.
      For LINUX01,
            DEDICATE 1D00 8600
            DEDICATE 1D01 8601
            DEDICATE 1D01 8602
      For LINUX02,
            DEDICATE 1D00 8603
            DEDICATE 1D01 8604
            DEDICATE 1D02 8605
Using the same virtual addresses (1D00-1D02) makes it easier to configure
the Linux boxes (/etc/chandev.conf can be the same on all).

On the z/OS LPARs that share the hipersocket, we use 8600-8602 on all (can
use same addresses on different LPARs).

Best regards,
      Mark Wheeler, 3M Company




             "Seader, Cameron"
             <[EMAIL PROTECTED]
             er.com>                                                    To
             Sent by: Linux on         [EMAIL PROTECTED]
             390 Port                                                   cc
             <[EMAIL PROTECTED]
             IST.EDU>                                              Subject
                                       Re: 127 device limitation for
                                       hipersockets
             12/02/2004 09:36
             AM


             Please respond to
             Linux on 390 Port
             <[EMAIL PROTECTED]
                 IST.EDU>






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



[INFO] -- Access Manager:
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.   A2

----------------------------------------------------------------------
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

Reply via email to