Conference ulysse::rdb_vms_competition

86.0. "Some details..." by TAV02::ARIE () Tue Mar 08 1988 09:11

    Hi,
    
    As I know Ingres doesn't have Two-phase commit so even they
    have a real distributed d.b. you can't guarantee consistency
    of transactions.
    
    Ingres has no connection to DB2.
    
    
    Here is a document which I've recieved from marketing and I hope
it'll help you 


        Arie.
-----------------------------------------------------------------------------

   Attached is a very interesting document comparing Rdb/VMS with Ingres.  
This document was created by a group at Livermore National Labs in 
California to justify the replacement of Ingres with Rdb.  It contains a
number of points which are of interest in competitive situations and a lot 
of information which is specific to the situation a Livermore Labs.  Here
is the document in its entirety.
cheers,
Chris

From:   WINERY::BARNES "WESTERN AREA MIS/VIA ASSG  09-Sep-1987 0857"  9-SEP-1987 18:12
To:     HERON::MARSHALL
Subj:   here is the work we did at Lawrence Livermore National Labs

Supervisory Control Systems
Ingres vs. Rdb
 
 
I.  Purpose
 
The purpose of this document is to examine the desirability of
replacing the Supervisory System's existing archival database
system, Ingres, with Digital's Rdb.  The study not only compares
the two systems' effectiveness in meeting current data storage
and management requirements, it also explores which product
offers the best tools for long range data analysis.
 
 
II.  Database Uses and Requirements
 
The Supervisory Control System presently tracks several thousand
data points.  Periodically, the Control system examines about
1500 of these points and stores their values in the archival
database.  Depending upon their volatility, the Control system
samples points with differing frequency.  For example, laser
control parameters are archived every five minutes, while beam
parameters are archived every thirty seconds.  Every set of
archival data is timestamped as it is sampled.
 
For the time being, archival data is used mainly for Operational
Trending.  While operating the laser system, for example,
operators often need to display graphs showing the recent history
of various parameters.  Based upon these graphs, or "trends," the
operators make critical decisions about how to adjust the system.
Because these trends play such an important role in real time
system operations, it is essential that the database system
fulfill several basic requirements:
 
    1)  24-hour per day availability.  The system cannot be taken
        off line for maintenance without seriously damaging the
        Control System's functionality.
 
    2)  Fast response.  Operational decisions cannot wait long
        for trends to display.
 
    3)  The ability to handle large amounts of data without
        degrading retrieval speed.  The Trender program displays
        "short term trends" (100 minutes of historical data),
        "long term trends" (100 hours of data), or arbitrary
        trends (any length window).  Enough data to meet this
        diversity of demands always must be available.
 
    4)  Efficient use of disk space.  So much data is archived
        that, unless the system both allocates space
        parsimoniously and reclaims unused space, disk volumes
        will be overrun in very short order.
 
    5)  Cost-effective and efficient network processing.  The
        Supervisory System both gathers archive data throughout a
        computer network and later retrieves it for real time
        display across the network.  Unless both operations can
        be done painlessly, system performance degrades
        unacceptably.
 
Besides being used for trending, the archival data is distributed
regularly to non-Supervisory System nodes for storage and other
forms of analysis.  At present, data must be moved to other nodes
to support the PaRTs system, to provide data for Dye Pump power
integration calculations, and to relieve disk overcrowding on the
Supervisory System.  Data need not be moved continuously to
fulfill these obligations.  Every hour or every day is
sufficient. Nevertheless, these uses require that the database
system migrate large blocks of data to other nodes without
disrupting real time activity.
 
 
III.  Ingres' Failure to Meet These Requirements
 
Although Ingres was deemed best database solution in 1984,
subsequent experience has revealed a number of drawbacks in the
product.  These shortcomings are severe enough to seriously
impair Ingres' ability to meet the requirements listed in section
II above.  Over the last few years, we have developed a number of
workarounds for these difficulties, but these workarounds have
been only partially successful.  They have also required that we
develop a large amount of in-house software, which has been
difficult and expensive to maintain.  Finally, these partial
solutions are both disruptive to the Supervisory System and
chronically labor intensive.  Our dissatisfaction with the need
for workarounds, our unhappiness with the workarounds themselves,
and the overall difficulty of maintaining Ingres thus prompted
the following review.  The sections that follow compare Rdb and
Ingres in the realms of performance, maintenance and management,
network characteristics, user/programmer interfaces, and
support/licencing issues -- always in the context of the
requirements stated above.  This examination shows Rdb to be more
successful in each of these spheres, not only because it has a
newer and better design, but because it is surrounded by superior
support and auxilliary tools.
 
 
IV.  Initial Considerations -- Programming and Performance
 
Although this study was motivated by the management and
maintenance difficulties attached to making Ingres satisfy the
requirements listed in Section II, we did not consider whether
Rdb could solve Ingres' difficulties until after we had compared
performance.  After all, if Rdb could not archive data and
deliver trend displays quickly enough to make the Supervisory
System useful, any other desirable features it might have would
be irrelevant.  As a rough guide, we decided that, unless Rdb's
throughput came within about 10% of Ingres,' no further time
would be spent on the issue.
 
Since Trending is the Supervisory System's most frequently used
and most time sensitive database function, the Trender program
was the most obvious vehicle for comparing Ingres and Rdb
performance.  To conduct the test, we edited a version of the
Trender to use RDB in place of Ingres.  We also used Datatrieve
and SCAN to convert CVL archive data from an Ingres database to
an identical Rdb database.  While editing the Trender, we
discovered a significant shortcoming in Rdb, viz., the inability
of the Rdb Pascal precompiler to handle variable table and column
names.  This meant that all table and column names had to be
specified at compile time, rather than being supplied as run-time
variable data, as we are able to do with Ingres.  This is
important, since the Trender requires random access to tables and
columns in order to allow Supervisory operators to select any
trend they wish.  To temporarily circumvent this problem, we hard
coded specific tables and columns into the RDB version of the
Trender.
 
We then conducted a series of time measurements, displaying
identical trends using the two different Trenders, called by the
same screen interpreter on the same machine, using identical
databases.  The results were promising: the Rdb version
consistently ran 30-50% faster than the Ingres version.  In two
series of 20 tests, the slowest instance of an Rdb trend was
slightly faster than the fastest instance of the same Ingres
trend.
 
Encouraged by these results, we next created an interpretive
version of an Rdb Trender to handle variable table and column
names.  This approach was equivalent to executing Rdb commands at
the DCL level from within our Pascal program.  We knew in advance
that this would not be a usable solution to the random access
problem, but it was a relatively easy way to implement random
access.  We did not expect this to run very fast, and it did not.
Typically, it was 4-6 times slower than the non-interpretive
Ingres version.
 
The correct solution to the Rdb random access problem is to add
two short functions to the Trender that can make run-time
modifications to the executable code generated by the Rdb
precompiler.  These functions take the necessary table and column
names, build them into the appropriate code, and insert them into
the executable image while the program is running, just prior to
executing the database calls.  The program operates just as if it
had been hard coded, because originally it was.  The new
functions just change the "hard code" at run time to retrieve the
tables and columns we want, thus providing random access.
 
Although this sounds rather obscure, it is not.  The Pascal Rdb
precompiler genrates DSRI (DIGITAL Standard Relational Interface)
code, which is well documented and highly regular.  The two
functions to parse and reconstruct this code are correspondigly
simple.  We were able to write and test them using actual Trender
code on the real archival database in less than one day.  The two
functions together are less than 100 lines long.  Incorporating
them into the production Trenders would be a very small task,
probably totalling less than a man-week.  Because this technique
produces essentially a "hard coded" Trender, it has the
desireable side effect of producing that approaches the speed of
the test Trender that so thoroughly outperformed Ingres in the
benchmarks described above.  A series of prototype studies
confirmed this.
 
