HP OpenVMS Systems Documentation
Compaq PATHWORKS for OpenVMS (Advanced
|accessalert =n||Specifies the number of resource access violations that can occur before the server sends an alert to the alertnames list.||0 to unlimited||5|
|alertnames =list||Specifies a list of the Advanced Server user accounts to receive administrative alerts. To receive alerts, a client workstation must be running the Messenger service. The Messenger service is not supported on OpenVMS servers.||None|
|autodisconnect =n||Specifies the interval, in minutes, that the server waits before dropping the virtual circuit to an inactive client.||0 to unlimited||0 (no automatic disconnect)|
|erroralert =n||Specifies the number of errors that can occur before the server sends an alert to the alertnames list.||0 to unlimited||5|
|logonalert =n||Specifies the number of logon violations that can occur before the server sends an alert to the alertnames list.||0 to unlimited||5|
|maxapplog= n||Specifies the maximum size, in kilobytes, of the Application event log file.||0 to unlimited||100 Kbytes|
|maxauditlog= n||Specifies the maximum size, in kilobytes, of the Security event log file.||0 to unlimited||100 Kbytes|
|maxclients= n||Specifies the maximum number of clients.||1 to unlimited||50|
|maxerrlog= n||Specifies the maximum size, in kilobytes, of the System event log file.||0 to unlimited||100 Kbytes|
|srvannounce =n||Specifies the number of seconds at which the server announces its presence to the network. This keyword has effect only if srvhidden=NO.||1 to unlimited||180 seconds|
|srvcomment =text||Specifies the descriptive comment that the server sends when it announces its presence to the network.||Up to 48 characters, including spaces||PATHWORKS V6.1 for OpenVMS (Advanced Server)|
|srvhidden=YES/NO||Specifies whether the server is hidden on the network. If the server is not hidden, it announces its presence at the interval set by srvannounce and can be viewed using the ADMINISTER SHOW COMPUTERS command.||YES or NO||NO (visible)|
Specifies the services that start automatically when the server is
started. Because services are started in the order they appear in the
srvservices entry, you must ensure that NetLogon appears before any
services that require it.
The Browser service is not controlled by this keyword. It is started when the Server service is started.
|alerter netlogon, browser||alerter, netlogon|
|userpath =path||Specifies the OpenVMS system directory on the server to be used as a default parent directory for home directories for new user accounts.||Up to 255 characters||If you do not specify this keyword, the path is assumed to be:|
188.8.131.52 VMSSERVER Section
The VMSSERVER section allows you to specify parameters related to your
|Specifies a synonym for the autoshare name for an OpenVMS disk device. The value for this keyword is a list of OpenVMS device names (or volume labels) and the share name for each device. (See Section 7.3.3.)||All OpenVMS disk devices are automatically shared, and share names are based on the volume label of each disk device|
|Checks to see if the PATHWORKS Advanced Server user's name matches an OpenVMS user account name. Explicit host mapping is checked and used first. If host mapping has not been specified, the software searches for a matching OpenVMS user name. (See Section 3.1.16.)||YES or NO||YES|
|Used for external authentication of a network user name located in a domain other than the one where the server is located. Checks that the user's domain name matches one of the domains listed, where the PATHWORKS Advanced Server user name matches an OpenVMS user account name. Affects hostmapusevmsnames translations.||List of domains used for OpenVMS host mapping||NULL. The server's domain name is assumed.|
|hostmapdefault =text||Used when no other host mapping definitions apply.||ADMINISTRATOR, PWRK$DEFAULT, GUEST, or REJECT||PWRK$DEFAULT|
Specifies a disk device or list of devices that should not be
automatically shared when the server starts. DFS disk devices are not
Autosharing DFS devices is not recommended.
|Up to 512 characters||dad, _dfs|
Specifies the PATHWORKS cluster alias.
Caution: Do not change pwrkalias by editing the LANMAN.INI file directly. To change the PATHWORKS cluster alias, use the PWRK$CONFIG.COM configuration procedure.
|Cluster alias name||OpenVMS Cluster alias|
184.108.40.206 WORKSTATION Section
The WORKSTATION section specifies how users connect from workstations.
Specifies the name of the domain that includes this server.
Caution: Do not change the domain name by editing the LANMAN.INI file directly. To change the domain name, use the PWRK$CONFIG.COM configuration procedure. Changing the domain name reinitializes the server security database.
|Up to 15 characters||LANGROUP|
You can use the Autoshare and Noautoshare keywords in the VMSSERVER section of the server's LANMAN.INI file to specify a list of autoshare names for the server to create, in addition to the autoshares that the server creates automatically, and to specify the names of devices that you do not want to autoshare. You must restart the server to activate these changes.
If you are running PATHWORKS Advanced Server in an OpenVMS Cluster environment, you can specify the Autoshare and Noautoshare keywords in the node-specific section of the LANMAN.INI file called NODE_servername. The devices you specify in the node-specific section remain local to that server node; they are not served to other OpenVMS Cluster members. Keywords specified in the VMSSERVER section override identical keywords in the NODE_servername section. See Section 220.127.116.11 for more information.
The Autoshare and Noautoshare keywords function as follows:
The Autoshare keyword in the LANMAN.INI file specifies an alias for the autoshare name created by default for an OpenVMS disk device. PATHWORKS Advanced Server creates an autoshare for each mounted OpenVMS disk device when the server starts. To create a more meaningful share name or to map the device name to a DOS format, use the Autoshare keyword in the LANMAN.INI file.
The format is as follows:
The share name cannot exceed 11 characters. Do not append a dollar sign ($) to the device name; the PATHWORKS Advanced Server does this automatically.
For example, Table 4-4, Sample Autoshare Names, shows physical device names and volume labels for disk devices mounted on node DOT and the autoshare names that PATHWORKS Advanced Server creates by default.
The following example shows an Autoshare keyword in the VMSSERVER section of the LANMAN.INI file:
AUTOSHARE = DOT$DUA1=USERS_1,DOT$DUA2=M,DOT$DUA3=WORK5
If you connect to an autoshare, you access the root directory of the disk device. For example, if you connect to the share USERS_1$, you access DOT$DUA1:. The Autoshare keyword directs PATHWORKS Advanced Server to create an autoshare named M$. When a user displays a list of available devices (for example, to create a shared directory), the device M: is listed.
The autoshare name C$ is reserved. By default, PATHWORKS defines C$ as an autoshare alias for PWRK$LMROOT:. If you use the Autoshare keyword to define another volume as C$, the share name will be rejected.
As shown in Table 4-6, Sample Default Autoshare Names, PATHWORKS Advanced Server did not create an
autoshare for the device DOT$DUA3:, because the volume label
WORK_DISK055 exceeds the 11-character limit. But PATHWORKS Advanced
Server allows you to include the device name (DOT$DUA3) in the
autoshare list in the LANMAN.INI file and creates the autoshare WORK5$
18.104.22.168 The Noautoshare Keyword
If the server configuration includes many disk devices, you may want to specify which devices are not shared automatically. By sharing some devices and not sharing others, you can separate OpenVMS disk resources from PATHWORKS Advanced Server resources and reduce unnecessary resource consumption by the server. Entries in the Noautoshare keyword list match OpenVMS device names that contain the search string. For example, the following line in the VMSSERVER section of the LANMAN.INI file specifies search strings DFS, DAD*, and PWRK$DKB300.
NOAUTOSHARE = DFS,DAD*,PWRK$DKB300
With this set of search strings, any OpenVMS device name containing the string DFS, any string containing DAD followed by any characters such as DAD1 and DAD2, and the explicit device PWRK$DKB300 are not shared. The total search string after the equal sign (=) cannot exceed 128 characters.
By default, PATHWORKS Advanced Server does not automatically share devices managed by DECdfs (DFS) software. The default LANMAN.INI file contains the following line in the VMSSERVER section: NOAUTOSHARE = dad,_dfs. DFS is a DECnet VAX and Alpha layered product that provides OpenVMS users with the ability to use remote disks as if they were directly attached to the local system. You cannot assign permissions to DFS devices, so if you override the default and allow PATHWORKS Advanced Server to create an autoshare for a DFS device, users with user or operator privileges cannot access that device. Access to a shared DFS device is restricted to users in the Administrators group.
OpenVMS disk devices mounted clusterwide are offered to users as shared devices (autoshares) by all server nodes in an OpenVMS Cluster system. Devices mounted on a specific server (not clusterwide) are accessible to users connected to that server only.
The LANMAN.INI file contains two sections that govern autoshares: the VMSSERVER section and the NODE_servername section. In an OpenVMS Cluster system, you can make a device available clusterwide by using the Autoshare keyword in the VMSSERVER section. You can restrict device availability to a particular server by using the Autoshare keyword in the NODE_servername section.
The following fragment of a LANMAN.INI file illustrates how you can share disk devices in an OpenVMS Cluster:
[VMSSERVER] AUTOSHARE = PCS524$DKA100=J,PCS524$DKA200=K [NODE_DOT] AUTOSHARE = DUA1001=H,DUA1002=G,DUA1006=I [NODE_TINMAN] AUTOSHARE = DUA1001=H,DUA1002=G
In this example:
For shares on a device to be available from any PATHWORKS Advanced Server node in an OpenVMS Cluster, you must enter the SET COMPUTER/AUTOSHARE_SYNCHRONIZE command on each node in the cluster after the device is available.
This appendix provides information about the following topics:
Before you explore the specific drivers and protocols supported by the
Advanced Server, you should understand both the OSI Reference Model and
the purpose of network interface card drivers. If you already
understand these topics, you can skip to Choosing a Network Protocol,
which includes an overview and description of each protocol that
interoperates with the Advanced Server.
A.1 Understanding the OSI Reference Model
In 1978 the International Organization for Standardization (ISO) developed a model for computer networking called the Open Systems Interconnection (OSI) Reference Model. The model describes the flow of data in a computer network---from the physical connections of the network to the applications used by the end user.
The OSI Reference Model is an idealized version of networking; few systems follow it exactly. However, the model is useful for discussion and comparison of networks.
The OSI Reference Model includes seven layers, as shown in Figure A-1, OSI Reference Model. Each of the layers is responsible for a specific and discrete aspect of networking.
Figure A-1 OSI Reference Model
Figure A-2 Transport Protocol
A network adapter card, also called a network interface card or a network interface controller (NIC), is an adapter board installed in a computer to let it function on a network. The network adapter card provides ports to which the network cable can connect physically. The card physically transmits data from the computer to the network cable, and back.
Every network computer must have a network adapter card driver, a software driver that controls the network card. Every network adapter card driver is configured to run with a certain type of network card.
When choosing network adapter cards, you first must choose cards that support your network's architecture (such as Ethernet or Token Ring) and cabling media (such as Thinnet or twisted pair). You also should consider the tradeoffs of performance and cost.
Performance for network adapter cards depends mostly on bus width and onboard memory. The best performance is achieved when the bus width of the card closely matches the internal bus width of the computer. Onboard memory enables a card to buffer frames going to and from the network. A card with the most memory is not always the best choice. At some point, diminishing returns and the maximum speed of other network components limit the performance gains of onboard memory.
When you consider the cost of network cards, factor in the cost of buying spare cards to replace the ones that fail. You should also ensure that your network hardware budget allows for cable, hubs, repeaters, routers, and other hardware, as well as the labor costs associated with installing them.
Before you decide on a type of network card, make sure that the OpenVMS operating system you are using supports it. Also, make sure the vendor can support your business needs. If you are working with a reseller, check that the reseller has good communication with the card manufacturer.