JPH02236767A - Area management in entity management system - Google Patents

Abstract

PURPOSE: To control the group of entities and to execute a management function by providing an access module processing and displaying a request from an operator through more than one indication module, function module and kernel means. CONSTITUTION: A controller is provided with various control modules of indication modules 10A-10K, function modules 11A-11M and access modules 12A-12M. The indication modules 10 becomes user interfaces for controlling a composite system and the respective function modules 11 execute management control and monitoring in connection to the function of one class. The respective access modules 12 manage/control the entity in a specified system, which can be controlled. Then, addition/subtraction are dynamically executed by the control modules 10-12 so that management with adaptability and extendibility can be executed. Thus, the controller can be adapted to the change of the topology of the composite system.

Description

DETAILED DESCRIPTION OF THE INVENTION FIELD OF INDUSTRIAL APPLICATION This invention relates generally to the field of complex system management, and more particularly to apparatus for managing complex systems such as distributed digital data processing systems. BACKGROUND OF THE INVENTION As digital data processing systems, or computers, become smaller and less expensive, individual computers are used by individuals and small groups. In order to increase the economy associated with resources that are not used for Including servers that store large amounts of data and thereby facilitate the distribution of the data, have become integrated into networks that communicate by means of messages conveyed through communications links.Servers include printers, telecommunications links, etc. In addition, servers can perform specialized computational services such as database searching, classification, etc. Various computers, referred to as contributors, and servers can communicate with each other through communication links. The present invention relates to a distribution system in which a plurality of computers communicate through a local area network, for example, to enable messages to be transferred between various computers and servers that make up a distribution system. The present invention provides a new and improved controller for controlling and monitoring complex systems, such as digital data processing systems. handles requests that occur in response to instructions from operators through modules and kernel means;
It includes an access module that responds and displays to an operator. The presentation module handles operator interface functions, including receiving commands from the operator and presenting responses thereto. The presentation module generates requests in response to commands from the operator. The kernel means receives the request and communicates it to the functional modules for further processing. Functional modules handle general functional operations in connection with processing requests. In response to a request, a functional module generates one or more requests (sometimes referred to hereinafter as dependent requests for convenience), which are forwarded to kernel means for processing or to a pond functional module. Ru. The kernel means communicates received dependent requests to the access module for processing. The access module handles primitive operations in relation to the entities that make up the complex system. Generally, the present invention is a system that controls and performs management functions for a group of entities, wherein the entity interfaces with the group to manage main information processing functions, and the entity further interfaces with the system to perform management functions. It features a system that allows you to do this. The system includes a storage management module that performs management functions by independently translating and executing predetermined management-related instructions, a storage device that includes area specification information that defines groups of entities, and individual It has a kernel that is adapted to issue commands to all entities of a group by issuing commands to the appropriate management module. Domain specification information is compatible with a universal specification language with a common syntax for representing any arbitrary group of entities.
The common syntax provides for incorporating entities from a first domain into a second domain by referencing the first domain. The common syntax provides for creating subdomains of entities that are entirely within the domain of the pond. At least one management module includes a region management module that establishes and maintains region specification information. The region management module responds to commands to add or remove entities from groups, create groups, or delete groups one or more times. The domain manager is responsive to instructions with a filtering procedure that selects one or more particular domain entities. The filtration procedure can select subregion entities that are completely within the pond region. 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 provides means for satisfying the instructions, if possible, by retrieving administrative information contained in the record, or in the case of the network, by accessing information related to the specified time range from members of the network. It is equipped with an information management device equipped with 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 accordance with 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 adapted to implement protocols for communicating members of the network. There is a presentation module that uses the network's primary information processing capabilities to receive instructions from and convey information to the user. The presentation module includes a menu generation routine that extracts data from the class database and generates a menu of valid instructions to display to the user. The menu generation routine is adapted to determine information related to the configuration of the network and generate a menu of available members of the network, and the at least one management module further independently translates and executes self-management instructions. By doing so, they are able to perform self-management functions for themselves. The kernel also includes a table of dispatch pointers that translate and direct instructions to the respective modules to be executed.

There is a register that registers new management modules into the system by adding another pointer to the table. The information manager further includes a scheduler responsive to commands specifying a time schedule, the scheduler possibly enabling a series of dependent accesses or searches in response to commands, 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.) An example of a complex system controlled by the apparatus shown preliminarily in FIG. Consisting of multiple nodes containing constituent elements,
It is equipped with a distributed digital data processing system. An example of such a digital data processing system is described in a US patent application. It will be appreciated, however, that the controller shown in Figure 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 top 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 contains all of the local area network bridges for 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),
Function module IIA to 11M (generally reference numeral 1
1), and access modules 12A to 12M (generally identified by the reference numeral 12). Presentation module 1o
Typically provides a user interface for a user to control a complex system, including control of terminals used by system operators. Each functional module 11 typically performs administrative control and monitoring associated with one class of functionality. 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 i9Jllable entities. The presentation module 1o communicates with the functional module 11 through the presentation/functional aspects of the kernels 13, 14 (hereinafter simply referred to as the presentation/functional kernel 13), and the functional module 1l communicates with the functional module 11 through the functional/access aspects of the kernels 13, 14 (hereinafter simply referred to as the presentation/functional kernel 13). The capabilities required from the control modules 10, 11, 12 can vary widely depending on the topology of the complex system being managed. Dynamically add and subtract all 10, 11, and 12 to the device,
Equipment can be adapted to the topology of a particular complex system and to changes in that topology. For further adaptability and extensibility purposes, i1iIJv
The R modules 10, 11, 12 form a "labor group" for the tasks to be performed in the management of the complex system.
In this way, for example, duties associated with the management protocols of a distributed data processing system can be separated from duties associated with, for example, displaying management information to a user. A. Presentation module More specifically, the presentation module 1o performs a presentation service, which includes, for example, the system
Operator accesses various function modules 11 and
A user interface, such as a video display terminal, personal computer, or computer workstation, that controls module 12 and that can be used to control and monitor various entities within the complex system.
It can be configured from an interface support device. The presentation service is required independently of the management function or entity managed by the system shown in Figure IA, and is therefore provided without regard to 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 support devices for displaying and reviewing command lines. Other presentation modules 10 provide specific output support for various types of graphical displays, such as histograms, bar diagrams, pie diagrams, or other forms of pictorial representations to be displayed on the terminal screen to the operator. ．． Still other presentation modules 10 provide management requests for presentation and functionality that may be annotated by portraits, menus, graphics, or commands entered by the operator on the command line.
3 and the management information from the presentation and functionality kernel 13 is transferred for display to a video display terminal used by the operator.

B. Functional Modules Functional modules 11 are associated with and support specific management applications carried out by the control device shown in Figure IA. Management aggregation refers to the presentation services performed by the presentation module 10 (other than to the extent that the presentation module 10 informs the operator about the management applications performed by the control management) and the specific services that constitute the complex system managed by the control management. Exists independently of entities.

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 baguette size and communication resource utilization of the delivery 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 the complex system in the form of data matching or correlation services.