Incidentally, the Trender is the only Supervisory application
that requires random table and column access.  All of the others,
including the archivers, are hard coded to begin with and thus
will work well using the existing Pascal Rdb precompiler.  As the
testing process required us to write the code for actual
Supervisory System Rdb database calls, modifying the existing
applications at this stage would involve little more than
replacing the Ingres calls with code already written.
 
In summary, Rdb is clearly capable of outperforming Ingres as a
Supervisory System trender and archiver.  Although achieving
maximum trender performance requires a special, one-time coding
effort, the code necessary to do this was actually written during
the test effort.  Based upon the experience accumulated during
the performance comparisons, it is also clear that converting the
application code from Ingres to Rdb will not be a major effort.
 
 
V.  Maintenance and Management Issues
 
Although Ingres appears to be somewhat slower than Rdb, its most
troublesome shortcomings lie in the areas of maintenance and
management.  It is these shortcomings that have most severly
strained our ability to fulfill basic control system obligations,
and it is our attempts to overcome them that have cost us
unacceptably over the last two years.  The problem is that most
Ingres maintenance and management functions cannot be carried out
on an active database.  This presents an obvious conflict with
the Supervisory System's requirement of 24-hour per day up time.
By contrast, Rdb either tolerates these activities without
interfering with database activities or it takes care of these
matters automatically. Ingres' problems are exacerbated by the
fact that, due to several design flaws, its maintenance and
management functions must be carried out far more frequently than
is true for a product like Rdb.  Some examples include:
 
    1)  Ingres does not allow dynamic alterations in table and
        column definitions.  As data points change type or
        dimension, are added or deleted, or undergo any of the
        many other changes that regularly occur in our
        development environment, the database definitions cannot
        be changed without redirecting the archivers and trenders
        to temporary tables, disassembling the original tables
        into a flat file, altering the database definitions, and
        then reloading the tables.  Figures 1 and 2 briefly
        describe the procedures required.  Through manual
        intervention by both the Ingres Database Administrator
        and the Supervisory Operations staff, the last 100
        minutes of data can be copied to temporary tables to
        maintain partial functionality until tables are redefined
        and the data copied back, but archiving and trending
        still must be suspended completely while the databases
        are modified and data is copied in both directions.
        Furthermore, the temporary database can accommodate only
        100 minute trends while the maintenance work is in
        progress.  Depending upon the number and size of the
        tables involved, this can be very time consuming.  Rdb,
        by contrast, permits tables and columns to be redefined
        without any system disruption.
 
    2)  Ingres cannot dynamically reclaim the disk space vacated
        by deleted records and their associated indexes.  Since
        the Supervisory System archives large and ever increasing
        amounts of data, and since disk space is always at a
        premium, the Ingres Database Administrator must
        constantly monitor the system and manually reclaim space
        on a nearly daily basis.  As always, the space can only
        be reclaimed by employing a temporary database scheme
        similar to the one described above.  Reclaiming space is,
        however, much more time consuming than altering database
        definitions.  Figure 3 briefly describes the tasks
        involved.  Rdb, once again, automatically and
        continuously reclaims deleted record and index space
        without any manual intervention.
 
    3)  In order to achieve adequate trending performance, the
        Supervisory System must use Ingres' B-tree indexing
        scheme.  Since all archived data is indexed by time,
        which increases monotonically, the B-trees are always
        completely unbalanced.  These unbalanced trees exhibit
        worst-case behavior on retrieval, and this degrades
        Ingres performance within approximately 1 day after the
        trees are re-balanced.  The problem is, as always, that
        Ingres B-trees cannot be re-balanced without the usual
        database disruption and its associated involvement by the
        staff.  Rdb, on the other hand, automatically and
        constantly re-balances its B-trees, so that performance
        remains persistently optimized without any manual
        intervention.
 
    4)  Ingres provides no facility for automatic recovery in the
        event of processor failure in a VAXcluster environment.
        Even though both Ingres and Rdb allow concurrent
        multiple-processor database access, Ingres does not
        safeguard against database corruption should one cluster
        node fail but others continue.  Rdb automatically allows
        remaining cluster members to roll back the failed node's
        incomplete transactions and then continue.  In addition,
        Rdb provides optional after-image journaling to further
        protect the integrity of the VAXcluster database.
 
In sum, Ingres' maintenance and management problems make it
difficult to meet the requirements of 24-hour per day up time,
good database performance, and efficient use of disk space.  Work
arounds for these difficulties are both disruptive and time
consuming.  By virtue of its different design, Rdb appears to
overcome these problems.  In addition, Rdb is more completely
suited to a VAXcluster environment.
 
 
VI.  Network Issues
 
Other Ingres' design problems interfere with its ability to meet
the requirements of migrating data efficiently to other nodes and
of making efficient use of the network in general.
 
The only mechanism currently available for migrating Ingres data
to non-Supervisory System nodes is our "Roll Out Procedure."  The
Roll Out Procedure is a locally developed data distribution tool
used to move older data off the Supervisory System so that it may
stored and analyzed without overloading the Supervisory System.
Although a database management tool of this type seems somewhat
fundamental, LIS had to develop this program locally because
Ingres does not supply one.  Although the Computer and
Communications Section invested significant effort in writing the
Roll Out Procedure, the program never became a mature, automatic
data distribution product.  The program remains very specialized,
it has occasionally misbehaved, and the original author is no
longer available to maintain it.  The gyrations necessary to
effect a roll out are described in the attached "Present Demo85
Database Management Procedures."  To bring this program up to par
with commericial data distribution products would require a
significant effort, probably measured in man years.
 
If Rdb were chosen as the Supervisory System database, this
problem could be eliminated using Digital's VAX Data Distributor.
VAX Data Distributor provides for automatic distribution of an
Rdb database, at user-defined intervals, by either
 
    1)  Extracting all or part of the database across the network
        to create an independent copy at a new location(s).  This
        technique is similar to a backup, except that the
        extracted database is a fully usable Rdb database, which
        may be changed and manipulated without any effect upon
        the original.  This facility could be used each day to
        extract all data older than a certain interval, thus
        replacing the current Roll Out Procedure.  Similarly, all
        data from a particular test run could be extracted to a
        non-Supervisory System node, for detailed analysis.
        Since the extracted databases carry with them all
        database definitions, data from any time period would
        always be available in its correct format, even if the
        active Supervisory System database had since changed.
        The existing Roll Out Procedure has to be changed each
        time the database changes, so it is unclear whether it
        actually can be used to restore and examine old data.
 
    2)  Replicating all or part of the database on new node(s) by
        transmitting database changes to the new node(s).  This
        method functions using a master-slave(s) relationship, in
        which one master (read/write) database reproduces some or
        all of its changes in one or more (read only) slave
        databases.  The changes are transmitted to the slave
        databases at user definable intervals, according to user
        definable selection criteria.  This technique could be
        especially useful, both in distributing database
        processing across the Supervisory System and in enhancing
        response for critical database uses.  By keeping the last
        100 minutes of data current in small databases on all of
        the nodes that drive screens, for example, this method
        could enable all short term trends to be performed
        without the overhead of realtime network access.
 
The advantages of Digital's Data Distributor are many: it is a
general purpose database management tool allowing numerous
database manipulation strategies. It is a supported product, it
is easy to use and change, and its use would free personnel
resources for other tasks.  It offers data migration strategies
that are clearly superior to anything possible with Ingres.
 
