JPH03105549A - Self control for entity managing system - Google Patents

Abstract

PURPOSE: To process a primitive operation in connection with entity constituting a composite system by providing a storage management module which operates entity managing function by independently translating a prescribed instruction, and operates a self-managing function to itself by translating and executing the other instruction. CONSTITUTION: This system is provided with at least one storage managing module which operates an entity managing function by independently translating and executing a prescribed instruction, and operates a self-managing function to itself by translating and executing the other instruction, and a kernel constituted of the tables of dispatch pointers directing to each module which translates and executes the entity management instruction and the self-management instruction. Thus, the entity controls a main information processing function by interfacing with a group, and operates a managing function by interfacing with a system.

Description

DETAILED DESCRIPTION OF THE INVENTION Field of the Invention The present 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 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 data. It is coming. The server may also control printers, telecommunications links, etc. Additionally, the server can perform specialized computational services such as database searching, classification, etc. The various computers, called requesters, and servers are interconnected by communication links to allow 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 summarized, the controller processes requests generated in response to commands from an operator through one or more acquisition modules, function modules, and power channel means, and displays access information in response to an operator.・Equipped with a module. The presentation module handles operator interface functions including receiving commands from an operator and presenting responses thereto. In response to commands from an operator, the presentation module generates requests.

The power channel means receives the request and sends it R for further processing.
to the Noh module. 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 for processing or to other functional modules. Ru.

The power channel means communicates received dependent requests to the access module for processing. The access module handles primitive operations in conjunction with entities that govern the complex system.

In general, the present invention is a system that provides control over a population of entities, performs entity management functions, and provides control and self-management capabilities over itself, wherein an entity interfaces with a population. It is characterized by controlling the main information processing functions and also allowing the entity to perform management functions by interfacing with the system. The system performs entity management functions by independently translating and executing predetermined instructions, and also performs self-management functions for itself by translating and executing other instructions. and a kernel consisting of a table of dispatch pointers that point to the respective modules that are to translate and execute entity management and self-management instructions. Each entity management instruction lists the identity of the associated entity and the action to take, according to the common instruction syntax, and each self-management instruction lists the identity of the associated module and the action to take, according to the common instruction syntax. are doing. The kernel includes a dispatcher that receives and delivers instructions based at least in part on the operations and entities or modules listed in the dispatcher.

The system includes a storage device comprising records of management information related to management functions, each record including an associated time indication. The kernel further satisfies the instructions, if possible, by retrieving administrative information contained in the records, and in other cases, by accessing information related to the specified time range from members of the network. Equipped with information management with means. At least one module stores rules identifying predetermined alarm conditions and includes a rule generator for generating rules for storage and an alarm condition detector for detecting alarm conditions in response to the content of the rules. 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 that are adapted to manage the protocols that communicate with the members of the network. Some presentation modules use the network's primary information processing capabilities to receive instructions from and convey information to the user. The kernel also includes a class database that defines the different management information available to members of the network.

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 determines information related to the configuration of the network;
A menu of available members of the network is generated and displayed to the user. The system also includes a storage device with region specification information defining groups of members of the network, and in which the kernel allocates all members of a group by issuing explicit instructions to the appropriate management module. It is designed to issue orders to members of the group. The registrar registers new management modules with the system by adding another pointer to the table. The information manager further includes a scheduler responsive to instructions specifying a time schedule, the scheduler possibly enabling a series of dependent accesses or searches in response to the instructions, possibly multiple times, according to the time schedule.

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. (The complex system itself is not shown.) A complex system ρJ, controlled by the equipment preliminarily shown in FIG. A distributed digital data processing system is comprised of a plurality of nodes including components of.

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. IA 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 prompt 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. As will be explained in more detail below, the apparatus of FIG. IA has scalability features that allow the apparatus to be modified to efficiently accommodate 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 may contain 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. IA, the controller is connected to the presentation module IO
A to IOK (as a whole distinguished by the reference numeral 10),
Functional modules 11A to IIM (generally reference numeral 1
1), and access modules 12A to 12M (generally identified by the reference numeral 12). Presentation module 10
Typically provides a user interface for a user to control a complex system, including control of terminals used by system operators. Each V1 function module generally performs management control and monitoring associated with one class of VA functions. Each access module 12 generally provides administrative control over a particular type of controllable entity within a control system, a set belonging to a class of controllable entities. The presentation module 10 communicates with the functional module 11 through the presentation/functional aspects of the kernels 13, 14 (hereinafter referred to simply as the presentation/I! function kernel 13), and the functional module 11 communicates with the functional/access aspects of the kernels 13, 14 ( It communicates with the access module through the function access kernel 14). The functionality required from the control modules IO, 11, 12 may vary widely depending on the topology of the complex system being managed. Therefore, the control module 10 is designed to provide adaptive and scalable management.
, 11, 12 can be dynamically added or subtracted to the device to adapt the device to the topology of a particular complex system and to changes in that topology. 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 complex systems, in this way for example the management of distributed data processing systems. Tasks related to the protocol can be separated from tasks related to displaying management information to the user, for example.

A. Presentation Module More specifically, the presentation module 10 performs presentation services, which may include, for example, 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 consist of an interface support device. The presentation service is required independent of the management function or entity managed by the system shown in Figure IA, and is 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. The pond presentation module 10 provides 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 and functionality kernel 13, which may be annotated by portraits, menus, graphics, or commands entered by the operator via the command line. management information is transferred to a video display terminal used by an operator for display.

Bll Functional Module Functional module 11 is associated with and supports specific management applications performed by the control device shown in FIG. 1A. The management application constitutes a complex system managed by the presentation service provided by the presentation module IO (other than to the extent that the presentation module 10 informs the operator about the management aggregation performed by the $IJ management) and the control management. It exists independently of any particular entity.

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 analysis, the functional module accesses communication data such as the number of packets and the number of bytes sent from several entities of the distributed data transmission system. The functional module then matches the information with higher level information such as average 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 example above, functional modules ``add value'' to the management information available from multiple systems in the form of data matching or correlation services.

In addition, functional modules utilize data produced by other functional modules to provide high-level services for managing complex systems.

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 it to the operator through the presentation module 10 .

Other functional modules 11 define, for example, the dimensions 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 to and subtracted from the network. allows the operator to control the sides of the network, change the access rights of various users of the nodes, and maintains a configuration (or stage) database that allows the operator to decide on changes to the configuration of the network at any time. It can be equipped with a configuration R function module that can perform Other functional modules 11 within the controller may, for example, control various alarms indicating that certain events have occurred in the distributed digital data processing system. This alarm function module l1 monitors the status and conditions of various entities of the distributed digital data processing system and generates alarm instructions to the operator, while the appropriate presentation module 10 is configured to Advise the operator.

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

Other functional modules 11 operate, for example, as historical data recorder functional modules 1l, 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. A management application may require the services and operations of a number of access modules 12 in a particular order, and the management aggregation support functional module 11 may require the services and operations of the various access modules 12 needed to accomplish the management aggregation. Coordinating the sequence of operations by module 12.

The management aggregation provided by one functional module 11 may require the aggregation of another functional module 11 within the control device, whereby that one functional module is also coordinated. The function module 11 is initially called by the presentation and function kernel 13 in response to an administrative request entered by an operator obtained by the presentation module 10. The functional module 1l is also called by requests directly received from other functional modules 11. Additionally, 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 as shown in FIG. Assist. For example, in a distributed digital data processing system, an entity refers to the system's various hardware components, including the various computers, disk and tag storage devices, routers, etc. that can constitute the nodes of the distributed digital data processing system. In addition to software components, it can also include software components including virtual circuits, databases, and the like.

The access module 12 is called by the function access kernel 14 in response to a request from the 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. You can do it. One access module 12 can, for example, control and monitor the status of various parts of a network linking two local area networks, and transmit messages between nodes of two local area networks. Be able to say one pause. Such access module 1
2, for example, initializes the bridge, allows it to start operating, disables the bridge, monitors its end-to-end operation, checks the number of messages passing through the buffers it has, Determine whether you have sufficient buffers to operate effectively within the system a. I can do Z.

Other access modules 12 include various information indicating the operation, virtual circuits, sessions and other links established between nodes, activity, and inactivity with respect to the message generation and decoding portions of the various nodes of the distributed digital data processing system. Timers and force counters, etc. can be controlled and monitored.

Similarly, the pond access module 12 controls and monitors the operation of the network layer portions 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 can be established.

