RE: Getting Alarm Handler (1.2.9 or 1.2.10) to write to ACKT fiel d

["Rock, Judith E." <jrock@SLAC.Stanford.EDU>]

Hi Dayle,
Did Ralph's suggestions fix your problem?
I hope...
- Judy

-----Original Message-----
From: Ralph.Lange@mail.bessy.de [mailto:Ralph.Lange@mail.bessy.de]
Sent: Thursday, September 05, 2002 5:22 AM
To: Kotturi, Karen `Dayle`
Cc: EPICS Tech-Talk
Subject: Re: Getting Alarm Handler (1.2.9 or 1.2.10) to write to ACKT
field


Hi Dayle,

the alh configuration and command line arguments that you are using seem
reasonable. Also your understanding of how the alh handles the ACKT
fields is correct.

The error message you are getting gives the most detailed hint:

  >   alCaPutGblAckT: ca_put acknowledge transients failed for PV <myPvName>
  >   Return Status: Write access denied

So the CA access that the alh is doing is correct, but the alh doesn't
get write access to the record.

So ...

  > I have removed all security from the IOC (i.e. ASG field for all
  > records is empty).

Here's the important clue:

The ASG field being empty does _NOT_ mean that you removed access
security. It only makes the record use an Access Security Group (aka
ASG) called DEFAULT instead of a specified one.

As long as you load an access security definition file, records with
empty ASG fields will end up using the rules in the DEFAULT group. You
have to comment out the setting of the access security definition file
in your startup script to shut down access security completely for the
IOC.

The only other reason for your alh not to work could be that it accesses
the database through an instance of the CA Gateway which is running in
read-only mode or doesn't have write access defined for your alh client.

When accessing an IOC through a Gateway, only the access security rules
in the Gateway are affecting your client's connection. The IOC only sees
the Gateway as its one and only CA client and has no idea of this being
a proxy serving more than one end user client on the other side.

Hope this helps,
Ralph

>>>>> "Dayle" == Dayle Kotturi <dayle@SLAC.Stanford.EDU> writes:

  > I am running alh (version 1.2.9 or 10) in global and active mode. I have
  > removed all security from the IOC (i.e. ASG field for all records is
  > empty).

  > I want the alarm handler to read the 'T' flags set for a given
  > channel and use them to override the (default) value in the database
  > for the channel (which is ACKT=YES), such that the operator does not
  > have to acknowledge transient alarms, as is the behaviour of alh
  > (version 1.2.2).

  > I understand that the way to do this is to run the alh with -caputackt
  > cmd line option. The expected behaviour is that alh will set all
  > channels' ACKT filed to NO where it finds a 'T' set in the alh config
  > file.

  > To be clear, the command line I am using to start the alh is:

  >     alh -global -caputackt -aCM -oCM -m 10000 alhConfigFile

  > Doing this, I get write access errors (i.e. alh process is not allowed
  > to write this field of the channel/record. Specifically, with R3.13.2, I get:
  >   alCaPutGblAckT: ca_put acknowledge transients failed for PV <myPvName>
  >   Return Status: Write access denied

  > Sorry to be so verbose but there is a recent tech-talk entry from
  > 14aug2002 related to this...

  > On Wed, 14 Aug 2002, Marty Kraimer wrote:

  >> john sinclair wrote:
  >> 
  >> > Can the ACKS and ACKT fields be modified via
  >> > channel access? When I try, ca_put fails.
  >> 
  >> ACKS can only be changed via a DBR_PUT_ACKS request.
  >> 
  >> ACKT can only be changed via a DBR_PUT_ACKT request.
  >> 
  >> ACKS,ACKT are present for alarm handlers not general purpose CA clients.
  >> Note that access security can be used to limit who/where/when can modify these
  >> fields.
  >> 
  >> Marty Kraimer

  > I am not sure how to accomplish Marty's suggestion. How do I get the
  > alh to use "a DBR_PUT_ACKT request"? Do I need another version of libca.so?
  > I saw no change using R3.13.6 and have not yet tried with R3.14.

  > thanks for any help,
  > Dayle