Re: Fwd: CA link behavior

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Andrew,

My personal opinion is that a record which is not processed should not "do" 
anything. That means it should not cause other records to process and should not 
change their value. I think the original idea behind processing a record is that 
this is the only time where a record is "active". Maybe apart from the time when 
it initializes. But even then it should not process other records.

Let's assume this situation:
ioc1:
A
B.OUT-> C

ioc2:
C
D.INP -> A

I think the "correct" behavior is:
When ioc2 reboots, C becomes INVALID/UDF and only gets a copy of B when B 
processes. D gets initialized with a copy of A. Neither C nor D gets processed 
unless they have PINI set.

Dirk


Andrew Johnson wrote:
> Hi Geoff,
>
> On Monday 23 November 2009 16:52:43 Geoff Savage wrote:
> > Here are the details of my testing with a summary preceding.
>
> Thanks for that very helpful and detailed bug report.  For others, I'll quote 
> Geoff's original message to explain what's happening:
>
> > On Friday 13 November 2009 13:38:36 Geoff Savage wrote:
> > > I have a passive stringout record in IOC A whose OUTLINK references an
> > > mbbo record in IOC B.  When I reboot IOC B the value in the stringout
> > > record is written to the mbbo record even though the stringout record
> > > has not been processed.
>
> I have confirmed that exactly the same thing occurs with the latest release, 
> and after studying the history of the code it looks like this behavior may 
> date all the way back to 1996.
>
> The good news is that it only happens when the data type used is a string, so 
> if you replace your stringout with a longout or another mbbo it will stop 
> happening.  That changes the coupling between your two IOCs slightly since 
> you've moved the string to state conversion, but it doesn't really increase it 
> because the strings had to match before anyway.
>
> The bad news is that it looks like Marty intended this to happen for all data 
> types, as he went to the trouble of storing a copy of the data and recording 
> the fact that the link had actually been used.  In practice non-string output 
> links don't re-send their last value on reconnection because the link flag bit 
> pvlOptOutNative never actually gets set anywhere in the code.
>
> The question at this point is whether to change the current behavior for 
> string data.  Given that EPICS users are not used to this my inclination is to 
> stop it happening for strings too, but I'm open to argument on that.  In the 
> future we might add a link flag to allow the DB designer to control whether 
> this should occur, so I will probably leave the implementation in place anyway 
> and just disable it for now.
>
> Any comments?
>
> - Andrew

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182