![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The VAX SCSI disk driver (DKDRIVER) does not implement the same level of error handling that exists in all other OpenVMS disk drivers. Consequently, the OpenVMS Volume Shadowing product is unable to recover from several rare error conditions when used on SCSI disks that are locally connected to VAX 3000 and VAX 4000 series systems. This problem does not occur on CI-based or DSSI-based SCSI storage.
Problems resulting from the unimplemented error handling typically are shadow set hangs or system crashes. No evidence of data corruption has been seen in Digital test labs. No hangs or crashes at customer sites have been reported. The complexity of this problem, which has existed since Version 5.5-2, precludes it being fixed with a patch, and Digital has no plans to implement the missing error handling code.
Customers who wish to use OpenVMS Volume Shadowing on SCSI disks that
are locally connected to VAX 3000 and 4000 series systems will be
supported by Digital up to the limits of the current error handling
capabilities. Volume Shadowing will continue to deliver data
availability in the event of disk media failure on these systems,
although some errors will cause a system failure, necessitating a
reboot.
4.25.2 Problems and Restrictions
The following sections describe known problems and other considerations
pertaining to volume shadowing.
4.25.2.1 Bad Block Repair (BBR) Logic Problem
V7.1
The OpenVMS Volume Shadowing driver's Bad Block Repair (BBR) logic does not perform correctly in some cases.
A partial solution for this BBR problem has been available in remedial kits for Version 6.2 and prior versions.
The complete solution, which includes enhanced code for the COPY DATA repair operations, was developed too late to be included in Version 7.1, but it is available in a remedial kit for Version 7.1.
If you update any Version 6.2 systems with the Cluster Compatibility Kit (see Section 4.15.1.2), the new Volume Shadowing drivers in that kit supersede any drivers with the partial BBR solution that were shipped in earlier remedial kits for Version 6.2. The Cluster Compatibility Kit does not include the BBR solution, but you can obtain the complete solution in a new remedial kit.
Contact your Digital support representative to obtain any of these
remedial kits.
4.25.2.2 HSD10 Virtual Disks
V7.1
The HSD10 controller supports a virtual disk capability by partitioning
physical disks. To prevent data corruption, do not use OpenVMS Volume
Shadowing to create shadow sets using HSD10 virtual disks.
4.25.2.3 Minimerge Capability Requires Dump Off System Disk
V7.1
With the use of the new DUMPSTYLE system parameter in OpenVMS Alpha Version 7.1, you can now enable minimerge on shadowed system disks. The DUMPSTYLE parameter lets you specify that the system write a dump to a nonshadowed, nonsystem disk of your choice. This results in a considerable performance improvement.
Control the shadowing of a system disk by setting the SHADOW_SYS_DISK system parameter as shown in Table 4-2.
| Setting | Description |
|---|---|
| 0 | Do not shadow the system disk |
| 1 | Shadow the system disk; disable system disk minimerge |
| 4097 | Shadow the system disk; enable system disk minimerge |
Do not enable system disk minimerge without using the DUMPSTYLE parameter to dump off system disk, as described in Section 4.21.1.1. If you do not set the DUMPSTYLE parameter to DOSD and proceed to enable minimerge for system disks, minimerge will be activated, to the detriment of crash dump analysis.
In the event that you accidentally enable minimerge to a system disk
that receives a crash dump and you have not set up dump off system
disk, you can recover if you know which disk contains the valid dump.
Remove that member, remount it, and remove the dump from that member.
4.25.2.4 Minimerge Version Incompatibility
V7.1
The Volume Shadowing software for OpenVMS Version 7.1 has been revised with substantial quality improvements. However, this creates an incompatibility in the minimerge function between Version 7.1 and Version 6.2 nodes within the same cluster. In such configurations, the Volume Shadowing software detects this incompatibility during Version 7.1 installation and disables the minimerge capability for the entire cluster.
This problem is resolved by installing the OpenVMS Cluster
Compatibility Kit that ships with OpenVMS Version 7.1 (see
Section 4.15.1.2). This kit makes the Version 6.2 minimerge function
compatible with that of nodes running Version 7.1 software.
4.25.2.5 HSZ40 and Transportable SCSI Disk Shadow-Set Members
V6.2
An HSZ40 Raid-Array Controller provides the capability of an OpenVMS initialized SCSI disk (that is, one with a Files-11 ODS-2 format on it) to be moved between an OpenVMS controlled SCSI bus and an HSZ40 controlled SCSI bus without reinitializing the disk and losing data. Disks that contain this functionality are called transportable disks.
A SCSI disk initialized by the HSZ40 and then subsequently initialized by OpenVMS is called a nontransportable disk, and cannot be moved to an OpenVMS controlled SCSI bus without losing data.
OpenVMS Volume Shadowing requires that a SCSI disk support the SCSI commands READ_LONG/WRITE_LONG. These SCSI commands in conjunction with OpenVMS Volume Shadowing are used to handle certain classes of errors as seen under normal volume shadowing operations. SCSI disks that support the READ_LONG/WRITE_LONG capability while connected to an OpenVMS controlled SCSI bus, lose this capability when the transportable disks are moved to the SCSI bus controlled by an HSZ40.
The lack of READ_LONG/WRITE_LONG capability is detected at shadow-set MOUNT time, by the following error:
MOUN$_DEVNOFE, device does not support FORCED ERROR handling
To correct this problem, specify the MOUNT qualifier /OVERRIDE=NO_FORCED_ERROR at shadow-set MOUNT time.
Note that specifying this MOUNT qualifier may cause shadow-set member SCSI disks to be removed from a shadow set if certain error conditions arise that cannot be corrected.
Digital recommends that HSZ40 nontransportable SCSI disks be used to
contain shadow-set members that support READ_LONG/WRITE_LONG
functionality, and offer benefits provided by the level of RAID chosen
at initialization time.
4.25.3 Corrections
The following notes describe corrections to former volume shadowing
problems.
4.25.3.1 Crash Dump Problem Corrected (Alpha Only)
V7.1
Formerly, if a boot device was removed from a multiple-member system disk shadow set on an OpenVMS Alpha system, this removal resulted in the loss of a crash dump if a subsequent system failure occurred.
This problem has been corrected in OpenVMS Alpha Version 7.1.
4.25.3.2 DISMOUNT/CLUSTER Command Problem Corrected
Formerly, issuing the DISMOUNT/CLUSTER command to a shadow set sometimes caused a clusterwide hang. This problem has been corrected in OpenVMS Version 7.1.
This chapter provides release notes about both application and system programming on OpenVMS systems.
For information about new programming features included in OpenVMS
Version 7.1, see the OpenVMS Version 7.1 New Features Manual.
5.1 Backup API
This section contains release notes pertaining to the Backup
application programming interface (API). See Section 4.3 for
additional notes about the Backup utility.
5.1.1 Problems and Restrictions
This section describes known problems and restrictions for the Backup
API.
5.1.1.1 CONTROL Event Types Return Incorrect Message Arguments
The Backup API returns incorrect message vector arguments to an event callback routine that handles event types BCK_EVENT_K_CONTROL and BCK_EVENT_K_STATISTICS. This means that the message vector, as passed to the application interface, is not suitable for output using the SYS$PUTMSG service.
For certain condition values, the application can correct the message vector. The condition value is located in the second longword of the message vector. The condition values and the required corrections are listed in the following table:
| Change First Word of Message Vector | Change Fifth Word of Message Vector | |||
|---|---|---|---|---|
| Condition Value | From | To | From | To |
| BACKUP$_CNTRL_CONFCOPY | 1 | 4 | 1 | 2 |
| BACKUP$_CNTRL_CONFCOMP | 1 | 4 | 1 | 2 |
| BACKUP$_STAT_COMPARE | 1 | 6 | ||
| BACKUP$_STAT_INACTIVE | 1 | 5 | ||
| BACKUP$_STAT_PHYSICAL | 1 | 7 | ||
| BACKUP$_STAT_RESTORE | 1 | 6 | ||
| BACKUP$_STAT_SAVCOP_ACT | 1 | 6 | ||
If an application registers a callback routine for any of the journaling events, it must register a callback routine for all the journalling callback events. The following is a list of the journaling callback events:
This is a permanent restriction. The documentation will be amended to incorporate this restriction.
See the Backup API chapter in the OpenVMS Utility Routines Manual for more information on
registering callback routines.
5.1.1.3 Repetitive Calls to BACKUP$START Can Cause an Error
Repetitive calls to BACKUP$START can cause the following error:
%BACKUP-F-INSBUFSPACE, insufficient buffer space
The number of repetitive calls completed before receiving this error varies, depending upon the previous backup operations performed.
The workaround for an application that receives this error is to exit the operation and restart.
This problem will be corrected in a future release.
5.1.2 Documentation Changes and Corrections
The following note contains a correction to the OpenVMS Utility Routines Manual.
5.1.2.1 OpenVMS Utility Routines Manual
This section describes corrections to Chapter 3, Backup Routine, of the OpenVMS Utility Routines Manual.
In Chapter 3, the Description section for the Backup Routine contains an error in the first paragraph under the heading BACKUP Event Callbacks. The third sentence in that paragraph, beginning "To do so," should read:
"To do so, the application registers the callback routine by including option structure BCK_OPT_K_EVENT_CALLBACK in the call to BACKUP$START."
The manual will be corrected in a future release.
5.2 Batch and Print Queues
This section contains release notes pertaining to batch and print
queues.
5.2.1 Problems and Restrictions
This section describes problems and restrictions pertaining to batch
and print queues.
5.2.1.1 Terminating Executing Batch Jobs
Under the following conditions, the DELETE/ENTRY command might fail to stop an executing batch job:
The DELETE/ENTRY command causes the job to terminate in phases. A delete_process AST routine is given in user mode, supervisor mode, and then executive mode. Because there is a small delay between each mode, it is possible that, in a batch job, a user-mode image might terminate and the command procedure might continue to execute until the supervisor-mode delete_process AST routine is executed.
The return status of the SYNCHRONIZE command is assumed to contain the termination status of the target batch job. In addition, command procedures would normally execute a command such as $ON ERROR THEN CONTINUE or $SET NOON before issuing the SYNCHRONIZE command. If a DELETE/ENTRY command is issued to the job executing the SYNCHRONIZE command, the JBC$_JOBABORT is interpreted as being the termination status of the target batch job rather than a return status of the SYNCHRONIZE command. The command procedure then continues to execute for a short period with this incorrect assumption and performs an operation such as requeuing the target batch job or incorrectly reporting a failure of the target batch job.
This problem has been fixed for the SYNCHRONIZE command by detecting this situation and waiting in an exit handler for longer than the delay between the user and supervisor mode termination delay.
Any other images that would report the job completion status obtained by the SJC$_SYNCHRONIZE_JOB function code of the $SNDJBC system service as the return status of the program should implement logic similar to the following:
IF (exit status is JBC$_JOBABORT)
THEN
Wait 10 seconds
ENDIF
This section contains release notes pertaining to the OpenVMS Debugger. Debugger release notes specifically about system management are in Section 4.4.
Unless specified otherwise, the release notes apply to both the
character-cell and DECwindows Motif interfaces of the debugger.
5.3.1 Corrections
This section describes corrections to problems that existed in OpenVMS
Debugger Version 7.0.
5.3.1.1 Breakpoints Within Fortran Routines
V7.1
In previous versions, when using the DECwindows Motif interface to
debug Fortran programs, the debugger erroneously allowed users to set
breakpoints with breakpoint toggles for subroutine entry masks, which
do not contain executable code. This behavior has been corrected.
5.3.1.2 SET TYPE/OVERRIDE No Longer Ignored in Conditional Statements
V7.1
In previous versions, the debugger ignored the type setting specified by a SET TYPE/OVERRIDE command and returned a %DEBUG-E-OPNOTALLOW error when evaluating a conditional expression. For example, if line and s1 were not of the same type, the following commands would result in an error message:
DBG> SET TYPE/OVERRIDE/BYTE DBG> SET BREAK %LINE 12 WHEN (line[1] = s1)
This behavior has been corrected.
5.3.1.3 SET TRACE No Longer Restricted to One AST Level
V7.1
In previous versions, you could use the SET TRACE command to trace lines, instructions, branches, or calls of the mainline routines or of specified AST routines, but not both (at the same time).
This problem has been corrected. However, if the trace is established in mainline code, you must specify additional permanent tracepoints or breakpoints for each AST routine of interest. For example:
DBG> SET TRACE/LINE/INTO/NOSYS/NOSHARE DBG> SET TRACE address-expression[,...]
where the first SET TRACE command is issued while suspended in mainline
code, and address-expression is the address of an AST routine
to be traced. Whenever the eventpoint suspends execution at the AST
routine, the SET TRACE/LINE... command will take effect.
5.3.1.4 Quoted String Literals Now Passed Correctly
V7.1
In previous versions, the debugger erroneously did not allow passing a
quoted string literal to a command procedure as a value or address
type. This behavior has been corrected.
5.3.1.5 EXAMINE Command No Longer Fails on Valid Address Range
V7.1
In previous versions, when the language was set to C, an EXAMINE
command of a valid range of addresses would sometimes fail with the
message "%DEBUG-E-EXARANGE, invalid range of addresses." This behavior
has been corrected.
5.3.1.6 Watchpoint Support in Global Sections (Alpha Only)
V7.1
In previous versions, watchpoints set on variables whose addresses are
in global sections did not work. Attempting to set a watchpoint on a
location in a global section resulted in a %DEBUG-E-BADWATCH message.
This problem has been corrected on Alpha systems, but still exists on
VAX systems (see the OpenVMS Debugger Manual).
5.3.1.7 Watchpoint Support and $GETJPI
V7.1
In previous versions, an active static watchpoint could cause changes in program behavior when both of the following conditions existed:
This behavior has been corrected, and the program receives correct
information from $GETJPI about AST enablement.
5.3.1.8 DEBUG.EXE Image
V7.1
In previous versions of OpenVMS, you could not debug an image named
DEBUG.EXE. This problem has been corrected on both VAX and Alpha
systems.
5.3.2 Documentation Changes and Corrections
The following release note describes a minor addition to the
OpenVMS Debugger Manual.
5.3.2.1 OpenVMS Debugger Manual
In Section 4.4, the list that begins with "On Alpha
processors:" should contain the following additional bulleted item:
This section contains release notes pertaining to the DEC Ada Run-Time
Library.
5.4.1 Problems and Restrictions
This section describes several potential problems.
5.4.1.1 AST Procedures With Access Violations
V7.0
DEC Ada written AST procedures can get access violations if the AST that causes their invocation occurs when the null thread or a non DEC Ada thread is running. A workaround exists if the procedure executes at the user level rather than the AST level. Instead of using a procedure, rewrite the program to use a task entry point that has pragma AST_ENTRY on it.
For more information about AST_ENTRY, refer to the section "Task
Entries and OpenVMS Asynchronous System Traps" and the
documentation on pragma AST_ENTRY in the DEC Ada Language Reference Manual.
5.4.1.2 Unexpected Storage Errors (Alpha Only)
V7.0
In OpenVMS Alpha Version 7.0 and later, binary compatibility fails for
some DEC Ada programs that make incorrect assumptions about the amount
of task space used by DEC Ada tasks. If a task gets a storage error
that it did not previously get, you may need to add a length clause
specifying the storage size for the task. If you already use a length
clause, you might need to increase the amount of storage specified.
This is necessary only in cases where the specified size (or default
size) is not large enough for the task's execution.
5.5 DEC C Run-Time Library
The following sections contain release notes pertaining to the DEC C
Run-Time Library (RTL).
5.5.1 Changes and Enhancements
This section describes changes and enhancements that are included in
Version 5.2 or later of the DEC C RTL software. For more details, see
the revision of the DEC C Run-Time Library Reference Manual for OpenVMS Systems that ships with DEC C Version 5.2 or
later.
5.5.1.1 New Universal Symbols in DECC$SHR Improve Link Profile (Alpha Only)
V7.1
In OpenVMS Alpha Version 7.0, the DEC C Run-Time Library functions whose names are of the form decc$fmath_2, are defined in STARLET, but are not universal symbols in the DECC$SHR image. When these functions are referenced by an application, linking the image results in inclusion of the DECC$SHR image from IMAGELIB and the specific C math modules from STARLET. If neither the DPML$SHR image or the CMA$TIS_SHR image were already brought in during the IMAGELIB phase, the object form is included from STARLET because references to these symbols appear in the STARLET phase. In OpenVMS Version 7.0, this resulted in the undefined symbols:
In OpenVMS Alpha Version 7.1, the decc$fmath_2 symbols have been added
to the DECC$SHR image so that both the DPML$SHR and CMA$TIS_SHR
references are now resolved using shareable images found in IMAGELIB.
5.5.1.2 Time Zone Cache Greatly Improves Performance
V7.1
The UTC-based time functions, introduced in OpenVMS Version 7.0, had
degraded performance compared with the non-UTC-based time functions. A
cache for time zone files has been introduced to improve performance.
The size of the cache is determined by the logical name
DECC$TZ_CACHE_SIZE. To accommodate most countries changing the time
twice per year, the default cache size is large enough to hold two time
zone files.
5.5.1.3 Changing Default LRL Value On Stream Files
V7.1
In OpenVMS Version 7.0 the default LRL value on stream files was changed from 0 to 32767. This change caused significant performance degradation on certain file operations such as sort.
This is no longer a problem. The DEC C Run-Time Library now allows users to define the logical DECC$DEFAULT_LRL to change the default record-length value on stream files.
The DEC C Run-Time Library first looks for this logical. If it is found and it translates to a numeric value between 0 and 32767, that value is used for the default LRL.
To restore the behavior prior to OpenVMS Version 7.0, enter the following command:
$ DEFINE DECC$DEFAULT_LRL 0
V7.1
In OpenVMS Version 7.1, the DEC C Run-Time Library has added support for Unicode character set conversions. This release also includes converters that perform conversions between Unicode and any other supported character sets. (See Section 10.6 in the DEC C Run-Time Library Reference Manual for OpenVMS Systems for more information about character set conversions and a list of the supported character sets.)
The expanded set of converters includes converters for UCS-2, UCS-4,
and UTF-8 Unicode encoding. The Unicode converters can be used by the
ICONV CONVERT utility and by the iconv family of functions in the DEC C
Run-Time Library.
5.5.1.5 Internationalization Support
V7.1
The DEC C RTL has added capabilities to allow application developers to create international software. The DEC C RTL obtains information about a language and a culture by reading this information from locale files.
If you are using these DEC C RTL capabilities, you must install a separate kit to provide these files to your system. The save set, VMSI18N071, is provided on the same media as the OpenVMS Version 7.1 operating system.
To install this save set, follow the standard OpenVMS installation procedures using this save set name as the name of the kit. There are several categories of locales that you can select to install. You can select as many locales as you need by answering the following prompts:
Do you want European and US support? Do you want Chinese support? Do you want Japanese support? Do you want Korean support? Do you want Thai support? Do you want the Unicode converters?
This kit also has an Installation Verification Procedure that Digital
recommends you run to verify the correct installation of the kit.
5.5.2 Problems and Restrictions
This section describes problems or restrictions related to using the
DEC C RTL software.
5.5.2.1 Internationalization Compatibility Problem With DECwindows Motif
V7.1
Applications that call the Xlib locale routines in DECwindows Motif Version 1.2--3 using the method described in Section 4.18.5.3 of the DECwindows Motif Version 1.2--3 for OpenVMS Release Notes will continue to function on OpenVMS Version 6.2 and later. However, because the locale support in Xlib is not compatible with the support in the DEC C Run-Time Library (DECC$SHR.EXE), Xlib does not use the locale environment provided by the C library. Therefore, setting the locale in the C library does not affect the behavior of DECwindows Motif, although it does affect C library routines such as strcoll(). Setting the locale in Xlib changes the behavior of DECwindows Motif but does not affect C library routines.
This problem is corrected in DECwindows Motif Version 1.2-4, and in the
remedial kits for DECwindows Motif Version 1.2-3 that are described in
Section 2.9.2.2.
5.5.2.2 Socket Behavior Prior to UCX Version 3.3
6481P006.HTM OSSG Documentation 11-DEC-1996 07:52:14.78
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.