Dynamic selective distribution of events to server receivers

[0002] This invention relates to servers comprising computer processor systems, such as in a distributed or network systems environment, and, more particularly, to the management of the server and the distribution of events occurring with respect to the server.

[0003] The distributed or network environment of computer processor systems typically comprises a large number of individual nodes, such as workstations, PC's, terminals, host computers, and data storage components, which are tied together across a network. Also typically, the distributed or network systems comprise remotely located clients tied together to utilize common data storage components. The management of the data for efficient storage and retrieval is a critical element of the operation of the network.

[0004] One type of network is that employed to provide a backup and archive storage system for remotely located clients. Backup protects the client system data from a system failure or disk crash. The data is typically first moved to disk drives and then migrated to tape as the need for access to the data becomes less immediate. Archive storage is data that won't usually have a copy in the originating client system. It is archived so that the data may be made available if it is ever needed, for example, for legal requirements. Data is typically archived on tape.

[0005] Before the advent of modern data management systems, the client kept the only log of events related to the backup or archived data, and that log was only viewable from the client workstation. Should some kind of error situation arise, there was no visibility of the error to the data storage system administrators because the error log was also only on the client machine.

[0006] Another major function of the network storage server is space management. The data storage capacity of the client system is limited, and the network storage server may migrate the client user's live data to a server to free up space on the client system until a particular file is needed. At that point, the file is recalled from the server back to the client system.

[0007] One system designed to store and manage data for remotely located clients is called the ADSTAR Distributed Storage Manager (ADSM) of IBM. In ADSM, a central server is coupled to multiple client platforms and one or more administrators. The server provides archival, backup, retrieval, and other management functions for the server's clients. Should an error situation arise, that message may be provided to the server system administrator as an “event” or an “alert”. In server system parlance, an “event” is any message relating to the server system, including those messages, called “alerts”, which require attention.

[0008] The number of networked clients is high and the mix of clients tends to change often. Additionally, the clients tend to have wide varieties of application programs with differing data storage needs. Thus, the server needs to have flexibility to allow changes to be made within the system without disrupting the operation of the system. U.S. Pat. No. 5,621,892, Cook, addresses this problem by having registration procedures for the registration of devices and of expected alerts and configures a map between registered alerts and registered service providers for the distribution of events when they occur. The registration and mapping occurs at a standard initial set up for the system.

[0009] With the number of client nodes now sometimes reaching 1,000 or higher, and a map of 1,000 events with respect to several receivers for a single client consuming over 1,000 bytes of memory, the total logging map would consume over 1,000,000 bytes of memory alone. It would be helpful if the memory usage could be reduced.

[0010] The high number of client nodes prevents the administrator from monitoring all of the clients individually. Thus, in the system of Cook, all the registered alerts of particular types are sent to particular receivers as selected at the registration, and not all events are sent to the administrator. However, the administrator would prefer to select and tailor the events that are to be monitored, and tailor the logging and display of the selected events at various receivers, such as a server console, an activity log, a SNMP management program, or an enterprise system management application, such as Tivoli Enterprise Console (TEC). Additionally, the administrator would prefer not to wait until an initialization of the server to update the system logging.

[0011] Further, a limitation on the prior art is the inability to easily specifically map and remap each individual client node into the system logging map, so as to distribute only the desired specific types of events or from specific types of client nodes to specific receivers.

[0012] It is an object of the present invention to allow specific tailoring of the distribution of events by the administrator, and to allow updating of the mapping of the distribution of events to client nodes during operation of the distributed network system, without waiting for an initialization.

[0013] It is another object of the present invention to provide distribution of events while allowing efficient use of the server memory.

[0014] It is still another object of the present invention to allow ease of distributing specific types of events to specific receivers, or specific events for groups of client nodes to specific receivers.

[0015] Disclosed is a server having a plurality of clients coupled to the server at client nodes, and coupled to a plurality of receivers. Events, which may range from a successful completion message to a major error alert, may be generated relating to the client nodes. A method is disclosed for dynamically selectively distributing the client node events to particular ones of the receivers, in response to commands selectively enabling/disabling the client events to each receiver, while maintaining only the presently needed mapping in the server memory. The method comprises: upon opening a session of a client node, the selectively enabled events/receivers relating to the client node are determined from a database and placed in a client vector, preferably in memory. Upon the selective enabling/disabling occurring during the session of the client node, the determined selectively enabled events/receivers relating to the client node are dynamically updated, both in the database and, as needed, in the client vectors. Then, upon occurrence of an event relating to a client node, the event is distributed to ones of the receivers having been selectively enabled for the event in the determining and the dynamically updating steps. The client vectors may comprise two dimensional bit vectors identifying the enabled/disabled events/receivers for the client nodes.

