EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: R3.14.8 Status/logClient patch
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Thu, 17 Nov 2005 14:29:25 +0100
On Thursday 17 November 2005 13:38, Marty Kraimer wrote:
> I am assuming that Benjamin will provide an updated version
> encorporating Jeff's suggestions.
> Is this correct?

Form my side: yes.

> Benjamin,
>
> Is  CaPutLog generic enough that we should include it in base?

I have been thinking about that. Definitely not for 3.14.8. The current 
implementation is, well..., let's say it doesn't fully meet the very 
high standard of code quality in base. I am in the process of (more or 
less) rewriting it for 3.14 and there are some open questions with 
regard to features and implementation. I'll announce the new version 
when I'm done with it. Let us postpone the question until then.

> I assume that to use it just requires starting a logServer that uses
> a different port than the server that listens for errlog messages? Is
> this correct?

Yes, exactly. (And another file name, of course)

> What about cmLog?

I am not an expert for cmLog. However, I discussed it with Thomas Birke.

In short, iocLog and cmLog are incompatible tools to solve a similar 
problem.

CmLog uses its own protocol with /structured/ messages and a database to 
store and retrieve log data. This is a very nice approach, because 
structured log data make it possible for tools to (easy & fast) extract 
whatever data they are interested in. However, it is based on CDEV for 
structuring the log data and also uses a 3rd party C++ network library. 
Thomas said that people somewhere have managed to use a cmLog client on 
the IOC (under VxWorks) for all logging (replacing the standard ioc 
log), but I think it would be a bad idea to include this with base. The 
comparatively low-tech ioc log approach is a lot more fool-proof and 
portable, IMHO. It would make more sense to write a cmLog client to be 
run on the /host/ that inspects the file written by a normal log 
server, parse the strings and forward the result to cmLog. Or maybe 
even use a pipe instead of a file.

Ben

Replies:
Re: R3.14.8 Status/logClient patch Benjamin Franksen
References:
RE: R3.14.8 Status/logClient patch Jeff Hill
Re: R3.14.8 Status/logClient patch Marty Kraimer

Navigate by Date:
Prev: Re: epicsAtExit Marty Kraimer
Next: Re: R3.14.8 Status/logClient patch Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: R3.14.8 Status/logClient patch Marty Kraimer
Next: Re: R3.14.8 Status/logClient patch Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·