In general these alarms are usually due to an environmental issue which is preventing the spooler probe from accessing one of these queue files. The out-queue corresponds to the q2.rdb file. The spooler will not clear this alarm, even if the condition that causes the alarm to be generated in the first place is cleared on the robot. If you continue to receive alarms and QoS from this robot and you see that the \Nimsoft\robot\q1.rdb file is not continuously growing in size, then the intermittent problem is most likely environmental.
It is advisable to have the robot System admin check for these common causes for this alarm:
- There is no hard drive space on the robot disk volume or the drive is read-only
- The robot does not have proper permissions
- There are 2 spooler services running
- There is AV software scanning/locking the files in the nimsoft directory which is preventing the spooler service from functioning correctly.
- (you must create a full exception for all UIM/Nimsoft programs on the robot)
- There is a file system problem on the system where the robot is installed
- Backup software is locking the files
On the other hand, if you are not receiving any messages from the robot generating the alarm and the q1.rdb file is growing in size, it may mean that the q2.rdb file is corrupted. To look into this further:
1. Stop the Nimsoft Robot Watcher service on the robot
2. Save off a copy of the q2.rdb file and remove it from the \Nimsoft\robot directory
3. Start the Nimsoft Robot Watcher service
The spooler will create a new q2.rdb file and if the problem was due to a corrupted q2.rdb file, messages should start flowing again.
An analysis of the archived q2.rdb may show corrupt data via illegal characters which could have been disrupting the normal data flow.