You are on page 1of 72

1.1.

FDS Alarms

1.1.1.1

DB Interface

1.1.1.1.1

Oracle user or password error


Description: the purpose of this test case is to verify the event DB
interface Oracle user or password error.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSS RC and EMA integration has been verified.
2) The Alarm DB interface Oracle user or password error has been
defined in EMA system monitor GUI.
Procedure: Follow the steps as below:
Action: Login to EMA server 1 as user Sogadm and stop PL
sogadm> emaserver domain PL stop
Result: PL stopped
Action: Edit /var/sog/data/database/FDS-PL.cfg and change the entry as
below:
sogadm> cd /var/sog/data/database
sogadm> cp p /var/sog/data/database/FDS-PL.cfg \
/var/sog/data/database /FDS-PL.cfg.<yyyymmdd>

sogadm> vi FDS-PL.cfg
<ProcLogDBLoginInfo>
<DBUser type="Search">
<DBUserName>emalogsearcher_wrongUserName</DBUserName>
<DBUserPassword>#000223303030317063666</DBUserPassword>
</DBUser>
<DBUser type="Operate">
<DBUserName>emalogoperator</DBUserName>
<DBUserPassword>#00022330303031706D72</DBUserPassword>
</DBUser>
<DBConnectStr>emalog</DBConnectStr>
</ProcLogDBLoginInfo>

Note: Original value of DBUserName is emalogsearcher.


<DBUserName>emalogsearcher</DBUserName>

ACTION: Restart PL and ProcLog cannot startup.


ProcessingLog is always "RECOVERING"

The status of

sogadm> emaserver domain PL start


sogadm> emaserver domain PL status
Result: The DBInterface:OracleUserPasswordError alarm received at
OSSRC and in the system monitor
Post requisite: To recover ordinary operational status, tester needs to
follow up the next steps.
1) Stop PL application using sogadm user.
sogadm> emaserver -domain PL stop
2) Recover FDS.cfg to original file and check whether DBUserName is
return to
original value (emalogseacher).
sogadm> cd /var/sog/data/database
sogadm> cp p FDS-PL.cfg.<yyyymmdd> /FDS-PL.cfg
sogadm> view FDS-PL.cfg
3) Restart PL application and confirm whether ProcLog can startup
properly.
sogadm> emaserver -domain PL start
sogadm> emaserver -domain PL status
1.1.1.1.2

Oracle connection string error


Description: The purpose of this test case is to verify the event DB
interface oracle connection string error.
Prerequisite: The following prerequisites need to be met prior to
execution of this test case.
1) OSS and EMA integration has been verified.
2) The alarm for DB interface oracle connection string error has been
defined in system monitor GUI.
Procedure: Follow the procedure as below:
Action: Login to EMA server 1 as user Sogadm and stop PL
sogadm> emaserver domain PL stop
Result: PL stopped

Action: Edit /var/sog/data/database/FDS-PL.cfg and change the entry as


below:
sogadm> cd /var/sog/data/database
sogadm> cp p /var/sog/data/database/FDS-PL.cfg \
/var/sog/data/database /FDS-PL.cfg.<yyyymmdd>

sogadm> vi FDS-PL.cfg

<ProcLogDBLoginInfo>
<DBUser type="Search">
<DBUserName>emalogsearcher</DBUserName>
<DBUserPassword>#000223303030317063666</DBUserPassword>
</DBUser>
<DBUser type="Operate">
<DBUserName>emalogoperator</DBUserName>
<DBUserPassword>#00022330303031706D72</DBUserPassword>
</DBUser>
<DBConnectStr>emalog_worngConnectStr</DBConnectStr>
</ProcLogDBLoginInfo>

Note Original value of DBConnectStr is emalog.


<DBConnectStr>emalog</DBConnectStr>

Action: Restart PL application and ProcLog cannot startup. The


status of ProcessingLog is always "RECOVERING"
sogadm> emaserver -domain PL start
sogadm> emaserver -domain PL status
Result: The DBInterface:OracleConnectionStringError alarm received at
OSSRC and in the system monitor
Post Requisite:To recover ordinary operational status, tester needs to
follow up the next steps.
1) Stop PL application using sogadm user.
sogadm> emaserver -domain PL stop
2) Recover FDS.cfg to original file and check whether DBConnectStr is
return to
original value (emalog).
sogadm> cd /var/sog/data/database
sogadm> cp p FDS-PL.cfg.<yyyymmdd> FDS-PL.cfg
sogadm> view FDS-PL.cfg
3) Restart PL application and confirm whether ProcLog can startup properly.

sogadm> emaserver -domain PL start


sogadm> emaserver -domain PL status

1.1.1.1.3

Oracle server unavailable error


Description: The purpose of this test case is to verify the event oracle
server unavailable error.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC and EMA integration has been verified.
2) The Alarm DBInterface:OracleServerUnavailableError has been
defined in EMA System monitor GUI.
Procedure: Follow the procedure as below:
Action: Log on EMA as emadba user and execute the following
commands to login to sqlplus
tyEMA01:~ # su - emadba
emadba@tyEMA01:~> export ORACLE_SID=emadb
emadba@tyEMA01:~> sqlplus / as sysdba
Result: The following result is displayed, which indicates connected to
sql plus
SQL*Plus: Release 11.2.0.3.0 Production on Tue Oct 30 15:45:54 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit
Production
With the Partitioning, OLAP, Data Mining and Real Application Testing
options

SQL>
Action: Execute the below command to lock the EMALOGSEARCHER
account
SQL> alter user EMALOGSEARCHER account lock;

Logon PN as sogadm user and restart ProcLog:


sogadm> emaps -k PROCLOG
Result: The DBInterface:OracleServerUnavailableError alarm received
at OSSRC and in the system monitor
Post
requisite:
After
DBInterface:OracleServerUnavailableError,
EMALOGSEARCHER account

raising
logon RN

and

alarm
unlock

# su emadba
emadba@tyEMA01:~> export ORACLE_SID=emadb
emadba@tyEMA01:~> sqlplus / as sysdba
SQL> alter user EMALOGSEARCHER account unlock;

1.1.1.2

FDS Core

1.1.1.2.1

To verify Event Reciever connection


Description: The purpose of this test case is to verify thae alarms
raised with the event Reciever connection. This test cases is under
discussion.

1.1.1.3

MO Handler

1.1.1.3.1

Routing failed
Description: The purpose of this test case is to verify event MOHandler:
RoutingFailed.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified
2) The Alarm MOHandler:RoutingFailed has been defined in EMA
System monitor GUI
Procedure: Follow the procedure as below:
Action: Login to PL admintool GUI from PN and select component
Controller. Stop Procengine component in the processing via the GUI
Result: Procengine component stopped successfully.
Action: Prepare a temporary xml request

#su sogadm
sogadm> echo '<Request MO="Sog.Cluster" Operation="Get"
SessionId=""></>' > /tmp/cluster.get.xml
Action: Send the request to procengine as a sogadm user
sogadm> xmlsend -domain PL /tmp/cluster.get.xml
Action: After seen the Alarm start the procengine component again and
Check the status of EMA for all active and online
# su sogadm
sogadm> emaserver domain PL status
Result: The MOHandler:RoutingFailed alarm received at OSSRC and in
the system monitor
1.1.1.3.2

Registration warning
Description: The MO name is already registered in the FDSServer
process with the same address. This is a warning that a plug-in client has
not properly unregistered its MO interface from the FDSServer process.

Prerequisite: The following prerequisite needs to be met prior to


execution of this test case:
1) The OSSRC & EMA integration has been verified
2) The Alarm MOHandler:RegistrationWarning has been defined in
EMA System monitor GUI.
Procedure: Follow the procedure as below:
Logon to EMA as sogadm user and restart ProcLog:
sogadm> emaps -k PROCENGINE
Result: The MOHandler:RegistrationWarning alarm received at OSSRC
and in the system monitor
1.1.1.3.3

Invalid registration
Description: The MO name is already registered in the FDSServer
process with another address. It happens when two plug-ins try to use
the same MO name. The plug-in that uses an existing MO name with
another address fails to register and may not be created properly.

Prerequisite: The following prerequisites need to be met prior to


execution of this test case:
1) The OSSRC & EMA integration has been verified
2) The Alarm MOHandler:InvalidRegistration has been defined in EMA
System monitor GUI.
Note: Make sure there's no NHFValidator on FDS-PL.cfg before this test
case.
Procedure: Logon EMA as sogadm user and stop PL application.

sogadm> emaserver domain PL stop


Result: PL stopped.
Action: Edit the file /var/sog/data/database/FDS-PL.cfg. Add a new line
in
<FDSMOHandler></FDSMOHandler> segment as below:
sogadm> cd /var/sog/data/database
sogadm> cp p /var/sog/data/database/FDS-PL.cfg \
/var/sog/data/database /FDS-PL.cfg.<yyyymmdd>
sogadm> vi FDS-PL.cfg
<Subscriber MOName="NHFValidator" \
MOAddress="DefaultMO:NHFValidator/2.0"></Subscriber>
Action: Restart PL application
sogadm> emaserver -domain PL start
Action: Create Component NHFValidator by sogadm user.
sogadm> cd /var/sog/data/xml/component_requests/fast
sogadm> xmlsend -domain PL 2007_FSC-NHFValidation.xml
Result: The following error message will receive.