In addition, functional modules utilize data generated 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 the topology to the operator through the presentation module 10. The functional module 11 of the network defines, for example, the configuration of a distributed digital data processing system, i.e., the various stages of entities and their interrelationships, and allows nodes and other entity stages to be added or subtracted from the network, allowing operators to A configuration system that allows an operator to control the configuration of a network, change access rights for various users of a node, and maintains a configuration (or stage) database that allows an operator to decide on changes to the configuration of a network at any time. It can be equipped with functional modules. Other functional modules 11 within the control device can, for example, control various alarms indicating that a predetermined event has occurred in the distributed digital data processing system. The alarm function module 11 monitors the status and conditions of various entities of the distributed digital data processing system and generates alarm actions to the operator, while an appropriate presentation module 10 responds to the status or condition having a predetermined value. and advise the operator. Still other functional modules 11 may, for example, define the domain of an entity within a distributed digital data processing system and limit or facilitate control or monitoring by an operator. The pond functional module 11 operates, for example, as a historical data recorder functional module 11;
You can periodically ball the various entities in a complex system to determine their values at specific times, establishing and maintaining time and numerical databases, and facilitating 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 functional module 11 supporting the management application may require the services and operations of a number of access modules 12 in a particular order. Adjust the sequence of movements. Additionally, the management application provided by one functional module 11 may require the application of another functional module 11 in the control device, whereby that one functional module is also adjusted. 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 function module 11 is also called by requests directly received from other function modules 11. Additionally, the functional module 11 can generate requests for processing by the 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 various hardware of the system, including the various computers, disk and tape storage devices, routers, etc. that can constitute the nodes of the distributed digital data processing system. In addition to the components, it may also include software components including virtual circuits, databases, etc. The access module 12 is called by the functional access kernel 14 in response to requests from the functional modules 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. can. One access module 12 can, for example, control and monitor the status of various parts of a bridge connecting two local area networks, and can send messages between two local area networks.
Enables communication between nodes in an area network. Such an access module 12 is
For example, you can initialize the bridge, enable it to start working, disable the bridge, monitor its end-to-end operation, see how many messages are passing through the buffers it has, and You can check whether you have enough buffers to operate effectively. Other access modules 12 provide various information indicating the operation of the message generation and decoding portions of the various nodes of the distributed digital data processing system, the virtual circuits, the established sessions and links between the nodes, and the activity and inactivity associated therewith. Timers, counters, etc. can be controlled and monitored. Similarly, other access modules 12 control and monitor network layer portion operations of the node that control the actual transmission and receipt of messages through the network, including various message transmission receipt counters, transmission receipt timers, etc. be able to. In addition to monitoring the values of various timers and counters, one node can maintain and establish other default and operating parameters using the access module 12 that controls both timers and counters. Limits on the number of concurrent virtual circuits and sessions can also be established. In certain embodiments, the access module provides access connectivity testing to management functions at an Ethernet LAN bridge or an IEEE 802 functional Ethernet station, a boat fraction control and checking function at an Ethernet repeater, or a management function at an FDDI entity. In addition, the access module is the DECnet Phas, published by Digital Equipment Corporation of Maynard, Massachusetts.
It can be provided to access management support equipment at eIV or Phas eV nodes, or DEC terminal servers. D. Request control modules 10, 11, 12 interact with each other and with users through requests. There are two general forms of requests. A request can, for example, cause something to occur within a complex system. That is, the condition or condition 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 transmit the visibility information to the functional access kernel 14.
Return to . In case a, information stored in the controller (such as by a historical data recorder functional module) may be used to satisfy the request. Additionally, requests may be of both types. That is, a request can change the state or condition of one or more entities, and can also request information about the changed state or condition of the entity. In processing such a request, the access module 12 causes changes, if possible, and also returns information regarding the state or condition of the entity to the pool of state information regarding the state of the request. 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 transmits it to the presentation/function 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 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 data storage overview 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 Device The data storage device 17.22 may include one or more RAMs containing dispatcher data structures, or one or more fixed disk drives, or other storage means, depending on the type and amount of data to be stored. can be prepared. 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. IB, 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 function module 11, predetermined information regarding the status and conditions of the historical data recorder function module 11 is maintained. This is stored in the history 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 the user's control. Alternatively, region information can be stored as an element in the configuration database. Similarly, the alarm module can use the alarm rule base 24 to ascertain alarm conditions within the complex system. Possible information relating to individual modules within the control device may also be maintained in the storage elements 17, 22. For example, as detailed below, dispatcher 16, 21
The dispatch table 28 used by is the number 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, the information manager 15 receives requests from the presentation module 10 to which it can respond using information in the data storage element 17, as will be described 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 the request to the operator who generated it. 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. Based on 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, hereafter 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;
This is transmitted to the dispatcher 16. Dispatcher 16 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.
, dispatcher 21, and data storage element 22
It is equipped with Dependency requests from functional modules 11 directed to functional access kernel 14 are first received by information manager 20 . Data storage element 22
Also, information regarding the state of the complex system at each point in time generated from the historical data recorder function module 11,
In particular, predetermined information regarding the status and conditions of the various entities controlled by the access module 10 may be provided. When information manager 20 receives a dependent request from functional module 11 to which it can respond using information in data storage element 22, the manager intercepts the request and generates a response to the occurrence of the dependent request. and transmits this to the functional module 11 that is the source of the dependent request. If the information manager 2o does not respond to a dependent request from the functional module 11, it determines whether the request pertains to the current time or to a future time. That is, the 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 immediately or at a scheduled time, the information manager 20 forwards the dependent request to the dispatcher 21.
In response to receiving the dependent request from the information manager 20, the dispatcher 21 identifies the access module 12 to which the dependent request should be communicated and forwards the dependent request to this access module.
Transfer to module 12. In response to receiving a dependent request from distributor 21, access module 12 begins processing the request. Access module 12, in response to the dependent request,
One or more actions associated with the entity of the controlled complex system can be initiated. If the dependent request requests access module 12 to change the state or condition of the entity, access module 1
2 attempts to do so and generates a response containing status information indicating the status of the attempt, ie, for example, whether the modification was successful, unsuccessful, or partially successful. On the other hand, the dependent request is access module 1
2 to identify the state or condition of the entity, the access module 12 generates a response indicating the state or condition of the entity. Finally, if the dependent request requests access module 12 to do both of the above, access module 12 attempts to change the state or condition of the entity and updates the state of the attempt and the new state or condition of the entity. It also generates a response that indicates . 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 functional module 11 is a dispatcher 1
6 or to dependent requests from other functional modules 11, as applicable. When functional module 11 receives a dependent request from pond functional module 11, it processes it in the same manner as it processes a request from desbatcher 21.

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, the information manager 15.20 can, based on the contents of the associated data storage device 17.22, without the need for further processing to other elements further down the chain.
If the request can be processed, the information manager 15.20
does so. Furthermore, since the controller is expandable, additional presentation modules, input modules 11, and access modules 12 can be easily added without changing the structure of the controller, as described below. be able to. S
The addition of the functionality module 11 and the access module 12 is done by way of a registration procedure, which will be explained below in conjunction with FIG. Module 10.11
The addition or deletion of or 12 includes certain data structures of data storage elements 17.22, as described below.
and other data structures maintained by the presentation module 10, as shown in FIG. Additionally, the modular and expandable nature of the control device makes it easier to manage the control device itself. 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 aid 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 control device, including its various elements, is a distributed digital
It can include multiple routines that are processed by various nodes and computers that make up the data processing system. That is, the computer equipment does not need to handle the modules that make up the controlled distributed digital data processing system and the controller that controls the distributed digital data processing system. Traditional procedure call Ia structures, interprocess communication mechanisms, and internode communication mechanisms are used to communicate communications, including requests, dependent requests, and responses, to different parts of the same process, to different processes on the same node, and to different Transfers can be made between each part of the control unit that may be present in the node. If the modules exist in different processes on the same node or on different nodes, the
Each inter-process and inter-node communication t described below
i-structures are used to transfer requests and dependent requests as well as responses between various processes and nodes. 1. Entity Model Before proceeding further, it may be helpful to further explain the relationship between the controller shown in FIG. 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 function module 11, and an accelerator module 12, together with a kernel 13.14.
A complex system includes one or more entities 36. Each entity 36 includes a service element 31, a management interface 30 and a service interface 3.
It has 3. The management interface controls and monitors service elements through agents 34. A service element is the actually managed 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, the service element 31 communicates, through the management interface 30 and the service interface 33, with the controller and in particular with the accelerator module 12.
It is managed through communicating agents. Communication through the management interface 3o facilitates the opening/closing of the service element 31 and its initial setting, and also allows the commander 35 to check the operating 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 for 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. The management characteristic of an entity lies in the commands it supports and its attributes, which are parameters broadly related to its functions and control as well as commands. For example, in the case of a router where the entity communicates data packets through a distributed digital data processing network, the attributes of the router may include the number of packets transmitted and the number of bytes transmitted. If the entity is a modem, the attributes may include counters and status registers related to modem operation. Examples of directives include SH to retrieve attribute values.
There is an OW, and a SET that modifies attribute values. Service interfaces are concerned with the functionality of the entity, and management interfaces are concerned with the behavior of the agent. The commands and attributes accessed through the service interface characterize the functionality of the entity, while the commands and attributes accessed through the management interface characterize the control and monitoring of the entity.

To clarify the role of the two interfaces and to provide an example of how to apply the above model to a specific entity, consider a controllable entity, a modem. Modems can be equipped with several functional attributes, such as baud rate, line selection, and power switch settings. In addition, the modem may be equipped 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 immediate operation of the modem and can be accessed through the service interface on its own. 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.
TION, 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. ``Plug in any entity and use the IIJ control device in Figure IA to {1) describe it consistent with the entity model, (2) realize an appropriate access module,
(3) It can be managed by inserting (registering) the access module into the control device.

