|
Software > OpenVMS Systems > Documentation > 83final > 6677 HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.3 Release Notes
Chapter 3
|
$ MOUNT/OVERRIDE=IDENTIFICATION ddcu: |
In this command, the ddcu: specification represents the device name of the CD or DVD device on your OpenVMS system. This device name is specific to each OpenVMS system.
$ TYPE ddcu:[FREEWARE]FREEWARE_README.TXT |
Duplicate copies of this file are found on each volume of the Freeware 8.0 distribution, and you can view its contents by using the TYPE command or your preferred text editor.
For additional information about the Freeware, refer to the FREEWARE_README.TXT files.
Once the appropriate device is mounted, you can access the kit directories directly using standard DCL commands such as DIRECTORY and COPY . Omnibus text files containing submission abstracts and other materials are available in the [FREEWARE] directory on each disk.
The [FREEWARE]FREEWARE.COM Freeware menu system interface has been removed from Freeware 8.0 distribution.
V8.2
The [FREEWARE]FREEWARE.COM Freeware menu system interface on the OpenVMS Freeware V7.0 distribution does not operate on OpenVMS I64 systems.
The menu system interface is expected to function on OpenVMS Alpha and on OpenVMS VAX systems.
You can directly access the contents of the Freeware V7.0 distribution media by using DCL commands such as DIRECTORY and COPY from an OpenVMS I64, OpenVMS Alpha, or OpenVMS VAX system. This is the preferred way to access the contents of the Freeware V7.0 distribution.
Information about submissions and the Freeware distribution is contained in the file [FREEWARE]FREEWARE_README.TXT. This file is on each volume of the Freeware V7.0 distribution, and you can view its contents by using the TYPE command or a text editor.
The following release notes pertain to DCL commands.
V8.2
CREATE/MAILBOX/TEMPORARY currently requires CMEXEC privilege. This restriction will be removed in a future release.
V8.2
The OpenVMS Migration Software for VAX to Alpha (DECmigrate) is not included on the Open Source Tools CD shipped with the OpenVMS Version 8.2 distribution media. The software kit was included on the media for OpenVMS Version 7.3-2, but testing has not been completed on OpenVMS Version 8.2. The software will continue to be available on the following website for earlier versions of OpenVMS:
An update will be posted when support for OpenVMS Version 8.2 becomes available.
The following notes pertain to the HP Secure Web Browser.
V7.3-1
If you have an OpenVMS workstation and you are using the HP Secure Web Browser (SWB), based on Mozilla, the minimum memory requirement is 256 MB; however, 512 MB is highly recommended for more robust performance.
V8.2
Installing the HP Secure Web Browser (CSWB) Version 1.4 for OpenVMS I64 on an ODS-2 disk volume fails with a PCSI error, as follows:
%PCSI-E-OPENIN, error opening ODS2$DISK:[SYS0.SYSCOMMON.][CSWB.RES]SAMPLE^.UNIXPSFONTS.PROPERTIES;* as input -RMS-E-FND, ACP file or directory lookup failed -SYSTEM-W-BADFILEVER, bad file version number %PCSI-E-OPFAILED, operation failed |
You can continue with the installation by answering "NO" to the "Do you want to terminate?" prompt. The installation will continue successfully.
As an alternative, you can install the HP Secure Web Browser on an ODS-5 disk volume.
The following sections describe corrections and additions to various manuals in the OpenVMS documentation set.
For changes and updates to the HP OpenVMS System Analysis Tools Manual, see Chapter 4.
The following corrections pertain to the HP OpenVMS Programming Concepts Manual:
The following changes should be made to the paragraph in Section 31.2, "Writing a Privileged Routine (User-Written System Service)":
"As a protected image, your program does not have the entire operating system programming environment at its disposal. Unless a module has the prefix SYS$ or EXE$, you must avoid calling it from an inner mode. In particular, do not call LIB$GET_VM or LIB$RET_VM from an inner mode. You can call OpenVMS RMS routines from executive mode but not from kernel mode."
LIB$GET_VM should be LIB$FREE_VM. You cannot call these LIBRTL routines directly, and you cannot call any routines that might now or in the future call these routines indirectly. This includes other routines within LIBRTL and the user-mode C library, among other libraries.
The Version 8.2 HP OpenVMS Debugger Manual contains incorrect information for the PC client interface kit. This release note corrects the information in Sections 11.1 and 11.2, as follows:
The debug server runs on OpenVMS systems. The client is the user interface to the debugger, from which you enter debugger commands that are sent to the server. The server executes the commands and sends the results to the client for display. The client runs on Microsoft® Windows® 95, Windows 98, Windows NT®, Windows 2000, and Windows XP®.
The correct client kit for the above client platforms is:
[DEBUG_CLIENTS011.KIT] DEBUGX86011.EXE |
There is no special installation procedure for the components that run on OpenVMS. The system administrator should move the OpenVMS debug client kit listed above from the OpenVMS distribution media to a place accessible to PC users, such as a PATHWORKS share or FTP server. The client kit is a self-extracting .EXE file.
Once the appropriate executable file has been transferred to the PC, you can run the file to install the debug client on the PC. The InstallShield installation procedure guides you through the installation.
By default, the debug client is installed in the \Program Files\OpenVMS Debugger folder. You can also click Browse to select an alternate location.
The installation creates an OpenVMS Debugger program folder that contains shortcuts to the following items:
V8.3
The HP DELTA debugger was made available on OpenVMS I64 Version 8.2-1. The HP OpenVMS DELTA/XDELTA Debugger Manual has been revised in this release to include information about using DELTA on OpenVMS I64 systems.
V8.3
The HP OpenVMS Utility Routines Manual has been revised to include the following information:
The HP OpenVMS I/O User's Reference Manual does not fully describe the behavior of the read request. The following paragraph should replace the first paragraph of Section 6.5.1:
To read data from the pseudoterminal, the control program uses the PTD$READ routine. When a PTD$READ routine is called, the operating system queues a read operation. The read operation completes when the pseudoterminal has characters to output. The read request queries TTDRIVER whether there is data found to be returned. If so, the resulting string of characters is returned. If a read request is issued and no data is available, the read request is queued and then completed at a later time. In this case, the routine always returns at least one character. The read request may complete even when there are no characters available to output. In this rare case when TTDRIVER indicates that there is no more data to be output and there is really no data, the read operation completes with zero bytes of data.
The following paragraphs replace Section D.4.4:
The PTD$READ routine reads data from the pseudoterminal. The read request completes with a minimum of one character and a maximum of the number of characters specified by the readbuf_len argument.
When a PTD$READ routine is called, the operating system queues a read operation. The read operation completes when the pseudoterminal has characters to output. The read request queries TTDRIVER whether there is data found to be returned. If so, the resulting string of characters is returned. If a read request is issued and no data is available, the read request is queued and then completed at a later time. In this case, the routine always returns at least one character. The read request may complete even when there are no characters available to output. In this rare case when TTDRIVER indicates that there is no more data to be output and there is really no data, the read operation completes with zero bytes of data.
In references to the pseudoterminal driver control-connection routines, the PDT$ prefix is incorrect. The prefix should be PTD$.
The following release notes provide corrected information about the OpenVMS I64 Librarian utility.
In Section 4.8.2.3 of the HP OpenVMS Version 8.2 New Features and Documentation Overview, the description of the enhanced library /REMOVE qualifier is incorrect. The correct information follows.
The /REMOVE qualifier has been enhanced for the I64 Librarian utility. The format now allows you to specify the module instance of the symbol to be removed. The enhanced /REMOVE qualifier requests that the LIBRARY command delete one or more entries from the global symbol table of an object library.
Section 4.8.3.2 of the HP OpenVMS Version 8.2 New Features and Documentation Overview contains incorrect information. The following text replaces information in that section:
Accessing ELF Object Libraries
ELF object modules are inherently random access modules, whereas OpenVMS Alpha objects, text modules, and so on, are sequential. To allow random access, a new library routine was created to map the ELF object modules into process P2 space so that applications can make random access queries. To recover virtual address space from this mapping, another library routine was created to remove this mapping. These new routines (LBR$MAP_MODULE and LBR$UNMAP_MODULE) work only with ELF object libraries. These entry points are 64-bit interfaces because they refer to P2 space.
Because of the random-access nature of ELF object files, the following operations are not allowed on ELF object libraries:
LBR$GET_RECORD
LBR$SET_LOCATE
LBR$SET_MOVE
Because inserting modules into the library is a sequential operation, LBR$PUT_RECORD is allowed on ELF object libraries. Because the ELF object modules are not segmented into records, you need to provide the module's on-disk size when calling LBR$PUT_MODULE or upon the first call to LBR$PUT_RECORD when writing a module into the library.
The C code fragment in the following example illustrates how to use LBR$PUT_RECORD to insert an object module:
bufdesc->dsc$a_pointer = &p0_buffer ;
bytes_to_transfer = module_size ;
while ( bytes_to_transfer ) {
transfer = MIN ( bytes_to_transfer ,
ELBR$C_MAXRECSIZ ) ;
bufdesc->dsc$w_length = transfer ;
status = lbr$put_record ( library_index ,
& bufdesc ,
& txtrfa ,
module_size ) ;
if ( (status & 1) == 0 )
break ;
bytes_to_transfer -= transfer ;
bufdesc->dsc$a_pointer += transfer ;
} ;
if ( (status & 1) == 1 )
status = lbr$put_end ( library_index ) ;
|
To avoid making several calls to LBR$PUT_RECORD, a new library routine, LBR$PUT_MODULE, has been created.
V8.2-1
The following sections provide additions and corrections to Version 8.2 of the HP OpenVMS RTL Library (LIB$) Manual.
V8.2-1
In the description of the LIB$CVT_DX_DX routine in the HP OpenVMS RTL Library (LIB$) Manual, the following paragraph under "Guidelines for Using LIB$CVT_DX_DX" should contain specific information about the rounding rule that is used:
Results are always rounded instead of truncated, except for the case described below. Note that loss of precision or range may be inherent in the destination data type or in the NBDS destination size. No errors are reported if there is a loss of precision or range as a result of destination data type.
This paragraph should be modified as follows:
Results are always rounded instead of truncated, except for when the source and destination are both NBDS and no scaling is requested. That case is described more fully in a later rule. LIB$CVT_DX_DX uses the VAX_ROUNDING rule. Note that loss of precision or range may be inherent in the destination data type or in the NBDS destination size. No errors are reported if there is a loss of precision or range as a result of destination data type. For details about the VAX_ROUNDING rule, refer to the description of CVT$CONVERT_FLOAT.
V8.2--1
The HP OpenVMS RTL Library (LIB$) Manual incorrectly identifies the following routines as being available on both Alpha and I64. These routines are available only on Alpha:
The HP OpenVMS RTL Library (LIB$) Manual also should specify that the LIB$GET_UIB_INFO routine is available only on I64.
The routines relating to invocation contexts and invocation handles that are I64 only include the following:
For additional information about these routines, refer to the HP OpenVMS Calling Standard.
Section 9.15, Using Interrupt Priority Level C (IPC), in the HP OpenVMS System Manager's Manual, Volume 1: Essentials incorrectly states that you can use IPC commands on I64 and all Alpha systems. This is not correct. The documentation has been changed to include the following statement:
For OpenVMS Versions 8.2 and 8.2--1, you cannot use IPC commands
on I64 systems or on ES47 or GS1280 Alpha systems if you booted
from a Graphic console.
|
V8.2-1
The $PUTMSG prototype is incorrectly documented in Version 8.2 of the HP OpenVMS System Services Reference Manual. The correct prototype is as follows:
C Prototype
int sys$putmsg (void *msgvec, int (*actrtn)(__unknown_params), void *facnam, unsigned __int64 actprm); |
Note that the return value from *actrtn is indeed checked to determine whether or not the message is input.
The documentation source file has been corrected, and the correction will appear in the next version of the HP OpenVMS System Services Reference Manual and in online help.
V8.2--1
Starting with OpenVMS Version 7.3, additional memory is required to run Volume Shadowing for OpenVMS, as described in the Version 7.3--2 HP Volume Shadowing for OpenVMS manual in Chapter 1 under Hardware Environment, Memory Requirements.. Note the following corrections:
These totals will be corrected in the next revision of HP Volume Shadowing for OpenVMS.
V8.2--1
OpenVMS Version 8.2--1 supports network update of the operating system from Version 8.2 to Version 8.2--1. Network update is supported only over the core I/O LAN cards on systems supported by OpenVMS Version 8.2. Refer to the HP OpenVMS Version 8.2--1 for Integrity Servers Upgrade and Installation Manual for more information.
In addition, there is also a hardware configuration restriction for network booting. Unlike Alpha consoles, where the speed and duplex setting for the network adapter can be selected at the console, the Integrity server console and network boot drivers perform autonegotiation only. The network switch nearest the Integrity server boot client must be set to autonegotiate for a successful network boot. Failure to set the switch to autonegotiate results in an inability to complete the network boot process.
V8.2--1
OpenVMS Version 8.2--1 does not support any synchronous data link hardware on Integrity servers.
V8.3
A duplex-mode mismatch condition occurs when a LAN device is operating in full-duplex mode and the other end of the cable, typically a switch port, is operating in half-duplex mode. The reverse is also true. A common network configuration error that results in a duplex mode mismatch condition occurs when the switch port is set to autonegotiate the speed and duplex settings, and the LAN device is set to a fixed setting of full duplex. In this configuration, autonegotiation by the switch results in the selection of half-duplex mode and the LAN device is set to full-duplex mode, and a duplex-mode mismatch occurs.
The consequence of a duplex-mode mismatch is typically a performance degradation. In addition, the IEEE 802.3 specification that describes the autonegotiation process suggests that a duplex-mode mismatch can result in data corruption. For most LAN devices, the only consequence of a duplex mode mismatch is the performance degradation. For some LAN devices, packet data is corrupted with good CRC, resulting in packet corruption undetected by the LAN subsystem. These devices include all Broadcom-based NICs and embedded LOM chips. On Alpha systems, these include the DEGPA, DEGXA, BCM5703 LOM on the AlphaServer DS25, and any implementations using the dual-port BCM5704 chip. On Integrity systems, these include the A6847A, A6725A, A9782A, A9784A, AB465A, and BCM5701 LOM on the rx2600; BCM5703 LOM on other systems; and the A6794A.
In prior versions of OpenVMS, the LAN drivers attempt to detect the duplex-mode mismatch condition. Once an hour while the condition exists, they issue a console message and error log message warning of the condition.
In OpenVMS Version 8.3, the frequency of the messages is increased from once per hour to once every 36 seconds for any Broadcom-based LAN devices. The frequency remains at once per hour for non-Broadcom-based LAN devices. In addition, to increase the visibility of these messages, the console messages are sent to OPCOM and to the LANACP log file (SYS$MANAGER:LAN$ACP.LOG).
The purpose of this note is to underscore the importance of avoiding duplex-mode mismatches, particularly when this condition results in undetected data corruption for Broadcom-based devices.
Note that the LAN drivers detect a duplex mode mismatch condition by monitoring device errors. The detection is not perfect, so the LAN drivers refer to the condition as a "potential duplex-mode mismatch." Upon noticing these messages, a system or network manager should inspect the LAN counters and LAN device settings to ensure a duplex-mode mismatch condition does not exist.
V8.3
System managers should be aware that, during boot, if the AUDIT_SERVER fails to initiate for any reason, the startup process enters a retry loop that attempts to restart the AUDIT_SERVER until the condition preventing the initiate to complete is cleared and AUDIT_SERVER initiates correctly. This behavior is deliberate and is designed to prevent the system from running in a compromised security state.
Conditions that can prevent complete initiation include the following:
Clearing the condition might require manual intervention. The action required depends on the fault source. Corrective action can include restarting the AUDIT_SERVER processes on other cluster nodes or rebooting the affected node in MINIMUM state and manually correcting the fault. Corrupt database files can be identified by renaming the files and then restarting the AUDIT_SERVER. The server recreates the absent files and populates them with system default entries.
For more information about booting options, see Chapter 4 of HP OpenVMS System Manager's Manual, Volume 1: Essentials.
| Previous | Next | Contents |