Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 12 Dec 2008 12:00:57 +0100

On Donnerstag, 11. Dezember 2008, Andrew Johnson wrote:
> On Thursday 11 December 2008 00:39:31 Till Straumann wrote:
> > Quoting the AppDevGuide (3.14.8, 3.14.10,
> > Section 5.4 "Database Locking")
> >
> > "All records linked via OUTLINKs and FWDLINKs
> >  are placed in the same lock set.
> >  Records linked via INLINKs with PROCESS_PASSIVE
> >  or MAXIMIZE_SEVERITY TRUE are also forced to
> >  be in the same lock set."
> >
> > I was naively concluding that records linked
> > via INLINK NPP NMS would _not_ be forced to be
> > in the same lock set.
>
> I agree that this would seem to be a reasonable thing to conclude.  I
> have been lecturing about this exact same behavior for many years, so I
> was surprised to hear that it doesn't work this way any more...

So am I.

> > Does anybody know when the implementation deviated from
> > the documented semantics?
>
> I didn't, but I just did the research.
>
> [...] 
>
> At this point I think the only reasonable fix is to update the
> documentation, and tell people to use a .CA link to break a lockset. 
> Local .CA links do not traverse the network, so they're not quite as
> inefficient as they might seem. Unfortunately this can break some R3.13
> IOCs that get converted to R3.14, but I don't see any way around that
> issue; any IOC developer doing a conversion will have to look carefully
> at their locksets if they matter to that IOC.

I find it somewhat disturbing that such a profound change gets overlooked 
for years, even by core developers.

At BESSY we switched to 3.14 only a about 2 months ago. At one time I /did/ 
notice that our locksets had become very large: it seemed that all the 
records belonging to one device were in the same lockset. At the time I 
didn't pursue the issue any further and put it somewhere in the back of my 
head to get back to when I had a more leisure, believing that I had 
overlooked something that would explain this strange observation. It is now 
clear that this is to be expected, since we usually link all hardware 
records belonging to a device via SDIS to a single boRecord. We will have 
to re-examine our databases for this pattern.

Many thanks to Till Straumann for finally bringing this to our attention!

Cheers
Ben

PS: Do CA input links behave the same way as 3.13-NPP-NMS input links (apart 
from going through the CA layer)? That is, do they actually dbGet the value 
each time they get processed, or are the target PVs monitored and dbGetLink 
gets the last monitored value?

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH   
Glienicker Straße 100, 14109 Berlin   
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph   
Stellvertretende Vorsitzende: Dr. Jutta Koch-Unterseher   
Geschäftsführer: Prof. Dr. Anke Rita Pyzalla, Prof. Dr. Michael Steiner, Dr. Ulrich Breuer   
Sitz der Gesellschaft: Berlin Handelsregister: AG Charlottenburg, 89 HRB 5583   

Information:   
Durch die Fusion mit dem ehemaligen Hahn-Meitner-Institut (HMI) ist   
BESSY nun Teil des neuen Helmholtz-Zentrum Berlin für Materialien   
und Energie (HZB). Die Fusion wird im Januar 2009 vollzogen sein.   

By the merger with the former Hahn-Meitner-Institut (HMI), BESSY   
became part of the new Helmholtz-Zentrum Berlin für Materialien und   
Energie (HZB). The merger will be completed by January 2009.

Disclaimer automatically attached by the E-Mail Security Appliance   
mail0.bessy.de 12/12/08 at Helmholtz-Zentrum Berlin GmbH. 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System