Viewing Cloverleaf 6.0 process logs

We’re not on 6.0 yet, but it looks a lot like you have the EO turned up, or you have some Tcl code generating all of those lines.

I have a couple of band-aids for you:

1. Change your Reflection settings. In the version we use: Setup > Display > Screen > Columns. Set the number of columns that works for you. You may need to adjust the font to improve readability. (I happen to use 196 columns).

2. Use “colrm [startcol [endcol]]”  in conjunction with “less” to remove the columns you don’t want to see. “colrm” reads from stdin and writes to stdout so you can use it like a filter.

Cheers.

Try this as a quick hack.

This uses sed to substitute 59 of any character at the beginning of the line with nothing, then pipes the output to less.  If you want, you could incorporate this into a script outputting the file with a different file extension.

That’s a winner Chris!!!!

I forgot to mention in my suggestion for changing the Reflection settings that you will also need to tell your AIX session what screen width you are using. Running in Linux we have a script that contains:

I concluded the extra information in the Cloverleaf 6.0 process log files is an enhancement from our previous Cloverleaf 5.6 log files, but then my xterms are about 200 characters wide.

I know I’ve been asking for years to have each and every entry in the log file time stamped.

This can really help with trouble shooting when trying to determine what happened percisely when.

Interesting to see how one person’s dream is another person’s nightmare.

I would agree the log files aren’t backward freindly with an 80 character limitation.

Even without the extra log information, I would of considered that to be true so ouch on that 80 character restriction.

There has been a long standing request for the Engine to date/time stamp Log Entries to assist in debugging.

That has been deployed in 6.0.0 and also includes the thread name.

Perhaps requesting a EO Config option or something like that to suppress date/time stamp in a future release may give relief to those with terminal challenges.

Even though I have a laptop with a small screen I appreciate the date.time stamp.

In fact, I would think this would really be welcome if the log is primarily used for analysis because now there is no question as to when the events are logged.

Hi all,

I hear you this and we will look at making the EO detail on Tcl echos optional in a future release.

Rob,

Also note that when a Tcl proc echos multiple lines to the log the date/time portion is not always filled in.

A line from Jennifer’s post:

[tcl :out :INFO/0:epic_a_out_961701:–/–/—- –:–:–] **** epic_a_out_961701/mmc_validate_reply : Three consecutive AR responses – Incorrect Pro

less -S logFileName

You can hit the left and right cursor keys to scroll left and right.

It’s too bad that the log file lines are so long.

We will be adding an option to turn off that extra logging in an upcoming release. An AR has been submitted.

That being said, it’s simple enough to use the system tools to clean up your output. I see that you already mentioned awk/sed, and cut, which is a great place to start.

Also, a quick note on process logging …

The slowest part of any computer system is disk I/O. It is orders of magnitude slower than the rest of the components such as CPU and RAM. Because of this, we recommend that disk I/O be cut down to a minimum where possible and reasonable. The general recommendations are a) don’t write to the logs unless strictly necessary, and b) don’t duplicate disk write.

This is not really a preference idea, but rather an efficiency idea.

With faster disks and better technology this is not as much as an issue as it used to be, but it still becomes an issue when volume and/or message size increases.

Personally, I recommend that message FILTERS almost always be logged so that the reason a message is filtered can quickly be determined. In this case, the I/O is worth the cost. I then recommend all other process logging be turned off unless there is a worthwhile reason to leave it on. And finally, use SMAT for message logging instead of writing messages to process logs.