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

TITLE: OpenVMS VAXRMS04_062 VAX 6.2 RMS/CONVERT ECO Summary

New Kit Date : 07-FEB-2001
Modification Date: Not Applicable
Modification Type: Updated Kit Supersedes VAXRMS03_062
 
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 2001. All rights reserved.

OP/SYS: DIGITAL OpenVMS VAX

COMPONENT: RMS - RMS.EXE
            CONVERT CONVSHR.EXE
                       CONVERT.EXE
                       RECLAIM.EXE

SOURCE: Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name: VAXRMS04_062
     ECO Kits Superseded by This ECO Kit: VAXRMS03_062
                                           VAXRMS02_062
                                           VAXRMS01_062
     ECO Kit Approximate Size: 810 Blocks
     Kit Applies To: OpenVMS VAX V6.2
     System/Cluster Reboot Necessary: Yes
     Rolling Reboot 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:

         None

       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 RMS/CONVERT on OpenVMS VAX V6.2. This kit
addresses the following problems:

PROBLEMS ADDRESSED IN VAXRMS04_062 KIT:

  o Mark the Buffer Descriptor as busy for asynch multistreamed
     block IO autoextends.

     Performing multistreamed asynchronous Block IO to a sequential
     file could result in random data corruption and/or sporadic
     SS$_BADPARAM errors if an autoextend occurs.

  o Fix to prevent an inconsistent primary index structure.

     This problem is characterized by an ANALYZE/RMS_FILE of an
     indexed file reporting the following error: "Index bucket
     references missing data bucket with VBN nnn"

     When the index bucket is examined, the problem is determined
     to be that the primary index structure has duplicate index
     entries. There should never be duplicate entries in the index
     structure.

     Any file that has a prevalence of deleted records as the last
     records in a data bucket that is subsequently a candidate for
     a bucket split could potentially encounter this problem.

     A convert of the file will rebuild the primary index structure
     and leave the file in a consistent state.

     This problem is fixed in OpenVMS VAX V7.2.

  o Fix to prevent the creation of a corrupt file structure with
     repeated calls to the CONVERT callable interface.

     Under rare circumstances, repeated calls to the CONVERT
     callable interface from within an application can produce a
     file with a corrupted file structure. The conditions that
     must exist for this to occur are as follows:

      + The previous file processed must have allowed duplicates
         on the last key

      + The last data bucket of the file must be part of a
         duplicate chain.

  o Fix convert/reclaim of RU_DELETED records.

     A CONVERT/RECLAIM of a fixed record length file with no
     compression enabled that has been used with RU journaling may
     inappropriately reclaim buckets containing valid user records.
     This results in data loss.

     This problem is fixed in OpenVMS VAX V7.2.

  o Prevent RMS pool corruption when accessing bad .DIR file

     Access to a corrupted directory could result in the user's
     process being deleted from the system through an EXEC mode
     exception (a system bugcheck would occur if the SYSGEN
     parameter BUGCHECKFATAL were set).

  o Fix IORNDN non-fatal bugchecks caused by busy RMS stream.

     Processes may disappear with RMS IORNDN non-fatal bugchecks
     when an EXIT is requested by an Executive-mode subsystem (such
     as ACMS). This is a very small timing window, so processes
     with a large number of files increases the probability of the
     problem occurring.

