OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: system PRIVILEGED account (rootnfsserver.support.compaq.com)
Date: Fri Aug 03 2001 - 02:31:15 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    *******************************************************************************
    * *
    * This is an update to an existing patch... *
    * *
    * Online links can be found at *
    * http://ftp.support.compaq.com/patches/public/vms/vax/v7.2/vaxf11x03_072.README
    *******************************************************************************

    TITLE: OpenVMS VAXF11X03_072 VAX V7.2 F11AACP/F11BXQP ECO Summary

    New Kit Date : 1-AUG-2001
    Modification Date: Not Applicable
    Modification Type: Updated Kit Supersedes VAXF11X02_072
     
    NOTE: An OpenVMS saveset or PCSI installation file is stored
           on the Internet in a self-expanding compressed file.
     
           For OpenVMS savesets, the name of the compressed saveset
           file will be kit_name.a-dcx_vaxexe for OpenVMS VAX or
           kit_name.a-dcx_axpexe for OpenVMS Alpha. Once the OpenVMS
           saveset is copied to your system, expand the compressed
           saveset by typing RUN kitname.dcx_vaxexe or kitname.dcx_alpexe.
     
           For PCSI files, once the PCSI file is copied to your system,
           rename the PCSI file to kitname-dcx_axpexe.pcsi, then it can
           be expanded by typing RUN kitname-dcx_axpexe.pcsi. The resultant
           file will be the PCSI installation file which can be used to install
           the ECO.
     

     
     
    Copyright (c) Compaq Computer Corporation 1998, 2001. All rights reserved.

    OP/SYS: OpenVMS VAX

    COMPONENTS: F11BXQP
                F11AACCP

    SOURCE: Compaq Computer Corporation

    ECO INFORMATION:

         ECO Kit Name: VAXF11X03_072
         ECO Kits Superseded by This ECO Kit: VAXF11X02_072
         ECO Kit Approximate Size: 414 Blocks
         Kit Applies To: OpenVMS VAX V7.2
         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:

             VAXUPDATE01_072
             VAXODS1_01_072
            
           NOTE: The VAXODS1_01_072 kit dependency applies only
                 if the user has OPS-1 drives.

           In order to receive all the corrections listed in this
           kit, the following remedial kits should also be installed:

             None

    ECO KIT SUMMARY:

    An ECO kit exists for F11AACP and F11BXQP on OpenVMS VAX V7.2. This kit
    addresses the following problems:

    PROBLEMS ADDRESSED IN VAXF11X03_072 KIT:

      o The XQP bugchecks with XQPERR in routine MAKE_DIRINDX in
         module RDBLOK, 'All the index buffers are active'. There is
         DFO IO$M_MOVEFILE activity on the node at the time of the
         crash.

         Crashdump Summary Information:
         ------------------------------
         Bugcheck Type: XQPERR, Error detected by file system XQP
         Current Process: BATCH_1170
         Current Image: $2$DUA0:[SYS8.SYSCOMMON.]
                            [SYSEXE]PSPA$ADVISOR.EXE;14
         Failing PC: FFFFFFFF.8017DCDC MAKE_DIRINDX_C+0032C
         Failing PS: 30000000.00000000
         Module: F11BXQP (Link Date/Time:
                            18-JUL-2000 13:27:34.38)
         Offset: 00001CDC

            Images Affected: [SYS$LDR]F11BXQP.EXE

      o During the DISMOUNT of a bound volume set, the XQP signals an
         XQPERR bugcheck in CHECK_DISMOUNT after a $DEQ against
         RVT$L_STRUCLKID fails with "Cannot dequeue a lock with
         sublocks".

            Images Affected: [SYS$LDR]F11BXQP.EXE

      o The XQP for trusted processes/threads is supposed to suppress
         the audit messages that may emanate from their actions. These
         audit messages are not being suppressed.

            Images Affected: [SYS$LDR]F11BXQP.EXE

    Problems Addressed in VAXF11X21_072:

      o A BADATTRIB error can occur from BACKUP and other applications
         that use ATR$C_ASCNAME.

           Images Affected:
             - [SYSEXE]F11AACP.EXE
             - [SYSEXE]F11AACP.STB

      o An XQPERR bugcheck can occur when the volume allocation lock
         becomes invalid and the process is extending/re-validating the
         INDEXF.SYS file.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o An exception, which leads to an INVEXCEPTN bugcheck, can occur
         in XQP routine INS_LIMBO or TRIM_LIMBO.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o The XQP bugchecks in routine MARK_INCOMPLETE with NOTWCBWCB, a
         corrupted WCB list. Other bugchecks could occur, depending
         upon when the WCB queue corruption is detected.

           Images Affected: [SYSEXE]F11BXQP.EXE

      o MOUNT routine START_ACP bugchecks with NOTUCBRVT.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o If a directory command is executed for a directory file that
         is greater than 127 blocks, the UCB$x_QLEN counter gets
         incremented, but may not get decremented.

           If an I/O past the highwater mark is started exactly at
           %x7FFFFF blocks from the file size, a false SS$_ENDOFFILE
           would be reported.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o A process hangs and may not be deleteable when writing to a
         sequential file. The process may have a "lost" I/O
         outstanding. In such cases, the I/O may be on the FCB (file
         control block) HWM (high water mark) wait queue waiting for
         other I/Os.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o Separator pages for print jobs, which are created via COPY to
         a spooled device, do not include the complete file specification.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o The XQP bugchecks with an XQPERR in routine RES_SEQ_MISMATCH,
         'Found a stale referenced or non directory FCB (file control
         block) in FCB queue'.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o The XQP bugchecks with an XQPERR in routine MAKE_DEACCESS,
         'deaccess conversion failed'.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

      o An XQPERR bugcheck occurs in UPDATE_INDX of multi-header
         directories.

           Images Affected:
             - [SYS$LDR]F11BXQP.EXE
             - [SYS$LDR]F11BXQP.STB

      o A paged pool may become overused or exhausted when many
         shuffles occur on a directory with multiple headers. This is
         due to an occurrence of a large ACL (access control list)
         chain.

           Images Affected:
             - [SYSEXE]F11BXQP.EXE
             - [SYSEXE]F11BXQP.STB

    Problems Addressed in VAXF11X01_072:

      o A 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.

         Images Affected: [SYS$LDR]F11BXQP.EXE

      o 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. However, the blocking lock (F11B$b) is left
         with the process.
                                                                                  
         Image(s) Affected: [SYS$LDR]F11BXQP.EXE
                                                                                  
      o An XQPERR bugcheck in LOCKERS can occur when the retry
         limit on the 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 After releasing the current process' IPL/Fork lock, a system
         can crash with a SPLACQERR bugcheck
                                                                                  
         Image(s) Affected: [SYS$LDR]F11BXQP.EXE
                                                                                  
      o When writing a large number of log files in rapid succession
         to a very large directory, the directory file becomes "corrupt"
         and DUMP/DIRECTORY displays a block similar to the following:
      
           Virtual block number 3574 (00000DF6), 512 (0200) bytes
           0000 Directory Entry:
           0000 Size: 508
                                                                                  
             0002 Version limit: 32767
             0004 Type: 0 (FID)
             0005 Name count: 24
             0006 Name: COSLR1201_01_JUPICC2.LIS
             001E Version: 7859 FID: (40993,5,0)
             0026 Version: 7858 FID: (40990,1,0)
             002E Version: 7857 FID: (40988,3,0)
             ...
             01E6 Version: 7802 FID: (40455,1,0)
             01EE Version: 7801 FID: (40454,1,0)
             01F6 Version: 32767 FID: (16744447,65535,0)
             01FE End of records (-1)
                                                                                  
         Image(s) Affected: [SYS$LDR]F11BXQP.EXE
                                                                                  
      o Exhaustion of non-paged pool with FCBs and CFCBs as the
         primary data structures. The output from a SHOW
         MEMORY/CACHE/FULL command may put odd values in the files
         retained field:

           $ SHOW MEMORY /CACHE/FULL

             System Memory Resources on 18-NOV-1999 14:13:52.13
             Virtual I/O Cache
             Total Size (pages) 2098 Read IO Count 13359
             Free Pages 0 Read Hit Count 6130
             Pages in Use 2098 Read Hit Rate 45%

             Maximum Size (SPTEs) 3140177 Write IO Count 16874
             Files Retained ****** IO Bypassing the Cache 536

           Non-paged pool exhaustion starts when a file create or access
           causes the file to become part of the VCC cache and be held on
           the XQP limbo queue. A short time later, if this file is
           renamed and as part of that rename operation the file is
           removed from the limbo queue, the accounting for that file
           is not correct. If the file is later deleted, the count
           of the limbo items goes down incorrectly and eventually goes
           negative. This then allows the limbo list to grow very large.

           This can be seen using SDA where the value of EXE$GL_LIMBOLEN
           does not match the number of queue elements in EXE$GQ_LIMBOQ.

           For example:

             SDA> EX EXE$GL_LIMBOLEN
             EXE$GL_LIMBOLEN: 00000061 "a..."
             SDA> VALIDATE QUEUE EXE$GQ_LIMBOQ
             Queue is complete, total of 195 elements in the queue
             SDA> EVAL 61
             Hex = 00000061 Decimal = 97
             SDA>

           Images Affected: [SYS$LDR]F11BXQP.EXE

      o Under the following circumstances:
                                                                                  
           1. A directory with multiple headers (from a large ACL for
               example) is deleted on one node (A) in a cluster and
                                                                                  

           2. the directory had been previously accessed on another node
               (B) in the cluster
                                                                                  
         The files created with the previously deleted headers in step
         1 would show up on node B with the error:
                                                                                  
           %SYSTEM-F-NOSUCHFILE, no such file
                                                                                  
         Image(s) Affected: [SYS$LDR]F11BXQP.EXE

      o 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
           - [SYSEXE]F11AACP.EXE

    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.

    All trademarks are the property of their respective owners.

    ---