HP OpenVMS Systems Documentation

This appendix provides additional examples for some common management tasks.

It includes scripts for the following tasks:

• Event dispatcher
• Session control application
• NSP
• OSI Transport
• Routing initialization password
• MOP

The following NCL script sets up the event dispatcher.

The following example creates the event dispatcher.

ncl> create event dispatcher

The following example creates and enables the default local event sink.

ncl> create event dispatcher sink local_sink
ncl> enable event dispatcher sink local_sink

The following example creates and enables the default local outbound stream.

ncl> create event dispatcher outbound stream local_stream
ncl> enable event dispatcher outbound stream local_stream

The following example creates and enables an additional sink on the local node. Note that sales_sink_device is a logical name that corresponds to printer lpa0:. The logical name was defined with a standard DCL define/system command.

ncl> create event dispatcher sink sales_sink
ncl> set event dispatcher sink sales_sink end user = number = 200
ncl> set event dispatcher sink sales_sink client type = device
ncl> set event dispatcher sink sales_sink device -
_ncl> name = "sales_sink_device"
ncl> enable event dispatcher sink sales_sink

The following example creates an outbound stream to node usa.sales.admin by means of the end-user name, admin_sink.

ncl> create event dispatcher outbound stream admin_obs
ncl> set event dispatcher outbound stream admin_obs sink node -
_ncl> usa.sales.admin
ncl> set event dispatcher outbound stream admin_obs sink end user -
_ncl> = name = admin_sink
ncl> enable event dispatcher outbound stream admin_obs

The following example creates a sink corresponding to the outbound stream admin_obs on node usa.sales.admin. Note that the end-user name of both the sink and the outbound stream must correspond.

ncl> create event dispatcher sink admin_sink
ncl> set event dispatcher sink admin_sink end user -
_ncl> = name = admin_sink
ncl> enable event dispatcher sink admin_sink

The following example creates an outbound stream to a node identified by the DECdns object name, usa.sales.finance_sink.

ncl> create event dispatcher outbound stream finance_obs
ncl> set event dispatcher outbound stream finance_obs sink object -
_ncl> usa.sales.finance_sink
ncl> enable event dispatcher outbound stream finance_obs

The following example creates an outbound stream to a node by means of an address. The example first creates an outbound stream on route66.

ncl> create node route66 event dispatcher outbound stream sales_obs
ncl> set node route66 event dispatcher outbound stream sales_obs -
_ncl> sink address -
_ncl> { -
_ncl> ( -
_ncl> [DNA_CMIP-MICE], -
_ncl> [DNA_sessioncontrolV3, number = 82], -
_ncl> [DNA_nsp], -
_ncl> [DNA_osinetwork, 49::00-13:aa-00-04-00-8a-4f:20 (dec:.zk0.ilium)] -
_ncl> ) -
_ncl> }
ncl> enable node route66 event dispatcher outbound stream sales_obs

The following example enables the event dispatcher.

ncl> enable event dispatcher

The following NCL script creates and sets up several applications.

ncl> create session control application fal
ncl> set session control application fal addresses = {number=17}, -
_ncl> client, -
_ncl> incoming alias true, -
_ncl> incoming proxy true, -
_ncl> outgoing alias true, -
_ncl> outgoing proxy true, -
_ncl> node synonym true, -
_ncl> image name sys$system:fal.exe, -
_ncl> incoming osi tsel

ncl> create session control application mail
ncl> set session control application mail addresses {number=27} -
_ncl> client, -
_ncl> incoming alias true, -
_ncl> incoming proxy true, -
_ncl> outgoing alias true, -
_ncl> outgoing proxy true, -
_ncl> node synonym true, -
_ncl> image name sys$system:mail_server.exe, -
_ncl> user name "mail$server", -
_ncl> incoming osi tsel

ncl> create node 0 session control application task
ncl> set node 0 session control application task addresses {name=task} -
_ncl> client, -
_ncl> incoming alias true, -
_ncl> incoming proxy true, -
_ncl> outgoing alias true, -
_ncl> outgoing proxy true, -
_ncl> node synonym true, -
_ncl> incoming osi tsel