In certain embodiments, the access module provides access connectivity testing to management functions at an Ethernet LAN bridge or a port fraction control and checking function at an IEBE802fi-enabled Ethernet station, an Ethernet repeater, or a management function at an FDDI entity. I can cheat. In addition, the access module is
DECnet published by Equipment Company. Ph
a s e IV or Phase V node, or D
It can be provided to access the management support device on the EC terminal server. D. The request control modules 10, 11, l2 interact with each other and with the user through requests. There are two general forms of requests. A request can, for example, cause something to occur within a complex system. In other words, the state B or conditions of the complex system can be changed. In processing such requests, 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. The access module 12 that processes such requests generates state information indicating the status of the request and returns this to the functional 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 a request, one or more access modules 12 determine the state or condition of the entity and report it to the functional access kernel 1.
Return to 4. Fi! ! In this case, information stored in the control unit (e.g., by a historical data recorder functional module) can be used to satisfy the request. In that case, requests can be of both types. That is, a request can change the state or condition of one or more entities, and can request information about the changed state or condition of the entity. In processing such a request, the access module 12 causes changes, if possible, to include state information regarding the state of the request as well as the state of the entity! r3 or article rt-
Also returns information related to.

Requests can be generated in response to operator actions 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 Kernels 13 and 14 are information managers 15 and 20 (hereinafter simply referred to as information manager 15 or information manager 20, but they form one and the same information manager), dispatchers 16 and 21 ( (hereinafter referred to simply as dispatcher 16 or dispatcher 21, forming one and two dispatchers), and a data storage element 17.
, 22 (hereinafter simply referred to 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 devices, depending on the type and amount of data to be stored. means can be provided. Additionally, data in different formats may be stored in various storage means for later use by the kernel.
All these means are integrated into one data storage element 17,
22.

Referring to FIG. 1B, in one embodiment, the data storage elements 17, 22 store 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. as obtained by the historical data recorder functional module 11. This is stored in the historical database 26. Other information may also be stored in data storage elements 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 a user's scope of control. Alternatively, region information can be stored as an element in a treetop or database.

The alarm module can also use the alarm rule base 24 to confirm alarm conditions within the complex system. Other information relating to individual modules within the control device may also be held in the storage elements 17, 22. For example, as detailed below, dispatchers 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 menus and prompt user requests. G. Information Manager Referring to FIG. IA, information manager l5 receives a request from presentation module 10 to which it can respond using information in data storage element 17, as will be explained in more detail below. Then, 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, the 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 a 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, each represented by a request, hereinafter referred to as dependent requests, 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 . Dispatcher l6 formats the response and communicates it through information manager 15 to the appropriate presentation module 10 for display to the operator.

The functions and access aspects of the power channel 14 are handled by the information manager 20.
, a dispatcher 21, and a data storage element 22
It is equipped with Dependency requests from functional modules 11 directed to functional access kernel 14 are initially received by information manager 20 . Data storage element 22
The access module 10 may also be provided with information generated from the historical data recorder function module 1l regarding the state of the complex system at each point in time, in particular with predetermined 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. Then, this is transmitted to the functional module 11 which is the source of the bt attribute 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 a dependent request from information manager 20, dispatcher 21 identifies the access module 12 to which the dependent request should be communicated and forwards the dependent request to this access 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, dependent request or 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 requires access module 12 to do both of the above, access module 12 attempts to change the state or condition of the entity, and determines the state of the attempt and the new state or condition of the entity. Generates a response that also indicates the condition. 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. The R function module 11 is the dispatcher 1
The response from access module 12 is used in formatting its response to a request from access module 6 or to a dependent request from pond functional module 11, as applicable.

When the functional module l1 receives a dependent request from another functional module 11, it processes it in the same way as it processes a request from the desbatcher 2l.

advantage The control system shown in Figure IA 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, if the information manager 15.20 is able to process the request based on the contents of the associated data store 1722 without the need for further processing to the pond elements further down the chain, the information manager 15.20 .20 does that. Furthermore, since the control device is expandable, additional presentation modules 10, functional modules 11, and access modules 12 can be easily added without changing the structure of the control device, as described below. I can do it. The addition of functional modules 11 and access modules 12 is performed by the registration method, which will be described below in conjunction with FIG. Module 10.11
The addition or deletion of or 12 may include certain data distributions of data storage elements 17.22, as described below.
and other data structures maintained by the presentation module 10, as shown in FIG. , the control device itself can be easily managed. The same dispatch and request models used to issue management commands to a complex system can also be used to issue commands to the management module itself. This eliminates the need for a separate management application 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 device for the module, allowing the module designer to support the user interface for each module. Free yourself from the burden of doing so. This type of "automatic" user interface support ensures a uniform look and feel for the user interface, regardless of the source or nature of the management module being used. When the controller is used to control a distributed digital data processing system, the controller, including its various elements, comprises a plurality of routines processed by various nodes and computers that control the distributed digital data processing system. be able to. That is, the computer equipment need not handle the modules that make up the controller that controls the distributed digital data processing system other than those that make up the controlled distributed digital data processing system. Requests, dependent requests,
and the response f3 can be transferred between parts of the control unit that may exist to different parts of the same process, to different processes of the same node, and to different nodes. If the modules reside in different processes on the same node or on different nodes, the sixth
The inter-process and inter-node communication mechanisms shown in the figure and described below send requests and dependent requests as well as responses.
Used to transfer 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 Figure IA 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. The complex system includes one or more entities 36, each entity 36 including a service element 31, a management interface 30, and a service interface 33.
It is equipped with Management interface is agent 3
4 to control and monitor service elements. A service element is the actually managed portion of entity 36 and performs the entity's primary functions or functions. That is, service element 31 performs the functions of an entity that is required within the context of a distributed digital data processing system. For example, if an entity communicates to a node through the network, the service element 31 communicates. As noted above, service element 31 includes management interface 30 and service interface 33.
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 ascertain the operational status of the entity 36. By communicating through the service interface 33, the commander 35 can control and monitor the service elements 31. If this is not the case, this may be a predetermined communication parameter 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. This is done by determining the attribute conditions. 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 pagets conveyed and the number of bytes conveyed.

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

The service interface is concerned with the functionality of the entity, and the management interface is concerned with the operation of the agent 1~. The commands and attributes accessed through the service interface characterize the functionality of the entity, while the commands and attributes accessed through the stub interface characterize the control and monitoring of the entity.

Clarify the roles of the two interfaces. To give an example of how to apply the above model to a particular entity, consider a controllable entity, a modem. Modems can be equipped with 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. Baud rate, line selection, and power switch settings are related to the modem's immediate operation and are themselves accessible through the service interface. Line utilization and the elapsed time since the modem's last self-test and 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 an entity but are not themselves stored by the entity. Pseudo attributes are attributes that are generally needed to explain an entity model, but are not provided by the entity. An example is IMPLEMENTA which is a composition of the attributes IMPLEMENTATION TYPE and VERSION supplied by the entity.
T10N, and CREATIONTI of the entity
It is ME. 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 FIG.
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.

As noted above in J8 management module management, the control device that controls the distributed digital data processing system uses various presentation modules 10.
, functional modules 11, access modules 12, and kernels 13.14 are processed by the various nodes making up the distributed digital data processing system. In that case, the various modules 10.11 and 12 and the kernel 13.14 represent entities within the complex system and are controlled in the same way as other entities, as described above. The dispatch and request models used to issue management commands to a complex system can also be used to issue commands to the Sugaku module itself. As you can see from the dispatcher specification below, in the pool of 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 the request syntax. Therefore, as the ability to manage complex systems increases by adding new control modules, the ability to manage control devices increases as well. Detailed explanation A, management module management 1. i[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 comprises an access protocol for the entity class serviced by the access module.
In the case of a VA functionality module, 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 module's R capabilities. 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 data for a scrutiny table or presentation form, 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 Figure 2B, dispatch pointer 39A relates to procedures within a module that performs management services for the complex system, while dispatch pointer 39B relates to procedures within a module that performs management services for itself. It has to do with procedures. As explained above, when a module is registered with a controller, two 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 associated with command and response structures that request services from the module, as well as management specifications 48 that describe the 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, composition, 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 specified by the management specification and the dispatch specification. It will be done. Figures 3A to 3D are details of the management specifications for the entity, and Figure 3E defines the dispatch specifications used to initiate specific operations in relation to the entity. 3rd A first
Referring to the diagram, the management specifications for the entity are in heading section 4.
0 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. Body portion 45 is further defined in Figure 3A. Preliminarily, the controller comprises two general types of entities: global entities and dependent entities. The control device 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, as made clear above. The main body part 45 of the specification includes provisions for two types of entities, namely provisions 45A for global entities;
, or provisions 45C 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 published by Digital Equipment, Inc. of Maynard, Massachusetts.
Occurs in net Phase IV. DECnet
In Phase ■, 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
A mechanism must be provided to indicate that the management specification for a class exists within the management specification for another module (which manages the node 4 circuit class). Provisions 45A and 45C for global entities and dependent entities, respectively, are further defined in FIGS. 3A-3D. The entity specification 46 comprises a name field 47 comprising a name and a code by which the entity can be identified. Additionally, a name field 47 identifies the entity as a global or subordinate entity and identifies the entity's class name. Entity provision is W:
If it is for a genus entity, it has an upper field 50 that identifies an upper entity in the hierarchy. The identifier field 51 is later added to the entity body portion 5.
It has a list of attribute names for the attributes specified in 3. Finally, symbol field 52 contains symbols used to generate special compiler constant files with consistent names for use by entity developers. In another embodiment, the entity definition may include a DYNAMIC field. This field has the value T
It can have RUE or FALSE and indicates whether the entity's management specifications should be stored in the tree control database {Figure IB}. This gives management module developers a way to precisely indicate which dependent entity stages should be stored in the configuration database. In this way,
It eliminates the need to store highly dynamic entities such as connections between nodes in the system architecture. 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 stage of the entity class is not stored in the precept. If FALSE, the stage of the entity class is stored in the configuration.

As noted above, the entity definition 46 for an entity comprises a body portion 53. Main body part 5
3 is specified in detail in Figure 3B. Referring to FIG. 3B, the book # part 53 of the management specification has four parts, namely, an attribute partition provision restructuring 4, a collection provision restructuring 5, a directive provision restructuring 6, and when an entity class contains subordinate entities. It has a dependent entity list 57. If the body portion 53 comprises a dependent entity list 57, each entry in the dependent entity lister 7 is rsUBORD I NATE,
Entity definition 4 with a name field 47 containing
6 (Figure 3A). As mentioned above, the entity body is an attribute partition list 54
and attribute set restructuring 5. At this point it is useful to explain the distinction between these lists. Each list takes a complete combination of an entity's attributes and combines each attribute into one or more groups. The groupings indicated by the partition list 45 are independent of those indicated by the set list, each list being an independent specification of the attributes of the entity.

The partition restructuring 4 identifies all attributes of the same shape and groups them. For example, the attribute PART I T I ON can comprise all counters or all state attributes (flubs). The word "partition" is used to indicate that the group formed by the attribute partition is a 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 Node4 global entity class may define an attribute set that reads rsQUARE. The SQUARE attribute set is a node 4 class.
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 be able to select SHOW MODE <instance> ALL
These statistics can be viewed together with commands such as SQtlARE.

The term "set" is used to indicate that a set contains attributes that have similar functions, 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 sets.

Attribute partition definition list 54 may further include one or more attribute definitions 64 as defined in FIG. 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. It has a type field 56.
For each attribute format, the data format is an additional field 68
It is established by Attribute partition definition 54 may also include fields 60 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 can 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 state and condition information. In addition, the attribute definition comprises one or more attribute fields 62, each comprising an attribute name 63. This field comprises a code by which attributes can be accessed, and an associated attribute body 64. As shown above, all the specifications for attributes that are members of a partition are one partition specification 54.
It's inside. Independent aspects of an attribute are indicated by one or more attribute body definitions 64. FIG. 3B further describes the information contained in the attribute body 64 of the attribute field of the attribute partition definition 55.

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 70 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 CONF.
IGURATION, FAULT, PERFOR
MANCE, SECURI TY, or ACC
Categories defined in the 74-98-4 Open Systems Interconnect (OS I) standard, including, but not limited to, the In addition, if the polling speed for a specific attribute specified by the attribute body 64 is different from the polling speed specified in fields 60 and 61 of the attribute partition specification 54, the attribute body 64 is set to field 7.
2 and 73 can be provided with polling speed information. Finally, the attribute body 64 may include a proprietary variable field 74 that identifies proprietary variables used by the management module when processing in connection with the attribute. In another embodiment, polling speed information may be omitted from the attribute specification altogether, as the accuracy of this data is implementation specific. In another embodiment, the attribute body 64 may include a UNIT field.
If a UNIT field is provided, numerical data can (and should) have its specified units. Attributes can be grouped together to simplify the management of complex systems. The set definition part 55 of the entity body 53 identifies one or more sets that the entity has. The contents of the attribute definition portion 55 are defined in detail in FIG. 3B. The set specification portion 55 includes a set name field 75 for identifying a set, and an attribute list 81 for identifying attributes included in the set. The set definition part 55 may also comprise commands, ie requests, lists, which can be processed by referencing the set. Set definition portion 55 includes a symbolic field 77 similar to the symbolic field described above, a category field 80 which may include, but is not limited to, OSI category information, and a set identified by the collective 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 control device in response to requests and subordinate requests from the presentation module 10 and the functional module I1, 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 the command setting 56. Figures 3C and 3D show the structure of directive provision 56 in detail. Referring to Figure 3C, Designation Regulation 5
6 comprises a name field 83 with a code by which the command can be identified and accessed.

The command includes a request specification field 90 that identifies the structure of the request or dependent requests, a response specification field 91 that specifies the structure of the response, and an exception specification field 92 that specifies the structure of exceptions that may occur during processing of the command. I am prepared. 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. It is also possible to include a field 84 indicating whether the file only starts. In another embodiment, the effect field 84 may be set to
I NE, MODFY format or ACTIO
DIRECT TYPE indicating whether it is of N format
Can be replaced by fields. The EXAMINE directive operates only on attributes and does not modify them.

The SHOW command or the DI RECTORY command is used as an open command. The MODEFY directive operates only on attributes and makes modifications. Examples are SET, ADD. or REMOVE
There are various instructions. The ACTION command does not work on attributes, but on the entity itself. For example, CREA
There are TE and TEST directives. 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. In addition, category field 87 is
As defined above in connection with field 71 (FIG. 3), one or more OSI 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 rREQUBsTJ,
Request bidirectional field 90 includes O or more arguments 91 defined by name field 92, each containing an access code.
can be prepared. 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 has a field 94 that indicates whether the overwriter must provide a value for the argument, a default field 96 containing the default value, a symbolic field 97 containing the identifying text string, and the argument value. A unit field 95 indicating the unit of measurement of can also be provided. 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 active field is SU when the response fulfills the request specified by the request field.
Whether CCBSS 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. Additionally, the response definition field may include one or more argument fields 104, each including a name field 105, 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 provision field 92 is similar to the structure of the response provision field 91, which includes fields 111 to 117 similar to fields 101 to 107 of the response specification 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. A pool display field can be provided to indicate the 3. Dispatch Use Figure 3 defines a dispatch use 39A (Figure 2B), which is used to define the initiation of a particular operation by an entity. The information in the dispatch usage for an entity is used to generate a pointer to the procedure that performs the operation. Referring to Figure 3E, the dispatch usage includes a heading 2o○ which defines the beginning of the dispatch usage and contains the table name, and a footer 2 which marks the end of the dispatch usage.
Equipped with 01. Between heading 200 and footer 2o1, 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. The directive operates on the entity, or it can operate on the attributes defined by the attributes portion 205 of the entry defined in the entity entry. The contents of entity entry 2o4 correspond to the entity or subentity identified by the entity class and stage name in name fields 47 and 50 of entity specification 46.
Similarly, the contents of the attribute portion 205 correspond to the attributes identified by the name field 62 of the attribute definition 54 of the entity body 53 of the entity definition 46 .

Disbatch entry 202 also includes procedure pointer portion 20
6, which is the date batch entry 202
The access manager processes the commands in conjunction with the entities and attributes identified in portions 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 traversal, 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 transfer
Dispatch engine 134 (Fig. 5)
used to stylize images). The request or dependent request essentially specifies the verb, entity, and attribute partitions, and the kernel disbatches the verb, entity, and attribute partitions specified by the request, specified by parts 203, 204, and 205, respectively. Compare the contents of the data structure section. If each part of the verb matches the contents of the corresponding part of the data structure (Figure 8B), then kernel 13.14 is a dispatch specification (Figure 3E).
Dispatch entry 1, which is contained in part 206 of
Initiate the procedure specified in Section 34. B. Data files and usage 1. Registering a data dictionary management module allows its management specification to specify new entity classes, subentity classes or attributes, global or subentity directives, or events. The management specifications (Figures 3A to 3D) are used to configure the data dictionary;
Data dictionaries are used to configure 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 is constructed from a three-hierarchical database having the general structure shown in Figure 4. Referring to Figure 4, the organization includes a relative root node 220 that is associated with a global entity defined for administrative use (Figure 3A).
The global entity node includes a subordinate node 221 that lists all attributes of the hierarchical organization of the entity body 53 of the entity specification 46 of the management specification, a subordinate node 219 that lists attribute partitions, a subordinate node 222 that lists attribute sets, Subordinate node 22 that lists directives
3, and a subordinate node 2 that lists the subentities.
Refers to multiple subordinate nodes, including 24.

Each subordinate node 219 to 224 indicates 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 the attribute regulation 54 of the entity body 53.
Each of the set nodes 222 refers to a set provision node 226 having a set provision defined by the set provision 55 of the entity body 53, Command node 223
refers to the command provision nodes 227 each having a provision of the command specified in the command provision 56 of the entity body 53, and the subentity nodes 224 each having a provision of the command specified in the subentity provision 57 of the entity body 53. Points to the subentity specification node 228 that contains the entity specification. Each command node 227 includes a request node 230, a response node 231, and an exception node 23.
2, each of which in turn corresponds to the management specification requirements 90,
It includes request, response, and exception provisions taken from response provisions 91 and exception provisions 92 (Figure 3C). fl
! 1, each subentity node 228 has a dependent node 233 for attributes and a dependent node 23 for sets.
4. Create a suborganization root node with a structure similar to that depicted for the global entity shown in FIG. I am disciplined. The organization shown in Figure 4 is the third
It is repeated for all sub-entities defined in the management specifications shown in Figures A through 3D and their sub-entities.

The information in the management specifications is fused into respective nodes of the data dictionary to display entity information, including entity identification information and response information, to the operator, and to the controller pool portion and complex system, as described below. is used to create two user interface information files that are used by presentation module 10 in connection with the generation of processing requests by entities. The various nodes of the data dictionary receive information from the elements of the management specification to form a complete database of data dictionaries. The information within the dispatch specification (Figure 3E) is used to create the dispatch table 28, as described below in connection with Figures 8B and 9. With this background, FIG. 5 shows one presentation module 10,
Function module 11, access module 12 and information manager 15.20 and dispatcher 16.21
A kernel 1314 with . Additionally, FIG. 5 shows various parts of data storage element 17.22. In particular, data storage elements 17.22 include configuration and domain databases 23, 25, alarm database 24, historical data files 26, data dictionary 2.
7, and a disk batch table 28. 2. Historical Data File The historical data file 28 is a representation of the kernel 13.
In the case of the function aspect, information regarding the state and conditions of the entity, in the case of the function/access aspect of the kernel 14,
It is equipped with 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;
Determine 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, Disbatch
Table 28 contains invocation information that facilitates initiation of various operations by each functional 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 routine of access module 12. This position is a dependent request from the functional module 11, i.e.
It is used to process invocation information that specifies various actions by the respective entities.

4. The user interface information control device further includes a user interface information file 29 containing information regarding the various functions provided by the function module 11 and the entities controlled by the access module 12. The user interface information file 29 includes information obtained from the management specifications of each entity. Presentation module 10 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 entities of the complex system.

5. Configuration Database As described above, the configuration function module can create and maintain a 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,
A presentation module can be used to create a review table or user menu that lists the available entity stages. The configuration database can also provide a domain database that limits the scope of user control to limit the 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 requesting an inventory of all entities in the configuration that match the wildcard request. The configuration module then uses the information in the configuration database (along with the 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 SHOGA MODE IN DOMAIN SITE
1 (where SHOW is the command, DOMAIN is the realm entity class, SITEI is the realm stage, NODB is the global entity class, and fire is the Winoredo card) is the realm named SITEI is interpreted as an instruction indicating all the stages of a node within.

In this way, the presentation module sends each request to S H OW
Expands into several requests in the form N O D B <instance>, where <instance> is the name of the stage, one corresponding to each stage of the NODE class of the area SITEI.

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

For example, rNODE OOJ is rNODE FOO
” and rNODE MAGOOJ, but r
Not compatible with NODE BARJ. Partial wildcards cannot be used for fields with certain data type identifiers, such as text or numeric strings.

The preferred implementation does not allow wildcard expansions in user-directed global entity class fields. Global class specifications are not wildcarded. This is because doing so would result in insufficient control over the scope of the command. This can generate errors if command names supported by one entity class are 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*" command). In addition, the global entity wildcard can contain more information than the user intended (for example, the rsHOW*J command).
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 access modules. This is especially true if no configuration function modules are used. In the absence of a configuration function module, the access module (typically involved in accessing all modules of a class or subclass) stores stage data as part of its proprietary storage 32 (Figure 2B). In this case, the access module will use the stage data to expand the wildcards of the received request.If wildcards are not supported by the particular access module, this condition will be The exception shown will be returned to the user.

C. When data file management and registration management modules are added to the control device, or when new information related to the management of entities becomes available, the control device must adapt.

The controller is data-driven and the associated data files must be modified to adapt the system to new modules or information. This process is commonly known as data file management. The specific procedure for adapting a 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 file 26 are provided and maintained in part by functional module 11, which acts as a historical data recorder functional module. In this practical example, 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 allowing requests to be issued, other forms of requests may cause the operator to initiate other actions associated with the historical data recorder functional module, including changing the polling rate and Enable or disable and indicate the last value in the response. 2. Dispatch Table The contents of the dispatch table 28 and of the user interface information file 29 contain registration information for registering modules with the control device, provided by the various functional modules 11 and access modules 12 during the registration procedure. During the registration procedure, the module loads display information, including name and code information, from its name field into the data dictionary. In addition, the module retrieves code information and other information specified in the management specification from the data dictionary (Figure 4) and dispatch information from its dispatch specification (Figure 3E) into the dispatch table 24.
Load into.

3. The user interface information presentation module 10 uses the display information of the user interface information file 29 to initially display entries,
Second, it is determined whether attributes, commands, etc. are to be displayed, and secondly, what is to be displayed. The user interface information file 29 is configured to:
Presentation module 10 receives the instructions, reviews the instructions using a review table, and issues the request. It is possible to obtain the code corresponding to the attribute code specified in the entity and management specifications, and send this to the kernel 1 as a request.
Transmit to 3.

Function modules and access modules are
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, the 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 and is used by dispatcher 16 to route requests to eligible procedures to process requests, as described below in connection with FIG.

Using code in the review table and in the dispatch table 28, while using presentation specific information in the two user interface information files, entities, attributes, etc. can be identified by the presentation module 10 to the operator, as used by the dispatcher 16. It can be seen that it is virtually separated from the identification displayed in . 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, the class data in the data dictionary (Figure 4) represents 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. r S H OW NODE FOOJ
rsHOW. +), so the scrutiny table should have directives as the first level of the hierarchy. As you can see from the example above, the scrutiny table is based on the class name (
e.g. rNODB,) is the stage name (e.g. rNODE)
This is necessary because the instruction will be examined if it is mixed with FOOJ's 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. Although class and data type information is available from the database, wildcard expansion allows stage data to be obtained from a tree or database. Therefore, the scrutiny table in the user interface information file is
Classes can be integrated, and user input scrutiny is considered more efficient. The above example also applies to graphical or menu-driven interfaces. However, in this kind of interface, the user has no control over the subsequent behavior of a particular entity or entities! kA,
You may wish to set the context for your command by graphically selecting the OSI category (listed in the command specification category field 87) of the command to be performed. You can then 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 an entire region or entity class (by clicking on just the commands). I can.EXAMI N
For E-style or CATEGORY-style commands, a separate menu may prompt the user to select an attribute partition or set. To implement 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. Additionally, a morphological database can store commands supported by classes or domains. The user interface information file can also store default value information. Default values for a stage or class may be provided by the user or by administrative specifications for the associated entity class. This allows users to save typing time by specifying default values within the command. For example, users may be most interested in NODE FOO.
NODE FOO, can be specified as the default node. Later, the user can use rsHOWROUT
You can type a command like INGJ, which will be interpreted as rsHOW NODE POOROUTINGJ. Similar usage of default values can be utilized in graphical environments.6 Another example of user interface information is the online auxiliary files available to the user through the presentation module. Auxiliary files contain auxiliary information for making use of the existing set of management modules. In the preferred embodiment, the auxiliary file is constructed from the auxiliary g1 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. In addition, personalized guidance 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 portions associated with the maximum polling speed field and the default polling speed field, to the attribute specification 54. Polling can be initiated and controlled in relation to various attributes of the identified entity, and 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. load display information into the user interface information file 29, including information from that portion of the data dictionary that pertains to the display field of the . Similarly, the functional module 11 obtains code information and other information specified in the management specification from the data dictionary (Fig. 4), and dispatch information from the dispatch specification (Fig. 3).
(Fig. E) to the display table 28.

D. Communication between modules and nodes 1. In one specific embodiment of the control function module, an operator can access
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 example, the presentation module 10 receiving instructions:
The instruction is examined using the examination table of the user interface 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 presented as a request. It is transmitted to the functional 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 control function module 11, dispatcher 21 calls access module 12 using dispatcher information in dispatcher table 28. Dispatcher table 28 also forms a scrutiny table, which is used by dispatcher 21 to route the request to the appropriate procedure and process the request, as described below in connection with FIGS. 9A and 9B. 2. When the intermode communication controller controls a complex system consisting of a distributed digital data processing system, FIG. a functional module 11 and an access module 12 containing data files 23, 24, 25, 26, 2γ;
Elements are shown including a dispatcher table 28 and a user interface information file 29 that are included in a single process on a single node of a distributed digital data processing system. Distributed digital data processing system presents module 10, functional module 1
1 and access module 12. The control unit includes dispatchers 16, 21 for all processes and nodes, if provided for different processes or nodes. Referring to FIG. 6, when the dispatcher 16(1) of one process of one node receives a request from the presentation module 10(1) that must be processed by a second process or functional module 1N2) of the node. , the dispatcher 16 ( 1 ) sends the request to the process of the other node or the dispatcher 16 ( of the node) by the inter-process communication mechanism or by the inter-node communication mechanism when the functional module 11 ( 2 ) is in another process of the same node. 2). The dispatcher 16 (2) then selects the functional module 11 (2) to process the request.
) receives the response generated by the functional module 11(2) and transmits it to the dispatcher 16(1) via the inter-process communication Wv4 or the inter-note communication device, and the dispatcher 16(1) sends the response to the presentation module 10(1). )
allows the response to be displayed to the operator. Similarly, the dispatcher 21(2)
When the access module 12 (3) of another process or node receives a dependent request from 1 (2) to be processed by the access module 12 (3) of another process or node, the dependent request is sent to the other process or node by the inter-process communication device or the inter-node communication device, respectively. The information is transmitted to the dispatcher 21 (3'). The dispatcher 21 (3) then communicates the dependent request to the access module 12 (3") for processing. The dispatcher 21 (3) receives the response from the access module 12 (3) and sends it to the access module 12 (3") for processing. or the inter-node communication mechanism to the dispatcher 21 (2), and the dispatcher 21<2)
couples this to functional module 11(2).

3. Figure 7A shows the structural requirements of the request and dependent requests, especially the structure of the parameters included with the request. The structure and contents of dispatch table 24, which is the same as the organization and contents of dispatch table 26, will be described in connection with FIGS. 7A and 7B. Examination of future requests and I! Information manager 15.20 and dispatcher IG,
The process carried out by 21 will be described in connection 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 operator actions.

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 Figure 7A. Kernels 13 and 14 as explained above
is a single dispatcher 16. having a presentation/response aspect 16 and a function access aspect 21. It is equipped with 21. The initial invocation identifier determines which of these aspects are enabled by each request. The initial call identifier can indicate a call to a functional module or an access module, each directed to a corresponding aspect of the dispatcher. 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, but a presentation module can only call an access module through the "control function module" described above. Can be done. The parameters include a verb field 120 whose content identifies the type of request, ie, the action to be taken in processing the request. As noted above, a request may initiate a change in the state or condition of an entity of a complex system controlled by a functional module 11 or an access module 12, and may cause information regarding the state or condition of such entity, or both. You can start the return shipment. Verb field 120
The content of indicates the action to be performed by the functional module 11 or the access module 12. Additionally, the request comprises an input entity specification field 121, which identifies the entity of the complex system being controlled. If the verb is a non-action verb, e.g. 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, that is, if the verb causes a change in a given entity, then the request does not have an attribute pointer field 122. In addition, the request may include a pointer to a time data interpolation that includes certain timing information, including absolute system time, time interval specifications, and time accuracy specifications, and specifications regarding the time range in the request for scheduling purposes. input time specifier field 1 with
It is equipped with 23. Input/output context handling field 12
4 has a value that identifies a request in the context of a multi-part operation, 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. ing. The request is sent to the functional module 11 in connection with the formation of the response.
(or access module 1 for dependent requests)
2) is also provided with a pointer to the item stamp specification to be used. The optional data descriptor field 127 contains the data used in processing the request and contains 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 buffer and a length specifier to indicate the length of the buffer. In other embodiments of the invention, the request may also include a qualifier field as a separate parameter or as a separate element of the parameter fields described above.

