Robot will not leave legacy maintenance when set from the controller GUI Status Tab
search cancel

Robot will not leave legacy maintenance when set from the controller GUI Status Tab

book

Article ID: 125319

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Using IM, devices or servers were placed into maintenance but it could not be cancelled.




The robot would not come out of or stop maintenance.


Environment

  • DX UIM 8.5.1 or higher
  • Tested in UIM 20.4 CU6 and CU7

Cause

  • Type of maintenance being used Legacy (controller) versus UMP (USM) or OC

Resolution

Maintenance Mode

There are two types of maintenance mode:

1. Legacy

The first type is the "older" legacy kind of maintenance, and it is accessed in the Infrastructure Manager, and puts the robot itself into a 'maintenance mode' status.
This mode actually suspends the probes on the robot and this stops QOS. This type of maintenance has nothing to do with the maintenance_mode probe at all.

Normally you can select the Status Tab within the controller probe and rt-click on the status icon and select "Leave suspend mode now"

or

Rt-click on the Hub in the IM and select Maintenance then "Leave maintenance now" then click 'Yes,' and choose View->Refresh in the IM.




After following the steps above, if the robot does not stop/leave maintenance, then try the following to force the robot to exit out of maintenance:

When setting a Robot using "Legacy" maintenance, it seems that 2 lines are added to the robot.cfg.

For example:

maint_from = 0
maint_until = 1684423791

To FORCE the robot to leave 'legacy-type' maintenance, simply do the following:

1. Edit the robot.cfg
2. Remove the two additional lines concerning maintenance
3. In IM-> RT-click and restart the robot
4. In IM->Click View->Refresh
5. Robot will turn green again and exit maintenance state


Note that legacy maintenance could be adversely affected if one or both of the following is true:

   a. controller is up but hdb and spooler are not running

       - Stop and start the robot and run ps -ef | grep nim to ensure that the controller AND the hdb and spooler processes are up and running.
       - Test legacy maintenance -> suspend robot and then verify function and then unsuspend and everything should now work as expected.

   b. robot.cfg is corrupted/truncated

      - One symptom could be - no robot nor probes show up in the IM and as a result, the window where probes normally show is empty.
      - Correct/replace the robot.cfg and restart the robot.
      - Test legacy maintenance -> suspend robot and then verify function and then unsuspend and everything should now work as expected.


2. UMP (USM) / Operator Console (OC)

The second type is the maintenance mode in UMP/OC. The design of this type of maintenance mode is only to suppress alarms related to the host which is in maintenance. The infrastructure Manager does not "know about" this type of maintenance and there is no functionality in IM to reflect robots that are in this type of maintenance status.

Note that you can run the following query which will tell you what robots/devices are currently in maintenance from UMP's (USM) / Operator Console perspective:

select distinct cs.name, cs.ip, cs.origin, ms.SCHEDULE_NAME, ms.DESCRIPTION, CONVERT(VARCHAR(50), mw.START_TIME,100) as 'Start Time', CONVERT(VARCHAR(50), mw.END_TIME, 100) as 'End Time' from CM_COMPUTER_SYSTEM cs
INNER JOIN MAINTENANCE_SCHEDULE_MEMBERS msm
ON cs.cs_id=msm.CS_ID
INNER JOIN MAINTENANCE_WINDOW mw
ON msm.SCHEDULE_ID=mw.SCHEDULE_ID
INNER JOIN MAINTENANCE_SCHEDULE ms
ON msm.SCHEDULE_ID=ms.SCHEDULE_ID
WHERE mw.END_TIME >=GETDATE()

We recommend using UMP (USM) / Operator Console (OC) maintenance mode and not the legacy type that relies upon the controller.