Conference orarep::nomahs::rdb_60

    ORACLE RDB V6.0A ECO 6 (AKA V6.0-16) is now available from the PATCH$$
    directory on WRVMS:-
    
    Directory WRVMS::PATCH$$:[PATCH.RDB.RDBV6016]
    
    DECRDBAMVE6A060.A;1    83538
    DECRDBASE6A060.A;1     81900
    DECRDBMVE6A060.A;1     42147
    DECRDBSE6A060.A;1      41580
    
    Total of 4 files, 249165 blocks.
    
    where
    	DECRDBAMVE6A060.A;1 is the Alpha Multi-version kit
        DECRDBASE6A060.A;1  is the Alpha Standard kit
    	DECRDBMVE6A060.A;1  is the Vax Multi-version kit
    	DECRDBSE6A060.A;1   is the Vax Standard kit
    
    Problems Fixed in RDB v6.0A ECO 6
    
      Extra I/O's during a single hash insert
      Restriction When Adding Storage Areas With Users Attached to Database
      Hash index does not fully utilise free space
      RMU/RESTORE Bugchecks at FILE_CLEANUP + 72
      Excessive SPAM fetches on batch insert to full area
      Read Only Transaction Returned Incorrect Results
      Process Would Not Release Logical Area Lock - Alpha only
      Out-of-lexical order during b-tree inserts
      Memory leak when executing backward index scans
      System Bugcheck with PGFIPLHI at Image Exit - VAX Only
      Faulty backup strategy could cause recovery process to loop
      Constraint may not be evaluated with NULL values - Alpha only
      Poorly formatted query causes infinite loop
      Full outer join with derived tables and IS NULL predicate may return
            incorrect results
      Usage of RDMS$BIND_SEGMENTED_STRING_COUNT may cause VM corruption
      CONVERT_ERROR or ARITH_EXCEPT from SELECT with GROUP BY when no data
            in underlying table
      Bugcheck in RDMS$$LOAD_STBL_MAPS
      Missing symbols from RDMMSGSHR
      DBHANDUNK returned instead of EOS in embedded SQL
      Cross database INSERT would go into a loop
      INVALID_BLR,INVTRIMOPT from TRIM built-in function when used with aliases
      Bugcheck in RMUANA$1_PAGE_UNIFORM after RMU/ANA/START
      RMU/EXTRACT and large VARCHARs
      ALTER INDEX changes HASHED ORDERED to HASH SCATTERED
      ALTER INDEX waits too long to validate storage area name
      Trailing Space Added When CAST'ing Smallint As Varchar(2)
      RDMS-E-EXCMAPLIMIT when inserting any data into a partitioned table
    
                                

          1  CHECKSUM Error Symptoms

          An application reports a RDMS-F-CHECKSUM or DBM-F-CHECKSUM er-
          ror. Oracle Rdb and Oracle Codasyl DBMS CHECKSUM errors indicate
          an error in the I/O path between the point in time when Oracle
          Rdb or Oracle Codasyl DBMS CHECKSUM or issued an I/O write re-
          quest and when Oracle Rdb or Oracle Codasyl DBMS subsequently
          read the data again. RMU/VERIFY and RMU/BACKUP, or DBO/VERIFY
          and DBO/BACKUP can also detect and report checksum errors.

          2  Oracle Page Checksum Overview

          Before writing a page to the database, Oracle Rdb and Oracle
          Codasyl DBMS perform a checksum calculation on the page. The
          checksum value is the longword arithmetic sum of all longwords
          on the entire physical page. The calculated value is stored on
          the page and then the page is written to the database.

          Each time a page is read from the database, the checksum value
          is re-calculated and compared with the value previously stored.
          If the calculated value is not the same as the value stored
          on the page, a CHECKSUM condition is signaled. This checksum
          process is used to provide a bit-level validation that the data
          read from the database is the same as the data that was written
          to the database.

          Oracle Rdb and Oracle Codasyl DBMS also store on each page the
          physical page and area number where this page resides along with
          a timestamp of when the page was last updated. Oracle Rdb and
          Oracle Codasyl DBMS compare the returned page and area number
          with the requested page and area number to ensure that the
          correct page was, in fact, returned by the system. Storing
          the update timestamp on the page virtually guarantees that
          each update of a page will result in a new checksum value being
          stored.

          If a problem with database checksums is suspected (due, for
          example, to CHECKSUM errors being signaled), the RMU or DBO
          /VERIFY command can be used to perform verification of the
          database. When using Oracle Rdb, the RMU /VERIFY /CHECKSUM_
          ONLY command can be used to performan a minimal verification
          where only page checksums are verified.

          3  Possible Causes and Analysis of Checksum Errors

          The I/O path on the system is complex and contains a number
          of individual software and hardware components. Each of these
          components may be involved when reading or writing data between
          a process and the storage device. If any one of the components
          were to fail to completely and accurately transfer the data, an
          unintended error or corruption could occur.




                                                                         1

 






          If checksum errors should occur, there are several steps that
          can be taken to help isolate the failing component(s) in the I/O
          path. It is important to realize that Oracle Rdb and Oracle Co-
          dasyl DBMS only detect the inconsistency, they are not actually
          responsible for the problem.

          Check any system error logs and look for events that occurred
          near the time of the checksum error. If, for example, a disk
          drive was failing, it is possible that it would be unable to de-
          tect all occurrences of failure and could unintentionally return
          bad data. Most often, however, there are no errors because the
          failing component was unable to detect the condition.

          If the page was written incorrectly to disk, it may be possi-
          ble to dump the page (using the RMU or DBO /DUMP command) and
          inspect the timestamp on the page. This may provide additional
          information about when the page became corrupted.

          If a component of the storage system were to fail to store an
          entire write I/O operation, later read requests by Oracle Rdb or
          Oracle Codasyl DBMS for the data may be unable to detect the I/O
          that was missed. This can happen, for example, because the data
          page is correctly formatted and various information that Oracle
          Rdb and Oracle Codasyl DBMS uses to validate the page appear
          correct as well. In these cases, there may be no way to detect
          the corruption, even though it actually occured. This sort of
          I/O failure may result in corrupted indexes or logically corrupt
          data that is not physically incorrect.

          Ensure that all components in the I/O path are at the latest
          available revision (contact your hardware and software vendor(s)
          for information about what revisions are current). This includes
          validating that, for example, disk drives are at the latest
          available firmware revisions, that storage controllers (for ex-
          ample, an HSC or HSJ device or a SCSI adapter) are at the latest
          hardware and firmware revisions, that operating system patches
          that could effect the I/O path (such as locking, shadowing, RMS,
          the XQP, disk port and class drivers, etc.) have been applied.

          3.1  Caches

          If a checksum error occurs and then the same operation is re-
          tried at a later time and it succeeds, then a transient error
          may have occurred. This can be caused, for example, by a problem
          with a cache somewhere along the I/O path.

          Data caches can exist at a number of places. Modern disk devices
          can include a cache of recently read and written data, storage
          controllers (an HSC or HSJ device for example) can include a
          cache, and operating systems can include read or write caches.
          If any of these caches were to be storing incorrect data, it
          could be returned in error. At a later time, the incorrect data
          may be flushed from the cache (perhaps to make room for more
          current data). The next read request for the data would cause

          2

 






          the information to be read directly from the disk (because it is
          no longer in the cache) and the correct date may be returned.

          If a problem were to occur in a cache and if the failing op-
          eration succeeds upon a later attempt, there may be no need
          to perform any more recovery. In this case, the incorrect data
          in the cache would have been removed from the cache and valid
          data was returned from disk. The errant copy of the data has
          'disappeared'.

          3.2  Shadowing

          Another cause of 'transient' checksum errors can occur when
          shadowed (RAID 1 or 'mirrored') devices are used. If a write
          operation to the shadow set correctly updates some member of the
          shadow set and does not correctly update other members, the data
          returned from a read to the shadow set may be different when the
          operation is retried. Again, this case would point to a problem
          within the shadowing software or firmware.

          3.3  Read and Write Checking

          When checksum errors are frequent, disks may be mounted with
          the /DATA_CHECK=(READ,WRITE) qualifier on the operating system
          MOUNT command. Mounting disks in this way cause read and write
          I/O requests to be verified by the operating system. Certain
          I/O errors will be detected by the operating system by re-
          reading data after reads or writes. A comparison failure at
          this stage will cause an error to be returned to Oracle Rdb or
          Oracle Codasyl DBMS indicating that the data was not correctly
          read or written by the operating system for the I/O operation.


          4  Recovery

          When a page in the database has a checksum error, the page must
          be restored from a database backup and then recovered from the
          after image journal. Using the RMU /RESTORE /JUST_PAGES or DBO
          /RESTORE /JUST_PAGES (in Oracle Rdb V7.0 and Oracle Codasyl
          DBMS V7.0, the /JUST_PAGES qualifier is replaced with the /JUST_
          CORRUPT qualifier) command, you can selectively restore selected
          pages of selected storage areas. Once the pages are restored,
          access to these restored pages is prohibited until they are made
          consistent by recovering from the after image journals. Note the
          in order to use the Oracle Codasyl DBMS DBO /RESTORE /JUST_PAGES
          feature, the backup must have been done using the /MULTITHREAD
          qualifier.








                                                                         3

 






          5  Backup Considerations

          Oracle recommends that you use the /CHECKSUM_VERIFICATION qual-
          ifier with all RMU and DBO BACKUP operations because of the
          improved data integrity this qualifier provides by verifying
          the checksum stored on each database page before it is backed
          up, thereby providing end-to-end error detection on the database
          I/O. Performing all RMU and DBO backups with the /CHECKSUM_
          VERIFICATION qualifier will provide an ongoing verification of
          page checksums within the database.

          The risk of using RMU or DBO /BACKUP /NOCHECKSUM_VERIFICATION
          is that RMU or DBO will save pages that have checksum errors
          (because the checksum calculation is disabled these errors will
          not be detected) and a subsequent RMU or DBO /RESTORE of the
          backup will restore these corrupt pages and will compute a new
          checksum value. This leads to undetected database corruption.

          For the highest level of backup media and I/O path error detec-
          tion, Oracle recommends that /CRC=AUTODIN_II qualifier be used
          when using the RMU or DBO /BACKUP command. Using this quali-
          fier during the backup allows the RMU or DBO /RESTORE command
          to detect additional media or other I/O errors during a restore
          operation beyond the error detection components of the backup
          device(s).






























          4

