What caught me off guard
I was reviewing an IBM i environment recently and doing what I thought was a routine health check.
The Change Selector was running. No errors were visible. Everything looked healthy.
Yet no new changes were making their way through replication.
At first, I started looking for the usual suspects - queue issues, journal issues, connectivity issues. None of them seemed to fit what I was seeing.
The Change Selector was clearly running.
So why wasn't it capturing anything?
The clue was hiding in the status
The breakthrough came when I stopped looking at whether the Change Selector was running and started looking at what state it was running in.
That's when I noticed the status was Drained.
I had seen the status before but never paid much attention to it. A Change Selector in Drained state is still running - but it does not currently have any capture-enabled tables assigned to it. In other words, the process itself is healthy, but there is nothing for it to capture.
Why this mattered
What made this confusing is that "running" and "capturing" sound like they should mean the same thing.
They don't.
The Change Selector process can be fully operational while capture is disabled for the tables associated with it. From the process perspective, everything is functioning normally. From the replication perspective, nothing is moving.
Once I understood that distinction, the behavior made perfect sense.
The system wasn't broken. It was doing exactly what it had been told to do.
A troubleshooting lesson I kept
This ended up being one of those investigations where the status message was technically correct but easy to misinterpret.
I was asking: "Is the Change Selector running?"
The more useful question turned out to be: "Is the Change Selector running and does it have capture-enabled tables?"
Those are very different questions. That small distinction can change the entire direction of an investigation.
Where to get the full technical details
If you want to understand exactly what the Drained status means, what causes it, and the full steps to resolve it - including checking the RP_REGISTERED column in RP_REL and how to handle a missing or corrupted RPCS400_nn configuration file - both resources below cover it in detail:
Takeaway
A healthy process does not always mean active capture. The next time replication appears idle, it may be worth looking beyond whether the Change Selector is running and checking whether it actually has capture-enabled tables to process.
Have you ever chased a replication issue only to discover the Change Selector was healthy the entire time and the real clue was hiding in its status?
*Precisely Software Inc.