<?xml version='1.0' encoding='ISO-8859-1' standalone='no'?>


<Response>
<Error>
<Code>2002</Code>

<Reason>Failed to create the following plugin: \


NHFValidator/1.0/A/1 \
Undo successful \
Failed to call initialize at level 2.\
Missing configuration</Reason>
</Error>
</Response>
The MOHandler:InvalidRegistration alarm received at OSSRC and in the
system monitor
Post requisite: To recover ordinary operational status, tester needs to
follow up the next steps.

1) Stop PL application using sogadm user.


sogadm> emaserver -domain PL stop
2) Recover FDS.cfg to original file and check there's no NHFValidator.

sogadm> cd /var/sog/data/database
sogadm> cp p FDS-PL.cfg.<yyyymmdd> FDS-PL.cfg
sogadm> view FDS-PL.cfg

3) Restart PL application and confirm whether ProcLog can startup


properly.

sogadm> emaserver -domain PL start


sogadm> emaserver -domain PL status
1.1.1.3.4

Correct registration
Description: A successful registration of an MO in the MOHandler.
Prerequisite: The following prerequisites needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm MOHandler:CorrectRegistration has been defined in EMA
System monitor GUI.
Procedure: Perform the steps as below:
Action: Telnet to EMA PN node as sogadm user and re-start the FDS
server component
sogadm>emaps -k FDS-PL

Result: FDS-PL is killed


Action: Check that the all the plugin in the PL has become active
sogadm> emaserver status
Wait until all the plugins become active before go to the next test case.
Result: The MOHandler:CorrectRegistration alarm received at OSSRC
and in the system monitor
1.1.1.3.5

Correct unregistration
Description: A successful Unregistration of an MO in the MOHandler.
Purpose of this test case is whether OSS-RC can show the alarm slogan
properly.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm MOHandler:CorrectUnRegistration has been defined in
EMA System monitor GUI.
Procedure: Follow the below procedure:
Action:
Check
current
ESA
(FDSAuthority:UserNotAllowed
FDSConfigurationManager:NotificationWarning) using
command.

configuration
and
the following

# /opt/sog/bin/alarmmapping l

Revise the configuration to generate fake alarm


# /opt/sog/bin/alarmmapping m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
MOHandler:CorrectUnRegistration

Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:


MOHandler:CorrectUnRegistration
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Note: After tester follow up above procedure, OSS-RC will detect Cold
restart event (Warning) because it is updated about alarm configuration
at EMA AS. Please ignore such event on OSS-RC.
Action: Generate the fake alarm by sogadm user using following
procedure towards OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The MOHandler:CorrectUnRegistration alarm received at
OSSRC and in the system monitor
Post requisite: After this test case finish, test engineer needs to return
to original configuration as follows.
# /opt/sog/bin/alarmmapping m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription
[MOHandler:CorrectUnRegistration]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[MOHandler:CorrectUnRegistration]:
FDSAuthority:UserNotAllowed

Please input ituAlarmEventType [10]: 10


Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping l
Then,
need
to
check
whether
original
(FDSAuthority:UserNotAllowed) can see on OSS-RC

alarm

# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
1.1.1.3.6

Invalid unregistration
Description: The MO name is already unregistered in the FDSServer
process.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm MOHandler:InvalidUnRegistration has been defined in
EMA System monitor GUI.
Procedure: Open admintool at PN as sogadm user and send a request
like this (unregister one MO which actually doesnt exist)
<Request MO=FDSController Operation= _-_UnregisterMO_-_ SessionId=>
<Name>abc</Name>
</>

Result: The MOHandler:InvalidUnRegistration alarm received at OSSRC


and in the system monitor

1.1.1.4

FDS configuration manager

1.1.1.4.1

Write warning
Description: The FDS Configuration Manager fails to write its
configuration to the local disk.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSConfigurationManager:WriteWarning has been
defined in EMA System monitor GUI.
Procedure: Follow the below procedure
1) Login to one EMA as sogadm user, Remove FDS-PL.cfg and
create a folder having the same name
sogadm> cd /var/sog/data/database

sogadm> mv FDS-PL.cfg FDS-PL.cfg.bak


sogadm> mkdir FDS-PL.cfg
2) Open admintool and modify the setting of CAI component, e.g.,
modifying
CAI IdleTimeout from 86400 to 300
Result: The FDSConfigurationManager:WriteWarning received at
OSSRC and in the system monitor
Post requisite: To recover ordinary operational status, tester needs
to follow up the next steps.
1) Remove FDS-PL.cfg
sogadm> cd /var/sog/data/database
sogadm> rm -rf FDS-PL.cfg
2) Open admintool and modify the setting of CAI component, e.g.,
modifying
CAIIdleTimeout from 300 to 86400
In admintool, change the CAI Idle Timeout back to 300. A new
FDS-PL.cfg will be created automatically.
1.1.1.4.2

Notification warning
Description: Cannot notify subscriber interface in the component.
Purpose of this test case is whether OSS-RC can show the alarm
slogan properly.
Precondition: "FDSConfigurationManager:NotificationWarning" alarm
is already defined on System Monitor GUI and the alarm is ceased
before verification.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) "FDSConfigurationManager:NotificationWarning" alarm is already
defined on System Monitor GUI and the alarm is ceased before
verification.
Procedure: Follow the below procedure
1) Log in to EMA AS (PN) as root user.

2) Check current ESA configuration (FDSAuthority:UserNotAllowed


and FDSConfigurationManager:NotificationWarning) using the
following command.
# /opt/sog/bin/alarmmapping l
3) Revise the configuration to generate fake alarm
# /opt/sog/bin/alarmmapping m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

FDSConfigurationManager:NotificationWarning
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

FDSConfigurationManager:NotificationWarning
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Note: After tester follow up above procedure, OSS-RC will detect
Cold restart event (Warning) because it is updated about alarm
configuration at EMA AS. Please ignore such event on OSS-RC.
4) Generate the fake alarm by sogadm user using following
procedure toward OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The FDSConfigurationManager:NotificationWarning received
at OSSRC and in the system monitor

Post requisite: After this test case finish, test engineer needs to
return to original configuration as follows.
# /opt/sog/bin/alarmmapping m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription
[FDSConfigurationManager:NotificationWarning]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[FDSConfigurationManager:NotificationWarning]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping l
Then,
need
to
check
whether
original
(FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;

alarm

1.1.1.5

FDS authority

1.1.1.5.1

Invalid session Id
Description: The purpose of this test case is to verify the alarm
FDSAuthority: InvalidSessionId. This alarm is triggered when the
session ID or user which has already logged in is expired due to
tiume out
Prerequisite: None.
Procedure: Follow the procedure as below:
Action: Send the Login request to EMA
Result: User successfully logged in
Action: wait till the time out and send the provisioning request after
the timeout
Result: The alarm is raised in the EMA for FDSAuthority Invalid
session ID. Verify the alarm from the OSS.

1.1.1.5.2

User not allowed


Description: A user who has no authority tries to use a function in
Ericsson Multi Activation
Prerequisite: The following prerequisite needs to be met prior
toexecution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSAuthority:UserNotAllowed has been defined in
EMA System monitor GUI.
Procedure: Follow the below procedure:
1) Open a terminal application program
2) Telnet to EMA PN node as sogadm user at CAI port 3300
3) In the Enter command prompt enter
Enter command: LOGIN:aaa:aaa;
4) After verified the alarm enter the below command to logout

Enter command: LOGOUT;

Result: The FDSAuthority:UserNotAllowed received at OSSRC and


in the system monitor
1.1.1.5.3

User logged in
Description: The purpose of this test case is to verify the alarm for
the user who has the authority to use AS logs in to the system.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSAuthority:UserLoggedIn has been defined in EMA
System monitor GUI.
Procedure: Perform the steps as below:
Open a terminal application program
1) Telnet to EMA PN node as sogadm user at CAI port 3300
2) In the Enter command prompt enter
Enter command: LOGIN:sogadm:sogadm;
3) After verified the alarm enter the below command to logout
Enter command: LOGOUT;
Result: The FDSAuthority:UserLoggedIn has been verified in the
system monitor GUI

1.1.1.5.4

User logged out


Description: The purpose of this test case is to verify the alarm for
the user who has the authority to use AS logs out to the system.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSAuthority:UserLoggedOut has been defined in
EMA System monitor GUI.
Procedure: Perform the steps as below:
Open a terminal application program
1) Telnet to EMA PN node as sogadm user at CAI port 3300

2) In the Enter command prompt enter


Enter command: LOGIN:sogadm:sogadm;
3) After verified the alarm enter the below command to logout
Enter command: LOGOUT;
Result: The FDSAuthority:UserLoggedOut has been verified in the
system monitor GUI
1.1.1.6

FDS Component Manager

1.1.1.6.1

Plugin Died
Description: The purpose of this test case is to verify the event
FDScomponent manager plugin died. The PluginManager reports that
the plug-in stated in the message is dead
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:PluginDied has been defined
in EMA System monitor GUI.
Procedure: Follow the below steps:
1 Telnet to EMA PN node as sogadm user
2) As sogadm user re-start the CAI plugin
sogadm> emaps -k CAI
3) Check the OSSRC for the alarm message.
4) Check that the CAI plugin in the PL node has become active
sogadm> emaserver domain PL status
Wait until CAI component become active before go to the next test
case
Result: The FDSComponentManager:PluginDied received at OSSRC
and in the system monitor

1.1.1.6.2

Plugin recovery failed


Description: The purpose of this test case is to verify event
FDSComponentManager:PluginRecoveryFailed
Prerequisite: The following prerequisite needs t =o be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:PluginRecoveredFailed has
been defined in EMA System monitor GUI.
Note: Make sure that No alarms are active or showing in the system
monitor GUI. If any alarms presents please reset them before execute
the below actions.
Procedure: Perform the below steps:
1) Telnet to EMA PN node as sogadm user
2) As sogadm user re-start PROCQUEUE components other than
FDS-PL &
FDS-PM-PL eg: PROCQUEUE
sogadm> emaps -k PROCQUEUE
3) Now restart the FDS-PL plugin as sogadm user
sogadm> emaps -k FDS-PM-PL
Note you may experience a EMA PL restart due to this activity to
create the alarm.
4) Check the OSSRC for the alarm message.
5) Re-start all the plugins by stop and re-start the EMA Processing
Layer
this is due to restart the PROCQUEUE component which has been
failed to
recover.
sogadm> emaserver domain PL stop
sogadm> emaserver domain PL start
6) Check that all the plugins become active in the processing node
sogadm> emaseerver domain PL status

7) If the plugins are not active wait until all plugins are active
Result: The FDSComponentManager:PluginRecoveredFailed alarm
received at OSSRC and in the system monitor.
1.1.1.6.3

To verify event FDSComponentManager:InternalError


Description: The purpose of this test case is to verify the event
FDSComponentManager:InternalError. This alarm is raised when
there is some internal problem with the FDS component manager. It
is very difficult to trigger this alarm manually.

1.1.1.6.4

Failed to save config


Description: The purpose of this test case is to verify event
FDSComponentManager:FailedToSaveConfig
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) "FDSComponentManager:FailedToSaveConfig" alarm is already
defined on System Monitor GUI and the alarm is ceased before
verification.
Procedure: Perform the steps as below:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed
and
FDSComponentManager:FailedToSaveConfig)
using
the
following command.
# /opt/sog/bin/alarmmapping -l
3) Revise the configuration to generate fake alarm
# /opt/sog/bin/alarmmapping m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

FDSComponentManager:FailedToSaveConfig
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

FDSComponentManager:FailedToSaveConfig
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Note: After tester follow up above procedure, OSS-RC will detect
Cold restart event (Warning) because it is updated about alarm
configuration at EMA AS. Please ignore such event on OSS-RC.
4) Generate the fake alarm by sogadm user using following
procedure toward
OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The FDSComponentManager:FailedToSaveConfig received
at OSSRC and in the system monitor
Post requisite: After this test case finish, test engineer needs to
return to original configuration as follows.
# /opt/sog/bin/alarmmapping m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription
[FDSComponentManager:FailedToSaveConfig]:
FDSAuthority:UserNotAllowed

Please input alarmActiveDescription


[FDSComponentManager:FailedToSaveConfig]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then,
need
to
check
whether
original
(FDSAuthority:UserNotAllowed) can see on OSS-RC

alarm

# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
1.1.1.6.5

Information
Description: The purpose of this test case is to verify FDS Component
Manager: Information. This varies depending on the information
contained within the alarm.
Prerequisite: The following prerequisites needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:information has been defined in
EMA System monitor GUI
Procedure: Follow the procedure as below:
1) Telnet to EMA node as sogadm user
2) As sogadm user re-start FDS-PL plugin
sogadm> emaps -k FDS-PL
3) Check the OSSRC for the alarm message.
4) Check that all the plugins become active in the processing node
sogadm> emaserver status

5) If the plugins are not active then wait until all plugins are active
Result: The FDSComponentManager:information alarm received at
OSSRC and in the system monitor.
1.1.1.6.6

Mo Request failed.
Description: the purpose of this test case is to verify the event
FDSComponentManager:MORequestFailed.
This
happens
when
FDSController fails to process an MO request sent by the
FDSComponentManager.
Prerequisite: The following prereauisite needs to be met prior to
esecution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:MORequestFailed has been
defined in EMA System monitor GUI
Procedure: Perform the steps as below:
1) Log in to EMA as sogadm user and make sure CAI component is alive
sogadm> emaps
sogadm> emaserver domain PL status
2) Open admintool and send the below request. This request is to start
CAI. But, CAI
is already alive. So, this request will fail.

<Request MO="FDSController" Operation="Start" SessionId="">


<LogicalComponent>Cai/2.0/A/1</LogicalComponent>
</Request>
Result: The FDSComponentManager:MORequestFailed received at
OSSRC and in the system monitor
Admintool show the following information.

1.1.1.6.7

MO request info
Description: The purpose of this test case is to verify To verify event
FDSComponentManager:MORequestInfo. (MoRequests information:
get, delete, set and etc.) The event is triggered when different
configuration windows are opened in Ericsson Multi Activation GUI, for
example, Network Element or NE Cluster.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:MORequestinfo
defined in EMA System monitor GUI.

has

been

Procedure: Perform the procedure as below:


1) Login to EMA PL admintool GUI at PN and select component
configuration
2) Select CAI and Click "apply" button

3) Check the OSSRC for the alarm message.


Result: The FDSComponentManager:MORequestinfo alarm received at
OSSRC and in the system monitor.
1.1.1.6.8

Rebuilding structures info


Description: The purpose of this test case is to verify event
FDSComponentManager:RebuildingStructuresInfo. Component Manager
is rebuilding internal structure of every component.
Prerequisite: The following prerequisite needs to be met prior to
execution :
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:RebuildingStructuresInfo has
been defined in EMA System monitor GUI
Procedure: Follow the procedure as below:
1) Telnet to EMA node as sogadm user
2) As sogadm user re-start the FDS server component
sogadm> emaps -k FDS-PL

3) Check the OSSRC for the alarm message.


4) Check that the all the plugin in the PL has become active
sogadm> emaserver status
5) Wait until all the plugins become active before go to the next test case
Result: The FDSComponentManager:RebuildingStructuresinfo alarm
received at OSSRC and in the system monitor.

1.1.1.7

Gui Driver

1.1.1.7.1

LicenceKeyerror
Description: The purpose of this test case is to verify the event
GUIDRIVER:LicenceKeyError. We want to see that whether OSS-RC
can show the alarm slogan properly. This event arises when there is an
error in the Licence Key, either name or version is missing.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:

1) "GUIDriver:LicenceKeyError" alarm is already defined on System


Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the steps as below:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed and
GUIDriver:LicenceKeyError) using the following command.
# /opt/sog/bin/alarmmapping -l
3) Revise the configuration to generate fake alarm
# /opt/sog/bin/alarmmapping -m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
GUIDriver:LicenceKeyError
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
GUIDriver:LicenceKeyError
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Note After tester follow up above procedure, OSS-RC will detect "Cold
restart" event (Warning) because it is updated about alarm configuration
at EMA AS. Please ignore such event on OSS-RC.
4) Generate the fake alarm by sogadm user using following procedure
toward
OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;

Enter command: LOGOUT;


Result: The GUIDriver:LicenceKeyError received at OSSRC and in the
system monitor
Post requisite: After this test case finish, test engineer needs to return
to original configuration as follows.
# /opt/sog/bin/alarmmapping -m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription
[GUIDriver:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[GUIDriver:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then,
need
to
check
whether
original
(FDSAuthority:UserNotAllowed) can see on OSS-RC

alarm

# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;

1.1.1.7.2

To verify event GUIDriver:CorbaConnectionFailure


Description: The purpose of this test case is to verify the event
GUIDriver:CorbaConnectionFailure which triggered when the CORBA
connection is not established. The alarm is not possible to trigger
manually.

1.1.1.7.3

To verify event GUIDriver:LoadSubPluginOrComponentError


Description: The purpose of this test case is to verify the event
GUIDriver:LoadSubPluginOrComponentError which is raised when
there is some internal error in configuration which causes for the GUI
Driver subplugin to load properly. It is not possible to trigger this
alarm manually.

1.1.1.8

CAI driver

1.1.1.8.1

Server maximum connection reached


Description: The purpose of this test case is to verify event
IfDriver:ServerMaxConnectionReached.
Prerequisite: The event IFDriver:ServerMaxConnectionReached
defined in the system monitor gui
Procedure: Perform the steps as below:
1) Open admintool GUI from EMA AS (PN) as sogadm user.
2) Select CAI parameter panel (Component configuration-> Cai),
then, set
"NoOfConnections" value to "1".
Note Make a note about original value of the NoOfConnections.

3) Open terminal application at PN and Login to PN using port 3300


Telnet 0 3300 on PN.

# telnet 0 3300
Trying 0.0.0.0
Connected to 0.
Escape character is '^]'.
CONNECTING TO CAI
PROCESS cai3300 CONNECTED
Enter command:
Result: The IfDriver:ServerMaxConnectionReached received at
OSSRC and in the system monitor
1.1.1.8.2

Server Ready to accept


Description: The purpose of this test case is to verify the event
IfDriver:ServerReadyToAccept
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) Precondition of this TC reuses another TC condition (Section
1.1.1.8.1).
Procedure: Follow the steps as below:
1) Following another TC (Section 1.1.1.8.1), reuse the terminal that
is mentioned Step 3 of another TC , and wait until CAI session
timeout or type "^]" to exist immediately
Enter command: ^]
telnet> quit
Connection to 0 closed.
Result: The IfDriver:ServerReadyToAccept received at OSSRC and in
the system monitor
Post requisite:
1) Open admintool GUI from EMA AS (PN) as sogadm user.
2) Select CAI parameter panel (Component configuration-> Cai), then,
set
"NoOfConnections" value to "original value".

The value refers to Step 2 on TC Section 1.1.1.8.1

1.1.1.8.3

Maximum retries to login exceeded


Description: The purpose of this test case is to verify the event
IfDriver:MaxRetriesToLoginExceeded
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm IfDriver:MaxRetrysToLogInExceeded has been defined
in EMA System monitor GUI.
Procedure: Perform the procedures as below:
1) Open admintool GUI from EMA AS (PN) as sogadm user
2) Send a request using Request Sender

The request is (pay attention to the different newline symbols of UNIX


and DOS. Its better to type the request, not copying)
<Request MO="FSCCai" Operation="Set" SessionId="">
<Configuration>
<CaiServer>
<ProtocolServers>
<ProtocolServer Name="cai3300">
<CaiSessionConfig>
<FirstMessage>CONNECTING TO CAI...
PROCESS cai3300 CONNECTED... </FirstMessage>
<CaiPrompt>"Enter command: "</CaiPrompt>
<CaiConfirmation>CRNL</CaiConfirmation>
<ShowEmptyArg>0</ShowEmptyArg>
<CaiIdleTimeout>300</CaiIdleTimeout>
</CaiSessionConfig>
<CaiServerConfig>
<Type>TCPIP</Type>
<port>3300</port>
<backlog>1</backlog>
<NotAcceptMessage>Max number of connections
exceeded.</NotAcceptMessage>
</CaiServerConfig>
<NoOfConnections>80</NoOfConnections>
</ProtocolServer>
</ProtocolServers>
</CaiServer>
</Configuration>
</Request>

3) Wait several minutes. Then, open terminal application on PN and login to


CAIDriver using port 3300 with incorrect password
# telnet 0 3300
Trying 0.0.0.0
Connected to 0.
Escape character is '^]'.
CONNECTING TO CAI
PROCESS cai3300 CONNECTED
Enter command: LOGIN:sogadm:wrongPassword;
RESP:3006;
Connection to 0 closed by foreign host.
Result: IfDriver:MaxRetrysToLogInExceeded received at OSSRC and in
the system monitor
Post Requisite: Do the following steps to restore CAIDriver configuration:

1) Open admintool GUI from EMA AS (PN) as sogadm user

2) Send a request using Request Sender. The request request is (pay


attention to the different newline symbols of UNIX and DOS. Its better to
type the request, not copying)
<Request MO="FSCCai" Operation="Set" SessionId="">
<Configuration>
<CaiServer>
<ProtocolServers>
<ProtocolServer Name="cai3300">
<CaiSessionConfig>
<FirstMessage>CONNECTING TO CAI...
PROCESS cai3300 CONNECTED... </FirstMessage>
<CaiPrompt>"Enter command: "</CaiPrompt>
<CaiConfirmation>CRNL</CaiConfirmation>
<ShowEmptyArg>0</ShowEmptyArg>
<CaiIdleTimeout>300</CaiIdleTimeout>
<CaiMaxLoginRetry>1</CaiMaxLoginRetry>
</CaiSessionConfig>
<CaiServerConfig>
<Type>TCPIP</Type>
<port>3300</port>
<backlog>1</backlog>
<NotAcceptMessage>Max number of connections
exceeded.</NotAcceptMessage>
</CaiServerConfig>
<NoOfConnections>80</NoOfConnections>
</ProtocolServer>
</ProtocolServers>
</CaiServer>
</Configuration>
</Request>

1.1.1.8.4

To verify event IFDriver:BadLinkDevice


Description: The purpose of this test case is to verify the event
IfDriver:BadLinkDevice. The test case is not applicable.

1.1.1.9

Processing Engine

1.1.1.9.1

ConfigurationWriteFailure
Description: The purpose of this test case is to verify the event
procengine:ConfigurationWriteFailure. This happens when the
processing engine failed to write a configuration change in the
configuration manager.
Prerequisite: The following prerequisites need to be met prior to
execution of this test case:

1) "ProcEngine:ConfigurationWriteFailure" alarm is already defined


on System Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the below procedure:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed
and
ProcEngine:ConfigurationWriteFailure)
command.

using

the

following

# /opt/sog/bin/alarmmapping -l
3) Revise the configuration to generate fake alarm
# /opt/sog/bin/alarmmapping -m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

ProcEngine:ConfigurationWriteFailure
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

ProcEngine:ConfigurationWriteFailure
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Note After tester follow up above procedure, OSS-RC will detect
"Cold restart" event (Warning) because it is updated about alarm
configuration at EMA AS. Please ignore such event on OSS-RC.
4) Generate the fake alarm by sogadm user using following
procedure towards
OSS-RC.
# su - sogadm

sogadm> telnet 0 3300


Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The ProcEngine:ConfigurationWriteFailure
OSSRC and in the system monitor

received

at

Post Requisite: After this test case finish, test engineer needs to
return to original configuration as follows.
# /opt/sog/bin/alarmmapping -m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription
[ProcEngine:ConfigurationWriteFailure]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[ProcEngine:ConfigurationWriteFailure]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then,
need
to
check
whether
original
(FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;

alarm

Enter command: LOGOUT;


1.1.1.9.2

To verify event ProcEngine:BusinessLogicCompilationError


Description: The purpose of this test case is to verify the event
ProcEngine:BusinessLoginCompilationError
Note: This alarm is raised when there is some business logic
compilation error in the procengine, it is not possible to trigger this
alarm manually.

1.1.1.9.3

Licence Key error


Description: The purpose of this test case is to verify event
ProcEngine:LicenceKeyError. This condition comes when there is an
error in the Licence Key, either name or version is missing.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) "ProcEngine:LicenceKeyError" alarm is already defined on
System Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the steps as below:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed
and
ProcEngine:LicenceKeyError) using the following command.
# /opt/sog/bin/alarmmapping -l
3) Revise the configuration to generate fake alarm
# /opt/sog/bin/alarmmapping -m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?

1.1.1.10

(y/n):y
Please input alarmSeverity [6]: 6
Please
alarmModelDescription [FDSAuthority:UserNotAllowed]:

input

ProcEngine:LicenceKeyError
Please
input
[FDSAuthority:UserNotAllowed]:

alarmModelDescription

ProcEngine:LicenceKeyError
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Note After tester follow up above procedure, OSS-RC will detect
"Cold restart" event (Warning) because it is updated about alarm
configuration at EMA AS. Please ignore such event on OSS-RC.
4) Generate the fake alarm by sogadm user using following
procedure toward
OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The ProcEngine:LicenceKeyError received at OSSRC and in
the system monitor
Post Requisite: After this test case finish, test engineer needs to
return to original configuration as follows.
# /opt/sog/bin/alarmmapping -m
Please input alarmModule: FDSCore
Please input alarmErrorcode:505
The alarm has been existed, are you sure you want modify it?
(y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription
[ProcEngine:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input alarmActiveDescription

[ProcEngine:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then,
need
to
check
whether
original
(FDSAuthority:UserNotAllowed) can see on OSS-RC

alarm

# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
1.1.1.10.1

To verify event ProcEngine:UserNotAllowed


Description: The purpose of this test event
ProcEngine:UserNotallowed
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is successfully
verified.
2) The alarm ProcEngine:UserNotAllowed
Note: It is not possible to trigger this alarm manually.

1.1.1.10.2

To verify event ProcEngine:LoadSubPluginError


Description: The purpose of this test case is to verify the event
ProcEngine:LoadSubPluginError
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is successfully
verified.
2) The alarm ProcEngine:LoadSubPluginError is already verified in
EMA system monitor gui.
Note: It is not possible to trigger this alarm manually.

1.1.1.10.3

To verify event ProcEngine:LicenceExpiring


Description: The purpose of this test case is to verify the event
ProcEngine:LicenceExpiring
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is successfully
verified.
2) The alarm ProcEngine:LicenceExpiring is already verified in EMA
system monitor gui.
Note: It is not possible to trigger this alarm manually.

1.1.1.11

Processing Log

1.1.1.11.1

To verify event ProcLog:FileSystemError


Description: the purpose of this test case is to verify the event
Proclog:FileSystem Error.
Note: It is not possible to trigger this alarm manually.

1.1.1.12

CAI3G session

1.1.1.12.1

To verify the event Over Limitation Of MaxNumOfCAI3GSession


Description: The purpose of this test case is to verify the event Over
Limitation Of MaxNumOfCAI3GSession
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC verified
2) The alarm for Over limitation of Max number of cai3G session
already defined in EMA system monitor GUI
Procedure: Follow the procedure as below
Action: Open the CAI3G session control window to modify the max
number of cai3G sessions click Administration > CAI3G Interface>
Session Control. Change the value of max number of sessions to1
and save.
Result: The max value of cai 3g session saved
Action: send a login session reuest from SOAPUI to EMA.

Result: Login accepted and session established


