![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The following example configures a session control application entity to enable or disable incoming or outgoing connect requests. Refer to DECnet-Plus Network Control Language Reference for more information about these attributes.
ncl> create session control ncl> enable session control ncl> create session control application mail ncl> create session control application foo ncl> set session control application mail - _ncl> outgoing alias true (1) ncl> set session control application foo - _ncl> incoming alias false (2) ncl> enable session control application mail ncl> enable session control application foo
Section F.2 provides more examples of setting up a session control application entity.
The number of connections allowed for an alias equals the number of connections you have specified with the nsp maximum transport connections or osi maximum transport connections characteristic. For more information about configuring the NSP and OSI transports, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration guide.
If your OpenVMS Cluster environment participates in a DECnet Phase V network, you must decide if you want nodes in the OpenVMS Cluster to share common network definitions for such items as network applications. Sharing common network definitions simplifies updates. You change only the shared definitions rather than changing definitions for each member of the OpenVMS Cluster. To share files, copy the following script files from SYS$SPECIFIC:[SYSMGR] (where they are normally created) to SYS$COMMON:[SYSMGR]:
If you do not want certain files shared, keep them in SYS$SPECIFIC:[SYSMGR]. Keep communication-specific startup scripts, such as the following, that contain hardware-specific information in SYS$SPECIFIC:[SYSMGR]:
If the application database is identical on every node in an OpenVMS Cluster environment, you can share those common definitions among all nodes in the OpenVMS Cluster by issuing the following commands:
$ rename sys$specific:[sysmgr]net$application_startup.ncl - _$ sys$common:[sysmgr]net$application_startup.ncl
$ copy sys$specific:[sysmgr]net$application_startup.ncl - _$ sys$common:[sysmgr]net$application_startup.ncl
$ delete sys$specific:[sysmgr]net$application_startup.ncl;*
$ rename sys$specific:[sysmgr]net$application_startup.ncl;* - _$ sys$specific:[sysmgr]net$application_startup_old.ncl;*
A system running DECnet-Plus software can act as a host system that performs the following services for remote client systems:
The Maintenance Operations Protocol (MOP) module allows you to do these tasks. You can downline load or upline dump DECnet Phase IV or Phase V nodes. Table 10-1 lists the data links that MOP supports and the supported functions for those links.
| CSMA-CD and FDDI IEEE 802.3 LAN |
CSMA-CD Ethernet LAN |
HDLC | Synchronous DDCMP |
LAPB |
|---|---|---|---|---|
| Loop requester | Loop requester | Loop requester | Loop requester | Loop requester |
| Console requester | Console requester | Console requester | Console requester | |
| Dump server | Dump server | Dump server | Dump server | |
| Load server | Load server | Load server | Load server | |
| Configuration monitor | Configuration monitor | |||
| Console carrier | Console carrier | |||
| Query requester | ||||
| Test requester |
Either the configuration procedure creates MOP scripts from the information you supply to the prompts or the software provides a permanent client database:
If you start MOP (see Section 10.3) after running your configuration procedure, MOP can do its various tasks provided that you supply all necessary attributes in the NCL command or in the passive load request. This includes:
To downline load an OpenVMS Cluster satellite or to store information about downline loads to specific network servers, you can use the mop client database. The mop client database stores information, so you do not have to enter it every time you issue an NCL command.
The mop client database is the NET$MOP_CLIENT_STARTUP.NCL script file. You can add information to or delete information from it with the NET$CONFIGURE.COM Option 8, "Configure MOP Client database." If you want to add a client, the procedure prompts you for information about the client such as the following:
Note
To automatically configure an OpenVMS Cluster satellite, use the cluster configuration command procedure (CLUSTER_CONFIG.COM). For more information about CLUSTER_CONFIG.COM, refer to the OpenVMS Cluster Systems for OpenVMS guide.
The following sections show the commands to create the mop entities you need to accomplish the tasks described in this chapter. For the variables, substitute values appropriate to your configuration. Refer to the DECnet-Plus Network Control Language Reference for more information about these attributes. Section 10.2.2 shows how to set up the mop client for a network server , while Section 10.2.3 shows how to set up the mop client for an OpenVMS Cluster satellite.
This section shows how to create mop and mop circuits entities. Figure 10-1 shows the mop entity and its subentities.
Figure 10-1 mop Entity
ncl> create mop ncl> enable mop
ncl> create mop circuit csmacd-0 type csma-cd ncl> set mop circuit csmacd-0 - _ncl> link name csma-cd station csmacd-0, _ncl> known clients only value ncl> enable mop circuit csmacd-0 - _ncl> functions (load server, dump server, console requester, - _ncl> configuration monitor, loop requester, query requester, - _ncl> test requester)
ncl> show mop circuit circuit-name operation * all
You can have a variety of network servers on a network. Different kinds of network servers require different levels of information for downline loading and upline dumping. For instance, a terminal server requires the hardware address and the system image. A DECnet Phase V router requires the hardware address, the system image, and the management image or script file, depending on the kind of router you have.
For information about configuring a mop client for an OpenVMS Cluster satellite, see Section 10.2.3.
The following command example shows how to set up and define the characteristics for the mop client subentity for a network server. The mop client is a set of characteristics that represents the target node. These collected characteristics are known as the client database. The example shows all possible information you might need to provide. Refer to your network server documentation for the exact information you need to provide.
ncl> create mop client client-name
ncl> set mop client client-name -
_ncl> circuit circuit-name, - (1)
_ncl> addresses {lan-address, hardware-address}, - (2)
_ncl> secondary loader {filename}, -
_ncl> tertiary loader {filename}, -
_ncl> system image {filename}, -
_ncl> diagnostic image {filename}, -
_ncl> script file {filename}, -
_ncl> management image {filename}, - (3)
_ncl> verification octet-string, - (4)
_ncl> device types {device-types}, - (5)
_ncl> phase iv client address phase-iv-address, -
_ncl> phase iv client name phase-iv-name, -
_ncl> phase iv host address phase-iv-address, -
_ncl> phase iv host name phase-iv-name, - (6)
_ncl> dump file {filename} - (7)
_ncl> dump address address (8)
Note
For clients configured with NET$CONFIGURE, the extended Phase IV DECnet address is automatically added if you supply the Phase IV client address when prompted. For clients configured with NCL, you must manually include the additional address.
aa-00-04-00-ab-fc
To guard against unauthorized access, some network servers require that a 16-digit hexadecimal service password be present in MOP load, boot, or remote console requests. The way the password is set up for a particular server depends on the design of that server. For example, a server might use a console command to change a password held in nonvolatile RAM.
When you attempt to boot the server using the NCL boot or load commands, or to connect to the server's remote console using the ccr command, you must specify the correct password, or the server ignores the request. You can specify the password in the verification client attribute or command parameter.
When using NCP in a Phase IV network, the service password is interpreted as an unsigned integer of up to 16 hexadecimal digits. You can omit leading zeros. In keeping with the definition as an integer, the rightmost digits occupy lower addresses in memory than did the leftmost digits.
When using NCL in a DECnet Phase V network, the service password or verification value is interpreted as an octet string of up to 16 hexadecimal digits. You can omit trailing (rightmost) zeros on input. Leftmost digits occupy lower addresses in memory than do rightmost digits.
If a particular network server provides a command to set up the password value, the password syntax might be like NCP, treating the value as an integer, or it might be like NCL, treating the value as an octet-string. If the server's syntax is like NCP, you need to specify the password in different ways on the server and on the host system.
To convert an NCP-style value to an NCL-style value, do the following:
For example, if you have an NCP service password value of:
123456789ABCD
The NCL verification value is:
%XCDAB896745230100
Note
When using the Common Trace Facility (CTF) to trace MOP activity, the trace shows the bytes of the verification value in the order in which they are transmitted, which corresponds to the order in memory. For the NCL verification value:%XCDAB896745230100you would receive the following trace analysis output:
Verif=CD-AB-89-67-45-23-01-00
The following command example shows how to set up and define the characteristics for the mop client subentity for an OpenVMS Cluster satellite. The mop client represents the target node. You can either use the commands listed below to set up your OpenVMS Cluster satellite or you can use the command procedure CLUSTER_CONFIG.COM. For more information about CLUSTER_CONFIG.COM, refer to the OpenVMS Cluster Systems for OpenVMS guide.
ncl> create mop client client-name
ncl> set mop client client-name -
_ncl> circuit circuit-name, -
_ncl> addresses {lan-address}, -
_ncl> system image {"@net$niscs_laa(dev:[root.])"}, - (1)
_ncl> verification octet-string (2)
Note
OpenVMS Cluster satellites do not use upline dumping; rather, they write their memory image to the boot server's disk.
Section F.6 provides an example of configuring MOP for either an OpenVMS Cluster satellite or a network server.
After you have created the entities, defined their characteristics, and enabled the mop client entities and the mop circuit entities, use the load, boot, loop, query, and test commands to perform MOP operations. (For information about using the load and boot commands, see Section 10.5.1 and Section 10.5.2.) For information about using the loop, test, and query commands, refer to the DECnet-Plus Problem Solving guide. Use the show command to display information about all aspects of the mop entity and MOP operations.
MOP uses logical names to identify directories where it expects to find images or to write dump files. MOP defines the logical names shown in Table 10-2 in NET$STARTUP.COM.
Phase IV DECnet used a set of MOM$XXX logical names. Network server software already installed on your system and network server installation kits that have not yet been updated for DECnet Phase V expect these MOM$XXX logical names. For backward compatibility, NET$STARTUP.COM defines these MOM$XXX logical names to their default Phase IV values.
PROFILE_VMS_016.HTML OSSG Documentation 2-DEC-1996 12:35:12.37
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.