Document revision date: 15 October 2001

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:
	PWRK$LMROOT:[LANMAN.ACCOUNTS.USERDIRS

7.3.2.7 VMSSERVER Section

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
hostmapusevmsnames=YES/NO
	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

7.3.2.8 WORKSTATION Section

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 have a disk device whose volume label exceeds the 11-character limit.
• You want to map a server device to a single letter to accommodate the DOS disk device-naming convention.
• You do not want to autoshare some devices.

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

The Autoshare and Noautoshare keywords function as follows:

• If a volume label is specified with the Noautoshare keyword, that device is not shared, but it is still available by its logical name.
• If a volume label is specified with the Autoshare keyword, that device is shared and mapped to the specified autoshare name.
• If a volume is not specified, PATHWORKS Advanced Server creates an autoshare by default, so long as the volume label does not exceed the 11- character name limit.

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:

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:[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.

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:.

7.3.3.2 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.

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.

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:

• PCS524$DKA100 and PCS524$DKA200 are available as shared devices on autoshares J: and K: on all OpenVMS Cluster server nodes.
• DUA1001 and DUA1002 are available as shared devices on autoshares H: and G: on server nodes DOT and TINMAN, respectively.
• DUA1006 is available as a shared device on autoshare I: on node DOT only.

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

• TCP/IP
• NetBEUI
• DECnet Phase IV or DECnet-Plus

This appendix provides information about the following topics:

• Section A.1, Understanding the OSI Reference Model, describes the seven-layer networking software model.
• Section A.2, Choosing a Network Adapter Card, provides pointers on how to select your network adapters.
• Section A.3, Choosing a Network Protocol, briefly describes the protocols you can use, including TCP/IP, NetBEUI, and DECnet-Plus.

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:

• The Physical Layer is responsible for getting bits from one computer to another. It also regulates the transmission of a stream of bits over a physical medium. This layer defines how the cable is attached to the network adapter card and which transmission technique is used to send data over the cable. It also defines bit synchronization and checking.
• The Data Link Layer packages raw bits from the Physical Layer into frames. A frame is a logical, structured packet in which data can be placed. The Data Link Layer is responsible for transferring frames from one computer to another without errors. After the Data Link Layer sends a frame, it waits for an acknowledgment from the receiving computer. Frames that are not acknowledged are resent.
• The Network Layer addresses messages and translates logical addresses and names into physical addresses. It also determines the route along the network from the source to the destination computer, and it manages traffic problems such as switching, routing, and controlling the congestion of data packets.
• The Transport Layer is responsible for error recognition and recovery, ensuring the reliable delivery of messages. It also repackages messages when necessary by dividing long messages into small packets for transmission. At the receiving end, it rebuilds the small packets into the original message. The receiving Transport Layer also sends an acknowledgment of receipt.
• The Session Layer allows two applications on different computers to establish, use, and end a session. This layer establishes dialog control between the two computers in a session, regulating which side transmits, when, and for how long.
• The Presentation Layer translates data from the Application Layer into an intermediary format. This layer also manages security issues by providing services such as data encryption, and it compresses data to reduce the number of bits that need to be transferred on the network.
• The Application Layer enables end-user applications to access network services.
  When two computers communicate over a network, the software at each layer on one computer communicates with the same layer on the other computer. For example, the Transport Layer of one computer communicates with the Transport Layer on the other computer. As shown in Figure A-2, Transport Protocol, the Transport Layer on the first computer is not involved with how the communication actually passes through the lower layers of the first computer, passes across the physical media, and up through the lower layers of the second computer.

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.

	privacy and legal statement
6556PRO_020.HTML