JPH02277153A - Entity management system - Google Patents

Abstract

PURPOSE: To allow a new managing module to be adapted to topology and its change by adding another pointer to the new managing module so as to manage with adaptability and extendibility. CONSTITUTION: The system is provided with at least one presenting modules 10A to 10K, function modules 11A to 11M and access modules 12A to 12N. A presenting module 10 communicate with a function module 11 through a presenting and functioning kernel 13, the function module 11 communicates with an access module 12 through through a function and access kernel 14. A function requested from control modules 10 to 12 is changed by information managing devices 15 and 20 and dispatchers 16 and 21 and stored in a data storage devices 17 and 22. Thus the more capacity of managing a composite system is, the more the capacity of managing a controller is.

Description

DETAILED DESCRIPTION OF THE INVENTION Field of the Invention This invention relates generally to the field of complex system management, and more particularly to apparatus for managing complex systems, such as distributed digital data processing systems.

BACKGROUND OF THE INVENTION As digital data processing systems, or computers, become smaller and less expensive, individual computers are being used by individuals and small groups. To increase the economies associated with the distribution of data, communication between users, and resources that are used infrequently by individuals, computers, in addition to those directly used by each user, are connected to a network that communicates by means of messages conveyed through communication links, including servers that store large amounts of data that may be accessed, used, and updated, thereby facilitating the distribution of the data. It is coming. The server may also control printers, telecommunications links, etc. In addition, the server may perform specialized computational services such as database searching, classification, etc. The various computers, clients, and servers are interconnected by communication links to enable messages to be transferred between the various computers and servers that make up the distribution system.

SUMMARY OF THE INVENTION The present invention provides a new and improved controller for controlling and monitoring complex systems, such as distributed digital data processing systems, in which multiple computers communicate through a local area network. This is what we provide.

Briefly summarizing, the controller includes one or more presentation modules, a functional module, and an access module that processes requests generated in response to instructions from an operator through kernel means and displays responsively to the operator; It is equipped with The presentation module handles operator interface functions including receiving commands from an operator and presenting responses thereto. In response to instructions from an operator, the presentation module generates requests. The kernel means receives the request and communicates it to the functional modules for further processing. Functional modules handle general functional operations in connection with processing requests.

In response to a request, a functional module generates one or more requests (sometimes referred to below as dependent requests for convenience), which are forwarded to kernel means or to other functional modules for processing. .

The kernel means communicates received dependent requests to the access module for processing. Access modules handle primitive operations in relation to the entities that make up the complex system.

In general, in one aspect, the present invention is a system for controlling and performing management functions for a population of entities, wherein the entities interface with the population to control primary information processing functions and the entities further interface with the system. It is characterized by being able to perform management functions. the system,
a storage management module configured to perform management functions by independently translating and executing predetermined management-related instructions;
It includes a kernel with a table of dispatch pointers that translates and directs instructions to the respective modules to be executed, and a register that registers new management modules with the system by adding pointers to the table.

The management module is adapted to modify management parameters of the entity or enable a self-test mode in response to one or more requested state information from the entity. The system also stores management specification information that lists attributes related to the functionality and control of an entity, and management functions of an entity, according to a universal specification language with a common syntax for representing the attributes and behaviors of any manageable entity. We are prepared. Management specification information may further list attributes and behaviors of entities that are subordinate to other entities. The management specification information includes polling information in a predetermined field of a common syntax.

The polling information includes fields that specify a default rate and a maximum polling rate at which the value of the attribute should be requested from the entity. The management specification information may also include partition information in certain fields of the common syntax. Zero partition information represents a group of attributes having a common data format.

The management specification information can also include set information in a predetermined field of a common syntax. Aggregate information represents a group of attributes with functionality related to the management of an entity.

The management specification information can also include command information in a predetermined field of the common syntax, and the command information describes the management function that the attribute is supposed to perform, the structure of the command to be issued to the entity, and the structure of the reply to be received. It is something to list. The structure of the request to be issued includes fields that list the arguments to the command. The structure of the reply to be received includes fields used to indicate successful completion of the requested action. The structure of the reply to be received includes fields used to indicate error conditions that will prevent the requested action from successfully completing.

At least one management module includes an access module implementing a protocol for communicating with one or more entities. The protocol is the Industrial Ethernet standard, DECnet Phase IV standard, or DEC
NET Phase V standard.

Each instruction includes fields that list at least the associated entities and operations, and the kernel includes a dispatcher that receives and dispatches instructions based at least in part on the individually listed entities and operations.

The table of dispatcher pointers consists of a directed graph of data structures, a continuous data structure with a graph corresponding to the fields of the instruction. The dispatcher includes a scrutinizer that traverses the instruction graph according to the entities and operations listed in the instruction and locates terminal data structures with dispatcher pointers. The instruction graph includes wildcard flags and continuous data structures that correspond to the values of particular fields of the instruction.

The instruction graph includes ellipsis flags and continuous data structures that correspond to any number of values of the fields of the instruction.

The scrutinizer finds the most accurate match for the field in the instruction by first looking for an exact match for the field and then a wildcard match for the field, or by first looking for an exact match for the field and then an ellipsis match for the field. and a best-fitting unit that determines the best fit.

The system includes a presentation device for displaying information to a user and receiving instructions from the user, the instructions and information being in a particular predetermined format.

The presentation module receives instructions from the presentation device and conveys information to the presentation device, where the presentation module includes a conversion code that converts the information received from the entity into a predetermined format for the presentation device, and conveys the instructions from the presentation device to the dispatcher. Equipped with a transmission code. The presentation module includes user interface information that defines the mode in which a user interacts with the system. User interface information comprises assistance information that provides information to the user regarding how to use the system. The user interface information includes graphical mode information that defines the contents of the pop-up menu and imperative review tables.

The kernel also has a class database that specifies the different management information available from each entity. The presentation module includes a menu generation routine that extracts data from the class database and generates a menu of valid instructions to display to the user. The menu generation routine is adapted to determine information regarding the composition of the population and generate a menu of available entities for display to the user.

The register is configured to register a new management module at any time during system operation.

The system includes a storage device with records related to administrative functions, each record with an associated time indication. The instructions specify a time range, and the system may also access information regarding the specified time range, if possible, by retrieving administrative information contained in the records, and at other times from members of the network. Accordingly, an information manager is provided with means for satisfying the command. At least one module includes a rule generator that identifies a predetermined alarm condition and generates a stored rule, and an alarm condition detector that detects an alarm condition in response to the content of the rule. The first category of management modules comprises functional modules adapted to perform functional manipulation of data provided by members of the network.

The second category of management modules comprises access modules adapted to implement protocols for communicating with members of the network. There is also a presentation module adapted to use the primary information processing capabilities of the members of the network to receive instructions from and convey information to the user.

The storage device also includes region specification information that defines groups of members of the network, such that the kernel issues commands to all members of a group by issuing individual commands to the appropriate management module.

The information manager includes a scheduler responsive to instructions specifying a time schedule, the scheduler possibly allowing subsequent dependent accesses or retrievals according to the time schedule, possibly multiple times in response to the instructions.

In general, in other aspects, the present invention provides a system for controlling a population of entities and performing management functions by independently translating and executing predetermined management-related instructions. It is characterized by having a management module that is designed to be stored.

General Description FIG. 1A is a functional block diagram of an apparatus constructed in accordance with the present invention for controlling and monitoring the status and conditions of a complex system. An example of a complex system controlled by the apparatus shown preliminarily in FIG. 1A (the complex system itself is not shown) includes computers, terminals, terminal servers, and other devices that communicate by means of messages transmitted over a network. Consisting of multiple nodes containing constituent elements,
Equipped with a distributed digital data processing system. An example of such a digital data processing system is described in a US patent application. It will be appreciated, however, that the controller shown in FIG. 1A is not limited to controlling distributed digital data processing systems, but can be used to control many different types of complex systems.

Such complex systems require management, especially since the state and capabilities of the complex are constantly changing. Therefore, the management facilities and functions it provides must also change to adapt to the new management requirements of the system. This allows the device to be modified to efficiently adapt to complex systems.

For the purposes of this document, we will refer to the components of a complex system as entities. Describe entities in terms of classes and stages. An entity class specifies a particular type of entity. For example, one class includes all local area network bridges from a given vendor. Each entity is a member of a class and forms a stage of that class.

Referring to FIG. 1A, the controller controls the presentation module IO
A to 10K (identified as a whole by the reference numeral lO),
Functional modules IIA to IIM (generally reference numeral 1
1), and access modules 12A to 12M (generally identified by the reference numeral 12). Presentation module 10
generally provides a user interface for a user to take control of a complex system, including control of terminals used by system operators. Each functional module 11 generally performs administrative control and monitoring in connection with a class of functions, and each access module 12 generally provides administrative control and monitoring in connection with a class of controllable entities within the control system. Presentation module 1 that performs administrative control over controllable entities of the form
0 communicates with the ti function module 11 through the presentation and function aspects of the kernel 13.14 (hereinafter referred to simply as the presentation and function kernel 13), and the function module 11 communicates with the kernel 13.
．． The access module communicates with the access module through fourteen function and access aspects (hereinafter simply referred to as function and access kernels 14).

The functionality required from the control module 10.11.12 may vary widely depending on the topology of the complex system being managed. Therefore, for adaptive and scalable management, control modules 10.1-1.12 can dynamically add and subtract devices to and from a particular complex system topology. can be adapted to changes in the topology of

Furthermore, for the purpose of adaptability and scalability, the control modules 10.11.12 form a "work force" for the tasks to be performed in the management of the complex system. In this way, for example, duties associated with the management protocols of the distributed data processing system can be separated from duties associated with, for example, displaying management information to the user.

A. Presentation Module More specifically, the presentation module 10 performs presentation services, such as system
Operator accesses various function modules 11 and
A user interface, such as a video display terminal, personal computer, or computer workstation, that controls module 12 and that can be used to control and monitor various entities within the complex system.
It can be configured from an interface support device. The services presented are required independent of the management function or entity managed by the system shown in FIG. 1A, and are therefore provided regardless of the nature of the management function or entity.

Each operator interface or terminal can be controlled by multiple presentation modules. Various presentation modules 10 control various aspects of the operator interface, including such details as portraits, menus, graphics, and assistive devices for displaying and reviewing command lines. Other presentation modules 10 provide specific output support for various types of graphical displays, such as histograms, bar diagrams, pie diagrams, or other forms of pictorial representations to be displayed on the terminal screen to the operator. , yet another presentation module 10 sends administrative requests to and from the presentation/function kernel 13, which may be annotated by portraits, menus, graphics, or commands entered by the operator on the command line. Transferring the management information to a video display terminal used by an operator for display.

B. Illustrated Module Functionality module 11 is associated with and supports specific management applications performed by the controller shown in FIG. 1A. The management application includes the presentation services performed by the presentation module 10 (other than to the extent that the presentation module 10 informs the operator about the management applications performed in the control management) and the specific services that make up the complex system being managed by the control management. exists independently of the entities in it.

A management application that the functional module 11 can perform is, for example, analyzing the communication load of a distributed data transmission system. To perform such an analysis, the functional module accesses communication data such as the number of packets and the number of bytes sent by several entities of the distributed data transmission system.The functional module then averages the information. Check against higher level information such as packet size and communication resource utilization of the transmission system. This information can then be sent to the user or made available to other functional modules when running other management applications.

As can be seen in the above example, functional modules add value to the management information available from the complex system in the form of data matching or correlation services.

In addition, the functional module utilizes data produced by other modules to provide high-level services for managing the complex system.

In one particular controller for controlling a distributed digital data processing system, one functional module 11
, for example, manages the topology of the network and presents the topology to the operator through the presentation module 10 .

Other functional modules 11 define, for example, the configuration of the distributed digital data processing system, i.e. the various stages of entities and their interrelationships, and allow nodes and other entity stages to be added or subtracted from the network to provide operator control. A configuration system that allows an operator to control the configuration of a network, change access rights for various users of a node, and maintains a configuration (or stage) database that allows an operator to decide on changes to the configuration of a network at any time. A functional module can be provided.

Other functional modules 11 within the controller may, for example, control various alarms indicating that a predetermined event has occurred in the distributed digital data processing system. The alarm module 11 monitors the status and conditions of various entities of the distributed digital data processing system and generates alarm instructions to the operator, while an appropriate presentation module 10 responds to the status or condition having a predetermined value. and advise the operator.

Still other functional modules 11 may, for example, define the domain of an entity within a distributed digital data processing system, limit authority for control or monitoring by an operator, or facilitate control or monitoring by an operator.

Other functional modules 11 operate, for example, as historical data recorder functional modules 11, periodically balling various entities in the complex to determine their values at particular times and establishing a time and numerical database. , making it easier to maintain and create usage statistics.

Still other functional modules 11 are not capable of controlling certain aspects of the complex, but instead act as walk-throughs, allowing operators to control or monitor primitive functions of the complex through direct access modules 12. Make it.

The services and operations of the access modules 12 may be required, and the functional module 11 supporting the management application coordinates the sequence of operations by the various access modules 12 necessary to perform the management application.

Additionally, a management application provided by one functional module 11 may require an aggregation of other functional modules 11 within the control device, whereby that one functional module is also coordinated.

Function module 11 is initially called by presentation and function kernel 13 in response to an administrative request entered by an operator obtained by presentation module 10 . Functional modules 11 are also called by requests received directly from other functional modules 11. Thereupon, functional module 11 can generate requests for processing by access module 12.