The NCL script example creates and sets up nsp.

ncl> create nsp
ncl> set nsp maximum window 8
ncl> set nsp maximum transport connections 200
ncl> set nsp maximum receive buffers 2000
ncl> enable nsp
ncl> create session control transport service nsp protocol %x04

The following NCL script creates and sets up OSI Transport, including connection-oriented (CONS) and connectionless (CLNS) services.

ncl> create osi transport
ncl> set osi transport cons filters {}

ncl> create osi transport application osit_ivp
ncl> set osi transport application osit_ivp -
_ncl> image name sys$test:osit$ivpresp.com, -
_ncl> user name "systest", -
_ncl> called tsels {%x564F5453495650}

ncl> create osi transport template osi_loop_clns
ncl> set osi transport template osi_loop_clns -
_ncl> network service clns, -
_ncl> classes {4}, -
_ncl> cons template "", -
_ncl> expedited data true, -
_ncl> checksums false, -
_ncl> inbound false, -
_ncl> loopback true

ncl> create osi transport template osi_loop_cons
ncl> set osi transport template osi_loop_cons -
_ncl> network service cons, -
_ncl> classes {4,2,0}, -
_ncl> cons template "", -
_ncl> expedited data true, -
_ncl> checksums false, -
_ncl> inbound false, -
_ncl> loopback true

ncl> enable osi transport

The following NCL script shows the commands you need to set up a routing initialization password.

ncl> create routing type endnode
ncl> enable routing
ncl> create routing circuit hdlc-0 -
_ncl> type hdlc

ncl> set routing circuit hdlc-0 -
_ncl> transmit verifier %x2222222 -
_ncl> explicit receive verification false -
_ncl> receive verifier %x5555555
ncl> enable routing circuit hdlc-0

ncl> create routing permitted neighbor -
_ncl> boston id 08-00-2b-12-34-56
ncl> set routing permitted neighbor -
_ncl> boston verifier %x5555555

The following NCL script sets up MOP on a VAXstation 3100 with an integral Ethernet adapter. This example assumes that the entity csma station sva-0 has already been created and enabled. For the example, the mop circuit name is identical to the csma station name, but this is not necessary. The circuit is enabled for downline loading (load server), upline dumping (dump server), and for the use of the load and boot directives (console requester).

ncl> create mop
ncl> enable mop

ncl> create mop circuit sva-0 type csma
ncl> set mop circuit sva-0 link name csma station sva-0
ncl> enable mop circuit sva-0 function {load server, dump server, -
_ncl> console requester}

The following NCL commands configure an OpenVMS Cluster satellite client. Only the system image file specification characteristic is needed, and this is given in the special quoted form for an OpenVMS Cluster load. The characteristics phase iv client name, phase iv client address, phase iv host name, and phase iv host address are not required, but they are used to display information in the OpenVMS Cluster satellite banner when the downline load of the system image completes.

ncl> create mop client mopsy
ncl> set mop client mopsy -
_ncl> circuit sva-0, -
_ncl> system image {"@net$niscs_laa(sys$sysdevice:<sys10.>)"}, -

_ncl> address {08-00-2b-0d-b9-81}, -
_ncl> phase iv client name valis, -
_ncl> phase iv client address 4.620, -
_ncl> phase iv host name mu, -
_ncl> phase iv host address 4.260

The following NCL commands configure a DECnet/SNA Gateway-CT client node. The gateway runs DECnet Phase IV software, so the Phase IV client characteristics are needed. Also, the example uses two Ethernet addresses: the hardware address, and the Phase IV extended DECnet address.

ncl> create mop client valis
_ncl> set mop client valis -
_ncl> circuit sva-0, -
_ncl> phase iv client name valis, -
_ncl> phase iv client address 4.620, -
_ncl> phase iv host name mu, -
_ncl> phase iv host address 4.260, -