J. As noted above in the management module management section, the control device that controls the distributed digital data processing system includes various presentation modules 101m, function module 11, and access module 12.
, and kernels 13.14 are processed by the various nodes that make up the distributed digital data processing system.
In that case, various modules 10.11 and 12,
and kernels 13.14 form entities within the complex system and are controlled in the same way as the pond 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 management module itself. As can be seen from the dispatcher specification below, in addition to the management routines that manage the complex system, each module has self-management routines that manipulate the module's internal attributes. Both internal and external routines can be accessed by requests using 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, structure of management module 1. l[Referring to FIG. 2B, in one particular embodiment,
The management module structure includes executable code 38 that implements the management functions 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 functional modules, the executable code includes support for computing the higher level functionality provided by the module. In the case of a presentation module, the executable code comprises an interface protocol to the presentation device supported by the presentation module. Modules can require private storage to store various read-only and read/write variables related to the functionality of the module. This storage device is provided in the module as an allocated area 32. This storage can be used, for example, by the presentation module to store 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 FIG. 2B, the disbatch pointer 39A is related to a procedure within a module that provides management services for the complex system, while the disbatch pointer 39B is related to a module that provides management services for the module itself. It is related to the procedure within. As explained above, when a module is registered with a controller, two sets of pointers are loaded into kernel storage for use in managing the complex or module that includes the controller. In addition to the above structure, modules are also associated with a management specification 48 that describes the classes of entities and attributes serviced by the module, as well as commands and responses that request services from 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 Specifications The nature, configuration, and structure of the service elements 31 and service interfaces 33 of various entities including the control device as well as entities of the complex system managed by the control device (FIG. 1) are determined by the management specifications and dispatch specifications. stipulated. 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. f & first third
Referring to Figure A, the entity management specification includes a heading portion 40 and a body portion 45. Heading part 40
is a name field with a name that identifies the entity, a variant field with an identification of the variant, and location information that indicates the location of the entity within the complex (for example, if the complex is a distributed digital data processing system) , an equipment field 43 with an identification of a node), and a format declaration field 44 indicating predetermined data format information. In an alternative embodiment, the heading section 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 the 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 body part 45 of the specification comprises one of two types of entity definitions: a definition 45A for global entities, or a definition 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 manufactured by Digital Equipment, Inc. of Maynard, Massachusetts.
net Phase IV, DBCnet
In Phase ■, the adjacent node is a subordinate entity class, and its superior entity is the 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 definition 46 comprises a name field 47 comprising a name and a code by which the entity can be identified. Additionally, the name field 47 identifies the entity as a global or subordinate entity and identifies the entity's class name. If the entity definition is for a subordinate entity, it is provided with an upper field 50 that identifies an upper entity in the hierarchy.
The identifier field 51 is later converted to the entity body portion 53.
It has a list of attribute names for the attributes defined in . After I&, 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 can have the value TRUE or FALSE and indicates whether the entity's management specifications should be stored in the configuration database (Figure IB).

