one embodiment of a method to handle incomplete messages between managers and agents in a network management system is shown in fig1 . it must be noted that the specifics of this example use snmp protocols and terminology merely as examples . it is in no way intended to limit the application of the invention , but is only for discussion purposes . further , a printer is used as an example of the network component , again only for discussion purposes . in fig1 the network interface card , or nic , has as part of its structure , a printer interface software element in step 10 . the nic interface receives a query from the network manager and receives a pdu message from the manager that is complete at step 12 , but the nic tears it apart and only passes on part of the pdu . in this example , it was known at the design phase of the network that the pdu would be incomplete . this can be determined from several places , including the specifications provided by vendors of either the software or the hardware used in the network . in alternative embodiments , identification of an incomplete pdu may be necessary . additionally , there may be further analysis of incomplete pdus to determine what information is provided and how much adjustment will be necessary . however , for this specific example , the discussion will assume that the pdu was known to be incomplete at design of the system . once the incomplete pdu is received , the method needs to handle the incomplete pdu to allow the network to function correctly . in this example , this is at step 14 and a software element referred to here as snmp glue code will perform the handling and adjustment of the pdu . this will be discussed in more detail further in the description . the process of handling the incomplete pdu ends at step 16 , where a complete pdu has passed to the snmp subagent from the snmp glue code . at this point , the network can return to its normal functions with a complete pdu . in order to more clearly understand the restructuring of a network management message such as a pdu , it is helpful to study the specifics of such a message . in keeping with the snmp environment used in the above examples , a table below gives a format for an snmp pdu . in order to understand the table , however , some of the terms discussed in the comments may require further explanation . references will be made to both asn . 1 and ber , two hand - in - hand methods for coding and handling of the information to be transmitted and received . asn . 1 stands for abstract syntax notation , version 1 . it is a language for describing structured information , typically to be transmitted across an interface or communication link . the data types of asn . 1 are encoding using basic encoding rules ( ber ). ber allows automatic derivation of the transfer syntax for every abstract syntax defined using asn . 1 . asn . 1 is a hierarchical structure , which is followed by ber . they both operate on a tag , length , value , or identifier , length , contents ( ilc ) scheme . in the case of ber , the scheme is often referred to as type - length - value ( tlv ). many other encoding schemes use similar structures . the encoding schemes ensure that the information transmitted is in the proper format . for discussion purposes , the tlv format will be assumed . in the tlv format , the type portion conveys several pieces of information : the tag class of the value , the tag number and the form of the encoding , either primitive or structured . the length portion allows the system to identify the end the contents , thereby ensuring that all the contents are received and not mixed in with following terms . the value is the actual contents being conveyed , the substance of the encoding . ber uses unique identifiers as part of the type portion , thereby identifying data types . the identifier calls to the particular data type being transmitted under asn . 1 . the identifiers are divided into four classes , using the 8 th , 7 th and 6 th bits of the octet string . this is shown in the following table . the remaining bits designate a numeric tag associated with the particular data type defined by the first three bits . these tags , their class names and types uniquely identify the variables in the protocol . the identifier tags used in the pdu table below are shown as follows . the above terminology and tags are used in the pdu , shown in the table below . having seen the specification of one example of a complete pdu , it is possible now to discuss a method for construction of a complete pdu from a partial pdu . the partial pdu contains different portions of a complete pdu depending upon the type of message being sent . in a get message , the pdu contains a ber - encoded oid ( object identifier ). in a set message , the partial pdu contains a ber - encoded oid , a ber - encoded type , the length that is not ber - encoded , and the value that is not ber - encoded . these elements are used to rebuild and complete the pdu . referring now to fig2 and the pdu table above , one embodiment of a method for reconstructing a partial pdu begins at step 20 with set up of the snmp information . the snmp or network information provides the necessary parameters for the version of the network management code being used , such as snmpv1 , snmpv2 , and the network community . the network community identifies the community allowed to access the particular message . if the requester is not a member of the proper network community , it is denied access to this particular message . in most cases , however , the community is ‘ public .’ once the network environment information is set up , the command section information is processed in step 22 . in this example , the command section information was provided but known at the design phase to not be in the previously discussed tlv format . as shown in the table above , the command section identifies the type of message being transmitted . the codes a0 - a7 define different types of messages , as shown below . in addition to process the actual command portion of the pdu , the remaining pieces of the command section must be processed . this includes the request id section , which identifies the number of the request , the error status section , which identifies if there is an error , and the error index section , which identifies the variable giving rise to the problem if there is one . in step 24 , the lengths of the variable binding sections must be calculated . as can been seen by the pdu table , there can be n number of variable bindings and they can be of varying lengths . however , in order for the process from fig1 to handle the pdu , the lengths must be included , as discussed above . once all of the parameters for all of the objects have been identified and decoded as necessary to determine the lengths , these values are stored to be entered into the completed pdu . in step 26 , all of the previous information is copied into a framework of a complete pdu in the proper places and in the proper format . for example , the command section information was provided but not in the snmp - desired format of tlv . therefore , this information must be copied into the proper format , such as tlv , into the proper sequence of the complete pdu framework . once all the copying is performed , a complete pdu has been populated from the partial pdu information previously received as shown in step 28 . at this point , the discussion returns to fig1 . now that a complete pdu has been constructed , the process can continue in normal mode . in the example of fig1 an snmp subagent spawned by the nic interface uses the completed pdu . however , this is merely an example , and the completed pdu could be used in any number of functions within a network management system . similarly , while the snmp - specific examples have been used to this point , they are merely intended as examples . the expansion of these examples could be performed into any network management context . in general network terms , a partial pdu would translate to a partial or corrupted network agent message in non - snmp network management systems . the snmp information set up as discussed with reference to fig2 would translate into any specific information necessary for a particular network management environment . the various portions of the pdu table would have analogous portions to other network management message formats . thus , although there has been described to this point a particular embodiment for a method and structure for handling incomplete network management messages , it is not intended that such specific references be considered as limitations upon the scope of this invention except in - so - far as set forth in the following claims .