Problems addressed in the VAXRMS03_062 ECO kit:

  o A fix was done for explicit $extend to a relative file.

     The last data record(s) added at the end of a relative file
     may be lost (overwritten) after an "explicit" call to the RMS
     $EXTEND service for a relative file that is being shared by
     two or more concurrent writers. This problem is restricted to
     an explicit $EXTEND; autoextends done transparently by RMS for
     a relative file work correctly.

     NOTE: Until this remedial kit can be installed, this problem
     can be prevented by not doing any explicit $EXTEND for a
     shared write relative file. Let the autoextend feature of RMS
     take care of any extends needed. See "Relative File Extend
     Size" section in chapter 3 (Performance Considerations) of the
     Guide to OpenVMS File Applications for a description of how
     RMS derives the value it uses for its autoextend feature.

  o A fix was done for appender lock timing window hang for shared
     write, RU journaled sequential file.

     This hang requires all of the following conditions: a shared
     write sequential file, multi record streaming enabled, RU
     journaling enabled on the file, and heavy write contention
     among sharers at the end-of-file. It has only been reported
     by one site, and even then there was a lapse of over one year
     between two occurrences.

  o It is possible for an indexed file with more than one
     secondary key allowing no duplicates to show an inconsistent
     total number of data records as being accessible via two or
     more of the secondary keys. In order for this problem to
     occur, the file must have RU journaling enabled. As part of
     an RU transaction, a secondary data record must be deleted in
     one of the nonduplicate secondary keys (will be marked
     RU-DELETED) and then an attempt must be made to add a
     duplicate key value to another nonduplicate secondary key as
     part of a $PUT operation, which results in a duplicate (DUP)
     error.

     As part of the recovery triggered by the DUP error, the
     secondary key value marked as RU-DELETED will not be
     recovered. This will leave the file with an inconsistent
     secondary key. However, the primary key contents will be
     intact and correct, and a convert of the file will rebuild the
     secondary indexes and leave the file in a consistent state.

  o A XABITM stored semantics attribute fix was done for the SMFS
     (Sequential Media File System) device.

     Stored semantics is a file attribute used to indicate that a
     file contains compound documents (i.e., contains a number of
     integrated components including text, graphics, and scanned
     images). Support for setting this file attribute is provided
     through RMS using an item list XAB (XABITM) user interface.

     In specifying the item list for setting this attribute
     (XAB$_STORED_SEMANTICS), a user may request a return length
     (the length of the stored semantics ACE added by the file
     system to the file). RMS, without the fix. returns a length
     of zero if the file is on a SMFS device, despite the fact that
     the stored semantics attribute was successfully added to the
     file.

  o A fix was done to dynamically reflect file protection changes
     cluster wide for files that are INSTALLED with the /OPEN
     qualifier.

     Changes to the security profile of a file that was installed
     with the /OPEN qualifier were not reflected cluster wide until
     an INSTALL/REPLACE was performed on each node. With this
     correction, the protection information is dynamically
     propagated.

  o A fix was done to properly handle a special bucket split case
     to prevent an exec-mode ACCVIO occurring during a bucket
     split.

     This problem is restricted to a file with KEY compression
     enabled containing a secondary key allowing duplicates with a
     nearly full SIDR data bucket. An ACCVIO (access violation)
     may occur during a bucket split operation if both the last
     valid record in the bucket contains a long list of duplicates
     and starts before the calculated split point and the memory
     page adjacent to the page mapping the current buffer is not
     valid.

     If the SYSGEN parameter BUGCHECKFATAL is not enabled, then the
     process will be terminated; if it is enabled, then the system
     will crash with a SSRVEXCEPT ACCVIO. The file will not be
     left corrupted. A temporary workaround, if this problem ever
     occurs on a file, would be to convert the file using a revised
     FDL, in which key compression is disabled until the remedial
     kit is applied.

  o A fix was done to correct a unique situation where the delete
     of a record in a file with key compression enabled could
     possibly cause the resulting key expansion to overflow the
     current bucket.

     This problem is restricted to a file with key compression
     enabled. A nonfatal RMS bugcheck (R2 value FFFFFFD4 (Internal
     ISAM Error)) could occur during a record delete operation on a
     prologue 3 file. The ISAM error would be returned when the
     deletion of a record caused the expansion of the compressed
     key value of the next record in the bucket to exceed the
     available space in the data bucket.

     This would occur if the primary data bucket containing the key
     was nearly full and the record that followed the record being
     deleted was compressed to the extent that only one physical
     byte of the key was stored in the data record.

     The file will not be left corrupted. A temporary workaround,
     if this problem ever occurs on a file, would be to convert the
     file using a revised FDL in which key compression is disabled
     until the remedial kit is applied.

  o A fix was done to prevent process hangs when RMS rundown is
     invoked from within an EXEC-mode AST.

     If RMS rundown is invoked from within an EXEC-mode AST, the
     process will hang indefinitely waiting on the delivery of
     pending ASTs. As documented in Section 2.5 of the RMS
     Reference Manual, RMS services should not be called from
     within an EXEC-mode AST. If however, an EXEC-mode AST routine
     fails due to an unhandled condition, RMS rundown will be
     indirectly invoked by the image exit (resulting in a process
     hang).

     The rundown routine has been modified to abort RMS rundown
     with an RMS$_BUSY return status if it has been invoked from
     within an EXEC-mode AST.

  o A fix was done to prevent a nonfatal RMS bugcheck (ENQDEQFAIL)
     when a timeout on a lock request coincides with a system
     detected SS$_DEADLOCK condition for the same resource.

     If an RMS $GET is performed with the WAT and TMO options
     specified (wait for lock and timeout request after specified
     number of seconds) in the RAB$L_ROP (record options) field, it
     is possible for a nonfatal RMS bugcheck (ENQDEQFAIL;
     R2=FFFFFFF4) to be signaled when the timeout occurs. This can
     happen if an SS$_DEADLOCK condition is detected by the system
     (which cancels the lock request), but the timeout AST routine
     is triggered before RMS receives the AST notification that the
     request has been canceled.

  o A fix was done so that a RMS-F-FTM (network DAP file transfer
     mode does not permit operation) error is not returned
     inappropriately for a remote $FIND operation when the
     sequential-only (SQO) option is set in the FAB$L_FOP (file
     options) field and the access method used is sequential.

     When the SQO option is set, this error is only appropriate if
     either the keyed or record-file-address (RFA) access method is
     specified. The sequential access method should be allowed.

     This problem is fixed in the OpenVMS VAX V7.1 release.

  o A fix was done for an EXCHANGE/NETWORK user-mode access
     violation (accvio).

     This problem only occurs when the convert transfer_mode
     (/TRANSFER_MODE=CONVERT) option is used with a file that
     exceeds 255 blocks in size.

  o A %CONV-F-READERR converting undefined file format to fixed
     occurred.

     Converting a sequential file with an UNDEFINED record format
     to a FIXED record format aborts with following errors:

       %CONV-F-READERR, error reading <input filespec>
       -RMS-F-UBF, invalid user buffer

