HP OpenVMS Systems

HP Advanced Server V7.3B for OpenVMS
Release Notes

• The default cluster name in PWRK$CONFIG for new installations is NODE-ALIAS. Previous to Version 7.3A of the Advanced Server for OpenVMS, the default cluster name was NODE_ALIAS. The change has been made to avoid conflicts with DNS servers that do not accept the underscore (_) as a valid character.
• Advanced Servers running in an OpenVMS Cluster share the same copy of the user accounts and shares databases and assume a single role, either a primary domain controller (PDC), a backup domain controller (BDC), or a member server. They operate as a single entity identified by the Advanced Server cluster alias name.
• The Advanced Server cluster alias is transport independent. The DECnet cluster alias name is used by the DECnet transport only. OpenVMS Clusters running TCP/IP may have a cluster alias defined for the purpose of providing failover for Network File System (NFS) clients (this cluster alias is referred to as the TCP/IP cluster impersonator name). HP strongly recommends that the Advanced Server cluster alias not be the same as the TCP/IP cluster impersonator name.
• Do not use the name of the domain as the Advanced Server cluster alias; if they are the same, the NetLogon service will fail to start.
• If you plan to use the TCP/IP transport, ensure that all cluster members on which the Advanced Server will run are in the same TCP/IP subnet.
• In general, before starting the new Advanced Server in a cluster for the first time, reboot all the server cluster members upon which a previous version of the Advanced Server (Advanced Server for OpenVMS or PATHWORKS for OpenVMS) had been running.
• On each cluster member that you want to use as a file and print server, run the Advanced Server configuration command procedure (PWRK$CONFIG.COM) before you start the server. This ensures that each node has its appropriate parameters set and enough resources to run the server. You can then use the SYSMAN utility to start the server on all cluster members.
• All cluster members that will run the Advanced Server must run the same version of the Advanced Server for OpenVMS and share a common:
  • System user authorization file (SYSUAF.DAT)
  • Rightslist file (RIGHTSLIST.DAT)
  • LMF database file (LMF$LICENSE.LDB)
  • Advanced Server data directory location for PWRK$ROOT (PWRK$COMMONROOT:)
  • OpenVMS Registry database location (SYS$REGISTRY:)
    HP recommends that the OpenVMS Registry be configured to run the Registry Server on every Advanced Server node in the cluster. In this way, OpenVMS Cluster failover will help ensure that registry services are available to the file server.
• On an OpenVMS Cluster with multiple system disks, all nodes on which you plan to run the Advanced Server must use the same disk device (PWRK$COMMONROOT:, as noted previously) to store and access Advanced Server data files. Using separate disks on separate cluster members is strictly prohibited.
• If you are using external authentication, HP recommends that you set up external authentication software on all the nodes in the cluster. You can set up external authentication support on nodes that do not run HP OpenVMS file servers. In mixed-architecture OpenVMS Clusters with the Advanced Server for OpenVMS running on the Alpha members, the VAX members can still use external authentication. For details about setting up external authentication in OpenVMS Clusters, refer to the HP Advanced Server for OpenVMS Server Installation and Configuration Guide.
• You can run the License Server on an OpenVMS Cluster with the Advanced Server, where cluster failover provides increased availability. (Cluster failover also provides increased availability for the Advanced Server file server.)
• To gain the benefits of load balancing and failover, clients should connect to the Advanced Server using the Advanced Server cluster alias. Failover occurs when the node to which the client is connected becomes unavailable; the client is reconnected (using the Advanced Server alias) to the cluster member that is least loaded.
  The Advanced Server does not dynamically register the Advanced Server cluster alias with the WINS server. Therefore, you should define a static multihomed entry for the Advanced Server cluster alias in the WINS database. In addition, define a static entry for the Advanced Server cluster alias in the LMHOSTS file of each client that will access the server but is not using WINS. To enable cluster load balancing for service requests from WAN clients outside the server cluster's LAN, you might have to remove the static multihomed entry for the Advanced Server cluster alias from each client's WINS database. (If Windows 95, Windows 98, and Windows NT clients aer configured to use both WINS and DNS for NetBIOS name resolution, they first query the WINS server to resolve the name.) Likewise, remove any static entries for the server cluster alias from the LMHOSTS file and local hosts file on any clients that will access the Advanced Server and have DNS enabled for name resolution on those clients.
  For more information on setting up load balancing, first see Section 3.17, Setting Up Dynamic Cluster Load Balancing in WANs; then refer to the HP Advanced Server for OpenVMS Server Administrator's Guide for an overview of the basic requirements and steps for setting up load balancing, and the HP TCP/IP Services for OpenVMS Management guide for details on configuring the required TCP/IP Services for OpenVMS software.