[0016] Thus, the distribution of events may be continually updated during the operation of the server and the network system.

[0017] Additionally, the distribution rules are stored in a database, for example, on one or more disk drives, and only the distribution for the connected client nodes are stored in the client vector in the server memory.

[0018] In another aspect of the present invention, the step of storing rules in the database additionally comprises storing class vectors for selectively enabling classes of events to ones of the receivers. The determining step additionally comprises reading the database class vectors for selectively enabling/disabling the events for the receivers. Thus, the administrator may command distribution of classes of events, such as major errors, without identifying each of the events.

[0019] In still another aspect of the present invention, wild cards are used to collectively enable/disable client events for groups of clients to ones of the receivers. The determining and the updating steps thereupon additionally enable/disable the client events for the connected client nodes that are in the selected groups of clients. Thus, the administrator may command distribution of events relating to specific client nodes, such as major host systems to ones of the receivers.

[0020] For a fuller understanding of the present invention, reference should be made to the following detailed description taken in conjunction with the accompanying drawings.

[0021] FIG. 1 is a block diagrammatic representation of a server of the present invention with coupled client nodes and receivers;

[0022] FIG. 2 is a diagrammatic representation of the server subsystem of FIG. 1;

[0023] FIG. 3 is a representation of class vectors employed with the server of FIGS. 1 and 2;

[0024] FIG. 4 is a representation of event vectors that may be employed in the server of FIGS. 1 and 2;

[0025] FIG. 5 is a representation of a client vector that may be employed in the server of FIGS. 1 and 2 when a client is logged on to the server system;

[0026] FIG. 6 is a representation of a receiver list derived from the client vector table of FIG. 5 as employed in the server of FIGS. 1 and 2;

[0027] FIG. 7 is a flow chart representing an embodiment of the process of initializing class vectors employed with the server of FIGS. 1 and 2;

[0028] FIG. 8 is a flow chart representing an embodiment of the process of initializing client vectors employed with the server of FIGS. 1 and 2;

[0029] FIG. 9 is a flow chart representing an embodiment of the process of updating client vectors employed with the server of FIGS. 1 and 2;

[0030] FIG. 10 is a flow chart representing an embodiment of the process of handling a client event employed with the server of FIGS. 1 and 2;

[0031] FIG. 11 is a flow chart representing an embodiment of the process of initializing server event vectors employed with the server of FIGS. 1 and 2;

[0032] FIG. 12 is a flow chart representing an embodiment of the process of updating server vectors employed with the server of FIGS. 1 and 2;

[0033] FIG. 13 is a flow chart representing an embodiment of the process of handling a server event employed with the server of FIGS. 1 and 2; and

[0034] FIG. 14 is an illustration of a storage medium for storing computer readable program code.

[0035] This invention is described in preferred embodiments in the following description with reference to the Figures, in which like numbers represent the same or similar elements. While this invention is described in terms of the best mode for achieving this invention's objectives, it will be appreciated by those skilled in the art that variations may be accomplished in view of these teachings without deviating from the spirit or scope of the invention.

[0036] Referring to FIGS. 1 and 2, server 10 (often called a server subsystem) may comprise a network server, a data storage server, other type of server, or a combination. The hardware employed for the server 10 may comprise one or more general purpose computers 11, such as an IBM RS/6000, and attached devices such as a server console 12. The server is connected over a network 14 to a number of clients at client nodes 15. An example of a server subsystem 10 is called the ADSTAR Distributed Storage Manager (ADSM) of IBM, which is designed to store and manage data for remotely located clients. The server provides archival, backup, retrieval, and other storage management functions for the server's clients.

[0037] The operation of the subsystem is accomplished through a number of software components, including, for example, a session processor 20, an administrative processor 21, and a logging processor 22. The software components employ at least one database 24, which may comprise one or more hard disk drives, and the computer memory 25. The software may be supplied with the computer 11 configured as a complete subsystem or may be added at I/O 28.

[0038] The server 10 is managed by an administrator, for example, at the server console 12. Typically, the administrator employs a graphical user interface (GUI) or a command line to enter commands for managing the server system.

[0039] The session processor 20 manages all the “sessions” between the clients 15 and server 10. A “session” establishes a current connection between the client and the server and is characterized by a client (that has been registered with the server) logging on to the server. The administration processor 21 handles the commands from the administrator(s), for example at the server console 12.

