Message in scheduled state

Question

Hi Experts,
In our production system, messages are frequently going to 'scheduled for outbound processing" state. After the manual retry the messages are going through. We are planning to setup RSQIWKEX, RSARFCEX and RSXMB_RESTART_MESSAGES for automatic restart of the messages.
However, my question here is, why the message is going into scheduled status? When i compare a message which is in scheduled state, i find the below message in the trace.
<Trace level="1" type="T">Going to persist message + call qRFC now...</Trace>
  <Trace level="1" type="T">NOTE: The following trace entries are always lacking</Trace>
  <Trace level="1" type="T">- Exit WRITE_MESSAGE_TO_PERSIST</Trace>
  <Trace level="1" type="T">Async barrier reached. Bye-bye !</Trace>
  <Trace level="1" type="T">----
</Trace>
  <Trace level="1" type="B" name="CL_XMS_MAIN-WRITE_MESSAGE_TO_PERSIST" />
- <!--  ************************************
  -->
  <Trace level="3" type="T">Persisting message Status = 012</Trace>
  <Trace level="3" type="T">Message version 003</Trace>
  <Trace level="3" type="T">Pipeline CENTRAL</Trace>
  </Trace>
  <Trace level="2" type="T">Leave pipeline processing after LR because of receiver-wise queueing</Trace>
  </Trace>
After manual restart,
<Trace level="1" type="T">Async barrier reached. Bye-bye !</Trace>
  <Trace level="1" type="T">----
</Trace>
  <Trace level="1" type="B" name="CL_XMS_MAIN-WRITE_MESSAGE_TO_PERSIST" />
- <!--  ************************************
  -->
  <Trace level="3" type="T">Persisting message Status = 012</Trace>
  <Trace level="3" type="T">Message version 003</Trace>
  <Trace level="3" type="T">Pipeline CENTRAL</Trace>
  <Trace level="1" type="B" name="CL_XMS_MAIN-RESTART_ERROR_MESSAGE" />
- <!--  ************************************
  -->
  <Trace level="3" type="T">Trace object available again now. OK.</Trace>
  <Trace level="3" type="T">manual Restart Flag X</Trace>
  <Trace level="3" type="T">Message Guid 64B3B5B0AA3211DFCEE100144F64B6EF</Trace>
  <Trace level="3" type="T">Version 000</Trace>
  <Trace level="3" type="T">Pipeline ID CENTRAL</Trace>
  <Trace level="3" type="T">EOIO Force I</Trace>
  <Trace level="3" type="T">Restart Trace</Trace>
  <Trace level="3" type="T">Message was read from persist layer. OK.</Trace>
  <Trace level="3" type="T">Message properties in XMB object were setup. OK.</Trace>
  <Trace level="3" type="T">Error of the prevous version:</Trace>
  <Trace level="3" type="T">Area</Trace>
  <Trace level="3" type="T">Error ID</Trace>
  <Trace level="3" type="T">Restart of Queue?</Trace>
  <Trace level="1" type="T">Persisting message with status ManualRestart, version: 003</Trace>
I can find this trace message for all the scheduled messages.
<Trace level="2" type="T">Leave pipeline processing after LR because of receiver-wise queueing</Trace>
Can you guys help to understand why this is happening and what could be the root cause?
thanks in advance.
Regards,
Ravi

Answer 1

Hi all,
Thank you very much for the feedbacks.
Please allow me to ask few more questions.
1. How does the RSQIWKEX work? The purpose of the report is to reset the queue. If the queue is reset what will happen to the messages which are struck?
2. What is the difference between resetting the queue and restarting the messages?
3. If the message in the queue is failed due to genuine reason, if the report reset or restart the message, will it again block the queue, since the message will fail again? How this scenario will be handled by report?
4. Probably a very basic question, if a queue is retrying for a message or closed saying SYSFAIL, Will not PI automatically use another queue to process the rest of the messages since the QoS is EO? Why the messages are getting pilled up in the same queue?
Thanks in advance for your effort.
Best regards,
Ravi