In experiments conducted some years ago, I determined that the most
efficient way to signal between two guests was to use alternating IUCV
QUIESCE and RESUME signals. These signals cause the target to receive an
IUCV external interruption, which is sufficient to let it know that
something has
Only A to B as we have no broadcast requirement.
--. .- .-. -.--
Gary Dennis
Mantissa Corporation
On 4/21/09 4:08 PM, Alan Altmark alan_altm...@us.ibm.com wrote:
On Tuesday, 04/21/2009 at 01:55 EDT, Gary M. Dennis
gary.den...@mantissa.com wrote:
The IUCV tests seemed insensitive to
On 4/22/09 10:38 AM, Gary M. Dennis gary.den...@mantissa.com wrote:
Only A to B as we have no broadcast requirement.
You will. Efficient implementation of multicast will need a similar
transport capability.
Thanks.
The following is from some tests we conducted to compare *SIGNAL to straight
IUCV. 2097 Dallas Development, second level VM, under CMS.
100,000 signal / acknowledgement transmissions. The straight IUCV test sent
only 8 bytes to try and put it on equal footing with *SIGNAL.
4 *SIGNAL
On Tuesday, 04/21/2009 at 01:55 EDT, Gary M. Dennis
gary.den...@mantissa.com wrote:
The IUCV tests seemed insensitive to transmission size. Whether we sent
8
bytes or 32,000, the 5 to 7 second window held.
The savings of *SIGNAL would be the use of the broadcast function. Instead
of UserA
On Friday, 04/17/2009 at 12:16 EDT, Gary M. Dennis
gary.den...@mantissa.com wrote:
IF
you have experience using *SIGNAL service for high volumes
To my knowledge, the only exploiter of *SIGNAL is GCS, which has been used
since around 1986 to run VTAM, NetView, RSCS, AVS, PSF and VSCS
IF
you have experience using *SIGNAL service for high volumes
THEN
Could you provide information (or simply observation) relating to
overhead, latency?
ELSEIF
You know compelling reasons this service should not be considered for
very high signal volumes
THEN
This is an