Action: Send one more login request from another SOAP UI window.
Result: The Login rejected due to Over limitation of Max number of
cai3G session and alarm sent to OSS verify the alarm.
Post requisite: Restore the max number of session to the original
value in EMA GUI.
1.1.1.13

Mml Link Pool

1.1.1.13.1

MmlIP:linkFailure
Description: The purpose of this test case is to verify the event
Mmllp:LinkFailure which arises when no connection can be
established with a Network Element.
Prerequisite: The following prerequisite needs to be met prior to the
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm Mmllp:LinkFailure has been defined in EMA System
monitor GUI
Procedure: Perform the procedure as below:
1) Using the EMA GUI at PN, open the system monitor alarm
configuration window
2) Select a the Mmllp:LinkFailure Alarm definition
3) Configure the "Route on affected object" to ON (if it already defined
use the NE already defined)
4) Using the EMA GUI, In the Network Element window Set an invalid
IP address on selected MiO NE, eg: tyMiO01
5) Send some provisioning commands from CAS to Network Element
for which the IP is changed in the above step.
7) Check the OSSRC for the alarm message.
8) Re-configure the NE back to the original IP address and send a
provisioning request.
9) Check for the Mmllp:LinkRecovered Alarm at the OSSRC
10) Remove the "Route on affected object" selection, if its already
there then leave it as it is.

Result: The Mmllp:LinkFailure alarm received at OSSRC and in the


system monitor
1.1.1.13.2

Mmllp:LinkManangerConnectionFailure
Description: The purpose of this test case is to verify the event
Mmllp:LinkManangerConnectionFailure.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm Mmllp:LinkManagerConnectionFailure
defined in EMA System monitor GUI

has

been

Procedure: Perform the steps as below:


1) Using the EMA GUI at PN, open the system monitor alarm
configuration window
2) Select a the Mmllp:LinkFailure Alarm definition
3) Configure the "Route on affected object" to ON ( if it already
defined use the NE already defined)
4) Using the EMA GUI, In the Network Element window Set an invalid
IP address on selected MiO NE, eg: tyMiO01
5) Down LINKMANAGER component at both RNs as sogadm user
sogadm> emaps -k LINKMANAGER
6) Send some provisioning commands before the link manager
comes up ( this step needs to be done very quickly)
1) Check the OSSRC for the alarm message.
2) Re-configure the NE back to the original IP address and send a
provisioning command.
3) Remove the "Route on affected object" selection, if its already
there then leave it as it is.
Result: The Mmllp:LinkManagerConnectionFailure
OSSRC and in the system monitor

received

at

1.1.1.14
1.1.1.14.1

Logwriter
LogWriter:LoadFileStopped
Description: The purpose of this test case is to verify the event
LogWriter:LoadFileStopped
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm LogWriter:LoadFileStopped has been defined in EMA
System monitor GUI
Procedure: Perform the steps as below:
1) Open admintool GUI from EMA AS (PN) as sogadm user
2) Use "Component controller" to stop LogWriter.
Result: The LogWriter:LoadFileStopped received at OSSRC and in
the system monitor
Post requisite: To restore LogWriter, use "Component controller" on
admintool GUI to start LogWriter again.

1.1.1.14.2

LogWriter:FileLoadError
Description: The purpose of this test case is to verify the event
LogWriter:FileLoadError
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case
1) The OSSRC & EMA integration has been verified.
2) The Alarm Failed to load Log file. has been defined in EMA
System monitor GUI
Procedure: Perform the steps as below:
1) Logon one PN and go to directory /opt/sog/bin.
execution permission of log_loader.sh
sogadm> cd /opt/sog/bin
sogadm> ls -al log*

Revoke the

sogadm> chmod a-x log_loader.sh


2) Go to directory /var/sog/logs/proclog/raw and create an empty file
with the name CSO_2010-10-26_183156_90001.dat
sogadm> cd /var/sog/logs/proclog/raw
sogadm> touch CSO_2010-10-26_183156_90001.dat
3) It will take about 14 minutes to trigger this alarm. (Because
LogWriter did retrying.)
Result: The LogWriter:FileLoadError received at OSSRC and in the
system monitor
Post requisite: After this test case finish, test engineer needs to
return to original configuration as follows.
sogadm> cd /opt/sog/bin
sogadm> ls -al log*
sogadm> chmod 755 log_loader.sh
During the period of disabling log_loader.sh, there may also the
normal
provisioning
log
raw
file
is
generated
in
/var/sog/logs/proclog/raw,
e.g.,
CSO_2011-0706_152303_296790001.dat. Wait several minutes until the correct log
raw file, CSO_2011-07-06_152303_296790001.dat, disappears.
Then check if there's a directory named recovery under
/var/sog/logs/proclog/
and
there's
only
CSO_2010-1026_183156_90001.dat in that directory. If so, it doesn't matter and
just delete it directly.
sogadm> cd /var/sog/logs/proclog/recovery
sogadm> cd 20110706
(this is an example, the actual directory name is the
same with the date when doing this test case)
sogadm> ls -al
CSO_2010-10-26_183156_90001.dat
cd /var/sog/logs/proclog/
sogadm> rm -rf recovery

1.1.1.15

Order scheduler

1.1.1.15.1

To verify Order Scheduler: QueueFull in Order Scheduler with


alarmModule used in SNF as OrderScheduler.
Description: The purpose of this test case is to verify the event
Order Scheduler: QueueFull in Order Scheduler with alarmModule
used in SNF as OrderScheduler. This alarm is raised when the SOs
in the Queue exceed 1000,000.
Prerequisite: The following prerequisites need to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC successfully verified
2) The alarm Order Scheduler:Queue Full already defined in EMA.
3) Many SOS in Queue
Procedure: Follow the procedure as below
Action: Stop the consumer of Sevice order scheduler by logging in to
EMA GUI.
Result: Consumer stopped
Action: Keep sending multiple Async SOs until the total number of
SOs exceed 1000,000
Result: The alarm Order Scheduler queue full sent to the OSS.
Post requisite: Start the consumer, all the SOs in the queue will start
processing. Verify that all the SOs are successfully processed. If
some of the SOs fail process them manually.

1.1.1.15.2

To verify Order Scheduler receiver Stopped - The Service Order


Scheduler (SOS) receiver is stopped.
Description: The purpose of this test case is to verify the event
which is sent to the OSS when the reciever is stopped
Prerequisite: The following prerequisite needs to be met prior to the
execution of this test case:
1) The connectivity between EMA and OSS RC is verified.
2) The alarm for event SOS receiver stopped is already defined in
EMA.
Procedure: Follow the procedure as below

Action1: Open the control menu in EMA GUI.


click Administration > Service Order Scheduler > Control.

Action2: The control panel is opened, click on stop tab in front of


receiver
Result: receiver is stopped and alarm is sent to OSS. Verify the
alarm at the OSS.
Post requisite: start the receiver by clicking start in control panel.
1.1.1.15.3

To verify OrderScheduler:ConsumerStopped - The SOS consumer is


stopped.
Description: the purpose of this test case is to verify the alarm
OrderScheduler:ConsumerStopped which is raised on the OSS when
consumer is stopped.
Prerequisite: The following prerequisite needs to be met prior to the
execution of this test case:
1) The connectivity between EMA and OSS RC is verified.
2) The alarm for event SOS consumer stopped is already defined in
EMA.
Procedure: Follow the procedure as below
Action1: Open the control menu in EMA GUI.
click Administration > Service Order Scheduler > Control.

Action2: The control panel is opened, click on stop tab in front of


consumer
Result: Consumer is stopped and alarm is sent to OSS. Verify the
alarm at the OSS.
Post requisite: start the consumer by clicking start in control panel.
1.1.1.15.4

To verify Order Scheduler:CSO expired


Description: The purpose of this test case is to verify the event
which is sent ot the OSS when the CSO is expired.
Prerquisite: The following prerequisite needs to be met prior to
execution of this test case
1) The connectivity between EMA and OSS RC is verified.
2) The alarm Order schedulerCSO expired already defined in EMA
3) Many SOs in the order queue
Procedure : Follow the procedure as below
Action: Stop the consumer till many of the SOs stored in queue are
expired. And verify the alarm at the OSS
Result : The alarm OrderScheduler :CSO expired verified at the OSS
Post requisite: Start the consumer and execute the expired SOs
manually.

1.1.1.16

EMC Storage

1.1.1.16.1

To verify EMC Storage :Information Trap - Information trap is from


EMC storage
Description: The purpose of this test case is to verify the event EMC
Storage :Information Trap - Information trap is from EMC storage
Prerequisite: the following prereauisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC verified successfully
2) The trap EMC Storage :Information Trap is already defined in
EMA system monitor GUI
Procedure: This alarm is raise on the OSS in case of serious fault
(internal error) in the EMC, this alarm is not possible to trigger
manually.

1.1.1.16.2

To verify EMC Storage:Warning Trap - Warning trap is from EMC


storage
Description: The purpose of this test case is to verify the event EMC
Storage:Warning Trap
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is successfully
verified.
2) The trap EMC Storage:Warning Trap already defined in EMA
system monitor GUI.
Procedure: This alarm is raise on the OSS in case of serious fault
(internal error) in the EMC, this alarm is not possible to trigger
manually.

1.1.1.16.3

To verify EMC Storage:Error Trap - Error trap is from EMC storage.


Description: The purpose of this test case is to verify the event EMC
Storage:Error Trap
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is successfully
verified.