C. Access Module The access module 12 is associated with various primitive management operations provided by the controller in connection with the various entities that make up the complex system managed by the controller shown in FIG. 1A; We support this. For example, in a distributed digital data processing system, an entity refers to the various hardware of the system, including various computers, disk and tape storage devices, routers, etc., that can constitute the nodes of the distributed digital data processing system. In addition to components, it can also include software components, including virtual circuits, databases, and the like.

Access module 12 is called by function access kernel 14 in response to a request from function module 11.

The access module 12 that controls and monitors the distributed digital data processing system can control several different types of nodes or different levels to generate and transfer messages depending on the message transfer protocols used by the nodes. . One access module 12 can, for example, control and monitor the status of various parts of a bridge connecting two local area networks, and can route messages between two local area networks.
To enable communication between nodes of an area network. Such an access module 2 is
For example, you can initialize a bridge, enable it to start working, disable the bridge, monitor its end-to-end operation, see how many messages are passing through the buffers it has, and You can check whether you have enough buffers to operate effectively.

Other access modules 12 include various timers that indicate the operation of the message generation and decoding portions of the various nodes of the distributed digital data processing system, the virtual circuits, the sessions and other links established between the nodes, and the activity and inactivity associated therewith. and counters, etc., can be controlled and monitored.

Similarly, other access modules 12 control and monitor network layer portion operations of the node that control the actual transmission and receipt of messages through the network, including various message transmission receipt counters, transmission receipt timers, etc. be able to.

In addition to monitoring the values of various timers and counters, one node can maintain and establish other default and operating parameters using the access module 12 that controls both timers and counters. Limits on the number of concurrent virtual circuits and sessions may also be established.

In particular embodiments, the access module provides access connectivity testing or IEEE 802 functionality to management functions at Ethernet LAN bridges, port segmentation control and check functions at Ethernet repeaters, Alternatively, management capabilities in the FDDI entity can be provided. In addition, the access module is a DECnet Pha
s e IV or Phasev node, or DEC
It can be provided for accessing the management support device at the terminal server.

D. Request Control Modules 10.11.12 interact with each other and with users through requests. There are two general forms of requests. A request, for example, can cause something to occur within a complex system.

That is, the state or condition of the complex system can be caused to change. access to process such requests, in which one or more assessment modules 12 perform predetermined actions that change the state or condition of one or more entities of the managed complex system; - Module 12 generates state information indicating the state of the request and returns this to the function access kernel 14.

Alternatively, the request may request information regarding the state or condition of one or more entities in the system, and the entity is identified by the request.