This gives the management module developer a way to precisely indicate which dependent entity stages should be stored in the configuration database. In this way, there is no need to store highly dynamic entities such as connections between nodes in the system's configuration. This eliminates the overhead caused by iteratively adding and removing dynamic steps.
The pool value of the DYNAMIC field is
Indicates whether the nature of the class is dynamic; if TRUE, the stage of the entity class is not stored in the configuration. 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. Body portion 53 is defined in detail in Figure 3B. Referring to FIG. 3B, the main tree part 53 of the management specification has four parts, namely, an attribute partition specification restructuring 4, a set specification restructuring 5, a command specification restructuring 6, and when an entity class contains subordinate entities. It is equipped with dependent entity restructuring 7. Main tree part 5
3 has a dependent entity restorer 7, each item in the dependent entity restorer 7 is rsUBO
It consists of an entity specification 46 (Figure 3A) having a name field 47 containing RD I NATEJ. As mentioned above, the entity itself has 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 partitioned lists 45 are independent of those indicated by aggregated lists, each list being an independent pinpointing of an entity's attributes.

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 part after "partition" is used to indicate that the group formed by the attribute partition is the true partition of the attribute. An attribute cannot be a member of two partitions; each attribute must be a member of exactly one partition. The set restorer 5 identifies and groups all attributes that have the same function. For example, an access module for the Node4 global entity class may specify an attribute set that reads 'SQUAREJ. The SQUARE attribute set shall contain all attributes related to the current performance of the Node 4 class 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. Can be done. In this example, the user would thus be able to select SHOW NODE <instance> ALL
Commands like SQUARE allow you to view these statistics together. 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 to be members of sets. The attribute partition definition restructuring 4 may further include one or more attribute definitions 64 as defined in Figure 3B. Each attribute section regulation 64 defines an attribute as an attribute in an identifier format, an attribute in a state format, an attribute in a counter format, an attribute in a characteristic format, an attribute in a reference format,
or a type field 56 for identifying attributes of a particular type, including attributes of statistical type. For each attribute type, a data format is provided by an additional field 68. Attribute partition specification 54 may also include fields 60 and 61 indicating a default polling speed and a maximum polling speed, respectively, for the attribute. As noted above, the historical data recorder function module 11 may periodically obtain state and condition information associated with various entities comprising the complex system to be stored in the data storage elements 17.22. The contents of the Polling Rate field identify the default rate and maximum rate at which each entity provides status and condition information. In addition, the attribute specification includes one or more attribute fields 62, each with an attribute name 63. 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 in one partition specification 54. 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 specification 55. The attribute body 64 includes 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.
It can have many fields. 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 the entity developer. 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 C.
ONF IGURATION, FAULT, PERFO
RMANCE, SECURITY, or ACCOUNT
may include, but is not limited to, categories defined in the 74-98-4 Open Systems Interconnect (OSI) standard, including TING. 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 fields 72 and 73.
can be equipped with polling speed information. lastly,
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. Additionally, 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 included in the entity. The contents of the attribute specification portion 55 are specified in detail in FIG. 3B. The set specification portion 55 includes a set name field 75 for identifying a set, and an attribute list 8 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 for identifying proprietary variables used when processing in conjunction with the attribute. 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 11, respectively. Each command has a command request that specifies the action to be taken, and can have responses and exceptions that specify the response that the entity should take in conjunction with the action. Each Directive is defined by Directive Regulations 56. Figures 3C and 3D show the ellipses of Directive Provision 56 in detail. Referring to FIG. 3C, the specification specification 56 includes a name field 83 with a code by which the command can be identified and accessed. The command includes a request specification field 90 that identifies the elision of the request or dependent request, a response specification field 91 that specifies the elision of the response, and an exception specification field that specifies the elision of exceptions that may occur during processing of the command. 92, 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
INE, MODFY format or ACTION
The EXAMINE directive operates only on attributes and does not modify them. For example, S }
[If there is an OW command or DIRECTORY command,
The MODEFY directive operates only on attributes and makes modifications. Examples are the SET, ADD, or REMOVE commands. The ACTION directive does not operate on attributes, but on the entity itself. Examples are the CREATE command and the TEST command. A field 85 may be provided to indicate whether the command is accessible by the presentation module 10. An identifying text string may be provided in symbol field 86. In addition, category field 87 is
As specified above in connection with field 71 (Figure 3), one or more OSI categories may be specified, including, but not limited to, the structure of requirements specification field 90 of directive specification 56. In addition to the word rREQUEST, defined in Figure 3,
The request specification field 90 contains zero or more arguments 91 defined in the 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 indicating whether the overwriter must provide a value for the argument, a default field 96 containing the default value, a symbol field 97 containing an identifying text string, and a measurement of the argument value. A unit field 95 indicating the unit 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 II construction is shown in Figure 3D. Referring to FIG. 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 intensity field is set when the response fulfills the request specified by the request field.
whether it indicates UCCESS or whether the response is INFORM
Identifies whether it is ATIONAL or not. text·
Field 103 indicates a text string that presentation module 10 can display to the operator indicating a response. In addition, the response specification fields each include a name field 105 . One or more argument fields 104 may be provided, including a unit field 106 and a symbol field 107. In an alternative embodiment, the intensity field 102 can be replaced with a symbolic field with an identifying text string for the response, and the arguments field 104 includes a pool display field that indicates whether the response should be displayed to the user. be able to. The structure of the exception regulation field 92 is similar to the structure of the response regulation field 91, which includes fields 111 to 117 similar to fields 101 to 107 of the response regulation field 21. However, the severity field 112 indicates the severity of the error causing the exception, WARN
In another embodiment, the ferocity field 102 is a symbolic field with an identifying text string for the response, as in the case of response provision 91, which can have three values, including ING, ERROR, and FATAL. Alternatively, the argument field 104 can include a pool display field that indicates whether the response should be displayed to the user. 3. DISBATCH USE FIG. 3 defines a dispatch use 39A (FIG. 2B), which is used to define the initiation of a particular operation by an entity. The information in the Disbatch Use for an entity is used to generate a pointer to the procedure that performs the action. Referring to FIG. 3E, the dispatch use includes a heading 200 that defines the beginning of the dispatch use and includes the table name, and a rooter that marks the end of the dispatch use.
It is equipped with 201. Between the heading 200 and the footer 201, the dispatch usage has one or more dispatch entries, each of which specifies behavior 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 batch entry correspond to a command prescribed by the administration. The directives can operate on the entity or on the attributes specified by the attributes portion 205 of the entry specified in the entity entry, the contents of the entity entry 204 are specified in the name fields 47 and 50 of the entity specification 46. Corresponds to the entity or subentity identified by the entity class and stage name.
Similarly, the content of attribute portion 205 corresponds to the attribute identified by name field 62 of attribute definition 54 of entity body 53 of entity definition 46 .

Disbazuchi entry 2026 procedure pointer part 20
6, which is a dispatch entry 202
The access manager processes the directives 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 structures, specifically the process of directing requests by the kernel 13.14 to the appropriate functional module 11 or access module 12. Disbatch table 28 used to forward
The request or dependent request essentially specifies the verb, entity, and attribute partitions, and the kernel is specified by the request. Compare the verb, entity, and attribute sections of the dispatch usage with the contents of the parts of the data structure defined by parts 203, 204, and 205, respectively. If it matches the content of the part,
Kernel 13.14 is taken from dispatch entry 13, taken from section 206 of the dispatch specification (Figure 3E).
Begin the procedure specified in 4. B. Data files and usage 1. Registering a data dictionary management module allows its management specifications to define 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;
The Data Dictionary is used to construct another Data #4 structure, which is described below in conjunction with Figures 5 and 8A, and is used as shown in Figure 9. The data dictionary is comprised of a three-hierarchical database having the general organization or structure shown in FIG. Referring to FIG. 4, the organization includes a relative root node 220 that is associated with a global entity defined for administrative use (FIG. 3A).
The global entity node includes a subordinate node 221 that lists all attributes of the hierarchical organization of the entity body 53 of the entity regulation 46 of the management specification, a subordinate node 219 that lists attribute partitions, a subordinate node 222 that lists attribute sets, Dependent node 22 that lists commands
3, and a subordinate node 2 that lists the subentities.
Refers to multiple dependent nodes, including 24. Each subordinate node 219 to 224 refers to a respective element defined in the entity body.

That is, the subordinate nodes 221 point to attribute definition nodes 225, each of which has a definition of the attribute defined in the attribute definition 54 of the entity body 53, and the attribute partition node 2
19, each of which is an attribute definition 54 of the entity body 53.
The set nodes 222 each refer to a set definition node 226 having a set definition defined in the set definition 55 of the entity body 53; Command node 223
refers to the command provision nodes 227 each 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 definition node 228 that has the definition of . 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). In addition, each subentity node 228 has a dependent node 233 for attributes, a dependent node 234 for sets, a dependent node 235 for commands, a dependent node 237 for partitions, and a dependent node 2 for subentities.
36, forming the root node of a sub-organization with a structure similar to that depicted for the global entity shown in FIG. The organization shown in FIG. 4 is repeated for all subentities and their subentities defined in the management specifications shown in FIGS. 3A through 3D. The information in the management specifications relates to the display of entity information to the operator, including response information for each of the data dictionaries, and the generation of processing requests by the controller parts and complex system entities, as described below. and is used to create a user interface information file 29 for use by presentation module 10. The various nodes of the data dictionary receive information from the elements of the management specification to form a complete database of data dictionaries. Information in the dispatch specification (3rd E
) is used to create the dispatch table 28, as described below in connection with FIGS. 8B and 9. With this background, FIG. 5 shows one presentation module 10
, functional module 11, access module 12 and information manager 15.20 and dispatcher 16.2.
Kernel 13.14 with 1 is shown. In addition, FIG. 5 shows various parts of data storage element 17.22. In particular, data storage element 17.2
2 includes topographic and regional databases 23, 25, an alarm database 24, a historical data file 26, a data dictionary 27, and a database 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 has an entity. In file 26, the status and condition information also includes timing information that identifies the time at which the status and condition information occurred. When the information manager 15.20 receives a request or dependent request regarding a state or condition at a particular time, the information manager determines that if the time indicated in the request or dependent request is in the past;
Check whether the information exists 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 utilizes a response from the direct access module 12 or from the functional module 11, as appropriate. 3. process the request using the ``Scheduling'' heading, or if appropriate, using the file 26; 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 identify the location within the distributed digital data processing system of the entry point for the routines making up each functional module 11 that are called in response to a request from the presentation module 10. More specifically, dispatch table 28 contains invocation information that facilitates initiation of various operations by respective functional modules 11.
Similarly, the contents of the distribution table 28 identify the location within the distributed digital data processing system of the entry point of the routine of the access module 12.
This location is used to process dependent requests from the functional modules 11, ie, call information specifying various actions by the respective entities. 4. The user interface information control device further comprises two user interface information files 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 complex system entities. 5. Configuration Database As described above, the configuration function module can create and maintain a configuration database that lists all entity stages of the current configuration (and, if necessary, past configurations) of the complex system. This information can be, for example,
The presentation module can be used to create a scrutiny table or user menu that lists the available entity stages. The configuration database may also provide a domain database that limits the scope of user control to facilitate use of the complex system, as described below. In addition to the above features, in one embodiment, an elliptical 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. Next, the tree formation function module uses information from the tree formation database (along with area information) to create a list. Upon receiving the list, the presentation module expands the user request to all possible dependent requests that match the wildcard. For example, request SHOl4 MODE *IN DOMAIN SIT
E 1 (.:.: where sHOW is a command and DOMAI
N is the area entity class, SITEI is the area stage, and MODE is the global entity class.
It is a class, and the big one is a wild card, and the other one is SITE.
It is interpreted as an instruction indicating all stages of nodes inside the region named I. In this way, the presentation module sends each request to S H O W N O D E
<instance> (where <instance>
is the name of a stage], one corresponding to each stage of the NODE class of the area SITEI. Partial wildcards can also be supported. In this case, the command issued is a group of target entities whose stage names match the pattern specified by the partial wildcard name.

Tatoeba rNODE"OO, is rNODF, FO
O' and rNODE MAGO044: Matches, but does not match rNODE BARJ. Partial wildcards cannot be used for fields with certain data type identifiers, such as text or numeric strings. In the preferred embodiment, wildcard expansions are not allowed 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 cause errors if directive 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 rDBLETE tag command). In addition, global entity wildcards can easily generate more information than the user intended (for example, an rsHOW tag command). 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 you do not use tree-building functional modules. In the absence of a constituent function module, an access module (usually 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 wildcard of the received request. If wildcards are not supported by a particular access module, an exception will be returned to the user indicating this condition. C. 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 III9ll 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 embodiment, the historical data recorder functional module is controlled through requests submitted to presentation module 10 by an operator. Initially, such a request identifies an entity and one or more attributes, but, along with the polling speed, establishes a record for the identified entity and attributes in the historical data file, and the historical data recorder functional module , a dependency that allows an entity to respond to an entity at the polling rate specified in the request with a value representing the state of the entity in the complex specified by the entity and attributes specified in the request. In addition to allowing requests to be issued, other forms of requests may cause the operator to initiate operations on the historical data recorder function module and associated tunes, including changing the polling rate and temporarily changing the polling rate. Enable or disable and indicate the last value in the response. 2. Disbatch Table The contents of the dispatch table 28 and of the user interface information file 29 include registration information, which is provided by the various functional modules 11 and the access module 12 during the registration procedure. During the registration procedure that registers the module with the control device, the module loads display information, including name and code information, from its name field into the data dictionary. In addition, the module obtains code information and pond information specified in the management specifications from the data dictionary (Fig. 4), dispatch information from its dispatch specifications (Fig. 3E), and stores it in the dispatch table 24.
3. Load into . The user interface information presentation module 10 uses the display information of the user interface information file 29 to initially display the entries,
Decide whether or not to display attributes, commands, etc. Second, decide what to display. 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 user
Note that you do not need to own the interface code. All user interface support equipment is provided for these modules, and the module designer
There is no need to worry about the interface. This makes modular design incredibly easy and ensures that the system looks and feels uniform to the user, regardless of the actual modules being used. Upon receiving the request from the presentation module, dispatcher 1
6 calls the function module 11 using the dispatch information in the dispatch table 28. Disbatch
Table 28 also forms a scrutiny table, which is used by dispatcher 16 to route the request to the eligible procedures to process the request, as described below in connection with FIG. Using the code in the scrutiny table and in the dispatch table 28 while using presentation-specific information in the user interface information file 29, entities, attributes, etc. are provided to the operator by the presentation module 10, as used by the dispatcher 16. It can be seen that it is virtually separated from the displayed identification. Presentation module 10
The representations generated by the presentation module 10 can therefore be expressed in diverse languages, while the requests generated by the presentation module 10 have the same identification of entities, attributes, etc. Additionally, 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 subordinate to entity classes 220. Although this format is logical for representing entity class information, it is not very useful for scrutiny tables. User requests typically first include commands (e.g., rsHoW NODE FOO, rsH
OW,), the scrutiny table should have the command as the first level of the hierarchy. As you can see from the example above, the scrutiny table is based on class names (e.g. rN
ODEj) is mixed with a stage name (for example, the identifier F00 of "rNODEF00"), this is necessary because the instruction will be inspected. Therefore, after listing the available directives, the scrutiny table specifies the class names that support these directives.
You should then list the data formats for these class stages. While class and data type information is available by reorganizing the data dictionary, for wildcard expansion stage data can be obtained from the configuration database. Therefore, the scrutiny table in the user interface information file can integrate directives and entity classes, making the scrutiny of user input more efficient. The above example also applies to graphical or menu-driven interfaces. However, in this type of interface, the user graphically selects a particular entity or area of entities for further action and the OSI category of the command to be performed (listed in the directive specification category field 87). Sometimes you may want to set the context for your command. 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 entire regions or entity classes (by clicking just the commands). For EXAMINE-style or CATEGORY-style commands, a separate menu can prompt the user to select an attribute pane or set. To implement this type of interface, the list of all regions and entity stages and the list of all stages within a region must be retrieved from the configuration database. Fl! ! The configuration 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 ING, which will be interpreted as rsHOW NODE FOOROUTINGJ. A similar use of default values is available for graphical environments. Other examples of user interface information are online supplementary files available to users through presentation modules. Auxiliary files contain auxiliary information for making use of the existing set of management modules. In the preferred embodiment, the auxiliary file is assembled from auxiliary information provided by the module when the module is registered. The supplied auxiliary information may comprise a textual description of the classes of entities and subentities supported by the module and instructions for the classes supported by the module. In addition,
Tutoring information can be provided to educate new users about the module and its commands. Although the above information can be obtained from the management specifications for the module, the auxiliary information file translates the management specification information into English, reducing the need for users to learn the horizontal grammar of the management specifications. 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. The historical data recorder function module 11 stores the responses in its historical data file 26 by initiating and controlling polling in relation to various attributes of the defined entity. 5. Module Registration Referring to FIG. 5, the access module 12, for example, while engaged in a registration procedure, displays the name and code information and its management specifications as specified in the name and code information from its name field. Load display information into the user interface information file 29, including information from the portion of the data dictionary that pertains to the field. Similarly, the functional module 11 stores code information and other information specified in the management specifications in a data dictionary (Figure 4).
and dispatch information from the dispatch specification (Figure 3E) to the dispatch 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 io that receives the instructions is
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 function/access/power channel 14, where it is processed in the same manner as other dependent requests. When a dependent request is received from a control function module, the dispatcher 21 uses the dispatcher information in the dispatcher table 28 to call the access module 12. 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 associated data files 23, 24, 25, 26.27;
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 an 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, the dispatcher 16 (1) of one process of one node presents a request that must be processed by the functional module 11 (2) of a second process or node to the module 1o (1). If the functional module 11(2) is in another process of the same node, the dispatcher 16(1) dispatches the request to the process of the other node or to the Dispatcher 16 (2). Dispatcher 16(2) then selects functional module 11(2) to process the request. The dispatcher 16 (2) receives the response generated by the functional module 11 (2) and sends it to the inter-process communicator or the inter-node communicator.
and the dispatcher 16(1), which enables the presentation module 10(1) to display the response to the operator. Similarly, the dispatcher 21(2)
1 (2) to process the dependent request to be processed by the access module 12 (3) of the pond process or the notebook, the dependent request is transmitted through inter-process communication tl! It is transmitted to the dispatcher 21 (3) of another process or node through a treetop or inter-node communication mechanism. Dispatcher 21(3) then communicates the dependent request to access module 12(3) for processing. The dispatcher 21 ( 3 ) receives the response from the access module 12 ( 3 ) and sends it to the dispatcher 21 ( 3 ) using the inter-process communication mechanism or the inter-node communication mechanism.
2), and the dispatcher 21 (2) couples this to the function module 11 (2). 3. Figure 7A shows the structural requirements of the request and dependent requests, particularly the elision of the parameters included with the request. The structure and contents of dispatch table 24, which is the same as the structure and contents of dispatch table 26, will be described in conjunction with FIGS. 7A and 7B. The information manager 15.20 and the dispatcher 16. 2
The process performed by 1 will be described in conjunction with Figure 9. Referring to FIG. 7A, the user interface information file 27 may be generated by the presentation module 10 in response to the contents of the user interface information file 27 and related actions by the operator.
or the request comprises a plurality of parameters, which can be generated by the information manager 15 during polling in connection with various entities of the complex system to be controlled.
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 and function 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. Although a presentation module or a functional module can call a functional module and a functional module or an access module can call an access module, the presentation module
Only the access module can be called through the "control function module". 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, the request is made by function module 11 or access
The module 12 may initiate a change in the state or condition of an entity of the complex system controlled by the module 12 and may initiate the return of information regarding the state or condition, or both, of such entity. verb field 1
The contents of 20 indicate the operations performed by the functional module 11 or the access module 12. The request includes 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 ellipse that contains certain timing information, including absolute system time, time interval specifications, and time accuracy specifications, and specifications for that time range in the request for scheduling purposes. An input time specifier field 123 is provided. Input/output context handling field 1
24 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. ．． The request is made by function module 1 in connection with the formation of the response.
1 (or access module 1 for dependent requests)
It also has a pointer to the item stamp specification that is to be used by 2). Finally, an optional data descriptor field 127 contains the data used in processing the request and provides a descriptor for the buffer in which the entity stores the data that constitutes the response. Each descriptor has a pointer to the starting position of its respective buffer and a length specifier indicating the length of the buffer.
In another embodiment of the invention, the request is made as a separate parameter or as a separate element of the parameter field described above.
It can also have a qualifier field. The WITH qualifier can be associated with a field that filters the entity list created by wildcards, for example. For example, rBR
IDG★WITH STATUS=ON AND
FILTERING=0FFJ sets the status flag to O.
N points to each bridge class entity with the filter flag set to OFF (this example refers to AND, O
It also illustrates the use of pool functions such as R, NOT, and qualified XOR). In a preferred embodiment,
To realize WITH@Constant, all modules and information managers are configured at each level of entity parameters.
In other words, it is configured to check the presence or absence of a WITH clause in global entities, sub-entities, sub-sub entities).

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
i I e name> Send to a file named
rFROM<f iI e nam to search for the "To<f i lename>" qualifier, other request parameters in the file named <f i le name>
e>J qualifier, the rVIAPATH qualifier that specifies a series of "hops" along a path through the hierarchy of management modules (e.g., in specifying a fine-grained management module between several devices performing an operation). useful), and the rVIA PORTJ qualifier (useful, for example, to specify that the access module performs diagnostic tests that use a particular Ethernet port), and the rVIA PORTJ qualifier that specifies the particular network path that the management module uses when performing an operation. ). Similarly, explicit parameter qualifiers can specify groups of entities. rlN DOMAI
N<doma1n name>” qualifier is <doma
Filters the specification so that it applies only to members of the area named in name>. Also, explicit parameter qualifiers can authenticate or qualify requesters of management services with limited access rights. rBY ACCOUNTJ, 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 lause>:
:=″AT” <time-arg> [” ,”
<time-arg>]. Here time argument < t
ime-arg> is, for example, the start time (rsTA
RT=<time>"), end time (rEND=<
time > 4 ), or connection time ( 'DURAT
ION=<ti me−1ength>J ), repetition period ( rREPERT EVERY[=]<ti
me-1ength>”), time accuracy (rcON
F I DENCE [=]<time-1engLh
>”), or sampling rate (rsAMPLE
RATE [=] <t i me − 1 e n
gt h>”). These arguments interact with each other to create a general schedule and scope of interest for the request. In particular, in one particular embodiment:
Three time arguments, START, END, and DURA
The TrON is related in such a way that two of these define the period. Therefore, at least two of these qualifier arguments must be specified when displaying period-standardized entity statistics. Other time qualifiers can also be used. For example, ^T OR BEFORE<
The time qualifier of <tile> can be interpreted as requesting time-slumped information at or before the time indicated by <trne>. 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. In the case of that pond, the management module determines that the time < t
Continue checking/checking the m-report until it reaches ina>. If the information is generated, it is returned to the requester. Otherwise, at time <time>, the management module forces the ball of information from the access module or entity and returns the information to the requester. To supplement the AT OR BEFORE tils qualifier, a No one time qualifier can also be implemented. For songs, field 124 contains a handling pointer that points to a context data structure, which is a dedicated section of storage that stores processing context information. Tokumi is used, for example, as a ``notepad'' to communicate context information between the module and the information manager. I. Each item of time stamp data has a time stamp 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 specification of interest 123 can be used to request retrieval of 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 entitled value'' can be displayed and processed, and statistics can be calculated over a period of time. In one particular embodiment, the "time range of interest" is represented by a prepositional phrase in the time specifier of the request. Generally, time specifiers are used with SHOII instructions, but time contexts can also be applied to 140DIFY style requests and actions. The time ranges of interest are absolute instants, sequences of absolute instants, time intervals 《start time rsT^RT, and duration rou
nJ), 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:00 EVERY O:1
5, is 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 r 5:EVEf
tEY O15LINTIL6:OO” is 5:00,5
:15, 5+30, 5:45, 6:00.
You can specify the repetition time interval in the same way.
rsTART5:00 0UR:05 EVERY
I:00, is the time interval 5:00-5:05, 6:00
Equivalent to -6:05,7:00 -7:Q5... 3. Scheduling Scheduling information may also be indicated by the time specifier 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, is the time of Sugeju song +1? cannot contain intervals. A time interval whose starting point and ending point are equal is an ``instant'' (T
ODAY, TODAY )). There are a number of 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, the future time interval is the keyword TOHORn014,
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 Structure 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. In general, 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.
module or information manager only knows about the context blocks and extractions associated with the local portion of the chain.Referring to FIG. 7B, in one particular embodiment, the requester, e.g. The assigned time context handling 172 includes a range field 175 and a schedule field 176 that relate to the time specification 123 of the initial request. 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 112 also includes a context pointer 177 and a state variable 178. These data items, which represent the collection state and criterion functions, 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 171 will ultimately include a pointer to another data structure 174, known as a context block, which created and maintained by the service provider, e.g., the presentation and functionality surface 15 of the information manager (
Functional modules and access modules can also create and maintain context blocks on demand. The handling status field 178 has one of three values: rFIRsT J, rsont, or rcANcEL', these are used as flags to indicate further actions to take. When first created, the handling state 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 a more general case, a service provider, e.g. a functional module,
The information manager or access module cannot satisfy the request with a -9 answer; for example, the requester may use a wildcard in the input entity parameter 121 to specify a group of entities. can. Since each reply can only incorporate information from a single entity, several replies are required, one for each entity. Fl! In case I, a request to a single entity can have a time specifier with several different time values, since each reply can only incorporate information for a single time value, Several replies are required, one at a time. Requests that require multiple replies may be of any form, including obtaining attribute data about an entity or entities, modifying attributes of some entities, and modifying the state of some entities. It may also be related to motion.

If a service provider processes a request and finds that the request has an alternative 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 feature, for example, stores collections related to dependent requests for functional modules in a pool of pointers to the service provider's disk batch entries (see discussion below under the heading Dispatch Table). Associated proprietary variables generated on demand, such as context pointers pointing to 1
This is accomplished by creating a context block 174, which can include a .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
Set r HORE J to the value of r HORE J, and use an appropriate handling modification routine to signal that you have another reply. When the reply is returned to the requester, the requester looks at the rHORE, 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, the request must be dismissed (see below). If the requester wants a different reply, he must repeat the request without changing the parameters. If the service provider makes these repeated requests (this is rHORE,
), the appropriate fetch access routine is used to locate and detect the state r }IORE . The service provider then knows that the call is part of a previously established request. (Note that a treatment with a state of rFIRsT. indicates to the service provider that the associated call is the first invocation of a request.) For each call with a state of rHORE, a treatment, the service provider Pointed out context block 174
and continue its execution using a context block,
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 parameter in the rHORE, state, the service provider has more replies to requests. The service provider may 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 state). When the return is sent to the requester with this final reply, the requester receives r
FIRsT. Look at its collection parameter state set to , and find that its requirements are completely 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 parameters that result in the rMORE, state. The requester is handled according to its initial setting rFIRsT.
” state to indicate to the requester that the request is complete. If the service provider returns a handling parameter in state rHORE, the request must be repeated or canceled; if the request is otherwise discarded, it must not be assigned to the collection and context block. System resources will be lost due to storage. Regarding the above discussion, note that if the service provider did not issue any dependent requests, a single transaction would suffice for communication between the service requester and the provider. 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 is 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 scheduled time specified by the time specification, the information manager generates a request that causes the service provider to perform the requested action and generate a response.

