RE: dm and edm problems with CA gateway

["Kenneth Evans, Jr." <evans@aps.anl.gov>]

I was able to reproduce this problem with the behavior described by
Rolf with one combination of systems.  I set DRVH = DRVL =0.0 on a
test PV to allow the large values.  It then happens for me from an
MEDM on Windows going to a Gateway on Linux.  The MEDM was using a
simple ADL file with only a slider.  It does not happen for me for any
other combination of Solaris, Linux, or Windows MEDMs going to Linux
or Solaris Gateways.

I was also unable to reproduce the problem (mentioned by Ralph) with
two simultaneous sliders when going to Solaris Gateways.  That worked
all right for me.

I was able to set up a test Gateway on a non-standard port on the one
Linux box with multiple interfaces I have available.  (I cannot debug
with our Main Gateway on the same machine even though it also
has the described problem with the Windows MEDM.)

The connection goes:

MEDM -> CAS -> Gateway -> CAC -> IOC

I can verify the MEDM is sending the correct values and CAS is sending
incorrect values to the test Gateway.  When the Gateway does a CAC
put, it does a put with callback and does not do any other puts until
the callback happens.  Any write requests that come in while there is
a pending write are sent back to CAS as postponed, and CAS handles them
and resends them later.  Normally things are so fast that there are
probably no postponements.  With sliders they can happen, and
apparently there is a problem with the postponed I/O.

I also note the postponed I/O comes back quite some time after it was
originally sent.  Other new values come in the meantime, so the slider
values that result in CAC puts are done out of order.  In my tests
only about 1 in 10 writes was postponed.

The fact that it only happens with Linux may be the speed of our Linux
box, not the platform itself.  In addition, when I inserted print
statements in MEDM to check its values, the problem stopped happening
owing to the slowdown associated with the prints.  It seems to require
the postponed I/O, which probably rarely happens in the APS Gateways,
owing their being predominately read only in the first place.

It looks as though it needs to be fixed in CAS.