Re: Data types in monitor function

[Jeong Han Lee <citadel.lee@gmail.com>]

Hi Andrew,

  Thank you for the explanation. I've agreed that it is not important
thing to fix.

  I will try to do if I have some peaceful time.

  Thanks,
   Han


On Mon, Apr 24, 2017 at 9:43 PM, Andrew Johnson <anj@aps.anl.gov> wrote:
> Hi Han,
>
> On 04/24/2017 07:27 AM, Jeong Han Lee wrote:
>>   I am wondering the mixed data types in monitor function in
>> most_of_Record.c. For example,  static void monitor(aiRecord *prec).
>>
>>   recGblResetAlarms function returns epicsUint16 (unsigned short) and the
>> returned value is used in different way according to its record, and
>> pass it as argument of db_post_events function with mixed data type.
>>
>>   All of them mixed data types are larger than its epicsUnit16, so no
>> problems I saw.
>>
>>   Is it just due to "history of Data types evolution" in many difference
>> records? If so, do we have any intention to keep the same data type in
>> entire (at least monitor function) EPICS layer? If any help is needed, I
>> can work on them.
>
> The value returned by recGblResetAlarms and accepted by db_post_events
> is a bitmap which tells the CA server which class of monitor events to
> send with this update. The individual bit values are defined in the CA
> header caeventmask.h as DBE_xxx macros and these values are used in the
> CA network protocol. Currently only the lowest 4 bits are used, so all
> values appear in the range 0..15.
>
> Adding additional bits would involve quite a lot of work; in addition to
> modifying the IOC core and/or all the record types it also needs changes
> to the CA client code and both CA servers (RSRV and CAS) in Base, in
> addition to updates to the CA Gateway. I think it unlikely that we would
> add many more events, if any.
>
> The differences between the individual record types is certainly
> historical, because there were many people involved in creating the
> standard set of types that come with Base. There are various things that
> we have cleaned up in the record type code over the years, but this one
> isn't something that we have bothered with. If you wanted to send us
> patches to unify the code we would be happy for the help, but I don't
> see this as being a particularly important thing to fix.
>
> HTH,
>
> - Andrew
>
> --
> Arguing for surveillance because you have nothing to hide is no
> different than making the claim, "I don't care about freedom of
> speech because I have nothing to say." -- Edward Snowdon