[0040] Typically, the server 10 communicates with the users and its administrator by means of “events” or messages. As described above, with a large number of client nodes 15, the administrator likely prefers to view and consider only certain events exchanged by the server 10 with the clients and internally.

[0041] A data storage server, such as ADSM, must organize and track data stored by the subsystem, and must protect that data. Many of the events are therefore highly important to the administrator with respect to the operating state of the server system, many are needed to record activities of the server and to backup the server, and many are needed from an enterprise overview perspective. Hence, various “receivers” are typically provided to receive certain of the events. Still referring to FIGS. 1 and 2, examples of receivers which are part of the server subsystem include the server console 12, and an activity log 30, which may comprise part of the ADSM database also stored on a disk file for the computer processor 11. The activity log stores events and allows them to be queried later, for example, by querying the activity of a particular node, or a particular time period.

[0042] Examples of external receivers may include an Enterprise Application Manager 32, such as the Tivoli Enterprise Console, and an “alert” manager 34, such as a conventional Simple Network Management Protocol (SNMP) manager. “Alerts” are the more significant messages that may require urgent attention. Other external receivers depicted as receivers 35 in FIG. 2 include, for example, an external file 36, a “Netview” manager 37, a user exit 38 and “other receiver” 39, depicted in FIG. 1. The user exit 38 may comprise a user's own program which will provide a message at the user's administration console, or send an E-mail message to the user, or operate a pager of the user's administrator. The receivers are coupled to the server processor 11 by means of busses and I/O 40, and the communication of the events is under the control of the logging processor 22. Each receiver has therefore started a thread which continues to run, and passes along events based on current rules until the server terminates it.

[0043] Other server components depicted as components 41 in FIG. 1 include, for example, central scheduling 42, transaction manager 43, physical volume repository 44, and other server components 45, depicted in FIG. 2. The central scheduling component 42 manages clients' schedules, that is, coordinating the timing for both client and server processes. The transaction manager 43 allows grouping of transactions for later rollback or commit, e.g., back up batching of files to the data storage managed by the server runs out of space and the transaction manager rolls back the transaction (cancel and do later). Commit is when the job completes successfully and comprises doing all the updates to the server database. The physical volume repository (PVR) 44 is a layer that manages the drives of the data storage managed by the server, and provides high level I/O code that is platform specific for the drives, one level up from the device drivers. The other server components 45 comprise components employed for other aspects of the server 10. Other types of network or distributed system servers may have some added or different specific components.

[0044] The interaction between each client node 15 and the server 10 results in the occurrence of large numbers of events. Before describing the operation of the present invention, a few of the numerous types of events will be discussed:

[0045] a) “Command Completed” is informational—lets the initiator know that the requested command has completed successfully.

[0046] b) “Database Initiation Failed” is an error indication—for example, because “Sufficient Memory is Not Available”. The server administrator may wish to see this event so that the backup or archive storage may be allocated differently. The event may be stored in the activity log. The enterprise manager may wish to note the event.

[0047] c) “Session No. X Started for Node Y (client)” is informational. The administrator may want to see this event on the console, but the enterprise manager may not.

[0048] d) “Session No. X for Node Y Refused”, for example because an “Invalid Password Submitted”, is a warning, which the enterprise manager may want to know, for example, to track whether it is repeated without being cured.

[0049] e) “Disk Volume X Varied On Line” or “Disk Volume X Varied Off Line” are informational indicating that the disk is put online or is taken offline in the server and may be important to the administrator as well as to users whose data is involved.

[0050] f) “Insufficient No. of Mount Points Available in Device Class X”, meaning that in a tape or optical library that not as many drives as defined are in fact available, is an error. The administrator and requesting user may need to know this information, as may the enterprise manager.

[0051] g) “Inconsistency Found In LVM (Logical Volume Manager) Data Page—Partial Write Detected” would be a severe error situation of importance to the administrator, user, etc.

[0052] h) “Early Product Version Expired—Server Halting” is also a severe error situation, for example, occurring with a prototype which was expected to be updated to a production version. The situation would be of most importance to the administrator and the enterprise manager.

[0053] The above examples are called “server” events because they comprise messages originating in the server 10, most of which relate only to the interaction of the server components. Other events may originate in the client and are called “client” events. Although many client events result from the interaction of the server and the client, only a few are transmitted to the server, so that the network 14 bandwidth is not wasted on messages that are not of interest to the administrator. An example of a message not transmitted to the server, and therefore not an “event”, is that “File XYZ was backed up successfully”. An example of an “event” which is transmitted to the server is “Access Denied (e.g., no authority)”, a warning. The administrator may have an interest if it is a continuing problem.