Discussion came up today about the year 2000 being a leap year.  I
dug up this famous Digital SPR response from the archives.  Stan
Rabinowitz wrote this up in reply to a customer SPR.  I don't know
if it was ever actually sent to the customer or not...  Interesting
reading in any case.


SPR NO. 11-60903

           SYSTEM   VERSION   PRODUCT   VERSION   COMPONENT
SOFTWARE:  VAX/VMS  V3.2      VAX/VMS   V3.2      Run-Time Library


PROBLEM:

The LIB$DAY Run-Time Library service "incorrectly"  assumes  the  year
2000 is a leap year.


RESPONSE:

Thank you for your forward-looking SPR.

Various system services, such as SYS$ASCTIM assume that the year  2000
will  be  a  leap  year.   Although one can never be sure of what will
happen at some future time, there is strong historical  precedent  for
presuming  that the present Gregorian calendar will still be in affect
by the year 2000.  Since we also hope that VMS will still be around by
then, we have chosen to adhere to these precedents.

The purpose of a calendar is to reckon time in advance,  to  show  how
many  days  have  to  elapse  until a certain event takes place in the
future, such as the harvest or the release of VMS  V4.   The  earliest
calendars,  naturally,  were  crude  and  tended  to be based upon the
seasons or the lunar cycle.

