referring to fig2 , an snmp agent runs on a processor ( 21 ) in a general - purpose module - rack ( 22 ). the rack has a number of slots into which equipment modules ( 23 a ) ( 23 b ) ( 23 c ) ( 23 d ) are plugged . the individual modules have input and output connections ( 24 ) appropriate to their functions . a power unit ( 25 ) is connected ( 26 ) to a source of mains power and converts this power into a form suitable for the modules ( 23 ). the processor ( 21 ) has a connection ( 27 ) to a data network , and will typically have its own ip address so that it can be distinguished over the network . the processor ( 21 ) also has connections to the modules ( 23 ) and communicates values of control objects to and from one or more of them . the current values of these objects are stored in the processor ( 21 ) and are made available , via the network connection ( 27 ) to a remote processor ( 28 ) which runs an snmp manager . using the snmp protocol , control objects for particular modules are reported to the processor ( 28 ) and control objects for particular modules are set to specific values . the snmp manager in the remote processor ( 28 ) makes use of a mib to learn the oids and data types and formats of the various items of control data . typically this mib would be written by the designer of the installation which includes the module rack ( 22 ). this work is simplified if “ generic ” mibs for the modules ( 23 ) are available from their manufacturer and they can easily be combined to make a specific mib for the rack ( 22 ) as it is configured in its particular installation . the snmp agent in the processor ( 21 ) must associate particular snmp oids with particular control data items relating to the modules ( 23 ). in the case where a new module has been inserted , or modules have been changed , the agent may not have a mib to fully interpret these oids . in the system of the invention the agent does not require knowledge of the mib used in the remote processor ( 28 ). this is achieved by locating each control object in a storage location which is associated with a position in a two - dimensional table . particular pairs of numbers in the string of numbers comprising an oid are treated as addresses to the rows and columns of the table . the table is structured with an extensible space for module control data objects . in a typical module rack with space for a maximum of 16 modules , the table is structured with space for at least 16 instances of an unlimited number ( no more than 16 in any practical example ) of different types of module ; and , for each module , an extensible space for module data objects . the agent periodically interrogates each slot ( or interrogates each slot at the time its operation is initiated ) to obtain : the identity of the equipment module ( if any ) in that slot , the identities , data types and formats of the control data objects for that module ; and , the current values of the control data objects . the module identities and the data object identities are represented by integers whose interpretation is defined in module - specific , generic mibs published for each module . these module - specific mibs can be used by any snmp manager needing to control the relevant module , regardless of the configuration of the module rack in which the module is installed . fig3 shows how the agent running on the processor ( 21 ) stores the results of the interrogation of the modules in the slots of the rack ( 22 ) in the table . the table ( 31 ) has one column for each module ( 23 ). typically the maximum number of modules which can fit in an enclosure is limited and so the maximum possible number of columns is limited to that number . each column has a header row ( 32 ) and the cells of this row contain equipment - type identifiers which identify the individual equipment modules ( 23 a ) to ( 23 d ). the identifiers are the numbers which are defined in a published mib for the respective modules and in this example correspond to the number in the oid string defining the particular module type . the order of the columns of the table ( 31 ) is arranged so that the module identifiers are arranged in ascending order . it can be seen that modules having type 19 , 230 and 250 are present , and that there are two type - 230 modules present . each column has a second header row ( 33 ) and the cells of this row contain “ slot identifiers ” which indicate which position in the enclosure ( 22 ) is occupied by a particular module . it can be seen that the two type - 230 modules are in slots 1 and 4 . each column of the table ( 31 ) contains a cell for each of the data object identifiers for the module identified by the header rows . the data object identifiers are sorted into numerical order . each type of equipment module has a known number of commands . the number of cells in each column therefore depends on the number of commands reported in the previously described interrogation process and defined in the published mib for that relevant module . it can be seen that the type - 19 module has only three commands , and that type - 230 modules have five commands . the agent need not have prior knowledge of every possible module type , and the associated number of commands . these are provided by the equipment modules themselves , when interrogated by the agent . each of the cells containing a data object identifier is associated with a storage location for the relevant data object that will be reported to , or set by the snmp manager running on the processor ( 28 ). the table ( 31 ) can be interpreted as a tree with nodes numbered according to the header rows and contents of the table as shown in fig4 . it can be seen that the hierarchy of the table in fig3 is different from that of the tree in fig4 , but they are logically related so that one may be derived from the other . the tree of fig4 can be divided into sections ( 401 ) ( 402 ) ( 403 ), each section corresponding to a particular module type . mibs corresponding to these sections can be published as each relevant module becomes available and used to construct mibs for snmp managers controlling racks containing these modules . where more than one instance of a module is present in a particular rack , its location within the rack ( slot number ) will be known from system design data and it is only necessary to append the slot number to the oid for a particular data object in order to control or monitor that data object . when an oid ( forming part of an snmp message ) is received by the agent running in the processor ( 21 ) the agent interprets the oid according to the tree as shown in fig4 and is able to locate the corresponding cell in the table of fig3 and so access the corresponding control object . the agent examines in turn each constituent number element in the oids of snmp commands received from the network to select data objects relevant to it . it will not have prior knowledge of all of the number elements but the oid is structured so that one of the elements represents module identity , and another represents command parameter identity . the positions of these numbers are the same in all module oids and they can be used be the agent to address the table and so identify a particular stored control parameter for reporting or modification ( depending on the snmp message containing the oid ). it is noted that in the present example , where two type - 230 modules are present , these occupy adjacent columns in the data table even though they are not physically located in adjacent slots . the two modules can therefore be addressed distinctly using a “ next ” node syntax as described above . it is intended that the foregoing detailed description be regarded as illustrative rather than limiting and that it be understood that it is the following claims , including all equivalents , that are intended to define the scope of the invention . the embodiment of any figure or described example or any feature thereof may be combined with the embodiment of any other figure or described example . other features known in the art and not inconsistent with the structure and function of the present invention may be added to an embodiment or example described herein .