unCoreInternals 9.3.0
unManagerState Developers Notes

First note

The loop that performs checks every X seconds was introduced after discarding the use of dpConnect/dpDisconnect that in theory would determine if a manager that was in manual mode changed from not running to running (or vice versa). The problem was that the process of managers being added/removed from the _Connections datapoint was faster than the connection/disconnection of the managers in the console. This mean that there were scenarios where the alarm would remain unchanged when it should not have been the case.

Second note

The changes in manual modes (Always, Manual, Once) are tracked using the sysConnect function with the path to the progs file as parameter. Therefore, a change in the status of the mode of a running manager is checked immediately.

Third note

When the apply button is clicked on the manager filter list of the System Integrity Configuration panel, a call to check the state of the alarms is performed. Therefore, pressing the apply button also performs an immediate check of the status of the managers.

Fourth note

In the Application Operation panel, additional information for the managers running in manual mode can be displayed. To be able to do it, first the alarm must be in Bad status. Then, after right clicking on the state or description text of the unManager State alarm, a cascade menu is invoked. The manager table with information about the manager’s types and numbers running in manual mode is displayed when clicking on the first option, i.e., the option containing the description text. The logic behind shown on this manager table is as follows: In the unSystemIntegrity_unManagerState.ctl script, in the unSystemIntegrity_unManagerState_statusChanged function, there is a call to unSystemIntegrity_unManagerState_raiseAlarm. Inside, the manager type and number information is obtained using the pmonGet functions, and added to a dyn_string variable that contains the list of managers that are running in manual mode and specified within the manager filter. This dyn_string variable is then passed as parameter to unSystemIntegrity_unManagerState_writeErrorCode and stored on the ._comment of the alert handler using alertSet. In the RightMousePressed event of the applicationDPEList table in the applicationOperationDetail.pnl panel, the value is then retrieved using alertGet and passed to ChildPanelOnCentral to open the systemIntegrity_unManagerState_managersTable.pnl panel with the managers information.

Fifth note

In the unSystemIntegrity.postInstall script, there is a check in place that sets the manager filter list with the default manager types if it had never been done before (first-and only-time configuration). The condition has been implemented in this way to avoid rewriting the user configuration of the filter in case that the unManagerState implementation was already installed and a configuration was already in place.