System Startup sequence: The first task started is StartPxc with the entry point pxc().

pxc() instantiates the CpCardManager_i , the CorbaManager and other managers and provisioners in the pxc() function. Starting as a CORBA servant object by calling the function activateServant internally calls the getInstance() method over the class to instantiate the singleton object and register it with the naming service of the CORBA. 1. pxc() { 2. CpCardManager_i is activated as a CORBA servant object. This is with name CardManager 3. Auth_i started as AuthenticationServer . 4. NodeManager_i started as a CORBA servant object. With the name NodeManager . . . } Then pxcMainComplete() is called by pxc() and then this task is delayed indefinitely because we don t want the arguments on its stack

The CpCardManager_i then further initializes the following objects: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. IP Service Manager IpServiceMgr::getInstance() Replication Manager BackupNRM::getInstance() Corba Setup CorbaSetup::getInstance() Config Registry startCfgReg(); Force creation of NMS interface?? NmsIntf::create(); Set time TimeZone::getInstance() Alarm manager AlarmMgr_i::getInstance() Cp Redundancy CpRedundancy::getInstance() Control Shelf Manager ControlShelfManager_i::getInstance() CP Proxy service CpProxy::getInstance()

Attach with CpRedundancy as observer and get current role in case we miss updates. This is followed by starting up of pxc event server: es = new EventServer(EventServerParams);es->start;

The EventServer:

PxcEventServer_i PxcPortEventServer_i PxcCardEventServer_i Data members of PxcEventServer_i: 1. struct subjects { subjects(const char * _id, PxcEventConsumer_ptrec, NS_PxcEvent::EventSubType t) : id(_id), consumer(PxcEventConsumer::_duplicate(ec)), type(t) {} PxcEventConsumer_var consumer; string id; NS_PxcEvent::EventSubType type; }; 2. typedef list<subjects>SubjectList; 3. typedef map<string, SubjectList*, less<string>>SubjectMap; 4. SubjectMapmySubjects; 5. EventServer&myEventServer; 6. AMutexmyMutex; 7. string myServerType;

The subscribers call attach() to get them added to the SubjectList. subject is basically a char*, which tells the type of event the consumer is subscribing to. Its All if the consumers wants to be notified of all the events for that event server object ( viz. PxcPortEventServer_i , and PxcCardEventServer_i ). Hence a map of these lists is created called SubjectMap, which maps the lists against the event type. For example, a map is made like ( All , consumer1, consumer2, ). When an event occurs, the event will be pushed to the consumers by calling the function myEventServer.addEvent(si->consumer, pxcEvent);

The event server, basically, runs as a thread and maintains a queue of events, viz. EventQEntry. This list is popped and sent to the consumer in the entry, like this: for(;;) { EventQEntry* entry; { GuardMutexlock(myEventListMutex); if(myEventList.empty()) break;

entry = *(myEventList.begin()); myEventList.pop_front(); } // release lock

// Update the consumer with the event entry->aConsumer->update(entry->event); delete entry; } Where, PxcEventConsumer* consumer, PxcEvent& event. Refer: /vobs/pxc/src/NodeServices/PxcEvent/server/EventServer.cpp for details. Probably this has been replaced by the Corba Event service. Have to find out.

The next step is to do the rest of the initialization: initComplete(); What all are done by this function: 1. addCommonOperationalMonitors 2. Get the Active lan interface 3. Initiate Heartbeating HeartBeatMonitor::getInstance(

AdcStateHBMonitorParams, newAdcStateHeartBeatMsg(), interfaceAddr, multicastAddr );

CpStartup: Starts up the CP services, basically the ControlShelfManager_i and NodeManager_i. The services which logically belong to CP: Startup::service_IpServiceMgr, // Internal Lan Startup::service_corba,

Startup::service_CpCardManager, // System services

Startup::service_Replication, Startup::service_ConfigRegistry, Startup::service_CpRedundancy, Startup::service_ControlShelfManager, Startup::service_CpProxy, Startup::service_AlarmMgr, Startup::service_AuthServer, Startup::service_NodeManager, Startup::service_NodeProv, Startup::service_ControlShelfProv, Startup::service_IoShelfProv, Startup::service_OooCardProv, Startup::service_OooNRVCardProv, Startup::service_OOORS15CardProv, Startup::service_AMP15CardProv, Startup::service_OAORSCardProv, Startup::service_OAONRCardProv, Startup::service_CSCardProv, Startup::service_RGNNRCardProv, Startup::service_OOOFRXCardProv, Startup::service_Drv16CardProv, Startup::service_BdmCardProv, Startup::service_PwrCardProv, Startup::service_SysmonCardProv, Startup::service_OooSMFCardProv,

Startup::service_OooMMFCardProv, Startup::service_NOPCardProv, Startup::service_PROXYCardProv, Startup::service_OooRSVCardProv, Startup::service_IoscCardProv,

NodeManager_i:

Functions of NodeManager_i during initialization: 1. 2. 3. 4. Initiate Standby Initiate Active Register callback with CpCardManager_i to get to know the role changes. And for the Standby card it is made sure that the cfgreg files directory structure is created.

1. Initiate Standby NodeManager_i::initStandby() Start the heartbeat manager if This CP is not a Standlone. Question: I understand that AdcStateHeartBeatMgrworks by sending UDB based socket pulses. But how this is structured in classes? 2. Initiate Active NodeManager_i::initActive Populates the CardStateDB in /Node/Manager format strings in the cfgreg. If it is not a standalone setup, then heartbeat monitoring is started. AlarmMgr_i is started by the CpCardManager_i when the CpCardManager_i is initialized as a singleton object.