What I ran into
I hit a situation where MonCon stopped responding, and I couldn’t stop the IBM i Change Selector from there. The request would hang, and eventually I would see a timeout like “Request timed out after 300 seconds.”
In my case, the source system was not reachable, but I’ve seen similar behavior when there are connectivity or credential issues.
What actually helps first
The first thing I try now is simple:
I’ve seen cases where MonCon itself is the issue, not the replication model.
When MonCon still cannot stop it
If stopping the Change Selector from MonCon does not work, the control has to move to the IBM i side.
Here is what worked for me:
- Identify the Change Selector jobs (RPCS400) on IBM i
- Use the green screen to find the right job
- End the job directly using ENDJOB
- Use *IMMED when needed for faster stop
To identify the correct job, I typically check locks on the metabase library and trace the associated RPCS400 jobs.
Once the job is ended, the Change Selector stops even if MonCon is unresponsive.
If the kernel itself is unreachable
In a few cases, I could not even shut down the kernel from MonCon.
What helped then:
- Stop all other kernels if needed
- Go to the machine where the Listener is running
This brings down all kernels under it, including the stuck one. After that, I bring things back up in a controlled way.
Useful trick while debugging
One thing I found really helpful during troubleshooting:
- Create a file called
CSSwitchFile.txt in the kernel directory
This prevents the Change Selector from starting automatically. It is useful when trying to drain queues or debug startup issues.
Once done, just delete the file to restore normal behavior.
What changed for me
I used to think MonCon was the only control point.
This made it clear that:
- MonCon is just one interface
- The actual control still exists at the system and job level
Knowing when to switch from MonCon to IBM i commands makes a big difference during outages.
Takeaway
If you cannot stop a Change Selector from MonCon, it usually means control needs to shift closer to the source system.
Understanding where the process actually runs makes it much easier to recover quickly.
Have you run into cases where MonCon was up but you still had to control things directly from IBM i?
*Precisely Software Inc.