2) The trap EMC Storage:Error Trap already defined in EMA system


monitor GUI.
Procedure: This alarm is raise on the OSS in case of serious fault
(internal error) in the EMC, this alarm is not possible to trigger
manually
1.1.1.16.4

To verify EMC Storage:Critical Trap - Critical trap is from EMC


storage.
Description: The purpose of this test case is to verify the event EMC
Storage:Critical Trap
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is successfully
verified.
2) The trap EMC Storage:Critical Trap already defined in EMA system
monitor GUI.
Procedure: This alarm is raise on the OSS in case of serious fault
(internal error) in the EMC, this alarm is not possible to trigger
manually

1.1.2

Pacemaker Alarms

1.1.2.1

LVS External Resource VIP stopped

1.1.2.1.1

To verify LVS:ExternalVIPResourceStopped
Description: The Purpose of this test case is to verify the event
LVS:ExternalVIPResourceStopped lvs-vip is used to set up VIP for
incoming provisioning connections.
Prerequisite: The following prerequisites needs to be met prior to
execution of this test case:
1) The connection between OSS- RC and EMA is verified
2) The alarm LVS:ExternalVIPResourceStopped configured in EMA
system monitor GUI
Procedure: Follow the procedure as below:
Action: Login to EMA server 1 as user root
Result: user root logged in

Action: check the status of lvs vip. (this should be running)


tyEMA01:~ # crm resource status lvs-vip
Result: The following is the expected result
resource lvs-vip is running on: tyEMA01
Action: stop the lvs vip by executing the command
tyEMA01:~ # crm resource stop lvs-vip
Result: lvs vip stopped and alarm raised on OSS. Verify the alarm
on OSS
Post requisite:
1) start the lvs vip by executing the command
tyEMA01:~ # crm resource start lvs-vip
3) Verify that it is started by executing the command
tyEMA01:~ # crm resource status lvs-vip
1.1.2.1.2

To verify lvs-ldirectordResourceStopped
Description: The Purpose of this test case is to verify the event
LVS:LdirectordResourceStopped lvs-ldirectord is used to
activate ldirectord which configures and monitors IPVS.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connection between OSS- RC and EMA is verified
2) The alarm LVS:LdirectordResourceStopped configured in EMA
system monitor GUI
Procedure: Perform the steps as given below:
Action: Login to EMA server 1 as user root
Result: user root logged in
Action: check the status of lvs-ldirectord (this should be running)
tyEMA01:~ # crm resource status lvs-ldirectord
Result: The expected result is as shown below:

resource lvs-ldirectord is running on: tyEMA01


Action: stop the lvs-lDirectord by executing the command
tyEMA01:~ # crm resource stop lvs-ldirectord
Result: lvs-lDirectord stopped and alarm raised on OSS. Verify the
alarm on OSS
Post requisite:
1) Start the lvs ldirectord by executing the command
tyEMA01:~ # crm resource start lvs-ldirectord
3) Verify that it is started by executing the command
tyEMA01:~ # crm resource status lvs-ldirectord
1.1.2.1.3

To verify LVS: Internal VIP Resource Stopped


Description: The purpose of this test case is to verify the event LVS:
Internal VIP Resource Stopped lvs-dip is used to setup VIP for
distributing traffic to PN nodes in the AS scalable HA configuration. It
is also used to forward outgoing requests from PN nodes. It is not
used on the AS two nodes HA configuration
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case
1) The connection between EMA and OSS-RC verified
2) The alarm LVSInternal VIP resource stopped already defined in
EMA system monitor GUI
Procedure: Perform the steps as below
Action: Login to server 1 as user root
Result: User root logged in
Action: Stop lvs-dip by executing the command
# crm resource stop lvs-dip
Result: LVS dip stopped, verify the alarm at OSS
Post requisite:
1) Start the lvs dip by executing the command

# crm resource start lvs-dip


2) Verify that the lvs dip is successfully started by executing the
command
# crm resource status lvs-dip
1.1.2.1.4

To verify ExternalPingResourceonNode1Stopped
Description: The purpose of this test case is to verify
ExternalPingResourceonNode1 stopped. This is basicall a clone set
which runs on both server 1 and server 2 simultaneously, hence
stopping this resource will stop it on both the servers and the alarms
for both the servers will be raised on OSS RC.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connection between EMA and OSS RC verified
2) The alarm ExternalPingResourceStopped already define in the
EMA system monitor GUI
Procedure: Perform the steps as below:
Action: Login to EMA server 1 as user root
Result: User root logged in.
Action: Check the status of the resource ping external clone by
executing the command
tyEMA01:~ # crm resource status ping-external-clone
Result: it will show that this resource is running on both the nodes.
resource ping-external-clone is running on: tyEMA01
resource ping-external-clone is running on: tyEMA02
Action: Stop the resource ping-external-clone by executing the
command
tyEMA01:~ # crm resource stop ping-external-clone
Result: ping external clone stopped on both the nodes and the alarm
raised on OSS, verify the alarm from OSS.
Post requisite:
1) Start the resource ping external clone by executing the command

tyEMA01:~ # crm resource start ping-external-clone


3) Verify that the resource is successfully started by executing the
command
tyEMA01:~ # crm resource status ping-external-clone
Result: The command will show that the resource is started on both
the ema nodes.
resource ping-external-clone is running on: tyEMA01
resource ping-external-clone is running on: tyEMA02
Note: It takes some time for the ping-external-clone to start up and
stop, please wait for some time for the alarms to come and for the
resource to start and stop.
1.1.2.1.5

To verify InternalPing Rersource on Node 1 Stopped


Description: The purpose of this test case is to verify
InternalPingResource on Node1Stopped ping-internal is used to
detect connectivity of the internal network. LVS, NFS and EMALOG
services will refuse to start up if ping-internal fails to ping other nodes
in the internal network.
Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm InternalPingResource already defined on the EMA
system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
Result: User root Logged in
Action: Issue the below command to stop the resource ping-internalclone
# crm resource stop ping-internal-clone
Result: The command above will stop the ping internal clone on node
1 and node 2 and the alarms will go to the OSS for this. Verify the
alarms on the OSS
Post requisite:
1) Start the resource ping-internal-clone

# crm resource start ping-internal-clone


2) Verify that this resource is successfully started on both the nodes
by issuing the command
#crm resource status ping-internal-clone
1.1.2.1.6

To verify ClusterMonitorResource on Node 1 stopped


Description: The purpose of this test case is to verify cluster-mon
resource on node 1 is stopped. cluster-mon is used to monitor the
status of Pacemaker resources. If any of these resources stops,
SNMP notification will be sent out to the ESA server.
Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm ClusterMonitorResource already defined in the system
monitor gui
Procedure:
Action: Login to EMA server 1 as user root
Result: user root logged in
Action: Shut down Node 1 and verify the alarm from the second
node and from the OSS
# init 0
Result: The resource base-clustermon-clone stopped on node 1 and
the alarm sent to the OSS, verify the alarm for node 1 on the OSS
Post requisite:
1) Login to HPiLO of server 1 and power on the server
Open terminal with iLOM IP, ssh <ipaddress of hpilom
server1>
2) Power on the server
</>hpiLO-> power on

1.1.2.1.7

To verify ClusterMonitorResourceonNode2 stopped


Description: : the purpose of this test case is to verify cluster-mon
resource on node 2 is stopped. cluster-mon is used to monitor the
status of Pacemaker resources. If any of these resources stops,
SNMP notification will be sent out to the ESA server.
Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm ClusterMonitorResource already defined in the system
monitor gui
Procedure:
Action: Login to EMA server 1 as user root
Result: user root logged in
Action: Shut down Node 1 and verify the alarm from the second
node and from the OSS
# init 0
Result: The resource base-clustermon-clone stopped on node 1 and
the alarm sent to the OSS, verify the alarm for node 2 on the OSS
Post requisite:
1) Login to HPiLO of server 2 and power on the server
Open terminal with iLOM IP, ssh <ipaddress of hpilom
server1>
2) Power on the server
</>hpiLO-> power on

1.1.2.1.8

To verify OracleDataGuardRoleMonitorResource on Node 1 stopped


Description: The purpose of this test case is to verify the event
OracleDataGuardRoleMonitorResource dg-role is used to check the
status data guard database. If data guard database is started and the
role is primary, dg-vip will be started on the same node.
Prerequisite:
1) The connectivity between EMA and OSS RC verified

2) The alarm OracleDataGuardRoleMonitorResource


configured in the EMA system monitor GUI

already

Procedure:
Action: Login to EMA server 1 as user root
Result: user root logged in
Action: Stop the resource dg-role-clone
# crm resource stop dg-role-clone
Result: The resource dg-role-clone stopped on both the nodes and
the alarms for both the nodes raised on the OSS. Verify the raised
alarms on the OSS
Post requisite:
1) Start the resource dg-role-clone
# crm resource start dg-role-clone
2) Verify that the resource is successfully started
# crm resource status dg-role-clone
3) Logout from ema server
1.1.2.1.9

To
verify
Node1Stopped

OracleDataGuardObserverMonitorResource

on

Description: dg-observer is used to check the status data guard


database and start data guard observer accordingly. If data guard
database is started and the role is standby, the data guard observer
will be started. In this test cases while execution we will also verify the
alarm OracleDataGuardObserverMonitorResource on node 2
stopped.
Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm OracleDataGuardObserverMonitorResource already
defined in EMA system monitor GUI
Procedure:
Action: Login to server 1 as user root
Result: User root logged in

