It Says Retry. Nobody Scheduled Anything.

Leer este post en español →

Two queues, same warehouse, same morning. Both red in the monitor. Both showing an error text about repeating the unit of work later.

One of them will clear on its own before lunch. The other will still be sitting there in March, and every day somebody will look at it, read the word about repeating, and decide to give it a bit longer.

The difference between those two queues is not in the error text. It is not in how long they have been waiting, or how many entries they hold, or what the application was trying to do. It is one word in the status column, and it answers a question almost nobody thinks to ask:

Did anybody actually schedule a retry?

Because a queue does not retry out of optimism. A retry is a batch job, scheduled by the qRFC manager, on the basis of a setting somebody made in a specific place. If no job was scheduled, nothing is going to happen — not today, not in March. The queue is not being patient. It is finished, and it is red, and those look identical from a distance.

Nobody Retries Anything Without a Job

The first post in this series dealt with a queue that was quietly holding a document nobody was looking for. This one is the opposite situation: everybody is looking at it, and everybody is reading it wrong.

When an application hits a problem while a unit of work is being executed — an LUW, which is how it is spelled in every status text and button you are about to meet — it does not simply fail. It tells the qRFC manager what kind of problem it was, and that decision propagates into the status you see:

If the application says this is temporary, the qRFC manager schedules a batch job for another attempt.
If the application says this is serious, the manager cancels the unit of work and no job is scheduled.
If the target system raises a serious error while executing the first unit of work, execution is interrupted, no job is scheduled for a repetition, and the queue is no longer processed at all.

Three outcomes, three different futures, and the only place that distinction is recorded is the status. Read it as a label and you learn nothing. Read it as a signature — who decided, and what they decided — and it answers the question in about four seconds.

The Status Is a Signature

Here is the whole thing on one table. Find your status on the left; the last column is whether waiting will ever help.

Two rows in that table are worth stopping on, for opposite reasons.

SYSFAIL is the one that costs weeks. It is the most common status on a queue that everybody believes is retrying, and it explicitly means the opposite: execution was interrupted, nothing was scheduled, and the queue has stopped. Double-clicking the status gives you the error text. Often the detail behind it is a short dump in the target system — exactly the header the previous post taught you to read. When ST22 has nothing, the detail is somewhere else: the message itself in table T100, or the application log in SLG1, which is the route the first post walks through. An empty ST22 is not evidence that there is nothing to find.

WAITUPDA is the one that resolves itself while you are still typing the ticket. The unit of work is blocked until an update completes. If it sits there more than a couple of minutes, the thing to check is not the queue at all — it is the update request in SM13, which is where an update termination lives.

The Communication Error That Is Not a Communication Error

This is the part of the post worth the whole post.

CPICERR reads like a verdict: a network or communication error occurred during transmission or processing. It sends tickets to Basis. It starts conversations about firewalls and gateway timeouts and whether something changed on the network last Tuesday.

And sometimes none of that happened.

When a qRFC application discovers that a unit of work cannot be processed further because of a temporary problem in the application, it calls the function module RESTART_OF_BACKGROUNDTASK. That prompts the qRFC manager to cancel the execution and repeat it later according to the destination settings. And to express that, qRFC simulates a communication error.

Not reports one. Simulates one. Complete with a status text:

That sentence is the tell. It is not the sound of a network failing. It is an application saying «not now, ask me again later», wearing a communication error as a costume because that is the only way qRFC has of expressing it.

You may have met that sentence before, under another label. The first post in this series found it on a queue sitting in RETRY. That is not a contradiction: the wording tells you that an application asked for another attempt, and nothing more. Which status it arrives under is what tells you how the qRFC manager recorded that request, and therefore what rules the repeat is running under. The text is the plea. The status is the ruling.

That recurring one is the queue the previous post pointed at: not stuck, but failing over and over with the same entry. It is the loud failure, and loud failures get fixed eventually, because somebody gets tired of them. The one that costs you a quarter is its silent twin — the queue that never asked for a repeat at all, and has been sitting there since March looking exactly the same.

The practical consequence is a routing decision, and it is worth getting right the first time. A genuine CPICERR belongs with Basis, and the detail lives in the syslog and the RFC traces. A simulated one belongs with the functional team that owns the application, and no amount of network investigation will ever find anything — because there is nothing there to find.

