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
OpenVMS VAXODS1_01_071 VAX V7.1 ODS-1 ECO Summary
TITLE: OpenVMS VAXODS1_01_071 VAX V7.1 ODS-1 ECO Summary
 
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) Compaq Computer Corporation 1999.  All rights reserved.

Modification Date:  15-DEC-1999
Modification Type:  Corrected Kit Name

OP/SYS:     OpenVMS VAX

COMPONENT:  ODS1
            BACKUP
            F11BXQP
            F11CACP
            F11AACP
            DUMP
            INIT
            MTAAACP
            VERIFY

SOURCE:     Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXODS1_01_071
     ECO Kits Superseded by This ECO Kit:  None

       The VAXODS1_01_071 does not supersede any other kits.  
       However, it does include problem corrections shipped 
       in the VAXF11X05_071, VAXVER01_071 and VAXMTAA01_071 
       remedial kits.  If you install the VAXODS1_01_071 kit, 
       you do not need to install the VAXF11X05_071, VAXVER01_071 
       and VAXMTAA01_071 remedial kits.

     ECO Kit Approximate Size:  1908 Blocks
     Kit Applies To:  OpenVMS VAX V7.1
     System/Cluster Reboot Necessary:  Yes
     Rolling Re-boot Supported:  Yes
     Installation Rating:  INSTALL_2
                           2 - To be installed on all systems running
                               the listed version(s) of OpenVMS and
                               using the following feature(s):

                                 Users of ODS-1 Format Files

     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
         VAXBACK04_071
         VAXMOUN05_071
         VAXDISM01_071
         VAXMTAA01_071


ECO KIT SUMMARY:

An ECO kit exists for Y2K issues on ODS-1 on OpenVMS VAX V7.1.  This kit
addresses the following problems:

Problems Addressed in this kit:

  o  The 64 bit internal time is not formatted to an RSX-11
     compatible ASCII string.  An RSX date string contains 
     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) in the string.  
     This means that for the years 1900 through 1999, the date
     string will appear as 00 to 99.  For the years 2000 through 
     the years 39xx, the string will show as ':0', ';0' and so 
     forth.

     Images Affected:
       -  [SYSEXE]F11AACP.EXE
       -  [SYSLIB]INIT$SHR.EXE
       -  [SYSEXE]VERIFY.EXE
       -  [SYS$LDR]F11BXQP.EXE
       -  [SYSEXE]MTAAACP.EXE
       -  [SYSEXE]F11CACP.EXE
       -  [SYSEXE]F11DACP.EXE
       -  [SYSEXE]DUMP.EXE
       -  [SYSEXE]BACKUP.EXE
       -  [SYSLIB]BACKUPSHE.EXE
       -  [SYSEXE]STABACKUP.EXE

  o  An INIT/STRUCTURE=1 command returns the following error:

       %INIT-F-ILLBLKNUM, illegal logical block number

     Images Affected:  [SYSLIB]INIT$SHR.EXE

  o  Attempting to mount the second volume of a two-volume RMU
     backup results in %MOUNT-F-MEDOFL and %MOUNT-F-FILACCERR
     errors.

     Images Affected:  [SYSEXE]MTAAACP.EXE

  o  Verify does not flag files which are directly back linked to
     themselves as having invalid backlinks.

     Images Affected:  [SYSEXE]VERIFY.EXE

  o  VERIFY hangs in an infinite loop during its scan of the
     directory structure.

     Images Affected:  [SYSEXE]VERIFY.EXE


Problems Addressed in the VAXF11X05_071 Kit:

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


Problems Addressed in the VAXF11X04_071 Kit:

  o  During the mounting of the system disk, the error message that
     the disk is mounted with a reduced cache is suppressed.  Thus,
     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  An 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  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 the VAXF11X03_071 Kit:

  o  A XQPERR bugcheck error "all the index buffers are active"
     occurs typically when running with a reduced cache or during a
     BACKUP.

  o  An XQPERR bugcheck error, 'wrong lock basis with FCB present',
     occurred when creating files with ACLs on a full volume.

  o  One can 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  When a file with a version limit of 1 is created and 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 problem is normally all right,
     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 XQPERR "Lock index has shifted".  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).

     One can possibly 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 filesystem.  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.

     *** Note:  In order to get this fix, you must install the
                VAXSYSA02_071 kit.

Problems Addressed in the VAXINIT01_071 Kit:

  o  A possible system crash occurs during Host Based RAID Unbinds          
     with MME code enabled.  A mailbox read synchronization problem         
     causes the crash.                                                      
  
     This problem only occurs when a host-based RAID UNBIND command         
     is done while an MME-based application is running.                     
                                                                            
     This problem can occur in several different code areas of the          
     operating  system.  In order to eliminate all known instances          
     of this problem, the following remedial kits (or their                 
     supersedants) will also need to be installed:                          
  
       VAXSYSA02_071                                                        
       VAXBACK03_071                                                        
       VAXMOUN04_071                                                        
       VAXDISM01_071                                                        
       VAXMTAA01_071                                                        

     Images Affected:  [SYSEXE]INIT$SHR.EXE
                                                                              
  o  A process using MME could potentially "miss" the VOL1 label on           
     a tape.  Also, a process could "hang" trying to send a message           
     to the MME process.                                                      
  

Problems Addressed in the VAXVERI01_071 Kit for OpenVMS VAX V6.1, V6.2,       
V6.2-0HF, V7.0, V7.1:                                                                   
                                                                              
  o  ANALYZE/DISK goes into an infinite loop.                                 
                                                                              
     VERIFY has incorrectly 'fixed' the backlink of a lost directory to       
     point to itself.  The next time VERIFY is run, it encounters the         
     lost directory and goes into a tight loop following the directory's      
     backlink.

     Images Affected:  [SYSEXE]VERIFY.EXE

Problems Addressed in the VAXMTAA01_071 Kit:

  o   A possible system crash occurs during Host Based RAID Unbinds         
      with MME code enabled.  A mailbox read synchronization problem         
      causes the crash.                                                       
                                                                              
      This problem only occurs when a host-based RAID UNBIND command         
      is done while an MME-based application is running.                      
                                                                              
      This problem may occur in several different code areas of the         
      operating system.  In order to get eliminate all known         
      instances of this problem, the following remedial kits (or         
      their supersedants) will also need to be installed:                     
                                                                              
        VAXSYSA02_071                                                           
        VAXBACK03_071                                                           
        VAXDISM01_071                                                           
        VAXINIT01_071                                                           
        VAXMOUN04_071                                                           
                                                                              
   o  A process using MME could potentially "miss" the VOL1 label  on         
      a  tape.  Also, a process could "hang" trying to send a message         
      to the MME process.                                                     


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.


Files on this server are as follows:
»vaxods1_01_071.README
»vaxods1_01_071.CHKSUM
»vaxods1_01_071.CVRLET_TXT
»vaxods1_01_071.a-dcx_vaxexe
»vaxods1_01_071.CVRLET_TXT
privacy statement using this site means you accept its terms