Extendible and portable network protocol based system management architecture

• US 6,104,868 A
• Filed: 12/12/1996
• Issued: 08/15/2000
• Est. Priority Date: 04/30/1996
• Status: Expired due to Term

• Current Assignee: RPX Corporation
• Original Assignee: PB Electronics, Inc. (NEC Corporation)
• Inventors: Peters, Daniel G., Corbett, Charles F., Flynn, Dennis R.
• Primary Examiner(s): Rinehart, Mark H.
• Assistant Examiner(s): Pierce, III, Ivan C.
• Application Number:
  US08/766,220
• Time in Patent Office: 1,342 Days
• Field of Search: 395/200.32, 395/200.46, 395/182.18, 395/185.1, 395/184.01, 395/673, 702/166, 706/10
• US Class Current: 709/202
• CPC Class Codes: H04L 41/0213 Standardised network management protocols, e.g. simple network management protocol [SNMP]
• CPC Class Codes: H04L 41/022 Multivendor or multi-standard integration

Abstract

A method and system server software architecture incorporates a series of software interfaces which allows porting and running of the particular ported software used for managing server components to operate in conjunction with other network operating systems/hardware platforms in addition to allowing for expanding the types of instrumentation components used on such systems which are uniquely constructed for managing newly attached server devices or functions with minimal additional programming effort.

Claims

1. A method of organizing a peer agent application for managing a number of different server systems which operate under the control of a number of different network operating systems, each server system comprising a plurality of components and at least one management information base (MIB) component for storing information describing a set of server specific variables and the hierarchy used in managing server hardware components, and a local agent component which communicates over a communications network using a standard request/response protocol for processing requests received over the network, the peer agent being organized in a modular fashion for facilitating porting to different network operating systems in addition to extensive component reuse and the method comprising the steps of:

(a) providing a first peer agent extension software module in the server system operative to communicate with the local agent component over a first programmable interface using a first type of standard protocol, the first software module including operating system specific routines for communicating with the network operating system controlling the server system;

(b) providing an independent abstraction application program interface in the server system for communicating through a second protocol which uses a small set of non-network operating system specific instrumentation commands and a defined set of control data structures;

(c) providing a second instrumentation module in the server system which operatively couples to the MIB component, the second instrumentation module including a number of server specific instrumentation components which operatively couple to the different server components and include mechanisms for directly managing hardware specific information variables described in the MIB component obtained from the server components of the server system; and

,

(d) incorporating into the first peer extension module and the second instrumentation module respectively, first and second mechanisms for communicating between the first and second modules over the abstraction interface, requests and responses from the second instrumentation module obtained from the instrumentation components managing the different server components using the instrumentation commands and control data structures coded for representing the requests and responses.

2. A method of operating a peer agent application for managing any one of a number of different server systems which operate under the control of any one of number of different types of network operating systems, each server system comprising a plurality of components and at least one management information base (MIB) component for storing information describing a set of server specific variables used in managing server hardware components, and a local extensible agent component which communicates over a communications network using a standard request/response protocol for processing requests and responses associated with server system operations, the peer agent being able to operate in conjunction with a plurality of different network operating systems, the method comprising the steps of:

(a) initially communicating the requests for the server system received from the network by the local agent to a first peer agent extension software module over a first programmable interface using a first type of standard protocol, the first software module including operating system specific functions for communicating with the network operating system controlling the server system;

(b) transferring the requests over an independent abstraction application program interface following processing by the first software module, the abstraction interface operating with a second protocol using a small set of non-network operating system specific instrumentation commands and a defined set of control data structures;

(c) receiving the requests through the independent abstraction application program interface by a second module which operatively couples to the MIB component, the second module including a number of server specific instrumentation components which operatively couple to the different server components and operate to directly manage hardware specific information variables described in the MIB component based on information obtain ed from the server components of the server system; and

,

