The RDO 4.1 new features and technical changes include:

Additional information available:

RDO_IMPORT

RDO SHOW FIELD statementCarry over LocksDefault Lock Wait
Fast CommitGlobal BuffersQuery GovernorModifiable Logical Area Thresholds

 The RDO SHOW FIELD statement displays the new SQL date/time data
 types as follows:

 RDO> SHOW FIELDS FOR DT_TEST
  Fields for relation  DT_TEST
      INT_DAY                          interval day (4)
      INT_DAY_HOUR                     interval day (3) to hour
      INT_DAY_SECOND                   interval day (4) to second (3)
      INT_YEAR                         interval year (4)
      INT_MONTH                        interval month (2)
      INT_HOUR_MINUTE                  interval hour (2) to minute
      TIME_NOW                         time (0)
      TIME_NOW_2                       time (2)
      DATE_TODAY                       date only
      CLOCKON                          timestamp (3)

 The RDO IMPORT statement supports the full range of V4.1 features.

 The RDO IMPORT statement now correctly imports interchange files
 (RBR) created using SQL and RDO EXPORT commands.  This support
 includes:

 1.  Multischema databases created by SQL

 2.  New database wide attributes

     1.  Global buffers

     2.  Carry-over locks

     3.  Lock timeout interval

     4.  Journal fast commit (fast commit)

     5.  Adjustable lock granularity (although not new this attribute
         is only exported and imported by Rdb/VMS V4.1 and later)


 3.  Storage area attributes

     1.  Write-once attribute is restored (output device should be a
         WORM device)

     2.  Mixed area thresholds (although not new this attribute is
         only exported and imported by Rdb/VMS V4.1 and later)

     3.  SPAM intervals (although not new this attribute is only
         exported and imported by Rdb/VMS V4.1 and later)


 4.  Storage map and index attributes

     1.  Logical area thresholds


 5.  New data type support

     1.  DATE, TIME, TIMESTAMP, and INTERVAL data types are imported,
         although these data types cannot be defined or used directly
         in RDO


 6.  SERdb database attributes

 7.  An informational message is now issued naming the original
     databases's AIJ file.  After-image journaling is NOT enabled by
     the IMPORT statement.


                                 NOTE

         The RDO IMPORT statement cannot be used to disable
         multischema.  You must use the SQL IMPORT statement
         and the MULTISCHEMA IS OFF clause to perform this
         task.

 The carry-over locks option is a database-wide parameter that allows
 you to disable carry-over lock optimization.  This optimization
 (implemented in Rdb/VMS Version 4.0) is enabled by default.  Although
 this is an advantage in most environments, it can result in false
 lock conflicts in some applications.

 The carry-over locks optimization holds area and record locks across
 transactions and depends on NOWAIT transactions asking for and
 acquiring the NOWAIT lock.  This can result in long delays if
 concurrent users are executing long verbs.  You should consider
 disabling the carry-over locks optimmization if transactions
 experience noticeable delays in acquiring the NOWAIT lock (as seen in
 the output of the RMU/SHOW STATISTICS command).  Note that if you do
 disable the carry-over locks option, there may be some performance
 degradation because transactions will acquire and release area and
 top level ALG locks for every transaction.

 Use the RDO DEFINE or CHANGE DATABASE statements as follows:

 DEFINE DATABASE FILENAME TEST
 CARRY OVER LOCKS ARE ENABLED.

 DEFINE DATABASE FILENAME TEST
 CARRY OVER LOCKS ARE DISABLED.

 CHANGE DATABASE FILENAME TEST
 CARRY OVER LOCKS ARE ENABLED.

 CHANGE DATABASE FILENAME TEST
 CARRY OVER LOCKS ARE DISABLED.

 Use the RDO DEFINE or CHANGE DATABASE statements as follows:

 DEFINE DATABASE FILENAME PERSONNEL
 LOCK TIMEOUT INTERVAL IS n SECONDS.

 CHANGE DATABASE FILENAME PERSONNEL
 LOCK TIMEOUT INTERVAL IS n SECONDS.

 Where n is defined as the number of seconds.

 This is a database wide timeout interval.  It is used as the default
 as well as the upper limit in determining the timeout interval to
 use.  For example, if LOCK TIMEOUT INTERVAL IS 25 SECONDS is
 specified with the CHANGE DATABASE or DEFINE DATABASE statement, a
 user specifies 30 seconds with the SQL SET TRANSACTION WAIT 30
 statement or sets the logical name RDM$BIND_LOCK_TIMEOUT_INTERVAL to
 30, RDO would still use the interval of 25 specified with the LOCK
 TIMEOUT INTERVAL clause.

 By default, Rdb/VMS writes updated database pages to disk each time a
 transaction executes the COMMIT statement.  If a transaction fails
 before committing, Rdb/VMS only needs to rollback (undo) the current
 failed transaction; it never has to redo previous successful
 transactions.

 You can change the commit processing method by enabling journal fast
 commit processing (fast commit).  With fast commit enabled, Rdb/VMS
 keeps updated pages in the buffer pool (in memory) and does not write
 the pages to disk when a transaction commits.  The updated pages can
 remain in the buffer pool until the process meets a condition
 specified by the database administrator or applications programmer.
 At the moment the condition is met, called the checkpoint, all the
 pages the process has updated, for multiple transactions, are written
 to disk.

 You can set a checkpoint for your process when:

  o  A fixed number of transactions have been committed or aborted

  o  A specified time interval has elapsed

  o  The after-image journal (AIJ) file has grown a certain amount

 If a transaction fails, Rdb/VMS must undo the current, failed
 transaction and redo all the committed transactions since the last
 checkpoint.  Redoing updates involves reading the AIJ file and
 reapplying the changes to the relevant data pages.

 The checkpoint interval value is set by the database administrator
 and applies to all processes attached to a database.  Users can
 implement an alternate, process-specific method of checkpointing by
 defining the logical name RDM$BIND_CHKPT_TRANS_LIMIT.  The mechanism
 uses transaction count as the checkpoint.  When fast commit
 processing is disabled, the RDM$BIND_CHKPT_TRANS_LIMIT logical name
 is ignored.  For more information about the
 RDM$BIND_CHKPT_TRANS_LIMIT logical name, see the VAX Rdb/VMS Guide to
 Database Performance and Tuning.

 Fast commit processing applies only to data updates, that is erase,
 modify, and store operations.  Transactions that include data
 definition statements, such as create logical area or create index
 operations, force a checkpoint at the end of the transaction.

 Note that in order to enable fast commit, you must enable after-image
 journaling.

 If fast commit is enabled for a database, you cannot perform a
 no-quiet-point AIJ backup.

 The VAX Rdb/VMS Guide to Database Performance and Tuning discusses
 the merits of each recovery method and provides details about how the
 recovery from fast commit processing affects AIJ backups.

 A syntax diagram for the fast commit feature and more information
 about the feature can be found in the "journal-fast-commit-clause"
 subtopic of the CHANGE_DATABASE help topic.

 Prior to Version 4.1, all page buffering was local to the user
 process.  Beginning with Version 4.1, global page buffering is
 available.  Existing buffer qualifiers have not changed.
 Page-locking protocol has been adjusted to support global buffering
 on VAXclusters.  By default, global buffering is not enabled and
 local buffering is used.

 With global buffering, user processes map global sections to their
 virtual memory instead of making copies of the buffer in physical
 memory.  For more than one user process to read a page at the same
 time, there will be only one copy of the page in the global buffer
 pool.  Improved performance is achieved because I/O operations are
 reduced and memory is better utilized.

 By default, Rdb/VMS maintains a local buffer pool for each process.
 For more than one process to use the same page, each must read it
 from disk into their local buffer pool.  A page in the global buffer
 pool may be read by more than one process at the same time, although
 only one process reads the page from disk into the global buffer
 pool.  Global buffering provides improved performance because I/O is
 reduced and memory is better utilized.

 You can use the CHANGE DATABASE statement to enable global buffering
 as follows:

 CHANGE DATABASE FILENAME PERSONNEL
 GLOBAL BUFFERS ARE ENABLED
 (NUMBER IS n,
 USER LIMIT IS u).

 Where n is defined as the number of global buffers and u is defined
 as the maximum or (user limit) number of global buffers per user.

 The NUMBER IS clause specifies the default number of global buffers
 to be used on one node when global buffers are enabled.  This number
 appears as "global buffer count" in RMU/DUMP command output.  Base
 this value on the database users' needs and the number of attaches.
 The default is the maximum number of attaches multiplied by 5.  The
 number is clause is specific to global buffers.  All other buffer
 arguments are valid for both local buffers and global buffers.

 The USER LIMIT IS clause specifies the maximum number of global
 buffers each attach allocates.  Because global buffer pools are
 shared by all attaches, you must define an upper limit on how many
 global buffers a single attach can allocate.  This value cannot be
 greater than the total number of global buffers.  The default is 5.
 This number appears as "maximum global buffer count per user" in
 RMU/DUMP command output.

 Decide the maximum number of global buffers a process can allocate
 per attach by dividing the total number of global buffers set by the
 NUMBER IS clause by the total number of attaches you want guaranteed
 to access the database.  For example, if the total number of global
 buffers is 200, and you want to guarantee that no more than 10
 attaches can be made to the database, set the maximum number of
 global buffers per attach to 20.

 In general, when using global buffers, the maximum global buffer
 count per user should be set higher than the default database buffer
 count.

 There is no RDO interface for the query governor feature.  Use the
 two new Rdb/VMS logical names (RDMS$BIND_QG_TIMEOUT and
 RDMS$BIND_QG_REC_LIMIT) for implementing this feature for RDO, RDML,
 and RDBPRE.

 See the top-level help topic "Logical_Names" for more information
 about using these logical names to implement the query governor
 feature.

 The RDO DEFINE and CHANGE INDEX and RDO DEFINE and CHANGE STORAGE MAP
 statements support user specified logical area thresholds for more
 efficient storage of table rows and index records in uniform storage
 areas.

 See the "index-storage-clause" subtopic of the CHANGE_INDEX and
 DEFINE_INDEX help topics and the "map-storage-clause" subtopic of the
 CHANGE_STORAGE_MAP and DEFINE_STORAGE_MAP help topics for more
 information.