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.

Description:
This patent application claims the benefit of Provisional Application Ser. No. 60/017,072 filed on Apr. 30, 1996. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of Use 
     The present invention relates to network management and, more particularly, to computer system management software which manages computer component operation and performance. 
     2. Prior Art 
     In recent years, attention has shifted from the connectivity and interoperability of heterogeneous networks to network management. That is, great attention is being given to keeping track of the devices on a network, checking on the network&#39;s performance and diagnosing and correcting problems. Since the late 1980&#39;s, the Simple Network Management Protocol (SNMP) has become widely accepted as the protocol of choice for managing TCP/IP based systems. SNMP lets network managers monitor and control network devices and the systems that have SNMP agents, independent of the network topology or complexity. 
     Implicit in the SNMP model is a collection of network management stations and network elements. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, terminal servers and the like which have management agents responsible for performing the network management functions requested by the network management stations. The SNMP model is used to communicate management information between the network management stations and the agents in the network elements. 
     Also, the SNMP model is designed to minimize the number and complexity of management functions realized by the management agent itself which provides the significant advantage of reducing development costs for management agent software necessary to support the protocol. SNMP models all management agent functions as alterations/changes or inspections of variables. Thus, a peer process which implements the SNMP model and supports SNMP application entities present on a logically remote host interacts with the particular management agent resident on the network element in order to retrieve (get) or alter (set) variables. 
     This mode of operation reduces the number of essential management functions realized by the management agent down to two functions, one function to assign a value to a specified configuration or other parameter and another function to retrieve such a value. The monitoring of network state at any significant level of detail is accomplished primarily by polling for particular information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) are used to guide the timing and focus of such polling. 
     Management agents have been designed to monitor a greater number of diverse computer system devices having different communication requirements which vary from vendor to vendor. To maintain design flexibility in accommodating vendor requirements, one approach has been to provide an application program interface (API) at the SNMP agent level for implementing peer software or a software extension which communicates with an SNMP agent. 
     One such agent extension facility is described in a document published by The Santa Cruz Operation, Inc. entitled SCO® TCP/IP SMUX Peer API Programmer&#39;s Guide&#34; Document version: 1.0.0b. In this implementation, an SNMP Multiplexing protocol (SMUX) is used as the mechanism for communicating between an SNMP agent and one or more user daemon processes called SMUX peers. Each peer in turn communicates through a proprietary protocol to access information from multi-port serial board software. 
     While the above approach has provided increased flexibility at a specific level of operation, the peer software still remains operating system specific, thus reducing the ease of porting such software to work in conjunction with other network operating systems. Additionally, in order to extend the utilization of such software in managing other types of computer devices, it still is necessary to rewrite such peer software in order to provide support for such managed devices. Such programming effort can involve substantial resources and require a certain level of expertise to carry out. 
     Accordingly, it is a primary object of the present invention to provide a system and method characterized by an architecture which can be easily ported enabling such ported software to run on other operating systems and easily extended to operate in conjunction with new computer devices or instrumentalities. 
     BRIEF SUMMARY OF THE INVENTION 
     The above objects and advantages of the present invention are achieved in a preferred embodiment of a network management architecture for inclusion in any one of a number of different types of server and network operating systems. The network management architecture includes a plurality of modules organized to communicate over a plurality of different interfaces in a manner which maximizes reuse, ease of porting and device expansion. In an embodiment for a UNIX type network operating system, a first module daemon process termed a peer agent is designed to communicate both with a local extendible SNMP agent over an operating system specific interface (e.g. SMUX) utilizing a first type of standard protocol and with a second instrumentation module daemon process over an independent application programmable interface (IABS) using a second type of protocol. The second type of protocol is designed to use a small set of non-operating system specific instrumentation commands and a unique set of control data structures implemented in one embodiment through an instrumentation abstraction (IABS) library facility. The use of an abstraction interface allows a user to develop new client software without requiring any knowledge of implementation details relating to the mechanisms or specific data structures being used in managing the actual server system instrumentation data and server hardware components. 
     In the UNIX type network operating system, the peer agent implemented as a daemon (client) process performs the function of managing the hardware specific information on configured server systems at the local SNMP level. The instrumentation module daemon (server) process in turn manages a number of server specific instrumentation component modules configured in the server system which are responsible for directly managing the hardware specific information on the server system at a common application level interface which is below the local SNMP level. 
     By confining the peer agent to operate within the confines of the above two interfaces, the peer agent is able to be partitioned into operating specific and generic module components for performing operating system functions and generic functions as required for operating in conjunction with several different types of network operating systems. Also, the establishment of the two interfaces reduces the number of network operating system specific components contained in the peer agent down to those for performing a few functions. This greatly facilitated the ease of porting the peer agent to operate in conjunction with such network operating systems. Also, the creation of a common application level interface to perform local monitoring of MIB variables, SNMP trap management and other non-driver instrumentation tasks minimized and reduces the complexity of client components which operatively couple to the second type of interface. The instrumentation daemon component and instrumentation components collectively form an abstraction instrumentation module. 
     In the preferred embodiment, the instrumentation component communicates with the number of instrumentation specific component modules over a third low level interface called a component interface. Each component module is specifically designed to communicate with a particular server hardware component and manage a particular set of MIB variables associated therewith. The component interface is organized for instrumentation expansion which is able to provide instant SNMP agent support for new instrumentation components simply by plugging the particular instrumentation component into the system and adding to the MIB, a subset of objects associated with the instrumentation component in a standard manner. The component interface by distributing the above discussed functionality between the abstraction component and the instrumentation components allows for local and remote access. 
     In operation, the instrumentation daemon component process listens and sends on an available TCP network port to exchange units of information known as Protocol Data Units (PDUs) with a peer agent client process and a local console facility client process. The instrumentation daemon process listens for and responds to IABS interface requests received from its clients to get or set server database variables contained in a conceptual database and described with a hierarchical collection of Object Identifiers (OID) in a file called a Management Information Base (MIB). The actual implementation of this conceptual database stores variable values in hardware registers, disk resident files and memory resident data structures. 
     In the preferred embodiment, the client processes communicate with the instrumentation abstraction component through client API functions contained in the abstraction library facility which in turn invoke particular socket based functions for transferring appropriately constructed protocol data structures (PDUs) containing the required data and commands through the sockets mechanism of the particular network operating system to the abstraction component. The socket based functions create the appropriate control protocol data structures and format the data contained therein according to predefined definitions in addition to sending them across the IABS interface via the network operating system sockets mechanism. Also, the standard sockets library of the particular network operating system has been extended to include functions for communicating the control protocol data unit structures through the network operating system&#39;s sockets mechanism. 
     Through the use of instrumentation commands, associated library function modules and unique set of control protocol data unit structures, the system provides a simplified interface in which the complexities of the network operating system mechanism remains encapsulated to within a few specific components. As indicated above, this facilitates the development of new client applications. 
     Other features of the architecture of the present invention include the following. The abstraction component includes a mechanism for enabling user defined local polling of SNMP MID variables. Since such polling can be done locally, this eliminates the need to incur network overhead. It also enables the data collected from such polling to be retrieved in bulk via a single SNMP request. Additionally, the abstraction component includes a trap table mechanism which provides a user with the capability of creating user definable SNMP traps. Further, the abstraction component includes a centralized mechanism for enabling the multi-level isolation, test and simulation of functionality through the use of stubbed values. 
     The above objects and advantages of the present invention will be better understood from the following description when taken in conjunction with the accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a functional block diagram of a system which includes a server system which incorporates the architecture and software components of the present invention. 
     FIGS. 2a through 2c are software layer diagrams illustrating the utilization of the present invention in different network operating system environments. 
     FIG. 3a shows in greater detail, the different component modules of the instrumentation abstraction component of FIG. 1. 
     FIG. 3b shows in greater detail, the different component modules of the instrumentation components of FIG. 1. 
     FIGS. 4a through 4c illustrate the different data structures utilized by the instrumentation abstraction component of FIG. 1. 
     FIGS. 5a and 5b illustrates the overall processing flow of requests through the architecture of the present invention. 
     FIGS. 6a through 6c illustrate in greater detail, the SNMP command procedural flow of FIG. 5. 
     FIGS. 7a through 7g illustrate the operational flow of the different modules of the instrumentation abstraction component of FIG. 1. 
     FIGS. 8a through 8c illustrate the operational flow of the different modules of the instrumentation component of FIG. 1. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1 shows a typical network configuration in which a remote system 20 interconnects via a internetwork 24 to a server system 30 as indicated. The remote system includes a remote network management workstation 22 containing standard SNMP network management software such as ISM Manager software developed by Bull HN Information Systems Inc., NMS software developed by Novell Inc. or SMS Windows NT software developed by Microsoft Inc. The workstation 22 during the execution of simple network management protocol (SNMP) client software sends requests to and receives responses from server system 30 through internetwork 24 via the TCP/IP protocol suite. 
     As discussed above, SNMP is a well known asynchronous request/response protocol used in systems management applications which provides the following four operations: (1) get which is used to retrieve specific management information; (2) get-next which is used to retrieve via traversal, management information; (3) set which is used to manipulate management information; and, (4) trap which is used to report extraordinary events. For more information regarding the SNMP protocol, reference may be made to the Internet standard RFC1157 published by the Internet Activities Board or to the text entitled &#34;The Simple Book An Introduction to Management of TCP/IP based Internets&#34; by Marshall T. Rose, published by Prentice Hall, copyright 1991. 
     As illustrated in FIG. 1, server system 30 includes an extendible SNMP agent component 31 which operatively couples to network 24 and exchanges network management information with workstation 22. The SNMP agent component 31 operatively couples to peer agent extension component 32a through a network operating system specific interface. The peer agent extension component 32a (client) operatively couples to an instrumentation abstraction (IABS) library facility 37 and to the network operating system&#39;s sockets mechanism for communicating with a module 33. As indicated, module 33 includes instrumentation abstraction (IABS) component 34 and instrumentation components 34a and 34b. In a similar manner, a second client component which corresponds to local console facility 32b operatively couples to the IABS interface. The facility 32b utilizes a graphical interface provided by a server system console 42. That is, a user communicates with the client facility 32b through the console keyboard 42a and mouse device 42b of server system 30. While FIG. 1 represents the graphical interface as being associated with the server hardware 36, such a graphical interface may be provided by another server system which is connected remotely via a TCP/IP sockets facility. In fact, this is the case when server system 30 is being operated with a NetWare SNMP Services Interface. 
     As shown, the IABS abstraction component 34 operatively couples to an instrumentation component interface for communicating with instrumentation components 34a and 34b. The instrumentation component 34a communicates with driver component 35a. The driver component 35a in turn communicates with the different hardware components of server hardware platform 36. The similarly constructed database instrumentation component 34b communicates with a file system 35b which provides access to an internal MIB database file described herein. While only two instrumentation components are shown in FIG. 1, it will be appreciated that additional components may be added as indicated by the series of dots. 
     In the preferred embodiment, the agent component 31 may be considered conventional in design and may take the form of any one of three standard extendible agents, such as the UNIX type SNMP agent described in the above mentioned publication of The Santa Cruz Operation, Inc. entitled &#34;SCO® TCP/IP SMUX Peer API Programmer&#39;s Guide&#34; Document version: 1.0.0b dated Feb. 21, 1993, the Windows NT SNMP agent described in the publication entitled &#34;Microsoft Windows/NT SNMP Programmer&#39;s Reference&#34; by Microsoft Corporation dated Jul. 22, 1992 or the NetWare SNMP agent described in the publication entitled NetWare SNMP Services Interface Developer&#39;s Guide&#34; by Novell Inc., May 1993 Edition. 
     It will also be noted that the agent component 31 operatively couples to the MIB module 39a which describes various &#34;objects&#34; in a tree structure. This actual coupling is operating system dependent. Under SCO UNIX operating system, support for MIB-II defined objects are hard coded into the SNMP extendible agent. While under the Microsoft Windows NT operating system the same support is provided in a Microsoft supplied peer agent extension. The MIB-II is described in the document entitled &#34;Management Information Base for Network Management of TCP/IP based internets: MIB-II&#34;, RFC 1213, published on March, 1991. The MIB database 39a contains descriptions of those objects which are expected to be implemented by managed nodes running the TCP/IP Internet protocol suite. For example, such objects include objects for the managed node itself, network attachments, the Internet Protocol, the Transmission Control Protocol, the User Datagram Protocol, the Simple Network Management Protocol, etc. 
     As discussed, the agent component 31 communicates over a first type of interface which is an operating system specific interface. As indicated in FIG. 1, this interface is different for each different network operating system. For example, for the UNIX type of operating system marketed by Santa Cruz Operations, Inc., the specific interface is socket based (i.e. TCP/IP sockets). The socket based interface of the server system of the preferred embodiment, uses a first type of protocol corresponding to a SNMP Multiplexing (SMUX) protocol designed for use with a user process known as a SMUX peer which exports a MIB module by initiating a SMUX association to; the agent component 31, registering itself and later processes management operations for objects contained in the MIB module 39a. The interfaces used with NetWare and Windows NT SNMP agents are structured differently and require extension agents have registered callback functions. 
     SMUX Protocol 
     The SMUX protocol involves the following simple sequence of operations. The SNMP agent component 31 listens for incoming connections. When started, the SMUX peer initiates a socket connection. Upon establishing a socket connection, the SMUX peer issues an OpenPDU request to initialize the SMUX association. If the agent component 31 declines the association, the SMUX peer issues a closePDU response and closes the connection. If the agent component 31 accepts the association, no response is issued. 
     For each subtree defined in a MIB module that the SMUX peer wishes to register or unregister, the SMUX peer issues a RReqPDU request. This causes the agent component 31 to respond by issuing a RRspPDU response in the same order as the RReqPDU request was received. When the SMUX peer wishes to issue a trap, it issues an SNMP Trap-PDU request. When the agent component 31 receives the trap request, it transmits to the remote workstation 22 which had been previously configured to be sent traps. When the agent component 31 receives an SNMP get request, get-next or set request from workstation 22 and the particular request includes one or more variables within a subtree registered by a SMUX peer, the agent component 31 sends an equivalent SNMP PDU containing only those variables within the subtree registered by the particular SMUX peer. When the SMUX peer receives such a PDU, it applies the indicated operation and issues a corresponding get-response. The agent component 31 then correlates the result and propagates the resulting get-response to the workstation 22. When either the agent component 31 or the SMUX peer wants to terminate the SMUX association, it issues a ClosePDU request and the connection is closed. The Windows/NT and NetWare SNMP agents provide different mechanisms to integrate and interface to extension agents which are described in the above referenced documents. 
     Peer Extension Agent Component 32a 
     As discussed above, in accordance with the teachings of the present invention, the traditional peer extension agent is organized in a highly modular fashion wherein it comprises an extension agent component 32a and an instrumentation abstraction component 34 which communicate through IABS interface via functions contained in library 37 and the sockets mechanism of the particular the network operating system. The peer agent component 32a also has access to MIB component 39b which is discussed later herein. 
     The peer agent component 32a is designed to operate within the confines of the network operating system specific interface and the abstraction which enabled its partitioning into operating specific and generic module components for performing operating system functions and generic functions as required for operating with above mentioned types of network operating systems. The operating system specific (dependent) component contains modules which perform the required initialization and termination sequences with SNMP agent component 31, receive SNMP requests from and send SNMP responses to the SNMP agent component 31, send SNMP traps to SNMP agent component 31, convert OS specific request PDUs into OS independent request PDUs, convert OS independent response PDUs into OS specific response PDUs, convert OS independent trap PDUs into OS specific trap PDUs, convert OS specific trap PDUs into OS independent trap PDUs and perform process initialization and termination including any required agent register and deregister functions in addition to the logging of process information. Such conversion or translation is carried out using appropriate data structure definitions contained in a particular SNMP agent file (snmp.h). 
     The peer agent operating system independent (independent) component of agent component 32a contains modules which receive SNMP requests from the operating system specific component, validates such requests and then forwards them to instrumentation abstraction component 34 for further processing. The independent component also receives SNMP responses and traps from the component 34 and sends them to the agent specific component which formats and transmits them to SNMP agent 31. SNMP agent 31 forwards the traps via network 24 to the remote network management station 22. Additionally, the independent component of agent component 32a also contains modules for reading the peer agent&#39;s component 32a configuration file and a Managed Object Syntax (MOSY) compiler produced definitions file. 
     Instrumentation Abstraction Library Component 37 
     Each of the instrumentation clients (i.e. peer Agent extension component 32a and local console facility 42) are provided with equal access to the instrumentation component 34 through the functions contained within IABS library 37. As indicated above, abstraction component 34 uses the sockets mechanism of each network operating system to interface with its client components and used the network operating system specific device driver interface to interface with system instrumentation driver components (e.g. driver component 35). 
     As shown, library 37 is organized into three major sections which correspond to a common section, a client section and a server section. The common section is used by both client components 32a and 32b and the instrumentation abstraction component 34 and includes the procedures for implementing the functions Send --  PDU() and Get --  PDU(). The client section is used by client components 32a and 32b and includes procedures for implementing the functions InstCallForComponent() through InstDisconnectComponent(), iabs --  cmd --  connect(), and iabs --  accept --  trap --  connect(). The server section is used by the instrumentation abstraction component 34 and includes procedures for implementing the functions iabs --  trap --  connect(), iabs --  accept --  cmd --  connect() and Create --  Port --  File(). 
     The client library functions enable client components to connect to the abstraction component 34 at assigned port. The abstraction component 34 produces an IABS port file that each client component must read to determine the assigned port to connect. The common library functions enable client components and abstraction component 34 to create the appropriate protocol data structures (PDUs) according to predefined meanings, format the data contained therein and send and receive such PDUs across the socket interface of the particular operating system. These functions are described in greater detail in Appendix I. 
     Instrumentation Abstraction Component 34 
     As described earlier, the Instrumentation Abstraction component 34 is used to manage the hardware specific information on server hardware 36 in addition to file system 35b. This involves maintaining MIB variables described in Enterprise MIB 39b which correspond to such hardware specific information. Such information is organized into a number of different sections within the MIB 39b. For example, descriptions of the following types of information are stored in different sections. System information (e.g. model name of the computer), processor configuration information (e.g. numerical count of the number of configured CPUs in the system), processor performance information (e.g. numerical count of the number of CPU subsystem statistical sets available for performance monitoring), processor board information (e.g. numerical count of the number of CPU expansion boards in the system) and memory information (e.g. numerical count of the number of memory subsystems in the system). Also, stored is devices information (e.g. numerical count of the total number of physical I/O slots in the system, drives information (e.g. numerical count of the number of drive bays provided by the system model&#39;s cabinet, power supplies (e.g. numerical count of the number of power supplies in the system), parallel/serial ports (e.g. numerical count of the number of parallel/serial ports configured on the system base board), environment information (numerical value of the system&#39;s first cabinet temperature as read from an analog to digital converter), maintenance information (e.g. general purpose I/O port data register used for monitoring system status), firmware loads (e.g. numerical count of the number of BIOS firmware loads for the embedded devices in the system and history information (e.g. the number of uncorrectable memory errors that have occurred prior to the last zSvMIBpMemRed trap). An example of these types of MIB variables information are given in Appendix II. 
     When operating in an UNIX type of network operating system, component 34 is a daemon process which listens and sends on an available TCP port for exchanging PDUs with client components 32a and 32b after an instrumentation abstraction connection has been established with the peer agent extension component 32a daemon process. A data file specified as a first argument when the component 34 is first invoked or started up, is read by the instrumentation abstraction component 34 to obtain initial values for selected MIB variables. Another file is used to communicate the TCP port to be used for IABS connections with the client component 32a and the local console facility client component 32b. Subsequently, the client component 32a establishes an instrumentation abstraction connection with component 34. Instrumentation component 34 polls selected MIB variables described in MIB 39 for potential traps and sends trap PDUs to the client component 32a when any trap condition has occurred. 
     The instrumentation component 34 listens for and responds to IABS requests to &#34;get&#34; or &#34;set&#34; MIB 39b variables from client components 32a and 32b. In order to access most MIB 39b variables, the instrumentation component 34 utilizes the Instci component 34a to issue ioctl requests to the server management instrumentation driver component 35a. When a user has selected a persistent MIB variables to set, the instrumentation component 34 utilizes the Instvar component 34b to write the updated value to the data file. Additionally, component 34 includes facilities which support user defined traps and data monitoring. These facilities allow specific MIB 39b variables to be polled at frequent intervals without incurring the network overhead which would be required to perform such polling activity from a remote network manager. A predetermined maximum (e.g. four) of separate user defined traps and separate predetermined maximum (e.g. four) of user defined data monitors can be concurrently active. Specific variables have been defined in the MIB 39b to provide this functionality. Appendix II provides more specific details concerning how SNMP traps and user traps are defined within MIB 39b. 
     Server System Layering FIGS. 2a through 2c 
     FIGS. 2a through 2c illustrate the different system software layers utilized in server system 30 and their relationships to each other on each of the different network operating systems according to the teachings of the present invention. FIG. 2a illustrates the software layer arrangement when the architecture of the present invention is operating in a UNIX type network operating system environment. FIG. 2b illustrates the software layer arrangement when the architecture of the present invention is operating in a Windows NT network operating system environment. FIG. 2c illustrates the software layer arrangement when the architecture of the present invention is operating in a NetWare network operating system environment. 
     From a comparison of the different software layer arrangements of FIGS. 2a through 2c, it is seen that the only differences pertain to how the extendible SNMP agent 31 communicates with peer agent extension 32. As indicated, in the UNIX type system environment, peer agent extension 32 communicates with extendible SNMP agent 31 via a SMUX peer API which uses TCP/IP sockets. In the Windows NT operating system environment, peer agent extension 32 communicates with the extendible SNMP agent 31 through a simple callback API. Similarly, in the NetWare operating system environment, peer agent extension 32 communicates with the extendible SNMP agent 31 through a NetWare SNMP interface. Thus, it seen that the software layer architecture of the present invention operates with both sockets and API interfaces. 
     Detailed Description of Instrumentation Component 34 Organization--FIG. 3a 
     FIG. 3a illustrates the overall organization of component 34 in terms of showing its major module components. As shown, the major components of component 34 include an inst --  main module 34-10, a plurality of trap modules 34-24 through 34-44 which collectively comprise a trap mechanism, a dispatch module 34-22, a variable control table 34-12 having a MIB data table structure portion 34-16 and a dispatch table portion 34-18, an initialization process table structure 34-20, a SNMPVDSP module 34-19 and a termination process table structure (termtbl) 34-14 which are arranged as shown. As indicated by the dotted lines in FIG. 3a, the different fields of data table portion 34-16 and dispatch table portion 34-18 are contained within variable control table 34-12 which is illustrated in greater detail in FIG. 4b. 
     The MIB module 34-16 is used to create tables of information (database) that component 34 uses to manage every variable in MIB 39b. More specifically, the building of the MIB database 34-16 by component 34 is done off-line using scripts. The MIB information is compiled and processed into a file which is loaded onto server system 30 during the installation process. When component 34 is started up, it reads the MIB information into memory for future use in processing requests. 
     The trap mechanism modules handle those operations relating to the monitoring of fixed conditions established by &#34;hard coding&#34; or by a user defined MIB variables to detect over and under threshold conditions which are established in accordance with entry structures contained in a trap table 30-34 which define what conditions are to be monitored by component 34. The trap table 30-34 is created or built by compiling the values contained in a file zmibtrap.tbl included within activate trap module 34-40. The table contains an array of structures zsvmib --  trap wherein there is one such structure for each trap that component 34 supports. The trap structure is described in greater detail in Appendix III. 
     The activate trap module 34-40 when started up or activated, builds a trap poll item and queues it in the timeout poll list 34-42. Information in this list is used to manage which MIB variables are polled as well as the time interval between polls. Client components of the Instrumentation Abstraction Component 34 indicate their ability to handle traps when they establish their connection with the Instrumentation Abstraction Component 34. Client 32a indicates its ability to accept traps by providing the specific port for the Instrumentation Abstraction Component 34 to establish its trap connection with the client. Client 32b (Local Console Facility) does not provide any trap connection port thereby indicating that traps are not supported. 
     When dispatch module 34-22 signals the expiration of a select timer, it activates poll for trap module 34-44 which polls MIB variables described in the poll list items contained in the timeout poll list 34-42. The poll list item is processed using the test conditions therein. When the results of a test conditions indicates an over or under threshold condition exists, trap module 34-26 invokes send trap module 34-28 which creates an appropriate trap PDU (i.e. initializes certain data fields in the PDU data structure) which is forwarded by component 34 to all active trap connection sockets. 
     The inst --  main module 34-10 carries out the initialization and termination functions which define the startup conditions and clean up conditions for the individual instrumentation components 34a and 34b of FIG. 1. Component 34 does not perform this initialization directly but calls other components (i.e. components 34a and 34b) to perform their own setup operations during initialization and cleanup operations upon termination. Component 34 uses initialization process table 34-20 and termination process table 34-14 in carrying out such functions. 
     More specifically, the tables 34-20 and 34-14 are hard coded to contain function call entries associated with each instrumentation component with which it interfaces. In the server system 30, as indicated in FIG. 3a, tables 34-30 and 34-14, each contains two entries, one designating Instci instrumentation component 34a initialization function and another designating Instvar instrumentation component 34b initialization function. At startup, component 34 references table 34-20 and makes calls to the specified component functions to perform their own specific startup/initialization operation. Similarly, upon termination, component 34 references table 34-14 and makes calls to the designated components functions to perform their own cleanup operations. This arrangement enables component 34 to accommodate additional instrumentation components without having to make any modifications. 
     After initialization and prior to termination, component 34 processes set and get requests relating to specific MIB 39b variables which are dispatched by dispatch module 34-22 to the appropriate instrumentation component. More specifically, dispatch module 34-22 calls such components with the IABS appropriate variable identification value so that it can get the appropriate variable information for component 34 which in turn passes it back to the SNMP agent 31. As indicated in FIG. 3a, dispatch module 34-22 uses dispatch table portion 34-18 of variable control table 34-12 which is populated by each instrumentation component at initialization time. That is, during initialization, when inst --  main module 34-10 invokes init processing table 34-20 to call each instrumentation component to perform its own setup operation, such instrumentation component takes the opportunity to populate the dispatch table portion 34-18 with function entries designating the MIB 39b variable or subset of variables for which it has management responsibility. During run time, component 34 then calls these component functions to process the particular MIB 39b variable as designated by such variable control table entries. As explained herein, dispatch table portion 34-18 of variable control table 34-12 is organized to contain a unique processing function entry for each MIB 39b variable as described in greater detail with reference to FIG. 4b. 
     For further details relative to the initialization of instrumentation component interface, reference may be made to the description contained in an Appendix IV. 
     Instrumentation Component 34 Data Structures 
     In carrying out above functions in processing client requests, instrumentation component 34 utilizes the several different types of data control structures, some of which were discussed above. The first control structure is the IABS PDU data structure of FIG. 4a which contains the command and data sent or received over the sockets mechanism by the instrumentation component 34. The second data control structure is the IABS variable control table entry structure of FIG. 4b which defines the collection of different fields of the variable entries stored in the MIB data table portion 34-16 and dispatch table portion 34-18 of the variable control table 34-12. The third data structure is a poll list item structure of FIG. 4c which defines the different fields of the poll entries of timeout poll list table 34-42 used by trap mechanism of instrumentation abstraction component 34 to control the polling for traps invoked at the expiration of a select timer. 
     As mentioned above, the three structures are shown in greater detail in FIGS. 4a through 4c. FIG. 4a illustrates the different fields and format of the PDU data structure which is received by component 34 and acted upon as explained herein. FIG. 4b illustrates the fields and the format of each IABS variable control table structure entry stored in data table structure 34-12 of FIG. 3a. FIG. 4c illustrates the format of the each poll list item entry stored in timeout poll list table structure 34-42. These structures will be discussed in greater detail herein. 
     Detailed Description of Instrumentation Component 34a 
     FIG. 3b illustrates in greater detail, the organization of a typical component 34 which augments component 34 in managing specific MIB 39b variables relative to satisfying SNMP queries (i.e. SET --  CMD, GET --  CMD). As indicated in FIG. 1, component 34a processes queries relating to specific MIB variables (objects) by calling driver component 35a. Component 34b can be considered to be similarly organized but handles MIB variables by calling a file system 35b. 
     As indicated in FIG. 3b, component 34a includes several groups of modules 34-10, 34-12 and 34-14 for performing the indicated functions. Each group of modules are invoked by specific functions contained in component 34. More specifically, when component 34 is performing initialization, it activates the group of modules 34a-10 comprising the instci --  init function which perform the operations of allocating memory, initializing data structures and opening the device driver 34a-16 associated therewith via an operating system specific open type function call. At termination, component 34 calls the group of modules 34a-14 comprising the instci --  term function which perform the operations of freeing or deallocating memory and closing the device driver 35a via an operating system specific close type function call. 
     During operation, component 34 calls the group of modules 34a-12 via its dispatch module to process those MIB variables which the variable control table indicates that component 34a has responsibility. A similar group of functions are provided for processing each different section of MIB variables (e.g. processor CPU related MIB variables, Network Operating System MIB variables). 
     Component 34a invokes a validation function which performs an additional validation after component 34 has performed a general (generic) validation. If the MIB variable is valid, component 34a operates to obtain the requested MIB variable data by invoking driver operating system specific ioctl type function 34a-16. Component 34a obtains the data and returns it to component 34 which in turn returns it back to SNMP agent. 
     DESCRIPTION OF OPERATION 
     With reference to FIGS. 1 through 7g, the operation of the present invention will now be described. FIGS. 5a and 5b diagramatically illustrate the components which define the overall architecture of the present invention along with the overall flow and character of requests that passes through the different interfaces of server system 30. FIG. 5a illustrates the processing of a single instance variable value while FIG. 5b illustrates the processing of a multi-instance variable value. Since the differences in the figures reside mainly in the type of variable being processed, the operations are explained with reference to FIG. 5a. 
     As indicated, at the SNMP agent level, there are three different types of command requests (i.e. Get, Get-Next, Set) which are mapped into five types of command requests (i.e. Get, Set, Set-Verify, Commit, Rollback). The Get-Next command is eliminated by having included a facility for MIB browsing in peer agent 32 which allows the command to be processed by translating the command into a series of Get commands. Also, facilities are included in the peer agent 32 which enables the Commit and Rollback commands to be processed at that level. 
     It will be noted that at the SNMP agent level, the variables being processed are identified by OIDs which are long tree structure (hierarchical) sequences of integers. Peer agent 32 includes functions for translating each such sequence into a single simple variable identifier. This operation greatly facilitates the processing of such variables. 
     By way of example, it is assumed that two variables are received as part of a Get command request. This command request is processed by the peer agent 32 as mentioned above and causes the formulation of an IABS command request PDU as shown. This allows the command request to be passed across the IABS interface by invoking the appropriate IABS library functions which in turn invoke the particular network operating system&#39;s interprocess communications mechanism (i.e. sockets) to accomplish the actual transfer between the peer agent 32 and IABS instrumentation component 34. 
     The component 34 passes a Get command request for each variable in the PDU to the instrumentation component which is designated as having management responsibility for that MIB variable. The instrumentation component issues an ioctl command to its OS specific driver or file system or other to obtain the current value for the MIB variable. When the instrumentation component has obtained the current value (e.g.. 7) for all the variables in the PDU, it passes it back to component 34. As indicated, component 34 generates an IABS command response PDU. Component 34 passes the command response across the IABS interface to peer agent 32 by invoking the appropriate functions contained in the IABS library and the socket mechanism. As indicated, the peer agent 32 translates the command response variables back into the format supported by SNMP agent 31 and passes the SNMP response containing the variables to SNMP agent 31. 
     FIG. 5a also illustrates the flow for a trap which proceeds in parallel. This is initiated by component 34 when a particular variable being monitored is detected as having exceeded a specific threshold. When this occurs, component 34 generates an IABS Trap Indication PDU which it sends across the IABS interface to the peer agent 32 in the same manner as described. Peer agent 32 translates the variables into the format supported by SNMP agent 31 and passes the SNMP trap to SNMP agent 31 as indicated. 
     The actual operations performed by the different components of FIGS. 5a and 5b will now be considered in greater detail with reference to FIGS. 6a through 7g. FIGS. 6a through 6c illustrate the operations performed by peer agent 32 in processing SNMP command requests. By way of example, the flow illustrated is that executed when the architecture of the present invention is being used in the Windows NT network operating system environment illustrated in FIG. 2b. This environment was selected for ease of illustration. The sequence of operations performed by peer agent 32 is carried out by the functions designated on the right side of each of the FIGS. 6a through 6c. The IND designation is used to indicate that the operations are being performed by an operating system independent function and the name appearing in brackets indicate the module containing that function (e.g. nt --  dep.c). 
     FIG. 6a illustrates the specific sequence of operations performed by peer agent 32 in processing an SNMP Get and Get Next command request. FIG. 6b illustrates the specific sequence of operations performed by peer agent 32 in processing an SNMP Set command request. FIG. 6c illustrates the specific sequence of operations performed by peer agent 32 in processing an SNMP trap. 
     FIGS. 7a through 7g 
     The basic sequence of operations performed by IABS component 34 will now be described with reference to the flow charts of FIGS. 7a through 7g. FIG. 7a illustrates the sequence of operations performed by the inst --  main module 34-10 of FIG. 3a during initialization and termination operations. 
     As indicated in FIG. 7a, module 34-10 of FIG. 3a sorts the MIB database built by component 34 as part of the startup process using the information stored in enterprise MIB 39b of FIG. 1 (i.e. block 700). This operation eliminates obsolete records and organizes records in variable Id order. Next, module 34-10 processes the MIB data base by updating values in the IABS variable control entries of table structure 34-16 of FIG. 3a (i.e. block 702). 
     As indicated in block 704, module 34-10 initializes the different instrumentation components 34a and 34b of server system 30. As indicated in block 706, by invoking the component initialization function of each of the components 34a and 34b designated by the init entries previously stored in the INIT --  PROC --  TABLE 34-20 of FIG. 3a. When so invoked, this provides each instrumentation component with an opportunity to set its processing function pointer value into the processing function field of each entry contained in the IABS variable table structure 34-16 which is formatted as shown in FIG. 4b. 
     When initialization is performed by each inst component without error (i.e. block 708, inst-main module 34-10 next determines if data monitoring is active (i.e. block 710). If it is, inst-main module 34-10 initiates the data monitoring activity (i.e. block 712). When no further data monitoring activity needs to be initiated, module 34-10 invokes the dispatch module 34-22. The sequence of operations performed by dispatch module 34-22 are illustrated in FIG. 7b. 
     As shown, module 34-22 determines if there is an IABS connection (i.e. block 714-2). If there is not, then module 34-22 invokes a socket accept command function (iabs lib) and blocks until the socket connection is established with peer agent 32 (i.e. block 714-6). Next module 34-22 makes a select socket system call (invokes the select function-iabs lib) to determine whether a command request has been sent by peer agent 32 as indicated by the command socket being ready to read, whether the command socket is ready to write a queued command response, whether the trap socket is ready to write a queued trap indication or whether the interval for the next poll queue item has elapsed. The module 34-22 remains blocked until at least one socket ready is received or until a timeout occurs (i.e. block 714-8). 
     If module 34-22 detects a timeout (i.e. block 714-10), it invokes the process poll queue function module 34-44 which performs the sequence of operations shown in FIG. 7g. At the completion of polling entries contained in timeout poll list queue 34-42, the function module 34-44 returns control back to dispatch module 34-22 as indicated for further socket testing. 
     If a timeout has not occurred, then module 34-22 determines if the socket is ready to write which means it has queued an PDU output (i.e. block 714-14). If it is ready to write, then module 34-22 sends out an IABS PDU structure formatted as shown in FIG. 4a (i.e. block 714-16) and continues in that loop. If there is no socket to be written, then module 34-22 determines if there has been any queued input received. It determines this by testing for sockets to be read (i.e. block 714-18). If there is a socket to be read, modules 34-22 determines if it is a command socket that is to be read (i.e. block 714-20). 
     If it is a command socket, module 34-22 invokes the Get IABS PDU function (iabs lib) as indicated in block 714-22 which in turn invokes the process IABS command request function as indicated in block 714-24. This function processes the command received from peer agent 32 via the previously established command socket connection by executing the sequence of operations of FIG. 7c. After completing the processing of the command contained in the IABS PDU as indicated in block 714-22, module 34-22 then continues in that loop. 
     If there is no command socket ready to be read, then module 34-22 determines if there is an accept socket ready to read as indicated in block 714-30. If there is, module 34-22 invokes the IABS command accept function as indicated in block 714-30. After completing that operation, module 34-22 continues in that loop. 
     FIG. 7c illustrates the flow of the IABS command request function invoked by module 34-22. As indicated in the Figure, this function performs the operation of testing the command filed of the IABS PDU to determine if it is a Get, Set or Set-Verify command (i.e. block 714-240). If it is not any of these types of commands, the function logs an invalid command error (i.e. block 714-242 and returns to dispatch module 34-22. 
     If the command is valid, the function allocates a memory buffer for storing a command response PDU as indicated in block 714-244. Next, the function begins processing each of the variables contained in the IABS PDU by invoking the process IABS variable function (i.e. block 714-248) of FIG. 7d. This function determines if an error was returned by the variable processing function as indicated in block 714-250. If the variable is not valid, then the function sets an error index and error code as indicated in block 714-252 and continues the sequence of operations. 
     After successfully completing the processing of a variable, the function continues in that loop, processing other variables. After completing the processing of all of the variables contained in the IABS PDU, the function sets size and # variables fields with the appropriate values into the command response PDU buffer as indicated in block 714-254. It then outputs the command response IABS PDU. As indicated, it queues the IABS command response PDU to be sent and returns to the dispatch module 34-22 as indicated in block 714-256. 
     FIG. 7d illustrates the specific sequence of operations performed by the process IABS variable function module of component 34. As indicated in block 714-248a, the function module first determines if the variable being processed is valid by checking its Id value and seeing if it is within a particular range. If it is not, the function logs an invalid variable error as indicated in block 714-248b. If it is valid, the function gets the IABS variable control table entry from IABS variable control table 34-12 as indicated in block 714-248c. It then invokes the variable validation function as indicated in block 714-248d which performs a generic validation operation. The validation operation sequence is shown in greater detail in FIG. 7e. 
     If there is a validation failure, then the function logs an error as indicated in block 714-248k and returns to the process IABS command request function of FIG. 7c. If the variable is valid, then the function determines if the variable is stubbed which is a mechanism that is used for prototyping and testing. The sequence of operations performed by this mechanism (i.e. block 714-248g) is illustrated in FIG. 7f. If the variable is not stubbed, the function calls a component variable processing function of the instci component as indicated in block 714-248i. This function completes the validation and processing of the snmp variable as discussed herein with reference to FIGS. 8a through 8c. 
     As indicated in block 714-248j, the function next checks for errors that are normally encountered during the course of &#34;MIB browsing&#34;. SNMP MIBs are hierarchically organized so that a MIB may be traversed by GET-NEXT commands without a-priori knowledge of the specific MIB organization. The process of issuing SNMP GET-NEXT commands down one tree of a MIB until reaching it&#39;s final object and then down the next branch is called &#34;MIB browsing&#34;. Errors are normally encountered when a GET-NEXT is issued at the end of a MIB branch to indicate to the browsing software End of Branch. These errors should not be placed in a log file and this function tests for them to so handle them. If it is another type of error (not associated with MIB browsing), then the function logs an error as indicated in block 714-248k and returns. 
     FIG. 7e illustrates the specific sequence of operations performed by the generic IABS variable validation function invoked as indicated in FIG. 7d in processing a variable from the MIB 39b. As indicated in blocks 714-301 through 714-308, the component 34 examines the corresponding IABS control table entry and PDU array entry for the particular variable. It determines from the contents of the IABS variable control table entry if it is an accessible variable (can be read, written), if it is a multi instance variable and if a multi instance, if it is &#34;0&#34; or less than &#34;0&#34; in which case an invalid instance error is returned. Additionally, as indicated in blocks 714-312 through 714-318, the component 34 determines its type, if it is an integer or counter type. Also, as indicated in blocks 714-322 through 714-340, the component 34 checks if the command is a set or set-verify command and if the variable is writable as well as determining if it is a get command and whether or not the variable is readable as indicated. The component 34 returns the indicated status based on the examination of these fields within the IABS variable control table entry and IABS PDU variable array entry. 
     FIG. 7f illustrates the sequence of operations performed by the database component variable processing function in processing get, set verify and set commands utilizing the IABS variable array entry and IABS variable control table entry. As indicated, the component 34b examines the IABS variable control entry for the variable being processed. First, the component 34b determines if the variable is a multi instance variable and if it is, the component 34b determines if the instance is less than the maximum instance value for that variable (i.e. blocks 714-2480 and 714-2482). If it exceeds the maximum value, then the function then returns with an indication that the instance is invalid (i.e. block 714-2484). 
     Next, as indicated in block 714-2486, the component 34b determines if the instance exists by checking an indicator specifying if the instance is present (used for handling sparsely populated tables of MIB variables defined in internal MIB database 39c of FIGS. 5a and 5b). The internal database 39c is accessed by database instrumentation component 34b as indicated in FIGS. 5a and 5b. The database contents are derived from MIB 39b and organized as discussed herein. If it is not present, then the component 34b returns an instance not present. If the instance exists/is present, the component function 34b determines what type of command is being processed by performing the operations of blocks 714-2488, 714-2494, and 714-2496 in the manner indicated in FIG. 7f. 
     If a set-verify command, then a successful return is made. If a get command, component 34b checks whether the buffer supplied is large enough to contain the current value as indicated in block 714-2490. If it is large enough, the buffer is updated from the database and a successful return is made. If not, then a value too big error indication is returned. 
     If a set command, the component 34b checks the length field contained in the instance value structure to determine if the instance value being written into the MIB database 39c has a length which is equal to the previous instance value. If it is not, then the component 34b reallocates in memory, the structure of the data base buffer as indicated in block 714-2302. Then the component 34b updates the memory database 39c with the value contained in the database buffer as indicated in block 714-2304. 
     Next, the component 34b checks the contents of the IABS variable control table entry, to determine if the variable is a persistent variable as indicated in block 714-2306. In the case of a persistent variable, the function builds an ASCII database record which is appended to the database file 39c as indicated in blocks 714-2308 and 714-2310. The database file 39c is organized to contain ASCII records, each record consisting of ASCII strings separated by a conventional separator character and terminated in a conventional manner with a new line character wherein initial database strings are encoded to identify MIB variable and instance. The simplified ASCII structure makes the database very portable. 
     The instrumentation component 34 provides direct support for the persistence of a subset of MIB variables. Such variables retain the value which was last specified in a SET --  CMD command even if the instrumentation component 34 has been terminated gracefully or not gracefully and restarted in interim. In the present embodiment, the &#34;persistent&#34; variables are zSvMIBpfMBCerrs, zSvMIBhsMenReds, zSMIBhsMemYellows and all of the user monitoring and trap variables (zSvMIBmn*). As described above, when a successful SET --  CMD command is performed for a &#34;persistent&#34; variable, then a new server MIB ASCII data base record is appended to the data base file 39c by component 34b at initialization. When the server MIB data base file 39c is processed on a subsequent initialization of the component 34 and 34a, then the later appended record overrides any previous record for that snmpvar/instance. In order to ameliorate the continuing growth of the server MIB data base file 39c with increasing number of duplicate records as more SET --  CMD commands are performed on &#34;persistent&#34; variables, the component 34b re-sorts the server MIB data base 39c at each initialization and at each graceful termination as described above. Sorting the server MIB data base file 39c recreates the file with records in ascending snmpvarfinstance order and all duplicate records are supplanted by the latest version of the record in the file 39c prior to such sorting. Then the function returns to the IABS variable function of FIG. 7d 
     FIG. 7g illustrates the sequence of operations performed for carrying out poll list processing which drives the trap polling and data monitoring function. As indicated in block 714-2400, the component 34 sets the current poll item obtained from head of queue (HOQ) pointer designating the beginning of the list and dequeues it from the list. The function first checks to see if the current poll item in the list has matured. If it does not, the function returns since list items are ordered from shortest timeout value to longest timeout value, no further items need to be tested. If the current poll item has not matured, the function next checks to determine the type of poll item being processed by performing the operations of blocks 714-2402 through 714-2408. Based on the result of such tests, the function performs the indicated operations. 
     More specifically, if the component 34 determines from the type field of the poll list item data structure that the current poll item is a generic poll item, then it calls the instrumentation component processing function specified by the processing structure&#39;s processing function. This allows the instrumentation component 34a to perform timeout management functions such as the determination of the time interval between polls. If the component 34 determines that the current poll item is a monitor poll item, it performs the operation of getting the monitor poll variable value by calling the processing function of the component 34a to obtain the variable value and updates the monitor circular buffer with the variable value received from the component 43a. 
     If the component 34 determines that the current list item is a trap poll item, it then gets the trap poll variable value specified by the poll variable field of the poll list item structure. Component 34 then tests for the one or more test conditions for that variable contained in the current poll item (i.e. block 714-2411). If the condition being tested is true, then the component 34 builds an IABS TRAP PDU and queues the PDU to be sent (i.e. blocks 714-2416 and 714-2418) and continues that loop until all of the conditions have been tested. As indicated in block 714-2412, component 34 then determines whether the poll duration for this poll item has been completed. If not, it requeues the poll item at its next time of maturity (i.e. block 714-2413). If so, it does not requeue the poll item, but frees the memory allocated for that poll item (block 714-2414). As indicated in block 714-2420, the component 34 obtains the next poll item from the current HOQ and repeats the sequence of operations of FIG. 7g. This is done until a poll item is encountered which has not matured indicating the completion of the poll list processing. At this time, component 34 returns to the iabs server dispatcher module 714 of FIG. 7b which continues as described above. 
     FIGS. 8a through 8c 
     The basic sequence of operations performed by Instci component 34a will now be described with reference to FIGS. 8a through 8c. FIG. 8a illustrates the sequence of operations performed by the instci component module 34a-10 of FIG. 3b during initialization. As indicated in block 800 of FIG. 8a, inst --  main module 34-10 of calls Instci component 34a through its init --  proc --  table 34-20 to perform all required set-up operations. That is, it generates an init call to module 34a-10 of FIG. 3b which then sets a global flag indicating that the initialization function module 34-10 has been called (i.e. block 802). Then module 34-10 performs the setup operations of blocks 804 through 812. 
     More specifically, module 34-10 allocates memory and initializes the fields of all data structures with either zero values, predetermined constants or with persistent values obtained from a disk file containing persistent MIB variables (i.e. zmibdata.bas). Next, Instci component 34a opens driver 35a as indicated in block 806 using the open call function driver function module of block 34-16. As indicated in block 808, the module 34-10 gets the various static configuration data and places it in the appropriate data structures for later retrieval. Such types of configuration data includes processor type, number of I/O expansion cards in the server system, configurations of server parallel and serial ports and the amount of system memory. 
     Next, as indicated in block 810, the Instci component 34a uses the timeout poll list 34-42 of FIG. 3a to set up items for making delayed call backs as required for performing functions such as a delayed initialization of special hardware and an elapsed time calculation for processor speed. As indicated in block 812, Instci component 34-10 populates the dispatch table portion 34-18 of FIG. 3a with pointer entries designating those MIB processing functions 34-12 through 34n of FIG. 3b which manage the particular MIB variables. Such functions include zssm --  var(), eisa --  var(), cpu --  var(), inca --  var() and nos --  var(). Since each of these function modules is responsible for processing a related group of MIB variables, the same function appears several times in variable control table dispatch table portion 34-18. After successfully completing the above setup operations, Instci component 34a returns back to the inst --  main module 34-10 with a successful status. 
     FIG. 8b illustrates the sequence of operations performed by the function module 34a-14 of FIG. 3b during termination. As indicated in block 820, dispatch module 34-22 calls the Instci function module 34-14 through the termtbl process table 34-14 by invoking a TERM call to perform all of the required clean-up operations. These include the operations of blocks 822 through 826. As indicated, module 34-14 checks the state of the global flag to determine if initialization had taken place. If it did not (i.e. the global flag initialized was not set), it returns directly to inst --  main module 34-10. Otherwise, as indicated in block 822, when global flag is set, module 34-14 returns all allocated memory and then closes driver 35a by invoking the close driver function of block 34-16 (i.e. block 826) before returning to inst --  main module 34-10 (i.e. block 714-248h). 
     FIG. 8c illustrates the sequence of operations performed by function module(s) 34-12 of FIG. 3b during the processing of GET and SET commands for which it is responsible. As indicated in block 830, dispatch module 34-18 invokes the processing function specified in the variable control table location for that variable to process one specific MIB variable identified by a snmp variable Id (i.e. snmpvar) and an instance number (i). It also identifies such processing as a GET or SET command. Next, as indicated by block 832, the particular processing module 34a-12 responsible for processing the variable validates the instance number (i) against the total number of instances of this specific MIB variable. If the instance is greater than the total, the module 34a-12 returns to the dispatch module 34-22 with an error indicating INSTANCE TOO BIG. 
     If the instance is valid or this is a single instance MIB variable, then module continues processing (i.e. block 836). As indicated in block 838, depending on the type of MIB variable being processed, module 34a-12 performs the operations of one of the blocks 840, 842 or 844. That is, if the MIB variable corresponds to data contained in a hardware component (e.g. register), it issues an IOCTL function call to driver function module 34a-16 to get the data or set the data into such hardware component and perform any processing of the raw data as required. 
     If the MIB variable corresponds to the data contained in a memory resident data structure, then module 34a-12 gets the data from the memory structure by performing a memory read operation or sets the data into the memory by performing a memory write operation (i.e. block 842). If the MIB variable is a constant value, then function module 34a-12 generates the required data using a prestored constant in the case of a GET command. After performing one of these operations, module 34a-12 returns the data (i.e. GET command only) to dispatch module 34-22 along with successful status as indicated in block 846. 
     From the above, it is seen how the architectural organization of the present invention is able carry out the processing of snmp variables through the use of a plurality of interfaces operating in conjunction with a plurality of different types of network operating system environments. 
     It will be appreciated that many changes may be made to the preferred embodiment of the present invention without departing from its teachings. For example, the architectural organization of the present invention may be used with other types of networking operating systems and with a variety of server hardware platforms. Also, the abstraction interface functions contained in the iabs library may be packaged within the specific modules. 
     Additionally, it will be appreciated that the present invention enables new instrumentation components to be added to module 33 without having to make changes to that module. Similarly, it will be appreciated that new driver and file system modules may be added to the system. In such cases, it will be understood that new calling procedures may be required for communicating between instrumentation components and newly added modules. 
     While in accordance with the provisions and statutes there has been illustrated and described the best form of the invention, certain changes may be made without departing from the spirit of the invention as set forth in the appended claims and that in some cases, certain features of the invention may be used to advantage without a corresponding use of other features. ##SPC1##