• Other domain controllers (including the PDC) that are not in the same subnet as the Advanced Server cluster must add an entry for the Advanced Server cluster alias to their LMHOSTS file. This assumes they are not using other methods (WINS or DNS) for resolving NetBIOS names. For domain operations, all the domain controllers in the cluster operate as a single domain controller identified by the Advanced Server cluster alias name, rather than by the specific computer names of the individual cluster members. However, because the LMHOSTS file does not offer any means for mapping multiple IP addresses to a single NetBIOS name, the entry for the Advanced Server cluster alias must be mapped to the IP address of one specific server cluster member. If the Advanced Server is stopped on that cluster member, you must modify the LMHOSTS file on all clients and servers to map the cluster alias name to the IP address of a cluster member on which the Advanced Server is still running. On systems running a Microsoft Windows operating system, the NetBIOS name cache must also be reloaded using the command NBTSTAT -R (capital R required).
  Due to the LMHOSTS limitations noted above, it is difficult (and perhaps unmanageable) to gain the benefits of load balancing and failover using an LMHOSTS file.

• To perform administrative functions on a particular cluster member, you must connect to that member by using its specific node name, rather than the cluster alias.
• The Advanced Server cluster alias is stored in the OpenVMS Registry as value AliasName. Use the PWRK$CONFIG configuration procedure to modify the cluster alias. To display the current Advanced Server cluster alias, as defined in the OpenVMS Registry, use the following command:

  $ REGUTL SHOW VALUE * ALIASNAME

  
  For more information about using REGUTL, refer to the HP Advanced Server for OpenVMS Server Administrator's Guide.
• 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. You can make a device available clusterwide by using the AutoShare value in the OpenVMS Registry. You can restrict device availability using the NoAutoshare value. In addition, you can control the devices to be automatically shared on a single node in the cluster, using the Autoshare_nodename and NoAutoshare_nodename values. Use the REGUTL utility to modify these values, which are stored in the following key:

  SYSTEM\CurrentControlSet\Services\AdvancedServer\ShareParameters

• All Advanced Servers in the same cluster will automatically share the same language (they share the same registry database).

• The client license product authorization keys (PAKs) must be loaded on the system that runs the License Server. In an OpenVMS Cluster, the PAKs must be loaded in a shared license database available to all cluster members.
• When registering and loading a new Advanced Server license PAK on an OpenVMS Cluster, use the LICENSE REGISTER command on one node of the cluster to register the PAK and then use the LICENSE LOAD command on each cluster member to load the licenses on that cluster member. This ensures that Advanced Server license components running on any member of the cluster will be able to detect the new licenses.
• When using server-based licenses for access to file and print services in an OpenVMS Cluster environment, HP recommends that clients connect to the cluster using the Advanced Server cluster alias, if this option is available. Clients connecting using the alias consume one server-based license for each connection to a different cluster member. Clients connecting directly to specific cluster members consume one server-based license for each connection to a different cluster member. A client can map multiple drives and printers to a single server while consuming a single server-based license.
• As noted previously, you can run the License Server on an OpenVMS Cluster with the Advanced Server, taking advantage of cluster failover in the event that license services terminate on the node running the active License Server. Normally, the License Server process (PWRK$LICENSE_S) is started on every node of the OpenVMS Cluster that starts the file server, but only one License Server process is active at any one time. The other License Server processes remain dormant until an event, such as system shutdown or a system failure, causes the active License Server process to stop. When the active License Server stops, one of the dormant License Servers becomes active and continues to provide license services to clients.
  In most cases, HP recommends that you run the License Server on all nodes of the cluster that run the file server, for maximum availability. The exception is the case where the License Server will serve licenses to WAN clients. Then you will want to limit the License Server to running on one node of the cluster. For more information, refer to the HP Advanced Server for OpenVMS Guide to Managing Advanced Server Licenses.
  For additional information on licensing, see Section 3.19, Licensing Support.

This section covers important licensing guidelines that either have not been documented before or need special consideration.

3.19.1 License Enforcement

Advanced Server for OpenVMS requires that clients accessing server resources be appropriately licensed. To conform to this requirement, one of the following must be true:

• The client must present a client-based license before each attempt to connect or reconnect to an Advanced Server for OpenVMS server.
• The Advanced Server for OpenVMS must have a server-based license available to assign to an unlicensed client attempting to use services of the Advanced Server for OpenVMS.

In both cases, the minimum license required to access Advanced Server for OpenVMS services is the Client Access license PWLMXXXCA07.03, or an equivalent client virtual license. This license can be used as either a client-based license or a server-based license.

