SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
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

privacy and legal statement