|
|
 |
OpenVMS VMS72_SYS-V0300 Alpha V7.2 System ECO Summary
|
TITLE: OpenVMS VMS72_SYS-V0300 Alpha V7.2 System ECO Summary
Modification Date: 07-APR-2000
Modification Type: Updated Kit: Supersedes VMS72_SYS-V0200
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
For OpenVMS savesets, the name of the compressed saveset
file will be kit_name.a-dcx_vaxexe for OpenVMS VAX or
kit_name.a-dcx_axpexe for OpenVMS Alpha. Once the OpenVMS
saveset is copied to your system, expand the compressed
saveset by typing RUN kitname.dcx_vaxexe or kitname.dcx_alpexe.
For PCSI files, once the PCSI file is copied to your system,
rename the PCSI file to kitname.pcsi-dcx_axpexe, then it can
be expanded by typing RUN kitname.pcsi-dcx_axpexe. The resultant
file will be the PCSI installation file which can be used to install
the ECO.
Copyright (c) Compaq Computer Corporation 1999, 2000. All rights reserved.
PRODUCT: OpenVMS Alpha
COMPONENTS: IMAGE_MANAGEMENT
LOGICAL_NAMES
PROCESS_MANAGEMENT
PROCESS_MANAGEMENT_MON
SECURITY
SECURITY_MON
SYS$CLUSTER
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VMS72_SYS-V0300
DEC-AXPVMS-VMS72_SYS-V0300--4.PCSI
ECO Kits Superseded by This ECO Kit: VMS72_SYS-V0200
DEC-AXPVMS-VMS72_SYS-V0200--4.PCSI
VMS72_SYS-V0100
ECO Kit Approximate Size: 3456 Blocks
Kit Applies To: OpenVMS Alpha V7.2
System/Cluster Reboot Necessary: Yes
Rolling Re-boot Supported: Yes
Installation Rating: INSTALL_1 - To be installed on all systems running
the listed version(s) of OpenVMS.
Kit Dependencies:
The following remedial kit(s) must be installed BEFORE
installation of this kit:
VMS72_UPDATE-V0200
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
None
ECO KIT SUMMARY:
An ECO kit exists for Process Management and Security on OpenVMS Alpha
V7.2. This kit addresses the following problems:
Problems Addressed in VMS72_SYS-V0300:
o Subprocesses created from image (LIB$SPAWN) do not inherit the
parents image privileges.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
o If process termination occurs while image activation is in
progress, an ACCVIO may occur.
Images Affected:
- [SYS$LDR]IMAGE_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
o IPL synchronization issues in the Cluster-Wide Process Services
code for the $GETJPI system service opens a context corruption
timing window. The problem can crash either the sending or target
node in an OpenVMS Cluster via CWSERR or INVEXCEPTN bugchecks in
SYS$CLUSTER code. In most cases the target node crashes but the
actual corruption occurred on the sending node.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]SYS$CLUSTER.EXE
o A BASIC application terminates abnormally with the
BAS$_PROLOSSOR, DEVFOREIGN or ACCVIO status.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
o MFPR_xxx and MTPR_xxx PALcode instructions can leave registers
R1, R16 and R17 with unpredictable results. These registers
were not always saved and restored in ASTDEL_STACK.M64.
Although corruptions of these registers have not been known to
occur, the potential is there, particularly on newer platforms.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
o SET PROCESS/PRIORITY=n fails with the following error:
"%SET-E-NOTSET, need ALTPRI privilege to elevate above base
priority"
when the target process is on a remote cluster node.
Images Affected: [SYS$LDR]SYS$CLUSTER.EXE
o A call to $SETPRV may not result in the requested modifications
being applied to the security structures. Subsequent calls
requiring the UNSET privileges may fail with SS$_NOPRIV. This
only occurs when the SYSGEN parameter ARB_SUPPORT equals 3.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
o Image activation retry fails for process created for single
image execution. Image activation retry is used to deal with
un-satisfied shared address data dependencies.
For example:
$ RUN SYS$SYSTEM:INSTALL
sys$library:librtl /delete
sys$library:librtl /open/header/shared
$ start/que MM$TEST_LATSYM
%RMS-F-SYN, file specification syntax error
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
o System crashes with INVEXCEPTN while above ASTDEL. The
failing PC is at OTS$REM_UL_C+B8 in SYS$BASE_IMAGE.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
o Redefining a logical name table, such as LNM$TEMPORARY_MAILBOX,
to a process-private logical name table may lead to a system crash
if the process also creates a mailbox with a logical name. The
crash would typically occur when the CLUSTER_SERVER process was
the current process.
Images Affected: [SYS$LDR]LOGICAL_NAMES.EXE
Problems Addressed in VMS72_SYS-V0200:
o Identifiers are being ignored on user accounts.
When granting identifiers to a user, access to a queue that had
previously worked was no longer working. This is shown below:
$ submit/user=USER1/nolog SYS$SYSDEVICE:[USER1]test/que=USER1$test
%SUBMIT-F-CREJOB, error creating job
-JBC-E-NOPRIV, insufficient privilege or queue protection violation
$
$ uaf grant/id ID1 USER1
%UAF-I-GRANTMSG, identifier ID1 granted to USER1
$
$ submit/user=USER1/nolog SYS$SYSDEVICE:[USER1]test/que=USER1$test
Job TEST (queue USER1$TEST, entry 7) started on USER1$TEST
$
$ uaf grant/id ID2 USER1
%UAF-I-GRANTMSG, identifier ID2 granted to USER1
$
$ submit/user=USER1/nolog SYS$SYSDEVICE:[USER1]test/que=USER1$test
Job TEST (queue USER1$TEST, entry 8) started on USER1$TEST
$
$ uaf grant/id ID3 USER1
%UAF-I-GRANTMSG, identifier ID3 granted to USER1
$
$ submit/user=USER1/nolog SYS$SYSDEVICE:[USER1]test/que=USER1$test
Job TEST (queue USER1$TEST, entry 9) started on USER1$TEST
$
$ uaf grant/id ID4 USER1
%UAF-I-GRANTMSG, identifier ID4 granted to USER1
$
$ submit/user=USER1/nolog SYS$SYSDEVICE:[USER1]test/que=USER1
$test
%SUBMIT-F-CREJOB, error creating job
-JBC-E-NOPRIV, insufficient privilege or queue protection violation
Images Affected:
- [SYS$LDR]SECURITY.EXE
Problems Addressed in VMS72_SYS-V0100:
o Non-privileged system crashes
A problem that can lead to non-privileged system crashes has been
identified in all OpenVMS V7.2-1 systems, and in OpenVMS Alpha V7.2
systems with the VMS72_UPDATE-V0100 or VMS72_HARDWARE-V0100 ECO
kit(s) installed. The following OpenVMS Alpha environments are
specifically affected:
OpenVMS Alpha V7.2-1
OpenVMS Alpha V7.2 with DEC-AXPVMS-VMS72_UPDATE-V0100--4
OpenVMS Alpha V7.2 with DEC-AXPVMS-VMS72_HARDWARE-V0100--4
No other OpenVMS Alpha releases or ECO kits are affected.
OpenVMS VAX is not affected.
In the specified OpenVMS Alpha system environments, certain
non-privileged programming errors and certain command errors within
specific non-privileged DCL commands can trigger an OpenVMS system
service exception and a resulting system crash.
The bugcheck is "SSRVEXCEPT, Unexpected system service exception",
and the crash itself can be identified by locating a reference to
the EXE$NAM_TO_PCB routine and the PROCESS_MANAGEMENT module in the
contents of the stack present at the time of the system crash, and
specifically by looking in a stack frame prior to the failing stack
frame in the system crashdump. The user or the application that has
issued the errant DCL command or the errant system service call can
also be determined from the contents of the system crashdump. To
correct this problem, OpenVMS Engineering recommends the
installation of the following ECO kit (or later) for OpenVMS Alpha
V7.2:
DEC-AXPVMS-VMS72_SYS-V0100--4
Even though this problem exists only on V7.2 systems that have the
VMS72_HARDWARE-V0100 and/or VMS72_UPDATE-V0100 kit(s) installed,
OpenVMS Engineering recommends that customers install this kit in
ALL V7.2 environments. This will prevent occurrence of this problem
in the event the HARDWARE or UPDATE kits are installed at a later
time.
The following ECO kit (or later) should be installed for OpenVMS
Alpha V7.2-1:
DEC-AXPVMS-VMS721_SYS-V0100--4
To activate the fix, a system reboot is required.
The OpenVMS Alpha version and the ECO kits presently installed on
the local system can be identified using the DCL command:
PRODUCT SHOW PRODUCT VMS/FULL
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
INSTALLATION NOTES:
Install this kit with the POLYCENTER Software Installation utility by
logging into the SYSTEM account, and typing the following at the DCL
prompt:
PRODUCT INSTALL VMS72_SYS /SOURCE=[location of Kit]
The kit location may be a tape drive, CD, or a disk directory that
contains the kit.
Additional help on installing PCSI kits can be found by typing HELP
PRODUCT INSTALL at the system prompt
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.
All trademarks are the property of their respective owners.
|
Files on this server are as follows:
|
»dec-axpvms-vms72_sys-v0300--4.README
»dec-axpvms-vms72_sys-v0300--4.CHKSUM
»dec-axpvms-vms72_sys-v0300--4.pcsi-dcx_axpexe
»vms72_sys-v0300.CVRLET_TXT
|
