HP OpenVMS Systems Documentation

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

7.3.2.7 VMSSERVER Section

7.3.2.8 WORKSTATION Section

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.