When the service provider completes the requested action, it issues a response. When the information manager sees that the service provider has completed the requested action, it examines the scheduled time context set aside for the initial request. If there is more time to schedule the requested action, the information manager does not set the handling status of the requester to rFJRSTJ and returns 'MOR
E. Leave it in bad condition. The requester sees that its handling parameters are still in the r MORE J state, knows that the entire request is not complete, and asks about the rest. Next, the information manager waits until a predetermined schedule time,
Have the dispatcher make another call to the service provider. The service provider will send this next call to the rFIRs
Note that returning the handling state set in TJ does not preserve the context, so it cannot be distinguished from invoking a completely new request. The requester also does not distinguish between the handling status of rN(IREJ) generated by the service provider waiting for more replies to the request and the information manager preparing between the new schedule Il#.Other implementations In the example, the handling access routine is augmented to allow the requester to confirm the handling parameter rMORE, the occurrence of the condition, during a request with multiple replies or multiple schedules.
If the requester decides that he does not want any further response from the service provider to this request, he must cancel the request. Possible reasons for attempting to cancel a request include receiving an exception reply indicating that no more data is available, or receiving an error condition indicating that the desired action was not performed correctly. The reason for cancellation is the responsibility of the requester. Cancellation terminates all activity of the request, including the scheduling and scope of the operation.