_ncl> system image {sys$common:<sna$csv>snacsa021.sys}, -
_ncl> diagnostic image {mop$load:snacsa$desnx.sys}, -
_ncl> dump file {sys$common:<sna$csv>valis.dmp}, -
_ncl> address {08-00-2b-0f-9e-ca, aa-00-04-00-6c-12}

The console carrier provides access to the remote console subsystem (ASCII console) of a network server on a LAN. The console carrier interface does not use NCL. Instead, you enter commands at the operating system to use the console carrier.

G.1 Using the Console Carrier on OpenVMS Systems

To use the console carrier, specify the console requester function when you enable the mop circuit (discussed in Section 10.2.). The console carrier user interface does not use NCL. Instead, DECnet-Plus uses the DCL command, set host/mop, to run the console carrier requester program.

In addition, the target system must support remote console access. See your network server documentation for information about remote console access support.

The following command examples show how to invoke the set host/mop command:

$ set host/mop client-name -
_$ /disconnect = disconnect-character - (1)
_$ /break = break-character (2)

1. Specifies the disconnect character. The default is the backslash (\). To disconnect from the remote console, press and hold down the Control (Ctrl) key while pressing the disconnect character.
   Choose the disconnect character from the set a-z (except for s and q), @, [, \, ], ^, _. Other characters might work, depending on the terminal keyboard. Enclose special characters in quotes to prevent DCL from misinterpreting them.
2. Specifies the break character. The default is the right bracket (]). To send a break condition to the remote console, press and hold down the Control (Ctrl) key while pressing the break character.
   Choose the break character from the set a-z (except for s and q), @, [, \, ], ^, _. Other characters might work, depending on the terminal keyboard. Enclose special characters in quotes to prevent DCL from misinterpreting them.

Alternatively, you can use the following format to access a client system that is not defined in the client database. For example:

$ set host/mop -
_$ /circuit = circuit-name - (1)
_$ /address = lan-address - (2)
_$ /verification = octet-string - (3)
_$ /disconnect = disconnect-character -
_$ /break = break-character

1. Specifies the name of the MOP circuit over which the target system can be reached.
2. Specifies the LAN hardware address associated with this client.
3. Specifies the verification string. The value is an octet string of up to 16 hexadecimal digits. Enter the value as "%X" followed by an even number of digits. For more information about specifying a verification string, see Section 10.2.2.1. The default is %X0000000000000000.

The console prompt for the network server to which you have connected appears on your terminal. For example:

>>>

At the server prompt, you can enter commands appropriate to your server. For information about what commands your network server supports, see your server documentation.

For example:

$ set host/mop slug /address=aa-00-04-00-33-30

Connection established to remote system AA-00-04-00-33-30
Press Ctrl/\ to disconnect, Ctrl/] to send break
DEMSA Console
ROM Firmware Version:   8-AUG-1995 16:08

Processor State:       *RUNNING*
Software state :        Running

>>>

This appendix describes the correspondence between DECnet Phase IV (NCP) and DECnet Phase V (NCL) network management commands for network managers who use VAX P.S.I. (X.25) in their networks.

The material is organized from the Phase IV network manager's viewpoint. Each section describes the changes made in a specific area of Phase IV network management to support DECnet Phase V. For more information about DECnet Phase V network management, refer to the DECnet-Plus Network Control Language Reference.

H.1 Phase IV Databases and DECnet Phase V Entities

For X.25 network managers, the major Phase IV manageable structures are:

• X25-ACCESS
• X25-PROTOCOL
• X25-SERVER
• X29-SERVER
• LINE
• CIRCUIT

In DECnet Phase V, network management operates on manageable entities. These entities are organized in a hierarchical structure. The topmost entity in this structure is the node entity. Below this entity is a series of modules, each of which provides a particular network service. The following DECnet Phase V modules are used by X.25:

• X25 Access
• X25 Client
• X25 Server
• X25 Protocol
• LAPB
• LLC2
• Modem Connect

The X25 Access module provides management directives for creating and deleting the entity and starting and stopping its operation.

