Document revision date: 19 July 1999

In versions of OpenVMS prior to Version 7.2, the range of densities that users were able to set for magnetic tape devices was limited. With OpenVMS Version 7.2, that range has been extended to include any density that a specific tape drive supports. Because of this enhancement, exchanging tapes among tape drives with different default settings for density is much easier.

Using multiple tape densities is discussed in the OpenVMS System Manager's Manual.

You can set densities using the following DCL commands:

• $ INITIALIZE
• $ SET MAGTAPE (for tapes only)

Refer to the OpenVMS DCL Dictionary for details about using the /DENSITY qualifier with these DCL commands.

You can also set densities using the following system management utilities:

• $ MOUNT (with /FOREIGN qualifier for mounted tapes)
• $ BACKUP

Refer to the OpenVMS System Management Utilities Reference Manual for details about using the /DENSITY qualifier with these utilities.

Multiple tape density support is provided by changes in the QIO interface. These changes are guided by device/density tables in system libraries and the corresponding class drivers. This enhancement functions with tape drives that support multiple tape density switching via the standard MODE_SENSE and MODE_SELECT mechanisms. The QIO interface uses the information in the libraries and drivers to identify and match valid densities and compressions with tape drives.

For more information about enhanced tape density support, refer to the OpenVMS I/O User's Reference Manual.

3.25 TCP/IP Services for OpenVMS

With OpenVMS Version 7.2, the DIGITAL TCP/IP Services for OpenVMS Version 5.0 product replaces Version 4.2 (also known as UCX). Version 4.2 is no longer supported, but will remain on your OpenVMS system after the upgrade to Version 5.0. Version 5.0 completes the change initiated several releases ago when the product name changed from ULTRIX Connection (UCX) to DIGITAL TCP/IP Services for OpenVMS.

The identifier UCX is replaced with TCP/IP in the following items:

• Registered product facility code
• Management command prompt
• All messages, examples, and banners
• All product file names and databases
• All logical names
• All associated product documentation

OpenVMS Version 7.2 provides backward compatibility for all UCX logical names and support for UCX> commands.

New TCP/IP features include:

• A new, reliable, commercial-ready kernel, ported from the DIGITAL UNIX Version 4.0D IPv4 protocol stack.
  This kernel incorporates several performance enhancements either developed or extended by Compaq.
• A new option for dynamic routing---the gateway routing (GATED) daemon.
  GATED supports the following protocols:
  • Routing Information Protocol (RIP) Version 1 (RFC 1058) and RIP Version 2 (RFC 1388)
    RIP is a commonly used interior protocol that selects the route with the lowest metric (hop count) as the best route.
  • Open Shortest Path First (OSPF) Version 2 (RFC 1583)
    Another interior routing protocol, OSPF is a link-state protocol (shortest path first) and better suited than RIP for use in complex networks with many routers.
  • Exterior Gateway Protocol (EGP) (RFC 904)
    EGP exchanges reachability information between autonomous systems. An autonomous system is usually defined as a set of routers under a single administration, using an interior gateway protocol and common metric to route packets. Autonomous systems use exterior routing protocols to route packets to other autonomous systems.
  • Border Gateway Protocol (BGP) (RFC 1163 RFC 1267 RFC 1654)
    Like EGP, BGP exchanges reachability information between autonomous systems, but supports nonhierarchical topologies. BGP uses path attributes to provide more information about each route. Path attributes can include, for example, administrative preferences based on political, organizational, or security considerations.
  • Router Discovery (RFC 1256)
    This protocol is used to inform hosts of the availability of hosts it can send packets to and is used to supplement a statically configured default router.
• A new management interface based on the following UNIX management utilities:

  UNIX Utility	Function
  ifconfig	Configures or displays network interface parameters, redefines an address for a particular interface, or sets options such as an alias list, broadcast address, or access filter.
  netstat	Displays network statistics of sockets, data link counters, specified protocols or aliases, network interfaces, and a host's routing table.
  sysconfig	Displays and maintains the network subsystem attributes.
  route	Manually manipulates the routing table.
  arp	Controls and displays ARP tables.

  Important If you are not familiar with these UNIX utilities, you should continue to use the OpenVMS-style management commands provided with the product and available at the TCPIP> prompt.

• New support for Dynamic Host Configuration Protocol (DHCP). DHCP provides a centralized approach to the configuration and maintenance of IP address space. It lets the system manager provide dynamic allocation of IP addresses from a single OpenVMS host.
• A new implementation of DNS/BIND based on the Internet Software Consortium's (ISC) BIND 8.1.
• A new method for cluster load balancing.
• New implementations of NTP and SNMP.
• A new TELNET port driver QIO programming interface.

Other changes for OpenVMS Version 7.2 include the following:

