RE: Question Re: Piping and Redirection

Unix messages can have a "severity level", but not in the OS/400 sense.
There are levels such as "debug", "info", "crit", "kernel", etc. But these
levels are processed by the syslog daemon to determine which messages should
be sent to a log file (for example, /var/log/messages). I believe the
message level is part of the text in the log file. If you're using syslog,
you can flag certain messages to interrupt the terminal; I think "crit"
messages do this. However, I don't think unix log files + tail + syslog has
the same flexibility and power as OS/400 message files with break mode,
break handling programs, rcvmsg, etc. It's just a different animal.

The tail command does automatically refresh the screen (new entries are at
the bottom of the screen), which I do like over dsppfm, dspmsg. I use a
secure shell program in Windows to monitor my unix box's activities, the
advantage here is if messages are occurring faster than I can read them,
then I can simply use the scroll bar to view previous messages.

Two big problems with both OS/400 and /var/log/messages, in my view, are
1) you cannot selectively "clear" messages from the queue. Here, I'm talking
about wrkmsg qsysopr, then remove all printer alignment messages, or all
jobs at workstation X ended messages. This is different from having critical
messages in qsysmsg; I'd want to clear the "fluff" from qsysopr. Same is
true for /var/log/messages.
2) Both of these are cleared on IPL/bootup. If you had an abnormal
powerdown, you don't see anything prior to the IPL message or initial boot
message. Again, I'm talking about message queues, not the wrkhst command.

I think the monitoring capabilities are better for OS/400 (we like Messenger
Plus), since the messages are standardized, and contain "metadata" that
shouldn't change between releases. Unix message files can contain any
message format, where it is up to the program to interpret the message "in
stream". OS/400 is better, with substitution variables, message data,
severity levels, and message identifiers.

I guess I'm agreeing with you. I do Linux stuff part time, and am by no
means a guru. My limited exposure to tail is exclusively for monitoring log
files. I do know of some Perl programs that tail work files? Log files? To
see the latest entries. There really is no real equivalent in OS/400. The
closest I can think of is (for instance) a data queue tied to an outq, that
receives new spool file entries. The wrkmsg and dsppfm don't really compare
to tail, other than you can refresh them manually to view new content.

I'd say that unix is a different hands-on than OS/400. Out of the box, you
get similar tools. Programs like Messenger Plus or the Robot products you
must purchase in addition. Otherwise, you are in a similar situation of
doing a periodic wrkmsg qsysopr or having it break to your terminal. But
that's just my experience.

I use /var/log/messages in my examples because it's roughly analogous to the
qsysopr message queue. However, tail works similarly with other files.

Loyd Goodbar

-----Original Message-----
From: Evan Harris [mailto:spanner@ihug.co.nz]
Sent: Wednesday, November 20, 2002 12:35 PM
To: midrange-l@midrange.com
Subject: RE: Question Re: Piping and Redirection


Hiya Loyd

I'm still mystified as to why you would want to watch the log files. Seems
to me that constantly watching them would be more disruptive than getting a
break message  - especially when you can't easily filter the log by a
severity level. Or can you ?

I guess you could write a small script to do some filtering, but AS/400
already has this via severity level parameter and you could write a script
there anyway too.

I presume the monitoring of the SQL log is to check progress on a  job so
the equivalent on the AS/400 would be to just check the job log after
locating the job by wrkactjob. Slightly different access to visibility I
guess but much the same result. Same with watching the processes to monitor
jobs completing (my example was intended to appy where there was a job  that
you needed to be alerted the instant it completed not as any kind of generic
procedure)

The approach I tend to take on the AS/400 is to watch nothing but monitor
everything. The critical message queues are monitored for exceptions,
critical jobs are monitored - I have a home grown monitoring system) and any
exceptions to the expected parameters will interrupt me etc etc

This seems to be - at least to me - one more demonstration or symptom that
unix is a much more hands on environment than the AS/400 at a basic level.
This is not necessarily a bad thing - I fondly remember the 38 environment
in the early 80's being kind of similar regarding the level of involvement
it demanded :)

Anyway, I'm not trying to shoot holes in your examples - I appreciate you
providing them and it makes a bit more sense to me than it did.

Regards
Evan Harris