Document revision date: 15 October 2001
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

Compaq PATHWORKS for OpenVMS (Advanced Server)
Server Administrator's Guide

Previous Contents Index SERVER Section

The SERVER section allows you to specify parameters related to your server, as shown in the following table.

Table 7-6 Server Keywords
Keyword Description Setting Default Setting
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)
srvservices =list 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:


The VMSSERVER section allows you to specify parameters related to your server setup.

Table 7-7 VMSSERVER Keywords
Keyword Description Setting Default Setting
autoshare= devn=sharename
  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
hostmapdomains =(domainname,...)
  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
noautoshare=( device[,...device])
  Specifies a disk device or list of devices that should not be automatically shared when the server starts. DFS disk devices are not automatically shared.

Autosharing DFS devices is not recommended.

Up to 512 characters dad, _dfs
pwrkalias= text 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 WORKSTATION Section

The WORKSTATION section specifies how users connect from workstations.

Table 7-8 WORKSTATION Keywords
Keyword Meaning Setting Default Setting
domain =domainname 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

7.3.3 Defining Autoshares

The PATHWORKS Advanced Server lets you map autoshare names through entries in the LANMAN.INI file. This feature is useful if:

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 for more information.

The Autoshare and Noautoshare keywords function as follows: The Autoshare Keyword

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:

AUTOSHARE=(devname_1=sharename_1,...,devname _n=sharename_n)

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:


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:[000000]. 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:[000000]. 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$ for DOT$DUA3:. The Noautoshare Keyword

The Noautoshare keyword in the LANMAN.INI file specifies the OpenVMS device names that should not be automatically shared.

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.


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. Autosharing in an OpenVMS Cluster Environment

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:

   AUTOSHARE = PCS524$DKA100=J,PCS524$DKA200=K 
   AUTOSHARE = DUA1001=H,DUA1002=G,DUA1006=I 
   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.

Appendix A
Network Protocols

With its open architecture, the Advanced Server software can operate over several popular protocols simultaneously, including:

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

The following list describes each OSI Reference Model layer in detail:

Figure A-2 Transport Protocol

A.2 Choosing a Network Adapter Card

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.

Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement