![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The octet data type represents a single byte (8 bits) of data. While similar to an octet-string of length 1, it has a slightly different user-visible representation. The ordering of octet is defined by considering an octet as an unsigned 8-bit quantity. Two octets are equal only if they have the same length and the same octets.
On output, the hexadecimal digits A to F are uppercase.
The octet data types do not support the use of wildcard symbols.
The user-visible representation of an octet-string appears as follows:
' {octet} ' h | % x {octet}
For example, %x89ABCDEF or '89ABCDEF'h are valid representations.
The Phase4Name data type is used for Phase IV-style node names. It is a Latin1String whose length is restricted from 1 to 6 characters from the set A to Z, or 0 to 9, at least one of which is a letter. The type is ordered as a normal character string. Node names can contain wildcard symbols: the asterisk (*) matches a sequence of zero or more characters; the percent sign (%) matches any single character.
For example, LEAF97 is a Phase4Name.
The Phase4Address data type is used for Phase IV-style node addresses. It is an unsigned, 16-bit integer where the least significant ten bits (bits 0 to 9) encode the local address and the most significant six bits (bits 10 to 15) encode the area number. Local address is an integer from 1 to 1023 and area number is an integer from 1 to 63. The area number zero and the local address zero are reserved to represent all areas and all local addresses, respectively, and are represented by the asterisk (*) character when user-visible. Phase4Address data types are ordered by the value of the equivalent unsigned integer.
For example, 4.83 is a Phase4Address.
The presentation-address data type defines the format that should be used for all presentation addresses in OSI applications.
This data type is a Latin1 string. Its values must conform to the following syntax (shown in BNF). This syntax is an extension of the Internet standard for representing OSI presentation addresses.
<presentation-address> ::= [[[ <psel> "/" ] <ssel> "/" ]
<tsel> "/" ] <network-address-list>
<psel> ::= <selector>
<ssel> ::= <selector>
<tsel> ::= <selector>
<selector> ::= '"' <otherstring> '"' (1)
| "#" <digitstring> (2)
| "'" <hexstring> "'H"
| ""
<network-address-list> ::= <network-addr> [ "|" <network-addr> ]
| <network-addr>
<network-addr> ::= <network-address> ["," <network-type> ]
<network-type> ::= "CLNS" | "CONS" | "RFC1006" (3)
<network-address> ::= "NS" "+" <dothexstring> (4)
| <afi> "+" <idi> ["+" <dsp>]
| <idp> "+" <hexstring> (5)
| RFC1006 "+" <ip> ["+" <port>] (6)
<idp> ::= <digitstring>
<dsp> ::= "d" <digitstring> (7)
| "x" <dothexstring> (8)
| "l" <otherstring> (9)
| "RFC1006" "+" <prefix> "+" <ip> ["+" <port>
["+" <tset>]]
| "X.25(80)" "+" <prefix> "+" <dte>
[ "+" <cudf-or-pid> "+" <hexstring> ]
| "ECMA-117-Binary"
"+" <hexstring> "+" <hexstring>
"+" <hexstring>
| "ECMA-117-Decimal"
"+" <digitstring> "+" <digitstring>
"+" <digitstring>
<idi> ::= <digitstring>
<afi> ::= "X121" | "DCC" | "TELEX" | "PSTN"
| "ISDN" | "ICD" | "LOCAL"
<prefix> ::= <digit> <digit>
<ip> ::= <domainstring> (10)
<port> ::= <digitstring> (11)
<tset> ::= "TCP" | "IP" | <digitstring> (12)
<dte> ::= <digitstring>
<cudf-or-pid> ::= "CUDF" | "PID"
<decimaloctet> ::= <digit> | <digit> <digit>
| <digit> <digit> <digit>
<digit> ::= [0-9]
<digitstring> ::= <digit> <digitstring>
| <digit>
<domainchar> ::= [0-9a-zA-Z-.]
<domainstring> ::= <domainchar> <otherstring>
| <domainchar>
<dotstring> ::= <decimaloctet> "." <dotstring>
| <decimaloctet> "." <decimaloctet>
<dothexstring> ::= <dotstring>
| <hexstring>
<hexdigit>:: ::= [0-9a-fA-F]
<hexoctet> ::= <hexdigit> <hexdigit>
<hexstring> ::= <hexoctet> <hexstring>
| <hexoctet>
<other> ::= [0-9a-zA-Z+-.]
<otherstring> ::= <other> <otherstring>
| <other>
Keywords can be specified in either uppercase or lowercase. However, selector values are case sensitive. Spaces are significant.
Note that you can find more information about network (NSAP) addresses in the DECnet-Plus for OpenVMS Introduction and User's Guide.
The following examples illustrate the use of this data type:
This base data type allows most names to be represented as unquoted strings. The simple-name data type also allows some values to be expressed as quoted strings and other values as binary data.
The simple-name data type does not have a defined ordering but it does support the use of wildcards. The supported symbols include the asterisk (*), which matches any sequence of zero or more characters, and the question mark (?), which matches any single character.
For example, tweedle_dee, "tweedle dee", and %x4700050020AA0004005310 are simple names.
Four time data types are available for use with NCL. Each is a built-in data type for management, and does not support wildcard symbols. The four are:
For example, 1995-08-18-14:47:47-05:00I0.168 is a time data type of the BinaryAbsoluteTime data type.
You can order time values. For example, the following command makes use of the ordering property of the time data types:
ncl> show node busy session control port * all, with creation time > 16:45
The TransportSelector (or TSEL) data type is used by OSI Transport to identify a particular OSI Transport port.
A TransportSelector is an octet string, of 0 to 32 octets in length.
The user-visible representation, ordering, and use of wildcards is the same as for an octet-string (Section B.1.22).
The UID data type provides unique space and time identifiers and does not support wildcard symbols. No two UIDs are ever the same. A UID is hexadecimal. For example, 7834E80-E519-1119-8D8D-08002B16A872 is a valid UID.
The user-visible presentation of a UID consists of four fields, separated by spaces:
UIDTime UIDVersion UIDClock UIDNodeID
where
The version data type is used to encode a version number of a particular entity (usually a module or node entity) in a standard way. Wildcard symbols are not supported.
The version number contains the four subfields: status, major version, minor version, and an edit or revision number.
The version status subfield indicates whether the version is Approved (V), Field Test (T), or Draft (X).
The order of version numbers is defined by checking the fields in the order:
Enter the version number as follows:
version-status.major.minor.eco
For example, T5.0.2 is a valid version number.
The version number with an edit number is commonly used and is represented as a separate type called version-with-edit.
Enter the number as follows:
version_number-edit_number
For example:
X5.0.13-967
The bit-set data type is an efficient means of describing small quantities of a base type's sets of values.
The order of a bit-set is defined by A <= B if A is a subset of B. A = B means normal set equality. No wildcard symbols are defined for bit sets.
The user-visible representation of a set is to enclose the set values in bracketing characters, with the values separated by commas. Braces are used as bracketing characters for both input and output. For example, {0,2,3,5}.
An end-user-specification is defined by session control and used as an address of a particular end user. This is generally equivalent to Phase IV object name and number.
The user-visible syntax is the standard syntax for a record. For example, Number=25 and Name=FAL are valid.
Note that end-user-specification does not work as a filter attribute in a with clause.
The TowerSet data type is used at the DNA session control interface to specify addressing information. The idea behind the tower set is that a given networking service may be accessible through many different combinations of protocols and addresses. The TowerSet data type is intended to allow the end user to specify any arbitrary combination of protocols and addresses to session control. Of course, most end users do not want to do this, so normally the end user would specify the name of the service, and DNA session control would look up the TowerSet of the service (its address) using the DNA Naming Service, and would try to establish a connection using any one of the possible ways of connecting to the remote service. Table B-2 shows TowerSet levels of specification.
| TowerSet | A set of ProtocolTower |
| ProtocolTower | A sequence of Floor |
| Floor | (Protocol ID, address) pair |
| Protocol ID | Name or number of a network protocol |
| Address | Address of this service with respect to a protocol |
A ProtocolTower specifies a layering of protocols that can be used to access the network service. The top floor in a ProtocolTower corresponds to the highest-level protocol and the bottom floor to the lowest-level protocol. Usually the Network layer (layer 3 in the OSI model) is the lowest level of protocol needed.
A Floor is a particular (protocol, address) pair used within a ProtocolTower to access a remote service. The data type of the address is a function of the protocol. For example, the DNA_OSInetwork protocol uses an NSAP as the address, whereas DNA_SessionControlV3 uses an end-user-specification. Some protocols do not require an address; for example, the Application layer (top layer) does not require an address.
A protocol ID is the name or number of a protocol.
An address value specifies the SAP (service access point) to be used by the application for this particular protocol.
For example, the node entity's address attribute is given by NCL as:
Address =
{
(
[ DNA_CMIP-MICE ] ,
[ DNA_SessionControlV3 , number=19 ] ,
[ DNA_OSItransportV1 , 'DEC0'H ] ,
[ DNA_OSInetwork , 41:45418715:00-41:08-00-2B-16-A8-72:21 ]
) ,
(
[ DNA_CMIP-MICE ] ,
[ DNA_SessionControlV3 , number=19 ] ,
[ DNA_OSItransportV1 , 'DEC0'H ] ,
[ DNA_OSInetwork , 49::00-0C:AA-00-04-00-50-30:21 ]
) ,
(
[ DNA_CMIP-MICE ] ,
[ DNA_SessionControlV3 , number=19 ]
[ DNA_NSP ] ,
[ DNA_OSInetwork , 41:45418715:00-41:08-00-2B-16-A8-72:20 ] ,
) ,
(
[ DNA_CMIP-MICE ] ,
[ DNA_SessionControlV3 , number=19 ] ,
[ DNA_NSP ] ,
[ DNA_OSInetwork , 49::00-0C:AA-00-04-00-50-30:20 ]
)
}
The above example shows all the possible methods of connecting to the CML (CMIP Management Listener) on a DECnet-Plus node. There are four ProtocolTower values in this TowerSet because there are two possible transport protocols that can be used:
{ DNA_OSItransportV1, DNA_NSP }
There are also two possible network addresses where this node can be reached:
{ 49::00-0C:AA-00-04-00-50-30:20, 41:45418715:00-41:08-00-2B-16-A8-72:20 }
All possible combinations of members of these two sets will produce four combinations. The upper two floors of each ProtocolTower are identical.
Usually, the node registers its TowerSet automatically with the naming service; the end user would not enter it. However, if the naming service is unreachable from the network manager's node, it may be necessary to manually enter a TowerSet. Enter a single ProtocolTower. It may be possible to omit the upper floor since it is not yet used by applications.
If the node entity identifier is formally defined to be a TowerSet, NCL allows the end user to enter the identifier by Phase IV address and by NSAP. In such cases, NCL infers the TowerSet from a much more abbreviated form of address.
The enumeration data type represents a collection of defined, named values, (for example, Sunday, Monday...Saturday). A keyword, which may be one or more words, names each value. An integral number code represents each value in the protocol and in the interfaces. The architect constructing this type assigns the codes and keywords.
Codes and keywords as defined here also identify entity classes, attributes, directives, responses, exceptions, event reports, and arguments.
On output, the keyword is presented as defined. The case used in the definition is preserved.
On input, any legal abbreviation of the keyword is allowed. Legal abbreviation is determined by the director architecture, allowing for some flexibility depending on the parser.
The range type constructor defines a new type whose value is a set of values selected from a base type. The set is defined by specifying an upper and lower boundary of the set. The base type must have a well-defined ordering of values. Ranges can be defined for integers, enumerated types, latin1strings, and so forth. The order of a range type is undefined. range values may not contain wildcards.
For example, if a value type is defined as a range of integers, an example might be: [10...100].
A record is a data type containing one or more fields, each with its own pre-defined data type. Recursive definitions are not allowed. The fields can be either a fixed collection, that is, all the fields always appear and always in the defined order, or a variant record (described in Section B.2.10).
A record type's order is defined by the order of the fields defined in the records.
The fields within a record may contain wildcard symbols, as allowed by their type. For example,
[node=usa:.boston.admin, EndUser=michael]
A-type can be replaced by any one type, such as a LIST OF type. Sequence is used where the number of elements in a list varies, the order of the elements in the list has meaning, and the elements of a list are repeated. The syntax for declaring a sequence is:
SEQUENCE OFelement-type
The order of two sequences is undefined. Wildcard symbols are allowed within the elements of the list, as allowed by the base type.
On output, braces are used to bracket the elements. For example, here is a sequence of simple-names:
{ Diane, Patty, Mark, Cyndi, Carly }
Note that sequences do not work as filter attributes in a with clause.
Set is used where the number of elements in the set varies, the order of the elements in the set has no meaning, two copies of an element value are equivalent to a single copy of the element, and the element type has more possible values than can be efficiently represented using a bit-set.
Set A <= set B if A is a subset of B. A < B is not defined on Sets. A = B means normal set equality. Wildcard symbols are not allowed within the set.
On output, braces bracket the elements.
Note that sets do not work as filter attributes in a with clause.
New types can be constructed by limiting the values of an existing type to a subset in the new type. The mechanism used to specify the subset depends upon the base type. The user-visible representation is identical to the base type. The order of a subrange type is inherited from the base type.
For integers and enumeration, the subrange is defined by the low and high values in the base type. The user-visible representation is that of the base type. For example:
TYPE
CircuitCost = Integer [1...32];
The following integer subranges are already defined:
Variant records extend the record type constructor by allowing the structure of a record to vary, depending upon the value of one of the nonvarying fields.
The user-visible representation is the same as that for a record (Section B.2.6.)
NCL_PROFILE_036.HTML OSSG Documentation 2-DEC-1996 12:49:05.76
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.