OpenVMS VAXMANA04_070 V5.5-2 - V6.1 and V7.0 SYSMAN ECO Summary
TITLE: OpenVMS VAXMANA04_070 V5.5-2 - V6.1 and V7.0 SYSMAN ECO Summary
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
The name of the compressed file will be kit_name-dcx_vaxexe
for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
Once the file is copied to your system, it can be expanded
by typing RUN compressed_file. The resultant file will
be the OpenVMS saveset or PCSI installation file which
can be used to install the ECO.
*OpenVMS] VAXMANA04_070 (V5.5-2 - V6.1 and V7.0 SYSMAN) ECO Summary
Copyright (c) Compaq Computer Corporation 1997, 1999. All rights reserved.
Modification Date: 18-JUN-99
Modification Type: The V6.2 part of VAXMANA04_070 has been superseded
by VAXMANA02_062.
OP/SYS: OpenVMS VAX
COMPONENT: SYSMAN.EXE
SMISERVER.EXE
SMI$OBJSHR.EXE
SMI$SHR.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXMANA04_070
ECO Kits Superseded by This ECO Kit: VAXMANA03_070
VAXMANA02_070
VAXMANA01_070
VAXMANA02_061
VAXMANA02_060
VAXMANA01_060
VAXMANA01_061
VAXMANA05_U2055
VAXMANA04_U2055
MANAGE$02_U2055
MANAGE$03_055
ECO Kit Approximate Size: 3402 Blocks
Saveset A - 108 Blocks
Saveset B - 558 Blocks
Saveset C - 576 Blocks
Saveset D - 576 Blocks
Saveset E - V6.2 files - removed
Saveset F - 774 Blocks
Kit Applies To: OpenVMS VAX V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1, V7.0
System/Cluster Reboot Necessary: Yes
Installation Rating: INSTALL_3 - To be installed on all systems running
the listed versions of OpenVMS which
are experiencing the problems described.
NOTE: In order to receive the full fixes listed in this kit,
the following remedial kits also need to be installed:
None
ECO KIT SUMMARY:
An ECO kit exists for SYSMAN/SMISERVER on OpenVMS VAX V5.5-2 through V6.1
and V7.0. This kit addresses the following problems:
Problems Addressed in the VAXMANA04_070 Kit for for OpenVMS VAX V7.0:
o Incorrect problem statement noted in the VAXMANA03_070 kit
(Correct SYSMAN DISKQUOTA ENABLE|DISABLE command behavior.)
This problem has not been fixed. This kit, VAXMANA04_070
removes this problem statement from the documentation. This
kit does not contain any new fixes.
Problems Addressed in the VAXMANA01_070 Kit for V6.1 and V7.0:
o SYSMAN DO commands that result in very long output records
result in errors similar to the following:
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-MBTOOSML, mailbox is too small for request
There may be some SYSMAN truncation errors also.
Problems Addressed in the VAXMANA01_070 Kit for V7.0:
o The SYSMAN PARAM SET command, when executed on a cluster, would
return with an extraneous NOMORENODE error message.
o The SYSMAN PARAM SET command, when executed on a cluster, would
return with an extraneous NOMORENODE error message.
o With the SYSMAN DO command, certain DCL commands that do not
have output (e.g. SYSMAN> DO DEFINE XXX YYY) would take at
least 10 seconds/node to complete.
o SYSMAN accommodates the use of a ! at the beginning of its
command line. All characters subsequent to the ! are ignored
and processing is passed to the next SYSMAN> prompt. A
regression in behavior occurred causing a ! character at the
beginning of a SYSMAN command line to return:
%CLI-W-NOCOMD, no command on line - reenter with alphabetic first
character
Problems Addressed in the VAXMANA02_061 Kit:
o For nodes running DECNET Phase V, SYSMAN may return the
following errors:
%SYSMAN-I-NODERR, error returned from node
LIB-F-INSEF, insufficient event flags
when repeatedly issuing a DO command, exiting and then
re-entering SYSMAN to issue another DO command. Mailboxes were
not being deassigned at the end of the SYSMAN session.
o SMISERVER experiences intermittent hangs, particularly when
SYSMAN DO commands are issued from within a batch job.
Problems Addressed in the VAXMANA02_060 Kit:
o The VAXMANA01_060 kit was missing documentation concerning
various fixes in the kit.
o Under certain conditions, SYSMAN users, who have large numbers
of rights identifiers associated with their accounts, could
cause the SMISERVER to fail. This fix places a temporary
restriction on the number of rights identifiers that SYSMAN
users may hold. SYSMAN users will be limited to 60 rights
identifiers per account. This limitation is an inclusive total
identifiers per account. This limitation is an inclusive total
of all process, system, image and extended rights.
This limitation includes the 3 identifiers that are granted
during login when the process rights list is created: a UIC
identifier, a system identifier, and, depending upon the
environment in which the process is operating, at least one
environmental identifier.
If a SYSMAN user, running with more than 60 total rights
identifiers, attempts to invoke a SYSMAN command, the following
message will be returned:
SMI-E-RIGHTSLIM, Temporary restriction: rights limit exceeded
Users wishing to run SYSMAN must either have a separate account
with no more than 60 rights, or have enough identifiers removed
from the current account such that the total number of rights
falls within the appropriate range. Such account modification/
creation will generally be performed by a System Manager.
Problems Addressed in the VAXMANA01_060 Kit:
o Occasionally, at the completion of a DO command, SMISERVER
fails to detect completion of the detached process in which the
DO command was executed, and it goes CPU bound. The DO command
has returned all its output, but SYSMAN never returns the
"SYSMAN" prompt. Investigation of the target system shows
SMISERVER CPU bound at priority 7.
o SYSMAN/SMI allows a user to send commands to a remote node for
execution on that node.
In addition, a user on V6.0 systems, with lots of rights granted
to his account, can send SMI messages which can cause SMISERVER
failures on V5.5-2 nodes, and possibly crash such systems.
o If an AXP SYSMAN user issues the IO function to SMISERVER on a
VAX, the SMISERVER on the target VAX fails, causing a dump. It
then restarts itself.
o Using SYSMAN from an OpenVMS VAX V6.0 or V6.1 node, it is
possible to cause the SMI server on an older OpenVMS VAX node
to malfunction. This malfunction may result in either an
SMISERVER process dump, or a system crash.
The user producing such failures generally has a moderately
large number of rights granted. A user with approximately 20
rights can produce these failures.
o When using the CSP SMI link within a cluster, the default
Device/Directory is incorrect on the target SMI system.
If the user has set his default to something other than his
login default before running SYSMAN, and if he issues SYSMAN
commands to another node or nodes within the same cluster, then
the SMI server is supposed to use his current default
device/directory. Instead, the SMISERVER was using his login
default device/directory.
o The SYSMAN ALF function would lock the ALF data file. Thus,
while a user was using SYSMAN ALF, the Auto Login Facility
didn't work, since its file was locked.
Problems Addressed in the VAXMANA01_061 Kit:
o Non-privileged users often see SYSMAN DO commands hang for 10
seconds. Specifically, the first user of SMISERVER (after reboot
of a node) generally works fine. However, after that first use,
if a different user, who has no SYSPRV, GRPPRV, BYPASS etc.
privilege, tries to do DO commands to the same node they generally
see hangs.
o Under certain conditions, SYSMAN users, who have large numbers
of rights identifiers associated with their accounts, could
cause the SMISERVER to fail. This fix places a temporary
restriction on the number of rights identifiers that SYSMAN
users may hold. SYSMAN users will be limited to 60 rights
identifiers per account. This limitation is an inclusive total
of all process, system, image and extended rights.
This limitation includes the 3 identifiers that are granted
during login when the process rights list is created: a UIC
identifier, a system identifier, and, depending upon the
environment in which the process is operating, at least one
environmental identifier.
If a SYSMAN user, running with more than 60 total rights
identifiers, attempts to invoke a SYSMAN command, the following
message will be returned:
SMI-E-RIGHTSLIM, Temporary restriction: rights limit exceeded
Users wishing to run SYSMAN must either have a separate account
with no more than 60 rights, or have enough identifiers removed
from the current account such that the total number of rights
falls within the appropriate range. Such account
modification/creation will generally be performed by a System
Manager.
Problems Addressed in the VAXMANA05_U2055 Kit:
o Non-privileged users often see SYSMAN DO commands hang for 10
seconds. Specifically, after reboot of a node, the first user
of SMISERVER generally sees no problem. However, after that
first use, if a different user, who has no SYSPRV, GRPPRV,
BYPASS etc. privileges tries to do DO commands to the same
node the user will see a hang.
Problems Addressed in the VAXMANA04_U2055 Kit:
o Occasionally the SMISERVER process will go CPU bound a
priority 7. Occasionally, at the completion of a DO command
SMISERVER fails to detect completion of the detached process in
which the DO command was executed, and it goes CPU bound. The
DO command has returned all its output, but SYSMAN never
returns the "SYSMAN" prompt.
o A spurious end of file on the Cluster Server and Network
communication Mailbox will cause the SMISERVER to abort.
o SYSMAN/SMI allows a user to send commands to a remote node for
execution on that node.
A privileged user on V6.0 systems can send SMI messages which
can cause SMISERVER failures on V5.5-2 nodes, and possibly
crash such systems.
o The SMISERVER "DO" command has caused problems that include:
- Hangs when doing a "DO" command on a heavily loaded cluster.
- SMISERVER failing due to memory corruptions.
o SMISERVER can hang due to the detached processes performing DO
commands.
Problems Addressed in the MANAGE$02_U2055 Kit:
o Specifying the name of the local node in non-clustered systems
which do not have SCSNODE defined can cause the following
error:
SYSMAN> SET ENV/NODE=MYNODE
SYSMAN> DO SHOW TIME
%SYSMAN-I-OUTPUT, command execution on node
%SYSMAN-F-NOSUCHNODE, remote node is unknown
o The CLUSTER_SERVER process could hang. This would be indicated
by:
- The CLUSTER_SERVER process going into RWMBX state and/or having a
number of busy channels assigned to the SMI$CSPTOSMIMBX mailbox
device
- No busy channels to the SMI$SMITOCSPMBX mailbox device while the
SMISERVER process has a busy channel to the SMI$MITOCSP mailbox.
o Decrease the amount of BYTLM required to process an SMISERVER
request in order to increase the number of requests which can
be processed in parallel.
o It is possible that SYSMAN could only show partial output for a
command (i.e., it only displays the first (n) lines of output).
This could be seen when performing operations which generated a
lot of output very quickly and is only a problem on SMP type
systems.
o SMISERVER could see internal corruptions possibly resulting in
process failures. Symptoms are those of general corruptions,
likely including either IOSB data of SYSMAN output overwriting
in-use stack locations.
Problems Addressed in the MANAGE$03_055 Kit:
o Handling of ^C and ^Y interrupts could cause SYSMAN/SMI to hang
and refuse future requests.
o Additional logic has been added to improve the interaction
between the SMISERVER process and the CLUSTER_SERVER process,
which eliminates a possible system bottleneck.
INSTALLATION NOTES:
In order for the corrections in this kit to take effect, the system
must be rebooted. If the system is a member of a VMScluster, the
entire cluster should be rebooted.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxmana04_070.README
.CHKSUM
vaxmana04_070.a-dcx_vaxexe
vaxmana04_070.b-dcx_vaxexe
vaxmana04_070.c-dcx_vaxexe
vaxmana04_070.d-dcx_vaxexe
vaxmana04_070.f-dcx_vaxexe
vaxmana04_070.CVRLET_TXT
|