Message Monitoring

[ARobb73]

Anyone have a suggestion for a bare bones monitoring software. I don't really need anything terribly fancy, just something to text me if there's an error on the system.

Thanks!

[jamief]

Re: Message Monitoring

Take a peak at this nasty bit of code..
go here: http://www.code400.com/inside.php?category=OPERATIONS

ctrl-f then past this in window "Identify jobs in *MSGW" and mash the enter key

[tomholden]

Re: Message Monitoring

i'll go you one better...if you have MMAIL installed you can just download my tool i use here for free as well...code included (as-is, no warranty)....
http://tommyholden.com in the downloads section just click on Send Message Waiting NEP and you can download the savf, restore the library and you're pretty much set...

[John Andersen]

Re: Message Monitoring

What exactly are you wanting to monitor; message queues like QSYSOPR, active jobs with MSGW status or something else?

Getting a list of jobs with MSGW status is pretty straight forward, one poor mans way is to dump WRKACTJOB to and outfile and filter then you can use another tool to email. Message queues can be tricky because of the whole allocation bit.

-John Andersen

[jamief]

Re: Message Monitoring

John -- take a look at either mine or Tommy's example.
They use API: QUSLJOB and work flawlessly.
No need to dump wrkactjob to spool.

[ARobb73]

Re: Message Monitoring

Thanks guys, I'm most likely going to end up looking at both of them here in the next couple of days.

[tomliotta]

Re: Message Monitoring

Here's a simple test program to help checking monitors of MSGW jobs:

/* +
   Test job MSGW status...                                             +
                                                                       +
   Program requires a *MSGQ in MYLIB named MSGW. Use CRTMSGQ to create +
   the *MSGQ, then use SBMJOB to call this program. The program will   +
   wait up to five minutes for you to send a message to that *MSGQ.    +
   You can use SNDMSG to send the message.                             +
                                                                       +
   While the program is waiting, the job will be in MSGW status. When  +
   a message is found or the five minutes expires, the program will    +
   send an *INQ message to MYLIB/MSGW with SNDUSRMSG. While waiting    +
   for a reply, the job will again be in MSGW status. When the reply   +
   is received, a second *INQ message is sent to MYLIB/MSGW with       +
   RPYMSGQ( &JobUsr ). The expected reply is redirected to the user    +
   message queue of the job running this program. This job will not be +
   in MSGW and will end.                                               +
*/
pgm

   dcl   &TstMsgL     *char    10     value( 'MYLIB     ' )
   dcl   &TstMsgQ     *char    10     value( 'MSGW      ' )

   dcl   &JobUsr      *char    10
   dcl   &REPLY       *char

   rtvjoba     user( &JobUsr )
   rcvmsg      msgq( &TstMsgL/&TstMsgQ ) wait( 300 )

   sndusrmsg   msg( 'Enter FIRST reply' ) +
                 msgtype( *INQ ) +
                 tomsgq( &TstMsgL/&TstMsgQ ) +
                 msgrpy( &REPLY )

   sndmsg      msg( 'Enter SECOND reply' ) +
                 tomsgq( &TstMsgL/&TstMsgQ ) +
                 msgtype( *INQ ) +
                 rpymsgq( &JobUsr )

   return

endpgm

As written, the program uses a *MSGQ named MYLIB/MSGW. That can be changed, of course; but the chosen *MSGQ should be empty when the program starts running. It also should not be the same as the user *MSGQ of the job user, since the program uses that for the target of redirected replies at the last step. The test *MSGQ should be empty in order to ensure that the RCVMSG is forced to wait, otherwise the MSGW status will zip by too fast for useful testing. A CLRMSGQ command might be added at the beginning to ensure RCVMSG won't find anything at first.

The point of using this for testing is that the program goes through three phases. Two of the phases generate two different kinds of MSGW job status. A program that monitors for the status should ignore it during the first phase (RCVMSG) and catch it during the second phase (SNDUSRMSG). The third phase (SNDMSG) is for an almost unrelated test of message replies and can be removed if desired..

Regardless, anyone installing (or creating) a MSGW monitor can test the monitor by submitting a call to this program. It gets tricky telling the two MSGW phases apart.

Tom