Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
HP Services Software Patches - vaxf11x04_061
 
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.
 

Copyright (c) Digital Equipment Corporation 1994, 1997.  All rights reserved.

PRODUCT:     OpenVMS VAX, Version 6.1

COMPONENTS:  File System - F11BXQP (XQP)
             ACL
             BACKUP
             SLS

SOURCE:      Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXF11X04_061
     ECO Kits Superseded by This ECO Kit:  VAXF11X01_071 (V6.1 Only)
                                           VAXF11X03_070 (V6.1 Only)
                                           VAXF11X02_062 (V6.1 Only)
                                           VAXF11X01_062 (V6.1 Only)
                                           VAXF11X03_061
                                           VAXF11X02_061
                                           VAXF11X01_061
     ECO Kit Approximate Size:  320 Blocks
     Kit Applies To:  OpenVMS VAX V6.1
     System/Cluster Reboot Necessary:  Yes

     Installation Rating:  1 - To be installed on all systems running
                               the listed version(s) of OpenVMS.

     NOTE:  In order to receive the full fixes listed in this kit,
            the following remedial kits also need to be installed:

                 VAXSYS06_070 for V6.1 (or its supersedant kit)

                 Due to a remedial change in the XQP, systems running
                 V6.1 may be at a greater risk of encountering a memory
                 management problem that may lead to system crashes. 
                 When this VAXF11X remedial kit is installed on a system,
                 the VAXSYS06_070 kit should also be installed to ensure
                 that this problem does not occur.  A description of the
                 memory management problem can be found in the
                 VAXSYS06_070 kit. 


ECO KIT SUMMARY:

An ECO kit exists for F11BXQP.EXE on OpenVMS VAX V6.1.  This kit
addresses the following problems: 

Problems Addressed in the VAXF11X04_061 Kit:

  o  An XQPERR bugcheck occurs when trying to create a file.

  o  A bad FID bugcheck occurs when trying to mark a file header free in
     the index file bitmap. 

  o  There are multiply allocated blocks and file headers on the disk. 

  o  Processes hang in an RWAST state while trying to deaccess a file
     during channel deassignment. 

  o  The system hangs during cluster wide cache flushes. 

  o  The contents of a header or bitmap block could be corrupted within
     the block buffer cache. 

  o  Failure to take an allocation lock could be ignored.

  o  If a DEACCESS request failed with a SS$_DEADLOCK error, a process
     could be left in an RWAST state indefinitely. 

  o  If a large file is created on a fragmented disk that has quotas
     enabled and the user needs to use EXQUOTA privilege to allocate the
     necessary disk space, an internal XQP table can become corrupted. 
     This leads to the following bugcheck: 

          SECAUDERR, Fatal error attempting to perform a security audit

  o  Attempting to queue a maximal length (39.39;5) filename to the XQP
     for spooling to a symbiont would cause either an infinite CPU loop
     or the following bugcheck: 

          FILCNTNONZ, Open file count nonzero after process rundown

Problems Addressed in the VAXF11X01_071 Kit for OpenVMS VAX V6.1:

  o  The problem occurs when a file is deleted while still being accessed
     by someone.  This produces an XQPERR bugcheck when an attempt is
     made to access the deleted file.

  o  The problem may result in an XQPERR bugcheck which claims that: "all
     the index buffers are active" during the processing of a directory
     file.

  o  System Hang.  Processes are stalled waiting to perform I/O
     operations, despite buffer credits being available for use. 



Problems Addressed in the VAXF11X03_070 Kit for OpenVMS VAX V6.1:

  o  A system might crash with a SECAUD bugcheck if "ANAL/DISK/ . . ."
     is run on a corrupted disk with auditing turned on.

  o  An XQP bugcheck occurs when a file is accessed for the first time
     with  cathedral windows, and the accessing process runs out of BYTLM
     quota. 

  o  Window mapping code might incorrectly concatenate extents which run
     from one volume to another in a volume set. 

  o  An XQPERR bugcheck may occur in [F11X]DIRSCNuPDATE_INDEX() during an
     attempt to insert an index entry into a directory index block with
     DIR$W_TOTALCELLS equal to zero. 

  o  Directory FCBs can become stale but invisible to the XQP.  The File
     IDs can then be reused.  If the FCB in question is an extension FCB,
     the next time the new file is accessed on that node, the XQP will
     bugcheck with the fatal XQPERR 'wrong lockbasis with FCB present'. 

  o  If a file is opened for exclusive access on one node in a cluster
     and a 'BACKUP/IGNORE=INTERLOCK' command is issued to backup the file
     on that node, after the BACKUP completes the file can be
     successfully accessed from the other node(s) of the cluster.  The
     BACKUP destroys the exclusive access. 

 o  BACKUP and SLS can cause WCBFCBMNG bugchecks when operating on some
    files.  These files are legal, uncorrupted files so they should not
    repeatedly cause a crash whenever BACKUP or SLS tries to back them up. 


Problems Addressed in the VAXF11X02_062 Kit for OpenVMS VAX V6.1:

  o  A system may crash with a BADFID bugcheck when a disk file is
     deleted.  This occurs when INDEXF.SYS is extended and the extension
     is not registered by all cluster nodes. 

  o  Due to an XQP error in the directory handling cleanup code, a file
     may appear twice in the same directory block. 

  o  Incorrect timing in blocking AST code may cause a system crash with
     a BADDALRQSZ bugcheck. 

  o  It is possible for the sequence numbers which protect the index file
     bitmap and storage bitmaps to wrap while another node is holding an
     obsolete buffer.  If that node then decides to use that buffer,
     there is a small window during which the invalid buffer could be
     seen as valid, and used to allocate blocks on the disk.  This is
     reported by the system as multiple allocated blocks after a disk has
     been defragmented. 

  o  A UNXSIGNAL crash may occur due to a corrupt Window Control Block (WCB). 

  o  When disk quota is exceeded, an extension File Control Block is not
     allocated, causing corruption of File Access Control Lists. 


Problems Addressed in the VAXF11X01_062 Kit for OpenVMS VAX V6.1:

  o  On a large, very fragmented disk with little free space and heavy
     usage, an XQP lock ranking violation can occur on a regular basis. 

  o  An XQP lock ranking violation may occur during the use of the DCL
     'EDIT/EDT' command under the following circumstances: 

       *  User B does not have an entry in the quota file.

       *  User A has CONTROL access to user B's files.  CONTROL access
          grants the accessor all the privileges of the object's actual
          owner.  User A can have this access by either being a member of
          the SYSTEM group or having the necessary entry in an ACL. 

       *  User A edits one of user B's files using EDIT/EDT.

  o  On a disk with highwater marking enabled, a file is created with
     several extents, any of which except the last one exceeds 2 Gigabytes
     in size.  When a write operation is performed on a block in the last
     extent of the file, the user may see blocks of a different file
     erased incorrectly. 

  o  An XQPERR bugcheck may occur with a message in the code 'FCBs must
     be in ascending order'.  With XQP+, there can be an unexpected lock
     manager error on a DEQ which is attempting to DEQ an FCB address. 
     The broken FCB chain in question is invariably for a multi-header
     directory which is produced by PATHWORKS V5.0 putting many ACLs on
     the directory. 

  o  When issuing a DCL 'SET SECURITY/VOLUME' command from the command
     line, it is possible to make the XQP crash. 

  o  Due to the resizing of INDEXF.SYS, the following system crashes may
     occur: 

       *  'BADFID, ACP file number out of range for this volume"

       *  'Failed to allocate FID when expected'


Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V6.1:

  o  The executive selects a random process to deassign/deaccess a
     global section file.  If the VMS File System (XQP) has not
     finished initialization of this random process before it is
     called to deassign/deaccess the global section file, the
     process may hang in the LEF or RWAST state.  The hang in RWAST
     will occur if a STOP/ID is performed on the process in LEF.

  o  Certain uses of the SET FILE/ENTER command can "leak" a File
     Control Block (FCB) structure.  For example, if the file being
     entered has more than one header, an FCB is lost for every header.
     The extension FCBs have reference counts of 1 so the transaction
     count on the disk will be left high (>1).  Consequently, the disk
     cannot be dismounted because of "[n] user files open on volume".

  o  During an IO$_CREATE function, usually RENAME, an XQPERR bugcheck
     may occur.

  o  When attempting to create a file on a volume set and a previous
     version of the file exists, an XQPERR bugcheck may occur.

  o  An access violation (ACCVIO) in the routine EXE$SEARCH_RIGHT
     results in an UNXSIGNAL crash.

  o  After deletion of a large file, the free disk space value reported
     by SHOW DEVICE can indicate that disks have more or less free space
     than the disks actually have.

  o  Restore ability to use wildcard values for valid UIC owner and group
     value ranges.


Problems Addressed in the VAXF11X02_061 Kit for OpenVMS VAX V6.1:

  o  As of OpenVMS VAX V6.0, movement of directory files is allowed
     as long as no node in the cluster has data from these files
     cached.

     The cluster-wide check for this condition does not work
     properly.  This results in cache incoherency and, as a result,
     directory file corruption.  Common symptoms of this problem are:

       +  out-of-order directory listings
       +  duplicate directory entries for the same file
       +  "lost" files
       +  inconsistent directory listings on different nodes
       +  files appearing in directory listings which are
          not "accessible" from the RMS level (i.e., they
          cannot be "typed" out).

  o  Crashes may occur from unexpected SS$_NOTQUEUED after $ENQ with
     LCK$M_NOQUEUE.  There are several places in the XQP where the
     code will $ENQ for a lock on a resource specifying LCK$M_NOQUEUE,
     since it does not expect to have to queue for the lock.  Under
     certain circumstances (detailed  below), it will receive back
     a status of SS$_NOTQUEUED, indicating that it did not get the
     lock since it would had to have queued for the lock.  This causes
     a fatal bugcheck and the system crashes.


Problems Addressed in the VAXF11X01_061 Kit for OpenVMS VAX V6.1:

  o  When the ACL of a file is modified, the revision date is not
     updated.  Therefore, the file will not be backed up by an
     incremental backup and data could be lost.


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. 
Files on this server are as follows:
»vaxf11x04_061.README
»vaxf11x04_061.CHKSUM
»vaxf11x04_061.CVRLET_TXT
»vaxf11x04_061.a-dcx_vaxexe
privacy statement using this site means you accept its terms