Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXSYS03_072 VAX V7.2 SYSTEM ECO Summary
*OpenVMS] VAXSYS03_072 VAX V7.2 SYSTEM ECO Summary
New Kit Date: 08-NOV-2002
Modification Date: 06-FEB-2003
Modification Type: Kit updated for incorrect documentation
Copyright (c) Compaq Computer Corporation 2000,2001,2002. All rights reserved.
PRODUCT: OpenVMS VAX
COMPONENT: LOGICAL_NAMES.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXSYS03_072
ECO Kits Superseded by This ECO Kit: VAXSYS02_072
ECO Kit Approximate Size: 2430 Blocks
Kit Applies To: OpenVMS VAX V7.2
System/Cluster Reboot Necessary: Yes
Rolling Re-boot Supported: Yes
Installation Rating: INSTALL_1
1 - To be installed by all customers.
Kit Dependencies:
The following remedial kit(s), or later, must be installed BEFORE
installation of this, or any required kit:
VAXUPDATE01_072
In order to receive all the corrections listed in this
kit, the following remedial kits, or later, should also be installed:
VAXAUDS01_072
VAXCLIU03_072
VAXMOUN01_072
ECO KIT SUMMARY:
An ECO kit exists for OpenVMS VAX V7.2. This kit addresses the following
problems:
PROBLEMS ADDRESSED IN VAXSYS03_072 KIT
o On a multi-processor machine, in a small cluster, when
creating or updating a clusterwide logical name, a process may
hang in RWSCS state. This fix closes a small window between
internal synchronization states and prevents this problem.
Images Affected:[SYS$LDR]SYS$CLUSTER.EXE
o The system can crash with a CWLNMERR bugcheck. The failing PC
is in routine TRNLNM, offset 7AC in PSECT
EXEC$HI_USE_PAGEABLE_CODE
Images Affected:[SYS$LDR]LOGICAL_NAMES.EXE
o A system can crash with an INVEXCEPTN bugcheck.
Images Affected:[SYS$LDR]PROCESS_MANAGEMENT.EXE
[SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
PROBLEMS ADDRESSED IN VAXSYS02_072 KIT:
o The $GETJPI system service can crash either the sending or
target node in an OpenVMS Cluster via CWSERR or INVEXCEPTN
bugchecks. In most cases the target node crashes but
the actual problem occurs on the sending no See the Crashdump
Summary Information below.
Crashdump Summary Information:
------------------------------
Bugcheck Type: KRNLSTAKNV, Kernel stack not valid
Current Process: CLUSTER_SERVER
Current Image: <not available>
Failing PC: FFFFFFFF 80060090
Failing PS: 00000000 00000000
Module: EXCEPTION
Offset: 00014090
Crashdump Summary Information:
------------------------------
Bugcheck Type: CWSERR, Error detected while processing
cluster-wide service request
Current Process: CLUSTER_SERVER
Current Image: $1$DKB205:[SYS0.SYSCOMMON.][SYSEXE]CSP.EXE
Failing PC: FFFFFFFF.801E4350 SYS$CLUSTER_NPRO+32350
Failing PS: 2C000000.00000000
Module: SYS$CLUSTER
Offset: 00032350
Images Affected: [SYS$LDR]PROCESS_MANAGEMENT.EXE
[SYS$LDR]SYS$CLUSTER.EXE
o If a process working set is reduced, such that the working set
only contains locked pages, and the process then pagefaults,
the system could bugcheck in MMG$PAGEFAULT with a "FREWSLX,
Free working set list index, resource wait" error. The
bugcheck occurs because no free working set list entries can
be found.
Images Affected: [SYS$LDR]PAGE_MANAGEMENT.EXE
o All FT device protection is hard-coded to (S:RWPL,O:RWPL,G,W).
When the SECURITY class TERMINAL device template's profile is
applied to device FTA0: at AUDIT_SERVER startup, any new
settings are applied to FTA0:. However, protections are still
being hard-coded within FTDRIVER for new FT devices created
later. Because of this, FT devices do not inherit settings
from the SECURITY class DEVICE object TERMINAL template as do
other devices, such as LT, TN, RT, and TT.
This change sets device protection for only FTA0:. This
allows the customer the option of modifying FTA0:'s device
protection later in the boot process (for example, in
SYSTARTUP_VMS.COM) or manually with a command similar to the
following:
$ SET SECURITY/CLASS=DEVICE/PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:
This new protection will be inherited from FTA0: by any new
FT devices created thereafter, (as well as other settings,
such as ACLs, originating from the SECURITY class TERMINAL
device template) Although, without customer intervention, this
same modified code behaves the same as in prior releases.
This ensures that existing applications will continue to
function correctly.
Images Affected: [SYS$LDR]IO_ROUTINES.EXE
[SYS$LDR]FTDRIVER.EXE
o A system can crash with an "XQPERR, Error detected by file
system XQP F11BXQP+11D94 %SYSTEM-F-IVLOCKID, invalid lock ID"
bugcheck
Note: To receive this full fix, you must also
install the VAXCLIU03_072 ECO kit.
Images Affected: [SYS$LDR]IO_ROUTINES.EXE
o An attempt to close a file, whose disk has timed out in
mount-verification, will fail. This causes FILCNTNONZ
bugchecks during process rundown.
Images Affected: [SYS$LDR]IO_ROUTINES.EXE
o Application Data Corruption could occur every 45 minutes when
using the TMX application on an SMP system. Applications such
as TMX, which uses its own I/O synchronization, might
inadvertently read and write the same block at almost the same
time. The cache could sometimes contain stale data.
Images Affected: [SYS$LDR]VAXCLUSTER_CACHE.EXE
o $TRNLNM code can exit without releasing the logical name
mutex. If that $TRNLNM request or any subsequent kernel mode
system service request made by that process exits with an
error status, the system will crash with a MTXCNTNZ bugcheck.
If no kernel mode system service request made by that process
exits with an error status, the system will eventually hang
with some processes in MUTEX wait trying to acquire the
logical name mutex. If some of those processes have already
acquired other mutexes, such as the I/O data base mutex and
GSD mutex, there may be other processes in MUTEX wait trying
to acquire those mutexes.
The $TRNLNM problem is exercised by a fairly unusual
combination of circumstances and is more likely to be seen on
an SMP system.
Crashdump Summary:
------------------
Bugcheck Type: MTXCNTNONZ, Mutex count nonzero at system
service exit
Current Process: ORA_PRODC0661
Current Image: $1$DGA21:[ORACLE8.RDBMS]ORACLE.EXE
Failing PC: FFFFFFFF.8008EFF4
__RELEASE_SERVICE_ERROR_EXCEPT+00094
Failing PS: 38000000.00000200
Module: EXCEPTION (Link Date/Time:
28-MAY-1999 23:22:24.23)
Offset: 00018FF4
Images Affected: [SYS$LDR]LOGICAL_NAMES.EXE
o Writing of full dumps of VAX systems with greater than 2
gigabytes of physical memory does not work. Symptoms can
vary, but the most common is a HALT in kernel mode while
trying to write the dump.
Images Affected: [SYSEXE]SYSBOOT.EXE
[SYSEXE]SYSBOOT_XDELTA.EXE
[SYSEXE]TERTIARY_VMB.EXE
[SYSEXE]VMB.EXE
[SYS$LDR]EXCEPTION.EXE
[SYS$LDR]EXEC_INIT.EXE
o MOUNT and Mount Verification sanity checks have been relaxed
to correct the following issues:
- A MOUNT/NOWRITE command on a disk on one cluster will now
work correctly even if the disk is mounted with a /WRITE
qualifier on another cluster in the SAN (Storage Area
Network). Previously, depending on the order in which the
mounts were executed, the mount would fail with the error
message:
DIFVOLMNT - different volume already mounted on this
device.
- If a disk is mounted with a /WRITE qualifier on one
cluster and a /NOWRITE qualifier on another cluster in the
SAN, MountVerification will fail with a WrongVolume status
error on the system which had the disk mounted /NOWRITE.
This change allows MountVerification to complete
successfully in this configuration.
Note: To receive this full fix, you must also install
the VAXMOUN01_072 ECO kit.
Images Affected: [SYS$LDR]IO_ROUTINES.EXE
o If a packet is requested from non-paged pool that is larger
than nonpaged pool's maximum allowed size (NPAGVIR), the
request fails but nonpaged pool expands to its maximum size
even though the request can not be satisfied.
Images Affected: [SYS$LDR]SYSTEM_PRIMITIVES.EXE
[SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
o In a mixed OpenVMS version clustered environment, a fatal
invalid identifier format (%SYSTEM-F-IVIDENT) error can result
on versions of OpenVMS that are not OpenVMS COE (Common
Operating Environment) compliant.
This can occur on non-COE compliant OpenVMS systems when
attempting to display the rights identifiers of a process that
is granted a valid GID COE identifier. The following
commands, lexicals, (and respective system services), cause
the %SYSTEM-F-IVIDENT system message to be displayed instead
of the text translation of this COE GID IDENTIFIER:
1. F$GETJPI("PID_xxx","PROCESS_RIGHTS")
2. F$GETJPI("PID_xxx","RIGHTSLIST")
3. $ SHOW PROCESS/ALL
4. $ SHOW PROCESS/RIGHTS
Images Affected: [SYS$LDR]SECURITY.EXE
[SYSLIB]SECURESHR.EXE
[SYSLIB]SECURESHRP.EXE
o The command reply mailbox timeout has been raised to 120
seconds for the SET AUDIT/SERVER=INITIATE command. The retry
timer for Object Initiation has been dropped to 15 seconds.
This allows multiple init retries before the command times
out. Before this change, any object init retry would be
meaningless, since it would not be attempted until after the
command timed out, which could result in a failure status for
a successful operation.
Note: To receive this full fix, you must also install
the VAXCLIU03_072 ECO kit.
Images Affected: [SYS$LDR]SECURITY.EXE
[SYS$LDR]IO_ROUTINES.EXE
o A cluster-wide AUDIT_SERVER hang prevents boot from
completing.
Note: To receive this full fix, you must also install
the VAXCLIU03_072 ECO kit.
Images Affected: [SYS$LDR]SECURITY.EXE
[SYS$LDR]IO_ROUTINES.EXE
o The order in which certain locks are taken was changed to
prevent deadlocks between blocking locks and RMS record locks
on the Objects database.
Note: To receive this full fix, you must also install
the VAXCLIU03_072 ECO kit.
Images Affected: [SYS$LDR]SECURITY.EXE
[SYS$LDR]IO_ROUTINES.EXE
o Delete an unused reply mailbox before returning to the caller.
Note: To receive this full fix, you must also install
the VAXCLIU03_072 ECO kit.
Images Affected: [SYS$LDR]SECURITY.EXE
[SYS$LDR]IO_ROUTINES.EXE
o The command SET AUDIT/NOLISTENER fails under all
circumstances. See error message below:
$ SET AUDIT/NOLISTENER
%SET-E-VERIFYFAIL, specified operation was not performed due
to the following error:
-AUDSRV-W-REQPKTINV, required packet missing or invalid;
requestor PID: 00000000
$
Note: To receive this full fix, you must also install
the VAXCLIU03_072 ECO kit.
Images Affected: [SYS$LDR]SECURITY.EXE
[SYS$LDR]IO_ROUTINES.EXE
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OpenVMS database. To view these articles, open the appropriate product
database and perform a query using either of the following search strings:
'VAXSYS03_072' or 'VAXSYS'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
INSTALLATION NOTES:
Install this kit with the VMSINSTAL utility by logging into the
SYSTEM account, and typing the following at the DCL prompt:
@SYS$UPDATE:VMSINSTAL VAXSYS03_072 [location of the saveset]
The saveset location may be a tape drive, CD, or a disk directory
that contains the kit saveset.
This kit requires a system reboot. Compaq strongly recommends that
a reboot is performed immediately after kit installation to avoid
system instability
If you have other nodes in your OpenVMS cluster, they must also be
rebooted in order to make use of the new image(s). If it is not
possible or convenient to reboot the entire cluster at this time, a
rolling re-boot may be performed.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| EXCEPTION.EXE |%X28E6ABA9| X-5 | 26-JUN-2002 |
| | | 11:07:13.49 |
+----------------------------+----------+-----------------+--------------+
| EXEC_INIT.EXE |%XEED8633F| X-5 | 26-JUN-2002 |
| | | 11:06:48.11 |
+----------------------------+----------+-----------------+--------------+
| FTDRIVER.EXE |%X5B633F51| X-12 | 2-SEP-1999 |
| | | 07:12:05.71 |
+----------------------------+----------+-----------------+--------------+
| IO_ROUTINES.EXE |%X6D65D2EE| X-5 | 26-JUN-2002 |
| | | 11:06:52.71 |
+----------------------------+----------+-----------------+--------------+
| LOCKING.EXE |%XC0287BE5| X-5 | 26-JUN-2002 |
| | | 11:07:00.37 |
+----------------------------+----------+-----------------+--------------+
| LOGICAL_NAMES.EXE |%XF8F5246D| X-5 | 26-JUN-2002 |
| | | 11:07:07.67 |
+----------------------------+----------+-----------------+--------------+
| MESSAGE_ROUTINES.EXE |%X955B5266| X-5 | 26-JUN-2002 |
| | | 11:07:17.44 |
+----------------------------+----------+-----------------+--------------+
| PAGE_MANAGEMENT.EXE |%XE36EF6A0| X-5 | 26-JUN-2002 |
| | | 11:06:31.82 |
+----------------------------+----------+-----------------+--------------+
| PROCESS_MANAGEMENT.EXE |%X8A762044| X-5 | 26-JUN-2002 |
| | | 11:06:11.28 |
+----------------------------+----------+-----------------+--------------+
| SECURESHR.EXE |%XA9178247| X-6 | 9-OCT-2001 |
| | | 12:47:20.14 |
+----------------------------+----------+-----------------+--------------+
| SECURESHRP.EXE |%X2DFFBA66| X-6 | 9-OCT-2001 |
| | | 12:47:17.01 |
+----------------------------+----------+-----------------+--------------+
| SECURITY.EXE |%X403CD336| X-5 | 26-JUN-2002 |
| | | 11:07:04.41 |
+----------------------------+----------+-----------------+--------------+
| SYS$CLUSTER.EXE |%X09228C2D| X-9 | 4-JUN-2002 |
| | | 20:49:38.85 |
+----------------------------+----------+-----------------+--------------+
All trademarks are the property of their respective owners.
|