Where the Retry Schedule Actually Lives

If a repeat was scheduled, something decided how often and how many times. That definition is not in the queue and not in the monitor. It is on the RFC destination:

SM59 → the destination → Destination menu → tRFC Options

This matters because «it will retry» is not a property of the error. It is a property of that destination, and it has an end. A queue in a retry status is not retrying forever — it is retrying according to values somebody set, possibly years ago, possibly by default, almost certainly never revisited.

That destination is also what resolves the depends in the CPICERR row. It carries both the number of attempts and a flag that suppresses the background job when a connection error occurs. With that flag set, a communication error schedules nothing at all — and the queue that looks like it is waiting for the network is waiting for nobody.

Before you tell anyone how long to wait, go and read those values. It converts «give it a while longer» into an actual number, and it is the difference between a status update and a guess.

Two Levels, One Red Light

There is a second failure that looks exactly like the first from where you are sitting, and it is not the queue at all.

The queue is one object. The scheduler that processes queues is another. Inbound queues are driven by the QIN scheduler and outbound ones by the QOUT scheduler, and those schedulers have their own statuses — including their own SYSFAIL and their own communication errors, entirely independent of any individual queue.

The distinction changes what you look at:

One detail worth carrying: after a scheduler problem is solved, the outbound scheduler does not automatically restart the units of work of the registered destination. Queues left in SYSFAIL have to be reset by hand. So a fixed scheduler and a still-red queue is a normal state, not a sign that the fix did not work.

The reference for what each status means across both monitors is SAP Note 378903. For the inbound scheduler specifically, SAP Note 1579728. Worth having both open the first time you do this.

When You Genuinely Need to Watch It Happen

Sometimes the status text is not enough and you need to be inside the unit of work while it executes. There is a supported way to do that, and it is a user parameter rather than a transaction — set under User Profile → Own Data:

Note which way round this works: the parameter goes in one system and the queue stops in the other.

The Order to Do This In

The whole method, for when somebody stops you with «the queue is stuck»:

1. Read the status, not the error text. The text tells you what happened. The status tells you whether anything is going to happen next.
2. Is a retry job scheduled at all? SYSFAIL and ANORETRY mean no. Stop waiting immediately.
3. If it says CPICERR, read the status text. If it asks to execute the unit of work once again, this is the application, not the network. Route it accordingly.
4. If a repeat is scheduled, go and read the destination. Attempts and interval live in tRFC Options, and they end.
5. If everything is red at once, look at the scheduler, not at the queues.
6. Only then reset anything — and one queue at a time, never in bulk.

And if SMQ1 and SMQ2 are not yours to touch, most of this is reachable from the message queue node of the warehouse management monitor, /SCWM/MON — the same queues, the same statuses, and a Reset Status function, without a Basis role.

Steps 1 and 3 resolve most of these. The value is not that they are clever; it is that they happen before somebody has spent a day on the wrong system.

The Shape of This Problem

The first post was about an absence: nothing to read, and a document waiting where nobody looks. The second was about noise: four hundred lines of it, and five that mattered.

This one is a third shape, and the most expensive of the three, because it does not look like a failure at all. It looks like progress. A queue that says it will try again is a queue that seems to be handling itself, and the natural response to something handling itself is to leave it alone.

So the habit is small and slightly contrarian: when a queue tells you it is going to retry, check that somebody scheduled it. Most of the time they did. The times they did not are the ones that cost you a quarter.

Next in this series: the status that is not a failure at all. STOP does not mean something broke — it means somebody, or something, locked the queue deliberately, and the lock outlived the reason for it. We will look at where those locks come from, why an abandoned debugging session leaves one behind, and how to tell a queue somebody is working on from one everybody forgot.

Related Reading

• Nothing Errored. Nothing Failed. Your Delivery Just Never Arrived. — the same queues, read for a different question: which document is trapped in there, and where the error text actually lives.
• Who Is the Master for Stock Quantities: EWM or ERP? — what these queues are carrying between the two systems, and which side owns the number when they disagree.
• SAP EWM Movement Type 561: Two Roads Into the Warehouse — a posting that can arrive by two different routes, and the mapping row whose absence stops it without any error at all.

---