[0054] It would be advantageous for the administrator to select easily between the various classes of events rather than to consider each event individually. Thus, in accordance with the present invention, as illustrated in FIG. 3, an embodiment of a two dimensional class vector 50, comprising a series of class bit vectors, which may be “0” or “1”, is shown which identify the severity class for each of a number of events. Four severity classes 51 are shown, and are the same as discussed above, including “severe”, “error”, “warning” and “information”. As a specific embodiment, the classes may be designated, respectively, as “S”, “E”, “W” and “I”. The vector 50 is located in server memory 25 and is loaded from the database 24 or from the I/O 28 at initialization, presetting the classes. As an example, ADSM may allow 1,000 client events and 10,000 server events, and all may be included in table 50, only 20 of which are shown in FIG. 3. The class vectors do not change unless maintenance is applied to the server, either adding new events or changing severities.

[0055] In accordance with the present invention, the administrator may select an entire class of events for display at the console 12 or for logging in an activity log 30, etc., without individually providing an event distribution instruction for each of the thousands of events. Further, space is saved by having only a small class map 50 of events, rather than a map of each event and each client. Additionally, in accordance with the present invention, as clients are logged on to the server 10, their events become active, and are included in the class vector table 50 without requiring a special initialization. Additionally, the class designation commands are stored in the database 24, so that if future clients are registered with the server system, their events of the designated class are included without special initialization.

[0056] FIG. 4 is an embodiment of a two dimensional event bit vector 54, in accordance with the present invention, representing event/receiver vectors of the server 10 of FIGS. 1 and 2, and may be duplicated in a two dimensional client vector for each of the client nodes. Thus, a client event bit vector identifies each event relating to the respective client, and the server bit vectors 50 identify all server events. In accordance with the present invention, the event vector 54 comprises a “1” bit for each of the receivers 55 to which the event is to be distributed, and a “0” bit for each receiver 55 where the event will not be distributed.

[0057] Hereinafter, the term “events/receivers” has the same meaning as “one to many events mapped to one to many receivers”, where the phrase “one to many” is the accepted term of those of skill in the art to mean “one or more”.

[0058] The event vector 54 may, in accordance with the present invention, be updated by the administrator without stopping and reinitializing the server. The initial server table from which the vector 54 is derived will have been stored in the database 24 together with specific commands, and the vector brought into memory. In the example illustrated by the bits in vector 54, all events are initially enabled by default for the console 12 and the activity log 30 of FIGS. 1 and 2, and disabled for all other receivers. Combining the vector 50 of FIG. 3 with vector 54, it can be seen that all events that are classified as severe and error have been enabled for “Tivoli” receiver 32. It can also be seen that events 3, 6, and 9 have been independently disabled for the console 12. Thus, the administrator may selectively enable or disable any event or class of events. The updated rules are stored in the database 24.

[0059] An embodiment of a specific two dimensional client event vector 60 is illustrated in FIG. 5, again only illustrating an exemplary 20 of the thousands of possible events. In accordance with the present invention, in order to save memory, while allowing maximum flexibility, the client event vectors are generated only when the associated client node is active and logged on to the server. Since very large numbers of clients may be associated with the server, it is likely that only a percentage, sometimes small, of the clients are logged on at any one time.

[0060] As with respect to the server event vectors, the client event vector 60 represents event/receiver vectors that identify each event relating to the respective client. The client event vector 60 is provided in server memory 25. In accordance with the present invention, the event vector 60 comprises a two dimensional set of bit vectors built specifically for that client, having a “1” bit for each of the receivers 61 to which the event is to be distributed, and a “0” bit for each of the receivers 61 where the event will not be distributed. Upon a client logging on to the server, the client event vector 60 is generated by session processor 20 of FIGS. 1 and 2 from the table in database 24 based on a set of rules, which may include the client event vector 54 of FIG. 4, ORed with the class vector 50 of FIG. 3, together with commands which identify the specific client node. Thus, in the example of vector 60 in FIG. 5, the user exit has been enabled for events 7, 10, and 14 in accordance with specific commands. If the client event vector has been updated after initialization, or if new commands (rules) added that relate to the specific client, those updates will be reflected in the vector 60 based on updates stored in the database 24.