To access Advanced Server for OpenVMS resources, clients currently using client-based licenses to access PATHWORKS file servers must upgrade their licenses. Clients requesting PWLMXXXCA06.00 licenses need to be upgraded to request PWLMXXXCA07.03 licenses. For more information about licensing and upgrading licenses, see Section 3.19.2, Loading or Upgrading to PWLMXXXCA07.03 Licenses, and refer to the HP Advanced Server for OpenVMS Guide to Managing Advanced Server Licenses.

3.19.2 Loading or Upgrading to PWLMXXXCA07.03 Licenses

Note that if you are loading or upgrading to PWLMXXXCA07.03 client access licenses, the License Server will assign any PWLMXXXCA07.02 licenses first, if they are loaded and available. Remember that a PWLMXXXCA07.03 license is required to access the Advanced Server V7.3B for OpenVMS. HP recommends that you remove the PWLMXXXCA07.02 licenses from the system and/or modify the clients to explicitly request PWLMXXXCA07.03 licenses. For more information, refer to the HP Advanced Server for OpenVMS Guide to Managing Advanced Server Licenses.

3.19.3 Client License Support

HP supports PATHWORKS 32 client license software on Windows 95, Windows 98, Windows NT 4.0, Windows 2000, and Windows XP Professional clients. For your convenience, unsupported PATHWORKS licensing software for other clients remain available on the Advanced Server kit (in specific, PATHWORKS licensing software for DOS and Windows 3.1, and PATHWORKS licensing software for Protected Mode Windows for Workgroups LAN Manager clients).

3.19.4 Client License Software for Windows 2000 and Windows XP Clients

Windows 2000 clients can obtain client license software either from the PATHWORKS 32 distribution kit, the PWLICENSE share, or from HP customer support. Windows XP Professional clients can obtain client license software either from the PWLICENSE share or HP customer support. To enable clients to access the PWLICENSE share and install the client licensing software, make sure that server-based licensing is enabled.

3.20 PWRK$MONITOR and CMT Tools Replaced by PWRK$PWMON Utility

Though the images for the PWRK$MONITOR utility and the client-based Configurator, Monitor, and Tuner (CMT) tools are still included in the Advanced Server for OpenVMS kit, as of Version 7.3 of the Advanced Server for OpenVMS, these utilities can no longer be used with the Advanced Server for OpenVMS.

The PWRK$PWMON utility gathers and displays the data collected by the server. Unlike PWRK$MONITOR, PWRK$PWMON is not invoked automatically at startup. It is invoked from the command line. The PWRK$PWMON utility is provided for use by HP customer support.

3.21 PWRK$LMDMN Process and Startup File Replaced

Advanced Server products prior to V7.3 use the PWRK$LMDMN process to validate logons and replicate the domain security accounts database. Beginning with Advanced Server V7.3 for OpenVMS, the PWRK$LMSRV process provides this functionality instead. As noted in Section 2.6.20.1, Domain Database Replication and Network Logon Performance Improvement, this serves to streamline the operation of the Advanced Server, especially during replication.

The PWRK$LMDMN process and its associated startup command file (PWRK$LMDMN_STARTUP.COM) are no longer part of the software kit and are not installed with the software.

3.22 RMS Protections

RMS sets protection on files and directories based on user identification codes (UICs). As described in the HP Advanced Server for OpenVMS Server Administrator's Guide, the user's UIC determines which categories a user belongs to (System, Owner, Group, World). RMS assigns file protections for each of these categories. The default protections for files and directories are listed in Table 3-2.

The RMS protections associated with a share definition are used to set RMS protections on new files or directories created within that share. When an object (file or directory) in that share is replaced with an object of the same name from another share, the original object's protections are inherited by the object replacing it.

The default values for the directory protections and file protections are listed in Table 3-2, Default Values for RMS File and Directory Protections:

The administrator can change the RMS protection on a specific share by using the ADMINISTER MODIFY SHARE command with the /HOST_ATTRIBUTES qualifier to set the file and directory protections. For example:

$ ADMINISTER MODIFY SHARE share-name -
_$ /HOST_ATTRIBUTES=(DIRECTORY_PROTECTION=(O:WRE,G:WR,W:R), -
_$ FILE_PROTECTION=(O:WRED, G:WR, W: R))

Note that granting write access to a category will automatically grant it delete access as well.

The Advanced Server for OpenVMS supports four different RMS file formats for shares:

• Sequential stream
• Sequential stream_LF
• Sequential fixed-length record
• Sequential undefined

