gateway won't set "busy" PV type properly

[Dennis Nicklaus <nicklaus@fnal.gov>]

We've encountered an odd behavior the last couple days that has us 
pretty confused.
Can someone please explain this and/or suggest a fix?
When I set a certain PV going through an EPICS gateway, the setting 
doesn't "work*" entirely.
If set through a non-gateway-ed connection, everything works fine.

By "work", I mean that it appears that the readback after a /caput 
/fails.  The /caput /actually sets the valueof the PV (as we can see 
from the intended effects happening), but the readback after the setting 
fails.  On a terminal, it looks like this, where 13PS1:cam1:Acquire is 
the PV name, Done is the ZNAM (value=0) and Acquire is the ONAM (value =1)./

/$ caget 13PS1:cam1:Acquire
13PS1:cam1:Acquire             Done
$ caput 13PS1:cam1:Acquire 1  
Old : 13PS1:cam1:Acquire             Done
Read operation timed out: PV data was not read.
New : 13PS1:cam1:Acquire             
CA.Client.Exception...............................................
   Warning: "Virtual circuit disconnect"
   Context: "op=0, channel=13PS1:cam1:Acquire, type=DBR_TIME_STRING, 
count=1, ctx="cag-clx-2.fnal.gov:5064""
   Source File: ../getCopy.cpp line 86
   Current Time: Mon Apr 19 2010 16:07:57.274885243
..................................................................
$

(cag-clx-2.fnal.gov is the gateway computer.)
Inspection via caget shows that 13PS1:cam1:Acquire has indeed been set 
to 1/Acquire.
  
Curiously, when we try to set this PV back to 0, the caput totally fails 
-- it doesn't set the value and the readback fails.  That looks like this:

$ caput 13PS1:cam1:Acquire 0
Old : 13PS1:cam1:Acquire             Acquire
Read operation timed out: PV data was not read.
New : 13PS1:cam1:Acquire 
CA.Client.Exception...............................................
 Warning: "Virtual circuit disconnect"
 Context: "op=0, channel=13PS1:cam1:Acquire, type=DBR_TIME_STRING, 
count=1, ctx="cag-clx-2.fnal.gov:5064""
 Source File: ../getCopy.cpp line 86
 Current Time: Mon Apr 19 2010 16:09:33.470317689
..................................................................

$ 


The PV in this case comes from the Prosilica camera support package in 
"areaDetector" version 1-6.  The PV 13PS1:cam1:Acquire is defined to be 
a record type "busy" and basically turns on image acquisition:

record(busy, "$(P)$(R)Acquire") {
  field(DTYP, "asynInt32")
  field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))ACQUIRE")
  field(ZNAM, "Done")
  field(ONAM, "Acquire")
}


Since we just picked up this camera support package recently, I don't 
really know anything about the "busy" record type.  I did discover that 
if I change it from "busy" to "bo" (binary output), everything works 
fine and it will work through a gateway.  But of course, we're concerned 
that we're losing whatever functionality/safety the original author 
wanted from the "busy" type.

And in general, we're curious and confused as to why it acts differently 
when it has to go through the gateway.  (If I set EPICS_CA_ADDR_LIST on 
the requesting machine so that it bypasses the gateway, it works fine.) 
Is it just some timeout because of the "busy" processing? Perhaps 
someone can explain what the "busy" record type does that is so bad here?

More details:
The gateway s/w detects errors when it fails. 
Errors in gateway logs:

Apr 22 09:26:50 !!! Errlog message received (message is above)
CAS Request: finstrom on clx32.fnal.gov: cmd=12 cid=2212591819 typ=0 
cnt=0 psz=0 avail=1
CAS:
Apr 22 09:37:26 !!! Errlog message received (message is above)
bad resource id in "../../../../src/cas/generic/casStrmClient.cc" at 
line 1706

backtrace from caput core file:

(gdb) bt
#0  0x00c6d402 in __kernel_vsyscall ()
#1  0x00530d20 in raise () from /lib/libc.so.6
#2  0x00532631 in abort () from /lib/libc.so.6
#3  0x004e82de in ca_client_context::vSignal (this=0x9172818, 
ca_status=<value optimized out>, pfilenm=0x0, lineno=0,    
pFormat=0xb7e7ee68 "host=cag-clx-2.fnal.gov:5064 ctx=Bad Resource 
ID=2212591819 detected at 
../../../../src/cas/generic/casStrmClient.cc.1706", args=0xb7e7edd4 "J") 
at ../ca_client_context.cpp:406
#4  0x004e8323 in ca_client_context::signal (this=0x9172818, 
ca_status=410, pfilenm=0x0, lineno=0,    pFormat=0xb7e7ee68 
"host=cag-clx-2.fnal.gov:5064 ctx=Bad Resource ID=2212591819 detected at 
../../../../src/cas/generic/casStrmClient.cc.1706") at 
../ca_client_context.cpp:358
#5  0x004e8709 in ca_client_context::exception (this=0x9172818, 
guard=@0xb7e7f0a8, stat=410, pCtx=0xb7e7ee68 
"host=cag-clx-2.fnal.gov:5064 ctx=Bad Resource ID=2212591819 detected at 
../../../../src/cas/generic/casStrmClient.cc.1706",    pFile=0x0, 
lineNo=0) at ../ca_client_context.cpp:314
#6  0x004c59e1 in cac::defaultExcep (this=0x9172a50, iiu=@0x91a3520, 
pCtx=0x91a9040 "Bad Resource ID=2212591819 detected at 
../../../../src/cas/generic/casStrmClient.cc.1706", status=410) at 
../cac.cpp:909
#7  0x004c5802 in cac::exceptionRespAction (this=0x9172a50, 
cbMutexIn=@0xb7e7f1c0, iiu=@0x91a3520, hdr=@0x91a36f4, 
pMsgBdy=0x91a9030) at ../cac.cpp:1012
#8  0x004c55b5 in cac::executeResponse (this=0x9172a50, mgr=@0xb7e7f1c0, 
iiu=@0x91a3520, currentTime=@0xb7e7f1c8, hdr=@0x91a36f4, 
pMshBody=0x91a9030 "") at ../cac.cpp:1106
#9  0x004e07aa in tcpiiu::processIncoming (this=0x91a3520, 
currentTime=@0xb7e7f1c8, mgr=@0xb7e7f1c0) at ../tcpiiu.cpp:1224
#10 0x004e0c5c in tcpRecvThread::run (this=0x91a35dc) at ../tcpiiu.cpp:530
#11 0x0021706e in epicsThreadCallEntryPoint (pPvt=0x91a35e0) at 
../../../src/libCom/osi/epicsThread.cpp:42
#12 0x0021e65b in start_routine (arg=0x918d990) at 
../../../src/libCom/osi/os/posix/osdThread.c:319
#13 0x00d3246b in start_thread () from /lib/libpthread.so.0
#14 0x005d8dbe in clone () from /lib/libc.so.6
(gdb)

We looked at the epics code where the error is. It appears to be a case 
where it's trying to access a PV that doesn't exist.

Thanks for your help!
Dennis