[0061] In accordance with the present invention, should the administrator wish to alter the distribution of any event or events which include the specific client, both the vector 60 and the stored rules will be updated by the administrative processor 21 of FIGS. 1 and 2.

[0062] FIG. 6 illustrates a single dimension receiver list bit vector 65 generated from the table 60 in FIG. 5. As the specific example, the bit vector 65 is event “7” from table 60. This vector is passed, together with the event, to logging processor 22 in FIGS. 1 and 2 for distribution. From this vector, and referring to the names of the receivers 61 in the table 60, the logging processor will distribute the event to the console 12, the activity log 30, and the user exit 38. The logging processor puts the event on the queue for each of the receivers, and the threads for the receivers each handle the event with the respective processes.

[0063] Thus, in accordance with the present invention, and referring to FIGS. 1-6, client node events are dynamically selectively distributed to particular ones of the receivers, in response to commands selectively enabling/disabling the client events to each receiver, while maintaining only the presently needed mapping in the server memory 25. Upon opening a session of a client node 15, the previously selectively enabled events/receivers relating to the client node are determined by session processor 20 from the class and event vectors of the server and placed in the client vector 60 in memory 25. Upon selective enabling/disabling occurring of an event/receiver during the session of the client node, the vector of determined selectively enabled events/receivers relating to the client node is dynamically updated by administrative processor 21, both in the vectors in the database 24 and in the client vector 60. Then, upon occurrence of an event relating to a client node, the event is distributed by logging processor 22 to ones of the receivers having been selectively enabled for the event in the determining and the dynamically updating steps. The event bit vector thus identifies the updated enabled/disabled events/receivers relating to the client nodes.

[0064] The commands by the administrator updating the rules and vectors, may be specific to a node, may be specific to a severity class, or, in accordance with the invention, may be wild cards. Wild cards are commands employing special characters to identify groups of client nodes, such as “*”, and are employed to collectively enable/disable client events relating to groups of clients to ones of the receivers. An example is “DD*”, which relates to all nodes beginning with “DD”. The determining and the updating steps thereupon additionally enable/disable the client events for the connected client nodes that are in the selected groups of clients. Thus, the administrator may command distribution of events relating to specific types or groups of client nodes, such as major host systems, to ones of the receivers. A special wild card is “ALL” which applies the command to all receivers and events.

[0065] Also, in accordance with the present invention, by updating the rules in database 24, any future instances encompassed by the wild card are also included. Thus, in the case of a wild card that applies to major host systems, the addition of another major host system as a client node 15, includes the added major host system in the event distribution indicated by the wild card.

[0066] Examples of administrator commands include:

[0067] a) “enable event snmp all node=jo*” is a wild card command enabling an event to the SNMP manager receiver 34 for all nodes which begin with “jo”;

[0068] b) “enable event tivoli severe” is a class command enabling severe events to the Tivoli receiver 32; and

[0069] c) “enable event console ANR4234 node=DD043” is a specific command enabling event no. ANR4234 at node DD043 to the console 12.

[0070] The bit vector tables of FIGS. 3, 4 and 5 are each generated by associated rules tables in the database 24. As an example, the client table rules include the following fields:

[0071] DATE/TIME

[0072] UNIQUE KEY

[0073] NODE NAME

[0074] RECEIVER

[0075] EVENT

[0076] OPERATION

[0077] The server table is very similar except that there is no node name field.

[0078] Each delimited field of the commands goes in a separate row of the database, except that wild cards are not expanded in the table. They get expanded at the time the rules are applied to generate the bit vectors.

[0079] The date/time and unique keys, above, are used to ensure that rules are applied in the same order in which they were entered by the administrator. In this manner, whenever a new rule is added via issuance of an enable/disable command, a separate thread is initiated to delete any existing rules that are rendered redundant by the new rule. For example, if the administrator issues “enable event console all”, any previous enables or disables for the console would be eliminated from the server rules table.

[0080] The method of the present invention is preferably implemented by means of computer readable program code which causes a computer processor 11, to perform the desired steps. Referring to FIG. 14, the computer readable program code may be provided in the form of an article of manufacture 29 comprising a computer readable medium having the computer readable program code embodied therein. Examples of such articles of manufacture include floppy disks, optical disks (e.g., CDROMs), or magnetic tape, read at I/O 28 in FIG. 1. The computer readable program code may also be delivered to the server 10 in the form of a communication transmission received from the network via a client node 15 or at I/O 28 and stored in a disk drive.

