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 - vaxf11x03_070
 
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] VAXF11X03_070 VAX V5.5-2 - V7.0 File System ECO Summary
 
Copyright (c) Digital Equipment Corporation 1994, 1996.  All rights reserved.

OP/SYS:     OpenVMS VAX

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

SOURCE:     Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXF11X03_070
     ECO Kits Superseded by This ECO Kit:  VAXF11X02_070
                                           VAXF11X01_070
                                           VAXF11X02_062
                                           VAXF11X01_062
                                           VAXF11X03_061
                                           VAXF11X02_061   (CSCPAT_1137)
                                           VAXF11X01_061
                                           VAXF11X03_060   (CSCPAT_1096)
                                           VAXF11X02_060
                                           VAXF11X01_060
                                           VAXF11X04_U2055 (CSCPAT_1162)
                                           VAXF11X03_U2055
                                           VAXF11X02_U2055
                                           VAXF11X01_U2055
     ECO Kit Approximate Size:  1348 Blocks
                    Saveset A -  126 Blocks
                    Saveset B -  216 Blocks
                    Saveset C -  216 Blocks
                    Saveset D -  234 Blocks
                    Saveset E -  234 Blocks
                    Saveset F -  270 Blocks
                 Cover Letter -   52 Blocks

     Kit Applies To:  OpenVMS VAX V5.5-2, V5.5-2H4, V5.5-2HF,
                                  V6.0, V6.1, V6.2, V7.0
     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, V6.2 and V7.0 installations only.

            Due to a remedial change in the XQP, systems running the  
            versions listed above may be at a greater risk of
            encountering a memory management problem that may lead 
            to system crashes.   When the VAXF11X03_070 remedial kit
            is installed on a system, the VAXSYS06_070 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 remedial kit.


ECO KIT SUMMARY:

An ECO kit exists for F11BXQP.EXE on OpenVMS VAX V5.5-2 through V7.0.
This kit addresses the following problems:

Problems Addressed in the VAXF11X03_070 Kit for OpenVMS VAX V6.1,
  V6.2 and V7.0:

  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.


Problems Addressed in the VAXF11X03_070 Kit for OpenVMS VAX V5.5-2,
  V5.5-2H4, V5.5-2HF, V6.1, V6.2, and V7.0:

 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_070 Kit for OpenVMS VAX V7.0:

  o  The VAXF11X01_070 remedial kit placed the OpenVMS VAX V7.0
     F11BXQP.EXE image in the SYS$SYSTEM directory.  For V7.0 the
     location of this file changed.  The file should now be placed in
     the SYS$LOADABLE_IMAGES images directory. 


Problems Addressed in the VAXF11X01_070 Kit for OpenVMS VAX V7.0:

  o  When enabling quotas on the system  disk, the system occasionally
     crashes with an ACCVIO.

  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  UNXSIGNAL crash due to a corrupt Window Control Block.

  o  File Access Control Lists are corrupted after a failure to allocate
     an extension File Control Block due to disk quota being exceeded.


Problems Addressed in the VAXF11X01_070 Kit for OpenVMS VAX V5.5-2,
V5.5-2H4, V5.5-2HF:

  o  This fix merges the PWXQP+ threaded OpenVMS VAX V5.5-2 XQP with the
     OpenVMS VAX remedial V5.5-2 code.  From this point on, all V5.5-2
     XQP kits will provide the threaded version of the XQP.  This XQP has
     exactly the same functionality as the current V5.5-2 XQP except when
     multi-threading is explicitly enabled.


Problems Addressed in the VAXF11X02_062 Kit:

  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.


  o  File Access Control Lists become corrupted after a failure
     to allocate an extension File Control Block due to disk quota
     being exceeded.


Problems Addressed in the VAXF11X01_062 Kit:

  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.


Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V5.5-2 and
V6.1:

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


Problems Addressed in the VAXF11X03_061 Kit for OpenVMS VAX V5.5-2, V6.0
and V6.1:

  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.


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

  o  The ability to use wildcard values for valid UIC owner and group
     value ranges has been restored.


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.


Problems Addressed in the VAXF11X03_060 Kit for OpenVMS VAX V6.0:

  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).


Problems Addressed in the VAXF11X02_060 Kit for OpenVMS VAX V6.0:

  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.


Problems Addressed in the VAXF11X01_060 Kit for OpenVMS VAX V6.0:

  o  When a file is opened with an NL mode access lock, an attempt
     to access an extension header may fail because the FCB chain is
     being re-built.

  o  The BACKUP utility accesses file extension headers directly
     without going through the synchronization of the primary
     header.  This allows the FCBs for the headers being looked
     at by BACKUP to be deallocated by other processes.  The
     results of this are exhibited as any one of several different
     XQP bugchecks.  The most notable of these bugchecks are
     UNXSIGNAL (ACCVIO), NOTFCBFCB and XQPERRs.


Problems Addressed in the VAXF11X04_U2055 Kit for OpenVMS VAX V5.5-2:

  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 VAXF11X03_U2055 Kit for OpenVMS VAX V5.5-2:

  o  If an application tries to access (IO$_ACCESS | IO$M_ACCESS)
     an extension header directly when the file (primary header/-
     File Control Block) is not open, the call usually fails with
     SS$_NOSUCHFILE.  However, if the header is the first extension
     header in a chain and contains only mapping pointers, an
     incorrect SS$_ACCONFLICT error is returned.  If the header
     contains an ACL, an [F11X]INIFC2.B32/FILL_FCB crash occurs.
     The offset of this crash varies.

  o  When accessing extension headers directly, cached File Control
     Blocks from the Virtual I/O Cache (VIOC) can appear to be the
     primary File Control Block.  This can cause unsynchronized
     access to extension headers.