The calendar of the Assyrians, for example, was based upon the  phases
of  the  moon.  They knew that a lunation (the time from one full moon
to the next) was 29 1/2 days long, so their lunar year had a  duration
of  364  days.   This  fell  short of the solar year by about 11 days.
(The exact time for the solar year is approximately 365 days, 5 hours,
48  minutes,  and  46  seconds.)  After 3 years, such a lunar calendar
would be off by a whole month, so the Assyrians added an  extra  month
from  time  to time to keep their calendar in synchronization with the
seasons.

The best approximation that was possible in antiquity  was  a  19-year
period, with 7 of these 19 years having 13 months (leap months).  This
scheme was adopted as the basis for the religious calendar used by the
Jews.   (The  Arabs  also  used  this  calendar until Mohammed forbade
shifting from 12 months to 13 months.)

When Rome emerged as a world  power,  the  difficulties  of  making  a
calendar  were  well  known,  but  the  Romans complicated their lives
because of their superstition that even numbers were  unlucky.   Hence
their  months were 29 or 31 days long, with the exception of February,
which had 28 days.  Every second year, the Roman calendar included  an
extra  month  called  Mercedonius of 22 or 23 days to keep up with the
solar year.

Even this algorithm was very poor, so that in 45 BC,  Caesar,  advised
by  the  astronomer Sosigenes, ordered a sweeping reform.  By imperial
decree, one year was made 445 days long to bring the calendar back  in
step  with  the  seasons.  The new calendar, similar to the one we now
use was called the Julian calendar (named after Julius Caesar).   It's
months  were  30 or 31 days in length and every fourth year was made a
leap year (having 366 days).  Caesar also decreed that the year  would
start with the first of January, not the vernal equinox in late March.