Problems addressed in the VAXRMS02_062 ECO kit:

NOTE: According to OpenVMS Engineering, the following fixes are
       included in the official OpenVMS VAX V7.1 software release.

  o This kit contains a fix for the compressed primary key problem
     that occurs in the context of record deletes being done using
     sequential access rather than keyed access.

     While sequentially walking through (accessing) the primary data
     records in an indexed file (a primary key is a string key with
     key compression enabled), a delete is done of one of the
     records. The following error may be returned when an attempt
     is made to sequentially access the next record:

        RMS-F-BUG, fatal RMS condition, process deleted.

     The file is not left corrupted. A convert of the file will
     leave the file in a consistent state.

     This problem is fixed in OpenVMS VAX V7.1.

  o For a file lock to be released, a process is delivered a blocking
     AST. Before the file lock is released, it has to release the
     lock it holds on the EOF buffer. A NOTLOCKED bugcheck is
     returned if the process is holding a PW (protected write) rather
     than an EX (exclusive) lock on the EOF buffer. A new routine
     in OpenVMS VAX V6.1 did not check for either EX or PW as it
     should have.

     This problem is fixed in OpenVMS VAX V7.1.

  o A loop may occur at the EXEC-MODE AST level during the deletion
     of network logical links. The process that loops cannot be
     deleted and will be an application that does network operations.

     RMS maintains a process cache of recent logical links for a
     period of time in an attempt to reuse them and save on image
     and process activations. When a link becomes inactive and is
     added to the cache, RMS deletes any links in surplus of three.
     In walking the link cache queue to delete these links, there
     is a potential race condition that could result in a stale
     pointer being used after a stall, which leads to the loop.

     This problem is fixed in OpenVMS VAX V7.1.

  o This kit contains an autoextend fix for a shared block I/O
     write which requires the use of the UPI option which disables
     any locking (file or EOF bucket).

     For this particular case with no locking synchronization,
     it is possible if two or more processes or two or more
     asynchronous streams are writing to a file, that two or more
     autoextends may occur concurrently. Though the file system
     will do the extends synchronously, the processing of the
     extend result may complete out of sequence and result in the
     FTL$_BADEBKHBK (R2=FFFFFFDC) RMS bugcheck.

     This problem is fixed in OpenVMS VAX V7.1.

  o The client/server may hang in detached RU recovery server.
     Given the right series of coincidences, both a client RMS
     process and the detached RU recovery server process can
     hang when the client accesses a file on which there is an open
     RU transaction. This is a VAX-specific problem.

     This problem is fixed in OpenVMS VAX V7.1.

  o An SDA-W-FAOERR error may occur when RMS FWA (File Work Area)
     is displayed. The contents of a buffer (LOGNAM) are being
     displayed after the space has been returned and reallocated
     for some other use.

     This problem is fixed in OpenVMS VAX V7.1.

  o The outlier area is not detected on an indexed file open. The
     RMS-F-AID error (invalid area ID) is not reported on the open
     of an indexed file with an XABALL declaration that has an area
     ID that is exactly one greater than the maximum number of areas
     in that indexed file. A check has been added for record I/O
     access. Block I/O access is excluded from this check.

     This problem is fixed in OpenVMS VAX V7.1.

