Australia - Updated: 24-SEP-2003
hp.com home products and services support and drivers solutions how to buy
» contact hp
hp.com home hp OpenVMS ECOs

IMPORTANT NOTICE

The online distribution of OpenVMS and related product patches is being migrated to the HP ITRC (Information Technology Resource Center) patch distribution site. The new ITRC patch server will allow OpenVMS customers to take advantage of many enhanced features for patch searching and distribution.

Beginning August 1, 2003, OpenVMS and related Layered Product, publicly available patches will be available from the HP ITRC web site at

http://itrc.hp.com/service/patch/mainPage.do

The same patches will still be available from the existing patch server in Colorado Springs (http://www.support.compaq.com/patches/) through the end of October 2003, to give customers sufficient time to update their bookmarks and make the transition to the HP ITRC web site.

ECO kits will also be available by raw FTP from (ftp://ftp.itrc.hp.com/).

PLEASE UPDATE YOUR BOOKMARKS AND REGISTER ON THE NEW SITE NOW

Note: if you're having trouble connecting to the ITRC site, please delete any cookies for "itrc.hp.com" from your browser and try again. Report any difficulties with or suggestions to MrVMS

» Sydney CSC home page

Navigation
» ECOinfo main index
» Search ECOs
» Search FTP site
» Browse FTP site

ECO Indexes
» Chronological Index
» Indexed by Version
» Indexed by Rating
» Alpha Indexed by Name
» VAX Indexed by Name
» On Hold List

Associated Links
» OpenVMS Home Page
» OpenVMS News
» DIA/WIS Web Service

Feedback
» mail to CSC
.
Sydney Customer Support Centre OpenVMS ECO information
    Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)

VAXF11X06_071 (VAX V7.1) F11BXQP ECO Summary

To obtain this kit please call the Customer Support Centre or use the FTP site

Search for this ECO kit and dependencies
Search the Compaq FTP web site this kit (exact match)
Search the Compaq FTP web site this or related ECOs

    
      
    Copyright (c) Compaq Computer Corporation 1998, 2000.  All rights reserved.
    
    Modification Date:  13-JUN-2000
    Modification Type:  Updated Kit:  Supersedes VAXF11X05_071
    
    PRODUCT:     OpenVMS VAX
    
    COMPONENTS:  F11BXQP
                 F11AACP
                 FILESERV
                 VMS$CONFIG-050_CACHE_SERVER.COM
    
    SOURCE:      Compaq Computer Corporation
    
    
    ECO INFORMATION:
    
         ECO Kit Name:  VAXF11X06_071
         ECO Kits Superseded by This ECO Kit:  VAXF11X05_071
                                               VAXF11X04_071
                                               VAXF11X03_071
         ECO Kit Approximate Size:  432 Blocks
         Kit Applies To:  OpenVMS VAX V7.1
         System/Cluster Reboot Necessary:  Yes
         Rolling Re-boot Supported:  Yes
         Installation Rating:  INSTALL_1
                               1 - To be installed on all systems running
                                   the listed version(s) of OpenVMS.
    
         Kit Dependencies:
    
           The following remedial kit(s) must be installed BEFORE
           installation of this kit:
    
             VAXY2K01_071
    
           In order to receive all the corrections listed in this
           kit, the following remedial kits should also be installed:
    
             VAXSYSA02_071
    
    
    ECO KIT SUMMARY:
    
    An ECO kit exists for F11BXQP on OpenVMS VAX V7.1.  This kit addresses
    the following problems:
    
    Problems Addressed in VAXF11X06_071:
    
      o  The VAXF11X05_071 kit installed the F11BXQP.EXE image in the
         [SYSEXE] directory.   It should have been installed in the
         [SYS$LDR] directory
    
    
    Problems Addressed in VAXF11X05_071:
    
      o  NOTFCBFCB Bugcheck on simultaneous dereference of file
    
         When two processes are accessing a file via the MOVEFILE and
         READATTR/FID_TO_SPEC mechanism, such as a data collector process
         running on the same volume as a defragger competing for the same
         data, both processes try to delete the 'primary_fcb' used to get the
         information in question.  In both of these circumstances, the
         reference count on the FCB has not been bumped up so both accesses
         appear to allow the deletion. This results in a NOTFCBFCB Bugcheck.
    
              Image(s) Affected
    
                -  [SYS$LDR]F11BXQP.EXE
    
      o  Attempt to lock volume for REBUILDing meta-data on volume fails
    
         If a process attempts to mount a Bound Volume Set (BVS) and all the
         members of the BVS are not present, an attempt to lock the volume
         for REBUILDing the meta-data on the volume will fail, but the
         blocking lock (F11B$b) is left with the process.
    
              Image(s) Affected
    
                -  [SYS$LDR]F11BXQP.EXE
    
      o  XQPERR bugcheck in LOCKERS when retry limit on F11B$x lock reached
    
         An XQPERR Bugcheck occurs in LOCKERS when the retry limit on F11B$x
         lock is reached.  This happens when the owner of the $x lock is
         running at a high process priority and there are a number of
         processes in a clustered system that are also trying to validate
         this lock but at a lower process priority.  The high priority
         process never really gives up the locks long enough to let the low
         process priority processes to continue and either validate or
         release the $v lock.
    
         To avoid this situation, after (every) 256 attempts, the process
         with the most retry iterations is stalled for a short period to
         allow other processes to complete their accesses to the lock.
    
              Image(s) Affected
    
                -  [SYS$LDR]F11BXQP.EXE
    
      o  NOSUCHFILE error.
    
         When a directory with multiple headers, e.g. a large ACL, is deleted
         on one mode in a cluster (Node A), if that directory had previously
         been accessed on another node in the cluster (Node B), the files
         created with the previously deleted headers would show up on Node B
         with a NOSUCHFILE error."
    
              Image(s) Affected:
    
                -  [SYS$LDR]F11BXQP.EXE
    
      o  Fix GETTIM to translate 64 bit time to RSX compatible time
    
         Fix the internal GETTIM function so that it properly formats the 64
         bit internal time to an RSX-11 compatible ASCII string.
    
         RSX date string contain only a 2 character year field (ASCII).  In
         order to accommodate the year 2000, this ASCII encoding will now
         include the value of decades (since 1900) into the string.  This
         means that for the years 1900 through 1999, the date string will
         appear as 00 to 99.  For the years 2000 into the years 39xx, the
         string will show as ':0', ';0', etc.
    
         For years prior to the year 1900, dates are encoded as binary zeros,
         which is interpreted as 'no date'.
    
              Image(s) Affected:
    
                -  [SYS$LDR]F11BXQP.EXE
    
    
    Problems Addressed in VAXF11X04_071:
    
      o  A reserved operand fault bugcheck occurs on a $QIO exit.
    
         During the mounting of the system disk, the error message that
         the disk is mounted with a reduced cache is suppressed.  Hence,
         the System Manager may be unaware that the performance of the
         system disk and all others attached to the same cache block is
         questionable.
    
         Image Affected:  [SYSEXE]FILESERV.EXE
    
         Note:  [SYS$STARTUP]VMS$CONFIG-050_CACHE_SERVER.COM also is
                needed to run the FILESERV.EXE image.
    
      o  When deleting a large file (such as a system dump file), a
         UNXSIGNAL Bugcheck may occur.  This particular bugcheck occurs
         because a variable in the code causes a reference to memory
         data that the file system does not own and an internal access
         violation occurs (ACCVIO).
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  On some systems with higher rates of system paging or with
         WSDEC set to a non-standard value, a system can crash with a
         PGFLIPLHI (Page Fault IPL too High) bugcheck.  This problem
         happened when the system returns from a SMP$ACQUIRE call.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  An XQPERR can occur in the RDBLOK module during disk cleanup
         using DCL.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  When storing the value of a directory index buffer, the system
         may crash with a PGFLIPLHI, SSRVEXCPTN error.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  A dismount on a shadowed device results in an unnecessary
         copy.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  If a process is created with a termination mailbox unit
         assigned, the files are not properly audited.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  An XQPERR bugcheck (crash) in the RETURN_CREDITS module can
         occur during DISMOUNT.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  A XQPERR Bugcheck (crash) in XQP can occur during an SET ACL
         (SET FILE/ACL) operation.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  When two processes are competing to dismount a volume, one
         process may be just a bit faster than the other.  This process
         can delete the VCB and other structures before the second
         process has time to finish up its processing.  The result is
         in an UNXSIGNAL/ACCVIO crash.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  A device reporting a read error (SS$_PARITY) during read/write
         processing in the XQP will attempt to record the bad blocks
         and FID in the BADLOG.SYS file.  When the internal close
         operation occurs (on BADLOG), the system XQPERR bugchecks when
         it finds the process's dirty buffers have not been written
         out.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  A UNXSIGNAL/ACCVIO error can occur at module F11BXQP.  This
         problem can occur during mount, when the primary volume is not
         yet mounted.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  Processes can hang (deadlock) when dismounting a device.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  A 'no such file' error can occur on directory extension FCBs.
    
         This problem can occur in at least two ways:
    
           1.  A file appears normal on one node but has an 'no such
               file' error from another node.
    
           2.  BACKUP or DUMP /HEADER encounters a read attributes
               error of NOSUCHFILE.  This error occurs when an attempt
               is made to read a file header, for which the FCB for the
               old header is still in memory.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  Alternate file access checking does not provide the correct
         information for files on ODS-1 disks.  That is, an ODS-1 disk
         access does not process the alternate file access checking
         parameters FIB$L_ALT_ACCESS and FIB$L_STATUS.
    
         Image Affected:  [SYSEXE]F11AACP.EXE
    
      o  The F11A routine ACPCONTROL only understands the control
         function REMAP_FILE.  Hence, for illegal function codes,
         all other control functions return NORMAL, when ILLIOFUNC
         should be returned instead.
    
         Image Affected:  [SYSEXE]F11AACP.EXE
    
      o  Occasional false end-of-file (EOF) errors can occur on a read
         operation.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  The XQP fails after an IO$_DEACCESS call with an SS$_BADPARAM
         error.   One cannot determine whether a file is still open or
         not due to the failed IO$_DEACCESS call.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
      o  Non-privileged users can change the revision date (and count)
         of a file for which they should have only READ access.  For
         example, if a non-privileged user with READ-only file access
         tries to set the file protection, a failure occurs with an
         SS$_NOPRIV error as expected.  However, the revision date
         (and count) are modified.
    
         Image Affected:  [SYS$LDR]F11BXQP.EXE
    
    
    Problems Addressed in VAXF11X03_071:
    
      o  An XQPERR bugcheck error, "all the index buffers are active",
         occurs when running with a reduced cache or during a backup.
    
      o  An XQPERR bugcheck error, "wrong lock basis with FCB present",
         occurs when files with ACLs are created on a full volume.
    
      o  It is possible to serialize on the wrong volume in a volume set.
    
      o  If more than one process queues for a volume's activity
         blocking lock, the XQP can deadlock.
    
      o  The user-mode crasher in VALIDATE_FILE needed to be fixed.
         Specifically, the FIB$C_VALIDATE_FILE ACP control function
         caused a bugcheck if called on a channel which was not
         accessed.
    
      o  Various XQPERR bugchecks occur in directory scanning/shuffling.
    
      o  A crash may occur during creation of a file with a version
         limit of 1 if SYSTEM_CHECK is on or bit 5 or 6 of ACP_DATACHECK
         is 1.  An XQPERR  bugcheck occurs due to a corrupted directory.
    
      o  The NOTIFY_USER for final status of an XQP request occurs too
         early in XQP request completion to report any errors produced
         in cleanup or auditing.  This normally does not cause a problem
         since USER_STATUS is not expected to change during cleanup.
         However, if it does change, then the output of SET WATCH FILE
         is misleading.
    
      o  XQP requests to create a new file with version limits set can
         fail with an SS$_NOSUCHFILE error.
    
      o  Deleting a stale alias on a directory with extension headers
         can bugcheck with an XQPERR "lock index has shifted" error.
         This problem occurs when:
    
              1.  An alias to an existing file is created;
    
              2.  The original file is deleted; and
    
              3.  The original file's file header is reused as an
                  extension header of the alias's parent directory
                  (when ACEs are added to the directory).
    
      o  Prevent access to file headers beyond index file highwater-marking
         (HWM).
    
         It is possible to ACCESS by FID a file header beyond the
         current end of the index file on a freshly-initialized volume.
         Creating a new file accessed in this way can bugcheck the
         system with the XQPERR error.
    
     o   Fix a reserved operand fault bugcheck on $QIO exit.  The
         $QIO failed on return because the IPL was set to zero but
         was entered at IPL 2.
    
      o  The code was in a pageable psect and managed to get paged out.
    
      o  $GET_SECURITY was reading the ORB on a file without any
         synchronization with the file system.  In the best case,
         this problem can lead to bad information being returned.
         In the worst case, if the filesystem was rebuilding the
         ORB's ACL chain at the time, a kernel mode ACCVIO can occur.
    
    
    RELATED ARTICLES:
    
    Detailed articles describing the problems listed above may exist in
    the OPENVMS database.  To view these articles, open the appropriate
    product database and perform a query using either of the following
    search strings: 'VAXF11X04_071' or 'VAXF11X'.
    
    
    ECO KIT ORDERING INSTRUCTIONS:
    
    If after an evaluation you wish to obtain this kit, request it
    electronically using the appropriate Advanced Electronic Services
    (AES) Service Tool.  If you are not familiar with how to request
    kits electronically, open the DIA, WIS or DSNLINK database and
    review the article entitled:
    
         [AES] How To Electronically Request ECO Kits Using Service Tools
    
    
    INSTALLATION NOTES:
    
    The images in this kit will not take effect until the system is
    rebooted.  If there are other nodes in the VMScluster, they must
    also be rebooted in order to make use of the new image(s).
    
    If it is not possible or convenient to reboot the entire cluster at
    this time, a rolling re-boot may be performed.
      
      ==========================================================================
      |                     Table of Kit Image Information                     |
      +----------------------------+----------+-----------------+--------------+
      |                            | Overall  | Image File      | Image Link   |
      | Image Name                 | Checksum | Identification  | Date/Time    |
      +----------------------------+----------+-----------------+--------------+
      | F11AACP.EXE                |%X1F8F3D58| X-2             | 13-OCT-1999  |
      |                                       |                 | 08:00:52.31  |
      +----------------------------+----------+-----------------+--------------+
      | F11BXQP.EXE                |%X755E00D9| XQP V7.1R-0005  | 13-OCT-1999  |
      |                                       |                 | 08:00:56.08  |
      +----------------------------+----------+-----------------+--------------+
      | FILESERV.EXE               |%X3B3C3F80| X-8R1           | 13-OCT-1999  |
      |                                       |                 | 08:01:02.07  |
      +----------------------------+----------+-----------------+--------------+
    
privacy statement using this site means you accept its terms feedback to the webmaster
VMS rules VMS rocks OpenVMS rules OpenVMS rocks