Caesar's year was 11 1/2 minutes short of the calculations recommended
by  Sosigenes  and  eventually the date of the vernal equinox began to
drift.  Roger Bacon became alarmed and sent a note to Pope Clement IV,
who  apparently  was  not  impressed.   Pope  Sixtus  IV  later became
convinced that  another  reform  was  needed  and  called  the  German
astronomer,  Regiomontanus,  to  Rome  to  advise him.  Unfortunately,
Regiomontanus died of the plague shortly thereafter and the plans died
as well.

In 1545, the Council of Trent authorized Pope Gregory XIII  to  reform
the  calendar  once  more.   Most of the mathematical work was done by
Father Christopher Clavius, S.J.  The immediate  correction  that  was
adopted  was  that Thursday, October 4, 1582 was to be the last day of
the Julian calendar.  The next  day  was  Friday,  with  the  date  of
October  15.   For  long  range  accuracy,  a formula suggested by the
Vatican librarian Aloysius Giglio was adopted.   It  said  that  every
fourth  year  is  a  leap  year  except for century years that are not
divisible by 400.  Thus 1700, 1800 and 1900 would not be  leap  years,
but  2000  would  be a leap year since 2000 is divisible by 400.  This
rule eliminates 3 leap years every 4 centuries,  making  the  calendar
sufficiently  correct  for  most  ordinary purposes.  This calendar is
known as the Gregorian calendar and is the one that we now use  today.
(It  is  interesting  to note that in 1582, all the Protestant princes
ignored the papal decree and so many countries continued  to  use  the
Julian  calendar  until either 1698 or 1752.  In Russia, it needed the
revolution to introduce the Gregorian calendar in 1918.)

This explains why VMS chooses to treat the year 2000 as a leap year.

Despite the great accuracy of the Gregorian calendar, it  still  falls
behind very slightly every few years.  If you are very concerned about
this problem, we suggest that you tune in  short  wave  radio  station
WWV,  which  broadcasts  official  time  signals for use in the United
States.  About once every 3 years, they declare a leap second at which
time  you  should be careful to adjust your system clock.  If you have
trouble picking up their signals, we suggest you  purchase  an  atomic
clock (not manufactured by Digital and not a VAX option at this time).


                         END OF SPR RESPONSE

    As one of Stan's former Project Leaders, I think it unlikely that Stan
    would have concluded that 12*29� = 364 instead of 354 -- which is 11
    days short of a solar year.  I think that error occurred in a
    transcription.
    
    Then again ...
    
    ed

Well I am all packed for the move to One Oracle Drive...

So I was reading comp.databases.rdb and write this small external functions
example to manipulate DBKEY's...

enjoy!

	Ian

a) The options files SHOW_AREA.OPT

universal=show_area
universal=show_line
universal=show_page
universal=set_dbkey

b) The C source for the external functions: SHOW_AREA.C

/* Ian Smith	27 February, 1997
   These are simple functions for use as
   Rdb EXTERNAL functions to extract and build DBKEYS
*/

#include <stdio>

/* The DBKEY is a packed structure.  On some platforms you'll
   Need to disable natural alignment */
struct dbk_format {
        short int       l;
        int             p;
        short int       a;
    };

int show_area (struct dbk_format *dbk)
{
    /* return the area from the DBKEY */
    return dbk->a;
}

int show_page (struct dbk_format *dbk)
{
    /* return the page number from the DBKEY */
    return dbk->p;
}

int show_line (struct dbk_format *dbk)
{
    /* return the line number from the DBKEY */
    return dbk->l;
}

void set_dbkey (struct dbk_format *dbk,
		int area_n, int page_n, int line_n)
{
    printf ("%d %d %d", area_n, page_n, line_n);

    /* build a DBKEY from the supplied pieces */
    dbk->a = area_n;
    dbk->p = page_n;
    dbk->l = line_n;
}