The WITH qualifier can be associated with an entity field that filters the entity list created by wildcards, for example. For example, rBR
IDG"WITH STATUS='ON' AN
D FILTERING='0FFJ refers to each bridge class entity with its state flag set to ON and its filtering flag set to OFF {This example is AN
D.OR. Also illustrates the use of pool functions such as NOT and qualified XOH}. In the preferred embodiment, all modules and information managers implement the WITH clause at each level of the entity parameter (global entity, sub-entity, sub-sub entity) to implement the WITH qualifier. It is configured to check for its presence. Other qualifiers can be used as explicit parameters of the request. For example, a communications qualifier may set the response of a request to <f
Send to a file named i le name>
rFROM<fiIename> to search for the ``To<fiIle name>'' qualifier, other request parameters in the file named <fiIename>
>” qualifier, rVIAPATHJ @ which specifies a series of “hops J along a path that penetrates the hierarchy of management modules.
qualifiers (for example, useful in specifying a fine-grained management module between several devices performing an operation), and rVIA PORTJ qualifiers (for example, access - Useful for specifying that the module performs diagnostic tests using a particular Ethernet port). Similarly explicit parameter qualifiers can specify groups of entities.

rIN DOMAIN<domain name>
``qualifier filters the specification so that it applies only to members of the domain named <domain name>. Also, explicit parameter qualifiers can authenticate or qualify requesters of management services with limited access rights. rBY ACCOUNT,, rBY
PASSWORDJ, and rBY USERJ
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 the time at which a command should be executed. Generally this is done in the AT clause.