• Enhanced messages
• Obsolescense of some management commands
• Timezone configuration changes
• Enhanced socket-based application programming interface
• FTP enhancements, including support for Extended File Specifications
• NFS and SMTP changes

For more information about these features and changes, refer to the release notes available in the DIGITAL TCP/IP Services for OpenVMS Version 5.0 kit.

For information about installing DIGITAL TCP/IP Services for OpenVMS, refer to the manual DIGITAL TCP/IP Services for OpenVMS Installation and Configuration.

3.26 Ultra SCSI Support

Ultra SCSI was invented by DIGITAL and subsequently standardized by the ANSI SCSI committee. Ultra SCSI incorporates several improvements over its predecessor, Fast SCSI, including an increase in the maximum transfer rate on the SCSI bus from 10 MHz to 20 MHz. For a wide Ultra SCSI bus, this means an increase in maximum bus bandwidth from 20 MB/s to 40 MB/s.

OpenVMS Ultra SCSI support was first introduced in the OpenVMS Alpha Version 7.1-1H1 hardware release. OpenVMS Version 7.2 extends Ultra SCSI support to multihost configurations, as described in Section 3.16.9.

3.26.1 Coexistence of Ultra SCSI Devices with Other SCSI Devices

Ultra SCSI devices can be used on the same SCSI bus as non-Ultra SCSI devices. For example, Ultra SCSI peripherals such as the RZ1DB-VW can be used at non-Ultra speeds with the KZPSA adapter. Furthermore, non-Ultra SCSI peripherals such as the RZ29B can be used with the KZPBA Ultra SCSI host adapter.

3.26.2 Ultra SCSI Devices Supported by OpenVMS

For information about all Ultra SCSI devices supported by OpenVMS and how to configure them, refer to StorageWorks UltraSCSI Configuration Guidelines, order number EK--ULTRA--CG. You can also obtain information about StorageWorks Ultra SCSI products from their Web site, which is periodically updated:

http://www.storage.digital.com

3.27 Year 2000 Readiness

OpenVMS Version 7.2 is fully Year 2000 ready. This version of OpenVMS includes all the Year 2000 enhancements that shipped in the Year 2000 kits for OpenVMS Version 7.1 and 7.1--1H1.

The OpenVMS Year 2000 enhancements are the result of a rigorous and comprehensive analysis of the entire OpenVMS operating system, including simulations of the transition to the Year 2000 and beyond, and extensive OpenVMS testing. These Year 2000 modifications affect only a few older and rarely used components.

You can find links to OpenVMS Year 2000 release notes and other information about testing your own environment for the Year 2000 on the OpenVMS Year 2000 web site:

http://www.openvms.digital.com/openvms/products/year-2000/

OpenVMS Version 7.2 conforms to the Year 2000 DIGITAL Product Warranty. For information on this special warranty, see the following World Wide Web page:

http://www.digital.com/year2000/warranty.asp

Although OpenVMS is ready for the Year 2000, you must ensure that the environment in which OpenVMS operates is also ready. Based on our investigations and testing, Compaq expects that most Year 2000-related problems will occur primarily in locally developed layered applications. Therefore, it is important to start evaluating your applications and environments as soon as possible.

This chapter describes new features relating to application and system programming on this version of the OpenVMS operating system.

4.1 Adapter Support (Alpha Only)

The following sections describe the new adapters supported for OpenVMS Alpha Version 7.2.

4.1.1 ATMWORKS 351 Adapter

The ATMWORKS 351 adapter is a high-performance, 155 Mb/s, full-duplex ATM adapter that enables systems with peripheral component interconnect (PCI) slots to communicate over an ATM network. The ATMWORKS 351 driver is supported by the SYS$ATMWORKS351 port driver which has a device name HWcu, where c is the controller and u is the unit number, as for example, HWA0.

For more detailed information, see the OpenVMS I/O User's Reference Manual.

4.1.2 DE500-BA/DE504-BA Adapters

OpenVMS Alpha Version 7.2 provides run-time and boot support for the DE500-BA and DE504-BA adapters. The DE500-BA and DE504-BA are single-slot adapters with direct interfaces to the 32-bit PCI Ethernet Network Interface Card (NIC). The DE500-BA contains a single port, and the DE504-BA contains four ports. Each port is capable of running Fast Ethernet (100 Mb/s) and 10 Mb/s standard Ethernet protocols. Both adapters support full- and half-duplex modes at either speed for configuration flexibility that allows a single adapter to communicate with Fast or standard Ethernet systems. Also, both adapter's NIC also includes support for IEEE 802.3u autonegotiation.

The DE500-BA uses an 8-position modular connector to connect to hubs, switches, or to other NICs. This connector, commonly referred to as an RJ-45, uses two pairs of data grade 100-ohm category 5 UTP or 150-ohm STP-A cable supporting a maximum distance of 100 meters.