In addition to lacking a good data migration tool, Ingres handles
its individual network database transactions inefficiently.  To
execute each application program's reads or writes over a
network, Ingres must create both a front-end process on the
application's node and a back-end process on the node where the
database resides.  When there are a large number of Ingres
applications, network Ingres will thus proliferate processes
excessively.  For example, a fully-loaded Supervisory System
node -- one that both communicates with GEMs and drives screens
-- will have 8 to 10 applications.  These applications will, in
turn, create 16 to 20 more processes just to communicate their
Ingres data.  This is problematic not only because it consumes so
much memory and other resources, but also because it creates so
much competition for processor time.  The Supervisory System
operates only one Ingres database for the entire network.  As a
consequence, all of the system's back-end process concentrate on
a single node, where they compete for that single processor.  It
turns out that the Ingres front-end processes do little more than
spawn the back-ends and wait for data to be returned.  The
back-ends actually do all of the Ingres processing.  Almost all
of the Supervisory System's Ingres processing thus occurs on a
single node.  Despite the fact that this node is the fastest
processor in the Supervisory System, it is already badly
overloaded.  As the system grows, Ingres' concentration of
processing will progressively degrade overall performance.
 
Applications performing Rdb network operations achieve their
database access via an Rdb server process on the node accessing
the database.  This differs from the Ingres approach in two ways.
First, it eliminates the front-end processes altogether, cutting
process proliferation in half and eliminating a major burden from
the nodes where Supervisory applications run.  Second, although
the Rdb server process looks something like an Ingres back-end,
it has two major advantages.  First, when returning the data
after the database access is complete, the server process
packages records into the smallest possible number of network
packets.  Second, in a VAXcluster environment, the server
processes can be distributed among all of the processors in the
cluster, thus eliminating the need for all processes to compete
for a single cpu.
 
 
VII.  User/Programmer Interface
 
The archiving system was created not only to support trending but
also to maintain a comprehensive record of the state of the laser
system.  The trends are used mainly by the Supervisory Operations
Staff, and their principal requirements for these predefined
database retrievals are availability and speed.  Bearing in mind
all that problems already mentioned, the present system has
nevertheless served this purpose better than any others.
 
On the other hand, it has always been hoped that project
physicists, engineers, designers, and managers also might make
use of the comprehensive data archive, to review events following
test runs, for example, or to reduce data for progress reports.
Unlike the operators, these "higher level" users take an ad hoc
approach to the data, in which they form their own, highly
individualized data queries.  Unfortunately, these users tend not
to be sophisticated computer users, and, even if they were, they
would not wish to spend their time writing software to get at
data.  To make data available to them, therefore, the data base
system must have easily approachable data manipulation tools.  In
this realm, flexibility in designing queries is far more
important than performance.  Ideally, these tools also should
permit easy integration with other data analysis products
available on the users' PCs.
 
Because Ingres is so thoroughly lacking in such tools, the
Supervisory System archive has until now almost never been used
for higher level analysis.  Ingres does have a powerful set of
query tools, but they are so user unfriendly that they can really
only be used by a trained Ingres programmer.  To make matters
worse, Ingres has no data dictionary to make its data definitions
easily available to programs or other tools.  Thus, even if
someone were willing to write software to approach the archive
data, he would face the cumbersome task of recreating the entire
database definition in his program.
 
Rdb, on the other hand, is accompanied by many powerful and user
friendly information management tools.  For example, VAX Teamdata
is a powerful, easy to use information management facility for
those who need to use data in their work, but don't want to do
"data processing."  TEAMDATA lets users store and modify data,
using a screen-oriented, text-editing style.  TEAMDATA also
allows users to manipulate their personal data, as well as shared
or remote databases, in simple tables, spreadsheets, reports, and
graphs, and to perform complex queries and data reduction
operations.  TEAMDATA users can do all of these things by
selecting items from strip menus, using the command language, or
a combination of the two.  TEAMDATA, using VAX XWAY, also can
export and import data in the following storage formats:  DIF -
Data Interchange Format (used by products such as VisiCalc and
SuperCalc), SYLK - Symbolic Link File Format (used by products
such as Multiplan), WKS - Worksheet Format (used by products such
as LOTUS 1-2-3), VAX DECalc dump file format, and ASCII tabular
data with a specified separator (e.g. tabs, spaces, commas,
hyphens) between each data element (used by products such as
dBASE III, Supercomp-Twenty, 20/20, C-CALC).
 