Problems addressed in the VAXRMS01_062 ECO kit:

  o The last chance handler needs to be more robust when a process
     that has a file opened with global buffers enabled is terminated
     with a STOP/ID. STOP/ID invokes the RMS abort last chance handler
     (RM$LAST_CHANCE). Problems addressed include:

     + A potential deadlock in the RMS last-chance handler if the
        same file is open more than once within a process or
        subprocess and it has global buffers set on it.

     + A potential fatal KRNLSTAKNV system crash due to nonfatal
        RMS bugchecks from failing $GETLKI calls which cause error
        rundown recursion until the stack fills up.

  o An ISAM RMS nonfatal bugcheck is returned by RM$EXPAND_KEY
     (module RM3PCKUNP). This bugcheck is forced if key expansion
     for the deletion of a secondary index data record (SIDR)
     overflows an SIDR data bucket.

     The current problem occurs in the context of an $UPDATE that
     changes a secondary key value (with key compression enabled)
     if both the SIDR data bucket freespace is exactly equal to the
     bucket size minus one and the key expansion of the next SIDR
     record (if any) results in a gain in bytes exactly equal to the
     number of bytes to be deleted. For both conditions to be
     satisfied makes the probability of this problem's occurrence
     rare.

     The update to the primary record will have been completed. The
     problem occurs during the delete operation to remove the old
     secondary key value after the new updated secondary key value
     has been added. The file is not left corrupted. A convert of
     the file will rebuild the secondary indices and leave the file
     in a consistent state.

     This problem is fixed in OpenVMS VAX V7.0.

  o An SIDR (secondary index data record) compressed key
     expansion problem could result in a corrupted SIDR bucket.
     The conditions that are required make the probability of its
     occurrence rare.

     For this problem to occur requires

       + The presence of many duplicate records for a secondary key;
       + A secondary key of a string type that is 9 bytes or more in
         length; and
       + A very particular key pattern which results in a number of
         bytes at the front of the key being compressed.

     The problem occurs in the context of a bucket split when the
     current design moves an entire SIDR array into a new bucket.
     It is possible that when the compressed secondary key for that
     SIDR array is expanded in its position as the first record in the
     new bucket, it may grow larger than the bucket.

     Since the problem is with a secondary key bucket, a convert
     will recover all the data records in the corrupted file.

     This problem is fixed in OpenVMS VAX V7.0.

  o In some cases, incomplete security success audit information
     is generated upon image activation of installed /OPEN images.

  o A Known File Entry (KFE) file open SSRVEXCEPT (Unexpected
     system service exception) may occur due to an ACCVIO in
     RM$KNOWNFILE (RMS0OPEN).

     Heavy concurrent INSTALL and F$FILE_ATTRIBUTE usage may cause
     locking conflicts accessing the KFE list, which can result in a
     bad KFE pointer being handed to RMS leading to ACCVIO.

     This problem is fixed in OpenVMS VAX V7.0.

  o The Statistics setting on a file may be lost from the FDL
     produced by ANALYZE/RMS/FDL. File monitoring is always set
     to 'no' whether it is enabled or not. The problem is not
     with ANALYZE[/RMS], but with RMS's processing of an XABITM list.

  o The following error will be reported in converting a VFC-format
     file to a fixed-format file using the /PAD qualifier:

     %LIB-F-BADBLOADR, bad block address

     The problem is restricted to a convert job that involves an
     input file with a VFC record format that is being converted to
     an output file with a fixed record format using the /PAD
     qualifier.

     This problem was introduced in OpenVMS V6.1 and is fixed in
     OpenVMS V7.0.

INSTALLATION NOTES:

This kit requires a system reboot. Compaq strongly recommends that
a reboot is performed immediately after kit installation to avoid
system instability

If you have other nodes in your OpenVMS cluster, 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.

---

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