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.