(d) converting the specific instrumentation commands and applicable control data structures representing the requests by the second module into commands for execution by the instrumentation components managing the server component s to provide responses to the requests received by the second module.

3. The method of claim 2 wherein the method further includes the steps of

(e) transferring responses to the first module received from the instrumentation components managing the server components over the independent abstraction program interface by the second module using the commands and data structures of the second protocol representing the requests;

and,

(f) transferring the responses received from the second module to the local agent over the first programmable interface by the first module using the first type of protocol for subsequent transfer of request responses to the communications network by the local agent.

4. The method of claim 2 wherein each of the different network operating systems includes a similar type of interprocess communications facility for communicating between processes being executed by the network operating system and wherein the transmission of requests and request responses over the independent abstraction program interface by the first and second modules uses the common interprocess communications facility.

5. The method of claim 4 wherein the similar type of interprocess communications facility utilizes sockets.

6. The method of claim 2 wherein the standard response/request protocol is the SNMP protocol, the network operating system controlling the server system is a UNIX type system, the first programmable interface corresponds to a SMUX the first protocol corresponds to a SMUX protocol and the second module corresponds to a daemon process.

7. The method of claim 2 wherein the standard response/request protocol is the SNMP protocol, the network operating system controlling the server system is a Windows NT operating system, the first programmable interface is an SNMP application program interface and the second module corresponds to a service facility.

8. The method of claim 2 wherein the standard response/request protocol is the SNMP protocol, the network operating system controlling the server system is a Netware operating system, the first programmable interface corresponds to an SNMP application program interface and the second module is a Netware®

loadable module.

9. The method of claim 2 wherein step (d) further includes the step of transferring each command over a component interface to one of the instrumentation components associated with the variables specified in the request, the component interface being common to each of the instrumentation components for facilitating adding of new instrumentation components without having to make changes to other parts of the second module.

10. The method of claim 2 further including the steps of:

(e) generating unsolicited messages in the form of trap responses by the second module upon receiving information from the instrumentation components indicating occurrences of error events within the server hardware components;

(f) transferring the trap responses over the abstraction interface by the second module to the first module using a subset of the specific instrumentation commands and control data structures; and

,

(g) converting the trap responses by the first module into a form for transfer to the local agent over the first interface and then to the communications network by the local agent.

11. The method of claim 2 wherein the small set of non-network operating system specific instrumentation commands and the defined set of control data structures incorporate a plurality of client functions, common functions and server functions.

12. The method of claim 11 wherein the client functions include an instCallForComponent function, an instIssueCommandRequest function, an instreceive CommandResponse function, an instReceiveTrapIndication function, an InstDisconnectComponent function, an iabs_-- cmd_-- connect function and an iabs_-- accept_-- trap_-- connect function.

13. The method of claim 11 wherein the common functions include a send_-- pdu function and a get_-- pdu function.

14. The method of claim 11 wherein the server based functions include an iabs_-- trap_-- connect function, an iabs_-- accept_-- cmd_-- connect function and a create_-- port_-- file function.

15. The method of claim 11 wherein the client based functions, common functions and server based functions are stored in a library accessible by the first module and second module over the abstraction interface.

16. The method of claim 11 wherein the client based functions and common functions are included in the first module and the server based functions and common functions are included in the second module.

17. The method of claim 9 wherein the component interface includes initialization and termination tables, each table containing a number of entries and wherein the method further includes the steps of:

providing entries in each table to have values designating each of the number of instrumentation components being managed by the second module at startup and termination respectively, and,

reading out each of the values stored in the initialization and termination tables respectively for causing the designated instrumentation component to perform start up and termination operations specific to one of the server hardware components being managed by the designated instrumentation component.

18. The method of claim 9 wherein the MIB component is organized in a hierarchical tree structure comprising a plurality of tree nodes and leaf elements defining MIB variables and wherein the second module further includes a variable control table containing a number of processing function entry locations, the method further including the steps of

providing a number of interfaces within the component interface usable by each instrumentation component designated to be initialized by the second module during startup to populate the variable control table processing function locations with processing function entries identifying the functions to be used to process get and set requests for one or more MIB variables wherein one of the interfaces specifies a MIB variable and is used to populate the variable control table processing function location for the specified MIB variable and another interface specifies a MIB tree node and is used to populate the variable control table processing function locations for all of the accessible MIB variables defined under the specified MIB tree node;

and,

invoking the processing function specified in each variable control table processing function entry location by the second module in response to each command received over the component interface requesting access to a specific MIB variable corresponding to the control table processing function entry location for enabling the processing of the specific MIB variable by the designated instrumentation component.

19. The method of claim 9 wherein the second module further includes a driver component operatively coupled to one of the instrumentation components and invokes the instrumentation component through the component interface to process a request for a specific MIB variable, the method further including the steps of:

performing by the instrumentation component, an additional component specific validation of the MIB variable identified by the request; and

,

the instrumentation component as a function of the type of MIB variable identified by the request, performing one of the following steps;

generating an IOCTL type function call to the driver component to get or set data specified in the request from or into a hardware component of the server system;

or,

getting or setting the data from or into a memory resident data structure coupled to the instrumentation component;

or

generating the data from a constant value.

20. The method of claim 9 wherein the component interface further includes a number of specific interfaces for enabling an instrumentation component to allocate, initialize and queue poll list items within a poll list item queue containing a plurality of locations and wherein the method further includes the steps of:

initializing each of a number of entry locations for identifying the poll list item as a generic poll list item and an address pointer value identifying a component specific function to be performed when a poll list item has matured as defined by a poll list item time interval value.

21. The method of claim 19 wherein the component specific function is used for determining the time interval between polls for performing calculations relative to the hardware component being managed by the instrumentation component.

22. The method of claim 21 wherein the calculations performed as used for determining processing unit speed.

23. The method of claim 2 wherein the second software module further includes a timeout poll list queue containing a variable number of poll list item tables, each containing a plurality of entry locations for supporting a number of different types of polling activities using a common mechanism which is independent of network operating system type and the method further including the steps of:

initializing each of a number of poll list entry locations to specify a time interval, a duration interval and type of each polling activity;

ordering the poll list items in the queue according to next time of maturity; and

,

performing a select operation for performing polling in a timely manner independently of and without interference from requests received from the first module in accordance with the contents of the poll list entry locations.

24. The method of claim 2 wherein the second module further includes a trap table having a plurality of trap entry locations and wherein the method further includes the steps of:

initializing each of the entry locations to store a set of values pertaining to testing for an occurrence of different one of a number of trap conditions being supported by the second module, the set of values being used for identifying criteria to be used in establishing the occurrence of the different trap condition and an action to be taken when the second module has determined that the trap condition has occurred.

25. The method of claim 24 wherein the information values corresponding to the criteria to be used includes an interval field value defining a time polling interval at which the trap condition is to be tested, a duration value specifying the number of polls to be performed before polling is discontinued, a value to be used in testing for the trap condition, a condition value identifying the trap condition to be tested for establishing the occurrence of the trap and a test value that the polled variable is to be tested against.

26. The method of claim 25 wherein the information value identifying the test value can specify either (1) an snmpvar value corresponding to a MIB variable containing the value that the polled variable is to be tested against or (2) an encoded specific trap test value that the polled MIB variable is to be tested against.

27. The method of claim 24 wherein the information identifying the trap condition includes a trap number value corresponding to an assigned enterprise trap number for that trap condition and an enterprise value corresponding to a particular snmp variable of the enterprise for the trap.

28. The method of claim 24 wherein the information values corresponding to the action includes a true action value identifying the action to be performed and an action object value identifying the variable which is the object of the trap action to be performed when the trap condition has been satisfied.

29. The method of claim 24 wherein the trap table includes a number of entries allocated for defining user trap conditions which can be concurrently active and wherein the method further includes the steps of:

in response to receipt of each set command by the second module, setting values for the designated MIB control variables for causing the polling of the MIB variables by the second module at frequent intervals for testing the occurrence of a user defined trap condition without having to incur network overhead in performing polling remotely.

30. The method of claim 29 wherein the designated MIB control variables include a snmp object identifier value for a MIB variable to be tested for the user defined trap condition, a MIB user trap duration value defining a polling duration, a MIB user trap poll value defining a number of times polling is to take place and MIB user threshold limit values defining when specified actions are to be taken relative to the user defined trap condition.

31. The method of claim 30 wherein the designated MIB control variables further include:

MIB user trap action values defining the specific actions to be taken when one of the threshold limit values has been exceeded and MIB user trap objects values corresponding to user definable OIDs for identifying which MIB variables are to be polled locally to determine when the threshold limit is exceeded.

32. The method of claim 31 wherein the specific actions include:

sending a trap, setting a MIB variable to a specified value, incrementing a MIB variable and decrementing a MIB variable and wherein the designated control variables further include MIB user trap object values to be used when the specified action is to set a MIB variable to a value.

33. The method of claim 30 wherein setting the MIB user trap poll value to zero causes the second module to discontinue polling for the corresponding user defined trap condition.

34. The method of claim 2 wherein the second module further includes a variable control table containing a plurality of entries, each entry containing control information pertaining to a specific snmp MIB variable and a validate variable function value designating the function to be used for validating each variable contained in a PDU of a request received by the second module, the method further comprising the steps of:

determining if a snmp variable identifier of the variable contained in the PDU being processed is within a valid range;

if valid, obtaining the entry from the variable control table corresponding to the snmp variable; and

,

invoking a variable validation function for performing a validation operation on the snmp variable using control information contained in the variable control table entry.

35. The method of claim 34 wherein the variable control table further includes locations for storing dispatch entries, each dispatch entry including a process variable function value and the method further includes the steps of:

upon successfully completing the step of validation by the second module, invoking the processing function specified in the dispatch entry to process that specific MIB variable by the associated instrumentation component; and

,

performing a specific validation operation on the snmp variable by the processing function of the instrumentation component using information specific to the instrumentation component.

36. The method of claim 2 wherein the second module further includes a multilevel stubbing mechanism for providing stub level values for a snmp MIB variable and the method further including the steps of:

testing the stub level value associated with a snmp variable by the second module to determine if the snmp variable being processed is a stubbed variable; and

,

if stubbed, completing processing of the snmp variable by the second module in the manner defined by the stub level value.

37. The method of claim 36 wherein the stubbing level value can be coded for specifying no stubbing, generic stubbing, component stubbing or driver stubbing for completing the processing of the snmp variable.

38. The method of claim 37 wherein the server system further includes a database for storing snmp variable values, a first instrumentation component being operatively coupled to the server hardware component being managed through a driver component and, a second instrumentation component being operatively coupled to the database, the method further including the steps of:

in response to a stub level value specifying generic stubbing, the second module operates to complete the processing of a request snmp variable by accessing a variable value in the database through the second instrumentation component;

when the stub level value specifies component stubbing, the second module in lieu of completing the processing of the snmp variable as defined in the previous step, calls the instrumentation component which is operative to complete the processing of the request snmp variable by accessing a variable value in the database through the second instrumentation component; and

,

when the stub level value specifies driver stubbing, the instrumentation component in lieu of completing processing of the snmp variable as defined in the previous step, calls the driver component which is operative to complete variable processing by providing a variable value.

39. The method of claim 2 wherein the second module further includes a poll list item table containing a number of entry locations reserved for enabling monitoring of specific MIB variables and a circular buffer storage for storing data pertaining to the specific MIB variables being monitored, the method further including the steps of:

determining if data monitoring is active;