VAX RALLY also provides a powerful 4th Generation environment for
developing applications.  As an integrated package, RALLY
provides the tools necessary to construct Rdb/VMS databases,
forms, reports, menus, and online HELP for the application user.
Application developers can use RALLY's menu interface and
extensive defaulting capabilities to create simple applications
quickly.  More sophisticated applications can be constructed in
the RALLY editing environment.  Furthermore, Rdb does have a data
dictionary available through Digital's Common Data Dictionary.
The CDD is technology of long standing, which makes all Rdb
definitions immediately available to Datatrieve, to user
application programs in almost any language, and to many other
tools as well.  By allowing data specifications and definitions
to be shared by multiple applications, the CDD simplifies
maintenance and encourages information sharing.
 
With Rdb's auxilliary tools available, the Supervisory System's
archival data very likely would be more extensively used than it
is today.
 
 
VIII.  Support/Licensing Issues  --  Rdb vs. Ingres
 
In the areas of licensing and support, Ingres also has been
difficult.  One problem is that Ingres' parent company, RTI,
distributes only full installation kits.  Even though disk space
is chronically short on Supervisory System machines, and even
though the most Supervisory System nodes make use of only a tiny
fraction of the Ingres software, LIS must nevertheless install
the full 40,000 block kit on every single node.  LIS has, on its
own, subsequently deleted files that it does not believe it
needs, but this technique is in no way supported by RTI.
Furthermore, these files cannot be deleted on full-function
nodes, where the Ingres system files alone occupy about 50,000
blocks.  RTI also requires that quite a few systems have
full-function licenses, including the archive node on both the
LDF production Supervisory System, the archive node on the test
system, the development node (VAXR), and the PaRTs node (VAXT).
Aside from consuming a lot of disk space, this requirement boosts
the cost of Supervisory System Ingres licenses to approximately
$55,000.
 
Rdb overcomes these problems by being available in three
varieties, a full (development) version, a run-time only version,
providing all facilities except language precompilers and data
definition commands, and a remote applications version, allowing
only access to Rdb databases on remote nodes.  The latter two
permit application programs that have been developed on a
fully-licenced machine to run on target machines with smaller Rdb
system files and less expensive licences.  Fortunately, all of
the Supervisory System machines, as well as the test system,
could operate fully with these smaller and less expensive
versions.
 
What kind of savings would this represent?  In the first place,
the three Rdb versions occupy only 9,200, 5,600, 3,700 blocks,
respectively, for execution, and the installations kits are even
smaller.  On the development, production, PaRTs, and test
systems, therefore, the Rdb system files would occupy about
180,000 blocks less than their Ingres equivalents.  Furthermore,
Rdb would require a full licence on only the development node,
VAXR, and perhaps the PaRTs node, VAXT.  All other nodes could
function fully with just the remote application licence, except
for VAXE, VAXU, and perhaps VAXD, which would need the run-time
only licence.  Rdb licences for the test and production systems
thus would list at only $20,500 -- 63% less than the Ingres
equivalent -- and this does not take into account the Lab
discounts, which normaly take 20-50% off the Digital list price.
While it is true that the Ingres licences already have been
purchased and cannot be returned, Rdb clearly offers the less
expensive option for a plant design.
 
Installation itself also has been a source of difficulty, in that
it requires a person who knows both the history of our
application and the details of our network get Ingres up and
running.  As an example, RTI recently provided a patch to the
Ingres backend which is essential to achieving satisfactory
system performance.  To date, the product updates do not include
this "fix," and it is not documented.  The system manager or any
others responsible for installing an update simply have to
"know" that the patched backend must be saved and reinstalled
each time to avoid losing its functionality.
 
