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 ALPRMS04_071 Alpha V7.1 RMS ECO Summary
TITLE: OpenVMS ALPRMS04_071 Alpha V7.1 RMS ECO Summary
 
Modification Date:  18-OCT-1999
Modification Type:  Updated Kit:  Supersedes ALPRMS03_071

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 1997, 1999.  All rights reserved.

PRODUCT:    OpenVMS Alpha

COMPONENT:  RMS.EXE - Record Management Services

SOURCE:     Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name:  ALPRMS04_071
     ECO Kits Superseded by This ECO Kit:  ALPRMS03_071
                                           ALPRMS02_071
                                           ALPRMS01_071
     ECO Kit Approximate Size:  3456 Blocks
     Kit Applies To:  OpenVMS Alpha V7.1, 7.1-1H1, 7.1-1H2
     System/Cluster Reboot Necessary:  Yes

     Installation Rating:  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 on OpenVMS Alpha V7.1 through V7.1-1H2.

Problems addressed in ALPRMS04_071:

  o  RMS directory cache limits have been removed.  Prior to this 
     enhancement, the maximum size of a directory file that RMS 
     would cache was 127 blocks; wildcard lookups to larger 
     directories would go directly to the file system.

     With this enhancement, RMS attempts to cache directories of
     any  size.  If memory or other resources are not available to
     cache the directory file, wildcard lookups are then directed
     to the file system.

     This RMS enhancement improves the performance of wildcard
     searches.   It does not improve the performance of directory
     inserts or deletes; management of the latter is done directly
     by the file system.

     This enhancement is included in OpenVMS Alpha V7.2.

  o  The directory overhead associated with journal file creation 
     and deletion has been reduced.

     Prior to Version 7.2, recovery unit (RU) journals were created
     temporarily in the [SYSJNL] directory on the same volume as
     the file that was being journaled.  The file name for the
     recovery unit journal had the form RMS$process_id (where
     process_id is the hexadecimal representation of the process
     ID) and a file type of RMS$JOURNAL.

     The following changes are being introduced to RU journal file
     creation in this remedial release of OpenVMS Version 7.1:

       +  The files are created in node-specific sub-directories 
          of the [SYSJNL] directory.

       +  The file name for the recovery unit journal has been
          shortened to the form: YYYYYYYY, where YYYYYYYY is the
          hexadecimal representation of the process ID in reverse
          order.

     The following example shows both the previous and current
     versions of journal file creation:

       Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
       Current version:   [SYSJNL.NODE1]CB300412.;1

     If RMS does not find either the [SYSJNL] directory or the
     node-specific directory, RMS creates them automatically.

     This enhancement is included in OpenVMS Alpha V7.2.

  o  A SYS$FILESCAN fatal (SYSTEM-F-ACCVIO) error is possible.

     For this problem to occur the mandatory first argument in the
     call to SYS$FILESCAN must contain a descriptor with both a
     zero length and a zero pointer to the string to be searched
     for the file specification.  In other words, no file
     specification is being passed.  The caller is doing a no-op
     call to $FILESCAN without allocating a valid buffer for its
     null request.  RMS returns a fatal (SYSTEM-F-ACCVIO) error to
     the caller as a result of a probe, but the process is not
     terminated.

     The fix will result in a success status being returned for a
     zero length (null) request.

     This problem is fixed in OpenVMS Alpha V7.2.

  o  An ANALYZE/RMS_FILE of the indexed file reports the following
     error:   

       "Index bucket references missing data bucket with VBN nnn"

     The problem is that the primary index structure has duplicate
     index value entries and there should never be duplicates in
     the index structure.  Any application that has a prevalence of
     deleted records as the last record 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 Alpha V7.2.

  o  In the case of a Prolog 1 or 2 indexed file with fixed length
     records, it is possible that an update may result in a
     duplicate record being added to a noduplicate primary key.

     This problem will never occur with a Prolog 3 indexed file.
     Prolog 3 has  been the recommended indexed file format since
     VAX/VMS V4.0. The possibility of this problem occurring can
     be avoided by converting any remaining Prolog 1 or 2 indexed
     files.  This conversion is totally transparent to applications.

     This problem is fixed in OpenVMS Alpha V7.2.

  o  Under rare conditions, if a CONVERT/RECLAIM is performed on 
     a file with a non-compressed, fixed length record format, with
     RU journaling enabled, inappropriate data buckets may be
     erroneously reclaimed.

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