when active, initiating a data monitoring activity by setting a number of MIB control variables, the control variables including a value defining an snmp OID of the variable which is to be monitored, a value defining a time interval at which the monitored variable is to be polled, a value defining the number of polling operations to be performed on the monitored variable and a value defining the size of the circular buffer storage to be used for storing instances of the monitored variable during polling;

during operation, polling the monitored variable upon each expiration of the time interval for storing in the circular buffer storage, an instance of the monitored variable obtained as a result of polling; and

,

upon completing the number of polling operations, returning a string containing all of the instances of the monitored variable collected in the circular buffer storage in response to each get request specifying the monitored variable.

40. The method of claim 39 wherein the method further includes the step of:

inactivating monitoring of a snmp variable by setting to zero, the value defining the number of polling operations.

41. The method of claim 39 wherein the method further includes the step of restarting data monitoring for each last specified time interval, each time the second module is restarted when the value defining the number of polls is not zero.

42. The method of claim 34 wherein the method further includes the step of:

during startup, overriding entries in the variable control table by the instrumentation component for designating a specific validation function to be used in carrying out validation.

43. The method of claim 2 wherein one of the plurality of components is a portable database component including a database file containing a number of selected current variable values and the method further including the steps of:

encoding a MIB variable name, instance number, attributes and current value of a MIB variable instance in an individual database record in ASCII form by one of the instrumentation components; and

,

storing the individual database record in the database file by the instrumentation component.

44. The method of claim 43 further including the steps of:

maintaining the persistence of MIB variables by testing whether a variable which has been set is a persistent variable; and

,

if a persistent variable, building an ASCII database record by the instrumentation component;

appending the record to the end of the database file wherein the last record for a specific MIB variable identifier and instance determines a persistent value of the record; and

,

periodically sorting the records of the database file according to MIB variable identifier and instance to eliminate obsolete records while preserving current persistent values.

45. A peer agent system organized for managing a number of different server systems which operate under the control of a number of different network operating systems, each server system comprising a plurality of components and at least one management information base (MIB) component for storing information describing a set of server specific variables and the hierarchy used in managing server hardware components, and a local extendible agent component which communicates over a communications network using a standard request/response protocol for processing requests received over the network, the peer agent system being organized for facilitating porting to different network operating systems in addition to extensive component reuse and the peer agent system further comprising:

(a) a first peer agent extension software module operative to communicate with the local agent component over a first programmable interface using a first type of standard protocol, the first software module including operating system specific routines for communicating with the network operating system controlling the server system;

(b) an independent abstraction application program interface for communicating through a second protocol which uses a small set of non-network operating system specific instrumentation commands and a predetermined set of control data structures;

(c) a second instrumentation module which operatively couples to the MIB component, the second instrumentation module including a number of server specific instrumentation components which operatively couple to the different server components and include mechanisms for directly managing hardware specific information variables of the MIB component obtained from the server components of the server system; and

,

(d) the first peer extension module and the second instrumentation module respectively further including first and second mechanisms for communicating between the first and second modules over the abstraction interface, requests and responses from the second instrumentation module obtained from the instrumentation components managing the different server components using the instrumentation commands and control data structures coded for representing the requests and responses.

46. A peer agent system for managing any one of a number of different server systems which operate under the control of any one of number of different types of network operating systems, each server system comprising a plurality of hardware components and at least one management information base (MIB) component for storing information describing a set of server specific variables used in managing server hardware components, and a local extensible agent component which communicates over a communications network using a standard request/response protocol for processing requests and responses associated with server system operations, the peer agent system being able to operate in conjunction with a plurality of different network operating systems, the peer agent system further comprising:

(a) means for initially communicating the requests for the server system from the network received by the local agent to a first peer agent extension software module over a first programmable interface using a first type of standard protocol, the first software module including operating system specific functions for communicating with the network operating system controlling the server system;

(b) an abstraction interface operating with a second protocol using a small set of non-network operating system specific instrumentation commands and a predetermined set of control data structures;

