| » contact hp |
search: |  | more options |
| Supportall of hp US

|  | HP Services Software Patches |

» | 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
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 |
© 1994-2002 Hewlett-Packard Company