cancel
Showing results for 
Search instead for 
Did you mean: 

Message in scheduled state

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Ravi,

First you have to register the queues.Pls follow the path

SXMB_ADM->Manage queues->Register Queues->Activate queues.

Once u register the queues automatically it will move from SMQ1 and SMQ2.

Thanks

Ravi

Former Member
0 Kudos

Hi

Thanks for your feedback.

Chirag >> Yes, i did check that, there are some messages struck in SMQ2. But, i am bit confused with the status message and queue name convention. As per my understanding the inbound queue names for EO would be XBTIx and outbound queue naming would be XBTOx. However, the inbound queue names what i see in SMQ2 starts with XBTOx and the status message says 'Scheduled for outbound processing'. Can you explain this context please?

Ravi >> I will check this out, btw, if the queue is not activated, how come after the manual restart, the message is getting processed?

Regards,

Ravi

Edited by: Jambunathan Ravikumar on Aug 25, 2010 1:00 PM

Shabarish_Nair
Active Contributor
0 Kudos

ideally, its best to do a registration and activation of the queues.

another thing is in sxmb_adm -> manage queues -> qrfc monitor check if the scheduler status is fine.

Also in DB02 check if there is a table space issue. When the table space gets filled up there are issues noticed in the queues

former_member186021
Participant
0 Kudos

About the queue name convention, you can have a look at this thread:

BR,

Winters

Former Member
0 Kudos

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

santhosh_kumarv
Active Contributor
0 Kudos

Hi,

How did you manage this issue? I'm also experiencing the same issue, no entries in the queue but the message status is scheduled in Message branch step.

~SaNv...

Former Member
0 Kudos

check whether any message got stuck in SMQ1 and SMQ2 tcode and reason behind it.

chirag