(c) a second module which operatively couples to the MIB component, the second module including a number of server specific instrumentation components which operatively couple to the different server components and operate to directly manage hardware specific information variables described in the MIB component based on information obtained from the server components of the server system;

(d) means for transferring the requests over an independent abstraction application program interface following processing by the first module for receipt by the second module; and

,

(e) means included in the second module for converting the specific instrumentation commands and applicable control data structures representing the requests by the second module into commands for execution by the instrumentation components managing the server components to provide responses to the requests received by the second module.

47. The system of claim 46 wherein the system further includes:

(e) means included in the second module for transferring responses to the first module received from the instrumentation components managing the server components over the independent abstraction program interface using the commands and data structures of the second protocol representing the requests; and

,

(f) means included in the first module for transferring the responses received from the second module to the local agent over the first programmable interface by the first module using the first type of protocol for subsequent transfer of responses to the communications network by the local agent.

48. The system of claim 46 wherein each of the different network operating systems includes a like interprocess communications facility for communicating between those processes being executed by the network operating system and wherein the transmission of requests and responses over the independent abstraction program interface by the first and second modules uses the interprocess communications facility.

49. The system of claim 48 wherein the similar type of interprocess communications facility utilizes sockets and the responses include both request and unsolicited responses.

50. The system of claim 46 wherein the standard response/request protocol is the SNMP protocol, the network operating system controlling the server system is a UNIX type system, the first programmable interface corresponds to a SMUX, the first protocol corresponds to a SMUX protocol and the second module corresponds to a daemon process.

51. The system of claim 46 wherein the standard response/request protocol is the SNMP protocol, the network operating system controlling the server system is a Windows NT operating system, the first programmable interface is an SNMP application program interface and the second module is implemented by a service facility.

52. The system of claim 46 wherein the standard response/request protocol is the SNMP protocol, the network operating system controlling the server system is a Netware operating system, the first programmable interface corresponds to an SNMP application program interface and the second module is a Netware®

loadable module.

53. The system of claim 46 wherein the second module further includes a component interface for transferring each command to one of the instrumentation components associated with the variables specified in the request, the component interface being common to each of the instrumentation components for facilitating adding of new instrumentation components without having to make changes to other parts of the second module.

54. The system of claim 46 wherein the second module further includes:

(e) means for generating unsolicited messages in the form of trap responses by the second module upon receiving information from the instrumentation components indicating occurrences of error events within the server hardware components; and

,

(f) means for transferring the trap responses over the abstraction interface to the first module using a subset of the specific instrumentation commands and control data structures; and

the first module further includes;

(g) means for converting the trap responses by the first module into a form for transfer to the local agent over the first interface and then to the communications network by the local agent.

55. The system of claim 46 wherein the small set of non-network operating system specific instrumentation commands and the defined set of control data structures incorporate a plurality of client functions, common functions and server functions.

56. The system of claim 55 wherein the client functions include an instCallForComponent function, an instIssueCommandRequest function, an instReceive CommandResponse function, an instReceiveTrapIndication function, an instDisconnectComponent function, an iabs_-- cmd_-- connect function and an iabs_-- accept_-- trap_-- connect function.

57. The system of claim 55 wherein the common functions include a send_-- pdu function and a get_-- pdu function.

58. The system of claim 55 wherein the server based functions include an iabs_-- trap_-- connect function, an iabs_-- accept_-- cmd_-- connect function and a create_-- port_-- file function.

59. The system of claim 55 wherein the system further includes a library for storing the client based functions, common functions and server based functions which are accessible by the first module and second module over the abstraction interface.

60. The system of claim 55 wherein the first module further includes a set of mechanisms for executing both client based functions and common functions and the second module further includes a set of mechanisms for executing both server based functions and common functions.

61. The system of claim 53 wherein the component interface includes initialization and termination tables, each table containing a number of entries containing values designating each of the number of instrumentation components being managed by the second module at startup and termination respectively, and in response to reading out each of the values stored in the initialization and termination tables respectively, causing the designated instrumentation component to perform start up and termination operations specific to one of the server hardware components being managed by the designated instrumentation component.

