Re: bugs in gateway and gdd

[Ralph Lange <Ralph.Lange@bessy.de>]

Hi Dirk,

first of all: thanks for all the time and effort you are putting into 
this. This is very valuable and highly appreciated.

Looking at the code it seems that you definitely some more bugs in gdd 
as well as in the Gateway. Wow, what a good job! (I've been poking 
around in that code myself a lot, and I mean it!)

Let me add just two comments about the alh connections over the Gateway 
at this time, as this might be of wider interest:

> Is this conversion to a string really necessary? It does not happen if 
> no alarm handler is connected. An other side effect of the conversion 
> is that DOUBLE values are rounded to only 6 significant digits if an 
> alh is watching them. I think, data should be stored in its native 
> type wherever possible.

If you look at db_access.h, you will find that DBR_STSACK_STRING is the 
_only_ DBR type that contains the data that the alh is interested in. 
The alh subscribes to the Gateway asking for DBR_STSACK_STRING, and the 
only thing the Gateway is able to do is to use the same type for its 
subscription to the IOC.
The Gateway does store data in its native type wherever possible - alas 
it is not possible for these alh connections.

Let me think ... back then - when I was adding alh connectivity to the 
V1 Gateway - I think I had organized it in a way that the Gateway would 
open two subscriptions to the IOC and keep two separate copies of the 
data (one native, one DBR_STSACK_STRING) in cases where alh and regular 
clients are connected to the same channel. Maybe this mechanism didn't 
work correctly or was broken somewhere during the changes for V2. I will 
check this as soon as I find time. Do you see different behavior 
depending on which client (alh or regular) is connecting first to the 
Gateway?

> So far my advice: Don't connect alh to the same gateway as your 
> "normal" clients.

This is true and a reasonable advice for another reason:
Regular clients will usually subscribe for DBE_VALUE events, while the 
alh subscribes for DBE_ALARM events, and an archiver will subscribe for 
DBE_LOG events.
Even if the Gateway ORed these bits together in its subscription to the 
IOC, Channel Access will not tell with an incoming update which event 
triggered this update, so the Gateway wouldn't know which clients to 
send the data to.
This is a known deficiency in the Channel Access network protocol which 
will be fixed in the next major protocol update (for EPICS V4).

As a workaround, I made the Gateway subscribe to the IOCs with a fixed 
event mask, which can be set through a command line argument. So the 
smartest way to handle this would be starting multiple Gateways with 
different event masks, and have the clients connect to the appropriate 
Gateway.
This is an ugly workaround, I know, but as long as CA doesn't send me 
the event that caused an update, it's all I can do.

So much for now - this mail is too long already....

Again: Thanks a lot for all your help!!
Ralph