In processing such requests, one or more access modules 12 determine the state or condition of the entity and return visibility information to the functional access kernel 14, or in other cases, to the controller ( Information stored (such as by a historical data recorder functional module) may be used to satisfy the request.

Alternatively, the request may be in the form of an image.

That is, a request may change the state or condition of one or more entities, and may also request information regarding the changed state or condition of the entity. In processing such a request, the access module 12 may cause changes and return state information regarding the state of the request as well as information regarding the state or condition of the entity.

The request may occur in response to operator action at the terminal presentation device. In that case, the presentation module 10 controlling the terminal generates a request and communicates this to the presentation and functionality kernel 13. In addition, requests can be generated directly by the appropriate functional module 11. for example,
A functional module 11 acting as a historical data recorder generates requests to periodically check the state or condition of each entity of the complex system and stores it in a historical database for later processing as required by the operator. let

E. Kernel Kernel 13.14 has information manager 15.20 (hereinafter simply referred to as information manager 15 or information manager 20, but they form one and the same information manager), dispatcher 16.21 ( (hereinafter referred to simply as dispatcher 16 or dispatcher 21, forming one and two dispatchers), and a data storage element 17.
．． 22 (hereinafter referred to simply as data storage device 17 or data storage device 22, forming one and the same data storage element as explained below).

F. Data Storage Devices Data storage devices 17.22 may include one or more RAMs with dispatcher data structures, or one or more fixed disk drives, or other storage, depending on the type and amount of data to be stored. Apparatus means may be provided. Additionally, data in different formats may be stored in various storage means for later use by the kernel.
All these means are combined into one data storage element 17.
Diagrammatically represented by 22.

Referring to FIG. 1B, in one embodiment, the data storage element 17.22 stores information at each time regarding the presence and status of the various entities that make up the complex system, and in particular the various entities controlled by the access module 10. Predetermined information regarding the status and conditions of the historical data recorder function module 11 has been obtained. t
Maintain at t. This is stored in the historical database 26. Other information may also be stored in data storage element 17.22. In particular, as explained above, the configuration module may form a configuration database 23 that indicates the existence of entity stages within the complex system. The realm module may store a database 25 that describes the realms of entities used to limit the scope of a user's control. Alternatively, realm information may be stored as an element of a configuration database.

The alarm module may also use the alarm rule base 24 to ascertain alarm conditions within the complex system.

Other information relating to individual modules within the control device may also be held in the storage element 17.22. For example, as detailed below, Dispatcher 16.21
The dispatch table 28 used by the dispatcher can store the location of modules and the operations, entities, and attributes serviced by the dispatcher. Additionally, the controller may maintain a data dictionary 27 that stores attributes, commands, and subentities for each of the various classes of entities within the complex system. This latter information may be used, for example, to process requests from users;
Alternatively, it can be used to generate a menu and prompt a user request.

G. Information Manager Referring to FIG. 1A, requests from presentation module 10 to which information manager 15 can respond using information in data storage element 17, as described in more detail below. Upon receiving the request, the information manager 15 intercepts the request, generates a response to the request, and sends it to the appropriate presentation module 1.
0 and display it to the operator who generated the request. If the information manager 15 is unable to respond to the request, the manager determines whether the request pertains to the current time or to a future time. That is, information manager 15 determines whether the request should be processed immediately or scheduled for a specific time in the future. At the appropriate time, either immediately or at a scheduled time, the information manager 15 forwards the request to the dispatcher 16. From the nature of the request, the dispatcher 16 identifies the functional module 11 to which the request should be sent and forwards the request to that functional module 11.

In response to receiving the request from dispatcher 16,
Functional module 11 begins processing the request.

In response to a request, a functional module 11 initiates one or more operations, hereinafter referred to as dependent requests, each represented by a request, and communicates this to other functional modules 11 or to the functional access kernel 14.

Upon receiving responses to all of the dependent requests, functional module 11 generates a response and communicates it to dispatcher 16 . The dispatcher 16 formats the response and communicates it through the information manager 15 to the appropriate presentation module 10 for display to the operator.

The functions and access aspects of the kernel 14 are handled by the information manager 20.
, dispatcher 21, and data storage element 22
A dependent request directed to the function access kernel 14 from a function module 1.1 comprising a function module 1.1 is initially received by the information manager 20. Data storage element 2
2 may also be provided with information originating from the historical data recorder functional module 11 regarding the state of the complex system at each point in time, in particular with certain information regarding the states and conditions of the various entities controlled by the access module 10. .

When information manager 20 receives a dependent request from functional module 11 to which it can respond using information in data storage element 22, the manager intercepts the request and generates a response to the occurrence of the dependent request. and transmits this to the functional module 11 that is the source of the dependent request. If information manager 20 does not respond to a dependent request from functional module 11, it determines whether the request pertains to the current time or to a future time. That is, information manager 20 determines whether the request should be processed immediately or scheduled for a specific time in the future. At the appropriate time, whether immediate or scheduled, the information manager 20 forwards the dependent request to the dispatcher 21.

In response to receiving the dependent request from the information manager 20, the dispatcher 21 identifies the access module 12 to which the dependent request should be communicated and forwards the dependent request to this access module.
Transfer to module 12.

In response to receiving a dependent request from dispatcher 21, access module 12 begins processing the request. Access module 12, in response to the dependent request,
One or more operations associated with an entity of the controlled complex system may be initiated. If the dependent request requests access module 12 to change the state or condition of the entity, access module 1
2 attempts to do so and generates a response containing status information indicating the status of the attempt, ie, for example, whether the modification was successful, unsuccessful, or partially successful. On the other hand, the dependent request is access module 1
2 to identify the state or condition of the entity, the access module 12 generates a response indicating the state or condition of the entity. Finally, if the dependent request requests access module 12 to do both of the above, access module 12 attempts to change the entity's state or condition and updates the attempted state and the entity's new state or condition. It also generates a response indicating . In any case, the access module 12 communicates the response to the dispatcher 21, which transmits it to the functional module 11 that originated the request.
Transfer to. In formatting the Ii functional module 11, its response to a request from the dispatcher 16, or its response to a dependent request from another functional module 11, as applicable, the Use responses.

When a functional module 11 receives a dependent request from another functional module 11, it processes it in the same manner as it processes a request from a desbatcher 21.

advantage The control system shown in FIG. 1A has a number of advantages.

The controller essentially forms a processing chain in which each element along the chain attempts to process the request before passing it on to the next element. Accordingly, the information manager 15.20 can, based on the contents of the associated data storage device 17.22, without the need for further processing to other elements further down the chain.
If the request can be processed, the information manager 15.20
does so.

Furthermore, since the controller is expandable, additional presentation modules 10, functional modules 11, and access modules 12 can be easily added without changing the structure of the controller, as described below. The addition of a functional module 11 and an access module 12 that can be performed is done by way of a registration procedure, which will be explained below in conjunction with FIG. module to, ti
or 12 addition or deletion of certain data of data storage element 17.22, as described below.
This can be done by simply modifying the contents of the structure and the pond data structure maintained by the presentation module 10, as shown in FIG.

Additionally, the modular and expandable nature of the control device facilitates the management of the control device itself. The same dispatch and request models used to issue management commands to the complex system can also be used to issue commands to the management module itself. This eliminates the need for a separate management aggregation to manage the control device itself.

Additionally, since the functionality of a module is specified in a standard format and available to the control unit as a whole, the control unit becomes a complete user interface support for the module, allowing the module designer to branch out the user interface for each module. Free yourself from the burden of doing so. This type of "automatic" user interface support ensures a similar look and feel to the user interface, regardless of the source or nature of the management module being used.

When a controller is used to control a distributed digital data processing system, the controller, including its various elements,
There may be a plurality of routines processed by the various nodes and computers that make up the distributed digital data processing system. That is, the computer equipment does not need to process modules that make up the controller that controls the distributed digital data processing system in addition to those that make up the distributed digital data processing system being controlled; Using interprocess and internode communication mechanisms, communications, including requests, dependent requests, and responses, can exist in different parts of the same process, in different processes of the same node, and on different nodes. Transfers can be made between parts of a control device. If the modules reside in different processes on the same node or on different nodes,
The interprocess and internode communication mechanisms shown in FIG. 6 and described below are used to transfer requests and dependent requests, as well as responses, between various processes and nodes.

1. Entity Model Before proceeding further, it may be helpful to further explain the relationship between the controller shown in FIG. 1A and the complex system being controlled. In particular, with reference to FIG. 2A, the control device includes a command unit 35 with all of the presentation modules 10, a functional module 11, and an accelerator module 12, together with a kernel 13.14.

A complex system includes one or more entities 36. Each entity 36 includes a service element 31, a management interface 30 and a service interface 3.
It has 3. The management interface controls and monitors service elements through agents 34. A service element is the actually managed part of an entity 36 and performs the entity's primary functions or functions, i.e. the service element 31 performs the entity's functions required within the context of a distributed digital data processing system, e.g. , the service element 31 communicates when an entity communicates with a node through the network.

As noted above, service element 31 includes management interface 30 and service interface 33.
The controller is managed through an agent that communicates with the controller and in particular with the accelerator module 12. Communication through the management interface 30 facilitates opening and closing of the service element 31 and its initial configuration, and also allows the commander 35 to check the operating status of the entity 36. Communication through the service interface 33 allows the commander 35 to control and monitor the service elements 31 . If not, then
This establishes conditions for certain attributes, such as communication parameters in the case of the entity 36, e.g. communicating in the context of controlling the entity 36 or checking the value of a counter in the context of monitoring the entity 36. It is done by

An entity's management is characterized by the commands it supports and its attributes, which are parameters that broadly relate to its functioning and control as well as to commands. For example, in the case of a router where the entity communicates data packets through a distributed digital data processing network, the attributes of the router may include the number of packets communicated and the number of bytes communicated.

If the entity is a modem, the attributes may include counters and status registers related to modem operation. Examples of directives include 5HOW to search for attribute values;
and SET to modify attribute values.

Service interfaces are concerned with the functionality of the entity, and management interfaces are concerned with the behavior of the agent. The commands and attributes accessed through the service interface characterize the functionality of the entity, while the commands and attributes accessed through the management interface characterize the control and monitoring of the entity.

To clarify the role of the two interfaces and to provide an example of how to apply the above model to a specific entity, consider a controllable entity, a modem. A modem can have several functional attributes, such as baud rate, line selection, and power switch settings. Additionally, the modem may be provided with several management attributes, such as its line utilization and the amount of time elapsed since its last self-test. The baud rate, line selection, and power switch settings are related to the modem's immediate operation, and as such are accessible through the service interface 0 line utilization and the elapsed time from the modem's last self-test to general operation. , and itself are accessed through the management interface.

To refine the above example, note that the presentation module, while presenting management information to the presentation device, uses a service interface since the presentation of information is the primary service of the presentation device. However, the controller's accelerator module can also manage the presentation device, for example by polling and determining if it is on.

In addition to the attributes described above, there are other "pseudo-attributes" that are related to the entity but are not stored by the entity as such; pseudo-attributes are generally needed to describe the entity model, but are not stored by the entity. This is an attribute that is not provided.

- Examples are attributes provided by the entity IMPLEM
IMPLEMENTATION, which is a composition of ENTATION TYPE and VER3ION, and CREATIONTIME of the entity. Pseudo-attributes are maintained by the access module responsible for accessing the entity.

It is worth noting at this point that an entity model is a general way of describing the directives and attributes of an entity, and does not imply the internal structure of the entity itself. An entity model is a tool that allows a controller to consistently reference the behavior and attributes of any entity. Any entity can be "plugged in" and controlled by the control device of Figure 1A (
1) Describe this consistent with the entity model,
It can be managed by (2) implementing the appropriate access module and (3) plugging (registering) the access module into the control device.

J. Management of Management Modules As noted above, in the control device that controls the distributed digital data processing system, various presentation modules 10
, functional modules 11, access modules 12, and kernels 13.14 are processed by the various nodes that make up the distributed digital data processing system. In that case, various modules 10.11 and 12. and kernel 13.14 form an entity within the complex system and, as described above, the dispatch and request model used to issue management commands to a joint system that is controlled in the same manner as other entities. The management module can also be used to issue commands to itself. As can be seen from the dispatcher specification below, in addition to the management routines that manage the complex system, each module has self-management routines that manipulate the module's internal attributes. Both internal and external routines can be accessed by requests using request syntax. Therefore, as the ability to manage a complex system increases by adding new control modules, the ability to manage control devices increases as well.

Description A, Structure of the Management Module 1.1III12 Referring to FIG. 2B, in one particular embodiment:
The management module structure includes executable code 38 that implements the management functionality provided by the module. In particular, in the case of an access module, the executable code provides access protocols for the entity classes serviced by the access module.
In the case of functional modules, the executable code includes support for computing the higher level functionality provided by the module. In the case of a presentation module, the executable code comprises an interface protocol to the presentation device supported by the presentation module.

Modules may require proprietary storage to store various read-only and read/write variables related to the functionality of the module. This storage device is provided in the module as an allocated area 32. This storage can be used, for example, by the presentation module to store scrutiny table or presentation form data, or by the access module to store password information with wildcard requests (see below). .

Access points for the various procedures provided by the access module are dispatch entities 39A and 39.
It is indicated by the pointer of B.

As will be explained more fully below, the dispatch entity is fused to a dispatch table stored in kernel storage 17.22 and is used to locate the various procedures supported by the module. As shown in FIG. 2B, dispatch pointer 39A is associated with a procedure within a module that provides management services to the complex system;
B relates to procedures within the module that perform management services for the module itself. As explained above, when a module is registered with a controller, two sets of pointers are loaded into kernel storage for use in managing the complex or module that includes the controller.

In addition to the above structure, modules are also associated with the structure of commands and responses that request services from the module, as well as management specifications 48 that describe classes of entities and attributes serviced by the module. The management specification also specifies the management of the module itself. During module registration, the associated management specifications are loaded into the data dictionary.

2. Management Specification The nature, configuration, and structure of the service elements 31 and service interfaces 33 of various entities including the control device as well as entities of the complex system managed by the control device (FIG. 1) are based on the management specification and dispatch. Defined by specifications. 3A to 3D are details of entity management specifications, and FIG. 3E defines a dispatch specification used when starting a specific operation in connection with an entity. Referring first to FIG. 3A, the management specification for the entity is in the heading section 40.
and a main body portion 45.

Heading portion 40 includes a name field with a name that identifies the entity, a variant field with variant identification, and location information indicating the location of the entity within the complex (e.g., if the complex is a distributed digital data processing entity). If the system is a system, it includes certain identification information such as an equipment field 43 with the node identification) and a format declaration field 44 indicating predetermined data format information.

In an alternative embodiment, the heading portion also includes a symbol/prefix field used in conjunction with symbol field 52, described below.

The management specification body portion 45 contains the actual management specifications for the entity.The body portion 45 is further defined in FIG. 3A. Preliminarily, the controller comprises two general types of entities: global entities and dependent entities. The control device, as made clear above, provides management that facilitates a hierarchy of entities, with global entities identifying entities at the top level of the hierarchy and subordinate entities identifying entities that are subordinate to other entities in the hierarchy. The main body part 45 of the specification includes provisions for two types of entities, namely provisions 45A for global entities.
, t or provision 45C1 for dependent entities.

A management module can provide services to entities of a global class or to classes of subentities within a global entity class. A specific example is the DEC released by Digital Equipment, Inc. of Maine, Massachusetts.
net, occurs in PhaselV. DECnet P
In hase■, the adjacent node is a subordinate entity class, and its superior entity is a node 4 circuit. When a management node specifically services an adjacent node dependent entity class, the management specification provides a mechanism to indicate that the management specification for the global class exists within the management specification for other modules (which manage the Node 4 circuit class). We must prepare.

Provisions 45A and 45C for global entities and dependent entities, respectively, are further defined in FIGS. 3A-3D. The entity definition 46 comprises a name field 47 comprising a name and a code by which the entity can be identified. Additionally, name field 47 identifies the entity as a global or dependent entity and identifies the entity's class name. If the entity definition is for a subordinate entity, it includes an upper field 50 that identifies an upper entity in the hierarchy.

The identifier field 51 is later converted to the entity body portion 53.
It has a list of attribute names for the attributes defined in . Finally, symbol field 52 contains symbols used to generate special compiler constant files with consistent names for use by entity developers.

In another example, the entity definition may include a DYNAMIC field. This field has the value T
Can be RUE or FALSE, indicating whether the entity's management specifications should be stored in the configuration database (Figure 1B).

This gives the developer of the management module a way to precisely indicate which subordinate and subordinate entity levels should be stored in the configuration database. In this way, there is no need to store highly dynamic entities such as connections between nodes in the configuration of the system.

This eliminates the overhead caused by iteratively adding and subtracting dynamic steps. The pool value of the DYNAMIC field indicates whether the nature of the entity class is dynamic; if TRUE, the pool value of the entity class
Class stages are not stored in the configuration; if FALSE, entity class stages are stored in the configuration.

As noted above, the entity definition 46 for an entity includes a body portion 5 having a body portion 53.
3 is defined in detail in FIG. 3B. Referring to FIG. 3B, the main body part 53 of the management specification consists of four parts: an attribute partition regulation list 54, a collection regulation list 5, a command regulation list 6, and a list 53 of the management specification when the entity class contains subordinate entities. 0 with Dependent Entity Listruff If the body part 53 comprises a dependent entity listruff, then each item in the dependent entity listruff has an entity definition 46 with a name field 47 containing rsUBORD INATEJ.
(FIG. 3A) As mentioned above, the entity body consists of the attribute partition list 54
and an attribute set list 55.

At this point it is useful to explain the distinction between these lists. Each list takes a complete combination of attributes of an entity, and the groupings indicated by the 0-part list 45 combining each attribute into one or more groups are independent of those indicated by the set list, and each list is an independent precise specification of the attributes of an entity.

The partition list driver 4 identifies all attributes of the same shape and groups them. For example, the attribute PART I T I ON can include all counters or all state attributes (flags). The word "partition" is used to indicate that the group formed by the attribute partition is the true partition of the attribute. An attribute cannot be a member of two partitions; each attribute must be a member of exactly one partition.

The set list 55 identifies and groups all attributes that have the same function. For example, the access module for the Node 4 global entity class is '
An attribute set read as SQUAREJ can be defined. 5QUARE attribute set has 4 classes of attributes.
It may include all attributes related to the current performance of the entity, such as attributes in the form of counters indicating the number of bytes sent and attributes in the form of characteristics indicating pipeline allocation. In this example, the user would thus get 5HOW N0DE (instance > 8115Q
Commands like IJARE allow these statistics to be viewed together.

The term "set" is used to indicate that a set includes attributes that have similar functionality, but do not necessarily form a partition of attributes. An attribute can be a member of more than one set, and not all attributes need be members of a set.

Attribute partition definition list driver 4 may further include one or more attribute definitions 64 as defined in Figure 3B. Each attribute partition specification 64 identifies the attribute as a particular type of attribute, including an identifier-type attribute, a status-type attribute, a counter-type attribute, a characteristic-type attribute, a reference-type attribute, or a statistics-type attribute. A type field 56 is provided.

For each attribute format, the data format is an additional field 68
It is established by Attribute partition definition 54 may also include fields 6° and 61 indicating a default polling rate and a maximum polling rate, respectively, for the attribute. As noted above, the historical data recorder functional module 11 may periodically obtain status and condition information for storage in the data storage elements 17.22 in connection with various entities comprising the complex system.

The contents of the Polling Rate field identify the default rate and maximum rate at which each entity provides status and condition information. In addition, the attribute specification includes one or more attribute fields 62, each with an attribute name 63.
It is equipped with This field comprises a code by which the attribute can be accessed, and an associated attribute body 64. As shown above, all the specifications for attributes that are members of a partition are in one partition specification 54. Independent aspects of an attribute are represented by one or more attribute body definitions 64. Figure 3B is attribute section regulation 5
The information contained in the attribute body 64 of the attribute field of No. 5 is further described.

The attribute body 64 may include a number of fields, including an access information field 65 indicating whether the attribute can be read or written and a display field 66 indicating whether the attribute should be displayed to the operator by the presentation module 10. .

Default value field 67 identifies the default or initial value of the attribute. Symbol field 7° contains the symbol used to generate a particular compiler constant file with a consistent name for use by entity developers.

Attribute body 64 further includes a category field 71 that identifies one or more categories with which attributes can be combined. If the complex system is a distributed digital data processing system, the category is C0NF.
IGURATI 0NFAULT, PERFORMA
NCE, 5ECURITY, or ACCOUNTI
Attribute body 64 may include, but is not limited to, categories defined in the 74-98-4 Open Systems Interconnect (05I) standard, including NG. The polling speed for a specific attribute that is
If the polling speed is different from the polling speed specified in fields 60 and 61, fields 72 and 73 can contain polling speed information. Finally, the attribute body 64 includes a proprietary variable field 7 that identifies proprietary variables used by the management module when processing in connection with the attribute.
4 can be provided.

In another embodiment, polling speed information may be omitted from the attribute specification altogether, as the accuracy of this data is implementation specific. Additionally, in another embodiment, the attribute body 64 may include a UNIT field.

If the tJNIT field is provided, data in numeric format can have its specified units (
should be held).

Attributes can be grouped together to simplify the management of complex systems. The set definition portion 55 of the entity body 53 identifies one or more sets included in the entity. The contents of the attribute definition portion 55 are defined in detail in FIG. 3B. The set definition portion 55 includes a set name field 75 that identifies the set, and an attribute list 81 that identifies the attributes included in the set. The set definition part 55 may also comprise commands, ie requests, lists that can be processed by referencing the set.

The set definition portion 55 includes a symbol field 77 similar to the symbol field described above, a category field 80 which may include, but is not limited to, O3I category information, and a set identified by the set name in field 75. A proprietary variable field 82 may be provided that identifies proprietary variables used in processing associated with the attribute being identified.

The entities process commands generated by the controller in response to requests and dependent requests from the presentation module 10 and the functional module 11, respectively. Each command includes a command request that specifies the action to be taken, and can have responses and exceptions that specify the response that the entity takes in conjunction with the action. Each command is defined by a command regulation 56.

3C and 3D show the structure of command provision 56 in detail. Referring to FIG. 3C, the specification specification 56 includes a name field 83 with a code by which the command can be identified and accessed. The directive includes a requirement specification field 9 that identifies the structure of the requirement or dependent requirement.
0, a response definition field 91 that defines the structure of a response, and an exception definition field 92 that defines the structure of an exception that can occur during processing of a command.

Details of fields 90, 91 and 92 will be discussed below.

Command provision 56 determines whether the command is an action command, that is, whether the command can change the condition or state of one or more entities of the complex system, or whether the command simply returns a state or information. A field 84 may also be provided to indicate whether or not it is only a start. In another embodiment, the effect field 84 may be set to
INE, MODFY format or ACTION
It can be replaced with a DIRECT TYPE field indicating the type of the file. The EXAMINE directive operates only on attributes and does not modify them.

Examples are the 5HOW command or the DIRECTORY command. The MODEFY command operates only on attributes, examples of which make modifications are the SET, ADD, or REMOVE commands. The ACTION directive does not work on attributes,
CREAT as an example of operating on the entity itself
There is an E command and a TEST command.

A field 85 may be provided to indicate whether the command is accessible by the presentation module 10. An identifying text string may be provided in symbol field 86. The pond, category field 87,
As defined above in connection with field 71 (FIG. 3), one or more O8■ categories may be defined, but are not limited to this.

The structure of the requirement specification field 90 of the command specification 56 is defined in FIG. In addition to the word rREQUEsT,
The request specification field 90 contains zero or more arguments 91 defined in the name field 92, each containing an access code.
can be provided. Additionally, the argument may include a display field 93 indicating whether the argument should be displayed to the operator by the presentation module 10. The argument includes a field 94 indicating whether the operator must provide a value for the argument, a default field 96 containing the default value, a symbolic field 97 containing an identifying text string, and a measurement of the argument value. A unit field 95 may also be provided to indicate the unit of . Additionally, the argument 91 may include a proprietary variable field 100 that identifies proprietary variables used in processing in conjunction with the argument.

Response provision field 91 and exception provision field 92
The structure of is shown in Figure 3D. With reference to Figure 5D,
The response specification field 91 comprises a response name field 101 which can contain a code by which the response can be accessed. The violent field is 5U when the response fulfills the request specified by the request field.
Whether CCESS is indicated or the response is INFORMA
TIONAL or not. Text field 103 indicates a text string that presentation module 10 can display to the operator to indicate a response. In addition, the response specification fields each include a name field 105 . One or more argument fields 104 may be provided, including a unit field 106 and a symbol field 107.

In an alternative embodiment, the intensity field 102 can be replaced with a symbolic field with an identifying text string for the response, and the arguments field 104 includes a pool display field that indicates whether the response should be displayed to the user. be able to.

The structure of the exception definition field 92 is similar to the structure of the response definition field 91, which includes fields 111 to 117 similar to fields 101 to 107 of the response definition field 21. However, the severity field 112 indicates the severity of the error causing the exception, WARN
It can have three values, including ING, ERROR and FATAL.

In other embodiments, as in response provision 91, intensity field 102 may be replaced with a symbolic field with an identifying text string for the response, and argument field 104 indicates whether the response should be displayed to the user. 3. Dispatch Use Figure 3 defines dispatch use 39A (Figure 2B), which is used to specify the initiation of a particular action by an entity. Ru. The information in the dispatch usage for an entity is used to generate a pointer to the procedure that performs the operation. Referring to FIG. 3E, a dispatch use includes a heading 200 defining the beginning of the dispatch use and containing the table name, and a footer 200 indicating the end of the dispatch use.
01. Between the heading 200 and the footer 201, the dispatch usage includes one or more dispatch entries, each of which defines an action in association with one or more entities and attributes.

A dispatch entry comprises a verb portion 203 and an entity entry 204, which together identify an action. Effectively, the verb portion 203 and entry portion 204 of the dispatch entry correspond to a command prescribed by the management. A command can operate on an entity or on attributes defined by the attributes portion 205 of the entry defined in the entity entry. The contents of entity entry 204 correspond to the entity or subentity identified by the entity class and Me name in name fields 47 and 50 of entity specification 46. Similarly, the content of the attribute part 205 is the entity specification 46.
corresponds to the attribute identified by the name field 62 of the attribute definition 54 of the entity body 53 of .

Dispatch End 92026 Procedure Pointer Part 20
6, which is the dispatch entry 202
The access manager processes the directive in relation to the entities and attributes identified in parts 203, 204 and 205 of the
Contains a pointer to the entry point to a procedure within the module. As discussed below in connection with FIGS. 5, 7A, and 8B, dispatch uses data structures, specifically the ability of the kernel 13.14 to route requests to the appropriate functional module 11 or access module 12 for processing. Dispatch table 28 used to forward
(Fig. 5) is used to stylize the dispatch entry 134 (Fig. 8B). A request or dependent request essentially specifies verbs, entities, and attribute partitions, and the kernel dispatches the verbs, entities, and attribute partitions specified by the request to the data specified by parts 203, 204, and 205, respectively. Compare with the contents of the structure part. If each part of the verb matches the contents of the corresponding part of the data structure (Figure 8B),
Kernel 13.14 is taken from section 206 of the dispatch specification (Figure 3E), dispatch entry 13.
4. Begin the procedure specified in 4.

B. Data Files and Uses 1. Registering a data dictionary management module allows its management specifications to define new entity classes, sub-entity classes or attributes, global or sub-entity directives or events. The management specifications (Figures 3A to 3D) are used to configure the data dictionary;
Data dictionaries are used to construct other data structures,
This is described below in connection with Figures 5 and 8A, but in Figure 9.
Used as shown in the figure. The data dictionary consists of a three-hierarchical database having the general organization or structure shown in FIG. Referring to FIG. 4, the organization includes a relative root node 220 that is associated with a global entity defined for administrative use (FIG. 3A). The global entity node is a hierarchical organization of the entity body 53 of the entity regulation 46 of the management specification.
Dependent node 221 that lists all attributes, Dependent node 219 that lists attribute partitions, Dependent node 222 that lists attribute sets, and Dependent node 223 that lists commands.
, and a dependent node 22 that lists the subentities.
Refers to multiple subordinate nodes, including 4.

Each subordinate node 219 to 224 refers to a respective element defined in the entity body.

That is, the dependent nodes 221 point to attribute definition nodes 225, each of which has a definition of the attribute defined in the attribute definition 54 of the entity body 53, and the attribute partition node 2
19, each of which is an attribute definition 54 of the entity body 53.
The set nodes 222 each refer to a set definition node 226 having a set definition defined in the set definition 55 of the entity body 53; Command node 223
refers to the command provision nodes 227, each of which comprises a command provision specified in the command provision 56 of the entity body 53, and the subentity nodes 224 are each provided with a subentity provision 57 of the entity body 5.3. Each directive node 227 points to a subentity provision node 228 that contains the subentity's provisions, a request node 230, a response node 231, and an exception node 2.
32, each of which in turn corresponds to the requirements 90 of the management specification.
, response rules 91, and exception rules 92 (FIG. 3C). In addition, each subentity node 228 includes a dependent node 233 for attributes, a dependent node 234 for sets,
forming the root node of a sub-organization having a structure similar to that depicted for the global entity shown in FIG. . The set shown in FIG. 4 is repeated for all subentities defined in the management specifications shown in FIGS. 3A to 3D and their subentities.

The information in the management specification is fused into respective nodes of the data dictionary to display entity information, including entity identification and response information, to the operator, and to other parts of the control equipment and complex system, as described below. is used to create a user interface information file 29 that is used by presentation module 10 in connection with the generation of a processing request by an entity. Various nodes of the data dictionary receive information from the elements of the management specification to form a complete data pulse of the data dictionary.

Information within the dispatch specification (Figure 3E) is used to create dispatch table 28, as described below in connection with Figures 8B and 9.

With this background, FIG. 5 shows one presentation module 10
, a functional module 11, an access module 12, a report manager 15, 20, and a dispatcher 16.
．． Kernel 13°14 with 21 is shown. Additionally, FIG. 5 depicts various portions of data storage element 17.22. In particular, data storage element 17
．． 22 includes configuration and domain databases 23, 25, alarm database 24, historical data file 26, pig dictionary 27, and dispatch table 28.

2. Historical data file The historical data file 28 is the presentation of the kernel 13.
In the case of the function aspect, information about the state and conditions of the entity, in the case of the function/access aspect of the kernel 14,
It has an entity. In file 26, the status and condition information also includes timing information identifying the time at which the status and condition information occurred. When the information manager 15-20 receives a request or dependent request regarding a state or condition at a particular time, the information manager determines that if the time indicated in the request or dependent request is in the past,
Check whether the information is present in file 26 and respond using the contents of the file.

On the other hand, if the time indicated in the request or dependent request is a time in the future, the information manager 15.20 effectively schedules the request to be processed at the indicated time. That is,
The information manager holds the request or dependent request until the indicated time, at which point it is accessed by the direct access module 12.
or from functional module 11, whichever is appropriate, or using file 26, if appropriate.

These features are fully described below under the heading "Scheduling".

3. Dispatch table Dispatch table 28 is dispatcher 16.2
1 to the appropriate functional module 1.
1 or access module 12. The contents of the dispatch table 28 are stored in the distributed digital data processing system at the entry points of the routines making up each functional module 11 that are called in response to a request from the presentation module 10.
Identify location. In more detail, dispatch
Table 28 contains invocation information that facilitates initiation of various operations by each R function module 11. Similarly, the contents of dispatch table 28 identify the location within the distributed digital data processing system of the entry point of the access module 12 routine. This location is used to process dependent requests from functional modules 11, ie call information specifying various operations by the respective entities.

4. User Interface Information The control device further comprises a user interface information file 29 comprising information regarding the various functions provided by the functional module 11 and the entities controlled by the access module 12. The user interface information file 29 comprises information obtained from the management specifications of each entity. Presentation module IO uses the contents of user interface information file 29 in displaying menus and other objects on operator terminals to facilitate control of the complex system. The information in user interface information file 29 facilitates the display of various functions and operations associated with complex system entities.

5. Configuration Database As explained above, the configuration function module can create and maintain a configuration database that lists all entity stages of the current configuration (and past configurations, if necessary) of the complex system. This information can be, for example,
The presentation module can be used to create a review table or user menu that lists the available entity stages. The configuration database may also provide a domain database that limits the scope of user control to facilitate use of the complex system, as described below.

In addition to the above features, in one embodiment, a configuration database can be used in conjunction with the presentation module to support wildcarding of user instructions. When the presentation module receives a user instruction containing a wildcard, the presentation module issues a request to the configuration function module, which requests an inventory of all entities in the configuration that match the wildcard request. uses information from the configuration database (along with region information) to create the list. Upon receiving the list, the presentation module expands the user request to all possible dependent requests that match the wildcard.

For example, request 5HOW MODE 'IN DOMAIN 5IT
E 1 (where 5HOW is the directive, DOMAIN is the area entity class, 5ITEI is the area stage, N0DB is the global entity class, and large is the wildcard) is the area named 5ITEI. is interpreted as an instruction indicating all the stages of a node within.

In this way, the presentation modules each send a request to SHOW
N OD E <1nstance> (where <
1nstance> is the name of the stage), one corresponding to each stage of the N0DE class of the area S I TE 1.

Partial wildcards can also be supported. In this case, the group of target entities whose stage group matches the pattern specified by the partial wildcard name is the command issued.

For example, rNODE 00J matches rNODE FOO and rNODE MAGOO, but rN
Zero-part wildcards, which are not compatible with ODB BARJ, cannot be used for fields with certain data type identifiers, such as text or numeric strings.

In the preferred embodiment, wild-one code extensions are not allowed in the global entity class field of user directives, and global class specifications are not wildcarded because doing so gives control over the scope of the directive. This is because it will be insufficient. This may generate an error if a directive name supported by one entity class is not supported by another. Even if a command name is supported by multiple classes, the command name may correspond to unrelated functions in different classes, resulting in unwanted side effects (eg, the rDELETE large command).

In addition, global entity wildcards can contain more information than the user intended (for example, rsHOW large,
commands) can be easily generated. Note that wildcards are safely allowed in subentity classes.

Wildcard embodiments may also delegate some or all of the wildcard expansion duties to the access module.

This is especially true if you do not use a configurator module; without a configurator module, the access module (which is typically concerned with accessing all modules of a class or subclass) It may be stored as part of proprietary storage 32 (Figure 2B). In this case, the access module will use the stage data to expand the wildcard of the received request. If wildcards are not supported by a particular access module, an exception will be returned to the user indicating this condition.

C. DATA FILE MANAGEMENT AND REGISTRATION MANAGEMENT As new tools are added to the controller, or as new information relating to the management of entities becomes available, the controller must adapt.

The controller is data driven and to adapt the system to new modules or information the associated data files must be modified, a process commonly known as data file management. The specific procedure for adapting the control device to a new module is known as registration.

1. Management of Historical Data Files - In one particular embodiment, the contents of historical data files 26 are provided and maintained in part by assistant functional module 11 as a historical data recorder functional module. In this embodiment, the historical data recorder functional module is controlled through requests submitted to presentation module 10 by an operator. Initially, such a request identifies an entity and one or more attributes, but, along with the polling speed, establishes a record for the identified entity and attributes in the historical data file, and the historical data recorder functional module , a dependency that allows an entity to respond to an entity at the polling rate specified in the request with a value representing the state of the entity in the complex specified by the entity and attributes specified in the request. In addition to being able to issue requests, other forms of requests can be made to Obeleta,
Historical data record jJ, device R, including changes in polling speed
Initiates other actions associated with the function module, temporarily enables or disables polling, and indicates the last value in the response.

2. Dispatch Table The contents of the dispatch table 28 and the user interface information file 29 contain registration information, which is provided by the various functional modules 11 and the access module 12 during the registration procedure. During the registration procedure that registers the module with the control device, the module loads display information, including name and code information, from its name field into the data dictionary. In addition, the module loads chord information and song information specified in the management specification from the data dictionary (Figure 4) and dispatch information from the dispatch specification (Figure 3E) into the dispatch table 24.

3. The user interface information presentation module 10 uses the display information of the user interface information file 29 to first display the entry,
Decide whether or not to display attributes, measures, etc. Second, decide what to display. User interface [h
The information file 29 is processed by the presentation module 10 in response to an instruction by the operator of the terminal, which receives the instruction and examines the instruction using a review table to correspond to the request, entity, and attribute codes defined in the management specification. and transmits this to the kernel 13 as a request.

Function modules and access modules are user
Note that you do not need to own the interface code. All user interface support equipment is provided for these modules, and the module designer
There is no need to worry about the interface. This makes modular design incredibly easy and ensures that the system looks and feels uniform to the user, regardless of the actual modules being used.

Upon receiving the request from the presentation module, dispatcher 1
6 calls the function module 11 using the dispatch information in the dispatch table 28.

Dispatch table 28 also forms a scrutiny table, which is used by dispatcher 16 to route requests to eligible procedures to process requests, as described below in connection with FIG.

Using the code in the scrutiny table and in the dispatch table 28 while using presentation-specific information in the user interface information file 29, entities, attributes, etc. are provided to the operator by the presentation module 10, as used by the dispatcher 16. It can be seen that it is substantially separated from the displayed identification. Presentation module 10
The representations generated by the presentation module 10 can therefore be expressed in a variety of languages, while the requests generated by the presentation module 10 have the same identification of entities, attributes, etc.

In addition, the user interface information file 29 can store information already available in a more convenient format from configuration databases and data dictionaries.

For example, class data in the data dictionary (Figure 4) indicates all commands 223 supported by the entities of the complex system.

However, directives 223 are stored in a hierarchical format and are dependent on entity classes 220. Although this format is logical for representing entity class information, it is not very useful for scrutiny tables. User requests typically first include commands (e.g., rSHoW N0DE FOOJ
HOWJ), so the scrutiny table should have the command as the first level of the hierarchy. As you can see from the example above, in the scrutiny table, the class name (for example, rNODE) is replaced by the stage name (for example, rNODEFoo).
This is necessary because the instruction will be examined if it is mixed with the identifier FOO). Therefore, after listing the available commands, the scrutiny table should list the class names that support these commands, and then the data types of the stages for these classes. Class and data type information is available through data dictionary reorganization, while for wildcard expansion stage data can be obtained from the configuration database. Accordingly, the scrutiny table in the user interface information file can integrate directives and entity classes, making the scrutiny of user input more efficient.

The above example also applies to graphical or menu-driven interfaces. However, in this type of interface, the user can specify a particular entity or area of an entity for further actions and the commands to be performed.
3I category (Category field 8 of Directive provisions)
You may wish to set the context for your command by graphically selecting one of the commands (listed in 7). Next, you can generate a menu listing all of the supported commands. Users can use pre-formed menus to request commands for one or more stages (e.g., by clicking on commands and stages) or for entire regions or entity classes (by clicking on commands only). can. EXAMINE format or CATEG
For ORY type commands, a separate menu may prompt the user to select an attribute pane or set. To realize this kind of interface, the list of all regions and entity stages and the list of all stages within a region must be retrieved from the configuration database, fl! ! In addition, a configuration database can store commands supported by classes or domains.

The user interface information file may also store default value information. Default values for a stage or class may be provided by the user or by management specifications for the associated entity class. This allows the user to save typing time by specifying default values within the instructions. For example, users may be most interested in N0DE FOO.
N0DE FOO, can be designated as the default node. f&, user rsHOWRO
UTING, you can type a command like rsHOW N0DE FOOROUTING
, it will be interpreted as Similar usage of default values can be utilized in graphical environments. Other examples of user interface information are online supplementary files available to the user through the presentation module. The auxiliary file contains auxiliary information for utilizing the existing set of management modules. In the preferred embodiment, the auxiliary file is assembled from auxiliary information provided by the module when the module is registered.

The supplied auxiliary information may comprise a textual description of the classes of entities and subentities supported by the module and instructions for the classes supported by the module. Additionally, tutoring information can be provided to educate new users about the module and its commands.

Although the above information can be obtained from the management specification for the module, - the auxiliary information file translates the management specification information into English, reducing the need for the user to learn the syntax of the management specification.

4. Historical Data Recording The historical data recorder functional module 11 uses the entity's polling information from its portions of the data dictionary, including the portions associated with the maximum polling speed field and the default polling speed field, to determine the attributes. Polling can be initiated and controlled in relation to the various attributes of the entity defined in the rules 54 and the responses thereto are stored by the historical data recorder function module 11 in its historical data file 26.

5. Module Registration Referring to FIG. 5, the access module 12, for example, while engaged in a registration procedure, registers the name and code information specified in the name and code information from its name field and its management specifications. Loads display information into the user interface information file 29, including information from the portion of the data dictionary that pertains to the display fields of the . Similarly, the functional module 11 stores code information and other information specified in the management specifications in a data dictionary (Figure 4).
and dispatch information from the dispatch specification (Figure 3E) into the dispatch table 28.

D. Inter-Module and Inter-Node Communication 1. In one particular embodiment of the control function module, the operator can
The module 12 can be controlled through the control function module 11, which essentially generates dependent requests that are copies of the requests it receives directly from the dispatcher 16. In this embodiment, the presentation module 10 receiving the instructions includes:
The instruction is examined using the examination table of the user interface host information file 29 to obtain codes corresponding to the codes for requests, entities, and attributes of the access module 12 specified in the management specification, and this is used as a request. It is communicated to the presentation/function kernel 13. Control function module 11 communicates the request as a dependent request to feature access kernel 14, where it is processed in the same manner as other dependent requests.

Upon receiving a dependent request from the control function module 11, the dispatcher 21 calls the access module 12 using the dispatcher information in the dispatcher table 28; the dispatcher table 28 also forms a scrutiny table, which is sent to the dispatcher 21 is used to route the request to the appropriate procedure and process the request, as described below in connection with FIGS. 9A and 9B.

2. Intermode Communication When the controller controls a complex system consisting of a distributed digital data processing system, FIG. and a functional module 11 and an access module 12, including associated data files 23, 24, 25, 26.27;
Dispatcher table 28, user.

3 shows elements including an interface information file 29 that are included in a single process of a single node of the distributed digital data processing system. If access modules 12 are provided in different processes or nodes, the control device includes dispatchers 16.21 in all processes and nodes. Referring to FIG. 6, the dispatcher 16(1) of one process of one node sends a request from the presenting module 10(1) to a functional module 11(2) of a second process or node. Upon receipt, if the dispatcher 16 (IN!, functional module IN2) is in another process on the same node,
The request is communicated to the other node's processes or to the node's dispatcher 16 (2) by an inter-process communication mechanism or by an inter-node communication mechanism. dispatcher 16
(2) then selects functional module 11(2) to process the request. The dispatcher 16 (2) receives the response generated by the functional module 11 (2), transmits it to the dispatcher 16 (1) through the inter-process communication mechanism or the inter-node communication mechanism, and sends the response to the dispatcher 16 (1).
allows the presentation module 1G(1) to display the response to the operator.

Similarly, the dispatcher 21(2)
1 (2) to the access module 12 (3) of another process or node, the dependent request is sent to the dispatcher 21 of the other process or node through the inter-process communication mechanism or the inter-node communication mechanism, respectively. (3). Dispatcher 21 (
3) then sends the dependent request to access module 12 (3
) for processing. Dispatcher 21 (3)
receives a response from the access module 12 (3) and transmits it to the dispatcher 21 (2) via an inter-process communication mechanism or an inter-node communication mechanism, and the dispatcher 21 (2) transmits it to the functional module 11 (2).
join to.

3. Structure of Requests and Dependent Requests The structure of the requests, particularly the parameters included with the requests, is shown in FIG. 7A. The structure and contents of dispatch table 24, which is the same as the structure and contents of dispatch table 26, will be described in connection with FIGS. 7A and 7B. Information manager 15.20 and dispatcher 16.21 in connection with future request scrutiny
The process carried out by will be described in conjunction with FIG.

Referring to FIG. 7A, the user interface information file 27 may be generated by the presentation module 10 in response to the contents of the user interface information file 27 and related actions by the operator.

The request comprises a plurality of parameters or can be generated by the information manager 15 during polling in connection with various entities of the controlled complex system.

All requests have the same structure: initial call identifier,
This is not shown, followed by the parameters shown in FIG. 7A. Kernel 13.14 as explained above
comprises a single dispatcher 16.21 having a presentation and function aspect 16 and a function access aspect 21.

The initial invocation identifier determines which of these aspects are enabled by each request. The initial call identifier may indicate a call to a functional module or access module, each directed to a corresponding aspect of the dispatcher. Although a presentation module or a function module can call a function module and a function module or an access module can call an access module, a presentation module can only call an access module through the "control function module" described above. I can do it.

The parameters include a verb field 12 whose content identifies the type of request, i.e. the action to be taken in processing the request.
0. As noted above, a request may cause a functional module 11 or an access module 12 to initiate a change in the state or condition of an entity of a controlled complex system, and may cause information regarding the state or condition, or both, of such entity. You can start sending back the items.

The contents of verb field 120 indicate the action to be performed by functional module 11 or access module 12.

The request also includes an input entity specification field 121, which identifies the entity of the complex being controlled. If the verb is a non-action verb, for example if you are requesting a response indicating the value of one or more attributes, then the request requires one or more actions to be taken in relation to this, as specified by the verb and the entity class. An attribute pointer field 122 is provided with a pointer to an attribute.

If the verb is an action verb, ie, the verb causes a change in a given entity, then the request does not include an attribute pointer field 122.

In addition, the request includes a pointer to a time data structure containing certain timing information, including absolute system time, time interval specifications, and time accuracy specifications, and specifications for the time range in the request for scheduling purposes. An input time qualifier field 123 is provided. The input/output context handling field 124 contains values that identify requests in the context of multi-part operations, each part of which requires a separate request. Output entity specifier field 126 comprises a pointer to a data buffer that can be used by dispatcher 15 (or dispatcher 21 if the parameter forms part of a dependent request) in conjunction with the identification of the entity. .

The request also includes a pointer to the item stamp specification that is to be used by the functional module 11 (or the access module 12 in the case of dependent requests) in connection with forming the response. The optional data descriptor field 127 after I& comprises the data used in processing the request and provides a descriptor for the buffer in which the entity stores the data that constitutes the response. Each descriptor has a pointer to the starting position of its respective buffer and a length specifier indicating the length of the buffer.

In another embodiment of the invention, the request is made as a separate parameter or as a separate element of the parameter field described above.
A qualifier field may also be provided.

The WITH qualifier can, for example, be associated with an entity field that filters the entity list created by wildcards. For example, rBRIDG WITH5TATUS
='ON AND FILTERING=OFF'
, refers to each bridge class entity with its state flag set to ON and its filtering flag set to OFF (this example includes AND, OR, NOT, and
It also illustrates the use of pool functions like OR),
In the preferred embodiment, all modules and information managers are configured as entities to implement the WITH qualifier.
It is configured to check the presence or absence of a WITH clause at each level of the parameter (ie, global entity, sub-entity, sub-sub-entity).

Other qualifiers can be used as explicit parameters of the request.
rTo sent to a file named iIename>
<f i 1 e name>" qualifier, other request parameters from the file named <f i 1 e name> rFROM <filename>"
qualifier, rVIAPATHJ qualifier (
rVIA PORT, qualifiers (e.g., useful in specifying a fine-grained management module between several devices performing an operation), and rVIA PORT, qualifiers (e.g., access (useful for specifying that the module performs diagnostic tests using a particular Ethernet boat).

Similarly explicit parameter qualifiers can specify groups of entities.

“IN DOMAIN<domain name>
``qualifier filters the specification so that it applies only to the first item in the area named <doJnain name>.

Also, explicit parameter qualifiers can authenticate or qualify requesters of management services with limited access rights. rBY ACCOUNT,, rBY
PASSWORD DJ, and rBY USER,
Qualifiers are examples of specifying the customer's name, password, or requester's user identifier for these purposes.

In addition to the above, qualifiers specify times at which commands are to be executed. Generally this is done in the AT clause.

For the show instruction, the syntax of the AT clause is <AT-c l
ause> : : =”AT”<time-
arg>[" , "<t time-arg)], where the time argument <t time-arg> is, for example, the start time (rsTART=<t time>"), the end time ('END=<t ime>"), or connection time ('DURATION=<time-1ength
＞”＞, Repeat period (rREPERT EVERY
[= ko <time-1ength>”), time accuracy (rcONF IDENCB[=]<time-1
length>”), or sampling rate (rsAM
PLE RATE [=]<time-1engt
h>”) can be shown. These arguments interact with each other to create a general schedule and scope of interest for the request. In particular, in one particular embodiment, three time arguments, 5TART, END, and DURATIO
N is related so that two of these define a period. Therefore, at least two of these qualifier arguments must be specified when displaying period-based entity statistics.

Other time qualifiers can also be used.

For example, the time qualifier of AT ORBEFORE<time> can be interpreted as requesting time slump 1 size information at or before the time indicated by <tile>. Upon receiving such a qualified request, the argument module continually checks for actions that will produce the requested information. For example, if information is generated due to the actions of other users, this information will be returned to the requester. Otherwise, the management module continues to check the information until time <tinge>. If information is generated,
This is returned to the requester. Otherwise, time <
time), the management module forces the ball of information from the access module or entity and returns the information to the requestor.

To supplement the AT ORBEFORE tiIIe qualifier, a NO wait time qualifier may also be implemented. In addition, field 124 contains a handling point that points to a context data structure, which is a dedicated section of storage that stores processing context information. The handle is used, for example, as a "notepad" for communicating contextual information between the module and the information manager.

1. Time stamp Each item of data has a timestamp value.

In the case of data returned to the user or management module, a timestamp is applied to the data value returned for a command, at the instant the event described by the data item occurred, at the instant the requested action actually occurred. For historical data stored in a historical data file, the timestamp is the instant at which a given data item had a given value, for the purposes of the historical data file. A timestamp can be thought of as a key or index. The time range of interest specification 123 can be used to request a search for a particular piece of information stored at a predetermined key or index. With the 0 time specifier supplied on request using
Other values of data than the "currently entitled value" can be displayed and processed, and statistics can be calculated over a period of time. In one particular embodiment, the "time range of interest" is represented by a prepositional phrase in the time specifier of the request. Although time specifiers are generally used with 5HOW instructions, time contexts can also be applied to MODIFYO-style requests and actions.

The time ranges of interest are: absolute instant, - subsequent absolute instant, time interval (start time rSTART, and duration rDt
lR, ), a repetition of an instant, or a repetition of a time interval.

Both of these are relative periods (rEVER'/J
) can be related to them. Once a period is established, the original moment, or subsequent moment, or time interval is treated as a base, and the period is added to this base. For example, time specification r5:oOEVEREY O:
15,! ,t,5:00,5:15,5:30,5
: Equivalent to 45°... absolute time instant (rUNT)
IL J, ) can be specified to indicate when the iteration is to be terminated. For example, time specification r5:E
VEREY 015UNTIL6:00. is 5:00,
Six repeat time intervals can be specified in the same way, which are equivalent to 5:15, 5:30, 5:45, 6:00, rSTART5:00 DLIR:05 EVE
RYI:00° is the time interval 5:00-5:05,6:0
This is equivalent to 0-6:05, 7:00-7:05, etc.

3. Scheduling Scheduling information can also be indicated by the time specifier field 123. A particular scheduling time can be expressed either in absolute instants or in consecutive absolute times. Unlike the range of interest, the scheduling time cannot include time intervals. A time interval whose start and end points are equal is an "instant" (for example, (TO
Break down into DAY, TODAY) ).

There are some rules that apply to time intervals. The past time interval may have a starting point indicated by the keyword YESTERDAY or an absolute time in the past. Similarly, a future time interval may have a dead center indicated by the keyword TOHORROW or a future absolute time. Also, the start time of a time interval must be earlier than its end time.

4. Time context handling structure As explained above, scheduling and scope of interest information can be supplemented by requests with associated context handling. Handling is created by the module that executes the request and is subsequently used to communicate with the service provider. Upon receiving a call from a service provider, eg, an information manager, a context block is generated as a local reference to the request time context.

Generally, context blocks and treatments are used as criteria for the state of a request. Because an initial request can generate many dependent requests, it is possible for a single request to produce multiple handling and context blocks. Zero context blocks are the standard used by service providers, but handling is the criterion used by the service requester. Each process in the request/dependent request chain (i.e.
A module (or information manager) only knows about context blocks and treatments that are relevant to its local part of the chain.

Referring to FIG. 7B, in one particular embodiment, a time context treatment 172 created by a requester, e.g., presentation module 10, includes a range field 175 and a schedule field 176 related to the time specification 123 of the initial request. We are prepared. These fields supplement the request timer data and are used to determine the current state when multiple requests and responses exist for a single operation. Handling 172 also includes a context pointer 177 and a state variable 178. These data items, which indicate the state and criteria functions of the treatment, are created and stored using range field 175 and schedule field 176 when a request is made.

If there are multiple requests and responses for a single operation, the context field 177 will ultimately contain a pointer to another data structure 174, known as a context block. This is created and maintained by the service provider, e.g. the presentation and functionality surface 15 of the information manager, in response to an initial request requiring multiple responses (
Function modules and access modules can also create and maintain context blocks on demand).

The handling status field 178 has one of three values: rFIR3T, , rHORE, or r CANCEL, these are used as flags to indicate further actions to take. When first made,
Handling status is set to rFIR8TJ.

As explained above, if a request can be satisfied with a single response, a response is generated and returned to the requester. In more general cases, the service provider, e.g., a functional module, information manager, or access module, cannot satisfy the request with one answer, e.g., the requester specifies a group of entities. Although,
Wildcards may be used in input entity parameters 121. Since each reply can only incorporate information from a single entity, several replies are required, one for each entity.

In the case of fltl, a request for a single entity can include a time specifier with several different time values. Since each reply can only incorporate information for a single time value, several replies are required, one for each time. Requests that feature multiple replies are
It may be for any type of operation, including obtaining attribute data for an entity or entities, modifying attributes of some entities, and modifying the state of some entities.

Once a service provider processes a request and determines that the request is awaiting another reply, it is responsible for indicating this to the requester. From then on, the requester is responsible for waiting for the service provider to make another reply.

To do this, an intermediate process, such as an information manager, must store information related to the request being generated.

This latter function, in addition to pointers to the service provider's dispatch entries (see explanation below under the heading Dispatch Table), also handles handling related to dependent requests for n-function modules, for example. Associated proprietary variables generated on demand, such as context pointers pointing to 1
This is accomplished by creating a context block 174, which may include 73.

Handling and context blocks are used as follows. The service provider causes the requester to (1) cause the pointer 177 to point to the context block 174 of the requester treatment 172; and (2) cause the requester treatment 172's status field 178 to
Use an appropriate handling modification routine to signal that you have another reply by setting r_MORE_J to the value of r_MORE_J. When the reply is returned to the requester, the requester looks at the rMORE, status in its handling status field and knows that the service provider has another reply for this request. If the requester does not want these different replies, it must cancel the request (see below); if the requester wants another reply, it must repeat the request without changing the parameters.

The service provider makes these repeated requests (this is rh).

(with a handling status field 178 equal to RE), the appropriate handling access routine is used to locate and detect the 'HORE, status.

The service provider then knows that the call is part of a previously established request. (Note that a treatment with a state of rFIR8T, indicates to the service provider that the associated call is the first invocation of the request.) Retrieve the pointed context block 174 and continue its execution using the context block to provide another reply. There is only one reply for each call made to the service provider. As long as the service provider keeps the handling parameters in the "rHORE" state, the service provider has more replies to the request.

The service provider will notify the requester of its final reply (e.g.
(determined by scope field 175 and schedule field 176 in the requestor's treatment).
Requester handling status field 178 is rFIR8T
It is set back to the value of J (initial setting state). When the return is sent to the requester with this final reply, the requester receives r
Look at the state of its handling parameters set in FIR3T and find that its requirements are fully satisfied. Note that if the request is satisfied with a single reply, the service offeror does not preserve the context and never generates a handling parameter state that results in an rMORE J state. The requester is handled according to its initial setting rFIR8T.
, indicating to the requester that the request is complete.

Once the service provider returns the handling parameters in state r MORE , the request must be repeated or canceled. If the request were to be discarded instead, system resources would be lost due to storage allocated to handling and context blocks.

Regarding the above discussion, note that if the service provider did not originate a dependent request, then the single treatment would suffice for the communication between the service requester and the provider. However, if a service provider originates a dependent request, then there are two or more separate treatments - an initial requester treatment generated by the call requester, and an initial requester treatment generated by, e.g., an information manager, e.g. There will be another treatment that is conveyed to the

If there are multiple requests and responses for a single operation, a scheduling dependent request to the service provider is made by the information manager and the time specification parameter 12
It is controlled by the schedule time component of 3. For each schedule time specified by the time specification, the information manager generates a request that causes the service provider to perform the requested action and generate a response.

When the service provider completes the requested action, it issues a response. When the information manager sees that the service provider has completed the requested action, it examines the scheduled time context for the initial request. If there is more time to schedule the requested operation, the information manager does not set the requester's handling status to rFIR3T, and returns rHOR to rHOR.
E. Leave it as it is. The requester sees that its handling parameters are still in the rHORE, state, knows that the entire request is not complete, and asks about the rest. The information manager then waits until a predetermined scheduled time and causes the dispatcher to make another call to the service provider. The service provider will send this next call to rFIR3T
Note that returning the handling state set to , does not preserve the context and is therefore indistinguishable from invoking a completely new request. It does not distinguish between the handling status of rHORE, generated by a service provider, and the information manager preparing a new schedule moment.

In another embodiment, the handling access routine is enhanced to allow the applicant to confirm the occurrence of the handling parameter rHORE, condition.

During a request with multiple replies or multiple schedules, if the requester decides that he does not want any further replies to this request from the service provider, he must cancel the request. Possible reasons for attempting to cancel a request include receiving an exception reply indicating that no more data is available, or receiving an error condition indicating that the required action was not performed correctly. The reason for cancellation is the responsibility of the requester. Cancellation terminates all activity of the request, including the scheduling and scope of the operation.

Cancellation shall be made by the service provider to the requester.
This can be done when returning the handling parameter status. The requester sets the handling parameter status as rCANCF,L,
, and reissue the call using an appropriate handling modification routine.

The requester must not change any other parameters to this call. When the service provider receives this call, the expected rMORE, rCAN instead of state
Look at the handling parameters in the CEL state. The service provider receives the context from the handling parameters and uses it to perform any desired cleansing, including canceling any lower-level requests it is making, terminating all processing, and freeing up system resources. Includes refund. Once the service provider completes its cleanup, the handling parameters are reinitialized back to the rFIR3TJ state using an appropriate handling modification routine. Next, the service provider is C.
A special condition value return code of ANCELED is returned to indicate that the request was successfully canceled.

The requester cannot cancel the request after the service provider returns the handling parameter status of the rF IR3T. The request has already been completed and there is no context for the service provider to cancel. Therefore, the cancel routine described above will not return an error unless the handling state is rMORE.

F. Dispatch The dispatch table 28 includes a plurality of data structures, one of which is shown in FIG. 8A, and one of which is shown in FIG. 8B.
One or more dispatch lists containing the dispatch entries depicted in the diagram. The dispatch tree and dispatch list essentially form a review table used in reviewing requests, as described below in connection with FIG. Referring to FIG. 8A, the dispatch tree includes multiple entity nodes 130. entity node 1
30 are assembled into tree structures to aid in inspection, but they can be assembled into other data structures. Entity nodes identify various entities within the complex system with which requests can be generated. Entity nodes 130 have respective dispatch nodes.
A pointer is provided that points to a dispatch entry 134 (FIG. 8B) of the dispatch list held in table 128.

The term "entity node" is used to describe data structure 130. This is because it satisfies the entity model shown above. In general, data structure 130 satisfies the entity model because it comprises a hierarchical structure and its child structures that resemble it.

The term "entity node" used to describe data structure 130 should not be confused with the term "entity" used to describe elements of a complex system.

Entity node 130 includes several fields, including a class/stage flag field 140 that indicates whether entity node 130 relates to an entity class or stage within a class. Each entity may be at the level of a class, and the class is defined by a class name distinguished by the entity's entity definition 46 (Figure 3A),
Table 24 includes further entity nodes 130 relating to classes and stages, as described below in connection with FIG.

While reviewing a request, the entity's class name and stage name and its attributes are verified using a data structure of the form shown in Figure 8A; used separately. The status of a class or stage is indicated by a class/stage flag.

Entity node 130 also includes tree link pointers that identify various other elements within dispatch table 28. Modules that service requests related to several entities of the same class can be identified by wildcards or ellipses. If so, the associated entity node has a wildcard pointer in field 141 or an ellipsis pointer in field 142. Each wildcard pointer and ellipsis pointer is
It consists of tree link entries as described below. If the entry node is related to a class with no levels, an example of which is described below in connection with FIG. - Equipped with a pointer. After I&, field 131 comprises a code entry, which comprises a code identifying the class or name of the entity stage associated with the entity node as well as the link pointer.

The code entry field 131 shown in entity node 130 of FIG. 8A is one entry in the coded list. (The remainder of the list is not shown.) When referring to the class or name of an entity's stage, the encoding list refers to the entity's management specification (see Figures 3A through 3D) as defined by the entity's management specification (see Figures 3A through 3D). It is a linked list with the names of classes. Each coded entry 131 has a pointer 150 pointing to the next coded entry in the list, a class code/stage name numeric field 151, and a link entry 133 with a pointer to an entry node 130 or dispatch entry 134. Field 1 with
It is equipped with 52.

Class code/stage numeric field 151 of coded entry 131 contains a class code or stage base. The content of field 151 comprises a class code if class/stage flag field 140 of entity node 130 is adjusted to identify the entity node associated with the class.
Alternatively, the contents of field 151 comprises a stage base if the class/stage flag field 140 of entity node 130 is adjusted to identify the entity node associated with the stage.

Referring to Figure 8B, dispatch entries 134 in the dispatch list are used to identify the particular procedure to process the request. The dispatch list is an linked list of one or more dispatch entries 134, each entry 134 containing information useful in forwarding a request or dependent request to the appropriate functional module 11 or access module 12. More specifically, dispatch entry 134 includes a pointer 160 that points to the next dispatch entry 134 in the list. Field 161 contains the identifier of functional module 11 or access module 12, during whose registration a dispatch entry 134 is generated. Dispatch entry 134 includes a series of fields 162-164 that point to procedures, processes, and nodes within the complex to handle requests. Field 165 identifies the verb to which the dispatch entry pertains, and attribute field 166 identifies the verb to which the dispatch entry relates;
The set of attributes identified by the attributes defined by the attribute definition field 54 of Figure B) is identified. Finally, the count field 167 indicates that the dispatcher has entered the dispatch entry 13 in connection with processing a request or dependent request.
Identify the number of times 4 was used.

With this background, the process followed by dispatcher 16 in reviewing and dispatching requests from presentation module 10 will be described in connection with FIG. dispatcher 2
It will be seen that 180 performs a similar process in conjunction with a dependent request from module 11.Referring to FIG. 9, request 180 is as follows.

HOW NODE (node narge > ROUT
I NG CI RCU I T (routing cicui)
t nane ) CHARACTERl, 5TIC
3 It is used in conjunction with distributed digital data processing systems. Request 180 includes a number of compartments, including a verb compartment 181, namely 5HOW, an entity compartment consisting of a plurality of entity class codes and stage groups 182-186, and an attribute compartment 187 consisting of a plurality of attributes. In this example, the verb 5HOW initiates the generation of a response from the entity named in the request that is related to the named property.

In request 180, the entity partition, element 18
2 to 186, comprises a large number of class/stage pairs. In particular, element 182, N0DE, is the class code and element 183, namely (node nale
) identifies the stage of the entity class MODE by the stage group (node narae >).

In a distributed digital data processing system, identifying nodes within the distributed digital data processing system,
(nocle nalne > identifies a node within a distributed digital data processing system.

In addition, the request 180 further includes an entity class code 184 that has no stage in the entity partition, RO
Equipped with UTING. Request 180 also has another entity class code, CIRCUIT, which is <ROUTING CIRCUIT N
It has a stage identified by AME >.

Referring to Figures 3A through 3D depicting management specifications, various elements of requirements associated with an entity are specified by the management specifications. In particular, the request verb section 181 is taken from the directive specified by directive specification 56, the entity class name and subentity class name 182.184.185 are taken from the entity class code field 47, and The attribute section 187 is taken from the attribute definition 54 of the management specification for the entity.

The stage base of entities and sub-entities is taken from stage data known to the user (eg, by reference to a configuration database or through automatically generated menus).

In response to receiving the request, dispatcher 16 uses entity node 130 (FIG. 8) to begin scanning the elements within the entity partition, starting with global entity class code element 182. In particular, with reference to FIG. 9A, dispatcher 16 begins (step 190) with a root entity node that is provided with a class/stage flag 140 that identifies the entity node associated with the class code and determines the N0DE. Class code field 15 with class code
Dispatcher 1 looks for an entry in its encoding list 131 that contains an encoding entry with 1.
6 cannot find such an entry in the dispatch table 28, the dispatcher 16 looks for a wildcard or ellipsis pointer (see below). When the dispatcher 16 locates such an entity node 130 in the dispatch table 28, it proceeds to the next step of the probe operation (step 191), in which: The stage specified by the entity element 183 <nod
Entity node 1 associated with e naIle >
Trying to track down 30. In this operation, the dispatcher 16 uses the contents of the pointer field 152 of the encoded entry 131 to identify the entity node associated with the stage group and whose encoded list identifies the entity node of the stage group 180 requesting that stage group entry. Locate the entity node whose class/stage flag 140 has a coded entry corresponding to <node nalle> of element 183. Again, the dispatcher 16 stores such nodes in the dispatch table 2.
If you can't find 8, look for a wildcard or ellipsis pointer (see below).

On the other hand, in step 191, the death batcher 16
After locating the entity node associated with element 183 in table 28, the next step (step 1.92)
and here class code 184, ROUTING
, and tries to locate the entity node associated with it. In this operation, dispatcher 16 uses the pointer in field 152 of coded entry 131 and the entity element ROUTING from the request to identify the entity node associated with the class code and whose coded entry list is ROUTING. Locate an entity node 130 with a class/stage flag 140 that has an encoded entry 131 with a class code field 151 with . In this situation, the entity class ROU
Since T I NG is a stageless entity class, pointer field 152 of encoded entry 131 is null. In this case, the null pointer field 143 of the entity node 130 is
Refers to a second entity node 130 associated with entity CIRCUIT.

At step 192, dispatcher 16 located step 192. ROUTING class, a second entity node 130 and its class code using a null pointer in the entity node 130 associated with the entity to indicate that its class/stage flag 140 is associated with the class code. - Locate the coded list comprising the coded entry 131 whose field 151 comprises CIRCUIT (step 193)
, if the dispatcher cannot locate such an entity node, it looks for a wild-card or ellipsis pointer (see below).

On the other hand, if the dispatcher 16 locates the entity node 130 in step 193, it proceeds to step 194, where the stage entity element (ROUTING CIR
In this action, dispatcher 16 attempts to locate entity node 130 that identifies CUIT N''AME.
52 pointer to its class/stage flag 1
40 identifies this as relating to a graduated color and its coded list indicates that its graduated color field 151 is associated with request 18.
(ROUTING
CIRCUIT NAME> is located. dispatcher 1
If 6 cannot locate such an entry, it looks for a wildcard or ellipsis pointer (see below).

On the other hand, if dispatcher 16 locates stage entity node 130 identifying stage entity element 186 in step 194, dispatcher 16
80 entity sections 182 to 186 have been successfully examined.

Dispatcher 16 then uses the pointer in field 152 of encoded entry 131 located in step 194, the verb in verb element 181, and the attributes in request characteristics element 187 to dispatch the dispatcher to use in processing the request. - Identify entry 134 (Figure 8B). In particular, following step 194, dispatcher 16 uses the pointer in field 152 of coded entry 131 to identify a list of dispatch entries 134.

Dispatcher 16 then sends its verb field 1
65 corresponds to the verb element 181 of the request 180, in this case 5HOW, and its attribute field 16
The dispatch entry 134 whose content corresponds to the attribute of the characteristic element 187 is sought.

If dispatcher 16 locates such a dispatch entry 134 in step 195, it uses the contents of procedure identification field 162, process identification field 163, and node identification field 164 to invoke a procedure to process the request; With this action, dispatcher 16 effectively forwards the request to the processing entity.

As discussed in connection with FIG. 6, if the process identifier in field 163 and the node identifier in field 164 identify other processes or nodes than those associated with the dispatcher, then the dispatcher will process the request, Transfer to the dispatcher of the other process or node identified in the respective fields 163 and 164.

Described above is the use of coded entries in the dispatch table. Wildcards and ellipsis pointers provide additional functionality to tables. For example, one management module can handle all requests for modules of a particular global or subordinate entity class. Without the wildcard and ellipsis pointers, all class stages and subclass stages would be listed in the dispatch table. To avoid this, wildcards and ellipsis are provided and the Dispatch Specification 39A to specify in a general way which entity classes or stages serve a management module.

An example of such a dispatch specification is N0DDE*ROUTING CIRCUIT, which means that if the module is a global entity of the N0DE class, then if it is a subentity class CIRCUIT, then all other CIRCUIT class subentities This shows that it is possible to handle subentities of . The asterisk (8) matches any graduated color, and the ellipsis (-
) is the stage Pa of the subentity that may follow
For example, the expression N0DE foo ROUTING CIRCU
IT bar LINK fred meets the batch specifications. This is because "fire" is compatible with "rfoo", and r,,,, are rbar LINK fr
This is because it is compatible with edJi.

Referring to Figure 9B, to enter the wildcard dispatch specification for dispatch tables 2 and 8, step 1
91 (FIG. 9A), the entity node 130 corresponding to the N0DE class entity stage group will be modified. The wildcard pointer 141 is
The child pointer associated with the class code ROUTING is changed to point to a new entity node 130 containing class codes, one of which is the class code ROUTING (step 196), and the child pointer associated with the class code ROUTING becomes null (step 192 (FIG. 9A). ), the null pointer points to another new entity node 130 that will have a child pointer corresponding to the class name CIRCUIT (step 197).

This child pointer points to another new entity node 13
0 (step 198) and its ellipsis pointer points to the dispatch entry for the module (step 199).

The examination of the modification table is the same as that described with reference to FIG. 9A up to step 191. In step 191, the dispatcher 16 sends the name, e.g. rf.

If this name is found in a coded entry (three are shown for illustration purposes), the dispatcher follows the child pointer of the coded entry.

However, if the name "foo" is not found in the coded entry (indicated by the null NEXT ENTRY pointer of the last coded entry), the dispatcher looks for a non-null wildcard pointer in step 191, the wildcard After fixing the pointer,
The dispatcher proceeds to step 196.

Steps 196 and 197 are the same as steps 192 and 193 in FIG. 9A. The dispatcher moves to step 197 using a null pointer (corresponding to class code rROUTING) in step 196 and to step 198 using a child pointer corresponding to class code rCI RCU I TJ.

In step 198, the dispatcher searches the linked list of encoded entries (three are shown for illustration purposes) and searches for '
Identify the stage group "bar". If this name is not found in the encoded entry, the dispatcher looks for a non-null wildcard pointer; if this is not found, the dispatcher looks for a non-null ellipsis pointer.

This is located and used to traverse to the dispatch entry (step 199), the contents of which are used to call the appropriate module.

Wildcards and ellipsis pointers allow for general matching of entity class codes and stage bases, but only after the dispatch table's coded entry has been checked. In this way, the dispatcher looks for the "best match" for the entity salt, so, for example, the first module has the dispatch specification N0DE ROUTING CIRCU
IT can be provided. This module is N0D
E-Class Global Entity Stage rJoe”
, it shows that all stages of all CIRCUIT class subentities of the ROUTING class subentity can be handled.

The second module is dispatch specification N0DE joe ROUTING CIRCU
IT... can be provided. This module is N.

DE class global entity stage rJoe
” indicates that all stages of all CIRCUIT class subentities of ROUT, ING class subentities can be handled.

In order to be consistent with the "most obvious match" rule, N0
DE Joe ROUTING CIRCUIT
All commands for subentities should be sent to the second module. This is accomplished using a dispatch table structure.

Because the step group rJoeJ appears in the encoding entry in step 191, rJoe'' is ROUTING
If the stage base in the request to CTRCUIT, then r
Joe' encoding entry will be used (since it is checked first) and the wildcard pointer will not be used.

To properly traverse the dispatch tree, the dispatcher must also use the stack. Let me explain why this is necessary with a simple example. Consider a new module with the dispatch specification N0DE Jlm DISKDRIVE... This indicates that the module can handle all stages of the sub-entities of the DISDRIVE class for the global entity stage rJim of the N0DE class. This specification is entered into the tree in step 191 in a manner similar to FIG. 9B by appending the stage group "rJ im" to the encoding entry, followed by appending the new entity code. Following this, dispatching the request using the global entity class and stage base N0DE Jim causes the dispatcher to transition to the new entity node.

However, N0DE Jim ROUTING CIRCU
A request with an entity name starting with IT indicates that the new module is DISKDR for NUDE stage 1'W'Jim'.
Since subentities of the IVE class do not support
It is not possible to receive services from a new module, therefore the dispatcher uses the class name ROUTING
Once you have determined that the CIRCUIT is not supported by the new module, return to step 191 and use a pool encoding entry or optionally a wildcard or ellipsis pointer to set 'N0DE Jim ROUTIN.
A mechanism must be provided to find a module to service a GCIRCUITJ request. Therefore, as the dispatcher traverses the dispatcher table, the dispatcher maintains a stack of pointers for all of the entity nodes 130 that it has traversed from the root node. As the pointer moves up and down through the tree structure of the dispatch table, it is pushed in and out of this stack in an attempt to find the appropriate dispatch' entry.

If no matching dispatch entry is found,
Errors are returned to the requester (ie, presentation module or functional module).

As explained above, the control function module can serve as a pass-through to the access module directly from the presentation module. To achieve such a passthrough, the dispatch table (which matches the name of any entity in any request) must be presented 1
The ellipsis pointer to the root node of the functional aspect should point to the dispatch entry for the control functional module. Upon receiving a request, the control function module simply issues the same request to the 81 capability access aspect of the dispatcher. In this manner, all requests that do not conform to the dispatch specifications in the Presentation and Functional Dispatch Table are entered into the Functional Access Dispatch Table for compliance. This allows access to the primitive functions available from the request or access module of the presentation module.

In another embodiment of the dispatch table, the null pointer field 143 is a linked list structurally similar to the list of coded entries 131 to allow for more than one class code with no stages. The first element can be provided. The second, "null" list will contain code values for class codes with no stages. The null list is scrutinized after the code list and before checking for wildcards.

G. Domains and Configurations As mentioned above, configuration function module 11 maintains a configuration database that defines the entities that make up the complex system. With appropriate instructions from the operator, the configuration function module 11 can add stages of entities defined by the data dictionary to the configuration database, delete them from the configuration database, and change the specifications in the configuration database. As noted above, the domain functionality module 11 establishes domain entities in the configuration database that reference a subset of entities already defined in the configuration database. Through the presentation module 10, an operator can control and monitor an entity comprising a particular area without regard to the potentially countless other entities that make up the complex system. Additionally, the operator initiates control or monitoring actions in relation only to the entities within the domain, without initiating the generation of requests by the presentation module 10 for each entity, thereby controlling and monitoring the iWJ of the complex. It can be simplified.

The region functionality module establishes a region database around each region entity that identifies the entities that make up the region entity within or in addition to the configuration database. Upon receiving the appropriate request, domain functional module 11 adds the entity to the domain database;
thereby adding an entity to a region, deleting an entity from a region database, thereby deleting an entity from a region, generating a response identifying the entities that constitute the region defined in the region database, and deleting the region database; This effectively deletes the area.

Referring to Figure 9C, the format of the configuration database and the region database (which can be combined into a single database) is as follows for each entity stage within the configuration, and similarly for each entity stage within the region:
It has a field.

The fn area database includes an entry 230 for each member of the area, listing the area name and stage name for each member of the entry or subentity. In addition, the realm database includes an entry 232 for each entity that is a member of a realm, listing each stage name and the realm of which it is a member. The region functionality module updates this information when the region is modified, utilizes this information to quickly determine the members of the region, and
Or alternatively, an entity's domain membership can be quickly determined.

In another example, the first region can incorporate members of the second region by referencing the second region;
In this way, the size of the area database is reduced. In other embodiments, the domain database may establish a hierarchy of domains similar to a hierarchy of entities and sub-entities, and instructions may be conveyed similarly to domains and sub-domains.

The configuration database includes entries 234 for each entity and subentity, organized hierarchically within the database.

A full name is provided for each entity and subentity stage. This information can be used by the configuration functionality module to quickly determine a configuration to display (via the presentation module) to the user, for example, a map of configurations or a menu of entity stage names.

H1 Alarm As explained above in connection with FIG. 1, one functional module 11 includes an alarm functional module 11,
This determines the alarm condition upon request from the presentation module 10 and detects the occurrence of the alarm condition using various conditions recorded in, for example, a user interface information file 29 of the entities of the complex system. can do.

FIG. 10A shows the functional organization of the alarm function module 11. Referring to FIG. 10A, the alarm function module 11 includes:
A general alarm module 200 is provided that receives requests from the modules and translates them so that one or more detector modules 201 or one or more rule maintenance modules 202 can act accordingly. As indicated above, the alarm function module performs two general types of operations: maintaining alarm conditions and detecting alarm conditions.

The operation of maintaining the alarm conditions of the alarm function module 11 is performed by the rule maintenance module 202. This module is
Alarm rule base 203 maintains rules that identify each alarm condition. Each rule represents a set of conditions that must be evaluated to determine the presence or absence of an alarm condition. In particular, rule maintenance module 202, in response to requests from presentation module 10, generates rules, which are stored in alert rule base 203, as described below in connection with FIG. 10B. In addition, the rule maintenance module 202 can modify the rules in the alert rule base 203 in response to a corresponding request from the presentation module 10, so that the alert condition represented by the rule exists. Conditions are modified.

Similarly, the operation of detecting an alarm condition is performed by the detector module 20.
1, this module uses, for example, condition information located in the historical data file (FIG. 5) and alarm rules located in the alarm rule base 203. As discussed below in connection with Figure 10B, each rule includes a condition portion that identifies the condition. Detector module 2
01 determines whether the contents of the historical data file comply with the conditions of various rules, for example, to detect an alarm condition. If so, the detector module 201 generates an alarm indication and the general alarm module 201
00, the information is transferred to the presentation module 10 via the notification module 204 and displayed to the operator.

The general form of an alarm rule generated by rule maintenance module 202 is shown in FIG. 10B. With reference to FIG. The 0 condition part that indicates is the expression part 212
, a relational operator 213°, and an expression numerical part 214. The relational operator 213 converts the expression part 212 into the expression numerical part 2.
14, the condition part 210 is logically TRUE.
(TRUE) logically evaluates to FALSE (False). When the expression part 212 itself evaluates to logical TRUE or logical end, the relational operator 213 and the condition part 2
It can be seen that the formula numerical part 214 of 10 is unnecessary.In any case, the condition part is logical TR
If evaluated by the UE, an alarm condition exists.

The rule includes an entity and attribute portion 212 and a time value portion 216. rel-Op value part 213
associates the value of one attribute with one numeric part 214, the zero time value part 216 establishes a time function, and the condition part 21
0 may indicate the time or time interval that the alarm detector module 201 should use.

The provision of the alarm function module 11 allows the operator to establish alarm conditions dynamically and on demand.

Because alarm conditions need not be predetermined within the controller, the controller can be used to control and monitor a wide variety of complex systems. For example, when a controller is used to control and monitor a distributed digital data processing system that may have various configurations of nodes communicating through a network, alarm conditions can be based on the particular configuration. Can be established by the operator. Additionally, if a new alarm condition is discovered during operation of the complex system, the alarm condition can be added by adding a rule to the alarm rule base 203.

We will describe a system that controls and manages a group of entities. In this system, entities interface with the group to control the main information processing functions, and the entities further interface with the system to perform management functions. be able to do so. Such a system is equipped with a storage management module that performs management functions by independently translating and executing predetermined management-related commands, and the kernel translates the commands and sends the commands to each module to be executed. It stores a table of dispatch pointers that point to
The register is used to register new management modules with the system by adding another pointer to the table.

We will further describe a system that controls and manages a group of entities.
Entities interface with populations to control key information processing functions, and entities further interface with systems to enable them to perform management functions.

Such a separate system has a storage management module adapted to perform management functions by independently translating and executing predetermined management-related instructions, and the kernel has a storage management module adapted to perform management functions by independently translating and executing predetermined management-related instructions. Stores a table of dispatch pointers that direct instructions to.

A system that controls a group of entities and performs management functions will be described separately. This system is equipped with a storage management module that independently translates and executes predetermined management-related commands, and stores a table of dispatch pointers that translate and direct instructions to the respective modules to be executed, and the register is used to register new management modules with the system by adding another pointer to the table. be done.

Alternatives to such systems may include a management module adapted to request one or more state information from the entity, modify management parameters of the entity, or enable a self-test mode of the entity. The storage management specification information lists attributes related to the functionality and control of the entity, and the management capabilities of the entity, according to a universal specification language with a common syntax for representing the attributes and behaviors of any manageable entity. Management specification information may further list attributes and behaviors of entities that are subordinate to other entities. The management specification information can include polling information in a predetermined field of a common syntax. The polling information may include fields specifying a default rate and a maximum polling rate at which values for the attribute should be requested from the entity.

Further describing the system, the management specification information may include partition information in predetermined fields of a common syntax, where the partition information represents a group of attributes having a common data format. The management specification information can include set information in a predetermined field of the common syntax, the set information represents a group of attributes that have related functions in the management of an entity, and the management specification information can include command information in a predetermined field of the common syntax. The command information lists the management functions that the entity is to perform, the structure of commands to be issued to the entity, and the structure of replies to be received. The structure of the request to be issued may also include fields that list arguments to the command. The structure of the reply to be received may also include a field used to indicate that the requested action has been completed in a JIIi fashion.

Further, an alternative is described in which the structure of the reply to be received may include a field used to indicate an error condition that prevents the requested action from successfully completing. At least one management module includes an access module implementing a protocol for communicating with one or more entities. The protocol conforms to the Ethernet standard, or the protocol conforms to the DECnet P
hase IV standard, or the protocol conforms to the DECnet PhaseV standard.

Another alternative is described in which each instruction includes a field listing at least one associated entity and operation. The kernel includes a dispatcher that receives and communicates instructions based at least on the entities and operations listed therein. dispatch·
The table of pointers may comprise a data structure, a pointing graph of a sequential data structure with a graph corresponding to fields of the instruction. The dispatcher includes a scrutinizer that scrutinizes the instruction graph according to the entities and operations requested by the instruction and locates terminal data structures with dispatch pointers. The instruction graph can include wildcard flags and continuous data structures that can correspond to any value of a particular field of the instruction, or the instruction graph can correspond to any number of values of a field of the instruction. The ellipsis flag, which can A best fit unit may be provided to determine the fit.

An alternative to such systems is to include a scrutinizer with a best match unit that determines the most accurate match to the field of the instruction by first looking for an exact match to the field and then an ellipsis match to the field. ing. The instruction graph includes wildcard flags and continuous data structures that can correspond to any value of a particular field of an instruction, ellipsis flags that can correspond to any number of values of a field of an instruction, and continuous a data structure, the scrutinizer finds the most accurate match for the field of the instruction by first looking for an exact match for the field, then for a wildcard match for the field, then for an ellipsis match for the field. The best fitting unit is determined. A presentation device is used to display information to a user and receive instructions from the user, the instructions and information being represented in a particular predetermined format.

Yet another alternative system receives instructions from a presentation device;
A presentation module is used to communicate information to a presentation device, the presentation module including a conversion code that converts information received from an entity into a predetermined format for the presentation device, and a transfer code that communicates instructions from the presentation device to the dense batcher. .

The presentation module may include user interface information that defines the mode in which a user interacts with the system. User interface information may include assistance information that provides information to the user regarding how to use the system. The user interface information may include graphics mode information that defines pop-up menu contents and imperative review tables. The kernel may further include class databases that define the different management information available from each entity. The presentation module may include a menu generation routine that retrieves the pig from the class database and generates a menu of valid instructions to display to the user. The menu generation routine may determine information related to the composition of the population and generate a menu of available entities to display to the user.

Describes a system that provides control and management functions for the members of a computer network, in which the members interface within the network to control primary information processing functions, and the members further interact with the system. interface to enable administrative functions to be performed. Such systems include a storage management module that performs management functions by independently translating and executing predetermined management-related commands, a dispatch module that translates the commands, and directs commands to the respective modules to be executed. It includes a kernel that stores a table of pointers and a register that is used to register new management modules with the system by adding another pointer to the table. The register is adapted to register new management modules at any time during system operation. An alternative to such a system describes a system in which storage members store records related to administrative functions, each record including an associated time indication. The instructions specify a time range and the information manager satisfies the instructions by retrieving administrative information contained in the record, if possible, and otherwise:
Means is provided for satisfying the command by accessing information related to the defined time range from members of the network. Another alternative to such systems is that at least one module stores rules identifying predetermined alarm conditions, but includes a rule generator that generates and stores the rules and detects the alarm conditions depending on the content of the rules. Equipped with an alarm condition detector. The first category of management modules comprises functional modules adapted to perform functional operations on data presented by members of the network. The second category of management modules includes access modules that are adapted to implement protocols for communicating with members of the network. The presentation module is adapted to receive instructions from and convey information to the user using the primary information processing capabilities of the members of the network.

The storage device further includes region designation information defining groups of members of the network. The kernel can cause commands to be issued to all members of the group by issuing individual commands to the appropriate management module. The at least one management module is further adapted to perform self-management functions for itself by independently translating and executing self-management instructions. The information manager further includes a scheduler responsive to instructions specifying a time schedule. The scheduler is used to possibly enable subsequent dependent accesses or retrievals - possibly in response to instructions multiple times, according to a time schedule.

describes a process that exerts control and performs management functions over a population of entities, in which an entity interfaces with the population to control primary information processing functions and allows the entity to perform additional management functions do it like this. The process includes the steps of providing a management module that performs management functions by independently translating and executing predetermined management-related commands; dispatching and directing commands to the respective modules that are to translate and execute the commands; It consists of providing a kernel with a table of pointers and providing a register that registers new management modules in the system by adding another pointer to the table.

In order to be used in a system that controls and performs management functions over a group of entities, a management system is stored in such a way that it performs management functions by independently translating and executing predetermined management-related instructions. We refer to modules, in which an entity interfaces within a population to control primary information processing functions, and an entity can further interface with a system to perform management functions, where a system has multiple management modules and commands. It includes a kernel with a table of dispatch pointers that direct instructions to each module to be translated and executed. Dispatch pointers, which point to modules and are associated with instructions translated and executed by the module, are also discussed.

[Brief explanation of drawings]

FIG. 1A is a functional block diagram of a control device constructed in accordance with the present invention. FIG. 1B is a block diagram of information stored in the storage elements of FIG. 1A. FIG. 2A is a functional block diagram of a part of the control device shown in FIG. 1A, particularly a portion defining entities forming the control device. Figure 2B shows the structure of the management module. 3A to 3D define management specifications that define control charts provided by the functional modules and access modules that make up the control device shown in FIG. 1A, and FIG. Defines dispatch specifications for modules. FIG. 4 shows the structure of a data dictionary containing information defined by the management specifications shown in FIGS. 3A to 3D. 5 and 6 are functional block diagrams showing various modules and data structures of the control device shown in FIG. 1A. FIG. 7A shows the parameters used for requests generated by the presentation and functional modules of the controller shown in FIG. 1A. FIG. 7B shows the temporal context handling and structure of the context block used by the requirements of FIG. 7A. 8A and 8B show dispatch table data used by the dispatcher shown in FIGS. 5 and 6 in connection with processing requests from the presentation module and functional module of the controller shown in FIG. 1A. Shows a side street. Figures 9A and 9B illustrate the operation of the dispatcher in conjunction with its associated dispatch table in processing requests from presentation or functional modules. FIG. 9C shows the format of the configuration database and region database. FIG. 10A shows the structure of functional modules used to establish and detect alarm conditions, and FIG. 10B shows the structure of rules used to establish alarm conditions. 10... Presentation module... Function module 2... Access module 5... Information manager 7.22... Data storage device

Claims (1)

[Scope of Claims] 1. A system that controls and performs management functions over a group of entities, wherein the entity interfaces with the group to control major information processing functions, and the entity further controls the system. a storage management module adapted to perform the management function by independently translating and executing predetermined management-related instructions; a kernel comprising a table of dispatch pointers directing said instructions to respective modules to be executed; and a register for registering new management modules with said system by adding another pointer to said table. 2. A system that controls and performs management functions over a group of entities, wherein the entity interfaces with the group to control major information processing functions, and the entity further interfaces with the system to perform the management functions. a storage management module adapted to perform said management functions by independently translating and executing predetermined management-related instructions; A system comprising: a kernel comprising a table of dispatch pointers that direct said instructions to modules. 3. A storage management module that is a system that controls a group of entities and performs management functions, and is configured to perform the management functions by independently translating and executing predetermined management-related commands; a system comprising: a kernel consisting of a table of dispatch pointers that translates instructions and directs said instructions to the respective modules to be executed; a register that registers new management modules with said system by adding another pointer to said table; . 4. A system for controlling and performing management functions over members of a computer network, the members interfacing with the network to control major information processing functions, and the members further interfacing with the system. In a system capable of performing the management function, a storage management module configured to perform the management function by independently translating and executing predetermined management-related commands; A system comprising: a kernel comprising a table of dispatch pointers directing said instructions to respective modules; a registrar for registering new management modules with said system by adding another pointer to said table. 5. A method for controlling and performing management functions over a group of entities, wherein the entity interfaces with the group to control primary information processing functions, and the entity further performs the management functions. providing a management module configured to perform the management function by independently translating and executing predetermined management-related commands; A method comprising: providing a kernel consisting of a table of dispatch pointers to which instructions are directed; and providing a registrar for registering new management modules with the system by adding another pointer to the table. 6. Management that is used in a system that controls a group of entities and performs management functions, and is stored in order to perform management functions by independently translating and executing predetermined management-related instructions. a module that allows said entity to interface with said population to control primary information processing functions and further enable said entity to interface with said system to perform said management functions, said system comprising: A system comprising a plurality of management modules and a kernel with a table of dispatch pointers that directs the instructions to the respective modules that are to translate and execute the instructions.