For the show instruction, the syntax of the AT clause is <AT-c I
aus e> : : =” AT” <t im
e-arg)[","<time-arg>]. Here, the time argument <time-arg> is, for example, the start time ('START=<time>''),
End time (rEND=<time>") or connection time (rDURATION=<time-1e
ngth>”), repetition period (rREPERT E
VERY[=]<time-1ength>") - Time accuracy (rcONF IDENCE[=]<tim
e−1ength>”), or the sampling rate (r
sAMPLE RATE[=ko<time-1eng
th>”). These arguments interact with each other to create a general schedule and scope of interest bound to the requirements. In particular, in one particular embodiment, three time arguments, START. END, and DURATI
ON is related so that two of these define the 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, a time qualifier of ^T OR BEFORE <time> can be interpreted to request time-slumped information at or before the time indicated by <tiffie>. When receiving such a qualified request, the arguments module constantly checks for actions that produce the requested information. For example, if information is generated due to the actions of other colleagues, this information is returned to the requester. Otherwise, the management module continues to check the information until time <tile>. Once the information is generated, it is returned to the requester. Otherwise, time (t
ime>, the management module forces the ball of information from the access module or entity and returns the information to the requester. To complement the AT OR BEFORE til'le qualifier, the NO one-time qualifier can also be implemented. At fljl, the funold 124 includes a handling pointer that points to a context data structure, which is a dedicated section of storage that stores processing context information. Handling includes, for example, "context information communication between the module and the information manager".
Used as a notepad.

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

For data returned to the user or management module,
The time stamp indicates the instant at which the event described by the data item occurred, the instant at which it is applied to the data value returned for the command, and the instant at which the requested action was actually performed.

For historical data stored in historical data files, a timestamp is the moment a given data item has a given value.For purposes of historical data files, the timestamp can be considered a key or index. Can be done. The time range of interest specification 123 can be used to request a search for a particular piece of information stored with a predetermined key or index.

2. Range of Interest A time range specification of interest is provided on request using the time specifier field 123. Using a time specifier,
Other values of data than the ``currently owned value'' can be displayed and processed, and statistics can be calculated over time periods. 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 SHOW instructions, time context can also be applied to HODIFY-type requests and actions.

The time ranges of interest are absolute instants, sequences of absolute instants, time intervals (start time rSTART J and duration rDU
R, ), a repetition of an instant, or a repetition of a time interval.

Both of these are relative periods (rEVERY .
) can be related to them. When a period is specified, the original moment, sequence of moments, or time interval is treated as a base, and the period is appended to this base. For example, time specification r5:oOEVEREY O:1
5, Ha, 5:00, 5:15, 5:30, 5:45
It is equivalent to... absolute time instant ( rUNTIL
J) can be specified to indicate when the iteration is to be terminated. For example, time specification r5: EVERE
YO15UNTIL6:00, is 5:00, 5:15
, 5:30, 5:45, 6:00. The repetition time interval can be specified in the same way, r
sTART5:00 DUR:05 EVERY1:O
OJ is time interval 5:00-5:05, 6:00-6:
It is equivalent to 05, 7:00 -7:05...

3. Scheduling Scheduling information may also be indicated by time designator field 123. A particular scheduling time can be expressed either as an absolute instant or as a series of 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 it down into DAY, TODAY ) ). There are some rules that apply to time intervals. The past time interval can have a starting point indicated by the keyword YESTERDAY, or by an absolute time in the past. Similarly, future time intervals are determined by the keyword TOHORROM. Or we can have a dead center indicated by a future absolute time. Also, the start time of a time interval must be earlier than its end time.

4. Time Context Handling As explained above, scheduling and scope of interest information can be supplemented by requests with associated context handling. Handlings are created by modules that execute requests and are subsequently used to communicate with service providers. When a call is received 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 multiple dependent requests, it is possible to create multiple handling and context blocks with a single request. Context blocks are the criteria used by service providers, whereas handling is the criteria used by service requesters. Each process in the request/dependent request chain (i.e.
A module (or information manager) only knows about context blocks and treatments related to its local part of the chain. Referring to FIG. 7B, in one particular embodiment, the time context treatment 172 created by the requester, e.g., presentation module 10, includes a range field 175 and a schedule field 176 that are related to the time lookup 123 of the initial request. It is equipped with 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 elision 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 (
R capability modules and access modules can also create and maintain context blocks on demand).

The handling status field 178 has one of three values: rFIRsT,, rHoru:,,
or rcANcEL, these are used as flags to indicate further actions to take. When i is created for the first time,
The handling status is set to rFIRsT.

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, a service provider, eg a functional module, information manager or access module, cannot satisfy the request with one answer. For example, a requester can specify a group of entities by
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 other cases, requests for a single entity may include time specifiers 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 require multiple responses include obtaining attribute data about an entity or entities, modifying attributes of some entities, and modifying the state of some entities.
It can be for any form of action, including When a service provider processes a request and finds that the request has a different 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 a pointer to a service provider's dispatch entry (see explanation below under the heading Dispatch Table), also points to a handling that is concerned with a dependent request for a functional module, for example. Associated proprietary variables generated on demand, such as context pointers1
This is accomplished by creating a context block 174, which may include 73.

The 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
r} to the value of 40REJ, and use the appropriate handling modification routine to signal that you have another reply. When the reply is returned to the requester, the requester looks at the rMOREJ 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 alternative replies, he must cancel the request (see below). If the requester wants a different reply, he must violate the request without changing the parameters. These repeat requests (rhoRE,
(with a handling status field 178 equal to ), the appropriate handling access routine is used to locate and detect the rHORE, status.

The service provider then knows that the call is part of a previously established request. (Note that a handling with a state of rFIRs'r, indicates to the service provider that the associated call is the first invocation of the request.) For each call with a handling state of rHORE, the service provider must set the handling context field It retrieves the context block 174 pointed to by 177 and continues its execution using the context block to provide another reply. There is only one reply for each call made to a service provider. As long as the service provider keeps the handling parameters in the r MORE J 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 range field 175 and schedule field 176 in the requestor's treatment).
Requester handling status field 178 is rFIRsT
It is set back to the value of J (initial setting B). When the return is sent to the requester with this final reply, the requester receives r
Look at its handling parameter status set in FJRST, 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 the state of the handling parameter that results in the r 140RE, state. The requester is treated according to its initialized rFIRs.
remains in state T, indicating to the requester that the request is complete.

Once the service provider returns the handling parameters in the rHORE, state, the request must be repeated or canceled. If the request were to be discarded instead, system resources would be lost due to handling and storage allocated to context blocks. Regarding the above explanation, note that if the service provider did not generate a dependent request, then the communication between the service requester and the provider is sufficient for single treatment. However, if a service provider originates a dependent request, two or more separate treatments may be used, one for the initial requester generated by the calling requester, and one for the initial requester generated by, e.g., an information manager, e.g. There will be another treatment that can be conveyed to

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 creates 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 set aside for the initial request. If there is more time to schedule the requested action, the information manager does not set the requester's handling status to rFIRsT, and rHOR
E, leave it as it is. The requester sees that its handling parameters are still in state r)40RE, 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 make this next call rFIRsT
Note that the context is not preserved after returning the handling state set to , so it cannot be distinguished from the invocation of a completely new request. Also, the requester does not distinguish between the handling status of rMORE, generated by the service provider waiting for more replies to the request, and the information manager preparing a new schedule moment.

In another embodiment, the handling access routine is enhanced to allow the requester to confirm the occurrence of the handling parameter rMORE, condition. During a request with multiple returns or multiple schedules, if the requester decides that he does not want any further responses to this request from the service provider, he must cancel the request. receiving an exception reply indicating that no further data is useful for possible reasons for attempting to cancel the request;
Or, you may receive an error condition indicating that a required action is not being 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 may occur when the service provider returns the handling parameter status of rMORE to the requester. The requester performs the cancellation using the appropriate handling modification routine that changes the handling parameter state to the value of rCANCELJ and reissues the call.

The requester must not change any other parameters to this call. When the service provider receives this call, rCAN instead of the expected rMORE, state
Look at the handling parameters in the state of CEL. The service provider receives the context from the handling parameters and uses the context to perform the necessary purification. This cleansing includes canceling any lower-level requests it is making, terminating all processing, and returning system resources. Once the service provider has completed its purification, the handling parameters should be adjusted using the appropriate handling modification routine.
, reinitialize and return to state. Then the service provider
A special Pl-value return code called CANCELED 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 IRSTJ. The request has already been completed and there is no service provider context to cancel it. Therefore, the cancel routine described above will not return an error unless the handling state is rMOREJ.

F. 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 figure. The dispatch tree and dispatch list essentially form the scrutiny table used in examining requests, as described below in connection with FIG. Referring to FIG. 8A, the dispatch tree includes multiple entity nodes 130. Entity nodes 130 are organized into a tree ellipse to aid in inspection, but they can be organized into a pond data structure. Entity nodes identify various entities within a complex system with which requests can be issued.

Entity nodes 130 each have a pointer to a dispatch entry 134 (FIG. 8B) of a dispatch list maintained in their dispatch 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, the data structure 130 satisfies the entity model because it has a hierarchical structure and its child structures that resemble it.
The term "entity node" used to describe data overlay 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 a stage within a class. Each entity may be at the level of a class, and the class is defined by the class name distinguished in the entity's entity specification 46 {Figure 3A}, and the class is
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 the various elements of the pond in distribution table 28. Modules that service requests related to several entities of the same class can be identified by fill cards or ellipses. If so, the associated entity node has a wildcard pointer in field 141 or an ellipsis pointer in field 142.2 Each wildcard pointer and ellipsis pointer is
It is constructed from tree link entries as described below. If the entry node pertains to a class with no levels, an example of which is described below in connection with FIG. - Equipped with a pointer. In fif&, field 131 comprises a code entry, which comprises a code identifying the class or name of the stage of the entity associated not only with the entity node but also with the link pointer.

The code entry field 131 shown in entity node 130 of FIG. 8A is one entry in the encoding 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 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
It is equipped with 52.

Class code/stage numeric field 151 of coded entry 131 comprises the class code or stage name. The contents of field 151 comprises a class code if the 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 the stage name 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. A dispatch list is a 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 the functional module 11 or access module 12, during whose registration a disk batch entry 134 is generated. Dispatch entry 134 includes a series of fields 162-164 that point to procedures, processes, and nodes within the complex for handling 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;
A set of attributes identified by the attributes defined by the attribute definition field 54 in 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 is used. With this background, the process followed by dispatcher 16 in examining and dispatching requests from presentation module 10 will be described in conjunction with FIG. dispatcher 2
It will be seen that 1 performs a similar process in conjunction with dependent requests from functional module 1l. Referring to FIG. 9, the request 180 is as follows. S H O W NODE <node nane > ROUTI
NG CI RC U I T (routing ci
cut nane ) CHARACTERISTI
CS This is used in conjunction with distributed digital data processing systems. Request 180 includes a number of compartments, including a verb compartment 181, ie SHOW, an entity compartment containing codes and stage names 182-186 for multiple entity classes, and an attributes compartment 187 consisting of multiple attributes. At this point, the verb SHOW begins generating a response from the named entity in the request that is related to the named property.

In request 180, the entity partition, i.e. element 18
2 to 186, comprises a large number of class/stage pairs. In particular, element 182, N O D E , belongs to the class
code, element 183, i.e. (node n
ane ) identifies a stage of entity class NODB by the stage name (node name >). identifies a node in a distributed digital data processing system. In a distributed digital data processing system, <n
ode nane > identifies a note within a distributed digital data processing system.

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

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 verb section 181 of the request is taken from the directive specified by directive specification 56, and the entity class name and subentity class names 182, 184, 185 are taken from the entity class code field 47. , the attribute section 187 is taken from the attribute definition 54 of the management specification for the entity.

The stage names of entities and subentities are taken from rank data known to the user (eg, by reference to an ellipse or database, or through an automatically generated menu). In response to receipt of the request, dispatcher 16 begins scouring the elements within the entity partition using entity node 130 (FIG. 8), 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, class code field 15 with the class code of
Find an entry in that encoding list 131 that contains an encoding entry with a 1. dispatcher 1
6 cannot find such an entry in the dispatch table 28, the dispatcher 16 looks for a wildcard or ellipsis pointer (see below) {if no wildcard or ellipsis pointer is found, the request is It responds with an error to the received module 10. } Once the dispatcher 16 locates such an entity node 130 in the daysbatch table 28, it proceeds to the next step of the probe operation (step 191), where the step (nod) specified in the entity element 183 is
Entity node 13 associated with e name )
Trying to find 0. 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 name and to point the encoded list to the entity in the request 180 for that stage name entry. Element 183 (
Locate entity nodes with class/stage flags 140 that have encoded entries corresponding to node nane >. Dispatcher 1 again
If 6 cannot locate such a node in the dispatch table 28, it looks for a wildcard or ellipsis pointer (see below). On the other hand, in step 191, the despatcher 16
Once we have located the entity node associated with element 183 in table 28, we proceed to the next step (step 192) where we identify the class code 184, ROUTING,
Attempts to locate the entity node associated with. In this operation, dispatcher 16 uses the pointer in field 152 of encoded entry 131 and the entity element ROUTING from the request to identify the entity node associated with the class code and add it to its encoded entry list. Locates an entity node 130 with a class/stage flag 140 that has a coded entry 131 with a class code field 151 with ROUTING. In this situation, the entity class ROU
Since TI NG is a stageless entity class, pointer field 152 of encoded entry 131 is null. In this case, the null pointer field 143 of entity node 130 is
Refers to a second entity node 130 associated with entity CIRCUIT.

In step 192, dispatcher l6 uses the null pointer of the entity node 130 associated with the ROUTI NG class entity determined in step 192 to determine that its class/stage flag 140 is associated with the class code. locating an encoding list comprising a second entity node 130 indicating a second entity node 130 and an encoding entry 131 whose class code field 151 comprises CIRCUIT (step 193);
. If the dispatcher cannot locate such an entity node, it looks for a wildcard 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
CUIT NAME>. With this operation, the data batcher 16 is set to the field 15 of the coded entry 131.
2 pointer to its class,/stage flag 1
40 identifies this as being associated with a stage name and its coded list indicates that its stage name field 151 is associated with request 18.
(ROUTING) specified by a stage entity of 0
CIRCUIT NAME>. dispatcher 1
If 6 cannot locate such an entry, it looks for a wildcard or ellipsis pointer (see below).

On the other hand, if the dispatcher 16 locates the stage entity node 130 that identifies the stage entity element 186 in step 194, the dispatcher 16
This means that the 80 entity divisions 182 to 186 have been successfully inspected.

The dispatcher 16 then uses the pointer in the field 152 of the encoded entry 131 located in step 194, the verb in the verb element 181, and the attributes in the 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.
Thereafter, the dispatcher 16 selects its verb field 1
65 corresponds to the verb element 181 of the request 180, in this case SHOW, and its attribute field 16
An attempt is made to locate the dispatch entry 134 whose content corresponds to the attribute of the characteristic element 187. 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 other than those associated with the dispatcher, the dispatcher will submit the request for processing, respectively. to the other process or node's dispatcher identified in fields 163 and 164 of the process.

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 may handle all requests for modules of a particular global or subordinate entity class. Without wildcards and ellipsis pointers, all class stages and subclass stages would be listed in the dispatch table. To avoid this, wildcards and ellipses are provided that can be specified in the Disbatch Specification 39A to indicate in a general way which entity classes or stages service the management module. An example of such a dispatch specification is NODDE ROUTING CIRCUIT, which specifies that a module is a global node of the NODE class.
All cases of an entity and all cases of a subentity class CIRCUIT indicate that all subentities of other CIRCUIT class subentities can also be handled. The asterisk (”) matches any stage name, and the ellipsis (
) matches any subentity stage ma or subentity class/stage pair that may follow. For example, the expression NODE foo ROUTING CIRCU
IT bar LINK fred conforms to the disbatch specifications. Because "8" is rfoo
” and r. ．． ．． , is rbar LINK
This is because "fred"i'a match. Referring to FIG. 9B, the wildcard information in dispatch table 28
To enter the dispatch specification, step 191 (Figure 9A)
The entity node 130 corresponding to the stage name of the NODE class entity will be modified.
Wildcard pointer 141 is changed to point to new entity nodes 130 containing class codes, one of which is class code ROUTING (step 196). Class code ROUTING
The child pointer related to becomes null (step 192 (9th
(similar to Figure A), the null pointer is the class name CIR
Points to the new entity node 130 in the pond that will have a child pointer corresponding to CUIT (step 197
). This child pointer will point to another new entity node 130 (step 198) and its ellipsis pointer will point to a 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 looks for a stage in the NODB class with the name, eg, "rfoQ." If this name is found in a coded entry (three are shown for illustration purposes), the dispatcher follows the coded entry's child pointer. However, if the name "rfoo" 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. After locating the wildcard pointer, the dispatcher proceeds to step 196.

Steps 196 and 197 are the same as steps 192 and 193 in FIG. 9A. The dispatcher returns a null value (corresponding to class code rROtJTING,) in step 196.
The pointer is used to move to step 197 and the child pointer corresponding to the class code rCIRCUIT is used to move to step 198.

In step 198, the dispatcher searches the linked list of coded entries (three shown for illustration purposes) and searches for '
Find out the stage name "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 the dispatch entry are used to call the appropriate module.

Wildcards and ellipsis pointers allow general matching of entity class codes and stage names, or only after the encoding entries in the dispatch table have been checked. In this way, the dispatcher looks for the "best match" for the entity name. So, for example, the first module is dispatch specification NODE * ROUTING CTRC
It can be equipped with a UIT. This means that the module is No.
DB class global entity stage rJoe
” indicates that all stages of all CIRCUIT class subentities of the ROUTING class subentity can be handled. The second module is a dispatch specification NODE Joe ROUTING CIRCU
IT... can be provided. This indicates that the module can handle all stages of all CIRCUIT class sub-entities of the ROUTING class sub-entity for the stage rJoej of the NODE class global entity. In order to be consistent with the "clearest match" rule, NO
DE Joe ROUTrNG CrRC U
All commands for the IT subentity should be sent to the second module. This is accomplished using a dispatch table mechanism.

Because the stage name "rjoe" appears in the encoding entry in step 191, "rjoe" is ROUTING
If it is a stage name in a request to CIRCUIT, r
joe' encoding entry will be used (because 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 a dispatch specification NODE jim DISKDRIVE... This indicates that the module can handle all stages of the sub-entities of the DISDRIVE class for the global entity stage 'jim' of the NODE class. This specification is entered into the tree in step 191 in a manner similar to Figure 9B by appending the stage name 'j im,1 to the encoding entry followed by appending the new entity code. Following this, dispatching a request using the global entity class and stage name NODE Jim will cause the dispatcher to transition to the new entity node.

However, NODE jim ROUTING CIRCU
Requests with entity names starting with IT will require the new module to be DISKDRIV for the NUDE stage 'jim'.
It cannot receive services from the new module because the subentities of the B class do not support it. Therefore, the dispatcher uses the class name ROUTING C
Once it is determined that IRCUIT is not supported by the new module, return to step 191 and optionally use other encoding entries or wildcards or ellipsis pointers to set rNODE jim ROUTING.
A v1 side must be provided to find the module that services the CIRCUITJ request. Therefore, as the dispatcher traverses the dispatcher table,
The dispatcher maintains a stack of pointers for all entity nodes 130 that have been traversed from the root node. As the pointer moves up and down 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 from the presentation module directly to the access module. To achieve such pass-through, the presentation of a disbatch table (which matches the name of any entity in any request),
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 function access aspect of the dispatcher. In this manner, all requests that do not conform to the dispatch specifications in the Presentation and Capability Dispatch Table are communicated to the Capability and Access Dispatch Table for compliance. This allows the presentation module's requests to access the primitive functionality available from the access 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. can have the first element of . 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 the filled cards. G. Domains and Topics As mentioned above, configuration function module 11 maintains a configuration database that defines the entities that make up the complex system. With appropriate commands from the operator, the configuration module l1 can add entity stages defined by the data dictionary to the configuration database, delete them from the configuration database, and modify specifications in the configuration database. . As noted above, the domain functionality module 11 establishes domain entities in the configuration database that reference subsets 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. Alternatively, the operator can perform control functions relating only to the entities within the domain without initiating the generation of requests by the presentation module 10 for each entity.
or start monitoring operations, thereby simplifying the control and monitoring of complex systems. The domain functionality module establishes a domain database for each domain entity that identifies the entities that make up the domain entity within the horizontal command database or in addition to the configuration database. Upon receiving the appropriate request, the head area function module 11 adds the entity to the area database;
This adds entities to the realm, removes entities from the realm database, generates a response that identifies entities that remove entities from the realm, controls the realm defined in the realm database, and deletes the realm database. , which effectively deletes the region. 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 realm database includes an entry 230 for each member of the realm, listing the realm name and stage name for each member of the entry or subentity. Additionally, the domain database includes an entry 232 for each entity that is a member of the domain, listing each stage name and the domain of which it is a member. The M-area functional module updates this information as the area is modified and utilizes this information to quickly determine the members of the area;
Or alternatively, an entity's domain membership can be quickly determined.

In another example, the lth region can incorporate members of the second region by referencing the second region;
In this way, the size of the region 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 function module to quickly determine which precepts to display (via the presentation module) to the user, for example, a map of precepts or a menu of entity stage names.

H. As described above in conjunction with FIG. 1, one functional module 11 includes an alarm functional module 11;
It determines the alarm condition in response to a request from the presentation module 10 and uses various conditions recorded in, for example, two user interface information files of the entities of the complex system to trigger the occurrence of the alarm condition. can be detected.

Figure 10A shows the functional organization of the alarm function module 1l. Referring to FIG. 10A, the alarm function module 11:
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
The 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 corresponding requests from the presentation module 10, so that the alert condition represented by the rule exists. The conditions are corrected. Similarly, the act of detecting alarm conditions is performed by the detector module 201, which includes, for example, the condition information located in the historical data file (FIG. 5) and the alarm rules located in the alarm rules base 203. As described below in connection with FIG. 10B, each rule includes a condition portion that identifies a condition. - Determine whether the content of the file complies with the conditions of various rules. If so, the detector module 201 generates an alarm instruction, and the general alarm module 200 sends it via the notification module 204. , for example, to the presentation module 10 and displayed to the operator. The general form of an alarm rule generated by the rule maintenance module 202 is shown in FIG. 10B. Referring to FIG. This indicates a set of conditions necessary for issuing an alarm.The condition part is the expression part 212
, a relational operator 213, and an expression numerical part 214. The relational operator 213 converts the formula part 212 into the formula number M part 2
14, the condition part 210 is logically TRUE.
(TRUE) logically evaluates to FALSE (FALSE). When the expression part 212 itself evaluates to logically TRUE or logically false, the relational operator 213 and the conditional part 2
It can be seen that the 1ii part 214 of Equation 10 is unnecessary. In either case, if the section ``g'' evaluates to a logical TRUE, then an alarm condition exists.

The rule has 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 numerical part 214. The time value portion 216 establishes the time function and the condition portion 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 as needed.
Because V-report conditions do not need to be predetermined within the control device, the V-IJ device 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 describe a system that controls and manages a group of entities, in which entities interface with the group to control major information processing functions, and entities further interface with the system to perform management functions. Make it possible 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 display 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, in which entities interface with the group to control major information processing functions, and entities further interface with the system to perform management functions. be able to do so.

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 disbatch pointers that direct instructions to.

A system for controlling and performing management functions over a group of entities will be further described; this system includes a storage management module configured to independently translate and execute predetermined management-related instructions; The kernel stores a table of batch pointers that translate and direct instructions to the respective modules to be executed, and the register registers new management modules with the system by adding another pointer to the table. used. Alternatives to such systems may include a management module adapted to request one or more status information from an entity, modify management parameters of the entity, or enable a self-testing mode of the entity. Storage management specification information 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. Management specification information can also 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 the common disaster statement. The polling information may include fields that specify 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 partition information represents a group of attributes having a common data format. The management specification information may include set information in a predetermined field of the common text, and the set information represents a group of attributes having related functions in the management of an entity. The management specification information can include command information in a predetermined field of a common syntax, and the command information includes the management function that the entity is supposed to perform, the structure of the command to be issued to the entity, and the response to be received. Listed. The structure of the request to be issued can also include fields that list arguments to the command. The structure of the reply to be received may also include fields used to indicate successful completion of the requested action. Additionally, an alternative is described in which the structure of the reply to be received can include fields used to indicate error conditions that 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 conforms to the Ethernet standard, or the protocol conforms to the DECnet P
The protocol conforms to the DBCnet Phase V standard. Another alternative is described in which each instruction has a field listing at least one related entity and operation. The kernel has a dispatcher that receives and passes instructions based at least on the entities and operations listed therein. dispatch·
The table of pointers can be provided with an indication graph of data overlay, continuous data ellipsis with a graph corresponding to the field of the instruction. The dispatcher is equipped with a scrutinizer that traverses the instruction graph according to the entities and operations listed in 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 can be provided with an ellipsis flag, and continuous data interpolation can be provided, or the scrutinizer can determine the most A best-fitting unit can be provided to determine the exact fit. An alternative to such systems is to find the
! k is also equipped with a probe with a best fit unit to determine the exact fit. 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 can have a data structure,
The scrutinizer includes 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, then a wildcard match to the field, and then an ellipsis match to the field. There is. 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 convey information to a presentation device, and the presentation module includes conversion code that converts information received from an entity into a predetermined format for the presentation device, and a transfer code that conveys instructions from the presentation device to the desbatcher. The presentation module may include user interface information that defines the manner in which a user interacts with the system. User interface information can include assistance information that provides users with information about how to use the system. User interface information can include graphics mode information that determines the contents of pop-up menus and command line scrutiny tables. The kernel may further include a class database specifying the different management information available from each entity. The presentation module may include 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 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 performs management functions for members of a computer network, in which members interface within the network to control major information processing functions, and members further interface with the system. to perform management functions. 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 has 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 designed to register a new management module 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 indication of an associated time. The instructions specify a time range, and the information manager satisfies the instructions by retrieving administrative information contained in the records, if possible, and in other cases, by retrieving the specified time range from members of the network. means for satisfying the instructions by accessing information related to the instructions. 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. It is equipped with an alarm condition detector. The first category of management modules comprises m-function modules adapted to perform a-manipulation of data presented 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. The presentation module uses the primary information processing capabilities of the members of the network to receive instructions from the user and convey information to the user. The storage device further includes region specification information that defines 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; at least one management module can further self-manage itself by independently translating and executing self-management commands. It is designed to perform self-management functions for The information manager further includes a scheduler that responds to commands specifying time schedules. A scheduler is used to possibly enable successive dependent accesses or retrievals in response to instructions, possibly 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 in which entities also perform management functions. It can be so. 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 collective to control primary information processing functions, and an entity can further interface with a system to perform management functions, and a system has multiple management modules and commands. It has 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 relate to instructions translated and executed by the module, are also discussed.

[Brief explanation of drawings]

FIG. IA is a functional block diagram of a control device constructed according to the present invention. FIG. IB is a block diagram of information stored in the storage elements of FIG. IA. FIG. 2A is a functional block diagram of a part of the control device shown in FIG. IA, particularly a portion defining entities that constitute the control device. Figure 2B shows the features of the management module. 3A to 3D define management specifications that define control charts provided by the functional modules and access modules that constitute the control device shown in FIG. 1A, and FIG. Defines the dispatch specifications for access 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 mtt block diagrams showing various modules and data structures of the control device shown in FIG. IA. FIG. 7A shows the parameters used for requests generated by the presentation and functional modules of the controller shown in FIG. IA. Figure 7B shows the temporal context handling and structure of the context block used by the requirements of Figure 7A. 8A and 8B illustrate dispatch tables used by the dispatcher shown in FIGS. 5 and 6 in connection with processing requests from the presentation and functional modules of the controller shown in FIG. Show the data structure. Figures 9A and 9B illustrate the operation of a dispatcher in conjunction with its associated dispatch table in processing requests from presentation or functional modules. Figure 9C shows the format of the configuration database and area 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 11... Function module 12... Access module 15... Information manager 17.22... Data storage device

Claims (1)

[Claims] 1. A system that controls a group of entities and performs an entity management function, and also controls itself and performs a self-management function, wherein the entity a system for interfacing to control primary information processing functions and for enabling said entity to further interface with said system to perform said management functions; at least one storage management module adapted to perform functions and further adapted to perform said self-management functions on itself by translating and executing other instructions; A system consisting of a kernel consisting of a table of dispatch pointers pointing to each management module to translate and execute management instructions. 2. A system that controls a group of entities, performs an entity management function, and also controls itself and performs the self-management function, independently translating and executing predetermined commands. at least one storage management module adapted to perform entity management functions for itself by translating and executing other instructions; and at least one storage management module adapted to perform entity management functions for itself by translating and executing other instructions; A system consisting of a kernel consisting of a table of instructions and a table of dispatch pointers that direct the self-managing instructions to the respective modules that are to be translated and executed. 3. A system that provides control over members of a computer network and performs network management functions, and also provides control and performs self-management functions on itself, wherein said members interface with said network and perform network management functions. In a system that controls information processing functions and allows said members to further interface with said system to perform said management functions, said network management functions are performed by independently translating and executing predetermined instructions. a storage management module configured to perform the self-management function on itself by similarly translating and executing other instructions; a kernel consisting of a table of dispatch pointers pointing to each module that translates and executes management instructions, the entity management instructions listing the identity of the associated entity and the action to be taken according to a common instruction syntax; , each self-management instruction listing the identity of an associated module and actions to be performed according to the common instruction syntax, and wherein the kernel is based at least in part on the actions and entities or modules listed therein. A system that has a dispatcher that receives and passes orders. 4. A method for controlling a group of entities to perform an entity management function, and controlling a system that exerts control over the group to perform a self-management function, wherein the entity interface with the system to control primary information processing functions and enable said entity to further interface with said system to perform said management functions, by independently translating and executing predetermined instructions; providing a management module adapted to perform said entity management functions and further adapted to perform self-management functions for itself by similarly translating and executing other instructions; and said entity management instructions. and providing a kernel consisting of a table of dispatch pointers pointing to each module that is to translate and execute self-managing instructions.