Support of the stream_LF file format is introduced with Advanced Server V7.3A for OpenVMS to accommodate applications that require or recommend such a format.

Define the RMS file format for a share by using the MODIFY SHARE or ADD SHARE/DIRECTORY command. Use the /HOST_ATTRIBUTES=rms-format qualifier to specify one of the following as the format (rms-format):

• SEQUENTIAL_FIXED
• STREAM (the default)
• STREAM_LF
• UNDEFINED

To control user access to print shares, you can assign users to the groups that have the appropriate access permissions, or you can assign permissions directly to shares. For more information, refer to the HP Advanced Server for OpenVMS Server Administrator's Guide.

3.25 Windows NT Printer Management of Large Numbers of Printers

Depending on the processor upon which your Advanced Server runs, the number of printers served might affect performance of Windows NT printer management actions. HP recommends enabling Windows NT printer management only on servers with fewer than 100 printers. HP has found that with 100 or more printers, actions that require enumerating could take a long time. (Note that for some actions, printer enumeration is not obvious.) Windows NT fails to display an hourglass, causing the printer action to appear hung. For information on restrictions relating to Window NT management of server printers, see Section 13.7.8, Windows NT Printer Management Restrictions.

Clients might not be able to access certain files on a shared ODS-2 disk that were originally created on an Advanced Server V7.2 for OpenVMS server. These are files that have long names that include multiple periods. When the periods are encoded, the file names exceed 40 characters in length. (On ODS-2 volumes, the limit for the file name is 39 characters and the limit for the extension is 39 characters.) Advanced Server V7.2 for OpenVMS servers use a method to encode file names that differs from the method that both Advanced Server for OpenVMS (V7.3 and higher) servers and PATHWORKS V6 Advanced Servers use. Therefore, files originally created on disk by an Advanced Server V7.2 for OpenVMS product might not be accessible by clients who connect to an Advanced Server V7.3 for OpenVMS product. Use the PWRENAME utility to rename such files so that they can be accessed by clients. PWRENAME is defined in the command definition file SYS$STARTUP:PWRK$DEFINE_COMMANDS.COM.

To invoke the command, enter the following line:

$ PWRENAME filespec

where filespec is the name of a specific file or the name of a device or directory. If you specify the name of a file, the utility operates on that specific file only. If you specify a device, the utility operates on all files on the device. If you specify a directory, the utility operates on all files in the specified diretory.

Use any of the following qualifiers:

Beginning with Advanced Server V7.3A for OpenVMS, the Macintosh file attribute information (used by the now retired PATHWORKS for Macintosh server) is no longer stored in the ACL of a file's header. This reduces the size of the Advanced Server ACE in the file header by 117 bytes (from 163 bytes to 46 bytes) and reduces the number of files with secondary file headers (extension file headers).

The ACE of a file created by an Advanced Server for OpenVMS prior to Version 7.3A, or by a PATHWORKS for OpenVMS (Advanced Server), would appear as follows (using the indicated OpenVMS DCL command):

$ SHOW SECURITY filename
(UNKNOWN=%X80,SIZE=%D163,FLAGS=%X0C00,ACCESS=%X06900000,DATA=
 %X00000008,%X00000000,%X0000041E,%X3EAC4100,%X511B0000,%XC63F8E74,
 %X1CF4009E,%X2703722A,%X27036E4D,%X05756E4D,%X00000000,%X00000000,
 %X00000000,%X00000000,%X00000000,%X00000000,%X00000000,%X00000000,
 %X010A0000,%X10E51200,%X00800200,%X00000000,%X00000000,%X00000000,
 %X00000000,%X00000000,%X00000000,%X00000000,%X00000000,%XEE710000,
 %XB022F5BF,%X0000FF39,%X00008000,%X00000000,%X00000000,%X00000000,
 %X00000000,%X00000000,%X00000000)

The ACE of a file created on Version 7.3A (or later) of the Advanced Server for OpenVMS now appears as follows:

$ SHOW SECURITY filename
(UNKNOWN=%X80,SIZE=%D46,FLAGS=%X0C00,ACCESS=%X06900000,DATA=
 %X00000008,%X00000000,%X0000041E,%X30064120,%X2A490003,%X8857ACB1,
 %X2AC600A0,%X2C3586F0,%X2C355E40,%X00005E40)

ACEs of files created on earlier versions of the Advanced Server for OpenVMS will be converted automatically to the latter format whenever the file is opened with write access; that is, whenever a client modifies or writes the file. Therefore, no further action is required to convert the ACE format.

 [ODS2]
      UPGRADE_DOS_ACE = 0