Experimental Physics and
Industrial Control System

[email protected] · Wed, 25 Oct 95 17:28:13 -0500

Item 1:  Meeting on Saturday, November 4th.
OK, I will be the bigmouth on this one...  I have horribly little interest
hauling my butt into down town Chicago on a Saturday to talk about EPICS
error messages and codes.  [Feel free to use this message as the meeting's
dart board.]

Item 2: MURMUR and DRAMA
I have looked at MURMUR and DRAMA.  These are nice systems that may very
well take care of the functionality you desire.  But...

If you look closely at DRAMA (that is, if you can actually get the docs in
from AU without their web server disconnecting 12.648% of the way thru), you
will notice that it is the foundation of the system's internal function API. 
Force-fitting it into EPICS is something that I figured, would not fly. 
(I honestly don't recall the part about how it mapps its error messages to
status codes.  But if the quote about it doing a static association is true,
that I object to it times 2.)  It might be OK if starting from scratch.  But
redesigning the core of EPICS to make the required information available for
the DRAMA message system is PROBABLY too much to deal with.  (The idea
of another Rx comes to mind here.)

MURMUR is ALOT closer to the architecture that seems to have been the talk
of this thread for the last week.  However, I would like to object to:
  1) The translation of a status code to a static message.
  2) Passing anything other than the EPICS *database* level information
     up thru Channel Access.

  Some discussion of this point:

    The EPICS system is an OO system made out of black boxes called
    records.  Records have fields.  A field is the 'atom' that Channel
    Access knows of and connects to.  The EPICS information atom is made
    of the following Quarks [if I may continue the theme]:

    status
    severity
    units
    upper_disp_limit
    lower_disp_limit
    lower_warning_limit
    lower_alarm_limit
    upper_ctrl_limit
    lower_ctrl_limit
    value

    Notice that there is no indication of it being an input or output, static
    or dynamic, or that the field is associated with an algorythm, device or
    anything else.  (Feel free to have a gander at the lovely db_access.h
    for yourself.)

    Adding a device status to this collection is possible, but what will it
    really mean?  What would be so useful about it that it would warrant
    an 11th quark?  The status and severity already deliver a VALID/INVALID
    status associated with the value.  The ONLY additional information made
    available in the proposed status code schemes would be a canned message
    such as "Timeout on GPIB bus."  Which, I can tell you (from years of
    getting complaints of such things) is pretty useless to all but a FEW
    cases.  If the user has any clue about how the real device is attached
    or can understand the specific device at all, they will still gripe that
    you did not mention the TYPE of device that timed out.  Given the type,
    they will want to know which of the 4 attached devices of that type is
    the ONE that timed out.  And then it will be which of the 3 identically
    configured GPIB buss adapters is the one that...

Look, what we NEED is a real error messaging system that allows code to
log meaningful, arbitrairly complex, appropriate messages.

I object to the idea of basing the error message and logging scheme on
a return code to message mapping system.  And that goes for anywhere,
including on the IOCs themselves.

I think the errMdef system stinks because it too is based on the assignment
of static messages to return codes.  Even though it's support functions
allow additional text to be appended to a print message, it is still just a
silly static message if it is used at the higher level for messaging
purposes.

Static codes will require an athority to designate groups or ranges.  The
WWW page idea is great, but we will run out of codes well before everyone
who wants a group can have one.  [Espically if non-EPICS institutions want
to be part of it.]  I suppose we could adopt a TCP subnet point of view to
sort-a solve that, but we would still have static mesages.

Saving code numbers and performing future translation is great if you need
to save space/bandwidth... as long you can say what you need in the messages
and as long as the codes never change.  [When was the last time a standard
like this did NOT change?]

I would like to see the error system be based only on text and that it
provide the following minimal functionality:

1) Allow any function in the system to print or log an arbitrairly complex
   message to the IOC console and/or log file.

2) The log file server/management system/thingy should provide a triggering
   mechanism that provides for system status mail-biffs perhaps similar to
   syslog.conf(5).

3) All functions be allowed to return an arbitrary status code to the caller.
   Each of which may or may not represent an actual error condition.

4) IF messages ARE to be statically assigned to return codes from a function,
   those messages should be assigned to the status codes in a header file
   appropriate to the function's api (which may not match that of EPICS or
   the calling function.)

Anything beyond this is icing on the cake.  I don't have a problem with the
request that messages be printable on user interfaces.  Lets just make sure
that the changes to the impacted systems are really warranted and provide
a way to deliver meaningful information.

--John Winans

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System