[0081] The program code causes the computer to operate as specialized “processors” which utilize components of the computer to perform the programmed functions. In the embodiment illustrated in FIGS. 1-6, these processors include, for example, administrative processor 21, session processor 20, and logging processor 22. The computer processor 11 of the server 10 may alternatively be operated in differing manners as different sets of “processors” or singly, without departing from the scope of the present invention.

[0082] FIG. 7 is a flow chart representing an embodiment of the process of initializing the class vectors 50 of FIG. 3 employed with the server of FIGS. 1 and 2. Step 70 is conducted separately in advance by a developer who creates an event that is desired, and assigns it a severity. In step 71, the server code is compiled which builds a header file and maps events to their severities. Step 72 comprises initializing the server 10 of FIG. 1, setting the server and client class vectors to zero to form a base from which the specific settings may be made. This assures that only one class vector will be provided for each event. The mapped events are read by the administrative processor 21 to set the event bits in table 50 of FIG. 3 of the appropriate severity class to “1”. In step 73, the client and server class vectors are then stored in the memory 25 and in the database 24. Subsequently, as will be explained, the class vectors are utilized for client event vector generation.

[0083] FIG. 8 is a flow chart representing an embodiment of the process of initializing client vectors, such as illustrated in table 60 of FIG. 5. In step 80, the client 15 starts the session with the server, such as by logging on to the server 10. In step 81, the session processor 20 initializes the client event vectors to defaults for receivers and, in step 82, reads all vectors that apply to the client node. In step 83, the session processor applies the vectors, e.g., by combining the server vectors, the class vectors, any client-specific rules commands, including any wild cards, to establish the table, and the client event vector 60, which enable/disable event/receiver bit vectors for the particular client node. The client event two dimensional vector is thus up to date just by logging on without requiring reregistration.

[0084] FIG. 9 is a flow chart representing an embodiment of the process of updating client event vectors while the client is logged on. In step 85, the administrator issues an enable or disable event command. The command may comprise a specific client event command, a class command, or a wild card. Administrative processor 21 determines from the session processor, in step 86, whether the applicable client is logged on to the server 10. If the client is logged on, the administrative processor dynamically updates the client table event bit vector (vector 60 of FIG. 5) in step 87, and, in step 88, stores the new rule in the database 24. If, in step 86, it was determined that the client was not logged on, the table 60 for the client does not exist, and only step 88 is performed, storing the new rule in the database and updating the appropriate server or class vector in memory 25 as necessary.

[0085] The occurrence of an event that relates to a client node is illustrated in FIG. 10. In step 90, the client table, such as vector table 60 in FIG. 5, is accessed, and, in step 91, the event vector of table 60 is accessed to form the receiver list bit vector 65 in FIG. 6. In step 92, this vector is passed, together with the event, to logging processor 22. From this vector, the logging processor distributes the event to receivers in accordance with the event vector.

[0086] Thus, the method of the present invention dynamically selectively distributes the client node events to particular ones of the receivers, in response to commands selectively enabling/disabling the client events to each receiver, while maintaining only the presently needed mapping in the server memory. The commands may be provided before the client node is logged onto the server, or after, and the client event vectors are dynamically updated and the events appropriately distributed.

[0087] Server vectors not related to any client nodes are discussed with respect to FIGS. 11-13. An embodiment of initializing the server event vectors is illustrated in FIG. 11. Server initialization begins at step 100. In step 101, the server event vectors are initialized with defaults for all events/receivers. The database rules for the server are read in step 103, and, in step 104, the rules are applied to modify the server event bit vectors, such as two dimensional vector 54 shown in FIG. 4.

[0088] The server vector may then be dynamically updated as the administrator makes changes to the logging requirements, as illustrated in FIG. 12. In step 110, the administrator issues enable or disable event command, which may be a command for a specific node and event, a class command, or a wild card. In step 111, the server event bit vector is updated in memory 25, and, in step 112, the new command rules are stored in database 24.

[0089] A server event is then illustrated in FIG. 13. Upon the occurrence of the event, the event is sent to logging processor 22, and the server vector 54 of FIG. 4 (in shared memory) is accessed by the logging processor in step 115. In step 116, the logging processor tests the appropriate bits. In step 117, the logging processor distributes the event to receivers in accordance with the tested bits.

[0090] Again, the vectors are dynamically updated without requiring that the server 10 be stopped and reinitialized.

[0091] While the preferred embodiments of the present invention have been illustrated in detail, it should be apparent that modifications and adaptations to those embodiments may occur to one skilled in the art without departing from the scope of the present invention as set forth in the following claims.