c) The SQL script to define and test: SHOW_AREA.SQL

-- These are the external function definitions
-- and some example usage

set verify
attach 'file scratch';

create function SHOW_AREA (in :dbk CHAR(8) by reference)
returns INTEGER;
external
    location 'SHOW_AREA.EXE'
    language C 
    GENERAL parameter style;

create function SHOW_PAGE (in :dbk CHAR(8) by reference)
returns INTEGER;
external
    location 'SHOW_AREA.EXE'
    language C 
    GENERAL parameter style;

create function SHOW_LINE (in :dbk CHAR(8) by reference)
returns INTEGER;
external
    location 'SHOW_AREA.EXE'
    language C 
    GENERAL parameter style;

create function SET_DBKEY (in :area integer by value,
			   in :page integer by value, 
			   in :line integer by value)
returns CHAR(8) by reference;
external
    location 'SHOW_AREA.EXE'
    language GENERAL	-- don't want DBKEY treated as a string
    GENERAL parameter style;

declare :dbk char(8);

-- for my database 8:485:0 is the DBKEY for RDB$DATABASE, your
-- database may well be different.  Substitute a real DBKEY for this...
--
select DBKEY, SHOW_AREA (DBKEY), SHOW_PAGE (DBKEY), SHOW_LINE (DBKEY)
 from rdb$database;

set flags 'TRACE';
begin
set :dbk = set_dbkey(8, 485, 0);
trace show_area (:dbk), show_page (:dbk), show_line (:dbk);
end;

select rdb$flags
 from rdb$database
 where DBKEY = set_dbkey(8, 485, 0);

rollback;

d) Here is what you do...

$ cc show_area.c
$ link/share show_area, show_area/opt
$ sql$ @show_area.sql

[OpenVMS] Which ECOs are Incorporated in VAX V6.2 / Need to Install
Last Technical Review:  6-MAR-1997                            Size: 229 lines


     Any party granted access to the following copyrighted information
     (protected under Federal Copyright Laws), pursuant to a duly executed
     Digital Service Agreement may, under the terms of such agreement copy
     all or selected portions of this information for internal use and
     distribution only. No other copying or distribution for any other
     purpose is authorized.

Copyright (c) Digital Equipment Corporation 1995, 1997.  All rights reserved.

OP/SYS:     OpenVMS VAX, Version 6.2

COMPONENT:  ECO Kits

SOURCE:     Digital Equipment Corporation


CORRECT USE OF ARTICLE:

The information in this article is not meant to be used as the only
reference regarding which kits may or may not need to be installed
on your system.  Its primary purpose is to inform you of ECO kits
that were included in OpenVMS VAX V6.2.  It also lists kits which
were released after V6.2 that may need to be applied to your system.
This article only contains lists of kits.  It does not and is not
meant to describe which fixes are contained in these kits. For that
information, please refer to the ECO Summary Articles in the
ECO-SUMMARY Database.  This article only documents ECOs which are
directly applicable to the OpenVMS VAX operating system.  It does
not include information on every layered product or network product
that can be installed on OpenVMS VAX.


EXPLANATION OF ARTICLE FORMAT:

The tables below may include the CSCPAT number, an ECO kit version
number, and an Engineering ECO kit cross-reference.  Since ECO kits
may at times be referred to only by the Engineering cross-reference
name and since kits are revised frequently, we are providing this
information to alleviate any potential confusion which may exist
regarding the names used for the kits.

As of September 19, 1994, ECO kits are only known by an engineering
name.  These Engineering names should be used in database searches
to obtain more information about these kits.  The change to pure
Engineering names was made so that the kits will be the same for
all customers on a world-wide basis.


DISCUSSION:

The following ECO kits have been incorporated in OpenVMS VAX V6.2 and
do NOT need to be re-installed:

     -------------------------------------------------------------
     | ECO KITS Included in OpenVMS VAX V6.2                     |
     ------------------------------------------------------------|
     | VAXACRT01_061                                             |
     | VAXACRT02_061                                             |
     | VAXAUDI01_061    (CSCPAT_1164 [RETIRED])                  |
     | VAXAUDI03_061                                             |
     | VAXBACK02_060                                             |
     | VAXBACK02_061                                             |
     | VAXBACK03_U2055                                           |
     | VAXBACK4_U2055                                            |
     | VAXBOOT01_061                                             |
     | VAXCDU01_060     (CSCPAT_1117)                            |
     | VAXCDU01_U2055                                            |
     | VAXCLIU01_061                                             |
     | VAXCLIU02_U2055                                           |
     | VAXCMAR01_061                                             |
     | VAXCOPY01_061                                             |
     | VAXCXXL01_061                                             |
     | VAXDDTM01_U2055  (CSCPAT_1132)                            |
     | VAXDDTM02_061    (CSCPAT_1146)                            |
     | VAXDEBU02_061                                             |
     | VAXDECW01_060    (CSCPAT_1121 V1.1)                       |
     | VAXDECW02_060    (CSCPAT_1121 V1.2)                       |
     | VAXDECW11_U2055                                           |
     | VAXDUP01_060     (CSCPAT_1125)                            |
     | VAXDWXT01_061                                             |
     | VAXF11C02_061                                             |
     | VAXF11X03_061                                             |
     | VAXINIT03_061                                             |
     | VAXLAT02_U2055   (CSCPAT_0511)                            |
     | VAXLMF01_061                                              |
     | VAXLOAD01_061                                             |
     | VAXLOGI04_061                                             |
     | VAXMAIL02_060    (CSCPAT_1170 [RETIRED])                  |
     | VAXMAIL03_061                                             |
     | VAXMAIL05_061                                             |
     | VAXMAIL06_U2055  (CSCPAT_1123)                            |
     | VAXMONT01_061                                             |
     | VAXMOUN01_061                                             |
     | VAXNETA01_061                                             |
     | VAXPHV02_061     (CSCPAT_0608)                            |
     | VAXPHV03_060     (CSCPAT_0591)                            |
     | VAXPHV09_U2055   (CSCPAT_0606)                            |
     | VAXQMAN03_061                                             |
     | VAXRMS01_061     (CSCPAT_1181)                            |
     | VAXSCSI02_061                                             |
     | VAXSCSI03_061                                             |
     | VAXSHAD02_060    (CSCPAT_1116 [RETIRED])                  |
     | VAXSORT01_061    (CSCPAT_1187)                            |
     | VAXSYS01_061     (CSCPAT_1113 [RETIRED])                  |
     | VAXSYS02_061     (CSCPAT_1185)                            |
     | VAXSYS04_061     (CSCPAT_1182)                            |
     | VAXSYS09_U2055   (CSCPAT_1177)                            |
     | VAXSYS10_U2055                                            |
     | VAXSYS12_U2055                                            |
     | VAXSYS12_061                                              |
     | VAXSYS13_061                                              |
     | VAXSYSL01_061                                             |
     | VAXSYSL01_2H455  (CSCPAT_1173)                            |
     | VAXSYSL09_U1055  (CSCPAT_1122)                            |
     | VAXSYSL11_U1055                                           |
     | VAXSYSL17_U2055  (CSCPAT_1077)                            |
     | VAXTTDR09_U2055                                           |
     | VAXVERI02_061                                             |
     |___________________________________________________________|


The following ECO kits are NOT incorporated into OpenVMS VAX V6.2 and
may need to be installed on your system after performing an upgrade to
this version:

NOTE:  Digital recommends that these kits only be installed
       if they are *appropriate* for your site.  For example,
       an OpenVMS POSIX kit should NOT be installed unless you
       are running OpenVMS POSIX.

     ------------------------------------------------------------------
     | ECO KITS Not Included in OpenVMS VAX V6.2/May Need to Install  |
     ------------------------------------------------------------------
     | COBRTLVAXE01053                                                |
     | FORRTLVE03062 (Supersedes FORRTLVE02054, CSCPAT_1186)          |
     | VAXACRT08_062 (Supersedes VAXACRT07_062, VAXACRT06_062         |
     |                           VAXACRT05_062, VAXACRT04_062         |
     |                           VAXACRT03_062, VAXACRT02_062         |
     | VAXBADB02_070 (Supersedes VAXBADB01_070)                       |
     | VAXAUDS01_070                                                  |
     | VAXCLIU02_070 (Supersedes VAXCLIU01_070, VAXCLIU01_062)        |
     | VAXCLIU03_062                                                  |
     | VAXCLUSIO01_062                                                |
     | VAXCMAR04_062 (Supersedes VAXCMAR03_062, VAXCMAR01_062,        |
     |                           VAXCMAR01_061, VAXCMAR02_062)        |
     | VAXCXXL01_062                                                  |
     | VAXDEBU06_070 (Supersedes VAXDEBU05_070, VAXDEBU04_070,        |
     |                           VAXDEBU02_070, VAXDEBU02_061,        |
     |                           VAXDEBU01_070, VAXDEBU01_061)        |
     | VAXDDTM01_070                                                  |
     | VAXDISM01_062                                                  |
     | VAXDOSD06_062 (Supersedes VAXDOSD05_062, VAXDOSD04_062,        |
     |                           VAXDOSD03_062, VAXDOSD02_062,        |
     |                           VAXDOSD01_062)                       |
     | VAXDRIV04_070 (Supersedes VAXDRIV03_070, VAXDRIV02_070,        |
     |                           VAXDRIV01_070)                       |
     | VAXF11C01_062                                                  |
     | VAXF11X03_070 (Supersedes VAXF11X02_070, VAXF11X01_070,        |
     |                            VAXF11X02_062)                      |
     | VAXINIT01_070                                                  |
     | VAXINST01_062                                                  |
     | VAXLAVC01_062                                                  |
     | VAXLIBR05_070   (Supersedes VAXLIBR02_070, VAXLIBR01_070,      |
     |                             VAXLIBR02_062, VAXLIBR01_062)      |
     | VAXLOAD02_070   (Supersedes VAXLOAD01_070, VAXLOAD01_062,      |
     |                                            VAXLOAD01_061,      |
     |                             VAXLOAD01_061, VAXLOGI02_070,      |
     |                             VAXLOGI01_070, VAXLOGI01_062,      |
     |                             VAXLOGI04_061, VAXLOGI03_061,      |
     |                             VAXLOGI02_061, VAXLOGI01_061)      |
     | VAXMANA03_070   (Supersedes VAXMANA02_070, VAXMANA01_070,      |
     |                             VAXMANA01_062, VAXMANA02_061,      |
     |                             VAXMANA02_060, VAXMANA01_060,      |
     |                             VAXMANA01_061, VAXMANA05_U2055,    |
     |                             VAXMANA04_U2055, MANAGE$02_U2055,  |
     |                             MANAGE$03_055)                     |
     | VAXMTAA02_062  (Supersedes VAXMTAA01_062, VAXMTAA02_061)       |
     | VAXOPCO01_070                                                  |
     | VAXPHV02_062   (Supersedes VAXPHV01_062)                       |
     | VAXPRTS02_070  (Supersedes VAXPRTS01_070, VAXPRTS01_062,       |
     |                            VAXPRTS01_061, VAXQMAN02_061,       |
     |                            VAXQMAN01_061 CSCPAT_1176),         |
     |                            VAXQMAN02_060, VAXQMAN8_U2055,      |
     |                            VAXQMAN01_060  (CSCPAT_1175),       |
     |                            VAXQMAN07_U2055 (CSCPAT_1165),      |
     |                            VAXQMAN06_U2055, and previous)      |
     | VAXPTD01_070                                                   |
     | VAXQMAN02_070  (Supersedes VAXQMAN01_070, VAXQMAN01_062)       |
     | VAXRMS02_062   (Supersedes VAXRMS01_062)                       |
     | VAXSHAD05_062  (Supersedes VAXSHAD04_062, VAXSHAD02_062,       |
     |                            VAXSHAD01_062)                      |
     | VAXSYS01_062                                                   |
     | VAXSYS02_062                                                   |
     | VAXSYS03_062                                                   |
     | VAXSYS04_070   (Supersedes VAXSYS06_062, VAXSYS05_062,         |
     |                            VAXSYS04_062)                       |
     | VAXSYS05_070   (Supersedes VAXSYS01_070)                       |
     | VAXSYS06_070   (Supersedes VAXSYS02_070)                       |
     | VAXSYS07_062   (DOES NOT Supersede any other ECO kits)         |
     | VAXSYS08_062   (Does NOT Supersede any other ECO kits)         |
     | VAXSYSL02_062  (DOES NOT SUPERSEDE VAXSYSL01_062)              |
     | VAXSYSL01_070  (Supersedes VAXSYSL01_062)                      |
     | VAXUAF01_070                                                   |
     | VAXVERI01_062                                                  |
     | VSCHED_E07B021 (Supersedes VSCHED_E05B021, VSCHED_E01B021)     |
     |________________________________________________________________|