The x25 access entity has the following subordinate entities:

• template --- Specifies outgoing call parameters.
• filter --- Defines discrimination criteria for incoming calls received by the X25 Protocol module or a local X25 Client module.
• reachable address --- Supports the mapping between OSI NSAP addresses and DTE addresses when using OSI Connection-Oriented Network Service (CONS).
• port --- Represents status information relevant to each X.25 virtual circuit currently in use.
• dte class --- Categorizes dte entities.
• application --- Specifies applications that wish to receive incoming calls.
• security dte class --- Controls incoming and outgoing calls. The security dte class entity has a subordinate entity, remote dte. An x25 access security dte class remote dte is a collection of access control attributes that control incoming calls from and outgoing calls to a particular remote DTE.
• security filter --- Defines access control information that can be applied to one or more filters. The value of the security filter attribute in an x25 access filter entity determines the required x25 access security filter.

You can create X25 Access filters with the VAX P.S.I. configuration procedure. Use the Declaring a Network Process Section, as follows:

1. On the introduction screen to Declaring a Network Process Section, answer YES to the question:

   Do you want X.25 or X.29 programs to specify filter names in $QIO(IO$_ACPCONTROL) calls?

2. On the next screen, answer NO to the question:

   Do you want IO$_ACPCONTROL calls issued by your programs to name any dynamic filters?

3. On the next screen, answer NO to the question:

   Do you want IO$_ACPCONTROL calls issued by your programs to name any dynamic filters?

4. On the next screen, answer YES to the question:

   Do you want IO$_ACPCONTROL calls issued by your programs to name any static filters?

5. On the following two screens you can set up the attributes for the X25 Access filter. You will be prompted to enter network process filter information. You must complete the following fields:
   • Filter name: OSI transport
   • Call data value: for example, %X03010100
   • Call data Mask: for example, %XFFFFFFFF
   
   The filter name can be set to any name. However the name used must match the name entered as the X25 Access template name and as the OSI transport CONS template name. The OSI transport template attribute cons template is case sensitive and must match the OSI transport attribute cons filters exactly.
   The call data value and call data mask entries are used by VAX P.S.I. to determine whether an inbound network connect should be passed to transport.
   For other fields, use the default value provided.
   You can set up a security filter corresponding to this X25 Access filter in the Incoming Security for Network Processes Section of the VAX P.S.I. configuration procedure.

The X25 Client module provides management directives for creating and deleting the entity and starting and stopping its operation.

The x25 client entity has no subordinate entities.

H.1.3 X25 Server

The X25 Server module provides management directives for creating and deleting the entity and starting (or restarting) its operation.

The x25 server entity has the following subordinate entities:

• client --- Describes a client system that might use this X25 server.
• security nodes --- Defines a set of rights identifiers associated with calls issued by the X25 Server module (on behalf of the X25 client at an accessing system) to the X25 Access module at the gateway system. These rights identifiers are used when making access control checks on the DTE class specified when a call is made.

The X25 Protocol module provides management directives for creating and deleting the entity. Because it is essentially a collection of dte entities, it does not provide directives for starting and stopping the module as a whole.

The x25 protocol entity has the following subordinate entities:

• dte --- Defines the attributes of each DTE in the system that is connected to an X.25 network. The dte entity has the subordinate entity, pvc, that defines the attributes of an X.25 permanent virtual circuit in use at this DTE.
• group --- Defines a closed user group (CUG) used by this system.

The LAPB module provides management directives for creating and deleting the entity.

The lapb entity has the following subordinate entities:

• link --- Defines LAPB attributes for use over a physical line.
• port --- Represents status information about each access point to the Data Link layer currently provided by the LAPB module.

The LLC2 module provides management directives for creating and deleting the entity.

The llc2 entity has the following subordinate entities :

• sap --- Defines LLC2 attributes for use over a LAN station. The sap entity has a subordinate entity, link, that defines the LLC2 attributes of a link that uses this SAP.
• port --- Represents status information about each access point to the Data Link layer currently provided by the LLC2 module.