User guide

3-268
Cisco Transport Manager Release 9.2 GateWay/CORBA User Guide and Programmer Manual
OL-20937-01
Chapter 3 Using CTM GateWay/CORBA Interfaces
3.13.5 getCTMHistoryPMData
3.13.5 getCTMHistoryPMData
Synopsis
public void getCTMHistoryPMData(
in nmsSession::NmsSession_I client,
in PMTPSelectList_T pmTPSelectList,
in PMParameterNameList_T pmParameters,
in globaldefs::Time_T startTime,
in globaldefs::Time_T endTime)
raises (globaldefs::ProcessingFailureException);
Description
This interface instructs the EMS to store historical PM data in a file, and to notify the NMS when the
request is complete. Within the request a list of TP/layerRate measurement points and a time frame are
specified. For each measurement point, the granularity (15-minute, 24-hour) and location
(PML_NEAR_END_RX, PML_FAR_END_RX) can be specified. A filtered set (scoped by the input
parameter pmParameters) of PM parameters collected for a particular TP/layer tate measurement point
for the specified granularity, location, and time window is made available.
Measurement intervals and the time frame are considered as half-open intervals to the right (that is,
startTime <= t < endTime).
Performance monitoring data on multiple TPs of multiple MEs is transferred in one data file. The PM
file format is defined by the TMF. CTM generates a unique filename and saves the file in the
CTMS-home/pmData/username/ directory. This file is retained for six hours after CTM finishes writing
the requested PM data. After six hours, the file is deleted. When CTM GateWay/CORBA restarts, it
retrieves a list of all existing PM files and deletes them after six hours.
This is an asynchronous operation. Once CTM receives the request, it validates it and the call returns. In
the background, CTM begins writing to the file. Upon successful completion, it notifies the NMS session
by invoking nmsSession::NmsSession_I::historyPMDataCompleted. If CTM fails to create this file or
write into the file, the NMS is notified by invoking nmsSession::NmsSession_I::historyPMDataFailed.
CTM allows only one request from each NMS session at a time.
For ONS 15454 SDH NEs, this operation is not supported on low-order STM-path, but is supported on
path parameters on E3 and DS3 cards.
For the DS1 module, this operation is not supported on STS/HO path, but is supported on VT data
(SONET) and VC11 data (SDH).
For the E1 module, this operation is not supported on STS/HO path, but is supported on VT data
(SONET) and VC12 data (SDH).
For the E3 module, this operation is not supported on HO path, but is supported on VC3 data (SDH).
For the DS3 module, this operation is not supported on HO path, but is supported on VC3 data (SDH).
CTM raises an EXCPT_UNABLE_TO_COMPLY exception if another request comes from a session for
which one request is already in progress. At any given time, CTM has a maximum of eight such requests.
This restriction is imposed because multiple requests downgrade the CTM database performance and
have an adverse impact on CTM.
Relevance of the validity status for historical PM data and the one-to-one mapping from PM data on the
EMS (CTM) to CTM GateWay/CORBA:
• –1—The PM parameter is not applicable to the module in that particular physical location (N/A).
The validity status is Invalid.
• –2—The PM data bucket is empty for the parameters in the module, for a time interval (blank). The
validity status is Invalid.