Monitoring of the Queue Status

Queue transmission process can be monitored in transactions SMQ1 (outbound queues) and
SMQ2 (inbound queues). All the error messages appearing in these monitors should be analyzed
and resolved as soon as possible in order to complete data transmission within the necessary
time frame and to avoid delay or cancellation of succeeding jobs.

Monitoring of the Outbound Queues-> Transaction SMQ1

Transaction SMQ1 offers options for monitoring of specific queues, specific destinations, hanging
queues or any combination of these criteria.
Call Transaction SMQ1. On the following screen, you can enter the queue name and the queue
destination.

To view the specified queue, choose

Execute. To display only those queues that have errors,
choose Waiting Queues Only.
The following screen will display all the outbound queues in the system.

The following Operations can be performed on a particular queue by selecting it and displaying its
contents.

a)
b)
c)
d)
e)

Manually activation of the Queue

Locking and Unlocking of queue
Lock Queue Immediately
Unlock without activating
Delete queue

We can directly view the queues with errors by using the Change View button
Operation and error statuses in the Status column for each entry:
READY If you monitor this status for more than 30 minutes, clear with the functional team
whether the queue can be activated explicitly. The reason is that the queue was locked manually
via transaction SMQ1 or via a program and then unlocked without being activated.
RUNNING If you monitor this status for more than 30 minutes, clear with the functional team
whether the queue can be activated explicitly. The reason is that the work process responsible for
sending this LUW (Logical Unit of Work) has terminated. Note that activating a queue in status
RUNNING may cause a LUW to be executed several times if this LUW is processed in the target
system at that.

Brief Note on LUW: - LUW is the acronym for Logical Unit of Work. All queued RFCs
with a single destination that occur between one COMMIT WORK and the next belongs
to a single LUW.

EXECUTED - If you monitor this status for more than 30 minutes, clear with the functional team
whether the queue can be activated explicitly. The reason is that the work process responsible for
sending this LUW has terminated. In contrast to status RUNNING, this current LUW has definitely
been executed successfully. The qRFC Manager will automatically delete the LUW already
executed and send the next LUW.
SYSLOAD - At the time of the qRFC call, no DIA work processes were free in the sending system
for sending the LUW asynchronously. A batch job for subsequent sending has already been
scheduled.
SYSFAIL - A serious error occurred in the target system while the first LUW of this queue was
executed. The execution was interrupted. When you double-click on this status, the system
displays an error text. You can find additional information on this error in the corresponding short
dump in the target system (ST22). No batch job is scheduled for repetition and the queue is no
longer processed. To solve the problem, information from the affected application is required.
CPICERR - During transmission or processing of the first LUW in the target system, a network or
communication error occurred. When you double-click on this status, the system displays an error
text. You can find additional information on this error in the system log (SM21). Depending on the
definition in transaction SM59 for the destination used, a batch job is scheduled for subsequent

sending. Status CPICERR may also exist although no communication error has occurred. A
qRFC application finds out that a LUW cannot be processed any further due to a temporary error
in the application. Therefore it calls the RESTART_OF_BACKGROUNDTASK function module to
prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in
accordance with the specification in transaction SM59. In this case, qRFC simulates a
communication error with the text "Command to tRFC/qRFC: Execute LUW once again". If this
error often occurs, contact the corresponding functional team.
STOP - On this queue or a generic queue (for example BASIS_*) a lock has been set explicitly
(SMQ1 or programs). Note that the qRFC never locks a queue in processing. Clear with
functional team whether the queue can be activated using transaction SMQ1.
WAITSTOP - The first LUW of this queue has dependencies to other queues, and at least one of
these queues is currently still locked.
WAITING - The first LUW of this queue has dependencies to other queues, and at least one of
these queues contains other LUWs with higher priorities.
NOSENDS - During the qRFC call, the application determines that the current LUW is not being
sent immediately. This error is used to debug the execution of an LUW via transaction SMQ1.
Investigate the application calling this qRFC or contact the appropriate functional team to clarify
this status since this is either a programming or configuration problem.
WAITUPDA - This status is set if qRFC is called within a transaction that also contains one or
more update functions. As a result of this status, the LUW and thus the queue is blocked until the
update has been completed successfully. If this status takes longer than a few minutes, check the
status of the update or the update requests using transaction SM13. After a successful retroactive
update, the blocked LUW is sent automatically. Clear with functional team whether the LUWs can
be restarted manually in the WAITUPDA status without a successful retroactive update (via
transaction SMQ1 ->Reset status -> Activate queue). This WAITUPDA problem may be
avoided if both qRFC calls and update calls occur within a transaction, qRFC must be executed
exclusively within the update. In this case, the qRFC LUW is only created after the update has
been completed successfully.
ARETRY - During LUW execution the application has diagnosed a temporary problem and has
prompted the qRFC Manager in the sending system via a specific qRFC call to schedule a batch
job for a repetition on the basis of the definition in transaction SM59.
ANORETRY - During LUW execution, the application has found a serious error and prompted the
qRFC Manager via a specific qRFC call to cancel processing of this LUW. Information from the
affected application is required to solve the problem.
MODIFY - Processing of this queue is temporarily locked as the LUW data is being modified.

Monitoring of the Inbound Queues-> Transaction SMQ2

Call transaction SMQ2. On the following screen, you can enter the queue name.

To view the specified queue, choose

choose Waiting Queues Only.

Execute. To display only those queues that have errors,

Transaction SMQ2 offers the same monitoring options as SMQ1 with small differences in the
possible status. The status READY, RUNNING, SYSFAIL, CPICERR, STOP, WAITSTOP,
WAITING, ARETRY, ANORETRY, MODIFY have the same meaning as for outbound queues but
consider queue processing instead of queue sending.
One additional status message displayed only for Inbound queues is NOEXEC.
NOEXEC - During the qRFC call, the functional team determines that the current LUW is not
processed automatically even if the queue to the QIN Scheduler (SMQR) is registered. This
information is used to debug the execution of an LUW via transaction SMQ2. Contact the
corresponding qRFC functional team to clarify this status since this is either a programming or
configuration problem.