Contents

1   Introduction

This instruction concerns alarm handling.

1.1   Alarm Description

The alarm is a primary alarm. The alarm is issued by the service Availability Management Framework (AMF) of the Core Middleware (Core MW) component, which is not modeled as a Managed Object (MO).

The AMF is responsible for assigning active or standby workloads to software components in the managed element through Service Units (SUs). The SUs are logical aggregations of several software components. The alarm is issued when a particular workload can no longer be assigned to any SU.

The possible alarm causes and fault locations are explained in Table 1.

Table 1    Alarm Causes

Alarm Cause	Description	Fault Reason	Fault Location	Impact
Workload cannot be assigned to the SU.	No SU is ready for an assignment of the indicated workload.	A component refuses to switch to an active role or to a standby role. Processor reboot	Component. Processor	The service associated with the particular work assignment is disrupted.
The SU is Locked.	All SUs configured to execute the indicated workload are administratively locked.	At least one SU is directly or indirectly administratively locked.	The locking of the SU through an administrative operation.

Note:  

The alarm can appear as a result of an upgrade.

The alarm attributes are listed and explained in Table 2.

Table 2    Alarm Attributes

Attribute Name	Attribute Value
Major Type	18568
Minor Type	131077
Source	safApp=<*>,safSi=<*>
Specific Problem	COM SA, AMF SI Unassigned
Event Type	processingErrorAlarm (4)
Probable Cause	x736UnspecifiedReason (418)
Additional Text	SI designated by <LDAP DN of the SI> has no current active assignments to any SU
Perceived Severity	major (4)

1.2   Prerequisites

Before starting this procedure, ensure that the following documents have been read:

• System Safety Information
• Personal Health and Safety Information
• COM Management Guide

2   Procedure

This section describes the procedure to follow when this alarm is received.

2.1   Analyze Alarm

To analyze the alarm at the maintenance center:

1. Check if there is any SU or node related to the unassigned service:

   cmw-status node su

   If the command returns Status OK then no item is locked.

2. Do AMF SI Unassigned Alarms exist, even though cmw-status node su returns Status OK?

   Yes: See Section 2.4 Actions for Uninstalling Application Alarm.

3. Is an SU locked?

   Yes: See Section 2.3 Actions for Accidental Locking.

   No: See Section 2.2 Actions for Failure.

2.2   Actions for Failure

To deal with failure:

1. Consult the next level of maintenance support for an analysis of the root cause to why the Service Instance (SI) no longer has active assignments assigned to any SU.
2. When the cause has been identified, take relevant corrective measures. As a result, the alarm is automatically cleared.
3. Confirm that the alarm has ceased.

   If the alarm remains, consult the next level of maintenance support. Further actions are outside the scope of this instruction.

2.3   Actions for Accidental Locking

To undo accidental locking:

1. Log in to any server of the cluster as root:

   ssh -l <user><address>

2. Unlock the SU or node which prohibits the proxy to execute:

   cmw-utility immadm -o 1 <Managed Object>

   Parameter <Managed Object> is the distinguished name of the SU or node to unlock.

3. Confirm that the alarm has ceased.

   If the alarm remains, consult the next level of maintenance support. Further actions are outside the scope of this instruction.

2.4   Actions for Uninstalling Application Alarm

To cease an AMF SI Unassigned alarm that was raised when an application was uninstalled, and that yet persists when the application is reinstalled:

1. Cease the alarm manually:

   cmw–alarm–clear unassign <Managed Object>

   Here <Managed Object> is given by the field Managed Object class in the alarm.

2. Confirm that the alarm has ceased.

   If the alarm remains, consult the next level of maintenance support. Further actions are outside the scope of this instruction.