Thanks for the response on the IUCV questions.
I have included below item 6 from the thread origin and a snippet from John
Baker's response.
Maybe I should have placed more emphasis on item 6. The server machine is
going to be updating the buffer areas in all the connected client machines.
On Wednesday, 08/27/2008 at 12:09 EDT, Gary M. Dennis
[EMAIL PROTECTED] wrote:
I have included below item 6 from the thread origin and a snippet from
John
Baker's response.
Maybe I should have placed more emphasis on item 6. The server machine
is
going to be updating the buffer areas in
Alan,
Thanks. Especially for 5 through 9.
On 8/27/08 12:37 PM, Alan Altmark [EMAIL PROTECTED] wrote:
I don't understand why you want to use temporary connections.
I don't. The original idea was to have connections for each guest active all
the time **so long as the associated overhead would
@LISTSERV.UARK.EDU
Subject: Re: IUCV - What's wrong with this picture?
Thanks for the response on the IUCV questions.
I have included below item 6 from the thread origin and a snippet from John
Baker's response.
Maybe I should have placed more emphasis on item 6. The server machine is
going
On Wednesday, 08/27/2008 at 10:04 EDT, John P. Baker
[EMAIL PROTECTED] wrote:
For example, let's say that we create an *NOTIFY system service.
A virtual machine, appropriately authorized is allowed to connect to the
*NOTIFY service, and by sending properly constructed messages, register
its
1. Does IUCV infrastructure overhead specifically associated with
number
of
connections become prohibitive at some well known point?
There is a limit to the maximum number of connections (a parm on the
IUCV statement in the directory entry; I think the max value for that
parm is 64K, but check
the opinions or policies of Hewitt Associates.
David Boyes [EMAIL PROTECTED]
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
08/26/2008 08:22 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: IUCV - What's wrong
Assumptions:
0. A VM server machine
1. A cluster of client virtual machines (possibly thousands)
2. n buffers are allocated for each client virtual machine
3. Each buffer contains table elements that require
(a) Element ageing
(b) Element deletion when invalidated by:
1. lack
Message -
From: Gary M. Dennis [EMAIL PROTECTED]
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV - What's wrong with this picture?
Date: Mon, 25 Aug 2008 12:23:49 -0500
Assumptions:
0. A VM server machine
1. A cluster of client virtual machines (possibly
thousands)
2. n buffers are allocated
: IUCV - What's wrong with this picture?
Date: Mon, 25 Aug 2008 19:13:20 -0800
Sounds like there is a need for decent performance
monitoring.
dave wrote:
Hi, Gary.
Well, there is no such thing as a free lunch, so
establishing *large* numbers of IUCV connections between
virtual
problems. The
server would have to have enough resources available to
process all of the traffic in an acceptable amount of
time
Good luck.
- Original Message -
From: Gary M. Dennis [EMAIL PROTECTED]
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV - What's wrong with this picture?
Date: Mon
/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gary M. Dennis
Sent: Monday, August 25, 2008 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV - What's wrong with this picture?
Assumptions:
0. A VM server machine
1. A cluster of client virtual machines (possibly thousands)
2. n
On Mon, 25 Aug 2008 12:23:49 -0500, Gary M. Dennis [EMAIL PROTECTED]
com wrote:
Assumptions:
0. A VM server machine
1. A cluster of client virtual machines (possibly thousands)
2. n buffers are allocated for each client virtual machine
3. Each buffer contains table elements that require
On Monday, 08/25/2008 at 10:11 EDT, dave [EMAIL PROTECTED] wrote:
Well, there is no such thing as a free lunch, so
establishing *large* numbers of IUCV connections between
virtual machines does cost something. Control blocks must be
allocated, must be managed by CP, interrupts fielded, etc.
14 matches
Mail list logo