4.1.3 DE500-FA Adapter

OpenVMS Alpha Version 7.2 provides run-time and boot support for the DE500-FA PCI FastEthernet Network Interface Card (NIC). The DE500-FA is capable of 100 Mb operation in half or full-duplex mode. This NIC supports the 100Base-FX physical layer described in clause 26 of the IEEE 802.3u specification. The 100Base-FX is designed to operate over two strands of 62.5/125 graded index multimode optical fiber cable. A maximum distance of 412 meters is supported in half-duplex mode and 2000 meters in full-duplex mode. The DE500-FA uses an SC fiber optic connector. The 100Base-FX does not support autonegotiation or 10 Mb operation.

4.1.4 DEGPA-SA Adapter

OpenVMS Version 7.2 provides run-time support for the DEGPA-SA PCI Gigabit Ethernet Network Interface Card (NIC). The DEGPA-SA conforms to the IEEE 802.3z Gigabit Ethernet standard running over 1000BASE-SX fiber optic cabling. It can run point-to-point to another Gigabit Ethernet adapter or to a Gigabit Ethernet hub/switch. For more information about Gigabit Ethernet support, see Section 3.19.

4.2 Clusterwide Logical Names

Clusterwide logical names are an extension to the existing logical name support in OpenVMS. They are available on OpenVMS Alpha and on OpenVMS VAX.

This section provides information regarding the use of clusterwide logical names in applications. For general information about clusterwide logical names, including how to create them at the DCL level, see Section 3.16.2. For more information about using logical names in applications, refer to the OpenVMS Programming Concepts Manual.

4.2.1 New Clusterwide Attributes for $TRNLNM System Service

Two new attributes have been added to the $TRNLNM system service:

• LNM$V_CLUSTERWIDE
• LNM$M_INTERLOCKED

LNM$V_CLUSTERWIDE is an output attribute to be returned in the itemlist if you asked for the LNM$_ATTRIBUTES item for a logical name that is clusterwide.

LNM$M_INTERLOCKED is an attr argument bit that can be set to ensure that any clusterwide logical name modifications in progress are completed before the name is translated. LNM$M_INTERLOCKED is not set by default. If your application requires translation using the most recent definition of a clusterwide logical name, use this attribute to ensure that the translation is stalled until all pending modifications have been made.

On a single system, when one process modifies the shareable part of the logical name database, the change is visible immediately to other processes on that node. Moreover, while the modification is in progress, no other process can translate or modify shareable logical names.

In contrast, when one process modifies the clusterwide logical name database, the change is visible immediately on that node, but it takes a short time for the change to be propagated to and made on other nodes. By default, translations of clusterwide logical names are not stalled. Therefore, it is possible for processes on different nodes to translate a logical name and get different equivalence names when modifications are in progress.

The use of LNM$M_INTERLOCKED guarantees that your application will receive the most recent definition of a clusterwide logical name.

4.2.2 New Clusterwide Attribute for $GETSYI System Service

One new clusterwide attribute, SYI$_CWLOGICALS, has been added to the $GETSYI system service. When you specify SYI$_CWLOGICALS, $GETSYI returns the number 1 if the clusterwide logical name database has been initialized on the CPU, or the value 0 if it has not been initialized. Because this number is a Boolean value (1 or 0), the buffer length field in the item descriptor should specify 1 (byte). On a nonclustered system, the value of SYI$_CWLOGICALS is always 0.

4.2.3 Creating Clusterwide Tables with the $CRELNT System Service

When creating a clusterwide table, the $CRELNT requester must supply a table name. OpenVMS does not supply a default name for clusterwide tables because the use of default names enables a process without the SYSPRV privilege to create a shareable table.

4.3 COM for OpenVMS

COM (Component Object Model) is a technology from Microsoft® that allows developers to create distributed network objects. Digital Equipment Corporation and Microsoft jointly developed the COM specification. First released as NetOLE (Network Object Linking and Embedding) and then renamed DCOM (Distributed COM), the COM specification now includes network objects. COM for OpenVMS is an implementation of the Microsoft code that supports the COM draft standards.

A developer might implement COM applications on OpenVMS in the following ways:

• For existing OpenVMS applications and data, a developer can encapsulate an OpenVMS application as a COM object. A Windows COM client can then interact with the existing OpenVMS application and data. This allows business-critical applications and data to stay on the OpenVMS system while making the OpenVMS data and code accessible through a Windows application.
• For existing COM applications on other operating systems, a developer can port COM objects to OpenVMS to take advantage of specific OpenVMS features. This allows you to leave other COM objects associated with the application unchanged on their current platforms, and lets you port only the objects you need to your OpenVMS system. You can then revise the ported code to maximize OpenVMS benefits and at the same time, minimize the change to the overall application.
• For new OpenVMS applications, a developer can create a COM server on OpenVMS. COM client applications on Windows NT systems, on other OpenVMS systems, or on other COM-enabled operating systems can access this OpenVMS COM server.