ORDERING INSTRUCTIONS:

To order a specific ECO kit, use one of the three AES (Advanced
Electronic Services) tools which are currently available.  For more
information on how to use these tools, refer to an article in the DIA
and DSNLINK databases entitled:

     [AES] How To Electronically Request ECO Kits Using Service Tools


RELATED ARTICLES:

To find articles that provide technical details on an ECO kit, use
the engineering cross-reference number (e.g., VAXDDTM02_061) or the
CSCPAT number (e.g., CSCPAT_1101) as a query in your Text Search
Application database search.
    

       Oracle Rdb V6.1A ECO 1 (aka V6.1-11) is now available on node WRVMS
    in the following location: PATCH$$:[PATCH.RDB.RDBV6111]. 
       
       The kits are also available on node NOVA: 
    NOVA::RDB_KITS:[RDBKITS61.RDBV6111KIT_%%%] where %%% is AMV, VMV, AS or VS. 
    
ALPHA MV
--------

DECRDBAMVE1A061.A;3
                       1386/1392    25-MAR-1997 10:56:43.60
DECRDBAMVE1A061.B;2
                     113148/113152  25-MAR-1997 10:56:52.37

Total of 2 files, 114534/114544 blocks.


ALPHA STD

DECRDBASE1A061.A;3     1386/1392    25-MAR-1997 11:10:43.98
DECRDBASE1A061.B;2   111510/111520  25-MAR-1997 11:10:52.74

Total of 2 files, 112896/112912 blocks.


VAX MV

DECRDBMVE1A061.A;3     1386/1392    25-MAR-1997 10:37:12.55
DECRDBMVE1A061.B;2    59913/59920   25-MAR-1997 10:37:21.80

Total of 2 files, 61299/61312 blocks.


VAX STD

DECRDBSE1A061.A;3      1386/1392    25-MAR-1997 10:47:09.59
DECRDBSE1A061.B;2     59346/59360   25-MAR-1997 10:47:18.71

Total of 2 files, 60732/60752 blocks.


Software Errors Fixed in Oracle Rdb V6.1A ECO 1
-----------------------------------------------
  -Bugchecks at PIOFETCH$WITHIN_DB + 2DC
  -RMU/RESTORE Bugchecks at FILE_CLEANUP + 72
  -Bugcheck dumps by Full Outer Join and Dbkey selection
  -Read Only Transactions Returned Incorrect Results
  -PGSPAMENT Errors from RMU VERIFY after an RMU RESTORE
  -RDO global field matching fails when SCALE is negative
  -Zigzag Match query returns wrong result on ALPHA platform
  -Correction found to possible database corruptions of indices and list data
  -Excessive SPAM fetches during a single update/insert & delete
  -Index rescanning problem in zigzag match query
  -CONVERT_ERROR or ARITH_EXCEPT from SELECT with GROUP BY when no data
     in underlying table
  -ALTER INDEX changes HASHED ORDERED to HASH SCATTERED
  -ALTER INDEX waits too long to validate storage area name
  -RDMS-E-EXCMAPLIMIT when inserting any data into a partitioned table
  -When page transfer via memory is enabled, read only transactions may
     fail with SYS-F-NOPRIV error
  -Disk Erase Control Logical Name RDM$BIND_FORCED_DISK_ERASE
  -Spam Pages Could be Incorrect after Recovery
  -Subquery of IN clause with both DISTINCT and LIMIT TO returned too few rows
  -RMU/VERIFY/ALL shows inconsistencies between indices and tables etc.
  -ARITH_EXCEPT Error When Storage Areas Added from other Node
  -COSI-F-EXQUOTA seen when creating storage map with many columns in STORE
     COLUMNS clause
  -System Bugcheck with PGFIPLHI at Image Exit - VAX Only
  -Query bugchecks in retrieving the same column by dbkey using view
  -Query loops indefinitely in optimizer compilation time
  -Bugcheck or Incorrect Data from RMU ANALYZE with START Qualifier
  -Incorrect text comparisons with BIG5 character set
  -Foreign Key constraint violation not reported when original value NULL
  -Memory leak with sort when cursor closed before end of stream
    
   Ginger Moreno
   Charles Sondey