Re: Newbie Question

Error messages ought to go to MSGQs with most serious to QSYSMSGQ.
We have ours split into type of message ... hardware disconnection problems to one OUTQ for example.
There's also security audit ... like if a hacker tries to get in.

There are APIs and other ways to have the messages both stay in the original Q and be copied elsewhere, with rising hierarchy if some message not responded to.

e.g. Backup failed or JOBQ hung because of error with job that came from JOBQ ... notify the IT staff by e-mail, pager whatever ... they don't respond in X minutes, so now pass on the alert to a higher level of management. You can write your own, or go with some 3rd party package of such solutions, such as ROBOT MESSAGES from HELP SYSTEMS

Depending on how the application software is written, its error messages might not show up in any OS/400 *JOB or *MSGQ tool.

When an interactive job has MSGW there is a message at that interactive work station spelling out the problem, with tools for the operator to get more info, and deal with it.

If the software is well written and managed, getting a MSGW on something other than an interactive job should be extremely rare ... like once in a blue year.

The purpose is to have some automatic monitoring for error conditions (MSGWs
and jobs that should be active at all times).

We did look into using Monitors through iSeries Navigator, but it kept
crashing and we could never actually get a monitor working.

So we're pulling the file over to a linux box and using perl parse the file
and notify us. Again, I have read that perl can be installed on an as400,
but that would be a whole different can of worms ;)

Steve


On Wed, Nov 26, 2008 at 10:11 AM, Shannon ODonnell <
wrote:

> Can I ask why you want that information on a PC? Are you going to graph
> it, or do you do it for sorting purposes of some kind?