Once installed, Ingres is activated on a system by means of an
"authorization string," which "opens" Ingres if the string
properly corresponds to the System ID (SID) for which Ingres has
been licensed.  Unfortunately, if a Supervisory System node's
configuration changes, or if the processor has to be swapped for
repair, the SID changes and Ingres ceases to function.
 
Finally, LIS has had frequent difficulty over the last two years
communicating specific performance or functionality problems to
RTI.  For example, LIS noticed a chronic problem with corrupted
Ingres data approximately 18 months ago, which RTI fixed only
very recently.  LIS staff spent most of that time trying to
convince RTI that there really was a problem.  Although technical
support response has greatly improved since then, the lack of
on-site support has hindered problem solving.  Rdb, on the other
hand, is a standard, supported Digital product.  Its installation
is accomplished the standard Digital product installation
procedure, with which the LIS system managers are familiar.
Telephone hotline support is available for the product 24-hours
per day, and Digital personnel are resident on site to expedite
problem resolution.
 
 
IX.  Other Considerations
 
Rdb is already a part of LIS, and rapidly is becoming part of the
Supervisory System itself.  As a result, significant parts of the
licensure needed for changing the Supervisory System to a full
Rdb implementation already are in place.  From the start, the EDS
group has used Rdb/VMS to support the real time distributed
database functions in its VAX/ELN-based GEMs.  Rdb/VMS not only
stores the definitions for EDS's run-time ELN databases but also
stores all initial values for these databases.  Because Rdb
support tools were rather limited when EDS began to use the
product, EDS developed two local programs to help use the Rdb
system.  The "Configuration Manager" creates and manages the
contents of the Rdb database, and the "Object Allocator" extracts
the definitions stored in Rdb and constructs a memory-based ELN
equivalent.  EDS applications programs are linked to the
memory-resident database, along with a set of simple data
manipulation routines.
 
Recently, the LDF Control Systems group began to develop a
variation of the EDS GEMs for use in the Supervisory System's new
microVAX-based GEMs.  This necessitated purchase of a full Rdb
licence on VAXR, which could be used without further cost for all
Rdb development that would be involved in converting the archival
database system from Ingres to Rdb.  The LDF Control Systems
group quickly realized, however, that VAX Rally would provide a
far easier and more functional database interface than the two
EDS programs mentioned above.  The EDS programs suffer from the
following limitations:
 
    1)  In-house software requires in-house maintenance.
 
    2)  The Configuration Manager is not user friendly.
 
    3)  Modifying the database definitions requires recompiling
        and relinking major portions of the system.
 
    4)  Only the simplest database queries are possible.
 
Tim Sherman actually duplicated 80-90% of the Configuration
Manager and Object Allocator functionality in one morning, using
Rally, and this was accomplished with no training other than
reading the Rally manual for an evening and experimenting for a
few hours.  The final Rally product will have none of the
shortcomings listed above, will provide significantly more
functionality than the locally developed programs, and will serve
for all similar microVAX-based GEMs that ultimately become part
of the Supervisory System.  Rdb and Rally thus will become part
of the Supervisory System regardless of whether the archival
system remains an Ingres application.  For the long run, however,
it might be more efficient to unify all database functions under
a single system.
 
 
X.  Conversion.
 
Conversion of existing Ingres databases to Rdb databases will not
be a major task, as evidenced by our experience in generating an
Rdb archive for the prototype Trender.  To create the test
database, Robert Barnes of Digital first used a VAX SCAN program
to parse the Ingres database definitions and create an equivalent
Rdb database definition.  Next, the Ingres Database Administrator
dumped the Ingres data into ASCII files using standard Ingres
utilities.  The ASCII data were then loaded into Rdb using
Datatrieve.  This entire operation was accomplished within one
day, despite the fact that Mr. Barnes had no familiarity with
either the Ingres database or of Supervisory Operations in
general.  The same procedure can, if necessary, be used to move
data in either direction between the two systems.
 
                                            James Beattie
                                            Rich Ward
 
                                            September 3, 1987
 
========================================================================