Abstract: Information on GDMO managed objects, including class hierarchy and the name binding templates, is compiled into a naming table. This naming table is built from an inheritance table and the name binding template information. The inheritance table indicates the inheritance hierarchy of the managed object classes. The compiler builds the inheritance table as a square matrix with a row and column for each class, and the classes arranged in an ordered list from highest to lowest in hierarchy. The compiler enters a one at each position in the inheritance table to indicate that the managed object class in the row inherits from the managed class in the column.With the inheritance table as a ready reference, the compiler builds the naming table from the name binding templates available as listed in the GDMO source files. The naming table is a square matrix identical to the inheritance table except the entries in the naming table are not ones and zeros.

Abstract: Managed Object Instances (MOIs) in a network of OSI computing systems are created, or deleted, without disrupting their interaction with other managed object instances. This is accomplished by a multi-phase commit process operation where in the first phase, a create or delete request is verified, and the CMIP platform places the created or deleted MOI on a pending list in the CMIP platform, along with information identifying the location of the MOI in a hierarchy of MOIs. In the second phase, the object being created or deleted is asked to accept, or reject, the request. The object responds saying that it accepts or rejects the request. If the request is acceptable, the CMIP platform finishes the object's connection to the tree hierarchy, or disconnects the object from the tree. Then the CMIP platform sends back a message to the object to acknowledge the creation of the object, or to tell the object to delete itself. Finally, the CMIP platform sends a request completion message to the manager.

Abstract: A new event forwarding discriminator (EFD) EFD named the persistent/impervious event forwarding discriminator (PI EFD) is described herein. The PI EFD is monitored by the agent infrastructure in such a way that if the agent goes down, and thus the PI EFD goes down, the agent rebuilds or restores the PI EFD with all its attributes. The PI EFD immediately creates an event notification indicating a create PI EFD event has occurred. This event notification is of the type passed by the PI EFD to the manager. The manager then knows the poll its other EFDs at the agent and recreate them as necessary.To foil rogue managers, the PI EFD can not be deleted by other managers. Also, the PI EFD has limited attributes that can be changed. A rogue manager can only add himself to the destination list; it can not otherwise change the attributes of the PI EFD.