Action: Stop the resource group dg-observer-clone by executing the


command
# crm resource stop dg-observer-clone
Result: The resource grop stopped on both the nodes and alarms will
be sent to the OSS, verify the alarms on the OSS
Post Requisite:
1) Start the resource group by executing the command
# crm resource start dg-observer-clone
2) Verify that the resource group is successfully started by executing
the command
# crmresource status dg-observer-clone
1.1.2.1.10

To verify OracleDataGuardVIPResourceStopped
Description: dg-vip is used to set up VIP for accepting incoming
requests to data guard database. The purpose of this test cases is to
verify the raised alarm in case dg-vip is stopped
Prerequisite:
1) The connection between EMA and OSS RC verified
2) The alarm OracleDataGuardVIPResourceStopped
defined in the EMA system monitor gui

already

Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
Action: stop the resource dg-vip
# crm resource stop dg-vip
Result: The resource dg-vip stopped and the alarm raised on the
OSS. Verify the alarm on the OSS
Post requisite:
1) start the resource dg-vip
# crm resource start dg-vip

2) Verify that the resource is successfully started


# crm resource status dg-vip
3) Logout from ema server
1.1.2.1.11

To verify OracleEMALOGInstanceResourceStopped
Description: The purpose of this test
OracleEMALOGInstanceResourceStopped

case

is

to

verify

Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm OracleEMALOGInstanceResourceStopped already
defined in the EMA system monitor gui
Procedure:
Action: Login to ema server 1 as user root
Result: User root logged in\
Action: stop the resource emalog by issuing the command
# crm resource stop emalog-instance
Result: The resource emalog-instance stopped and alarm sent to the
OSS. Verify the alarm on OSS
Post requisite:
1) Start the resource emalog-instance
# crm resource start emalog-instance
2) Verify that the resource emalog-instance is successfully started by
executing the command
# crm resource status emalog-instance
1.1.2.1.12

To verify OracleEMALOGVIPResourceStopped
Description: The purpose of this test case is to verify the resource
OracleEMALOGVIPResourceStopped
Prerequisite:
1) The connectivity between EMA and OSS RC verified

2) The alarm OracleEMALOGVIPResourceStopped already defined


in the system monitor gui
Procedure:
Action: Login to server 1 as user root
Result: User root logged in
Action: stop the resource emalog-vip
# crm resource stop emalog-vip
Result: The resource emalog-vip stopped and alarm sent to the OSS.
Verify the alarm on the OSS
Post Requisite:
1) start the resource emalog-vip
# crm resource start emalog-vip
2) verify that the resource emalog-vip is successfully started by
executing the command
# crm resource status emalog-vip
1.1.2.1.13

To verify NFSServerResourceStopped stopped


Description: The purpose of this test case is to verify the alarm for
NFSServerResourceStopped.
Prerequisite:
1) The connectivity between EMA and OSS RC is verified
2) The Alarm NFSServerResourceStopped already defined in the
EMA system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
Action: Stop the resource nfs-server by executing the command
# crm resource stop nfs-server
Result: The nfs-server group stopped and the alarm sent on the
OSS. Verify the alarm on the OSS

Post Requisite:
1) Start the nfs-server
# crm resource start nfs-server
2) Verify that the resource nfs-server is successfully started
# crm resource status nfs-server
1.1.2.1.14

To verify NFSVIPResourceStopped alarm


Description: the purpose of this test case is to verify the alarm for
the event NFSVIPResourceStopped
Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm NFSVIPResourceStopped successfully defined on the
EMA system monitor GUI
Procedure:
Action: Login to ema server 1 as user root
Result: user root logged in
Action: Stop the nfs-vip
# crm resource stop nfs-vip
Result: nfs-vip stopped and the alarm sent on OSS RC, verify the
alarm on the OSS
Post requisite:
1) start the nfs-vip
# crm resource start nfs-vip
2) Verify that the nfs-vip is successfully started by executing the
command
# crm resource status nfs-vip

1.1.2.1.15

To verify SplitBrainDetectorResourceStopped
Description: the purpose of this test case is to verify the alarm when
base-sbd resource is stopped. base-sbd is used to start Split Brain
Detector which is responsible to kill nodes behaves abnormally.

Prerequisite:
1) The connectivity between OSS and EMA is verified
2) The alarm SplitBrainDetectorResourceStopped already defined
on the EMA system monitor GUI
Procedure:
Action: Login to EMA serevr 1 as user root
Result: user root logged in
Action: stop the resource base-sbd
# crm resource stop base-sbd
Result: The resource base-sbd successfully stopped and the alarm
sent on the OSS. Verify the alarm on the OSS
Post requisite:
1) start the resource base-sbd
# crm resource start base-sbd
2) Verify that the resource base-sbd is successfully started
# crm resource status base-sbd
1.1.2.1.16

To verify OrchestratorFileSystemResourceStopped
Description: The purpose of this test case is to verify the event
OrchestratorFileSystemResourceStopped fs-orchestrator is used to
mount the device /dev/global/orchestrator.
Prerequisite:
1) The connectivity between EMA and OSS RC is verified
2) The alarm OrchestratorFileSystemResourceStopped
defined on the EMA system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
Action: Stop the fs-orchestrator for verifying the alarm

already

# crm resource stop fs-orchestrator


Result: fs-orchestrator stopped and the alarm sent to the OSS, verify
the alarm on the OSS
Post requisite:
1) start the fs-orchestrator
# crm resource start fs-orchestrator
2) Verify that the resource fs-orchestrator is successfully started by
executing the command
# crm resource status fs-orchestrator
1.1.2.1.17

To verify NfsinfoFileSystemResourceStopped
Description: The purpose of this test case is to verify the alarm
raised on the OSS when fs-nfsinfo resource is stopped. fs-nfsinfo is
used to mount the device /dev/global/nfsinfo.
Prerequisite:
1) The connectivity between EMA and OSS RC is verified
2) The alarm NfsinfoFileSystemResourceStopped is already defined
on the EMA system monitor GUI.
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
Action: Stop the resource fs-nfsinfo to verify its alarm on the OSS
# crm resource stop fs-nfsinfo
Result: The resource fs-nfsinfo successfully stopped and the alarm
sent on the OSS. Verify the alarm on the OSS
Post requisite:
1) start the resource fs-nfsinfo
# crm resource start fs-nfsinfo
2) Verify that the resource is successfully started
# crm resource status fs-nfsinfo

1.1.2.1.18

To verify the event BackupFileSystemResourceStopped


Description: The purpose of this test case is to verify the alarm
BackupFileSystemResourceStopped this alarm is raised and sent to
the OSS when fs-backup resource is stopped. fs-backup is used to
mount the device /dev/global/backup
Prerequisite:
1) The connectivity between EMA and OSS RC is verified
2) The alarm BackupFileSystemResourceStopped already defined
on the EMA system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
Action: Stop the resource fs-backup for the verification of its alarm
on the OSS
# crm resource stop fs-backup
Result: The resource fs-backup stopped and the alarm sent on the
OSS, verify the alarm on the OSS
Post Requisite:
1) Start the resource fs-backup
# crm resource start fs-backup
2) Verify that the resource fs-backup successfully started by
executing the command
# crm resource status fs-backup

1.1.2.1.19

To verify AgentdataFileSystemResourceStopped
Description: The purpose of this test case is to verify
AgentdataFileSystemResourceStopped This alarm is raised when fsagentdata resource is stopped. fs-orchestrator is used to mount the
device /dev/oracle/agentdata.
Prerequisite:
1) The connectivity between EMA and OSS RC verified

2) The alarm AgentdataFileSystemResourceStopped


defined in the EMA system monitor GUI

already

Procedure:
Action: Login to server 1 as user root
Result: User root logged in
Action: stop the resource fs-agentdata
# crm resource stop fs-agentdata
Result: The resource fs-agentdata stopped and alarm sent to the
OSS, verify the alarm from the OSS
Post Requisites:
1) start the resource fs-agentdata
# crm resource start fs-agentdata
2) Verify that the resource is successfully started by executing the
command
# crm resource status fs-agentdata
1.1.2.1.20

To verify the event EmalogFileSystemResourceStopped


Description: The Purpose of this test case is to verify the alarm for
EmalogFileSystemResourceStopped.
Prerequisite:
1) The connectivity between EMA and OSS RC is verified
2) The alarm EmalogFileSystemResourceStopped already defined in
the EMA system monitor GUI
Procedure:
Action: login to EMA server 1 as user root
Result: user root logged in
Action: stop the resource fs-emalog to verify its alarm
Result: the resource fs-emalog successfully stopped and the alarm
raised on the OSS. Verify tha alrm on the oss
Post requisite:

1) start the resource fs-emalog


# crm resource start fs-emalog
2) Verify that the resource is successfully started by executing the
command
# crm resource status fs-emalog
1.1.2.2

Data Guard Alarms

1.1.2.2.1

