Experimental Physics and
Industrial Control System

[email protected] (Jim B. Kowalkowski) · Thu, 26 Oct 1995 11:44:56 -0500

Chip,

In response to your last email on the error codes topic:

> John saids,
>
> >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.
> 
> Wholeheartedly agree!  Both EZCA and CDEV are attempting to move away from
> this, but much work remains.

------------------------------------------------------------

> John also proposed a basic error logging system, and I would suggest that
> log messages consist of the following "atoms":
> 

We've been discussing the idea of a error logging system throughout the email
on this topic, John was re-iterating on a point from Marty's follow-up to
the proposal from William Lupton (see attached email bits).

Yours:
> 
> 	severity
> 	status code (a ---small--- set)
> 	originating node
> 	originating application/sub-system/whatever
> 	time stamp
> 	arbitrarily long text
> 

Ours (merge from two attached email messages):

struct super_duper_error_info {
	short subsystem_error_code;   // (probably not needed now)
	short priority_of_message;    // in network byte order
	char subsystem_name[8];       // example length
	char subsystem_downstream[8]; // example length
	TS_STAMP time_stamp;          // maybe character format
	error_message_text[SOME_BIGGER_THING];  // arbitrary
};

Here priority_of_message is probably the same as your severity - Marty
refered to it as a basically a verbosity level (see below).

The originating node is good, it comes automatically if the logger is a
network server.

It seems like we are thinking along the same lines,
Jim Kowalkowski

--------------------------------
>From Marty Kraimer on 10/23/95:

                Possible new log system interface

The following assumes that errMdef could be "grandfathered" and ultimately
completely removed from EPICS. New code would use the following.

Perhaps the biggest objection to the existing EPICS status encoding scheme
is that definitions have to be placed in errMdef.h and that a utility has
to be run to create the mapping from S_ values to string messages.
The following suggestion is really due to Jim Kowalkowski and John Winans.

Let libraries define their own status values as small integers.
The problem is to be able to generate error messages
that contain both a meaningful message and the context. In order to solve
this problem any library could make a call to the following routine:

 logPrintf(int verbosityLevel, char *system, char *subsystem, char *format,...)

In addition the library must supply a routine

   char *xxxGetSystem(void);

Then in a normal error situation the following happens:

1) A library routine detects an error.
2) The library routine makes the call:
   logPrintf(0,"xxx",NULL,"This is a bad error because I found it");
3) The library routine returns a value indicating an error occured.
4) The caller executes the code:

   if(!xxxRoutine(...)) {
        logPrintf(0,"yyy",xxxGetSystem(),"This shows context");
   }

It is important to note that this method gives a way to correlate messages
from several layers while still only making each layer know about itself
and the layer it calls. (There is still a problem if two different
tasks call xxx which each result in an error and a task switch occurs between
the two calls).

Since the system values are strings there is only a small chance that
two different systems will use the same system name.

It is assummed that logPrintf would add taskid and hostid to messages
sent to a system wide  error handler.
The above scheme would allow a system wide error handler that lets a
user select messages from particular hosts, particular subsystems,
and particulay verbosity levels.

Marty Kraimer, Jim Kowalkowski, John Winans
------------------------------------------------------------
>From William Lupton on 10/19/95:

Jim Kowalkowski has proposed that the error information flowing over the
network could look like:

struct super_duper_error_info {
	short subsystem_error_code;     // in network byte order
	short priority_of_error_code;   // in network byte order
	char subsystem_name[8];
	TS_STAMP time_stamp;            // maybe char
	error_message_text[SOME_BIGGER_THING];
};

where priority is the same as what I am calling severity (I think).

I would also pass the subsystem-specific status code for completeness
(although most clients would do nothing with it apart, possibly, from
writing it somewhere). It may also be a good idea to break out the
string which is the direct translation of the status code from the extra
string which was provided in the call to errPrintf().
------------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System