To implement COM on OpenVMS, Compaq has made the following changes to the OpenVMS operating system:

• Added COM APIs to OpenVMS
  Compaq has added a set of Microsoft COM APIs to OpenVMS. These APIs allow developers to write and debug COM objects on OpenVMS systems. (For complete details about COM for OpenVMS development, see the OpenVMS Connectivity Developer Guide included with the COM for OpenVMS developer kit.)
• Added an OpenVMS Registry
  COM applications can add, read, change, and delete the OpenVMS Registry contents. You can view and edit the contents of the OpenVMS Registry either from OpenVMS (using the REG$CP utility or the $REGISTRY system service) or from Windows® NT^tm (using RegEdit or RegEdt32).
• Extended OpenVMS security to enable secure connections between Windows NT and OpenVMS
  These enhancements include support for common user authentication and authenticated RPC with NTLM security. In addition, Compaq has moved some DCE RPC functions into the base operating system to provide limited support for Microsoft RPC calls.
• Added application event logging on OpenVMS
  Applications write system, security, and application activity information to the OpenVMS event logs. You can view the contents of the event logs on OpenVMS either from OpenVMS (using the PATHWORKS Admin utility) or from Windows NT (using the Windows NT Event Viewer).

COM for OpenVMS will ship with the OpenVMS operating system. It is licensed as follows:

• The run-time version of COM for OpenVMS is licensed as part of OpenVMS Version 7.2.
• The COM for OpenVMS developer kit has a separately orderable license.

COM for OpenVMS security will be implemented in two phases. The following sections describe the phases.

Phase 1: COM Version 1.0 for OpenVMS (without authentication)

In this phase, a COM for OpenVMS process executes with an OpenVMS security identity only; OpenVMS does not authenticate COM requests from Windows NT clients or process any Windows NT credentials.

An OpenVMS system manager can set the COM for OpenVMS security identities of a COM server process in the following ways:

• Execute the process with a DCOM$GUEST identity.
  DCOM$GUEST is a nonprivileged account created by COM for OpenVMS during installation. (This is the default action.)
• Assign an OpenVMS account to a specific COM for OpenVMS application.
  In this case, the system manager creates a OpenVMS account that has privileges, rights, and restrictions as defined by the person creating the account. COM servers that execute from this account are restricted to the OpenVMS security context of the account.

Because COM Version 1.0 for OpenVMS does not authenticate remote users, COM for OpenVMS accepts and processes client requests as if authentication had taken place. Although less secure than a full NTLM implementation, COM Version 1.0 for OpenVMS minimizes the security risk by using the OpenVMS accounts to execute servers. COM Version 1.0 for OpenVMS enforces security on a processwide basis; as a result, per-method security is not available.

Because the COM process has no associated NT credentials and no authentication mechanism exists in COM Version 1.0 for OpenVMS, Windows NT systems treat the outbound requests to Windows NT systems as unauthenticated. Windows NT systems that run COM server processes for COM for OpenVMS client applications must allow access to everyone for the specific server applications.

When full NTLM authentication (COM Version 1.1 for OpenVMS) is available, Compaq will add another option: client access. This option allows the COM for OpenVMS server process to execute in the security context of the requesting Windows NT client. The COM for OpenVMS server process includes Windows NT credentials that OpenVMS can use for Registry access and outbound COM requests.

COM Version 1.0 for OpenVMS software requirements

COM Version 1.0 for OpenVMS does not use the NTLM security features (tactical security, SSPI, and authenticated RPC). COM Version 1.0 for OpenVMS does not require or use Advanced Server for OpenVMS (formerly the PATHWORKS server). Advanced Server for OpenVMS is required if you want to connect from a Windows NT system and access the OpenVMS Registry. Event logging is part of PATHWORKS and is not available in COM Version 1.0 for OpenVMS.

Phase 2: COM Version 1.1 for OpenVMS (with NTLM authentication)

In this phase, COM for OpenVMS processes OpenVMS security identities, authenticates COM requests from Windows NT clients, and processes Windows NT credentials. This is the full implementation of NTLM (NT LAN Manager) security for COM for OpenVMS.

COM Version 1.1 for OpenVMS software requirements

COM Version 1.1 for OpenVMS uses the NTLM security features (tactical security, SSPI, and authenticated RPC). COM Version 1.1 for OpenVMS requires Advanced Server for OpenVMS (formerly the PATHWORKS server). COM Version 1.1 for OpenVMS enables event logging.

	privacy and legal statement
6520PRO_005.HTML