Announcement Announcement Module
Collapse
No announcement yet.
Reading the QSYSOPR msgq Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Reading the QSYSOPR msgq

    Help/Systems Robot/Console and Alert are worth the money spent. You can spend a factor of 2 trying to do this yourself.

  • #2
    Reading the QSYSOPR msgq

    Messenger Plus from www.bytware.com is also useful. Robot might be easier to configure; I've never used it.

    Comment


    • #3
      Reading the QSYSOPR msgq

      I haven't used this but there's a special msgq QSYSMSG for severe error messages. According to IBM, QSYSMSG holds only messages that require immediate action. Which may be the only ones you want anyway. Google QSYSMSG or check the IBM manuals. I've setup Robot Alert/Console - very powerful, reasonably easy but somewhat pricey for my smaller clients. HTH.

      Comment


      • #4
        Reading the QSYSOPR msgq

        Thanks all for ur fast responses the qsysmsg really helped (as long as im not in a position i can make a decision to buy tools ) but my Russ, is there any other way to run the program other than submitting it to qbatch and keep it there running with status MSGW?? thanks again

        Comment


        • #5
          Reading the QSYSOPR msgq

          As I don't know what your pgm does, it's difficult to say. But I'll tell you what I do for long-running batch jobs or batch jobs that I want running all the time. For scheduled jobs that run most of the day: 1. Create job scheduled entry 2. Specify jobq as QUSRNOMAX (by default, in subsystem QUSRWRK - with *NOMAX for jobq entries at all priorities). For jobs that run as long as the system is running: 1. Create an autostart entry in QUSRWRK subsystem - specifying the desired job description which runs my never-ending job. Thus when subsystem starts, it runs the pgm. I use both methods depending on what I'm trying to accomplish. One caveat is that if the job crashes for some reason, you need some mechanism to restart it. The autostart job method can require you to end and start the subsystem. HTH

          Comment


          • #6
            Reading the QSYSOPR msgq

            I too, am an avid user of messenger plus. I will go on record as saying I can't live without it, and if that's the solution you choose, I'll be glad to share with you what we've done.

            Comment


            • #7
              Reading the QSYSOPR msgq

              I use SNAPSHOT to monitor the QSYSMSG queue. Its easy to set up in SNAPSHOT, and all you have to do is create the message queue, QSYSMSG, and tell SNAPSHOT to monitor it. Thats one thing that I didnt see in the above posts, you have to create QSYSMSG, its not on the systems by default. Back to SNAPSHOT, you have multiple choices on how you want to be notified. Personally I set it up to email certain phone extensions thru our AUDIX. I also get a hardcopy email of the error message. My desk extension is set up to call my cell phone with a message that is read to me in a "HAL" voice. Worked like a charm on saturday when one of my servers had a disk failure. Beat messanger plus by about 45 min as far as notifying me. And SNAPSHOT is way cheaper than ROBOT. If you have any questions feel free to contact me. Thanks Scott

              Comment


              • #8
                Reading the QSYSOPR msgq

                If you are on V5R4 and you know which messages you want to be notified of, then you may want to look at the new message watch function of i5/OS. This allows you to designate a program to be automatically called when a message (or list of messages) is sent to QSYSOPR. You can also watch for messages to the history log, job's job logs, etc but QSYSOPR is what you're appearantly looking for. To find information on this capability, see the Information Center and then select Programming; APIs; APIs by category; Problem Mangagement; and then Monitoring. In particular you might be interested in the Start Watch and the Watch for Event Exit Program interfaces. As an alternative to the Start Watch API, QSCSWCH, you can also use the STRWCH command. One distinction between the API and the command is that the command allows you to watch up to 5 messages per command use, the API allows up to 100 messages per API call. In either case you can call the command or API muliple times if you need more messages. You can have up to 10,000 watches active concurrently with V5R4. Bruce Vining

                Comment


                • #9
                  Reading the QSYSOPR msgq

                  Im trying not to use any tool for that Scoboza, but i will inform u if we intend to Is the API available only in V5R4? currently we are on V5R3, and it seems it doesnt have this function. Thakns all

                  Comment


                  • #10
                    Reading the QSYSOPR msgq

                    We distribute Snapshot. So thank you Scott for your kind comments. Firas400, if you want to try Snapshot free with no cost or obligation, email me malcolmv@accesspathsoftware.com

                    Comment


                    • #11
                      Reading the QSYSOPR msgq

                      firas400, see the attached code. Nothing elegant, but it does work. I simply sent each message to the user message queue, you could check the &RtnType field to identify the messages you want to act upon.
                      Code

                      Comment


                      • #12
                        Reading the QSYSOPR msgq

                        One could do a CHGMSGQ to specify a program that gets called whenever a message arrives. you will have to put the message queue into *BREAK mode, specify the SMS sending program on the Message Queue definition, and eventually specufy the *ALWRPY parameter. CHGMSGQ MSGQ(QSYSOPR) DLVRY(*BREAK) PGM(MYLIB/MYPGM *ALWRPY)

                        Comment


                        • #13
                          Reading the QSYSOPR msgq

                          Hello all need to read the qsysopr msgq in order to send special messages and alerts through SMS to mobile. is there anyway i can catch the message on the qsysopr depending on the msg description and then call the program to send it to mobile? thanks in advance

                          Comment


                          • #14
                            Reading the QSYSOPR msgq

                            You could create a Monitor in iSeriesNavigator to monitor QSYSOPR MSGQ for various messages. When one of these messages is encountered, you specify a program to call. You can pass the MSGKEY to the CL program and RCVMSG from QSYSOPR to get more details on the message. Then you can call your mobile. Note, however, that you can't do a RVCMSG if the MSGQ is locked by another job. Worst case though, you could send a message that just says "Check QSYSOPR". Hope this helps, mary

                            Comment

                            Working...
                            X