62. The system of claim 53 wherein the MIB component is organized in a hiearchical tree structure comprising a plurality of tree nodes and leaf elements identifying MIB variables, the second module further including a variable control table containing a number of processing function locations populated with processing function entries, each entry identifying the function to be used to process get and set requests for a specific MIB variable and wherein the component interface further includes:

a number of interfaces usable by each instrumentation component designated to be initialized during startup to populate the variable control table processing function locations with processing function entries identifying the functions to be used to process get and set requests for a number of MIB variables, one of the interfaces specifying a MIB variable and being used by the instrumentation component to populate variable control table processing function locations for the specified MIB variable; and

,

another interface specifying a MIB tree node and being used by the instrumentation component to populate the variable control table processing function locations for all of the accessible MIB variables defined under the specified MIB tree node, the interfaces enabling the designated instrumentation component to process requested MIB variables.

63. The system of claim 53 wherein the component interface further includes a number of interfaces for enabling an instrumentation component to allocate, initialize and queue poll list items within a poll list item queue containing a plurality of locations, the second module being operative to initialize each of a number of entry locations for identifying the poll list item as a generic poll list item and an address pointer value identifying a component specific function to be performed when a poll list item has matured as defined by a poll list item time interval value.

64. The system of claim 63 wherein the component specific function is used for determining the time interval between polls for performing calculations relative to the hardware component being managed by the instrumentation component.

65. The system of claim 46 wherein the second module further includes a trap table having a plurality of trap entry locations, each of the entry locations initialized to store a set of values pertaining to testing for an occurrence of different one of a number of trap conditions being supported by the second module, the set of values being used for identifying criteria to be used in establishing the occurrence of the different trap condition and an action to be taken when the second module has determined that the trap condition has been satisfied.

66. The system of claim 65 wherein the information values corresponding to the criteria to be used includes an interval field value defining a time polling interval at which the trap condition is to be tested, a duration value specifying the number of polls to be performed before polling is discontinued, an snmpvar value corresponding to a variable identifier of a variable to be used in testing for the trap condition, a condition value identifying the trap condition to be tested for establishing the occurrence of the trap and a test value that the polled variable is to be tested against.

67. The system of claim 66 wherein the information values corresponding to the action includes a true action value identifying the action to be performed and an action object value identifying the variable which is the object of the trap action to be performed when the trap condition has been satisfied.

68. The system of claim 66 wherein the trap table includes a number of entries allocable for defining user trap conditions which can be concurrently active and wherein in response to receipt of each set command, the second module sets values for the designated MIB control variables for causing the polling of the MIB variables by the second module at frequent intervals for testing the occurrence of a user defined trap condition without having to incur network overhead in performing polling remotely.

69. The system of claim 68 wherein the designated MIB control variables include a snmp object identifier value for a MIB variable to be tested for the user defined trap condition, a MIB user trap duration value defining a polling duration, a MIB user trap poll value defining a number of times polling is to take place and MIB user trap threshold limits values for defining when specified actions are to be taken relative to the user defined trap condition.

70. The system of claim 69 wherein the designated MIB control variables further include:

MIB user trap action values defining the specific actions to be taken when one of the threshold limits values has been exceeded and MIB user trap objects values corresponding to user definable OIDs for identifying which MIB variables are to be polled locally to determine when the threshold limits values are exceeded.

71. The system of claim 70 wherein the specific actions defined by the MIB user trap action values include:

sending a trap, setting a MIB variable to a specified value, incrementing a MIB variable and decrementing a MIB variable and wherein the designated control variables further include MIB user trap object values to be used when the specified action is to set a MIB variable to a value.

