[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEC Rdb against the World |
|
| Moderator: | HERON::GODFRIND |
|
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
377.0. ""major features of Rdb" sales support document" by SNOC02::ANDERSONK (The Unbearable Lightness of Being) Tue Jun 27 1989 15:11
What follows is SDML source (VAX DOCUMENT) that describes features of
Rdb/VMS. I pulled together some pieces from this and other notes
files and from reading manuals to make this up. It is intended to
be a document that highlights major features of Rdb/VMS briefly
with references to supporting manuals. This seems to be a useful
thing to do in a sales support situation.
I was processing it as a REPORT under DOCUMENT.
I welcome comments, corrections etc..
Regards, Keith Anderson
PS: This document was not sponsored by DBS. This document has not
been officially checked or approved. I hope that maybe one day soon
I will find out how to get that done. ceveat empor (spelling?) :-)
<FRONT_MATTER>(Front-matter)
<TITLE_PAGE>
<TITLE>(Major Features of Rdb/VMS)
<ABSTRACT>(April 24th, 1989)
This document is intended as a reference to introduce significant features of
DIGITAL's relational database management system VAX Rdb/VMS and the
DIGITAL Standard Relational Interface software architecture.
<ENDABSTRACT>
<AUTHOR>(<EMPHASIS>(Keith Anderson\ITALIC)\
<EMPHASIS>(Canberra Software Services\ITALIC)\
<EMPHASIS>(Digital Equipment Corporation (Australia)\ITALIC))
<p>
<ENDTITLE_PAGE>
<COPYRIGHT_PAGE>
<PRINT_DATE>(April, 1989)
<COPYRIGHT_DATE>(April, 1989)
<ENDCOPYRIGHT_PAGE>
<CONTENTS_FILE>
<PREFACE>(-5)
<HEAD1>(Structure of the Document)
The document is divided into two main parts:
<LIST>(UNNUMBERED)
<LE>Introduction and executive summary.
<LE>Detailed chapter on Rdb/VMS database management system, that provides
information, and pointers to documentation, relevant to each selection criteria.
<ENDLIST>
<HEAD1>(Related Manuals\RelatedManuals)
This document refers to a number of manuals on Digital products, especially
the following:
<LIST>(UNNUMBERED)
<LE><EMPHASIS>(<REFERENCE>(RdbIntro))
<LE><EMPHASIS>(<REFERENCE>(RdbGuideDesign))
<LE><EMPHASIS>(<REFERENCE>(GuideMaintPerf))
<LE><EMPHASIS>(<REFERENCE>(RdbGuideProg))
<LE><EMPHASIS>(<REFERENCE>(RdbGuideManip))
<LE><EMPHASIS>(<REFERENCE>(RdbRefManual))
<LE><EMPHASIS>(<REFERENCE>(SQLRefManual))
<LE><EMPHASIS>(<REFERENCE>(SQLUserGuide))
<LE><EMPHASIS>(<REFERENCE>(RDMLRefManual))
<LE><EMPHASIS>(<REFERENCE>(CDDRefManual))
<LE><EMPHASIS>(<REFERENCE>(CDDUsersGuide))
<LE><EMPHASIS>(<REFERENCE>(RallyIntro))
<LE><EMPHASIS>(<REFERENCE>(RallyRefManual))
<ENDLIST>
<p>
The following books provide related information:
<LIST>(UNNUMBERED)
<LE><EMPHASIS>(<REFERENCE>(VAXInfo_Summary))
<LE><EMPHASIS>(<REFERENCE>(VAXsetBook))
<LE><EMPHASIS>(Introduction to Database Development)
<ENDLIST>
<ENDPREFACE>
<ENDFRONT_MATTER>
<DEFINE_SYMBOL>(VAXInfo_Summary\VAX Information Architecture Summary Description)
<DEFINE_SYMBOL>(GuideMaintPerf\VAX Rdb/VMS Guide to Database
Maintenance and Performance)
<DEFINE_SYMBOL>(RdbGuideDesign\VAX Rdb/VMS Guide to Database Design and
Definition)
<DEFINE_SYMBOL>(RdbRefManual\VAX Rdb/VMS Reference Manual)
<DEFINE_SYMBOL>(SQLRefManual\VAX SQL Reference Manual)
<DEFINE_SYMBOL>(SQLUserGuide\VAX SQL User's Guide)
<DEFINE_SYMBOL>(RdbGuideManip\VAX Rdb/VMS Guide to Data Manipulation)
<DEFINE_SYMBOL>(RdbGuideProg\VAX Rdb/VMS Guide to Programming)
<DEFINE_SYMBOL>(RdbIntro\VAX Rdb/VMS Introduction and Master Index)
<DEFINE_SYMBOL>(RDMLRefManual\VAX Rdb/VMS RDML Reference Manual)
<DEFINE_SYMBOL>(CDDRefManual\VAX CDD/Plus Common Dictionary Operator Reference
Manual)
<DEFINE_SYMBOL>(CDDUsersGuide\VAX CDD/Plus User's Guide)
<DEFINE_SYMBOL>(RallyIntro\Introduction to VAX RALLY)
<DEFINE_SYMBOL>(RallyRefManual\VAX RALLY Reference Manual and Master Index)
<DEFINE_SYMBOL>(RdbSPD\Software Product Description for VAX Rdb/VMS
Version 3.0 (SPD 25.59.08))
<DEFINE_SYMBOL>(DTRSPD\Software Product Description for VAX Datatrieve
Version 4.2 (SPD 25.44.20))
<DEFINE_SYMBOL>(RallySPD\Software Product Description for VAX RALLY
Version 2.0 (SPD 27.03.02))
<DEFINE_SYMBOL>(TeamdataSPD\Software Product Description for VAX TEAMDATA
Version 1.3 (SPD 27.02.03))
<DEFINE_SYMBOL>(XwaySPD\Software Product Description for VAX Xway
Version 1.1 (SPD 27.36.02))
<DEFINE_SYMBOL>(Allin1SPD\Software Product Description for VAX ALL-IN-1
Version 2.2 (SPD 27.30.02))
<DEFINE_SYMBOL>(CDDSPD\Software Product Description for VAX CDD/Plus,
Version 4.0 (SPD 25.53.16))
<DEFINE_SYMBOL>(VAXsetBook\A Methodology for Software Development Using VMS
Tools)
<CHAPTER>(Choosing a Software Architecture\Choosing_Architecture)
<HEAD1>(Executive Overview)
<P>
DIGITAL believes it has the architectures and products to support the business
needs of many customers now and into the future.
<p>
DIGITAL believes in the importance of architectures and standards to develop
and maintain applications environments, in both software and hardware.
Architectures and standards provide a stable, consistent platform for software
and hardware evolution. They also provide optimum growth paths for the future,
integration, consistency, and permit the growth of performance and
functionality.
<p>
DIGITAL recommends the following architectures for special consideration:
<LIST>(UNNUMBERED)
<LE>DIGITAL Standard Relational Architecture (DSRI) and Rdb/VMS
<p>
<EMPHASIS>(These provide a solid foundation for data management, well
integrated with development and management tools, with open interfaces for
4GL and other tools.\ITALIC)
<LE>VAX Information Architecture (VAX)
<p>
<EMPHASIS>(This architecture describes a well-integrated product set based
on an active data dictionary that
addresses the needs of commercial information management.\ITALIC)
<LE>DECtp Architecture for distributed commercial transaction processing
<p>
<EMPHASIS>(This new architecture describes DIGITAL's intentions in the
OLTP environment.\ITALIC)
<LE>DECwindows and X-Windows
<p>
<EMPHASIS>(These new architectures describe functionality on the desktop
that integrate applications using a very powerful user interface based on
the windows way of working.\ITALIC)
<LE>Compound Document Architecture
<p>
<EMPHASIS>(This new architecture describes the operation of shared active
documents in a distributed environment, including DECwindows.\ITALIC)
<LE>DIGITAL Network Architecture and DECnet Phase V (including DECnet/OSI)
<p>
<EMPHASIS>(This architecture describes DIGITAL's intentions in the
networking environment.\ITALIC)
<ENDLIST>
<p>
<HEAD1>(Recommendations)
<P>
The following phased approach is useful for evaluating DIGITAL's solutions:
<LIST>(NUMBERED)
<LE>Business Needs Analysis
<P>
The needs should be
written down in a well defined manner and used to achieve mutual
concurrance on goals and objectives, both internally and externally.
<le>Applications Architecture
<P>
In a phased approach, a general applications architecture must first be
constructed to match the needs analysis. This architecture can be used to rank
requirements.
<LE>Strategic Product Sets
<p>
Often an architecture review will show that one or two software and/or
hardware product sets are critical to the success of the architectures. In the
DIGITAL VAX/VMS applications environment, the strategic product sets are:
<LIST>(UNNUMBERED)
<LE>the database management product set known as Rdb/VMS (it has several
utilities and products bundled, and is a core component of the VAX Information
Architecture),
<LE>the active data dictionary CDD/Plus (the other core component of VAX
Information Archiecture with Rdb/VMS),
<LE>the new DECwindows workstations software and hardware products, provides a
revolutionary way of integrating applications on the desktop,
<le>DECnet networking product set, such as Distributed Name Services.
<ENDLIST>
<p>
Many current DIGITAL (and third-party) software products are already based on,
or will add interfaces to, these products. New products will typically have
interfaces with one or more of these strategic products. Computer Assisted
Software Engineering products, DECtp products, end-user tools, data analysis
and management tools are all increasingly layered on these strategic products.
<p>
These strategic products would be evaluated prior to further detailed analysis
of products.
<LE>General, Specific Application and Product Review
<p>
Evaluate what products, packages and applications software exists to solve
general and specific applications needs. This evaluation is best performed
when a satisfactory understanding has been reached of the core strategic
products.
<ENDLIST>
<NOTE>(Document Content)
The rest of this document:
<LIST>(UNNUMBERED)
<LE>Describes the prototype application.
<LE>Suggests selection criteria for choosing applications architectures and
database architectures.
<LE>In summary format, describes the characteristics of DIGITAL's offerings in
terms of the database selection criteria and provides detailed references for
further reading. The database was chosen as being the most strategic product
for evaluation at this stage of the applications evaluation.
<ENDLIST>
<ENDNOTE>
<CHAPTER>(RDBMS Selection Criteria\Rdb_CRITERIA)
<comment>
<RUNNING_TITLE>(<emphasis>(RDBMS Selection Criteria))
<endcomment>
Choosing a database management system can be a complex task. DIGITAL feels
that VAX Rdb/VMS is the best relational database management system available
for the VAX/VMS environment.
<p>
<HEAD1>(Summary of Selection Criteria)
<P>
The following criteria are most commonly applied when choosing a relational
database management system (RDBMS). The list is not ranked by any order of
importance as the importance varies from application to application:
<LIST>(UNNUMBERED)
<le>Architected
<LE>Performance
<LE>High Availability
<le>Ease of Management
<LE>Ease of Use
<LE>Data Integrity
<LE>Functionality
<LE>3GL Integration
<LE>4GL Integration
<LE>Integration and Support of Environment
<LE>Operating System Integration
<LE>Hardware Integration
<LE>Networking Integration
<LE>Cost
<LE>Vendor Support
<LE>Documentation
<LE>Training
<LE>Standards
<le>Open Interfaces
<le>Third-Party Applications and Packages
<le>Marketplace Acceptance
<le>Distributable
<ENDLIST>
The rest of this chapter will address some of these issues with DIGITAL's
Rdb/VMS and DSRI in mind.
<HEAD1>(Introduction to Rdb/VMS and DSRI)
<P>
VAX Rdb/VMS is a full-function relational database
management system designed for the VMS
Operating System. It is intended for general purpose,
multi-user, centralized or distributed applications.
<P>
VAX Rdb/VMS supports a complete set of utilities
and precompilers that enable users to maintain
and manipulate databases. VAX Rdb/VMS includes a
VAX SQL component, Digital's implementation of the
Structured Query Language, an ANSI standard interface
to relational database products.
<P>
VAX Rdb/VMS implements the DIGITAL Standard Relational
Interface (DSRI). DSRI is an architecture for
relational database management systems, as well as
a standard calling mechanism that can be used for
DSRI database creation and population. DSRI allows
applications running on any VAX or MicroVAX node in
a DECnet network to access all other DSRI-compliant
databases in the network.
<HEAD1>(Availability)
<p>
Availability of a DBMS is usually restricted by the
functionality of backups, implementation of definition
changes, need for file or data restructuring, and some DBMS's
are restricted by their degree of fault-tolerance. VAX
Rdb/VMS has few restrictions and provides a high availability
RDBMS.
<HEAD2>(High Availability)
<HEAD3>(Online Backups)
<p>
<EMPHASIS>(Rdb/VMS has online backup, based upon the structure of an
Rdb database for greater speed, which permits the database to be
backed up while in use. Rdb/VMS also has online incremental
backup, which increases backup speed and ease of maintenance by
reducing the amount of data that needs to be backed-up.\BOLD)
This functionality is often not available in older database
management systems.
Refer to
Section 5.2 "Backing Up a Database", and subsections, in the
<emphasis>(<reference>(GuideMaintPerf)).
<p>
<EMPHASIS>(Digital's Rdb/VMS can provide the fastest and most reliable
backup capabilities of any database system on the VAX.\BOLD)
Multiple areas can be backed-up at the same time,
concurrently streaming three tape drives. Refer to Section 5.2.6.2
"Using Multiple Tape Drives" in the
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD3>(VAXcluster and Network Wide Automatic Recovery)
<p> Rdb has had fault-tolerance in a VAXcluster environment since 1985, so
that it can survive if a CPU goes off-line and automatically handles
recovery and rollback, and also if a HSC node fails.
<p> Refer to Section
15.8 "The Automatic Recovery Procedure" in the
<emphasis>(<reference>(GuideMaintPerf)), and the
<emphasis>(<reference>(RdbSPD)).
<HEAD3>(Automatic Housekeeping\AutomaticDBA)
<p>
The following activities are automatically performed by the database
online, whilst users are active:
<LIST>(UNNUMBERED)
<LE>Re-use of freed space in database storage area files and snapshot files
<LE>Creation, extension and/or deletion of a users Recovery-Unit Journal
file as required
<LE>Extension of any storage area files, as required
<LE>Extension of After-Image Journal file, as required
<LE>Recovery of any aborted transactions
<LE>Changing locking granularity of a user, as required
<LE>Deadlock detection
<LE>Updating approximate cardinality of relations and indices, as
appropriate
<LE>Grouping of Commits and After-Image Journal data for efficiency
<ENDLIST>
<HEAD3>(Online DBA Activities\ONLINE_section)
<p>
The following activities can be performed online, whilst users are active,
and can be done either interactively or in batch:
<LIST>(UNNUMBERED)
<LE>Online backup of database, either full backup or incremental, using
the RMU utility.
<X>(Online>backups>database)
<LE>Online spooling of After-Image Journal file (i.e. truncate and backup
contents of After-Image Journal file), using the RMU utility or RDO SPOOL
command.
<X>(Online>backups>After-Image Journal)
<LE>Monitoring and recording performance statistics, using the RMU
utility, either interactively or in batch. Display is usually only done
interactively.
<X>(Online>statistics)
<LE>Dump of any database area (eg header, indices, data areas), using RMU.
<X>(Online>dump)
<LE>Change OPEN MODE of database, using RDO CHANGE DATABASE or SQL ALTER
SCHEMA command (see <REFERENCE>(Changing_DB_Chars\FULL) for pointers to
documentation).
<LE>Start a RMU /VERIFY check of database integrity (will wait for
EXCLUSIVE and BATCH_UPDATE transactions to complete).
<ENDLIST>
<HEAD3>(Changing Database Characteristics Online)
<p>
All of the following DBA activities can be performed using interactive
utilities (either RMU, and/or Interactive RDO and/or Interactive SQL).
<X>(Online>Changing characteristics\ITALIC)
<p>
Refer to:
<LIST>(UNNUMBERED)
<LE>Section 7.1 "Changing Database Characteristics"
<LE>Section 7.2 "Adding New Storage Areas"
<LE>Section 7.3 "Changing and Deleting Storage Areas"
<LE>Section 7.4 "Changing and Deleting Storage Indexes"
<LE>Section 7.5 "Changing and Deleting Storage Maps"
<ENDLIST>
in the <emphasis>(<reference>(GuideMaintPerf)).
<HEAD4>(Changes With Active Users)
<p>
The following sub-sections describe the various changes that can be made
online while users are active on the database.
<HEAD5>(Global Fields (Domains))
<P>
Global field definitions (domain definitions) can be defined, changed or
deleted using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database (other users can be attached).
Changes can be made through Interactive RDO, Callable RDO, Interactive
SQL, precompiled SQL, a procedure in a SQL Module, or through Dynamic SQL.
Refer to:
<LIST>(UNNUMBERED)
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.4 "CHANGE FIELD Statement"
<LE>Section 6.16 "DEFINE FIELD Statement"
<LE>Section 6.26 "DELETE FIELD Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.1 "ALTER DOMAIN Statement"
<LE>Section 4.10 "CREATE DOMAIN Statement"
<LE>Section 4.25 "DROP DOMAIN Statement"
<ENDLIST>
<ENDLIST>
<HEAD5>(Relations (Tables))
<P>
Relation definitions (table definitions) can be defined, or changed
using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database (other users can be attached).
Definitions and changes can be made through Interactive RDO, Callable RDO,
Interactive SQL, precompiled SQL, a procedure in a SQL Module, or through
Dynamic SQL. Refer to:
<LIST>(UNNUMBERED)
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.7 "CHANGE RELATION Statement"
<LE>Section 6.19 "DEFINE RELATION Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.5 "ALTER TABLE Statement"
<LE>Section 4.15 "CREATE TABLE Statement"
<ENDLIST>
<ENDLIST>
<HEAD5>(Protections)
<P>
Access Control List definitions can be defined, changed or
deleted using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database (other users can be attached).
Changes can be made through Interactive RDO or Callable RDO.
Interactive SQL, precompiled SQL, a procedure in a SQL Module, or through
Dynamic SQL. Refer to:
<LIST>(UNNUMBERED)
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.6 "CHANGE PROTECTION Statement"
<LE>Section 6.16 "DEFINE PROTECTION Statement"
<LE>Section 6.26 "DELETE PROTECTION Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.41 "GRANT Statement"
<LE>Section 4.51 "REVOKE Statement"
<ENDLIST>
<ENDLIST>
<HEAD5>(Constraints)
<P>
Constraint definitions can be defined or
deleted using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database (other users can be attached).
Changes can be made through Interactive RDO or Callable RDO,
Interactive SQL, precompiled SQL, a procedure in a SQL Module, or through
Dynamic SQL. Refer to:
<LIST>(UNNUMBERED)
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.14 "DEFINE CONSTRAINT Statement"
<LE>Section 6.24 "DELETE CONSTRAINT Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.5 "ALTER TABLE Statement"
<LE>Section 4.15 "CREATE TABLE Statement"
<ENDLIST>
<ENDLIST>
<HEAD4>(Changes With No Database Users)
<p>
The following sub-sections describe the various changes that can only be
made online while no users are active on the database. Some require the
DBA to be the only user of the database, while for others even the DBA
must not have invoked the database.
<HEAD5>(Deleting Relations (Tables))
<P>
Relation definitions (table definitions) can be deleted
using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database with NO other active users attached.
Deletes can be made through Interactive RDO, Callable RDO, Interactive
SQL, precompiled SQL, a procedure in a SQL Module, or through Dynamic SQL.
Refer to:
<LIST>(UNNUMBERED)
<LE>Section 6.30 "DELETE RELATION Statement" in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC).
<LE>Section 4.30 "DROP TABLE Statement" in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC).
<ENDLIST>
<HEAD5>(Indexes)
<P>
Index definitions can be defined, changed, or
deleted using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database, only with NO active users.
Defines, changes and deletes can be made through Interactive RDO, Callable
RDO, Interactive SQL, precompiled SQL, a procedure in a SQL Module, or
through Dynamic SQL. Refer to:
<LIST>(UNNUMBERED)
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.5 "CHANGE INDEX Statement"
<LE>Section 6.16 "DEFINE INDEX Statement"
<LE>Section 6.27 "DELETE INDEX Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.2 "ALTER INDEX Statement"
<LE>Section 4.11 "CREATE INDEX Statement"
<LE>Section 4.26 "DROP INDEX Statement"
<ENDLIST>
<ENDLIST>
<HEAD5>(Storage Maps)
<P>
Storage Map definitions can be defined, changed, or
deleted using RDO or SQL statements, within a READ_WRITE
transaction on the relevant database with no other users attached.
Changes can be made through Interactive RDO, Callable RDO, Interactive
SQL, precompiled SQL, a procedure in a SQL Module, or through Dynamic SQL.
Refer to:
<LIST>(UNNUMBERED)
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.8 "CHANGE STORAGE MAP Statement"
<LE>Section 6.21 "DEFINE STORAGE MAP Statement"
<LE>Section 6.32 "DELETE STORAGE MAP Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.4 "ALTER STORAGE MAP Statement"
<LE>Section 4.14 "CREATE STORAGE MAP Statement"
<LE>Section 4.29 "DROP STORAGE MAP Statement"
<ENDLIST>
<ENDLIST>
<HEAD5>(Major Database Characteristics\Changing_DB_Chars)
<p>
No users can attach to the database when a RDO CHANGE DATABASE (or SQL
ALTER SCHEMA) command is issued, and the DBA also cannot have the database
invoked, with the exception of the OPEN IS MANUAL or OPEN IS AUTOMATIC
options. The following activities are performed by RDO CHANGE DATABASE
(and/or SQL ALTER SCHEMA) commands:
<LIST>(UNNUMBERED)
<LE>Change maximum number of database users
<LE>Change maximum number of VAXcluster nodes that can access the database
<LE>Change space allocation characteristics such as extension values of
the database. <EMPHASIS>(Note that the database can dynamically extend as
required, but the default value of the size to extend by can be altered by
the DBA.\ITALIC)
<LE>Changing database locking characteristics (whether or not automatic
locking granularity is enabled or disabled)
<LE>Changing default number of database buffers per user
<LE>Changing default number of database recovery buffers
<LE>Changing after-image journalling (disable, or enable and/or change
file being used)
<LE>Changing usage of snapshots (enabled, disabled and if enabled whether
immediate or deferred)
<LE>Changing allocation characteristics for After-Image Journal file
<LE>Changing allocation characteristics for a Snapshot File
<LE>Changing the requirement for a dictionary to be used when metadata
changed
<LE>Adding new storage areas
<LE>Changing storage areas
<LE>Deleting storage areas
<ENDLIST>
Changes can be made through Interactive RDO, Callable RDO, Interactive
SQL, precompiled SQL, a procedure in a SQL Module, or through Dynamic SQL.
Refer to Section 6.3 "CHANGE DATABASE
Statement" in the <EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC), and
Section 4.3 "ALTER SCHEMA Statement" in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC).
<HEAD3>(Changes by DBA Requiring Reload)
<p>
The following changes require the database to be closed down, unloaded
with EXPORT and reloaded with IMPORT :
<LIST>(UNNUMBERED)
<LE>Changing buffer size
<LE>Changing number of users on a single-file database (unload and reload not
required for multi-file database)
<LE>Changing number of VAXcluster nodes for a single-file database (unload and
reload not required for multi-file database)
<ENDLIST>
<p>
Refer to Section 7.6 "Applications That Use the EXPORT and IMPORT
Statements" in the <emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(Quick and Automatic Recovery)
<P>
<EMPHASIS>(Rdb will automatically detect abnormal termination of users
transactions, and will initiate recovery and rollback without causing
any data inconsistency.\BOLD) Refer to Section 6.1 "Journalling and Recovery
for Update Transactions", and Section 6.4 "The Recovery-Unit Journal
File", under Chapter 6 "Journalling and Recovery" in the
<emphasis>(<reference>(GuideMaintPerf)).
<p>
In a VAXcluster environment, Rdb will automatically coordinate
recovery even if the node which commenced the original transaction is
no longer present. There is no loss of recovery or integrity
capability in a VAXcluster. <EMPHASIS>(Rdb/VMS provides superior data
integrity and recovery capability in the VAX/VMS environment.\BOLD)
Refer to Section 15.8 "The Automatic Recovery Procedure" in the
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(Data Integrity)
<P>
Database integrity has been the primary goal of Rdb/VMS since
inception. Automatic detection and recovery/rollback of incomplete
transactions through user based recovery-unit journalling, after-image
journalling and use of the distributed lock manager means that Rdb
maintains optimum integrity in all VAX/VMS environments, including
single or multiple CPU nodes, CI VAXclusters, Local Area VAXclusters,
mixed VAXclusters, and under DECnet distributed environments.
Each database page contains a checksum, which is checked by Rdb and
recalculated after each update. As Rdb is integrated into Digital's
file system, bad disk blocks are handled by the file system.
<p>
References:
<LIST>(UNNUMBERED)
<LE>Database corruption is discussed in the
<emphasis>(<reference>(GuideMaintPerf)) under:
<LIST>(UNNUMBERED\-)
<LE>Section 5.4.1 "Example of Database Corruption"
<LE>Section 5.4.2 "Causes of Database Corruption"
<ENDLIST>
<LE>Also refer to Chapters 6 "Journalling and Recovery" and 15 "Using
Rdb/VMS in a VAXcluster Environment", in the same manual for
information on integrity.
<LE>Also refer to the <emphasis>(<reference>(RdbSPD)).
<ENDLIST>
<HEAD2>(DBA Facilities)
<P>
RMU has /VERIFY, /DUMP and /ANALYZE
functions for integrity checking and database analysis.
<p>
Verifying a database is discussed under Section 5.4 of the
<emphasis>(<reference>(GuideMaintPerf)). Also refer to Chapters 6 and
15 in the same manual for information on integrity.
<p> The Rdb/VMS RMU utility, which is a standard component of Rdb/VMS,
provides a SHOW STATISTICS function which is commonly used to analyse
database performance. For more introductory information on DBA facilities
for evaluating performance and database behaviour, refer to Section 10.2
"Utilities and Tools to Evaluate Performance" in the
<emphasis>(<reference>(GuideMaintPerf)).
<p> Deadlocks are detected by and broken by Rdb/VMS (through its use of
the VMS Distributed Lock Manager), and information on deadlocks and other
lock statistics can be viewed and recorded through the RMU utility's SHOW
STATISTICS displays. Refer to Chapter 16 "Using Database Statistics" in
the <emphasis>(<reference>(GuideMaintPerf)), and in particular Sections:
<LIST>(UNNUMBERED)
<LE>12.7.7 "Summary Locking Statistics"
<LE>12.7.16 "Lock Statistics for One Lock Type"
<LE>12.7.17 "Lock Statistics for One Statistics Field"
<ENDLIST>
<p>
Also refer to the <emphasis>(<reference>(RdbSPD)).
<p>
<HEAD1>(Functionality)
<HEAD2>(Support of VAXclusters and Networks\DSRIDistributed)
<P>
Users under VMS on a given node in a DECnet network can access DSRI
databases (including VAX Rdb/VMS databases) on the same node, and/or
other nodes in the network.
<p>
Installation of the VAX Data Distributor optional layered product with
Rdb/VMS provides:
<LIST>(UNNUMBERED)
<LE>Extraction of entire databases or parts of them, into target
databases on remote systems
<LE>Extraction rollup, with the additional capability of extracting
relations and fields from multiple source databases into a single, new
target database
<LE>Store and forward replication. Once a target database has been
created, updates to the source database are forwarded to the target
database(s) at scheduled intervals or on demand.
<ENDLIST>
<P>
VAX Rdb/VMS, VAX CDD, and most other Digital products, are fully
supported when installed on any valid and licensed VAXcluster
configuration without functionality restrictions, as per
the <emphasis>(<reference>(RdbSPD)) and the matching System
Support Addendum, and also the <emphasis>(VAXcluster Software Product
Description (29.78.xx)).
<HEAD2>(Support for Domain Integrity)
<P>
Domain integrity is implemented via the VALID IF construct. Values must
satisfy the VALID IF rule, which can include a test for MISSING or NOT
MISSING. Refer to:
<LIST>(UNNUMBERED)
<LE>Section 13.11 "Database Integrity Considerations" in the
<emphasis>(<reference>(GuideMaintPerf)).
<LE>Section 5.2 "Validity Clause" in the
<emphasis>(<reference>(RdbRefManual)).
<LE>Section 3.5.2.1 "VALID IF Clause" in the
<emphasis>(<reference>(RdbGuideDesign)).
<LE>Section 6.16 "DEFINE FIELD Statement" in the
<emphasis>(<reference>(RdbRefManual)).
<ENDLIST>
<HEAD2>(Support for Referential Integrity)
<P>
Referential integrity is implemented via the concept of constraints.
Constraints can use a simple RSE and conditional or can be a complex
nested test involving more than one relation and more than one field.
Constraints can be defined to be checked at verb time or at COMMIT time.
If data violates a constraint, then that transaction cannot be committed
until the constraint violation is corrected. Constraints are a feature of
the database and cannot be bypassed once defined, and apply to all users
of the database (hence even third-party 4GLs cannot bypass constraints).
<p>
Refer to:
<LIST>(UNNUMBERED)
<LE>Section 3.9 "Defining Constraints" in the
<emphasis>(<reference>(RdbGuideDesign)).
<LE>Section 13.11 "Database Integrity Considerations" in the
<emphasis>(<reference>(GuideMaintPerf)).
<LE>Section 6.14 "DEFINE CONSTRAINT Statement" in the
<emphasis>(<reference>(RdbRefManual)).
<LE><emphasis>(<reference>(RdbSPD)).
<ENDLIST>
<p>
DIGITAL is undertaking research and development into other forms of
referential integrity, such as "triggers".
<HEAD2>(Supported Data Types)
<P>
Rdb/VMS V3.0 supports the following data types:
<LIST>(UNNUMBERED)
<LE>ASCII text
<LE>Varying string
<LE>Date, as per VMS architecture
<LE>Signed word (16-bit) integer
<LE>Signed longword (32-bit) integer
<LE>Signed quadword (64-bit) integer
<LE>Single precision floating point (F_floating)
<LE>Double precision floating point (G_floating)
<LE>Segmented strings for storing large amounts of unstructured data, such
as documents, voice, or graphics (not supported through VAX SQL)
<ENDLIST>
<p>
Refer to:
<LIST>(UNNUMBERED)
<LE><emphasis>(<reference>(RdbSPD)).
<LE>Section 5.1 "Data Type Clause" in the
<emphasis>(<reference>(RdbRefManual)).
<LE>Chapter 2 "Data Type Compatibility" in the
<emphasis>(<reference>(RdbGuideProg)).
<ENDLIST>
<HEAD2>(Size Constraints)
<P>
For Rdb/VMS V3.0, the following size constraints apply:
<LIST>(UNNUMBERED)
<LE>Maximum number of relations and views in a database is 1,024
<LE>Maximum number of bytes in a record is 16,383
<LE>Maximum number of fields in a relation is 2,000
<LE>Maximum index key size is 254 bytes
<LE>Maximum length of a database object name is 31 characters
<LE>Minimum database page size is 512 bytes
<LE>Maximum size of database, is limited by available physical devices
<LE>Maximum number of subqueries or relation references in a Rdb/VMS
statement is 32.
<LE>Only one active transaction per database attach. <EMPHASIS>(However,
you can attach to the same database more than once, and start a single
transaction against each database attach within the same program, using
database handles and transaction handles.\ITALIC)
<ENDLIST>
<p>
Refer to:
<LIST>(UNNUMBERED)
<LE><emphasis>(<reference>(RdbSPD)).
<LE>Section 3.2.1 "Forming Record Streams" in
<emphasis>(<reference>(RdbGuideProg)).
<LE>Section 3.3.3 "Using Handles" in <emphasis>(<reference>(RdbGuideProg)).
<ENDLIST>
<HEAD2>(Integration and Links to Other Software\IntegratedSoftware)
<P>
VAX Rdb/VMS implements the <EMPHASIS>(DIGITAL Standard Relational
Interface\ITALIC). DSRI is an architecture for relational database
management systems, as well as a standard calling mechanism that can be
used for DSRI database creation and population. DSRI allows
applications running on any VAX or MicroVAX in a DECnet network to
access all other DSRI-compliant databases in the network.
<p> Many other DIGITAL products (eg RALLY, TEAMDATA, DATATRIEVE) and
third-party products use DSRI, permitting them to integrate closely
with Rdb/VMS databases.
<p>
Many of these products are in turn closely
integrated with other products or architectures such as ALL-IN-1 and
Xway. Some examples:
<LIST>(UNNUMBERED)
<LE>It is possible for an ALL-IN-1 user to use TEAMDATA or
20/20 to access data in an Rdb/VMS database, and use the output as
input to DECgraph within ALL-IN-1.
<LE>ALLIN-1 can invoke ACMS tasks, TEAMDATA, RALLY, etc..
<LE>TEAMDATA can include RALLY
applications within its folders, providing another interface to data.
<LE>RALLY applications can in turn call external programs such as
run-time library routines, user programs or even ACMS tasks.
<ENDLIST>
<p>
Refer to the:
<LIST>(UNNUMBERED)
<LE><emphasis>(<reference>(RdbSPD))
<LE><emphasis>(<reference>(DTRSPD))
<LE><emphasis>(<reference>(RallySPD))
<LE><emphasis>(<reference>(TeamdataSPD))
<LE><emphasis>(<reference>(XwaySPD))
<LE><emphasis>(<reference>(Allin1SPD))
<ENDLIST>
<HEAD2>(Extent of Physical and Logical Data Independence)
<P> Using Rdb/VMS, it is possible to create and use a database without
taking physical storage characteristics into consideration. While such an
approach can be useful and successful for smaller databases, it should not
be used for larger and/or more complicated database designs. Table 31-1
"How Far Will the Rdb/VMS Default Values Take You?" in the
<emphasis>(<reference>(GuideMaintPerf)) contains a rough outline to the
minimum tuning effort that may be required for various combinations of
size and complexity. Many of the performance parameters of a large or
complex database are physical characteristics which can be managed largely
separately from the logical design of the database domains and tables.
<p>
Refer to:
<LIST>(UNNUMBERED)
<LE>Section 1.3 "Understanding Logical and Physical Database Design" in
the <emphasis>(<reference>(RdbGuideProg)).
<LE>Table 3-1 "Storage Design Complexity as Required by Database Size and
Complexity" in Section 3.4.2 "Choosing Single-File or Multifile Storage" in
the <emphasis>(<reference>(RdbGuideProg)).
<LE>Chapter 13 "Improving Database Performance" in the
<emphasis>(<reference>(GuideMaintPerf)).
<LE>Chapter 4 "Implementing a Multifile Database" in the
<emphasis>(<reference>(RdbGuideProg)).
<ENDLIST>
<HEAD2>(Options for Physical Placement of Data/Indices)
<P>
Rdb/VMS implements the following physical characteristics/features:
<LIST>(UNNUMBERED)
<LE>Physical storage areas, with associated snapshot files
<LE>UNIFORM or MIXED format pages per storage areas
<LE>Storage maps, to associate data and/or indexes to storage areas
<LE>HASHED and SORTED (B-tree) indexes
<LE>PLACEMENT VIA INDEX to cluster records from different relations with
index
<ENDLIST>
<p>
Refer to:
<LIST>(UNNUMBERED)
<LE>Section 1.3 "Understanding Logical and Physical Database Design" in
the <emphasis>(<reference>(RdbGuideProg)).
<LE>Chapter 4 "Implementing a Multifile Database" in the
<emphasis>(<reference>(RdbGuideProg)).
<LE>Chapter 13 "Improving Database Performance" in the
<emphasis>(<reference>(GuideMaintPerf)), and in particular:
<LIST>(UNNUMBERED\-)
<LE>Section 13.5 "Indexed Retrieval"
<LE>Section 13.13 "Adjusting Storage Area Parameters"
<LE>Section 13.14 "Adjusting Storage Map Parameters"
<ENDLIST>
<LE>Chapter 4 "VAX SQL Statements" in the
<emphasis>(<reference>(SQLRefManual)), and
in particular:
<LIST>(UNNUMBERED\-)
<LE>Section 4.13 "CREATE STORAGE AREA Clause"
<LE>Section 4.14 "CREATE STORAGE MAP Statement"
<LE>Section 4.11 "CREATE INDEX Statement"
<ENDLIST>
<ENDLIST>
<HEAD1>(Production Support)
<HEAD2>(Extent and Quality of DBA Functionality Performed by RDBMS)
<P>
<REFERENCE>(AutomaticDBA\FULL) covers the DBA-class functions
automatically performed by Rdb/VMS.
<HEAD2>(Extent and Quality of DBA Documentation)
<P>
The documentation specifically aimed at the DBA is the
<emphasis>(<reference>(GuideMaintPerf)). Other documentation that the DBA
might need to use includes:
<LIST>(UNNUMBERED)
<LE><emphasis>(<reference>(RdbRefManual))
<LE><emphasis>(<reference>(SQLRefManual))
<LE><emphasis>(<reference>(CDDRefManual))
<ENDLIST>
The following guides may be useful for the new DBA:
<LIST>(UNNUMBERED)
<LE><emphasis>(<reference>(SQLUserGuide))
<LE><emphasis>(<reference>(CDDUsersGuide))
<LE><emphasis>(<reference>(RdbGuideDesign))
<LE><emphasis>(<reference>(RdbGuideProg))
<ENDLIST>
<HEAD2>(Extent and Quality of DBA Performance Monitoring and Tuning Tools)
<P>
Refer to:
<LIST>(UNNUMBERED)
<LE><emphasis>(<reference>(GuideMaintPerf)) and in particular:
<LIST>(UNNUMBERED\-)
<LE>Section 10.2 "Utilities and Tools to Evaluate Performance"
<LE>Chapter 11 "Analyzing Record Storage"
<LE>Chapter 12 "Using Database Statistics"
<LE>Chapter 14 "The Optimizer and RDMS$DEBUG_FLAGS"
<ENDLIST>
<ENDLIST>
<HEAD2>(Extent and Ease of Use of DBA Tools for User Self-maintenance)
<P>
Some of the statistics analysis might require a knowledge of material
covered in the <emphasis>(<reference>(GuideMaintPerf)). For most small databases,
very little maintenance should be required over backups.
<HEAD2>(Backup and Recovery Steps)
<P>
To backup a database, use the RMU /BACKUP command. Refer to Section 5.2
"Backing Up a Database" in the <emphasis>(<reference>(GuideMaintPerf)) for
details. The sample backup procedure in Section 5.2.2 "Sample Backup
Procedure" uses the following steps:
<p>
<LIST>(UNNUMBERED)
<LE>Full Backup, say once a week:
<LIST>(NUMBERED)
<LE>Optionally, verify the database using RMU /VERIFY
<LE>Perform a full backup using RMU /BACKUP/FULL
<LE>Optionally, verify the backup file by using RMU /DUMP/BACKUP command
<ENDLIST>
<LE>Every other day of the week, perform an incremental backup:
<LIST>(NUMBERED)
<LE>Verify the database since previous full backup using
RMU /VERIFY/INCREMENTAL
<LE>Backup using RMU /BACKUP/INCREMENTAL
<LE>Optionally, purge old versions of incremental backups
<LE>Check the incremental backup using RMU /DUMP/BACKUP_FILE command
<ENDLIST>
<ENDLIST>
Typically, these steps are adequate.
<p>
To recover a database to a known, uncorrupt state, follow these steps:
<LIST>(NUMBERED)
<LE>Restore the database from the last full RMU /BACKUP operation using the
RMU /RESTORE command. You may want to delete the corrupt database first.
<LE>Update the restored database from the last RMU /BACKUP/INCREMENTAL
operation using the RMU /RESTORE/INCREMENTAL command.
<LE>Use the RDO RECOVER statement to apply the transactions in the journal
file to the <EMPHASIS>(new\ITALIC), now fully restored copy of the
database. There may be more than one AIJ file to apply depending on the
prior use of the RMU /BACKUP/AFTER_JOURNAL command. The rollforward can be
done to the end of all the AIJ files, or to a selected date-time (useful
if the introduction of a bad program image caused the corruption).
<LE>Verify the integrity of the database with RMU /VERIFY command.
<LE>It is also recommended that you perform a full, online, database
backup using RMU /BACKUP (but not write over the previous backup copy) to
preserve a new copy.
<ENDLIST>
<p>
Refer to <emphasis>(<reference>(GuideMaintPerf)) for information on
restoring databases from backups, and recovering (roll-forward) with
after-image journals:
<LIST>(UNNUMBERED)
<LE>Section 6.3.1 "Steps for Recovering a Database"
<LE>Chapter 5 "Backing Up and Restoring Your Database"
<LE>Chapter 6 "Journaling and Recovery"
<ENDLIST>
<HEAD2>(Degree of DBA Involvement in Prototyping)
<P>
A minimal database requires no, or very little, DBA involvement.
<HEAD2>(Reorganising Files for Performance)
<P>
There is <EMPHASIS>(no need to reorganise files to free up space\BOLD) no
longer in use, as this is automatically made available.
<p>
Many of the RDO CHANGE and SQL ALTER commands reorganise the
appropriate structures (eg CHANGE INDEX) when the command is used.
<p>
In the event of disk fragmentation, or poor tuning practices, it is
possible to unload and reload with substantially changed parameters using
the RDO EXPORT and IMPORT commands, or use an appropriate ALTER command.
<p>
Refer to Chapter 10 "Performance Tuning Overview", and Chapter 7
"Modifying Your Database Characteristics", in the
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(Dynamic Increase of Database Size)
<P>
<EMPHASIS>(Rdb/VMS will dynamically increase sizes of storage areas,
snapshot files, after-image journal files, recovery-unit journal files,
etc, as required.\BOLD) This powerful functionality is uncommon amongst
many RDBMS's.
<p>
Refer to the <emphasis>(<reference>(GuideMaintPerf)):
<LIST>(UNNUMBERED)
<LE>Section 6.2 "The After-Image Journal File"
<LE>Section 6.4 "The Recovery-Unit Journal File"
<LE>Section 13.12.8 "Allocation for After-Image Journal and Snapshot Files"
<LE>Section 13.12.9 "Extents for After-Image Journal and Snapshot Files"
<LE>Section 13.13.2 "Allocation Size"
<LE>Section 13.13.3 "Extent Size"
<ENDLIST>
<HEAD2>(Maintenance Procedures Standard to Life-cycle Environments)
<P>
Rdb/VMS provides the same RMU utilities under run-time licenses as it does
under a full development license.
<p>
Rdb/VMS does not distinguish between a development environment and a
production environment, unless different Rdb/VMS licenses are used. The
more restricted licenses contain less development capabilities (eg no
precompilers) than the full development license.
<p>DBA maintenance procedures (eg statistics monitoring, backups) are
identical in all environments.
<HEAD2>(Online Maintenance Facilities)
<P>
All RMU functions can be performed interactively. Some functions require
the database to be off-line.
<HEAD2>(Online Help)
<P>
Help is provided online in many ways:
<LIST>(UNNUMBERED)
<LE>HELP for RMU is online through a VMS help library (eg HELP RMU).
<LE>The interactive utilities like RDO and Interactive SQL have Help
online available interactively.
<LE>Where an LSE template is available, it may have online help.
<ENDLIST>
<HEAD2>(Security Implementation)
<P>
Security uses VMS-style access control lists based upon VMS identifiers.
VMS identifiers include UIC identifiers, general identifiers (defined by
system manager, such as MANAGERS, PROGRAMMERS), system-defined
identifiers (such as BATCH, LOCAL, INTERACTIVE) and a combination of a
system identifier with a UIC or general identifier (such as [*,*]+LOCAL
to specify any user associated with a LOCAL login). Databases, relations
and views can have access control lists associated with them.
<P>
Database protection is described in:
<LIST>(UNNUMBERED)
<LE>Chapter 3 "Defining Database Privileges" of the
<emphasis>(<reference>(SQLUserGuide)), and especially Sections 3.1 and
3.2.
<LE>Chapter 5 "Defining Database Protection" of the
<emphasis>(<reference>(RdbGuideDesign)).
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(RdbRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 6.6 "CHANGE PROTECTION Statement"
<LE>Section 6.16 "DEFINE PROTECTION Statement"
<LE>Section 6.26 "DELETE PROTECTION Statement"
<ENDLIST>
<LE>The following sections in the
<EMPHASIS>(<REFERENCE>(SQLRefManual)\ITALIC) :
<LIST>(UNNUMBERED\-)
<LE>Section 4.41 "GRANT Statement"
<LE>Section 4.51 "REVOKE Statement"
<ENDLIST>
<ENDLIST>
<HEAD2>(Application Security Independent of Security at DML Level)
<p>
By default, protection is identifier based so that the same access rights
would apply regardless of the utility or program used to access the
database as the users process context is used to determine access.
<P>
If the application code can grant to the user (or revoke from) identifiers
that would not be available at DML level, then different access might be
granted (depending on the protections) from that which would ordinarily be
available.
<p>
This is often the case with applications using ACMS, so that 3GL programs
running under ACMS are considered to be different users from interactive
users using SQL or RDO. The database server process could run under a
username different from that of the terminal user, hence the user gains
controlled access to data through the ACMS application that is not
available otherwise.
<HEAD2>(Audit Options)
<P>
Currently, Rdb/VMS treats audit as an application concern, and provides no
facilities other than the RMU /DUMP/AFTER command.
<HEAD2>(Multi-user Access and Resource Availability)
<P>
The sharing options and transactions types used by users, control how
multi-user access will interact. <EMPHASIS>(Deadlocks are usually
prevented by the sophisticated locking strategy Rdb/VMS implements on top
of the VMS Distributed Lock Manager, and when deadlocking transactions are
detected the deadlock will be broken.\BOLD) Depending on the transaction
type, users will wait for data to become available, or the transaction
will fail immediately.
<p>
Refer to Section 13.4 "Locking Considerations" in the
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(Multi-user Access and Integrity)
<P>
<EMPHASIS>(Rdb/VMS implements degree-3 consistency (snapshots), by making writers
write snapshots of old data as required, so that a READ_ONLY user will
always see the same results when repeating queries within the same
transaction.\BOLD)
<p>
Refer to Section 13.4 "Locking Considerations" in the
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(RDBMS Tools to Monitor Performance Parameters)
<P>
Refer to Chapter 11 "Analyzing Record Storage", Chapter 12 "Using Database
Statistics" in the <emphasis>(<reference>(GuideMaintPerf))
<HEAD2>(Performance Parameters - Automatic Support by RDBMS)
<P>
See also <REFERENCE>(AutomaticDBA\FULL). <EMPHASIS>(The most significant
compared to older style RDBMS's is the dynamic file
extension capabilities and locking
strategies. No other RDBMS's on VAX/VMS can combine the performance and
power of these features at the same time.\BOLD)
<HEAD2>(Performance Parameters - Supported by DBA)
<P>
See Chapter 13 "Improving Database Performance" in
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(Performance Parameters - Supported by Application Developers)
<P>
See Section 13.4 "Locking Considerations" in
<emphasis>(<reference>(GuideMaintPerf)), for a discussion on transaction
types
available to developers.
<p>
See Section 14.1 "The Optimizer" for a discussion on types of queries that
the optimizer considers more expensive than others.
<p>
For very large and/or complex databases, there may be occasions where the
programmer has more knowledge about the spread of data values than the
optimizer does, and where queries manipulating large amounts of data can
be pushed towards a certain lookup strategy by the programmer. For
example, when programming using RDO style DML a programmer might choose to
use nested FOR loops to force Rdb to query the outside relation first
before the inner relation, rather than letting the optimizer choose.
These occasions are typically very rarely needed.
<HEAD2>(Database Setup Resource Overheads)
<P>
As Rdb/VMS is implemented via shareable images, mapped into users process
space, the overheads of Rdb are very low. Each VMS node uses a single
monitor process whose functions are very limited (eg perform attaches, check
for aborted transactions at attach) and the monitor typically uses few
resources.
<HEAD2>(Database Expandability)
<P>
The database files will grow dynamically as required, subject to physical
disk limitations.
<HEAD2>(Availability of Freed Space)
<P>
Freed space is always available to data and/or indexes using the same
storage area.
<p>
<HEAD1>(Development Issues)
<HEAD2>(Range and Integration of Application (CASE) Tools)
<P>
Refer to <emphasis>(<reference>(VAXsetBook)).
<HEAD2>(Quality and Ease of Use of Application 4GL Tools)
<p>
DIGITAL provides high quality 4GL tools such as RALLY, TEAMDATA,
DATATRIEVE, COBOL Generator. Typically, the more powerful 4GL's such as
the applications generator RALLY do require some training so that
programmers can reach full productivity as quickly as possible.
<HEAD2>(Integration of All Life-cycle Environments)
<P>
Refer to <emphasis>(<reference>(VAXsetBook)).
<HEAD2>(Common User Interface Across 4GL Tools)
<P>
While most DIGITAL products use similar definitions for keystrokes and
keypad functions, the interface for each 4GL tool (particularly
programming tools) tends to be optimised for that particular tool.
<p>
Applications developed under RALLY can have key definitions changed by the
developer, from either of the two supplied standards of EDT or WPS
compatible.
<HEAD2>(Data Dictionary Capabilities and Restrictions, with RDBMS)
<P>
Refer to Chapter 6 "Using Rdb/VMS with VAX CDD/Plus" in the
<emphasis>(<reference>(RdbGuideDesign)).
<HEAD2>(Management of Source and Executable Code)
<P>
Refer to <emphasis>(<reference>(VAXsetBook)).
<HEAD2>(SQL Procedural Language and ANSI Conformity)
<P>
Appendix B "Differences from ANSI Standard" details known areas of VAX SQL
noncompliance with the SQL ANSI standard X3.135-1986, in the
<emphasis>(<reference>(SQLRefManual)).
<HEAD2>(Integrated SQL Procedural Editor)
<P>
Interactive SQL supports either the EDT or TPU editors, to be invoked by
the EDIT command. VAX LSE has partial support under SQL. Refer to Section
4.32 "EDIT Statement" in the <emphasis>(<reference>(SQLRefManual)).
<HEAD2>(3GL PASCAL Support)
<P>
RDB/VMS currently has no SQL PASCAL Precompiler, but an RDML Precompiler is
provided. Digital recommends the SQL Module Language if PASCAL and SQL
are to be used together. Refer to Chapter 5 "SQL Module Language" in the
<emphasis>(<reference>(SQLRefManual)).
<HEAD2>(Host Language Interface)
<P>
Refer to Chapter 9 "Developing Host Language Programs" in the
<emphasis>(<reference>(SQLUserGuide)).
<HEAD2>(Test and Debugging Environment)
<P>
Rdb precompilers use standard compilers after precompilation, and so
standard VMS test and debugging features are available.
<P>
Refer to <emphasis>(<reference>(RdbGuideProg)) and
<emphasis>(<reference>(VAXsetBook)).
<HEAD2>(4GL RDBMS Produced Application Documentation)
<P>
VAX RALLY has an application report utility, which produces a description
of the RALLY application. Refer to the
<emphasis>(<reference>(RallyRefManual)).
<p>
<HEAD1>(Performance)
<HEAD2>(Maximum Performance)
<P>
Performance of a RDBMS is dependent upon the logical and physical design,
the supporting hardware and the nature, size and complexity of the
applications using that system. Performance is best estimated by looking
at a reasonable prototype of the application. Refer to following sections
for references to further reading on optimisation and tuning.
<HEAD2>(Effort to Optimise Performance)
<P>
There are some basic assumptions made by the Rdb developers as to the
minimum effort needed to implement a physical design of your application
based upon the kind of database (simple or complex) and the size of the
database (small to very large).
<p>
Table 31-1 "How Far Will the Rdb/VMS Default Values Take You?" in the
<emphasis>(<reference>(GuideMaintPerf)) contains a rough outline to the
minimum tuning effort that may be required for various combinations of
size and complexity.
<p>
Chapter 13 "Improving
Database Performance" is a thorough review of factors affecting
performance and should be considered with Chapters 10 to 12 inclusive, and
Chapter 14. It is envisaged that stable applications should not require
frequent performance reviews.
<p>
Many of the performance parameters of a large or complex database are
physical characteristics which can be managed largely separately from the
logical design of the database domains and tables. A few parameters are
involved with application programming (eg. sharing mode used in
transactions). See Section 13.4 "Locking Considerations" for some detail
on this.
<HEAD2>(Query Optimisation)
<P>
The optimizer is responsible for evaluating all queries and determining
the most efficient lookup strategy to implement that query. The optimizer
works at the lowest layer, and so even precompiled DML/SQL is passed to
the optimizer for evaluation. Once a query for a user has been evaluated
by the optimizer, the optimizer will recognise identical later queries by
that user and does not need to re-determine the strategy. You do not have
to be overly concerned about how to construct your queries; if the
database changes, the optimizer will automatically devise a new access
strategy. Thus, the order in which you specify joins and the order of
clauses in the RSE do not, in most cases, influence the order the
optimizer uses to satisfy the query.
<p>
The programmer and DBA can view the optimizer strategy by using the
RDMS$DEBUG_FLAGS logical. See Section 14.1 "The Optimizer" and Section
14.2 "Using RDMS$DEBUG_FLAGS" in the
<emphasis>(<reference>(GuideMaintPerf)).
<HEAD2>(Reclamation of Freed Space)
<P>
Freed space is automatically made available to other users, and is reused
freely. Rdb/VMS manages free space with space area management (SPAM)
pages, which track whether data pages are full or have free space. A
single SPAM page tracks space utilisation of many data pages. Hence, SPAM
pages are used to quickly determine target pages for storing new data,
rather than searching data pages for one that has sufficient free space.
<p>
For a
detailed description of the management of freed space using SPAM pages,
refer to Section 8.5 "Space Area Management (SPAM) Page Structure" in the
<emphasis>(<reference>(GuideMaintPerf)).
<p>
For a description of how free space within a
data page is managed, refer to Section 8.4.4 "Locked and Unlocked Free
Space for a Data Storage Page".
<HEAD2>(Data Contention\LockingContention)
<P>
Rdb/VMS uses the VMS Distributed Lock Manager to synchronise access of
shared resources. When one user's query fetches a record from the
database, a series of locks prevents other users from altering that
record. Locks might be placed on that record, as well as database
relations, pages, and index nodes as well. Through the VMS Distributed
Lock Manager, Rdb/VMS maintains locks on a database resource at various
levels; that is, a transaction can lock database resources at the relation
level (coarse granularity), the record level (fine granularity) or the page
level. This method of using locks to protect resources requested by a
transaction is called <EMPHASIS>(adjustable locking granularity\BOLD), and
is optional (it can be disabled and enabled as desired).
<p>
Adjustable locking granularity is the internal method Rdb/VMS uses to
maintain as few locks as possible on database resources. Refer to Section
13.4.4 "Adjustable Locking Granularity" in the
<emphasis>(<reference>(GuideMaintPerf)).
<p>
<emphasis>(It is usually best enabled for applications with heavy
retrieval content where the application processes groups of records. On
the other hand, it can be best disabled for heavy update content where the
application processes specific records individually.\BOLD) Refer to Section
7.1.5 "Changing Database Locking Characteristics" in the
<emphasis>(<reference>(GuideMaintPerf)).
<p>
Section 13.4 "Locking Considerations" covers the basics of locking and
transactions in some detail, and Figure 13-3 "Lock Compatibility" shows
the compatibilities of shared access by different transaction types.
<HEAD2>(Effect of Data Dictionary on Runtime Performance)
<P>
As the synchronised use of the Common Data Dictionary is optional, it is
unusual for precompiled applications to use the dictionary at runtime
(such as precompiled COBOL or PASCAL programs). Some products (eg
DATATRIEVE) always use the CDD, but the overhead is usually considered to
be minimal.
<p> Refer to Chapter 6 "Using VAX Rdb/VMS with CDD/Plus" in the
<emphasis>(<reference>(RdbGuideProg)), and Chapter 7 "Using VAX Rdb/VMS
with CDD/Plus" in the <emphasis>(<reference>(CDDUsersGuide)).
<p>
<HEAD1>(Cost)
<p>
<EMPHASIS>(VAX Rdb/VMS has the best cost of ownership of any RDBMS on VMS with
its capabilities.\BOLD)
<p>
<HEAD1>(Environment)
<HEAD2>(Compatibility with Environment)
<HEAD3>(Functionality and/or Performance)
<P>
DIGITAL products yield optimum performance, interoperability,
functionality, and ease of use in the
DIGITAL hardware and software environment.
<HEAD3>(Upgrade Effort or Risks)
<P>
Due to the extensive quality testing of new hardware and software
versions prior to release, DIGITAL attempts to minimise upgrade effort
and upgrade risks for its customers.
<p>
Third-party RDBMS's do not have the advantages of being involved in
DIGITALs hardware and software planning, research and development
process. Many third-party 4GL and other layered product developers do
have co-operative development agreements
with DIGITAL, so that they can provide compatible layered software.
<p>
DIGITAL aims to provide upgrade paths. New versions of
software (like Rdb/VMS) are provided as part of a regular software
maintenance contract (so that it is not necessary to purchase new
versions separately).
<HEAD3>(Database Extension)
<P>
Extension is dynamic. See also <REFERENCE>(AutomaticDBA\FULL).
<HEAD3>(Shareable Data Dictionary)
<p>
The CDD is shareable. Refer to Chapter 6 "Using VAX Rdb/VMS with
CDD/Plus" in the <emphasis>(<reference>(RdbGuideProg)), and Chapter 7
"Using VAX Rdb/VMS with CDD/Plus" in the
<emphasis>(<reference>(CDDUsersGuide)).
<HEAD3>(VAXcluster Support)
<P>
Database integrity has been the primary goal of Rdb/VMS since
inception. <EMPHASIS>(Automatic detection and recovery/rollback of incomplete
transactions through user based recovery-unit journalling, after-image
journalling and use of the distributed lock manager means that Rdb
maintains optimum integrity in all VAX/VMS environments, including
single or multiple CPU nodes, CI VAXclusters, Local Area VAXclusters,
mixed VAXclusters, and under DECnet distributed environments.\BOLD)
<P>
Refer to Chapter 15 "Using Rdb/VMS in a VAXcluster Environment", in the
<emphasis>(<reference>(GuideMaintPerf)).
<p>
VAX Rdb/VMS, VAX CDD, and most other Digital products, are fully
supported when installed on any valid and license VAXcluster
configuration without restrictions.
Refer to the <emphasis>(<reference>(RdbSPD)) and the matching
<emphasis>(System Support Addendum), and also the
<emphasis>(VAXcluster Software Product Description (29.78.xx)).
<HEAD3>(Host Language Interface)
<P>
Refer to Chapter 9 "Developing Host Language Programs" in the
<emphasis>(<reference>(SQLUserGuide)).
<HEAD3>(Minimal Lock Contention)
<P>
See <reference>(LockingContention\FULL).
<HEAD2>(PC Platform Functionality and Requirements)
<P>
This is difficult to cover briefly. There are many ways that PCs and
Rdb/VMS applications can interoperate, using PCSA architecture, Xway
transfers and the new very powerful SQL/SERVICES program.
<HEAD2>(Distributed Processing)
<P>
Currently, Rdb/VMS supports DECnet access. Further research and
development is being performed on extending distributed access.
See <REFERENCE>(DSRIDistributed\FULL).
<HEAD2>(Integration with Office Facilities)
<P>
Rdb/VMS integrates with VAX ALL-IN-1 through TEAMDATA, 20/20, Xway and
other methods.
See <REFERENCE>(IntegratedSoftware\FULL).
<p>
<HEAD1>(Documentation and Support)
<HEAD2>(Extent and Quality of Documentation for Life-cycle Environments)
<p>
As evidenced by the references in this document, there is extensive
high-quality documentation covering all stages of development and
production. For a partial list refer to the Preface of this document.
<HEAD2>(Documentation of Bugs/Errors and Error Reporting)
<P>
Usually documented in the Release Notes. Additional information is
available through the DSIN program. Up-to-date information and support is
assisted with the purchase of a DIGITAL Professional Software Services
Consulting contract.
<P>
Error reporting is done through the local Telephone Support Centre, and/or
through submitting a Software Performance Report for each problem. DIGITAL
will provide written responses for Software Performance Reports.
<HEAD2>(Online Documentation)
<P>
Not currently available, but DIGITAL would be pleased to discuss possible
future arrangements.
<HEAD2>(Availability, Extent and Quality of Local Vendor Support)
<P>
DIGITAL Professional Software Services has Consulting staff available
locally, and in other offices, to assist as required. DIGITAL is
continually training and developing its staff, particularly in the area of
applications and database management systems (ie Rdb/VMS), to keep their
skills and knowledge up-to-date.
<HEAD2>(Availability of Local Skilled Contract Personnel)
<P>
There are experienced local contract personnel who have worked with
Rdb/VMS.
<p>
<HEAD1>(Other)
<HEAD2>(Extensions and Deviations from ANSI SQL)
<P>
Appendix B "Differences from ANSI Standard" details known areas of VAX SQL
noncompliance with the SQL ANSI standard X3.135-1986, in the
<emphasis>(<reference>(SQLRefManual)).
<p>
Appendix C "Differences from DB2" describes differences between VAX SQL
and the SQL language used in DB2, and briefly describes the general
differences between the environment in which the two languages operate.
<HEAD2>(Description of RDBMS Architecture)
<P>
The <emphasis>(<reference>(RdbIntro)) provides a preliminary overview of
Rdb/VMS, as does Chapter 4 "VAX Rdb/VMS" in the
<EMPHASIS>(<REFERENCE>(VAXInfo_Summary)\ITALIC). Detailed information
about the internal architectures of Rdb/VMS is not available publicly as it is
a proprietory result of DIGITAL's ongoing research and development program.
<HEAD2>(Application Design Support Tools)
<P>
DIGITAL currently provides third-party solutions, such as Software Through
Pictures .
<HEAD1>(Summary of Functionality in Tabular form)
<p>
The following tables summarize some of the features of Rdb/VMS and the
DIGITAL environment.
<TABLE>(Rdb/VMS and Database Structures)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Supported)
<TABLE_ROW>(Database Structure\Relational)
<TABLE_ROW>(Multi-file databases\Yes)
<TABLE_ROW>(Partitioned Tables\Yes)
<TABLE_ROW>(Record Clustering\Yes)
<TABLE_ROW>(Multi-format Page Structure\Yes)
<TABLE_ROW>(Database file placement control\Yes)
<TABLE_ROW>(After Image file placement control\Yes)
<TABLE_ROW>(Before Image file placement control\Yes)
<TABLE_ROW>(Locking at <EMPHASIS>(Database\ITALIC) level\Yes)
<TABLE_ROW>(Locking at <EMPHASIS>(Table\ITALIC) level\Yes)
<TABLE_ROW>(Locking at <EMPHASIS>(Page\ITALIC) level\Yes)
<TABLE_ROW>(Locking at <EMPHASIS>(Record\ITALIC) level\Yes)
<TABLE_ROW>(Performance Monitoring tools\Yes)
<TABLE_ROW>(Database Restructuring\Yes while on-line
(Refer to <REFERENCE>(ONLINE_section\FULL)))
<TABLE_ROW>(Full VAX/VMS Cluster Support\Yes)
<TABLE_ROW>(Snapshot Capability\Yes)
<TABLE_ROW>(Database page size control\Yes)
<TABLE_ROW>(Database creation parameters control\Yes)
<TABLE_ROW>(Support for Views\Yes)
<ENDTABLE>
<TABLE>(Database Characteristics)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\10)
<TABLE_HEADS>(Characteristic\Comment)
<TABLE_ROW>(Maximum Size of Database\Limited by available physical devices)
<TABLE_ROW>(Maximum Size of table\Limited by available physical devices)
<TABLE_ROW>(Maximum Tables per database\1024)
<TABLE_ROW>(Maximum Files per database\Limited by available physical devices)
<TABLE_ROW>(Maximum Records per table\Limited by available physical devices)
<TABLE_ROW>(Maximum Records per database\Limited by available physical devices)
<TABLE_ROW>(Maximum Fields per record\2000)
<TABLE_ROW>(Maximum Record size \16383)
<TABLE_ROW>(Maximum Tables in a view \32)
<TABLE_ROW>(Datatypes Supported:\
<line>SIGNED WORD
<line>SIGNED LONGWORD
<line>SIGNED QUADWORD
<line>F_FLOATING
<line>G_FLOATING
<line>DATE
<line>TEXT
<line>VARYING STRING
<line>SEGMENTED STRING (Unstructured datatype) )
<TABLE_ROW>(Support for Arrays \No (Arrays are non-relational;
normalisation removes arrays))
<ENDTABLE>
<TABLE>(Data Dictionary Functions)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Requirement\Comment)
<TABLE_ROW>(General Purpose Data Dictionary\Yes, in CDD/Plus)
<TABLE_ROW>(Referential Integrity\Yes, in Rdb)
<TABLE_ROW>(Stored Procedures\No)
<TABLE_ROW>(Triggers\No)
<TABLE_ROW>(Two-way Active Dictionary\Yes, in CDD/Plus)
<ENDTABLE>
<TABLE>(Field Attributes)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Rdb/VMS)
<TABLE_ROW>(Required Field\Yes (NOT MISSING))
<TABLE_ROW>(Acceptable Values\Yes (VALID IF))
<TABLE_ROW>(Formatting of Data\Yes (EDIT STRING))
<TABLE_ROW>(Calculated Fields\Yes (COMPUTED BY), in both table and view)
<TABLE_ROW>(Display only\No, not at database level (implemented by forms
products))
<TABLE_ROW>(Prompt\No, not at database level (implemented for Datatrieve))
<TABLE_ROW>(Error Message\No)
<TABLE_ROW>(Case Conversion\No (TDMS, FMS and DECforms perform
case conversion))
<TABLE_ROW>(Default Value\Yes)
<ENDTABLE>
<TABLE>(Rdb/VMS Indexing)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Options Supported)
<TABLE_ROW>(Types of Index\B-TREE, HASH)
<TABLE_ROW>(Maximum number of indexes per table\Unlimited)
<TABLE_ROW>(Maximum number of indexes per database\Limited by maximum
relations of 1024)
<TABLE_ROW>(Maximum number of fields\2000)
<TABLE_ROW>(Maximum key size\254 bytes)
<TABLE_ROW>(Ordering options\Ascending only)
<TABLE_ROW>(Unique index\Yes)
<TABLE_ROW>(Data clustering by index\Yes)
<ENDTABLE>
<TABLE>(Screen Forms)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Comment)
<TABLE_ROW>(Default form generator\Yes, with RALLY)
<TABLE_ROW>(Able to design customized forms\Yes, in DECforms, TDMS, FMS)
<TABLE_ROW>(Interactive Screen Painter\Yes, using DECforms, TDMS, FMS)
<TABLE_ROW>(Ability to create forms in word processing editor\Possible to
setup RALLY and ALL-IN-1)
<TABLE_ROW>(Multiple tables per form\Yes, using RALLY, DECforms, TDMS, FMS)
<TABLE_ROW>(Multiple screens per form\Yes, using RALLY, DECforms)
<TABLE_ROW>(Embedded processing\Yes, using RALLY, DECforms, TDMS and FMS)
<ENDTABLE>
<TABLE>(Queries)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Option or Comment)
<TABLE_ROW>(Query by example facility \ Yes with RALLY and TEAMDATA)
<TABLE_ROW>(Exact match \Yes)
<TABLE_ROW>(Relational Operators \ All but UNION)
<TABLE_ROW>(Boolean logic \ Yes)
<TABLE_ROW>(Ranges \ Yes)
<TABLE_ROW>(List of values \ Yes)
<TABLE_ROW>(Wildcards \ Yes)
<TABLE_ROW>(Maximum/Minimum Values \ Yes)
<TABLE_ROW>(Aggregate Functions \ Yes)
<TABLE_ROW>(Sort results \ Yes)
<TABLE_ROW>(Case Insensitive \ Yes)
<ENDTABLE>
<TABLE>(Reports)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Option or Comment)
<TABLE_ROW>(Default report generator\Yes with DATATRIEVE,TEAMDATA, RALLY)
<TABLE_ROW>(Interactive report generator, using screen forms/painter \Yes
with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Input source \Table, rse, collection)
<TABLE_ROW>(Multiple tables/report \Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Page formatting \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Data formatting \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Sorting \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Aggregate functions \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Logical processing \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(User-defined variables \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Prompt for variables at runtime \ Yes with DATATRIEVE,
TEAMDATA, RALLY)
<TABLE_ROW>(Output options \ Yes with DATATRIEVE, TEAMDATA, RALLY)
<TABLE_ROW>(Applications Generator \ Yes with DATATRIEVE, RALLY)
<TABLE_ROW>(4GL \ Yes with DATATRIEVE and RALLY)
<TABLE_ROW>(Default Menu generator \ Yes with ACMS and RALLY)
<TABLE_ROW>(On-the-fly datafiles \ Yes with DATATRIEVE and RALLY)
<ENDTABLE>
<TABLE>(Security)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Option or Comment)
<TABLE_ROW>(Login password \ Yes with VMS user accounts and RALLY and ACMS)
<TABLE_ROW>(Levels of access for Database \ Database, table, view)
<TABLE_ROW>(Levels of access for Other \ Procedures, forms with CDD)
<ENDTABLE>
<TABLE>(Networked Database Support)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Option or Comment)
<TABLE_ROW>(Distributed processing \ Yes with ACMS)
<TABLE_ROW>(Remote Database access \ Yes, using task to task
communications (more efficient than file transfer))
<TABLE_ROW>(Multiple Database access/application \ Yes)
<TABLE_ROW>(Distributed databases \ Partial with VAX Data Distributor)
<TABLE_ROW>(Heterogeneous Networks \ Yes)
<TABLE_ROW>(Heterogeneous Database access\ Yes, with VIDA and
VAX Link (VAX Link provides the capability of accessing IBM databases and
loading an Rdb/VMS database))
<ENDTABLE>
<TABLE>(Miscellaneous)
<TABLE_ATTRIBUTES>(KEEP)
<TABLE_SETUP>(2\40\20)
<TABLE_HEADS>(Characteristic\Option or Comment)
<TABLE_ROW>(Support for SQL \ Yes)
<TABLE_ROW>(Support for Transactions Logging \ Yes, After Image Journal)
<TABLE_ROW>(Support for Transaction Commit/Rollback \ Yes)
<TABLE_ROW>(Support for Transaction Roll Forward \ Yes)
<TABLE_ROW>(Support for Transaction Concurrency control \ Yes)
<TABLE_ROW>(File import/export capabilities \ Yes with RALLY, DATATRIEVE,
and TEAMDATA)
<TABLE_ROW>(Online Backup capability \Yes)
<TABLE_ROW>(Support for OLTP \ Yes with ACMS)
<TABLE_ROW>(Single-threaded vs multi-threaded \ Single, one per user)
<TABLE_ROW>(Support for VMS V5.0 \ Yes)
<ENDTABLE>
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|