z/OS Communications Server: CMIP Services and Topology Agent Guide
z/OS Communications Server: CMIP Services and Topology Agent Guide
Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Hexadecimal BER format z/OS Communications Server: CMIP Services and Topology Agent Guide SC27-3646-00 |
|
Hexadecimal BER format is the hexadecimal value contained in the BER, enclosed in angle brackets. Hexadecimal BER format is the final format that can be used to specify a value. In some cases when CMIP services cannot decode a string sent by another CMIP services, CMIP services sends the string to the application program in hexadecimal BER format. In this format, the value is enclosed in less than (<) and greater
than (>) symbols, and consists of zero or more hexadecimal digits.
In all but one case, the hexadecimal digits represent the BER encoding
of the <value> portion of a particular field. For example, the
value of a BOOLEAN in BER is specified as a single octet,
with nonzero values representing true. An octet is a byte. To specify
a true value for field fred to the API in hexadecimal BER format,
the application program specifies:
When specifying a value for an ANY type, the application program
is required to specify the entire BER field, including the tag, length,
and value portions. It cannot specify only the value, because the
ANY type cannot understand what the possible types are. For example,
if the same application program specifies a BOOLEAN value of true
to the API for a field called fred that is an ANY type, the following
should be specified:
In this example, the first octet represents the tag, which is a universal tag for BOOLEAN. For a full description of how BER tags are encoded see the BER standard. The second octet represents the length of the value portion, a length of 1 octet, and the value is as specified previously. An application program should not use hexadecimal BER when sending information to the API, because error and subtype checking that is normally performed by the API code is not applied to the BER value. The value is assumed to be correctly formed and is inserted into the BER buffer at the appropriate location. Another potential problem is the use of the hexadecimal BER format for ANY types, because improper tags and lengths can be introduced. Hexadecimal BER format is necessary when an INTEGER that is longer than four octets needs to be shipped. Hexadecimal BER allows the application program to circumvent any limitations imposed by the API, but you might encounter problems. When CMIP services receives strings from an application program, CMIP services attempts to decode the strings into a combination of explicit values and constructed values. During decoding, if CMIP services encounters an error in a primitive data type, CMIP services sends to the application program the value for that type in hexadecimal BER format. For example, if the contents of an INTEGER field are too large to fit within four octets, CMIP services sends the application program the INTEGER value in hexadecimal BER format. If CMIP services encounters an error in a constructed data type or a decision data type, such as ANY DEFINED BY or CHOICE, CMIP services sends the application program the entire contents of the constructed or decision type in a single hexadecimal BER value. For example, if CMIP services does not recognize the value of an OBJECT IDENTIFIER, the OBJECT IDENTIFIER value is sent to the application program in hexadecimal BER format. 
|
 Copyright IBM Corporation 1990, 2014 |
