An NCL command can contain the following elements, in the order
shown:
verb [entity name] [,argument/attribute] [,prepositional_phrase]
and as demonstrated in the following example:
ncl> show node .mass.boston.welder routing circuit ethernet-1 -
_ncl> all status,by user=harry, password=truman
This command shows the current values for all status attributes
for routing circuit Ethernet-1 on node .mass.boston.welder with
access control information supplied. The components of this
command are:
o Verb (or directive): show
o Entity name: node .mass.boston.welder routing circuit
ethernet-1, where:
- node is the global entity class
- .mass.boston.welder is the instance name for class node
- routing identifies the module to which this entity belongs
- circuit is the entity class
- ethernet-1 is the instance name for class circuit. The
entity name reflects the full naming hierarchy for the
entity.
o all status, an attribute specifier
o by (preceded by a comma), a prepositional phrase
o user=harry, password=truman, user name and password used for
access control on the remote node
A comma must separate more than one attribute or argument and
must always precede a preposition. For example:
ncl> show node moosie session control port * all status, all -
_ncl> counters, with direction = outgoing
If the command is directed to the local system, it is not
necessary to include the node entity's class/instance in the
command. For example, this command would create the specified
entity on the local node:
ncl> create routing type endnode
1 – Data Types
1.1 – boolean
The boolean data type has two values, true and false, in an undefined order. On output, the strings appear as true and false. On input, the words true or false may be abbreviated to a single character and are not case-sensitive. The boolean data type does not support the use of wildcard symbols.
1.2 – counters
All counters for an entity are created together and a time of creation is associated with the block. The following counter types are defined: Type Modulus Counter16 2[16] Counter32 2[32] Counter64 2[64] If no modulus is specified, or if the type Counter is specified without reference to a modulus, the modulus 2[64] is assumed. The counter is displayed as an unsigned integer. It cannot be set to zero. In DECnet-Plus, when a counter reaches its maximum value, its next value is zero. Counters never latch (as they did in Phase IV). Consequently, there is never any need to reset or zero the counters. This is called "wrapping counters" because the values wrap around to zero (they are like true modulo 2**n integer values). NCL and other network management applications are able to cope with wrapping counters and can still compute counter differences, even if the second sampled value of the counter is less than the first because of counter wrap. The implicit assumption is that any counter with n (where n is a power of 2) distinct possible values cannot be changed more than n times between samples. Since all DECnet-Plus counters are 64-bit counters, the number of possible values is 2 raised to the 64th power, which is a 20-digit decimal number. Very few counters will ever exceed 32 bits, and it does not appear likely that a 64-bit counter will ever wrap once, let alone twice.
1.3 – DTE address
A DTE Address is an X.25-defined address of some data
terminal equipment (DTE). It is represented as a
latin1string whose length is 0 to 15 digits or wildcard
characters. Wildcard characters can be embedded: the
asterisk (*) matches any sequence of zero or more digits;
the question mark (?) and percent sign (%) match any single
digit.
The user-visible syntax of a DTE address is {digit-
wildcard}. For example, 5084865322 is a DTE address.
1.4 – entity_name
The entity name data type holds an arbitrary name of an entity. It is usually used as a pointer, so that an attribute (or argument) can refer to another entity. Entity names appear in two forms: as a full-entity-name, which includes both the global and the local portion of the entity's name, and as a local-entity-name, which includes only the local portion of the entity's name. A local-entity-name is always assumed to be subordinate to the node executing the directive. A local-entity-name is a convenient method of describing the configuration of the components that comprise a node. Entity names can be wildcarded. An entity class (the sequence of classes) is also a defined type, both as a full class name and as a local class name. For example, routing circuit csmacd-c2 is a local entity name. Neither the full or local class name has a defined order, but allow wildcarding in the same manner as an entity name. Refer to HELP ENTITY_HEIRARCHY for further information.
1.5 – EthernetProtocol
The EthernetProtocol data type consists of two octets, Octet #0 and #1. Octet #0 is transmitted first. The user-visible representation is a pair of octets (each a hex-digit) separated by a hyphen (-). For example 60-03 is a valid Ethernet data type.
1.6 – filespec
Wildcard symbols may be supported, as defined by the target implementation. A file specification appears in one of three forms, depending on the characters it contains. While most file specifications can be entered and displayed as simple names, the inclusion of certain punctuation characters or any control character makes the interpretation of the file specification ambiguous. The following three forms of a file specification may be entered or displayed: o Simple File Specification A file specification is a simple file specification if it consists solely of the following characters: alphanumeric Aa to Zz hyphen - and 1 to 9 dollar sign $ underscore _ period . brackets [ ] angle brackets <> backslash and slash \ / asterisk * percent sign % question mark ? colon : semicolon ; The file specification may be input directly as a quoted file specification or as a binary file specification. On output, it is displayed directly. o Quoted File Specification When the file specification consists of any of the latin1string character set, but is not a simple file specification, then the file is a quoted file specification. On input, a quoted file specification is displayed as a latin1string or as a binary file specification. On output it is displayed as a latin1string. o Binary File Specification If the file specification is not a simple or quoted file specification, it is a binary file specification. Binary file specifications are entered and displayed as an octet-string. For example, '01'H (a^A) The filespec data type for a file specification should be compatible with the transference of file specifications in the DECnet DAP protocol. Since file specifications are interpreted according to the file system at the target entity, there is no guarantee that a file specification for one operating system will be acceptable to another. The target implementation defines the ordering of filespec.
1.7 – fullname
The fullname data type represents globally distinct names and does not have a defined ordering. It does support wildcarding. 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, phasev_nsp.usa.mass.admin.fred is a full name. For more information, refer to the DECdns Management Guide.
1.8 – hex_string
A hex-string represents a string of zero or more
hexadecimal digits (also called semi-octets or nibbles).
A hex-string differs from an octet-string only in that
it allows for an odd number of hexadecimal digits. Two
hex-strings are equal if they have the same length and
hexadecimal digits. Ordering is defined as with an octet-
string, except the comparison is by hexadecimal digit
rather than by octet. The hex-string data type does not
support wildcards.
Enter the hex-string as follows:
' {hex-digit} ' h | % x { hex-digit }
On output, the hex digits A to F are displayed in
uppercase. For example, 'AABBCC'h is a hex-string.
On OpenVMS, the %X format must be used to specify hex
strings in NCL foreign commands. Commands using the ''H
format for hex strings can only be issued at the NCL>
prompt.
1.9 – ID802
An ID (or System ID or LAN Address), is a 48-bit quantity, uniquely assigned over space and used as an Ethernet or IEEE 802.3 CSMA/CD address (and for other purposes). An ID consists of six octets (48-bits) numbered from zero to five. When transmitted on an 802.3 LAN, the least significant bit of Octet #0 is transmitted first and the most significant bit of Octet #5 is transmitted last. The user-visible representation of a system ID is six octets, each displayed as a pair of hexadecimal digits separated by hyphens (-) in the order 0,1,2,3,4,5. For example: 08-00-2B-02-B0-C0
1.10 – IEEE802SNAPPID
The IEEE802SNAPPID (IEEE 802 Sub-Network Access Protocol (SNAP), Protocol Identification) consists of five octets numbered from zero to four. When transmitted on an 802.3 LAN, the least significant bit of Octet #0 is transmitted first, and most significant bit of Octet #4 is transmitted last. The user-visible representation is five octets, each displayed as a pair of hex digits separated by hyphens (-) in the order 0,1,2,3,4. For example, 01-23-45-67-89.
1.11 – implementation
An implementation data type identifies the components that
make up an entity and their implementation versions. An
implementation is a set of components, where each component
is a record containing a registered component name and
a version. The version field may be of any base type,
although it is recommended that the common version or
version-with-edit data type be used. The data type used
for the version field is registered with the component
name.
Example:
ncl> show imp
Node 0
at 2003-04-10-11:08:20.290-04:00Iinf
Characteristics
Implementation =
{
[
Name = OpenVMS Alpha ,
Version = "V7.3-2 "
] ,
[
Name = HP DECnet-Plus for OpenVMS ,
Version = "V7.3-2 3-APR-2003 12:17:03.79"
]
}
1.12 – integer
The integer data type represents signed or unsigned integer
values. The signed integer values may range from -2[31]
to +2[31]-1, following the normal ordering. The unsigned
integer values may range from 0 to +2[32]-1, following the
normal ordering. Remember the following:
o Both signed and unsigned integers may be represented in
4 bytes.
o Accepted integer syntax should be followed when entering
the integer values.
o Wildcard symbols are not supported.
o Ordering is supported.
1.13 – latin1string
The latin1string type represents general, printable
strings. These strings can be of any length (including
zero). The characters in the Latin 1 set are described in
ISO DIS 8859/1 Latin Alphabet Nr 1.
Only printable characters appear in a Latin1String. ASCII
control characters (00 to 1F, 7F, and 80 to 9F (hex))
cannot appear.
On OpenVMS on input and output of attributes, the string
is embedded either quote characters (") or apostrophe
characters ('). Double the quote character to embed a
quote within a string delimited by the same type of
quote character.
On Tru64 UNIX, you are not required to embed the
string in quotes.
1.14 – Network Layer Addresses
Network layer addresses in DNA may be of four types:
o Complete Network Service Access Point (NSAP) address.
o Network Entity Title (NET)-NSAP address with the
selector set to 00.
o Area address-NSAP address minus the last seven octets.
o Address prefix-leading substring of an area address.
None of these data types have a defined ordering or
support wildcarding. Refer to the DECnet-Plus
Introduction and User's Guide for your operating system
for a description of the parts of a DECnet-Plus Network
layer address.
1.15 – node_name
The node-name is used to represent names of nodes using either a full-name or a Phase IV node name. The only difference between a node-name and a full-name is that a node-name also be a Phase IV synonym.
1.16 – null
The null data type is used when the set of possible values is empty. This is used only to indicate that an entity class has no instance identifier, and then (to make the CMIP protocol complete) a null value is sent. The null type cannot be assigned to an attribute or argument.
1.17 – object_identifier
The object-identifier data type represents registered values of the ISO object identifier. Ordering is undefined and wildcarding symbols are not supported. For example, 1.2.3.4.5.6 represents a registered value.
1.18 – octet_and_octet_string
The octet string data type is used to represent arbitrary
data (octets). It is displayed as a hexadecimal string
(that is, HI-n in old NICE form). The length of an octet
string is variable, without a maximum, and may be zero.
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 hex 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.
1.19 – Phase4Name
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.
1.20 – Phase4Address
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.
1.21 – presentation_address
The presentation-address data type defines the format
that should be used for all presentation addresses in OSI
applications.
This data type is a Latin1string. 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>
<id> ::= <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>
1 Value restricted to printed characters
2 US GOSIP requirement
3 Network type identifier (the default is CLNS)
4 Concrete binary representation of network (NSAP) address
value
5 ISO 8348 compatibility
6 RFC1006 preferred format
7 Abstract decimal format for domain specific part (DSP)
8 Abstract binary for DSP
9 Printable character format for DSP (for local use only)
10 Dotted decimal notation (10.0.0.6) or domain name
(twg.com)
11 TCP port number (the default is 102)
12 Internet transport protocol identifier (1 = TCP and 2 =
UDP)
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 Introduction, Planning, and Glossary
manual.
The following examples illustrate the use of this data
type:
1. "my_psel"/"my_ssel"/"my_tsel"
/LOCAL++x0001aa000400d90621 "my_psel"/"my_ssel"/"my_
tsel"/NS+490001aa000400d90621,CLNS
These examples both specify the same presentation
address. The first example uses the LOCAL authority
and format identifier (AFI), which does not have an
initial domain identifier (IDI). The two plus signs
(++) indicate that the IDI is missing. By default, the
network type is CLNS. The second example uses the value
of the LOCAL AFI, which is 49.
2. "256"/NS+a433bb93c1,CLNS|NS+aa3106,CONS
This is a presentation address which has a transport
selector, (no presentation or session selector), and
two network addresses. The first network address is
CLNS (for a connectionless network) and the second
is CONS (for a connection-oriented network). These
network addresses are specified in concrete binary form.
This form can be used only when the concrete binary
representation of the network address is known.
3. #63/#41/#12/X121+234219200300,CONS
This presentation address has presentation, session and
transport selectors, and a single network address which
consists of an AFI (X121) and an IDI (234219200300).
There is no domain-specific part.
4. '3a'H
/TELEX+00728722+X.25(80)+02+00002340555+CUDF+"892796"
This is a network address for X.25. Note that, because
CONS is not specified, the network type defaults to
CLNS.
5. RFC1006+10.0.0.6519,RFC1006
This is an RFC1006 address. The address is not an ISO
network address but the combination of an IP address and
a TCP port number, which is 519 in this example. The IP
address can be specified as either a DNS domain name or
an IP address. For an RFC1006 address, the network type
can be omitted.
1.22 – simple_name
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 wildcarding. 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.
1.23 – time
Four time data types are available for use with NCL.
Each is a built-in data type for management, and does not
support wildcarding symbols. The four are:
o CharacterAbsoluteTime
o BinaryAbsoluteTime
o CharacterRelativeTime
o BinaryRelativeTime
For example, 1992-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 command
ncl> show node busy session control port * all, -
with creation time > 16:45
makes use of the ordering property of the time data types.
1.24 – TransportSelector (TSEL)
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 wildcarding is the same as for an octet-string.
1.25 – UID
The UID data type provides unique space and time identifiers and does not support wildcarding 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 o UIDTime is InstantaneousTime o UIDVersion is Integer o UIDClock is Integer o UIDNodeID is ID
1.26 – version
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. Wildcarding 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: 1. Major 2. Minor 3. Status (with V > T > X) 4. Revision Number Enter the version number as follows: version-status.major.minor.eco For example, T5.0.2 is a valid version number.
1.27 – version_with_edit
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
1.28 – bit_set
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}.
1.29 – end_user_specification
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.
1.30 – TowerSet
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 A-2 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 three 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, the DNA_IP protocol uses an IP address, and
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_OSItransportV1 , 'DEC0'H ] ,
[ DNA_IP , 161.114.94.62 ]
) ,
(
[ 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. The first floor in each of the above
ProtocolTowers specifies the application as
DNA_CMIP-MICE.
The second floor in each of the example ProtocolTowers
specifies the session control version in use. This will
generally be Session Control Version 3
{ DNA_SessionControlV3 }. Nodes capable of SC V3
(Phase V nodes) are also capable of communicating using
SC V2 (the session protocol used by Phase IV nodes).
There are five ProtocolTower values in the example
TowerSet above. Four of these ProtocolTower values were
determined using two possible transport protocols:
{ DNA_OSItransportV1, DNA_NSP }
in combination with these two possible network addresses:
{ 49::00-0C:AA-00-04-00-50-30:00, 41:45418715:00-41:08-00-
2B-16-A8-72:00 }
Still another ProtocolTower was produced using
RFC1006 and/or RFC1859 transport over the IP address:
{ 161.114.94.62 }
RFC1006 (OSI over TCP/IP) specifies the use of OSI
transport Class 0 (TP0) on top of TCP. RFC1859 (DECnet
over TCP/IP) specifies the use of OSI transport
Class 2 (TP2) on top of TCP. This is why towers
containing an IP address will always specifiy
DNA_OSItransportV1 as the transport protocol id.
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.
1.31 – enumeration
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.
1.32 – range
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].
1.33 – record
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. 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] The brackets are optional.
1.34 – sequence_of_a_type
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 OF element-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.
1.35 – set_of_a_type
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.
1.36 – subranges_of_a_base
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: o Integer 8, [-2[7]...2[7]-1] o Integer 16, [-2[15]...2[15]-1] o Integer 32, [-2[31]...2[31]-1] o Unsigned, [0...2[32]-1] o Unsigned 8, [0...2[8]-1] o Unsigned 16, [0...2[16]-1] o Unsigned 32, [0...2[32]-1]
1.37 – variant_records
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.
2 – Verbs
NCL commands form three broad categories:
o Control commands (such as set ncl default, exit, help) enable
the user to perform certain tasks within the NCL utility
environment. These commands perform no network management
functions.
o Database commands (such as, show, set, add, remove) modify
or display characteristics for existing entities, but may not
immediately affect the network configuration or operation.
o Action commands (such as create, delete, enable, disable)
have an immediate impact on the operation of the network,
often causing a state change to an entity. There are many
entity-specific action commands (see the individual entity
description sections for details). Any command that is not a
control command or a database command is an action command.
For descriptions of these verbs, refer to HELP <verb>.
3 – Entity Names
Entities are specified by their full name in the entity hierarchy
and consist of one or more class/instance pairs. For example, the
routing circuit reachable address entity is one of the subentities
that comprises the Routing module. The Reachable Address entity is
subordinate to the Routing Circuit entity, which is subordinate
to the top-level Routing entity in the Routing module. An example
of the entity's full name is:
node 0 routing circuit ether-1 reachable address foo
Node 0 is a class/instance pair for the global Node entity. Node
0 is a designation for the local system and is the default value
for the NCL commands. The "node node-name" element in an NCL command
is thus not required when the operation to be performed is for an
entity on the local system.
For a diagram of the entity heirarchy, refer to HELP
ENTITY_HIERARCHY. For more information on specifying the global
Node entity in an NCL command, refer to HELP NCL SYNTAX
NODE_IDENTIFIER.
4 – Attributes
Certain NCL commands, such as show, can include one or more
attribute specifiers.
You can specify one or several attribute groups, separated by
commas, in a show command. If you specify all, this is equivalent
to specifying all the attribute groups that are legal for a
command. The common attribute group names are:
o all [attributes]
o all characteristics
o all counters
o all identifiers (the default if no attribute group
is specified)
o all status
See the individual show command descriptions to see which
attribute groups are legal for each command.
4.1 – Characteristics
Characteristics describe the operating parameters of an entity
as they are currently defined. You can modify the value of
some characteristics by using the set, add, or remove command.
Some characteristics have read-only values; their values are set
by software and cannot be altered.
Each entity section gives complete information about that
entity's characteristics, if any, and explains if and how they
can be modified.
4.2 – Counters
Counters record the number of times the entity performed a
particular operation or the number of times a certain condition
or event has occurred since the entity was created. In some
cases, a counter counts the number of times a similarly named
event has occurred. Counter values are dynamically maintained by
the system and cannot be reset by the system manager.
4.3 – Identifiers
In most cases, an entity has one identifier: the simple name that
is assigned to it when it is created. This identifier is a unique
instance name within the entity class and cannot be modified
except by deleting the current entity and re-creating it with
a new name. See specific entity description sections for more
information on entities that have multiple identifiers.
4.4 – Status
Status attributes record current conditions of the entity, such
as its state. Usually status attributes are dynamically set by
the system to reflect current conditions set up by different
operations. You can display current status values, but you cannot
directly modify them. However, certain network management actions
(such as enabling or disabling an entity) may alter the values of
status attributes.
5 – Arguments
Certain NCL commands have required or optional arguments.
Arguments can indicate values to be set, data to be operated
on, or instructions for performing a specified task.
6 – Prepositional Phrases
Most NCL commands accept two types of prepositional phrases:
o Use "by" phrase to specify an access control string for remote
system management.
o Use "with" phrase to limit the action of an NCL command to
those entities that match the qualifying condition.
You can specify one or both prepositional phrases in any NCL
command that accepts them. Separate the prepositional phrases by
a comma.
6.1 – By Preposition
The "by" prepositional phrase authenticates that an account or
proxy account for a particular user has been set up with the
proper access control information. Use of the by preposition
is portable to other DECnet-Plus systems. Use the following
format to append access control information using the by
preposition.
by user=username, password=password, account=account, -
proxy={TRUE/FALSE}
For Tru64 UNIX, NCL ignores any use of the by proxy clause
so that the modifier "by proxy=true" (i.e., proxy access
allowed) is always in effect.
If user j_smith has privileges to access the session control
application graphics_exchange on the remote node, he can use
the by preposition as follows:
ncl> ! On node .admin.finance
ncl> show node .admin.artists session control application -
_ncl> graphics_exchange all counters, by user=j_smith, -
_ncl> password=DoNotUse
.
.
.
For Tru64 UNIX, access control does not have any effect when the
NCL command is directed to the local node. This happens because
NCL uses interprocess communication instead of DECnet-Plus to
communicate with node 0, the local node, and therefore the user's
privileges are determined by the user id that NCL is running under.
6.2 – With Preposition
Use the "with" prepositional phrase to qualify an NCL command to
limit the scope of its operation. Also called filtering, this
process is useful in displaying or acting upon only certain
information. The expression supplied as part of the with clause
must be an attribute of the entity (or entities) specified in the
command.
ncl> show session control application *, with maximum instances>0
For every session control application entity on node 0 (the local
system), NCL finds the entities with maximum instances greater
than zero, and returns the identifying information about those
session control application entities.
The with prepositional phrase is a boolean expression that can
use the relational operators as follows:
Symbol Meaning
<> Not equals
< Less than
<= Less than or equal to
> Greater than
>= Greater than or equal to
6.2.1 – Restrictions of With Clause
It is possible (but not improbable) for the value of an
attribute to change between the time that the attribute
value is tested against the with clause value and the time
that the directive is actually issued to the entity. This
limitation can lead to cases such as the following:
ncl> show 0 session control port *, with send queue > 0
Node 0 Session Control Port %XCC354000
AT 1994-11-13-16:32:03.249-05:00I0.269
Status
Send Queue = 0
In this case, the attribute briefly goes non-zero, then
immediately returns to zero again. Unfortunately, the
attribute changed value between the time that it was
sampled by the entity filtering software in the CML (CMIP
Management Listener) and the time that the Show directive
was issued to that entity instance. This is generally
not a problem. Most attributes are stable enough that this
rarely happens.
7 – Using Wildcards
Using an asterisk (*) as a wildcard character in an NCL command
is helpful when the target of a command, particularly a show
command, is not easily identifiable. The asterisk wildcard
represents one or more characters. You can also use a question
mark (?) as a wildcard. This represents a single character, and
can only be used in certain data types, such as simplename.
For Tru64 UNIX, if you use either the asterisk wildcard or the
question mark wildcard in a complete NCL command line entered at
the shell prompt (%), remember to insert the escape character (\)
before the wildcard so that the asterisk or question mark will
not be interpreted by the shell.
The rules for using wildcard characters are as follows:
o Use wildcards only within an entity name (the class name
or the instance name) in an NCL command. Do not use
wildcards within NCL verbs, attributes, or prepositional
phrases. In addition, do not use wildcards in attribute
values unless the use of wildcards is explicitly called
out in the attribute description.
o In all cases, wildcard characters can appear only in the last
class name or last instance value. You cannot use a wildcard
for the global entity node name. All NCL commands that affect
entities include at least two class/instance pairs (the first
being "node node-name" even if it is not specified). For
example:
ncl> show node 0 routing circuit * all status
ncl> show node 0 session control application tp?_appl
ncl> show node 0 session control application ma* all attributes
The first command requests a list of all status information
about all defined circuits. The second command requests a
listing of all applications that begin with tp and end with
_appl and have only one character between tp and _appl. The
third command asks for information about all applications that
start with ma and end with any combination of characters.
o Do not use wildcard characters with NCL control commands.
o If you use wildcard characters with an entity instance name, a
display of all the instances of a class appears.
o NCL supports wildcarding for any directive except create.
o For Tru64 UNIX, using a wildcard to show all subentities when
there are no subentities to be displayed may cause NCL to hang.
To return to the ncl> prompt if this occurs, press <Ctrl/C>.
o For Tru64 UNIX, using a wildcard in the entity class name
results in an operation on the enumerated entities of the
next layer down. For example, the "show node 0 *" command shows
the identities of all module entities on the local system.
o If you use a wildcard in an entity instance name, an operation
occurs on all the instances of a class. For example, show node
0 session control application * shows the identities of all
Session Control Applications.
For Tru64 UNIX, you can wildcard all the local entities on the
local system or a remote system. For example:
ncl> show node .admin.artists *
8 – Node Identifiers
In the absence of a default node entity, if no node is specified
in an NCL command, then the default node-id is 0, which represents
the local node.
You can specify a node-id in an NCL command in various ways, using
either a node name or address. Under certain conditions, the
unqualified node name (often identical to the node synonym) may be
used in an NCL command as the node-id.
8.1 – Addresses
If the name service is interrupted or unavailable, you can
still reach remote nodes to perform management functions. You can
use the remote node's Phase IV address (if the remote node is
configured to have one), or the remote node's NSAP. Refer to the
"Understanding and Creating NSAP Addresses" chapter in the
DECnet-Plus Planning Guide for the Tru64 UNIX or OpenVMS NSAP
format to use.
For example, the following commands all perform the same function:
ncl> show node 12.5 routing circuit syn-0-0
For a Tru64 UNIX system:
ncl> show node 49::00-0C:AA-00-04-00-05-30:20 routing -
_ncl> circuit syn-0-0
For an OpenVMS system:
ncl> show node net$49000CAA000400053020 routing circuit syn-0-0
If both the local and remote nodes are configured to run
DECnet over TCP/IP (RFC 1859), you may refer to the remote node
using the IP address as in:
ncl> show node 16.78.232.13 all
8.2 – Names
Node names can be specified in different ways depending upon
the directory service(s) you are using.
If the local node is configured to use the DECdns name service
and the remote node is correctly registered in the DECdns
namespace, you may refer to the node using a DECdns fullname,
as in:
ncl> show node NS:.lkg.remotenode all
If the local node is configured to use the LOCAL name service
and the remote node is correctly registered in the LOCAL
namespace, you may choose to use the LOCAL fullname, as in:
ncl> show node LOCAL:.remotenode all
If both the local and remote nodes are running DECnet over
TCP/IP (RFC 1859) and the remote host name is somehow
translatable (perhaps using the Hosts Database or DNS/BIND),
you may refer to the remote node using the DOMAIN fullname,
as in:
ncl> show node DOMAIN:remotenode.lkg.dec.com all
8.3 – Unqualified Names and Node Synonyms
A node synonym is a Phase IV-style node name, between 1 and 6
characters long, that is unique within the namespace. This
node synonym is required for Phase IV applications that can
handle only a maximum of 6-character node names.
An unqualified name is the final simplename -- that portion
of the DECdns or LOCAL full name following the last "."
Although this unqualified name is usually identical to the
node synonym, it is not required to be identical to the node
synonym.
An unqualified name may be substituted for a full name in
an NCL command only when the remote node specified in the
command and the local node use the same primary naming
service and their full names are identical except for the
unqualified names themselves.
For example, in the following cases:
LOCAL NODE REMOTE NODE
Full name: ns:.lkg.localnode ns:.lkg.remotenode
Unqualified name: localnode remotenode
Synonym: locnod remnod
Full name: local:.localnode local:.remotenode
Unqualified name: localnode remotenode
Synonym: locnod remnod
You can substitute the unqualified name for the full name in
the NCL command:
ncl> set event dispatcher outbound stream ost_1 -
sink node remotenode
However, for the following examples:
LOCAL NODE REMOTE NODE
Full name: ns:.uct.localnode ns:.lkg.remotenode
Unqualified name: localnode remotenode
Synonym: locnod remnod
Full name: ns:.localnode local:.remotenode
Unqualified name: localnode remotenode
Synonym: locnod remnod
Full name: local:.uct.localnode local:.remotenode
Unqualified name: localnode remotenode
Synonym: locnod remnod
You must specify the full name for the remote node in the
NCL command:
ncl> set event dispatcher outbound stream ost_1 -
_ncl> sink node ns:.lkg.remotenode
Or, on a Tru64 UNIX system:
ncl> set session control proxy dth source end user = -
_ncl> { [ node=local:.remotenode , end user=uic=[0,0]dan ] }
The node synonym cannot be substituted for a full name in
the NCL command. However, in most cases since the unqualified
name and the node synonym are usually identical, it may
appear that the synonym substitution was successful.