Experimental Physics and
Industrial Control System

Actually Andrew is correct. Take the "A&2" as an example, when bit 1 is TRUE
then the result of the CALC is TRUE, when bit 1 is FALSE then the result of
the CALC will be FALSE. TRUE being = 1 and FALSE being = 0.

This may be why you are seeing this problem. If you log into the IOC console
and issue this command you will see the value that CA access security thinks
your CALC expression evaluates to as shown below.

asDumpRules
ASG(ID01ds_ACTION) {
        INPA(ID01ds:AccessSecurity) value=3.000000
        RULE(1,READ,NOTRAPWRITE)
        RULE(0,WRITE,TRAPWRITE) {
                UAG(operator)
                HAG(local)
                CALC("A<3") result=FALSE
        }
        RULE(0,WRITE,TRAPWRITE) {
                UAG(flcord)
                HAG(flctrl,local)
                CALC("A<2") result=FALSE
        }
        RULE(1,WRITE,TRAPWRITE) {
                UAG(sec01)
                HAG(sec01)
                CALC("A<1") result=FALSE
        }
        RULE(1,WRITE,TRAPWRITE) {
                UAG(appdev)
        }
}

Marty


GOURNAY Jean-Francois wrote:

Dear Andrew,

I think you are wrong. Remember that the CALC expression must return TRUE or FALSE which will not be the case with A&2, A&4 ...
I guess my scheme is correct. Everything works except this problem with this spiral2mgr user that I don't understand (see the table below from my previous mail). We will try to overcome it in a way or another ... unless somebody has another idea about it !!!

J.F. Gournay
CEA Saclay
IRFU/SIS

-----Message d'origine-----

De : Andrew Johnson [mailto:[email protected]] Envoyé : mercredi 9 septembre 2009 16:56

À : [email protected]
Cc : GOURNAY Jean-Francois
Objet : Re: Access security problem

On Wednesday 09 September 2009 07:34:52 GOURNAY Jean-Francois wrote:

I did more systematic tests and I have this strange situation:

ASGVAL  UAG      spiral2  spiral2mgr      gournay

1       tous      W        W               W        OK
2       develop   -        - (should be W) -        WRONG
4       physique  W        -               -        OK
8       gournay   -        W (should be -) W        WRONG

W : database WRITE access
- :  no write access

I modified the CALC expressions accordingly to Martin suggestion :
CALC("A&1") instead of CALC("A&1=1").  But I don't think I have to write
CALC (A>0&&A<2) as my A value comes from a longout record.

You're right there, but for historical reasons the relative precedence of the ">>" and "=" operators are different in C and CALC, so you do need to change your expressions:

            CALC("A&1=1")

As Marty suggested "A&1" is sufficient here

            CALC("A>>1=1")

CALC actually evaluates this as "A>>(1=1)" which is not what you mean. You could use "(A>>1)=1" but I would suggest "A&2" here instead.

            CALC("A>>2=1")

"A&4"

            CALC("A>>3=1")

"A&8"

Using fewer operators will also parse and execute faster.

This message sent yesterday didn't show up.

That's because you actually sent it to tech-talk-bounces@aps., not to tech-talk@aps., and I didn't get a chance to forward it manually before you re-sent it.

HTH,

- Andrew

References:

TR: Access security problem GOURNAY Jean-Francois

RE: Access security problem GOURNAY Jean-Francois

Re: Access security problem Andrew Johnson

RE: Access security problem GOURNAY Jean-Francois

Navigate by Date:

Prev: RE: Access security problem GOURNAY Jean-Francois

Next: Killing a soft IOC which doesn't have an interactive shell Rees, Nick (DLSLtd,RAL,DIA)

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <2009>  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: RE: Access security problem GOURNAY Jean-Francois

Next: 2eSST??? Eric Bjorklund

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <2009>  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024