To verify DataGuard:NoListenerError.
Description: The purpose of this test cases is to verify the alarm
DataGuard:NoListenerError which is raised when no listener is
running on the oracle server
Prerequisite:
1) The connectivity between EMA and OSS RC verified
2) The alarm DataGuard:NoListenerError already configured in EMA
system monitor GUI
Procedure:
Action: Login to server 1 as user emadba and issue the below
command to stop the listener
# su - emadba
tyEMA01$ lsnrctl stop
Result: The following alarm is raised on the OSS
DBInterface:OracleServerUnavailableError
Action: wait for approximately 3-4 minutes and the following alarm
will be triggered on the OSS
DataGuard:NoListenerError.
Result: The alarm that the dataguard no listener is running is
displayed and verified from the OSS.
Post requisite:
1) Login to server 1 by user emadba issue the below command to
start the listener.
# su emadba

tyEMA01$ lsnrctl start


1.1.2.2.2

To verify NoemadbInstanceError
Description: The purpose of this test case is to verify the alarm
Noemadbinstance error.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC verified
2) The alarm NoemdbInstance error is already defined in EMA
system monitor GUI.
Procedure: Follow the procedure as below
Action: Login to server 2 as user emadba and issue the command to
stop the database instance
# su emadba
tyEMA02$ /opt/sogdb/bin/stopdb
Result: Data base instance stopped on Node 2.
Action: Repeat the above steps on Node 1 to stop the database
instance on Node 1.
Result: Database instance stopped on node 1 and alarm
NoemadbInstanceError
raised on the OSS.
Post requisite:
1) Login to server 2 form user emadba and issue the command to
start the emadb instance
# su emadba
tyEMA02$ /opt/sogdb/bin/startdb
2) Repeat the above step on node 1 to start the ema db instance on
Node 1.

1.1.2.2.3

To verify CannotLoginDBError - Users cannot log onto Oracle with


the sysdba account using sqlplus / as sysdba.
Description: The purpose of this test case is to verify the event
CannotLoginDBError - Users cannot log onto Oracle with the sysdba
account using sqlplus / as sysdba.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC verified.
2) The Alarm CannotLoginDB is defined in EMA system monitor GUI
Procedure: Follow the procedure as below:
Action: Login to EMA using user emadba
# su - emadba
Result: User emadba successfully logged in
Action: try logging in to DB using sqlplus / as sysdba without
specifying the SID.
tyEMA01$ sqlplus / as sysdba
Result: Unable to login to DB and alarm sent to OSS. Verify the
alarm at OSS.

1.1.2.2.4

To verify CannotLoginUsingTNSError - Users cannot log onto Oracle


as the sysdba account using TNS emadb or emadbdg.
Description: The purpose of this test case is to verify the event
CannotLoginUsingTNSError - Users cannot log onto Oracle as the
sysdba account using TNS emadb or emadbdg.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC verified.
2) The Alarm CannotLoginUsingTNSError already defined in EMA
system monitor GUI.
Procedure: Follow the procedure as below:
Action: Login to EMA using user emadba
# su - emadba

Result: User emadba successfully logged in


Action: Login to sqlplus with specifying the TNS
tyEMA01$ sqlplus / as sysdba@emadb
Result: As the connection string is wrong, the user will not be able to
login and the alarm will be sent to OSS. Verify the alarm from OSS.
1.1.2.2.5

To verify DataGuard:NoneVipError
Description: The purpose of this test case is to verify the alarm
DataGuard:NoneVipError
Prerequisite: Following pre requisites needs to meet prior to
execution of this test case:
1) The connectivity between EMA and OSS RC verified
The alarm DataGuard:NoneVipError is already defined in EMA
system monitor GUI.
Procedure: Follow the steps mentioned as below:
Action: Login to EMA server 1 from user root and issue the below
command to stop the EMA dataguard vip
# su root
# crm resource stop dg-vip
Result: The dataguard vip stopped on node 2
Action: Login to EMA server 2 from user root and issue the below
command to stop the EMA dataguard vip
# su root
# crm resource stop dg-vip
Result: The dataguard vip stopped on node 2 and the alarm
DataGuard:NoneVipError raised on the OSS. Also the alarm
DataGuard:VipOnStandbyServerError will be raised.
Post requisites:
1) Login to server 1 from user root and issue the below command to
start the dataguard vip
# su root

# crm resource start dg-vip


2) Repeat the above step on server 2 to start the dataguard vip.
1.1.2.2.6

To verify DataGuard:VipOnStandbyServerError
Description: The purpose of this test case is to verify the alarm
raised on the OSS when dg-vip is not running on standby server.
Prerequisite: The following prerequisites need to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is verified
2) The alarm DataGuard:VipOnStandbyServerError already defined
o the EMA system monitor GUI.

1.1.2.2.7

To verify DataGuard:NoObserverOnStandbyServerError
Description: the purpose of this test case is to verify the alarm
DataGuard:NoObserverOnStandbyServerError.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is verified
2) The alarm DataGuard:NoObserverOnStandbyServerError already
defined in EAM system monitor GUI.
Procedure: Follow the procedure as below
Action: Login to server 2 as user root and restart the dataguard to
view and verify the alarm
# rcopenais restart
Result:
The
dataguard
will
restart
and
the
alarm
DataGuard:NoObserverOnStandbyServerError will be raised on the
OSS.
Note: Many other dataguard related alarms may also be raised as we
are restarting the dataguard. These alarms will be ceased when the
dataguard is started again, ignore these alarms.

1.1.2.2.8

To verify DataGuard:ObserverOnPrimaryServerError
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:

1) The connectivity between EMA and OSS RC is verified


2) The alarm DataGuard:NoObserverOnPrimaryServerError already
defined in EAM system monitor GUI.
Procedure: Follow the procedure as below
Action: Login to server 1 as user root and restart the dataguard to
view and verify the alarm
# rcopenais restart
Result: The dataguard will restart and the alarm
DataGuard:NoObserverOnPrimaryerverError will be raised on the
OSS.
Note: Many other dataguard related alarms may also be raised as we
are restarting the dataguard. These alarms will be ceased when the
dataguard is started again, ignore these alarms.
1.1.2.2.9

To verify Dataguard:ToStandbyStatusError - The Data Guard status


on the primary server is not TO STANDBY.
Description: The purpose of this test case is to verify the event
Dataguard:ToStandbyStatusError.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS verified
2) The alarm Dataguard:ToStandbyStatusError already deifned in
system monitor GUI
Note: The procedure for this test case is still under discussion and
will be updated after the clarifications.

1.1.2.2.10

To verify the Dataguard:DiskExhaustedError - Disk partitions for


emadb or emadbdg are exhausted.
Description: The purpose of this test case is to verify the event the
Dataguard:DiskExhaustedError which is sent to the OSS when Disk
partitions for emadb or emadbdg are exhausted.
Prerequisite: The following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS successfully verified.
2) The alarm Dataguard:DiskExhaustedError already defined on the
EMA system monitor GUI

Procedure: Follow the procedure as below:


Action: Fill the partition on which emadb or emadbdg is mounted
woth some junk data till the partition is almost full
Result: The alarm Dataguard:DiskExhaustedError sent to the OSS
Post requisite: Delete all the Junk data that was added in this test
case to EMA server to cease the alarm.
1.1.2.3

Database Alarm

1.1.2.3.1

To verify Database: DBMaintainScriptFailed - Database Maintain


Script Failed
Description: The purpose of this test case is to verify the event
Database: DBMaintainScriptFailed which is sent to the OSS when the
Database maintainence script fails to run.
Prerequisite: None
Note: The risk factor for trigerring database related alarm manually is
under internal discussion and this test case will be updated after the
discussion.

1.1.2.3.2

To verify Database: ArchivelogBackupFailed - Archive log backup


failed
Description: The purpose of this test case is to verify the event
Database: ArchivelogBackupFailed which is sent to the OSS when
the archieve log backup fails.
Prerequisite: None
Note: The risk factor for trigerring database related alarm manually is
under internal discussion and this test case will be updated after the
discussion.

1.1.3

PC /CA alarms

1.1.4

Hardware Alarms / Events

1.1.4.1

System Resources

1.1.4.1.1

To verify event System resources: CPU


Description: The purpose of this test case is to verify the alarm
raised on the OSS when CPU usage has reached the threshold
value.
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion

1.1.4.1.2

To verify event System resources: LoadAverage


Description: The purpose of this test case is to verify the alrms
raised on the OSS when Load average has reached the threshold
value.
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion

1.1.4.1.3

To verify event System Reources:Disk


Description: The purpose of this test case is to verify the alarm
raised on the OSS when the Disk usage has reached the max
threshold value.
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.

Result: The result will be added after the internal discussion


1.1.4.1.4

To verify event system resources: Swap


Description: The purpose of this tet cases is to verify the alarm
raised on the OSS when the swap has reached the threshold value.
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion

1.1.4.1.5

To verify System resources: Memory


Description: The purpose of this test case is to verify the event
system resource:Memory.
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion

1.1.4.1.6

To verify System resources: Interface


Description: The purpose of this test case is to verify the event
system resources:Interface
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion

1.1.4.1.7

To verify system resources: Process


Description: The purpose of this test case is to verify the event
system resources:Process
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion

1.1.4.1.8

To verify System resources: Local Device


Description: The purpose of this test case is to verify the event
System resources:Local Device
Prerequisite: the following prerequisite needs to be met prior to
execution of this test case:
1) The connectivity between EMA and OSS RC is sucessfuly verified.
Procedure: The procedure is under internal discussion and will be
updated after that.
Result: The result will be added after the internal discussion