Problems addressed in ALPRMS03_071:

  o  Performance enhancements to Global Buffer processing.

     RMS  has  implemented  a  new  algorithm  for  global   buffer
     management   that   dramatically  improves  scalability.   The
     performance associated with the previous algorithm effectively
     limited  the maximum number of global buffers on large, shared
     files.  With this change, customers may increase the number of
     global  buffers  on these files to the full limit of 32,767 to
     fully exploit large memory systems.

     Access to the global section used for RMS  global  buffers  is
     now   mainly  synchronized  using  inline  atomic  instruction
     sequences  rather  than  distributive  locking.   This  change
     allows  more concurrent access to the section (particularly on
     SMP machines).

     Note that increasing the number of global buffers on  specific
     files  may  require  some  system resources to be increased in
     size.   In  particular,  the   SYSGEN   parameters   GBLPAGES,
     GBLPAGFIL  or  GBLSECTIONS  may  need  to  be  increased.  In
     addition, process working set size and  page  file  quota  may
     need to be increased.

     This enhancement is included in the next release after OpenVMS
     Alpha V7.1.

  o  Enhancement to  add  128-bit  UTC  support  for  FAL/RMS  time
     transfers.

     RMS and FAL have been enhanced to support time transfers using
     128-bit UTC format.  Currently, RMS and FAL exchange date-time
     file attributes using an 18-byte ASCII string which includes a
     2-digit year.  Since the date is pivoted at 1970 (YY's from 70
     to 99 map to 1970 through 1999 and YY's from 00 to 69  map  to
     2000  through  2069),  OpenVMS  RMS  is Year 2000 compliant in
     regards to file access using DECNET FAL.

     The DAP specification provides for using a 128-bit UTC  binary
     date  as an alternative to the ASCII format.  This enhancement
     allows non-VMS operating  systems  to  access  file  dates  on
     OpenVMS in a completely Year 2000 compliant manner.

     This enhancement is included in the next release after OpenVMS
     Alpha V7.1.

  o  Fix to $READ for invalid transfer size and status returned for
     last transfer preceding end-of-file

     This problem is restricted to an application  using  the  user
     RAB64  structure  for  a  $READ (block I/O) with a buffer size
     greater than 65535 bytes.  If the last transfer just preceding
     the  end-of-file  exceeds  65535 bytes, then the transfer size
     returned  in  the  RAB64  (RAB64$L_RSZ)  is  invalid  and   an
     RMS-E-EOF  status is returned.  The correct transfer size will
     now be returned with the appropriate status of RMS-S-NORMAL.

     This problem was introduced in Alpha  V7.0  when  the  maximum
     transfer  size  was  increased  from  65535 bytes to 2**31 - 1
     bytes.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Temporarily  modify  application  to  restrict  block  I/O
            ($READ) transfer size to 127 blocks.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Following  the  change  in  the  protection   information,
            perform  an  INSTALL/REPLACE  on  all  other  nodes in the
            cluster.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Disable KEY compression for the key.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Disable KEY compression.

      This problem was introduced in OpenVMS V6.0.  The  problem  is
      fixed in the next release after OpenVMS Alpha V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Use STOP/ID to terminate the process.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Ensure that the DEADLOCK_WAIT  SYSGEN  parameter  and  the
            time out value specified in the RAB are different values.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix  to  prevent  record  locking  on  the  Null  device  when
     encountered in a searchlist.

     If the null device is included in a searchlist  for  a  shared
     file  open,  it  may  inappropriately  be accessed with record
     locking enabled.  Since the null device does not  support  the
     record  locking  option,  the  inconsistency  may cause an RMS
     bugcheck to be reported.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Place  the  null  device  as  the  first  element  of  the
              searchlist, or omit it.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to properly handle buffered block-mode file transfers from
     a foreign host that uses a non-standard block size.

     If  a  foreign  host  initiates  a  buffered  block-mode  file
     transfer  with  a  block  size  that  is not a multiple of the
     OpenVMS standard 512 byte block, the output file  may  contain
     extraneous  null  bytes.   FAL was padding its internal buffer
     with nulls to position the transfer on a  512  byte  boundary.
     The nulls would appear at or around the 64th block of the file
     (the size of FAL's internal buffer).  With this  modification,
     FAL no longer pads the buffer to be on a 512 byte boundary.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Use a buffer size that is a multiple of 512 bytes.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to prevent NETBTS (network buffer too small)  errors  when
     reading a remote file with Undefined (UDF) record format.

     When reading a file with undefined record format from a remote
     node, FAL fills in the DAP buffer completely and returns it to
     the requesting application.  This can cause the application to
     receive more data than it was expecting, resulting in a NETBTS
     error.  With this change, the USZ (user size) field is used in
     the  DAP  packet to specify how much data the user application
     is requesting.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to correctly fill  in  XAB$_NET  items  when  executing  a
     $DISPLAY  operation  that doesn't require accessing the remote
     node.

     A $DISPLAY operation failed to fill in the XAB$_NET XABITMs if
     a  network  access wasn't necessary.  This would occur even if
     the information was available  locally  in  the  Network  Work
     Area.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Attach a NAM block or some other structure  that  requires
            access to the remote node for information.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to handle Stream file carriage control for network  access
     to non-OpenVMS systems.

     OpenVMS FAL misrepresents the carriage control  attributes  of
     stream  format  files (STM) to non-OpenVMS systems.  With this
     correction, the carriage control is no longer  unconditionally
     changed  to  EMBEDDED  in  the  DAP  ATTRIBUTES message.  This
     problem was specific to stream (STM) format files.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.


Problems addressed in ALPRMS02_071:

  o  Fix 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  Fix for exec-mode access violation (accvio) that  results  from
     issuing  an  RFA  access  using  a VBN that exceeds the highest
     block (out-of-range) currently allocated to a file.

     The accvio will only occur if the out-of-range  RFA  access  is
     done  to  a  file  that  is both an indexed file and has global
     buffers enabled.  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.

     Note:  RFA access is a rare access mode for an  application  to
     use  with  an  indexed  file;  an out-of-range RFA access to an
     indexed file should be even rarer.

  o  Fix 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  Fix for inconsistent  secondary  key  in  RU-journaled  indexed
     file.

     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  XABITM stored semantics  attribute  fix  for  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  Fix for 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.


Problems Addressed in ALPRMS01_071:

  o  Fix for NULL KEY option for PACKED DECIMAL key type.

     This problem is restricted to an indexed file that has a secondary
     key type of PACKED DECIMAL and the NULL KEY option set.  In
     performing adds or updates to the indexed file, the application may
     ACCVIO.  The process may either:

       -  Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with an
          access violation (ACCVIO); or

       -  Crash the system (BUGCHECKFATAL enabled) with a SSRVEXCEPT
          (unexpected system service exception) ACCVIO error.

     NOTE:  Until this remedial kit can be installed, this problem can be
            prevented from reoccurring by converting the file with a
            revised FDL in which the null key option for the packed
            decimal secondary key has been changed to "no."

     The problem is fixed in the next release after OpenVMS Alpha V7.1.

     Workaround:

       -  Convert the file temporarily (until the remedial kit is
          applied) with a revised FDL in which the null key option for
          the packed decimal secondary key has been changed to "no."

  o  Solution for COB-F-BUG_CHECK error when rereading a sequential file.
     This problem is restricted to DEC COBOL on OpenVMS Alpha V7.1.

     While a DEC COBOL application may fail with a COBOL internal
     consistency error (COB-F-BUG_CHECK) for other reasons, a DEC COBOL
     application that worked on an earlier OpenVMS version and is failing
     on Alpha V7.1 with a COB-F-BUG_CHECK is likely to be remedied by
     this remedial kit if ALL of the following conditions are met:

       -  The DEC COBOL application fails with the COB-F-BUG_CHECK error
          when it is reading data records in a sequential file.

       -  The sequential file is opened allowing no write sharing.

       -  The sequential file has a maximum record size greater than
          zero.  A fixed-length record format always has a maximum record
          size greater than zero.  A zero maximum record size is
          typically associated with a variable or stream record format.

       -  All the data records in the sequential file are read up to the
          end-of-file by the DEC COBOL application.

       -  And the DEC COBOL application reads all the data records in the
          same sequential file more than once.

          The DEC COBOL application is either run multiple times within a
          short time period on the same system or within the application
          itself, all the data records in the same sequential file are
          read up to the end-of-file more than once.

          If the data records are only read once, then even if all the
          other conditions are met, the problem will not occur.

       -  Presumption:  The OpenVMS virtual I/O cache (VIOC) is enabled
          (and since it is enabled by default, it will be unless someone
          has explicitly disabled it).

     A change in behavior between RMS and the VIOC cache was added as a
     performance enhancement for RMS in Alpha V7.1 (see Section 5.18 of
     the OpenVMS V7.1 Release Notes).  VIOC now lets RMS know if it is
     able to satisfy one of RMS's read requests from blocks already in
     its cache.  This allows RMS to avoid stalling, which reduces
     overhead and improves performance.  Some RMS operations that always
     stalled previously may now never stall.

     In the case of an unshared sequential file (with maximum record
     size > 0), DEC COBOL does not use RMS record I/O ($GETs) to read the
     records in the file.  DEC COBOL uses asynchronous block I/O ($READs)
     and intermediate buffers of its own to do its own record processing.

     After reading all the data records in an unshared file, a number of
     the blocks may be cached by VIOC, including data blocks beyond the
     logical end-of-file.  In coding the error checking for the
     asynchronous block I/Os, DEC COBOL presumed that an end-of-file
     (EOF) status would always be returned as a completion status after a
     wait and never as an immediate status for the asynchronous block I/O
     read.

     With the V7.1 RMS/VIOC enhancement, if the file is reread while the
     blocks are still cached, it is possible for an EOF status to be
     appropriately returned by RMS as an immediate status.  In the case
     of an unexpected immediate error status, DEC COBOL returns the
     COB-F-BUG_CHECK.  In other words, DEC COBOL is returning the
     COB-F-BUG_CHECK for an EOF status -- when in fact the read is beyond
     the logical end-of-file.

     The RMS/VIOC enhancement is a compatible extension of the definition
     of the RMS services; a block I/O read ($READ) may (as has always
     been true) complete with a status of RMS$_EOF.  However, to expedite
     delivery of a solution for any DEC COBOL users who may be impacted,
     RMS has restored the old status behavior that DEC COBOL presumed.
     Namely, in the case of an asynchronous block I/O read that completes
     synchronously and the transfer is beyond the logical end-of-file,
     RMS$_PENDING will be returned as the immediate status and RMS$_EOF
     as the completion status.

     Workaround:

     Alternative workaround when a nonshared sequential file has to be
     read multiple times within a DEC COBOL application:

      -  Until the kit is installed, DEC COBOL Engineering recommends
         modifying the application's source code to temporarily remove
         any APPLY PREALLOCATION and APPLY EXTENSION statements.  There
         is no guarantee that this will provide a workaround in all
         cases.  Underallocating the file simply decreases the
         probability of this problem occurring in some cases.  Since not
         preallocating a file (or using a reasonable extension size) can
         degrade performance, this should be viewed only as a possible
         temporary workaround to this specific problem.


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.



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

Modification Date:  18-OCT-1999
Modification Type:  ARCHIVED

PRODUCT:    DIGITAL OpenVMS Alpha

COMPONENT:  RMS.EXE - Record Management Services

SOURCE:     Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name:  ALPRMS03_071
     ECO Kits Superseded by This ECO Kit:  ALPRMS02_071
                                           ALPRMS01_071
     ECO Kit Approximate Size:  2286 Blocks
     Kit Applies To:  OpenVMS Alpha V7.1, 7.1-1H1, 7.1-1H2
     System/Cluster Reboot Necessary:  Yes

     Installation Rating:  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 on OpenVMS Alpha V7.1 through V7.1-1H2.

Problems addressed in ALPRMS03_071:

  o  Performance enhancements to Global Buffer processing.

     RMS  has  implemented  a  new  algorithm  for  global   buffer
     management   that   dramatically  improves  scalability.   The
     performance associated with the previous algorithm effectively
     limited  the maximum number of global buffers on large, shared
     files.  With this change, customers may increase the number of
     global  buffers  on these files to the full limit of 32,767 to
     fully exploit large memory systems.

     Access to the global section used for RMS  global  buffers  is
     now   mainly  synchronized  using  inline  atomic  instruction
     sequences  rather  than  distributive  locking.   This  change
     allows  more concurrent access to the section (particularly on
     SMP machines).

     Note that increasing the number of global buffers on  specific
     files  may  require  some  system resources to be increased in
     size.   In  particular,  the   SYSGEN   parameters   GBLPAGES,
     GBLPAGFIL  or  GBLSECTIONS  may  need  to  be  increased.  In
     addition, process working set size and  page  file  quota  may
     need to be increased.

     This enhancement is included in the next release after OpenVMS
     Alpha V7.1.

  o  Enhancement to  add  128-bit  UTC  support  for  FAL/RMS  time
     transfers.

     RMS and FAL have been enhanced to support time transfers using
     128-bit UTC format.  Currently, RMS and FAL exchange date-time
     file attributes using an 18-byte ASCII string which includes a
     2-digit year.  Since the date is pivoted at 1970 (YY's from 70
     to 99 map to 1970 through 1999 and YY's from 00 to 69  map  to
     2000  through  2069),  OpenVMS  RMS  is Year 2000 compliant in
     regards to file access using DECNET FAL.

     The DAP specification provides for using a 128-bit UTC  binary
     date  as an alternative to the ASCII format.  This enhancement
     allows non-VMS operating  systems  to  access  file  dates  on
     OpenVMS in a completely Year 2000 compliant manner.

     This enhancement is included in the next release after OpenVMS
     Alpha V7.1.

  o  Fix to $READ for invalid transfer size and status returned for
     last transfer preceding end-of-file

     This problem is restricted to an application  using  the  user
     RAB64  structure  for  a  $READ (block I/O) with a buffer size
     greater than 65535 bytes.  If the last transfer just preceding
     the  end-of-file  exceeds  65535 bytes, then the transfer size
     returned  in  the  RAB64  (RAB64$L_RSZ)  is  invalid  and   an
     RMS-E-EOF  status is returned.  The correct transfer size will
     now be returned with the appropriate status of RMS-S-NORMAL.

     This problem was introduced in Alpha  V7.0  when  the  maximum
     transfer  size  was  increased  from  65535 bytes to 2**31 - 1
     bytes.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Temporarily  modify  application  to  restrict  block  I/O
            ($READ) transfer size to 127 blocks.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Following  the  change  in  the  protection   information,
            perform  an  INSTALL/REPLACE  on  all  other  nodes in the
            cluster.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Disable KEY compression for the key.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Disable KEY compression.

      This problem was introduced in OpenVMS V6.0.  The  problem  is
      fixed in the next release after OpenVMS Alpha V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Use STOP/ID to terminate the process.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

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

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Ensure that the DEADLOCK_WAIT  SYSGEN  parameter  and  the
            time out value specified in the RAB are different values.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix  to  prevent  record  locking  on  the  Null  device  when
     encountered in a searchlist.

     If the null device is included in a searchlist  for  a  shared
     file  open,  it  may  inappropriately  be accessed with record
     locking enabled.  Since the null device does not  support  the
     record  locking  option,  the  inconsistency  may cause an RMS
     bugcheck to be reported.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Place  the  null  device  as  the  first  element  of  the
              searchlist, or omit it.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to properly handle buffered block-mode file transfers from
     a foreign host that uses a non-standard block size.

     If  a  foreign  host  initiates  a  buffered  block-mode  file
     transfer  with  a  block  size  that  is not a multiple of the
     OpenVMS standard 512 byte block, the output file  may  contain
     extraneous  null  bytes.   FAL was padding its internal buffer
     with nulls to position the transfer on a  512  byte  boundary.
     The nulls would appear at or around the 64th block of the file
     (the size of FAL's internal buffer).  With this  modification,
     FAL no longer pads the buffer to be on a 512 byte boundary.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Use a buffer size that is a multiple of 512 bytes.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to prevent NETBTS (network buffer too small)  errors  when
     reading a remote file with Undefined (UDF) record format.

     When reading a file with undefined record format from a remote
     node, FAL fills in the DAP buffer completely and returns it to
     the requesting application.  This can cause the application to
     receive more data than it was expecting, resulting in a NETBTS
     error.  With this change, the USZ (user size) field is used in
     the  DAP  packet to specify how much data the user application
     is requesting.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to correctly fill  in  XAB$_NET  items  when  executing  a
     $DISPLAY  operation  that doesn't require accessing the remote
     node.

     A $DISPLAY operation failed to fill in the XAB$_NET XABITMs if
     a  network  access wasn't necessary.  This would occur even if
     the information was available  locally  in  the  Network  Work
     Area.

       Alternative workarounds:

         +  Apply this remedial kit.

         +  Attach a NAM block or some other structure  that  requires
            access to the remote node for information.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.

  o  Fix to handle Stream file carriage control for network  access
     to non-OpenVMS systems.

     OpenVMS FAL misrepresents the carriage control  attributes  of
     stream  format  files (STM) to non-OpenVMS systems.  With this
     correction, the carriage control is no longer  unconditionally
     changed  to  EMBEDDED  in  the  DAP  ATTRIBUTES message.  This
     problem was specific to stream (STM) format files.

     The problem is fixed in the next release after  OpenVMS  Alpha
     V7.1.


Problems addressed in ALPRMS02_071:

  o  Fix 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  Fix for exec-mode access violation (accvio) that  results  from
     issuing  an  RFA  access  using  a VBN that exceeds the highest
     block (out-of-range) currently allocated to a file.

     The accvio will only occur if the out-of-range  RFA  access  is
     done  to  a  file  that  is both an indexed file and has global
     buffers enabled.  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.

     Note:  RFA access is a rare access mode for an  application  to
     use  with  an  indexed  file;  an out-of-range RFA access to an
     indexed file should be even rarer.

  o  Fix 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  Fix for inconsistent  secondary  key  in  RU-journaled  indexed
     file.

     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  XABITM stored semantics  attribute  fix  for  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  Fix for 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.


Problems Addressed in ALPRMS01_071:

  o  Fix for NULL KEY option for PACKED DECIMAL key type.

     This problem is restricted to an indexed file that has a secondary
     key type of PACKED DECIMAL and the NULL KEY option set.  In
     performing adds or updates to the indexed file, the application may
     ACCVIO.  The process may either:

       -  Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with an
          access violation (ACCVIO); or

       -  Crash the system (BUGCHECKFATAL enabled) with a SSRVEXCEPT
          (unexpected system service exception) ACCVIO error.

     NOTE:  Until this remedial kit can be installed, this problem can be
            prevented from reoccurring by converting the file with a
            revised FDL in which the null key option for the packed
            decimal secondary key has been changed to "no."

     The problem is fixed in the next release after OpenVMS Alpha V7.1.

     Workaround:

       -  Convert the file temporarily (until the remedial kit is
          applied) with a revised FDL in which the null key option for
          the packed decimal secondary key has been changed to "no."

  o  Solution for COB-F-BUG_CHECK error when rereading a sequential file.
     This problem is restricted to DEC COBOL on OpenVMS Alpha V7.1.

     While a DEC COBOL application may fail with a COBOL internal
     consistency error (COB-F-BUG_CHECK) for other reasons, a DEC COBOL
     application that worked on an earlier OpenVMS version and is failing
     on Alpha V7.1 with a COB-F-BUG_CHECK is likely to be remedied by
     this remedial kit if ALL of the following conditions are met:

       -  The DEC COBOL application fails with the COB-F-BUG_CHECK error
          when it is reading data records in a sequential file.

       -  The sequential file is opened allowing no write sharing.

       -  The sequential file has a maximum record size greater than
          zero.  A fixed-length record format always has a maximum record
          size greater than zero.  A zero maximum record size is
          typically associated with a variable or stream record format.

       -  All the data records in the sequential file are read up to the
          end-of-file by the DEC COBOL application.

       -  And the DEC COBOL application reads all the data records in the
          same sequential file more than once.

          The DEC COBOL application is either run multiple times within a
          short time period on the same system or within the application
          itself, all the data records in the same sequential file are
          read up to the end-of-file more than once.

          If the data records are only read once, then even if all the
          other conditions are met, the problem will not occur.

       -  Presumption:  The OpenVMS virtual I/O cache (VIOC) is enabled
          (and since it is enabled by default, it will be unless someone
          has explicitly disabled it).

     A change in behavior between RMS and the VIOC cache was added as a
     performance enhancement for RMS in Alpha V7.1 (see Section 5.18 of
     the OpenVMS V7.1 Release Notes).  VIOC now lets RMS know if it is
     able to satisfy one of RMS's read requests from blocks already in
     its cache.  This allows RMS to avoid stalling, which reduces
     overhead and improves performance.  Some RMS operations that always
     stalled previously may now never stall.

     In the case of an unshared sequential file (with maximum record
     size > 0), DEC COBOL does not use RMS record I/O ($GETs) to read the
     records in the file.  DEC COBOL uses asynchronous block I/O ($READs)
     and intermediate buffers of its own to do its own record processing.

     After reading all the data records in an unshared file, a number of
     the blocks may be cached by VIOC, including data blocks beyond the
     logical end-of-file.  In coding the error checking for the
     asynchronous block I/Os, DEC COBOL presumed that an end-of-file
     (EOF) status would always be returned as a completion status after a
     wait and never as an immediate status for the asynchronous block I/O
     read.

     With the V7.1 RMS/VIOC enhancement, if the file is reread while the
     blocks are still cached, it is possible for an EOF status to be
     appropriately returned by RMS as an immediate status.  In the case
     of an unexpected immediate error status, DEC COBOL returns the
     COB-F-BUG_CHECK.  In other words, DEC COBOL is returning the
     COB-F-BUG_CHECK for an EOF status -- when in fact the read is beyond
     the logical end-of-file.

     The RMS/VIOC enhancement is a compatible extension of the definition
     of the RMS services; a block I/O read ($READ) may (as has always
     been true) complete with a status of RMS$_EOF.  However, to expedite
     delivery of a solution for any DEC COBOL users who may be impacted,
     RMS has restored the old status behavior that DEC COBOL presumed.
     Namely, in the case of an asynchronous block I/O read that completes
     synchronously and the transfer is beyond the logical end-of-file,
     RMS$_PENDING will be returned as the immediate status and RMS$_EOF
     as the completion status.

     Workaround:

     Alternative workaround when a nonshared sequential file has to be
     read multiple times within a DEC COBOL application:

      -  Until the kit is installed, DEC COBOL Engineering recommends
         modifying the application's source code to temporarily remove
         any APPLY PREALLOCATION and APPLY EXTENSION statements.  There
         is no guarantee that this will provide a workaround in all
         cases.  Underallocating the file simply decreases the
         probability of this problem occurring in some cases.  Since not
         preallocating a file (or using a reasonable extension size) can
         degrade performance, this should be viewed only as a possible
         temporary workaround to this specific problem.


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.
Files on this server are as follows:
»alprms04_071.README
»alprms04_071.CHKSUM
»alprms04_071.CVRLET_TXT
»alprms04_071.a-dcx_axpexe
»alprms04_071.CVRLET_TXT
privacy statement using this site means you accept its terms