Cancellation 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 rCANCBL, 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
View the handling parameters in the "CEL" status. 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. When the service provider completes its purification, the handling parameters are reinitialized back to the "FIRST" state using an appropriate handling modification routine. Next, the service provider is C.
A special condition value return code of ANCELED is returned to indicate that the request was successfully canceled. The requester cannot cancel the request after the service provider returns the handling parameter status of rFIRST. 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 rMORE.

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.
Contains one or more dispatch lists containing the dispatch entries depicted in the figure. The dispatch tree and the dispatch list essentially form a review table used in reviewing requests, as described below in connection with FIG. Referring to FIG. 8A, the dispatch tree includes multiple entity nodes 130. entity node 1
30 are organized into tree top structures to aid in scrutiny, but these can be organized into pond data top structures. Entity nodes identify various entities within a complex system that can have requests associated with them. Entity nodes 130 have respective dispatch nodes.
A pointer is provided to a dispatch entry 134 (FIG. 8B) of the dispatch list maintained in table 128.

"The word of entity node J is data if4"ml
Used to describe 30. This is because it satisfies the entity model shown above. In general, data ellipse 130 satisfies the entity model because it has a hierarchical structure and its child structures that resemble it. used to describe the data structure 130.
The term ``entity node'' should not be confused with the term ``entity,'' which is 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 pertains to an entity class or a stage within a class. The class is defined by a distinguished class name in the entity's entity definition 46 (Figure 3A), and the dispatch
Table 24 lists other entities related to classes and stages, as described in Figure 9 and below.
It is equipped with a node 130. While refining a request, the class name and stage name of an entity and its attributes are examined using a data structure of the form shown in Figure 8A; are used separately. The status of a class or stage is indicated by a class/stage flag. Entity node 130 also includes tree link pointers that identify various other elements in dispatch table 28. Modules that service requests involving several entities of the same class can be identified by wildcards or ellipses. If so, the associated entity node has a wildcard pointer in field 141 or an ellipsis pointer in field 142. Each wildcard pointer and ellipsis pointer is
It consists of tree link entries as described below. If the entry node is related to a class with no levels, an example of which is described below in connection with FIG. - Equipped with a pointer. Finally, field 131 contains the code
An entry is provided that contains a code that identifies the class or name of the entity stage associated with the entity node as well as the link pointer. The code entry field 131 shown for entity node 130 in FIG. 8A is one entry in a coded list (the rest of the list is not shown). or, when referring to a name, is a linked list with the names of the classes of entities specified by the Entity Management Specification (see Figures 3A to 3D). 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 a class code or stage name. The contents of field 151 comprises a class code if class/stage flag field 140 of entity node 130 is adjusted to identify the entity node associated with the class.
Alternatively, the contents of field 151 comprises 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, a dispatch entry 134 in the dispatch list is used to identify a particular procedure to process a request. The 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 1l 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 comprises the identifier of the functional module 11 or access module 12, during whose registration a dispatch entry 134 is generated. Dispatch entry 134 includes a series of fields 162 through 164 that point to procedures, processes, and nodes for processing requests within the complex; field 165 identifies the verb to which the dispatch entry pertains; Attribute field 166 contains management specifications (third
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 reviewing 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 gross process in conjunction with the dependent request from functional module 11. Referring to FIG. 9, the request 180 is as follows. SHOW NODE (node nan+e) ROUTING CI RC UIT (routing ci
cuit naIIle ) CIIARAC7El? I
STJCS This is used in conjunction with distributed digital data processing systems. Request 180 has a number of compartments, including a verb compartment 181, ie SHOW, an entity compartment consisting of a plurality of entity class codes and stage names 182-186, and an attribute compartment 187 consisting of a plurality of attributes. In this example, the verb SHOW initiates the generation of a response from the entity named in the request that is related to the named property. In request 180, the entity partition, element 18
2 to 186, has a large number of class/stage pairs. In particular, element 182, NODE, is the class code and element 183, i.e., <node name
) identifies the stage of the entity class NODE by the stage name <node nalle>. Identify nodes in a distributed digital data processing system. In distributed digital data processing systems, <node
nan+e > identifies a node in a distributed digital data processing system. The pond, request 180 further states:
The entity partition has an entity class code of 184, ROUTING, which has no stages.
In addition, the request 180 is another entity class code,
CIRCUIT, which is <:ROUTI
It has a stage identified by NG CIRCUIT 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, 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 the entities and subentities are taken from stage data known to the user (e.g., by reference to a configuration database or through a menu generated in an automatic height).6 Upon receipt of the request, the dispatcher 16 • Using node 130 (Figure 8), begin to examine the elements in the entity pane, starting with the global entity class code element 182. Specifically, with reference to FIG. 9A, dispatcher 16 begins (step 190) with a root entity node that is provided with a class/level flag 140 that identifies the entity node associated with the class code; Class code field 1 with class code of NODE
Find an entry in that encoding list 131 that contains an encoding entry with 51. If dispatcher 16 cannot find such an entry in dispatch table 28, dispatcher 16
looks for a wildcard or ellipsis pointer (see below). (If the wildcard or ellipsis pointer is not found, it responds with an error to the module 10 that received the request.) - Once the node 130 is located in the dispatch table 28, the next step of the probing operation <<step 191>> is reached, where the step specified by the entity element 183 (nod
e natge ) and associated entity node 1
Trying to track down 30. In this operation, dispatcher 16 uses the contents of pointer field 152 of encoded entry 131 to identify the entity node associated with the stage name and whose encoded list requests 180 that stage name entry. Locate the entity node with the class/level flag 140 that has the encoded entry corresponding to <node nane> of the entity element 183. Again, the dispatcher 16 stores such nodes in the dispatch table 28.
If that doesn't work, look for wildcards or ellipsis pointers (see below). On the other hand, in step 191, the dispatcher 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,
Try to find 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
class/stage flag 1, comprising a coded entry 131 identifying the entity node associated with the code and whose coded entry list comprises a class code field l51 with ROUTING;
Locate the entity node 130 with 40. In this situation, the entity class ROUT
Since ING is a stageless entity class, pointer field 1 of encoded entry 131
52 is null. In this case, entity node 1
The null pointer field 143 of 30 points to the second entity node 130 associated with the class entity CIRCUIT. 13
A second entity node 130 and its class code field 151 have a CfRCUIT using a null pointer of 0 to indicate that its class/level flag 140 is associated with a class code. Locate the encoded list with encoded entry 131 (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 action, dispatcher 16 causes field 15 of coded entry 131 to
2 pointer to its class/stage flag 14
0 identifies this as being related to a stage name. The coded list is different and the stage name field 151 is the request 18.
<ROUTING specified with stage entity 0
Locate the entity node 130 with CIRCUIT NAME>. dispatcher l
If .6 cannot locate such an entry, it looks for a wildcard or ellipsis pointer (see below). On the other hand, dispatcher 16 performs process 194
Once the stage entity node 130 that identifies the stage entity element 186 is located, the dispatcher 16 retrieves the entity partitions 182 through 186 of the request 180.
This means that we have successfully examined everything up to the point. Dispatcher 16 then retrieves the pointer in field 152 of coded entry 131 located in step 194, verb element 1.
Dispatch entry 1 that should be used to process the request using the verb of 81 and the attributes of the request characteristic element 187
34 (Figure 8B). In particular, following step 194, dispatcher 16 uses the pointer in field 152 of coded entry 131 to identify a list of dispatch entries 134. Dispatcher 16 then determines that the contents of its verb field 165 are
80, which corresponds to the verb element 181, in this case SHOW, and whose attribute field 166 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 than those associated with the dispatcher, then the dispatcher will submit the request for processing, respectively. to the dispatcher of the other process or node identified in fields 163 and 164 of . 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, use wildcards and ellipses to
to specify in a general way which entity classes or stages serve a management module. An example of such a dispatch specification is NODDE"ROUTING CIRCUIT, which means that if a module is a global entity of class NODE, and if a module is a subentity class CIRCUIT of any other CIRCUIT class subentity, This indicates that all sub-entities can be handled. The asterisk (8) - matches any stage name, and the ellipsis (
) matches all subentity stages or subentity class/stage pairs that may follow. For example, the expression NODE foo ROUTING CIRCU
IT bar LINK fred conforms to the disbatch specifications. Because "r2" is rfoo
4 and r. ．． ．． , is rbar LINK
This is because "fred" is compatible. Referring to FIG. 9B, to enter the wildcard dispatch specification of dispatch table 28, correspond to the stage name of the NODE class entity in step 191 (FIG. 9A).
Entity node 130 will be modified. One of the wildcard pointers 141 is a class.
The code is changed to point to a new entity node 130 containing a class code whose code is ROUTI NG (step 196). The child pointer related to class code RoVTING is null (step 192 (9th A
), the null pointer is the class name CIRC
Create another new node 130 that will have a child pointer corresponding to the UIT (step 197).
．． This child pointer is the new entity node 1 in the pond.
30 (Step 1 98>), its ellipsis pointer points to the dispatch entry for the module (Step 199).
The steps up to 91 are the same as those explained using FIG. 9A. In step 191, dispatcher 16 sends a name, e.g. rf
Find the stage of the NODE class with "oO". 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, the name rfoo,
If a 1 is not found in the coded entry (indicated by the null NEXT ENTRY pointer of the coded entry after fi), 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 moves to step 197 using a null pointer (corresponding to class code rROUTING) in step 196 and to step 198 using a child pointer corresponding to class code rcIRcUIT. 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 for general matching of entity class codes and stage names, but the contents of the dispatch/chi table are Only after the coded entry has been checked. In this way,
Dispatch is the "most obvious match" for the entity name
Search for. So, for example, the first module is the dispatch specification NODE LARGE ROUTING CIRCUIT
can be prepared. This indicates that the module can handle all stages of all CIRCUIT class sub-entities of the ROUTI NG class sub-entities for the stage ``rJoe'' of the NoDE class global entity. 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-entities for stage 1'joe' of the NODE class global entity. In order to be consistent with the "clearest match" rule, NO
DE Joe ROUTING CIRCUIT
All commands for subentities should be sent to the second module. This is accomplished using a dispatch table mechanism. Because the stage name rJoe4
appears in the encoded entry in step 191, so rJo
If e4 is the stage name in the request for ROUTING CIRCUIT, then the rJoe4 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 shows that the module can handle all stages of the sub-entities of the DISDRIVE class for the stage rJlm4 of the global entity of the NODB class. This specification is entered into the tree in step 191 in a manner similar to Figure 9B by appending the stage name 1'Jimj to the encoding entry followed by 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 node. However, NODE J1m ROIJTING CIRC
Requests with entity names starting with tJIT will require the new module to be DISKDRI for the NUDE stage 'Jirrz'.
Since it only supports subentities of the VE class, it cannot receive services from new modules.
Therefore, the dispatcher uses the class name ROUTING
Once you have determined that CIRCUIT is not supported by the new module, return to step 191 and optionally use other encoding entries or wildcards or ellipsis pointers to create rNODB Jim ROUTING.
A mechanism must be provided to find a module to service a 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, an error is returned to the requester (i.e., 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 this kind of pass-through, the dispatch table
This is a presentation that matches any entity name in any request. The ellipsis pointer to the root node of the functional aspect is the dispatch pointer to the control functional module.
It should point to the entry. Upon receiving a request, the control function module simply issues the same request to the function access aspect of the dispatcher. In this way, all requests that do not conform to the dispatch specifications in the Presentation and Functional Dispatch Table are communicated to the Functional Access and Dispatch Table for conformance. This allows the presentation module's requests to access the primitive functionality available from the access module. In another embodiment of the distribution table, null pointer field 143 is a linked list elliptically 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 examined after the code list and before checking the filled cards. G. Domain and Configuration As mentioned above, the elliptic function module 11 maintains a configuration database that defines the entities that make up the complex system. With appropriate instructions from the operator, the configuration function module 11 can add stages of entities defined by the data dictionary to the configuration database, delete them from the configuration database, and change the specifications in the configuration database. As mentioned above, the domain functionality module 11 establishes domain entities in the domain database that refer to a subset of entities already defined in the domain 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. Thereupon, the operator initiates control or monitoring actions relating only to the entities in the area, without initiating the generation of requests by the presentation module 10 for each entity, thereby controlling and monitoring the complex system. It can be simplified. The realm functionality module establishes a realm database for each realm entity that identifies the entities that make up the realm entity within or in addition to the configuration database. Upon receiving the appropriate request, domain functional module 11 adds the entity to the domain database;
thereby adding entities to the region, deleting entities from the region database, thereby deleting entities from the region, generating a response identifying the entities that constitute the region defined in the region database, and deleting the region database; This effectively removes the log area. Referring to FIG. 9C, the format of the configuration database and the region database (which can be combined into a single database) for each entity stage within a configuration, and similarly for each entity stage within a region, is as follows:
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. In addition, the realm database includes an entry 232 for each entity that is a member of a realm, listing each stage name and the realm of which it is a member. The region functionality module may update this information as the region is modified and utilize this information to quickly determine the members of the region, or alternatively, quickly determine the region members of the entity.

In another example, the first region can incorporate members of the second region by referencing the second region;
In this way, the size of the region database is reduced. In an embodiment of a, the domain database may establish a hierarchy of domains similar to a hierarchy of entities and sub-entities, and instructions may be conveyed similarly to domains and sub-domains. The configuration database includes entries 234 for each entity and subentity, organized hierarchically within the database.

A full name is provided for each entity and subentity stage. This information can be used by the configuration functionality module to quickly determine configurations to display (via the presentation module) to the user, for example, a map of configurations 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 upon request from the presentation module 10 and detects the occurrence of the alarm condition using various conditions recorded in, for example, the user interface information file 29 of the entities of the complex system. can do. FIG. 10A shows the functional organization of the alarm function module 11. Referring to FIG. 10A, the alarm function module 11:
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
Rules for identifying each alarm condition using the alarm rule base 203. Maintain. Each rule represents a set of conditions that must be evaluated to determine the presence or absence of an alarm condition. especially,
Rule maintenance module 202, in response to requests from presentation module 10, generates rules, which are stored in alert rule base 203, as described below in connection with FIG. 10B. In addition, the rule maintenance module 202 can modify the rules in the alert rule base 203 in response to a corresponding request from the presentation module 10, so that the alert condition represented by the rule exists. The conditions are corrected. Similarly, the act of detecting an alarm condition 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 rule base 203. use. As discussed below in connection with Figure 10B, each rule includes a condition portion that identifies the condition. Detector module 201 detects an alarm condition by, for example, determining whether the contents of the historical data file comply with the conditions of various regulations. If so, the detector module 201 generates an alarm indication, which is forwarded by the general alarm module 200 via the notification module 204 to, for example, the presentation module 10 for display to the operator. The general form of the alarm rule generated by rule maintenance module 202 is shown in Figure 10B. Referring to Figure 10B, the alarm rule includes a condition portion 210, which indicates a set of conditions necessary to indicate an alarm. The condition part is the second part 212
, a relational operator 213, and an expression numerical part 214. The relational operator 213 converts the expression part 212 into the expression numerical part 2.
14, the condition part 210 is logically TRUE.
(TRUE) logically evaluates to FALSE (FALSE). When the expression part 212 itself evaluates to logically TRUE or logically false, the relational operator 213 and the conditional part 2
It can be seen that the numerical value part 214 of formula 10 is unnecessary. In either case, the condition part is a logical TR
As assessed by the UE, an alarm condition exists.

The rule has an entity and attributes part 212 and a time value part 216, a re1-op value part 213
associates the value of one attribute with one numerical portion 214. The time value portion 216 establishes the time function and the condition portion 21
0 can indicate the time or time interval that the alarm detector module 201 should use. The provision of the alarm function module 11 allows the operator to establish alarm conditions dynamically and on demand.

Because alarm conditions do not need to be predetermined within the controller, the controller can be used to control and monitor a wide variety of complex systems. For example, when a controller is used to control and monitor a distributed digital data processing system that may have various configurations of nodes communicating through a network, alarm conditions can be based on the particular configuration. Can be established by the operator. If a new alarm condition is discovered during operation of the complex system, the alarm condition can be added by adding a rule to the alarm rule base 203. We will describe a system that controls and manages a group of entities. In this system, entities interface with the group to control the main information processing functions, and the entities further interface with the system to perform management functions. Make it possible to do this. Such a system is equipped with a storage management module that performs management functions by independently translating and executing predetermined management-related commands, and the kernel translates the commands and sends the commands to each module to be executed. It stores a table of dispatch pointers that point to
We further describe a system that provides control and management over a collection of entities, where the register is used to register a new management module with the system by adding another pointer to the table. Entities interface with populations to control key information processing functions, and entities further interface with systems to enable them to perform management functions.

Such a separate system has a storage management module adapted to perform management functions by independently translating and executing predetermined management-related instructions, and the kernel has a storage management module adapted to perform management functions by independently translating and executing predetermined management-related instructions. Stores a table of dispatch pointers that direct instructions to. A system that controls a group of entities and performs management functions will be described separately. This system is equipped with a storage management module that independently translates and executes predetermined management-related commands, and stores a table of database pointers that translate and direct instructions to the respective modules to be executed, and the register is used to register new management modules in the system by adding another pointer to the table. It will be done. 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 text. Polling information can include fields that specify a default rate and a maximum polling rate at which the value of an attribute should be requested from an entity. The system will be further described. In this system, the management specification information can include partition information in a predetermined field of a common tree text, and the partition information represents a group of attributes having a common data format. Management specification information can include set information in a predetermined field of a common ellipse, and set information represents a group of attributes that have related functions in entity management. The management specification information can include command information in a predetermined field of the common ellipse, 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 structure of the reply to be received. It is listed. The structure of the request to be issued can also include fields that list arguments to the command. The structure of the response to be received may also include a field used to indicate successful completion of the requested action. Additionally, an alternative is described in which the response response to be received may include a field used to indicate an error condition that prevents the requested action from successfully completing. At least one management module includes an access module implementing a protocol for communicating with one or more entities. The protocol conforms to the Ethernet standard, or the protocol conforms to the DECnet P
The protocol conforms to the DECnet Phase V standard. Another alternative is described in which each instruction has a field that lists 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 comprise a data ellipse, a pointing graph of a continuous data structure with a graph corresponding to the fields of the instruction. The dispatcher traverses the instruction graph according to the entities and operations listed in the instruction and dispatches. It has a scrutinizer that locates terminal data structures with 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. ellipsis flag, and a continuous data structure, or the scrutinizer determines the most accurate match for the instruction's field by first looking for an exact match for the field, and then for an exact wildcard match for the field. An alternative to such systems is to determine the most accurate match for the field of the instruction by first looking for an exact match for the field and then for the ellipsis match for the field. It has a scrutinizer with a best-fit unit that determines the fit. The instruction graph includes wildcard flags and continuous data #I flags that can correspond to any value of a particular field of an instruction, and ellipsis flags that can correspond to any number of values of a field of an instruction. and a continuous data structure, the scrutinizer determines the most accurate match for the field of the instruction by first looking for an exact match for the field, then a wildcard match for the field, and then an ellipsis match for the field. It is equipped with a best-fitting unit that determines the fit. 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, the presentation module including a conversion code that converts information received from an entity into a predetermined format for the presentation device, and a transfer code that conveys instructions from the presentation device to the dispatcher. I'm here. The presentation module may include user interface information that defines the mode in which the user interacts with the system. User interface information can include assistance information that provides the user with information about how to use the system. User interface information can include graphics mode information that defines the contents of the buffer menu and the command line review table. The kernel may further include a class database that defines 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.

This describes a system that controls members of a computer network and performs pipe FA functions.
In this system, members interface within the network to control key information processing functions and
Members will also be able to interface with the system to perform administrative 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, with each record containing an associated time indication. 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 functional modules adapted to perform functional operations on 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 area specification information defining groups of members of the network. The kernel can cause commands to be issued to all members of a group by issuing individual commands to the appropriate management module. The at least one management module is further adapted to perform self-management functions for itself by independently translating and executing self-management instructions.
The information manager further includes a scheduler that responds to commands specifying a time schedule. A scheduler is used to possibly enable sequential dependent access or retrieval 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 the entity interfaces with the population to control primary information processing functions and allows the entity to perform additional management functions Do it like this. The process includes the steps of providing a management module that performs management functions by independently translating and executing predetermined management-related commands, dispatching commands to translate commands and directing commands to the respective modules to be executed. - 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, management is stored in such a way that it performs management functions by independently translating and executing predetermined management-related instructions. We refer to modules, in which an entity interfaces within a population to control primary information processing functions, and an entity can further interface with a system to perform management functions, and a system has multiple management modules and commands. It includes a kernel with a table of dispatch pointers that directs instructions to each module to be translated and executed.

Dispatch pointers, which point to modules and are associated with instructions translated and executed by modules, are also discussed.

[Brief explanation of drawings]

FIG. IA is a functional block diagram of an oval control device 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 structure 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. 3A, and FIG. Define the disk batch specifications for the module. Figure 4 shows the layout of a data dictionary containing information specified by the management specifications shown in Figures 3A to 3D. 5 and 6 are functional block diagrams showing various modules and data layout 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. FIG. 7B shows the temporal context handling and context block layout used by the requirements of FIG. 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 the 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 the functional modules used to establish and detect alarm conditions, and FIG. 10B shows the structure of the 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)

[Scope of Claims] 1. A system that controls and performs management functions over a group of entities, wherein the entity interfaces with the group to control major information processing functions, and the entity further controls the system. A storage management module adapted to perform the management function by independently translating and executing predetermined management-related commands; comprising a storage device comprising area specification information defining groups of entities, and a kernel adapted to issue commands to all entities of said one group by issuing individual commands to appropriate management modules. system. 2. A storage management module that is a system that controls a group of entities and performs management functions, and that performs the management functions by independently translating and executing predetermined management-related commands; a storage device comprising area specification information defining said groups of entities; and a kernel adapted to issue instructions to all entities of said one group by issuing individual instructions to appropriate management modules. A system consisting of 3. A system for controlling and performing management functions over members of a computer network, wherein the members interface with the network to control major information processing functions, and the members further interface with the system. A storage management module capable of performing the management function by independently translating and executing predetermined management-related commands, and a group of members. a storage device comprising area specification information to define and a kernel adapted to issue commands to all members of said one group by issuing individual commands to appropriate management modules; A system in which a device is responsive to instructions having a filter procedure that selects entities in one or more particular regions. 4. A method for controlling and performing management functions over a group of entities, wherein the entity interfaces with the group to control primary information processing functions, and the entity further interfaces with the system to perform the management functions. wherein said system is adapted to perform said management functions, said system comprising: a management module adapted to perform said management functions by independently translating and executing predetermined management-related instructions; and said group of entities. and providing a kernel adapted to issue commands to said group of entities by issuing individual commands to appropriate management modules.