EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  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  Index 1994  <19951996  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 
<== Date ==> <== Thread ==>

Subject: Re: application error codes
From: [email protected] (Jeff Hill)
To: [email protected], [email protected], [email protected], [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Date: Thu, 19 Oct 95 10:40:47 MDT


For the folks on the mail list that have not seen all of this discussion:

This thread resulted in part from discussions about moving drivers  
out of base. Currently drivers use error constants with 
an embedded sub system number which is registered in a header file
in base. This makes it difficult to use the EPICS error code system
in a driver without modifying base. In an expanding collaboration
this may become difficult to manage. Also the utility in base that
generates the system-wide error string tables is provided with a list
of header files to peak in by another file in base. This makes
installation of drivers from multiple sites complicated.


> If we go for dynamically-allocated subsystem numbers, as in:
> 
> static unsigned subsysCode = UNDEFINED;
> #define S_subsys_xxx ( subsysCode | 1 )
> 
> then the S_ codes are no longer constants and will not be usable in case
> statements. 

Good point. I dont personally check status with case statements very often
however we are certain to break code, slow things down, and confuse
people if they are not constants. 

I am rereading Jim's message and I see that he argues that we should 
solve this by asking the subsystem for the string equivalent of
a particular error code. 

The problem is that an error code may be passed through many sub 
systems before it reaches the top level application that will actually deal 
with the error condition. Thus the top level application will not know
which subsytem to interrogate (to convert the error code to a string). 
Hence the requirement for a sub system code embedded in the error code.

I suggest the following solution:
One of the sites in the collaboration agrees to provide sub system
error code allocation. This site will assign a unique integer code
to every EPICS sub system by name (and prevent conflicts). Perhaps this
is automated by a web page and a relational database?

When a sub system initializes it will call the following function:

errRegisterSubSystem(unsigned subSystemCode, const char * const *pErrorTable);


This routine will provide the following:
1) Detect when two subsystems are using the same sub system number or name
2) Allow errMessage() and errPrintf() to find the string table for all
	sub systems (even if they are not compiled with base)

>   This needn't affect the policy on always sending text over the wire but
> would mean that modules which need to be able to translate codes would need
> to be linked (dynamically or otherwise) with subsystem-specific modules
> capable of translating the codes (unless data files are used .. but this
> raises other issues).

If we pass codes (and not text) for errors over the wire then we will need
to have a system wide error server in which to store the error messages for 
each error code. Note when designing servers we must avoid a single point 
of failure (or if there is a single point of failure we prefer for it
to be a very small part of the overall system). Also, we must not design 
the server so that it is a requirement to funnel all error message traffic 
through one host or the system will not scale. Any volunteers to design
and write this server?

If we go with an error message server then the CA error traffic will be:
1) error code passed from sub system to sub system to the 
	ca server to the ca client library.
2) the ca client library wishes to convert the message to a string.
3) the ca client library asks the error server for the string
4) the ca client library provides the string to the client side
	application

In this situation we have not saved anything by passing the error
as a code (and not as a string) because we turn around and fetch
the error string off of another server.

Besides if there are any run time details (ie "bad card" isnt
enough information we also need "at A16=0xff00") then we have no
choice but to pass these as strings.

I vote that when sub system errors are passed over the wire that
they are initially converted to strings. In the future if we wish to
optimize we can cache an error constant to error string conversion
table. Optimization of this type could be shared between ca and 
an error logging tool (by using a common library).

Any comments?

Jeff


______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107


Navigate by Date:
Prev: Re: help with ar Deb Kerstiens
Next: MBBO record support Peregrine McGehee
Index: 1994  <19951996  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: application error codes Jeff Hill
Next: help with ar Ian Smith
Index: 1994  <19951996  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·