72. The system of claim 46 wherein the second module further includes a variable control table containing a plurality of entries, each entry containing control information pertaining to a specific snmp MIB variable and a validate variable function value designating the function to be used for validating each variable contained in a PDU of a request received by the second module, the second module being operative to invoke the process variable function for determining if an snmp identifier of the variable contained in the PDU being processed is within a valid range;

if within the valid range, the second module being operative to obtain the entry from the variable control table corresponding to the snmp variable; and

then invoke a variable validation function for performing a validation operation on the snmp variable using control information contained in the variable control table entry.

73. The system of claim 71 wherein the variable control table further includes locations for storing a process variable function entries, the second module upon successfully completing the validation operation invokes the instrumentation component processing function specified in the process function entry to process that specific MIB variable and the instrumentation component upon being invoked, performs a specific validation operation on the snmp variable using information specific to the instrumentation component.

74. The system of claim 72 wherein the second module further includes a multilevel stubbing mechanism for providing stub level values for a number of snmp variables and wherein in response to a request variable, the second module tests the stub level value associated with the snmp variable to determine if the snmp variable being processed is a stubbed variable and if stubbed, the second module completes processing of the snmp variable in the manner specified by the stub level value.

75. The system of claim 74 wherein the stub level value can be coded for specifying no stubbing, generic stubbing, component stubbing or driver stubbing for completing the processing of the snmp variable.

76. The system of claim 75 wherein the server system further includes a database for storing snmp variable values, a first instrumentation component being operatively coupled to the server hardware component being managed through a driver component and, a second instrumentation component being operatively coupled to the database, the second module in response to a stub level value specifying generic stubbing being operative to complete the processing of a request snmp variable by accessing a variable value in the database through the second instrumentation component, when the stub level value specifies component stubbing, the second module is operative to call the instrumentation component to complete the processing of the requested snmp variable by accessing a variable value in the database through the second instrumentation component and when the stub level value specifies driver stubbing, the second module is operative to call the instrumentation component which calls the driver component to complete variable processing by providing a variable value.

77. The system of claim 46 wherein the second module further includes a poll list table contains a number of entry locations reserved for enabling monitoring of specific MIB variables and a circular buffer storage for storing data pertaining to the specific MIB variables being monitored, the second module being operative to determine if data monitoring is active;

when active, the second module initiating a data monitoring activity by setting a number of MIB control variables, the control variables including a value for defining an snmp OID of the variable which is to be monitored, a value defining a time interval at which the monitored variable is to be polled, a value defining the number of polling operations to be performed on the monitored variable and a value defining the size of the circular buffer storage to be used for storing instances of the monitored variable during polling;

during operation, the second module being operative to poll the monitored variable upon each expiration of the time interval for storing in the circular buffer storage, an instance of the monitored variable obtained as a result of polling; and

,

upon completing the number of polling operations, the second module being operative in response to each get request specifying the monitored variable, to return a string containing all of the instances of the monitored variable collected in the circular buffer storage.

78. The system of claim 77 wherein the second module each time upon being restarted is operative to restart data monitoring for each last specified time interval when the value defining the number of polls is not zero.

79. The system of claim 72 wherein the instrumentation component during startup, overrides entries in the variable control table for designating a specific validation function to be used in carrying out validation of snmp variables.

80. The system of claim 46 wherein one of the plurality of components is a portable database component which includes a database file containing a number of selected current variable values, one of the instrumentation components being coupled to the portable database component and operative to encode a MIB variable name, instance number, attributes in an individual database record in ASCII form for each persistent variable and store the individual database record in the database file.

81. The system of claim 80 wherein the instrumentation component is operative to maintain the persistence of MIB variables by testing whether a variable which has been set in response to a request is a persistent variable;

and,

if a persistent variable, the instrumentation component being operative to build an ASCII database record, append the record to the end of the database file wherein the last record for a specific MIB variable identifier and instance determines a persistent value of the record and the instrumentation component periodically sorting the records according to MIB variable identifier and instance to eliminate obsolete records while preserving current persistent variable values.