ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Work with user jobs issue

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Work with user jobs issue

    Hello Everyone,

    There is this particular job which is in Message wait. But i am unable to hit a 7= Display Message against this job. And see a "Display message option not allowed" at the bottom of the screen.

    This seems to be a system message error of QWM1201 for option 7 not being able to be hit.

    Please guide what could be causing it and what could be the possible way of resolving it?

    Thanks

  • #2
    Re: Work with user jobs issue

    The message ID is usually more useful than message text, especially 1st-level message text. More than one message ID might have the same text from different reasons.

    However, I think the only system message ID that should have that text is CPD1201. Usually, I would expect that message ID to mean that there is no message that was sent and is waiting for a reply. A job status of MSGW means a job is waiting on a message. It might indeed be waiting for a message reply, which would be the most common cause; but it might also simply be in a "message queue monitor" state. It might be a job that is watching for any message to arrive on some message queue.

    For example, it could be a job that monitors the QSYSOPR message queue, looking for particular system problem messages to show up. That's not necessarily what your job is doing. It's just an example.

    If the job stays in that status and doesn't respond to option 7, that's likely what's happening. The job is supposed to be in MSGW status. That would be it's normal state. Even if it's a periodic state, it may be exchanging messages to another job or even another program in the same job.

    You need to know what the job is supposed to be doing in order to understand MSGW status. That status can't always be handled through option 7.

    Apart from that, if option 7 results in CPD1201 and the status stays in MSGW after refreshing, it's probable that the status has little to do with message ID QWM1201. That usually arises out of a Query Manager procedure that had a problem. Since we know the message ID, the text would be useful.

    Tom
    Tom

    There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

    Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

    Comment


    • #3
      Re: Work with user jobs issue

      Hi Tom,

      Firstly, thanks for the response.That's right. The Message ID is indeed CPD1201.

      If the job stays in that status and doesn't respond to option 7, that's likely what's happening. The job is supposed to be in MSGW status. That would be it's normal state. Even if it's a periodic state, it may be exchanging messages to another job or even another program in the same job.
      Well, the job is meant to end normally with no wait lag for any external monitor on job/user input.

      You need to know what the job is supposed to be doing in order to understand MSGW status. That status can't always be handled through option 7.
      The job runs for a report print and completes normally in test environments.

      That usually arises out of a Query Manager procedure that had a problem.
      How do I go about verifying an issue with the Query Manager procedure if this possibly is the case?

      Also I would like to know what could be the other possible way of replying to this message wait(if in case I would like to cancel the job)

      Please guide.
      Last edited by techas400; May 28, 2013, 04:06 AM.

      Comment


      • #4
        Re: Work with user jobs issue

        The joblog should show the QWM1201 message ID. And immediately before that message, there should be a SQL message related to the SQLCODE that is included in QWM1201 message text.

        Without seeing the actual joblog, it's hard to guess what the MSGW problem is. (And without knowing the programming, it could still be a guess.) It might also be useful to know the expected run-times for other instances of this job. E.g., there could be a potential for huge joblogs or there might be complex indexes being built, either of which can sometimes show significant delays in responses from jobs. Or there might even be one or more other jobs in the system that introdce delays.

        However, the joblog from the problem job is the starting point for any research into the job's problems. That a primary purpose of a joblog.

        Tom
        Tom

        There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

        Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

        Comment


        • #5
          Re: Work with user jobs issue

          I looked at some basic elements of MSGW since your question. Usually, a job in MSGW status will respond to WRKACTJOB option 7 by displaying the message that the job is waiting on. That's the expected result.

          The secondary result is that message ID CPI1150 will returned. That would normally indicate that the job is waiting on RCVMSG rather than on a reply to a message sent by the job.

          But your job returned message ID CPD1201. The 2nd-level text includes "Either the message is sent to the job message queue and cannot be displayed, or the status for the job was checked and the job is no longer waiting on a message. If the job was waiting on a message, that message was answered or received."

          Can you estimate how long the job remained in a state where CPD1201 was returned? You might have tried once, then tried a few seconds or minutes later. Was it immediate that you tried again? 30 seconds later? Five minutes? (A simple guess would be good enough.) And did the MSGW status change before the job ended? If you hadn't refreshed the WRKACTJOB display, the MSGW status could have been a transient condition. A simple F5=Refresh might have shown that the message processing was done and the status had changed. Was a screen refresh requested? (You might not have thought to try it, so I have to ask.)

          Tom
          Tom

          There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

          Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

          Comment

          Working...
          X