Problems Addressed in the VAXF11X02_U2055 Kit for OpenVMS VAX V5.5-2:

  o  There is a basic lock manager design problem that manifests
     itself in two different file system problems.

     1.  Occasionally access to a cluster-shared file is
         incorrectly denied to an accessor.  An application
         will attempt to access a shared file in what looks
         to be a compatible way and will receive an
         SS$_ACCONFLICT status.

     2.  Occasionally an application will create a new file
         and the system will crash in CREATE with an XQP
         bugcheck whose text says "how can we fail to
         access a new file."

  o  When a file is open with an NL mode access lock, an attempt
     to access an extension header may fail because the FCB chain
     is being rebuilt.

  o  The BACKUP utility accesses file extension headers directly
     without going through the synchronization of the primary
     header.  This allows the FCBs for the headers being looked
     at by BACKUP to be deallocated by other processes.  The
     results of this are exhibited as any one of several different
     XQP bugchecks.  The most notable of these bugchecks are
     UNXSIGNAL (ACCVIO), NOTFCBFCB and XQPERRs.


Problems Addressed in the VAXF11X01_U2055 Kit for OpenVMS VAX V5.5-2:

  o  Reading beyond the File Highwater Mark (FHM) returns a
     success status but the user's buffer is not modified.
     This problem manifested itself principally when doing
     BACKUP/VERIFY on files whose FHM was less than the
     physical file size.   When condition occurs under BACKUP,
     a %BACKUP-E-VERIFYERR error is returned.

     This problem is fixed in OpenVMS VAX V6.0.

  o  If a write error is encountered while writing directory
     data blocks, the system may crash with an XQPERR bugcheck
     at REMOVE+4F.  Directory corruption may also occur.

     This problem is fixed in OpenVMS VAX V6.0.

  o  The file system will attempt to acquire and subsequently
     release a SERIAL lock of a particular file while it still
     holds the ALLOCATION lock for the volume on which the
     particular file exists.  This is incorrect behavior.

     This problem is fixed in OpenVMS VAX V6.0.

  o  Disk space is inefficiently used due to the default extension
     size of INDEXF.SYS.  The algorithm now tries to extend the
     file by 15% of MAX_FILES - HEADERS_USED.  It does this until
     the index file has grown to 90% of MAX_FILES.  From then on
     the file is extended in increments of 1% of MAX_FILES.

     This problem is fixed in OpenVMS VAX V6.0.

     CSC NOTE:  This problem may also occur on OpenVMS Alpha V6.1.
                The AXPF11X02_061 ECO kit will fix the problem on
                OpenVMS Alpha V6.1.

  o  During a cluster transition, lock value blocks may normally
     become invalid.  However, the file system does not take
     appropriate action when encountering invalid value blocks.

     This problem is fixed in OpenVMS VAX V6.0.

  o  When running DECps and using the hot file collection feature,
     the system may crash with a FCBNOTFCB bugcheck if a process
     accesses an extension file header by FID (File ID) at the
     same time that the header is being deleted.

     This problem is fixed in OpenVMS VAX V6.0.

  o  When two processes access a shared file which has multiple
     file headers, one process may fail with an SS$_PAGRDERR error.
     For example:

        -  Image A creates FILE.DAT
        -  Image A writes 100 blocks to FILE.DAT
        -  Image B opens FILE.DAT
        -  Image B calls $CRMPSC and maps FILE.DAT
        -  Image A extends FILE.DAT to 200 blocks (FILE.DAT now has
           multiple file headers)
        -  Image B calls $CRMPSC and remaps FILE.DAT
        -  Image B tries to reference address returned from $CRMPSC
           and terminates with a SS$_PAGRDERR error.

     This problem is fixed in OpenVMS VAX V6.0.

  o  On a very fragmented disk, if the creation of a new file
     causes INDEXF.SYS to be extended, the index file may become
     corrupt.  When this occurs, the 'DUMP/HEADER INDEXF.SYS' DCL
     command displays a value of 256.  The ANALYZE/DISK command
     returns an "invalid map area" error.

     This problem is fixed in OpenVMS VAX V6.0.

  o  If a nonprivileged user performs a 'SET FILE/NODIRECTORY'
     command on a directory file that he does not own, an error
     is not returned.  However, the file retains the directory
     attribute.

     This problem is fixed in OpenVMS VAX V6.0

  o  Possible data corruption occurs after EXTEND failures on
     bound volume sets when the Window Control Block (WCB) is
     not reinitialized properly.

     This problem is fixed in OpenVMS VAX V6.0.

  o  The system crashes when reading a corrupt directory entry
     instead of returning a SS$_BADIRECTORY status.

     This problem is fixed in OpenVMS VAX V6.0.

  o  Problems occur when the file system accesses directories
     that are created non-contiguous by a QIO request.  This QIO
     request is no longer allowed.

     This problem is fixed in OpenVMS VAX V6.0.

  o  Under the following very specific set of conditions, the
     contents of a file may be corrupted by the file system:

     1.  File must be on Bound Volume Set
     2.  File must NOT be on RVN 1
     3.  File must be open
     4.  System must be running standalone, or the Bound Volume Set
         must not be available to any other node in a cluster.

     This problem is fixed in OpenVMS VAX V6.0.


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 must be rebooted.
Files on this server are as follows:
»vaxf11x03_070.README
»vaxf11x03_070.CHKSUM
»vaxf11x03_070.CVRLET_TXT
»vaxf11x03_070.a-dcx_vaxexe
»vaxf11x03_070.b-dcx_vaxexe
»vaxf11x03_070.c-dcx_vaxexe
»vaxf11x03_070.d-dcx_vaxexe
»vaxf11x03_070.e-dcx_vaxexe
»vaxf11x03_070.f-dcx_vaxexe
privacy statement using this site means you accept its terms