VAX Rdb/VMS Release Notes, Versions 3.0, 3.0A, and 3.0B
Order Number: (N/A)
August 1989
This document contains the release notes for VAX
Rdb/VMS V3.0, V3.0A and V3.0B. The V3.0 notes are presented
first, and the V3.0A and V3.0B notes are appended at the end.
The release notes describe new and changed features (V3.0
only), software errors fixed, and problems, restrictions, and
other information.
OPERATING SYSTEM: VMS
SOFTWARE VERSION: VAX Rdb/VMS V3.0, V3.0A, and V3.0B
digital equipment corporation maynard, massachusetts
________________________
__________
The information in this document is subject to change
without notice and should not be construed as a
commitment by Digital Equipment Corporation. Digital
Equipment Corporation assumes no responsibility for
any errors that may appear in this document.
The software described in this document is furnished
under a license and may be used or copied only in
accordance with the terms of such license.
No responsibility is assumed for the use or
reliability of software on equipment that is not
supplied by Digital Equipment Corporation or its
affiliated companies.
__________
Copyright (c)1984, 1985, 1986, 1987, 1988, 1989 by Digital
Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
__________
The following are trademarks of Digital Equipment
Corporation:
DEC DIBOL UNIBUS
DEC/CMS EduSystem VAX
DEC/MMS IAS VAXcluster
DECnet MASSBUS VMS
DECsystem-10 PDP VT
DECSYSTEM-20 PDT
DECUS RSTS
DECwriter RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version
1.0
_______________________________________________________
Contents for Rdb/VMS V3.0 Release Notes
_________________________________________________
PREFACE xi
_______________________________________________________
CHAPTER 1 NEW AND CHANGED FEATURES 1-1
_________________________________________________
1.1 VAX SQL INCLUDED WITH RDB/VMS V3.0 1-1
_________________________________________________
1.2 CONVERSION CONSIDERATIONS 1-2
1.2.1 Previous Databases
Incompatible with V3.0
Software 1-2
1.2.2 Deleting Obsolete Module
from System Help Library 1-3
_________________________________________________
1.3 MULTIFILE DATABASES 1-3
1.3.1 Space Management Options
for Multifile Databases 1-5
1.3.2 Hashed Indexes 1-5
1.3.3 Segmented Strings in PAGE
FORMAT MIXED Storage
Areas 1-7
1.3.4 Shadow Pages 1-7
_________________________________________________
1.4 SUPPORT FOR VAX CDD/PLUS V4.0 1-7
_________________________________________________
1.5 NEW AND CHANGED RDO STATEMENTS 1-8
1.5.1 EXPORT and IMPORT
Statements 1-8
iii
Contents
1.5.2 Stream Handling
Statements 1-9
1.5.3 PLACE Statement 1-9
1.5.4 RECOVER and TRACE
Statement Enhancements 1-10
1.5.5 Recovery Buffers 1-11
_________________________________________________
1.6 NEW AND CHANGED RMU COMMANDS 1-11
1.6.1 RMU/ANALYZE Replaces RDO
ANALYZE 1-11
1.6.2 RMU/ANALYZE/INDEX
Statement 1-12
1.6.3 RMU/BACKUP 1-12
1.6.4 RMU/COVERT Replaces RDO
CONVERT 1-12
1.6.5 RMU/RESTORE 1-12
1.6.6 RMU/VERIFY 1-13
1.6.7 RMU/SHOW STATISTICS
Enhancements 1-13
1.6.8 RMU/DUMP/BACKUP 1-13
1.6.9 Access Rights and
Privileges Checking 1-13
_________________________________________________
1.7 MISCELLANEOUS PERFORMANCE
ENHANCEMENTS 1-14
1.7.1 New Multi-Attribute
Retrieval Algorithm 1-14
1.7.2 Cardinality for Non-Unique
Indexes 1-15
1.7.3 AIJ File Enhancements 1-15
1.7.4 Relational Join
Performance 1-15
iv
Contents
1.7.5 Tuning for High
Transaction Rates 1-15
1.7.5.1 Adjustable Lock Granularity Can
Be Disabled 1-16
1.7.5.2 RDMS$AUTO_READY Logical Name 1-17
_________________________________________________
1.8 NEW LOGICAL NAME:
RDMS$BIND_SORT_WORKFILES 1-18
_________________________________________________
1.9 USE RDML PREPROCESSOR WITH
RDB/PASCAL 1-18
_________________________________________________
1.10 MCS CHARACTERS PERMITTED IN NAMES 1-19
_________________________________________________
1.11 DATABASE-WIDE PARAMETERS SUPPORTED
FOR CHANGE DATABASE 1-19
_________________________________________________
1.12 CHANGE/DELETE DATABASE NOW WORK ON
REMOTE DATABASES 1-19
_________________________________________________
1.13 NEW SYSTEM RELATION:
RDBVMS$INTERRELATIONS 1-20
_________________________________________________
1.14 RDBSHR.EXE INSTALLED ON MONITOR
STARTUP 1-21
_________________________________________________
1.15 NUMBER OF VAXCLUSTER NODES: 64 NOW
SUPPORTED 1-21
_________________________________________________
1.16 DOCUMENTATION TITLE CHANGES 1-21
v
Contents
_________________________________________________
1.17 RDML NEW FEATURES AND CHANGES 1-22
1.17.1 Enhancements to RDML
Permit Intermodule
Communication 1-22
1.17.1.1 Change in RDML Variable Names
1-23
1.17.1.2 RDML Databases Default Scope
Changed 1-24
1.17.1.3 New /LINKAGE Qualifier with the
RDML Command 1-24
1.17.1.4 New Qualifier to Initialize
Handles 1-26
1.17.2 GET Statement Added to
RDML Syntax 1-27
1.17.3 Enhancements to STORE
Statement 1-28
1.17.4 RDML/[NO]DEFAULT_TRANSACTIONS
Qualifier 1-29
1.17.5 DATABASE Statement DBKEY
SCOPE Clause 1-30
1.17.6 START_TRANSACTION
Statement: ON and
EVALUATING Clauses 1-30
1.17.7 Context-Variable.*
with STORE and MODIFY
Statements 1-30
vi
Contents
_______________________________________________________
CHAPTER 2 SOFTWARE ERRORS FIXED 2-1
_________________________________________________
2.1 DATABASE ADMINISTRATION AND
MAINTENANCE 2-1
2.1.1 CONTROL Access Right to a
Database 2-1
2.1.2 Incorrect Cardinality
Maintained 2-2
2.1.3 RESTORE Statement 2-2
_________________________________________________
2.2 DATA DEFINITION AND DATA
MANIPULATION 2-2
2.2.1 Views and Conditional
Expressions 2-3
2.2.2 CHANGE DATABASE
Statement 2-5
2.2.3 CHANGE FIELD Statement and
Views 2-5
2.2.4 DESCRIPTION IS Clause and
SHOW INDEX Statement 2-5
2.2.5 Defining a Default Value
of Data Type TEXT for
DATATRIEVE 2-6
2.2.6 Invoking Two Databases in
the Same RDO Session 2-7
2.2.7 Estimated Cost of Indexed
Retrieval for a BETWEEN
Operation 2-8
2.2.8 Deadlocks on
START_TRANSACTION 2-9
_________________________________________________
2.3 PROGRAMMING 2-10
2.3.1 RDML Checks for Proper
Statement Termination 2-10
vii
Contents
2.3.2 Path Name and the RDML
DATABASE Statement 2-11
2.3.3 RDML START_STREAM
Statement 2-12
2.3.4 STORE Statement With
Segmented Strings 2-12
2.3.5 FOR Segmented String
Statement 2-12
2.3.6 Pascal [HIDDEN] Attribute
in RDML/Pascal 2-13
2.3.7 Success Status Returned
on START_TRANSACTION
Failures 2-13
_______________________________________________________
CHAPTER 3 PROBLEMS, RESTRICTIONS, AND OTHER
NOTES 3-1
_________________________________________________
3.1 GENERAL INFORMATION 3-1
3.1.1 RDBVMS$PARAMETERS Logical
Name 3-1
3.1.2 Rdb/VMS V3.0 Not Supported
During VAXcluster Rolling
Upgrade 3-2
3.1.3 VMS V4.7 or Higher
Required 3-2
3.1.4 VAX DATATRIEVE V4.2 or
Higher Required 3-2
3.1.5 VAX Data Distributor V2.0
or Higher Required 3-2
3.1.6 VAX TEAMDATA Versions 1.1
and 1.2 3-2
3.1.7 Cross-Product Manuals Do
Not Include New Features 3-3
_________________________________________________
viii
Contents
3.2 DATABASE ADMINISTRATION AND
MAINTENANCE 3-3
3.2.1 Avoid Having Single-File
Databases with Same
Names 3-3
3.2.2 INTEGRATE Operation Must
Terminate with COMMIT 3-4
3.2.3 RMU/CONVERT Requires AIJ
Be Disabled 3-4
_________________________________________________
3.3 DATA DEFINITION AND DATA
MANIPULATION 3-4
3.3.1 Relation Name Must Match
Dictionary Record Name 3-5
3.3.2 No Data Type Checking on
Limit Clause 3-5
3.3.3 Field Definition Change
and Invalid Data 3-6
3.3.4 Performance Suggestion for
Hashed Index Use 3-7
_________________________________________________
3.4 PROGRAMMING 3-8
3.4.1 Conversion and
Coexistence: RDBPASCAL and
RDML/Pascal 3-9
3.4.2 Problems Converting from
RDBPASCAL to RDML/Pascal 3-12
3.4.3 RDML Problem with Embedded
Comments in C Literals 3-13
3.4.4 RDBPRE Problem with
START_SEGMENTED_STRING 3-14
_________________________________________________
3.5 DSRI PROBLEMS AND RESTRICTIONS 3-15
ix
Contents
3.5.1 Do Not Enable the
VMS System Service
SYS$SETSFM 3-15
3.5.2 Unsupported Calls 3-15
3.5.3 Passing Invalid BLR with
RDB$COMPILE_REQUEST 3-16
3.5.4 RDB$EXTENSION Call
Restriction 3-17
_______________________________________________________
APPENDIX A NOTES FOR SYSTEMS WITH BOTH RDB/VMS
AND RDB/ELN A-1
_________________________________________________
A.1 NEW ENTRY POINTS A-1
A.2 Preprocessing VAX C
Programs Using RDML A-2
[The Release Notes for Rdb/VMS V3.0A and V3.0B follow the
material for V3.0.]
x
_______________________________________________________
Preface for Rdb/VMS V3.0 Release Notes
VAX Rdb/VMS software, Version 3.0, often referred to
as Rdb/VMS V3.0 in this manual, is a general purpose
database management system based on the relational
data model.
This manual describes new and changed features,
problems fixed in this release, and current problems,
restrictions, and other notes.
Note: The V3.0 release notes are supplied both in printed
form and in online form (in SYS$HELP). The printed
form was prepared for production after the online form;
thus, information in the printed form is more up-to-
date. [The V3.0A and V3.0B release notes are supplied in
online form only (after the V3.0 notes in this file).]
__________________________________________________________________
Intended Audience
These release notes are intended for all users of
Rdb/VMS, and should be read to supplement information
contained in the Rdb/VMS and the VAX SQL documentation
sets.
To get the most out of this manual, you should be
familiar with Rdb/VMS, data processing procedures, and
basic database management concepts and terminology.
xi
Preface
__________________________________________________________________
Operating System Information
Information about the versions of the operating system
and related software that are compatible with this
version of Rdb/VMS is included in the Rdb/VMS media
kit and the VAX Rdb/VMS Installation Guide.
For information of the compatibility of other software
products with this version of Rdb/VMS, refer to the
System Support Addendum (SSA) that comes with the
Software Product Description (SPD). You can use the
SPD/SSA to verify which versions of your operating
system are compatible with this version of Rdb/VMS.
__________________________________________________________________
Structure
This manual contains three chapters and an appendix:
Chapter 1 Summarizes the new and changed
features of Rdb/VMS V3.0.
Chapter 2 Describes known software errors that
were fixed in Rdb/VMS V3.0.
Chapter 3 Describes problems, restrictions, and
workarounds known to exist in Rdb/VMS
as of V3.0; may also include other
information.
Appendix A Contains notes for systems with both
Rdb/VMS and Rdb/ELN
[The V3.0A and V3.0B notes follow Appendix A.]
xii
Preface
__________________________________________________________________
Related Manuals
For more information on VAX Rdb/VMS, see the following
manuals in the VAX Rdb/VMS and VAX SQL documentation
sets:
o VAX Rdb/VMS Installation Guide
A complete description of the steps to follow
before, during, and after the installation of
Rdb/VMS
o VAX Rdb/VMS Reference Manual
A complete description of the statements and syntax
of the RDO interface to Rdb/VMS
o VAX Rdb/VMS Guide to Programming
A detailed user's guide on how to write high-level
language programs that use Rdb/VMS for database
access
o VAX Rdb/VMS Guide to Data Manipulation
A tutorial on how to use the components of Rdb/VMS
to retrieve, store, change, and erase data
o VAX Rdb/VMS Guide to Database Design and Definition
A tutorial that explains how to design a logical
database and how to translate that design into a
physical database using Rdb/VMS data definition
statements
o VAX Rdb/VMS Guide to Database Maintenance and
Performance
A tutorial that explains how to use the database
maintenance utilities to perform such operations as
backup, recovery, restoring journals, and analyzing
the database
o RDML Reference Manual
A reference manual that describes the Relational
Data Manipulation Language (RDML)
xiii
Preface
o VAX SQL Reference Manual
A complete description of the statements and syntax
of VAX SQL
o VAX SQL User's Guide
Detailed information and examples on creating,
modifying, and manipulating data in Rdb/VMS
databases using VAX SQL
o VAX SQL Release Notes
Describes new features, problems fixed, and
problems and restrictions relating to the current
version of the VAX SQL interface to Rdb/VMS
o VAX SQL Installation Guide
A complete description of the steps to follow
before, during, and after the installation of VAX
SQL
__________________________________________________________________
Conventions
This section explains the conventions used in this
manual:
xiv
Preface
< > Angle brackets enclose user-supplied
names.
Vertical ellipsis means that irrelevant
. information has been omitted.
.
.
CTRL/x Means that while holding down the CTRL
key, press the designated key (for
example, CTRL/C).
__________________________________________________________________
References to Products
The Rdb/VMS documentation to which this document
belongs often refers to products by their abbreviated
names:
o VAX ACMS software is referred to as ACMS.
o VAX BASIC software is referred to as BASIC.
o VAX C software is referred to as C.
o VAX CDD/Plus software is referred to as CDD/Plus or
the data dictionary.
o VAX COBOL software is referred to as COBOL.
o VAX DATATRIEVE software is referred to as
DATATRIEVE.
o VAX DATA DISTRIBUTOR software is referred to as
Data Distributor.
o VAX FORTRAN software is referred to as FORTRAN.
o VAXELN Pascal and VAX Pascal are both referred to
as Pascal except when the use of a Relational Data
Manipulation Language (RDML) statement is not the
same in the VAXELN and VMS environment. In the
xv
Preface
latter case, either VAXELN Pascal or VAX Pascal is
specified.
o VAX Rdb/VMS software is referred to as Rdb/VMS.
o VAX SQL software is referred to as SQL.
o VAX TEAMDATA software is referred to as TEAMDATA.
o VAX TDMS software is referred to as TDMS.
o VIDA with IDMS/R software is referred to as VIDA.
xvi
_______________________________________________________
1 New and Changed Features
This chapter provides a summary of the new features
and technical changes in Rdb/VMS Version 3.0. It also
contains information on converting pre-V3.0 databases
to the V3.0 format.
__________________________________________________________________
1.1 VAX SQL Included with Rdb/VMS V3.0
VAX SQL is packaged with Rdb/VMS at Version 3.0.
That is, Rdb/VMS V3.0 users are able to use VAX SQL
in addition to RDO, RDML, and RDBPRE as interfaces,
without having to obtain a separate VAX SQL license.
The Rdb/VMS documentation for Version 3.0 does not
reflect the full integration of the VAX SQL interface
into the Rdb/VMS product. The Rdb/VMS manuals retain
their focus on RDO, RDML, and RDBPRE; however,
this focus results from V3.0 schedule and resource
considerations. For future releases the manuals will
also include SQL in their terminology and examples,
with adequate coverage of RDO and RDML. Note, however,
that the VAX SQL manuals are packaged with the Rdb/VMS
manuals for V3.0, thus providing essential tutorial
and reference information on VAX SQL.
Users are encouraged to install and use VAX SQL as an
alternative to RDO and RDML. Note that RDO and RDML
applications will continue to be supported.
When installing the software, install Rdb/VMS V3.0
first and then VAX SQL. Refer to the VAX SQL Release
Notes and the VAX SQL Installation Guide before
installing VAX SQL.
1-1
New and Changed Features
__________________________________________________________________
1.2 Conversion Considerations
This section details the factors you must consider
when upgrading your system to Rdb/VMS V3.0.
___________________________
1.2.1 Previous Databases Incompatible with V3.0 Software
The internal structure of the .RDB file changed in
Rdb/VMS V3.0 to provide improved performance. You
must prepare for the conversion of previous Rdb/VMS
database before you can install V3.0 software.
The pre-installation and post-installation steps
are covered in the VAX Rdb/VMS Installation Guide.
Briefly, you perform these tasks:
1 Make sure all existing Rdb/VMS databases are
recovered before installing the V3.0 software. The
recovery-unit journal (RUJ) files created prior the
V3.0 cannot be applied to V3.0 Rdb/VMS databases
due to internal structure differences.
2 Back up all existing databases by using the the
VMS Backup utility. For any existing databases that
you plan to restructure into multifile databases,
use the RDO BACKUP statement to back them up after
using the VMS Backup utility.
3 Install V3.0 software.
4 Use RMU/CONVERT to convert V2.3 single-file
databases into V3.0 single-file databases. Use
the RDO IMPORT statement to convert and restructure
a V2.3 single-file database into a V3.0 multifile
database.
IMPORTANT: Once a database (RDB) file is converted to a
higher version, you cannot use that database file with
an earlier version of Rdb/VMS.
1-2
New and Changed Features
___________________________
1.2.2 Deleting Obsolete Module from System Help Library
If you are upgrading your system from a version
of Rdb/VMS prior to the V2.3 version to Rdb/VMS
V3.0, enter the following command after the V3.0
installation completes to remove an obsolete module
from the system Help library:
$ LIBRARY/HELP/DELETE=RDB SYS$COMMON:[SYSHLP]HELPLIB.HLB/LOG
%LIBRAR-S-DELETED, module RDB deleted from SYS$HELP:HELPLIB.HLB
The Help module that contained a summary of the
Rdb/VMS product that existed prior to V2.3 was called
RDB. Starting in V2.3, this Help module is called
RDBVMS. Note that if you installed Rdb/VMS V2.3 but
never deleted this module, you should do so either
before or after installing Rdb/VMS V3.0.
__________________________________________________________________
1.3 Multifile Databases
Prior to V3.0, Rdb/VMS created only single-file
databases, in which all data is stored in a single
database file (default file type RDB), and a snapshot
file (default file type SNP) is created for the entire
database. You can still create a single-file database
with V3.0; and in most cases, the ease of creating
and maintaining a single-file database will probably
outweigh any performance improvements resulting from
the use of a multifile database.
However, with Rdb/VMS V3.0, you can optionally define
multifile databases. A multifile database consists of
a root (RDB) file, and one or more storage area (RDA)
files and snapshot (SNP) files. One snapshot file is
created for each storage area file. As with a single-
file database, each multifile database has an optional
after-image journal (AIJ) file, and a recovery-unit
journal (RUJ) file is created for each user while the
user is running a READ_WRITE transaction.
1-3
New and Changed Features
The root file in a multifile database does not contain
user data; instead, this file contains only metadata
and information about the entire database (for
instance, whether after-image journaling is enabled,
and if so, the full file specification of the after-
image journal).
When you create at least one storage area file,
the database is considered by Rdb/VMS to be a
multifile database. If you define a database without
specifying any storage area files, the database is
considered by Rdb/VMS to be a single-file database.
If you wish to convert a single-file database to a
multifile database, you must use the EXPORT and IMPORT
statements in RDO.
Multifile databases offer the following potential
benefits:
o Support for very large databases
Your database is not limited to the capacity of
a single disk pack. You can spread the database
across many disks.
o Performance improvement for database applications
By defining multiple storage area files, you can
distribute your files across many disks on your
system and eliminate the possibility of any single
disk becoming a performance bottleneck.
A potential disadvantage of using multifile
databases is that database design and definition
is more complex, and managing more files will very
likely require additional tasks for the database
administrator. For information on designing, defining,
and maintaining multifile databases, see the VAX
Rdb/VMS Guide to Database Design and Definition and
the VAX Rdb/VMS Guide to Database Maintenance and
Performance.
1-4
New and Changed Features
The following subsections describe new features that
apply only to multifile databases.
___________________________
1.3.1 Space Management Options for Multifile Databases
In multifile database storage areas where the page
format is defined as MIXED, you can use two options
to control how space management (SPAM) is performed in
each database storage area file. You can control how
many data pages each SPAM page manages (the interval
of SPAM pages in each storage area file) and you can
set three threshold values associated with the SPAM
page free space inventory lists.
Space management is used in single-file databases and
in multifile database storage areas using UNIFORM page
formats. However, you cannot control the INTERVAL and
THRESHOLD values for these files. In area files where
the page format is UNIFORM, Rdb/VMS always knows the
(single) size of records that can be stored on a given
page. Consequently, Rdb/VMS maintains simplified SPAM
entries for data pages; each SPAM entry indicates
whether the data page can or cannot hold one more of
the particular record type. The INTERVAL and THRESHOLD
parameters discussed in this chapter are not important
to single file databases or to multifile, UNIFORM page
format storage area files.
___________________________
1.3.2 Hashed Indexes
To optimize access of specific records by index key
value, you can define hashed indexes. Hashed indexes
can be defined only in multifile databases. (A single-
file database can have only sorted (B-tree) indexes; a
multifile database can have sorted and hashed indexes.
In fact, it is possible to create both a sorted index
and hashed index on the same field or combination of
fields.)
1-5
New and Changed Features
Hashed indexes provide direct access to a record
when your query specifies the full hash key and uses
equality (=) as the access criterion. For example,
assume that a hashed index had been defined for
the EMPLOYEES relation when John Smith's record was
stored, and the key field was EMPLOYEE_ID (Smith's
identification number is 15231). Rdb/VMS will use the
hashing algorithm to directly access Smith's record
when the following query is entered:
RDO> FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = "15231"
cont> PRINT E.* END_FOR
Hashed indexes are useful when your query needs
direct access to a specific record. However, retrieval
performance will improve if you create sorted indexes
for those queries that perform range retrievals. For
example, if a hashed index and a sorted index are both
defined for the EMPLOYEES relation and EMPLOYEE_ID is
the key field, the Rdb/VMS optimizer will correctly
choose the sorted index (over the hashed index) for
the following query:
RDO> FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID GT "00190" AND
cont> E.EMPLOYEE_ID LT "15231"
cont> PRINT E.*
cont> END_FOR
If there is a hashed index but no sorted index
defined, the Rdb/VMS optimizer will choose sequential
access for the preceding query.
1-6
New and Changed Features
___________________________
1.3.3 Segmented Strings in PAGE FORMAT MIXED Storage Areas
Segmented strings can be placed in PAGE FORMAT MIXED
storage areas. If you have segmented strings of
varying length, you might wish to use SPAM (space
management) pages to optimize searching for free
space.
However, if segmented strings are placed in a PAGE
FORMAT MIXED storage area, it is strongly recommended
that the MIXED storage area contain only segmented
strings.
___________________________
1.3.4 Shadow Pages
If you define a relation in one storage area and the
hashed index for that relation in another, Rdb/VMS
will use shadow pages.
See the VAX Rdb/VMS Guide to Database Maintenance and
Performance for information on shadow pages.
__________________________________________________________________
1.4 Support for VAX CDD/Plus V4.0
Rdb/VMS V3.0 fully supports CDD/Plus Version 4.0. This
enables you to:
o Define global field and record definitions in a
shareable dictionary
o Directly copy the field and/or record definition(s)
from the dictionary to an Rdb/VMS database when
you define new Rdb/VMS fields or relations using
the VAX SQL interface or the Relational Database
Operator (RDO) utility interface.
o Receive informational messages about the use of
shared VAX CDD/Plus field and record definitions by
other Rdb/VMS databases
1-7
New and Changed Features
o Integrate shareable dictionary definitions into
an Rdb/VMS database (INTEGRATE DATABASE ... FROM
PATHNAME) or integrate database definitions to
a VAX CDD/Plus dictionary directory (INTEGRATE
DATABASE ... IN PATHNAME)
For information about the Rdb/VMS and VAX CDD/Plus
environment, see the following:
o VAX Rdb/VMS Guide to Database Design and Definition
o VAX CDD/Plus User's Guide
__________________________________________________________________
1.5 New and Changed RDO Statements
The following sections describe new RDO statements
and significant changes to existing RDO statements.
For detailed information on any statement, see the VAX
Rdb/VMS Reference Manual.
___________________________
1.5.1 EXPORT and IMPORT Statements
The new RDO EXPORT statement replaces the existing
RDO BACKUP statement, and the new RDO IMPORT statement
replaces the RDO RESTORE statement. All new options
will be added to the IMPORT and EXPORT statements.
The RESTORE and BACKUP statements are maintained for
compatibility with applications that use previous
versions of Rdb/VMS. However, DIGITAL recommends the
use of the IMPORT statement rather than the RESTORE
statement, and the use of the EXPORT statement rather
than the BACKUP statement.
Use EXPORT and IMPORT statements for migrating
a database from one DIGITAL Standard Relational
Interface (DSRI) system to another; for example,
from Rdb/ELN to Rdb/VMS. For regular backups and
restorations of Rdb/VMS databases, use the RMU/BACKUP
1-8
New and Changed Features
and RMU/RESTORE commands described in VAX Rdb/VMS
Reference Manual.
You can also use the EXPORT and IMPORT statements to:
o Restructure a pre-V3.0 Rdb/VMS single-file database
into multifile database (having at least one
storage area (RDA) file)
o Restructure a single-file database created with
V3.0 (no DEFINE STORAGE AREA clause used when
database was defined) into a multifile database
o Archive database information in a format that can
be read by future releases of Rdb/VMS.
See the VAX Rdb/VMS Reference Manual for details on
the EXPORT and IMPORT statements.
___________________________
1.5.2 Stream Handling Statements
RDB/VMS V3.0 includes the new DECLARE_STREAM
statement, a new form of the START_STREAM statement,
and enhancements to the END_STREAM statement. These
changes allow you to use the components of a stream
(START_STREAM, FETCH, and END_STREAM) in any order,
and make conditional programming easier. Additionally,
the ON ERROR clause may now be specified in the END_
STREAM statement.
___________________________
1.5.3 PLACE Statement
The PLACE statement is now available with the RDO
utility and Callable RDO. This statement uses the
format of the STORE statement, but does not actually
store a record; instead, it returns the dbkey of the
specified record. The following example illustrates
the PLACE statement format:
1-9
New and Changed Features
[Example in V3.0 printed Release Notes is
incorrect. See the note on the PLACE statement in
the Rdb/VMS V3.0A Release Notes, Chapter 1.]
The PLACE statement is intended to be used only
in programs that load data into a database. It is
intended to be used only with records for which a
hashed index has been defined. When used properly, the
PLACE statement can result in significant performance
improvements in database load procedures that specify
PLACEMENT VIA a hashed index.
The general strategy for using the PLACE statement
effectively is as follows:
o For each record to be stored, get the dbkey (that
is, the page where the record would be stored).
o Place all the dbkeys somewhere (usually a file);
sort in ascending sequence.
o Read the records in the order of the sorted dbkeys,
and write the records to the database.
Thus, the records are still distributed randomly (that
is, stored where the hashing algorithm places them);
however, all records that are to be written to a given
physical page are written out at the same time.
___________________________
.3.3 1.5.4 RECOVER and TRACE Statement Enhancements
A new option in the RECOVER statement that allows you
to speed the recovery process by specifying the number
of database buffers and a new TRACE option to display
details of the recovery process.
1-10
New and Changed Features
___________________________
1.5.5 Recovery Buffers
You can specify the number of database buffers used
during the automatic recovery process. The NUMBER OF
RECOVERY BUFFERS option has been added to the DEFINE
DATABASE, CHANGE DATABASE, and IMPORT statements.
__________________________________________________________________
1.6 New and Changed RMU Commands
Rdb/VMS V3.0 contains the following new Rdb/VMS
Management Utility (RMU) commands and changes to
existing commands. (RMU commands are executed at the
VMS system prompt.) For detailed information on RMU
commands, see the VAX Rdb/VMS Reference Manual.
___________________________
1.6.1 RMU/ANALYZE Replaces RDO ANALYZE
The RMU/ANALYZE command should be used to analyze a
database and database usage. This command supersedes
the RDO ANALYZE statement.
The RMU/ANALYZE command gathers and displays
information on how storage is being used in the
database. It generates a formatted display of
statistical information describing the storage
utilization in the database. Information is displayed
selectively for storage areas and logical areas or for
a range of pages in a storage area. For example:
$ RMU/ANALYZE/AREAS=(EMPIDS_LOW,EMP_INFO)/OUT=EMP.OUT PERSONNEL.RDB
Format:
RMU/ANALYZE root-file-spec
1-11
New and Changed Features
___________________________
1.6.2 RMU/ANALYZE/INDEX Statement
The new command RMU/ANALYZE/INDEX generates a
formatted display of statistical information
describing one or more of the index structures for
this database. For example:
$ RMU/ANALYZE/INDEX PERSONNEL.RDB JH_EMPLOYEE_ID,SH_EMPLOYEE_ID
Format:
RMU/ANALYZE/INDEX root-file-spec [index-name[,...]]
___________________________
1.6.3 RMU/BACKUP
RMU/BACKUP performs a full or incremental backup of an
Rdb/VMS database. During an online backup, other users
may be bound to the database and execute any type of
transaction that does not conflict with the READ_ONLY
online backup transaction.
___________________________
1.6.4 RMU/COVERT Replaces RDO CONVERT
The RDO CONVERT statement is obsolete. Use RMU/CONVERT
to convert databases instead.
___________________________
1.6.5 RMU/RESTORE
RMU/RESTORE restores a database to the condition it
was in at the time of a full or incremental backup.
Reintegration of the metadata stored in the root (RDB)
file with the VAX CDD/Plus data dictionary occurs
optionally during the database restoration, and is
only possible if VAX CDD/Plus is installed on your
system.
1-12
New and Changed Features
___________________________
1.6.6 RMU/VERIFY
RMU/VERIFY checks and verifies the internal integrity
of database data structures.
___________________________
1.6.7 RMU/SHOW STATISTICS Enhancements
The RMU/SHOW STATISTICS command has been enhanced to
display useful information about multifile databases.
Refer to VAX Rdb/VMS Reference Manual for information
about using the RMU/SHOW STATISTICS command and the
new RDO ANALYZE PARTITIONS statement.
___________________________
1.6.8 RMU/DUMP/BACKUP
The RMU/DUMP/BACKUP command has been added. The format
is as follows:
RMU/DUMP/BACKUP[/REWIND][/BLOCK_SIZE=n][/ACTIVE_IO=n]
[/OUTPUT=file][/OPTIONS=list][/SKIP=list]
[/PROCESS=list] backup_file
___________________________
1.6.9 Access Rights and Privileges Checking
RMU operations now check for access rights and
privilege as follows.
o RMU/MONITOR requires VMS WORLD privilege.
o RMU/BACKUP, RMU/BACKUP/AFTER_JOURNAL, and
RMU/VERIFY require at least one of the following:
VMS SYSPRV, VMS BYPASS, DB ADMIN+READ, DB
OPER+READ.
o RMU/BACKUP additionally requires VMS READ access to
all database files and VMS WRITE access to the root
(RDB) file for full backups. This access must be
1-13
New and Changed Features
granted by the database's owner or a user with the
SYSPRV privilege.
The only accounts that normally have sufficient
privileges to perform full backups are the SYSTEM
account and accounts with the SYSPRV or BYPASS
privilege.
o RMU/DUMP (database dump) requires at least one
of the following: VMS SYSPRV, VMS BYPASS, DB
ADMIN+READ.
o RMU/SHOW requires at least one of the following:
VMS SYSPRV, VMS BYPASS, DB ADMIN, DB OPER.
o RMU/SHOW options without a database specified
require VMS WORLD privilege.
o RMU/DUMP/AFTER_JOURNAL, RMU/DUMP/RECOVERY_JOURNAL,
and RMU/DUMP/BACKUP_FILE require the appropriate
file access.
__________________________________________________________________
1.7 Miscellaneous Performance Enhancements
Numerous performance enhancements have been
made to the Rdb/VMS V3.0 software. Some of the
more significant are described in the following
subsections.
___________________________
1.7.1 New Multi-Attribute Retrieval Algorithm
A new algorithm may improve performance when the
AND logical operator is part of a record selection
expression (RSE) that retrieves data on the basis of
indexed fields.
1-14
New and Changed Features
___________________________
1.7.2 Cardinality for Non-Unique Indexes
Cardinality is maintained for non-unique indexes.
Prior to this release, Rdb/VMS did not maintain
cardinality on the number of values stored in an
index. With this release, Rdb/VMS will maintain
cardinality on these values and thus be better able
to determine which index to use for retrieval when two
or more non-unique indexed fields are specified in a
query.
___________________________
1.7.3 AIJ File Enhancements
You can specify the amount of disk space initially
allocated to the after-image journal file, the size
of after-image journal file extensions, and the number
of buffers that Rdb/VMS should use when the RECOVER
statement is executing. These options can improve
performance significantly.
___________________________
1.7.4 Relational Join Performance
Rdb/VMS includes improved code that, under certain
circumstances, may reduce the number of I/O operations
needed to perform a relational join (RDO CROSS clause)
and thereby may improve performance.
___________________________
1.7.5 Tuning for High Transaction Rates
The new features summarized in this section are
designed especially to permit tuning for applications
requiring high transaction rates. Note, however, that
they are intended only for use in special situations
and by sophisticated users; improper use may result in
no benefit or an adverse effect on performance.
1-15
New and Changed Features
_____________________
1.7.5.1 Adjustable Lock Granularity Can Be
Disabled
You can now disable adjustable lock granularity
(ALG) with the DEFINE DATABASE and CHANGE DATABASE
statements. The syntax of the clause for both
statements is:
ADJUSTABLE LOCK GRANULARITY is {ENABLED | DISABLED}
Enabled is the default.
In general, enabling ALG results in fewer locks
being used, because it uses one lock for a group
of contiguous pages. However, when contention for
pages in the database is very high, ALG can use up a
great deal of CPU as it adjusts the lock granularity
downwards.
At the application level, you might want ALG enabled
if the application processes groups of records (FIND
ALL EMPLOYEES IN COST_CENTER 947) and performs a
substantial number of retrieval operations. You might
want ALG disabled if the application processes very
specific records (FIND EMPLOYEE WITH EMPLOYEE_ID =
59401) and performs a substantial number of update
operations.
The best general guideline is to start with ALG
enabled and then, if CPU time utilization is a
problem, change to ALG disabled to see if that makes a
difference.
Disabling ALG may require that the VMS SYSGEN
parameters for locks be increased (since the total
number of locks will likely increase).
1-16
New and Changed Features
_____________________
1.7.5.2 RDMS$AUTO_READY Logical Name
A new logical name, RDMS$AUTO_READY, can be used under
very limited circumstances to cut the overhead of the
lock management.
Normally, when the user does not specify a RESERVING
clause as part of a START_TRANSACTION READ_WRITE,
Rdb/VMS locks relations in whatever mode is necessary
to complete each operation. For example, a lookup by
index of a record will take out a shared read lock on
the relation and on the index (that is, the equivalent
of having reserved them for shared read). Then, if the
record is modified, the relation lock is upgraded to
shared write. So, two lock operations were required
instead of one (that is, obtain a Concurrent Read lock
and then upgrade it to Concurrent Update, rather than
just obtaining a Concurrent Update lock in the first
place).
In the past, users have been encouraged to use
the RESERVING clause to specify the minimum mode
that the relation should be locked in. So, the
previously described "problem" could be avoided by
reserving the relation for Shared Write. However,
with partitioned relations the RESERVING clause
must lock each partition, resulting in considerable
overhead. This overhead can be avoided by leaving out
the reserving clause and allowing Rdb/VMS to "auto-
ready" only the partitions it must touch, leading back
to the previously described extraneous lock operation
problem.
Assigning RDMS$AUTO_READY the value "U" will eliminate
the two-tiered structure of locking the area for
concurrent read and then upgrading to concurrent
update, by converting the initial read requests to
update requests. This will only happen in a READ_WRITE
transaction with no RESERVING clause.
1-17
New and Changed Features
Defining RDMS$AUTO_READY as "U" should be done only
in transaction-oriented applications where no (or
very nearly no) sequential access is performed
(within a read_write transaction) and the Protected
Read/Write modes are avoided. In other words, this
feature will have similar conflict characteristics
to every START_TRANSACTION READ_WRITE containing a
RESERVING...SHARED WRITE for each relation accessed
within the transaction.
In general, it is suggested that you not define
RDMS$AUTO_READY as "U". Although it may save a little
CPU overhead, and may be particularly beneficial
on a VAXcluster or symmetrical multiprocessing
(SMP) system, the potential for a reduction in
concurrency argues against its use for all but the
most sophisticated users.
__________________________________________________________________
1.8 New Logical Name: RDMS$BIND_SORT_WORKFILES
RDMS$BIND_SORT_WORKFILES is a new logical name whose
equivalence name specifies how many workfiles SORT
is to use if workfiles are required. The default is 2
(the VAX SORT default) and the maximum is 10.
The workfiles can be individually controlled by the
SORTWORKn logical names (where n is from 0-9).
__________________________________________________________________
1.9 Use RDML Preprocessor with Rdb/Pascal
The Rdb/Pascal precompiler is no longer supplied,
because the RDML preprocessor support of the PASCAL
language is now fully compatible to the Rdb/Pascal
precompiler.
Please convert your sources to RDML/Pascal as soon as
possible and use RDML/Pascal henceforth. Starting with
Rdb/VMS V3.0, RDML/Pascal is the only supported method
to preprocess Pascal programs.
1-18
New and Changed Features
__________________________________________________________________
1.10 MCS Characters Permitted in Names
Prior versions of Rdb/VMS did not permit the use
of Digital's Multinational Character Set in field,
relation, etc., names. These characters are now
permitted.
Note, however, that MCS collation is not implemented.
For example, when sorting is specified for a field,
the values are sorted according to the ASCII character
set; also, ASCII sequence is used for the output of
the SHOW commands (SHOW FIELDS, SHOW RELATIONS, etc.).
__________________________________________________________________
1.11 Database-Wide Parameters Supported for CHANGE DATABASE
The following database-wide parameters can be changed
using the CHANGE DATABASE command:
o NUMBER OF BUFFERS IS numeric-literal
o NUMBER OF RECOVERY BUFFERS IS numeric-literal
o NUMBER OF USERS IS numeric-literal (multi-file
only)
o NUMBER OF VAXCLUSTER NODES IN numeric-literal
(multi-file only)
o DICTIONARY {IS | IS NOT} REQUIRED
__________________________________________________________________
1.12 CHANGE/DELETE DATABASE Now Work on Remote Databases
The CHANGE DATABASE and DELETE DATABASE statements now
work when a database on a remote node is specified.
1-19
New and Changed Features
__________________________________________________________________
1.13 New System Relation: RDBVMS$INTERRELATIONS
Rdb/VMS V3.0 uses a new system relation,
RDBVMS$INTERRELATIONS. This system relation is created
when a new database is created and when a pre-V3.0
database is converted to the V3.0 format.
In previous releases of Rdb/VMS, whenever a user
attempted to delete a relation or a field in a
relation, Rdb/VMS searched the database for views,
constraints, and computed fields which referenced the
fields being deleted, so that the user would not be
permitted to delete a field which was still referenced
and thus cause failures later.
To improve the performance of the CHANGE RELATION and
DELETE RELATION DDL operations, this algorithm was
changed by including a new Rdb/VMS-specific system
relation, RDBVMS$INTERRELATIONS, which has entries
added to it during DEFINE CONSTRAINT, DEFINE VIEW,
and DEFINE STORAGE MAP operations and during the
definition of computed fields. Now, before deleting
a relation or a field in a relation, Rdb/VMS first
checks RDBVMS$INTERELATIONS to determine whether or
not there is a conflicting reference.
If you should report a problem to DIGITAL pertaining
to deletion of a relation or a field, and if you do
not submit a copy of the database, please include the
listing generated by the following command:
FOR R IN RDBVMS$INTERRELATIONS PRINT R.* END_FOR
1-20
New and Changed Features
__________________________________________________________________
1.14 RDBSHR.EXE Installed on Monitor Startup
With V3.0, RDBSHR.EXE is installed on monitor startup
(that is, when SYS$MANAGER:RMONSTART.COM is run).
If the image is already installed, it will not be
replaced, but it will be deinstalled upon running
SYS$MANAGER:RMONSTOP. This change is designed to
simplify the installation and use of VAX products that
use or depend upon Rdb/VMS.
__________________________________________________________________
1.15 Number of VAXcluster Nodes: 64 Now Supported
The NUMBER OF VAXCLUSTER NODES clause of the DEFINE
DATABASE, CHANGE DATABASE, and IMPORT statements
accepts a value of up to 64, effective with VMS
Version 5.0. The previous maximum value was 32.
__________________________________________________________________
1.16 Documentation Title Changes
The V2.3 VAX Rdb/VMS Guide to Database Administration
and Maintenance has a new title for V3.0; it is
called the VAX Rdb/VMS Guide to Database Maintenance
and Performance. The V3.0 manual included expanded
information on performance and tuning, modifying
database characteristics, and using the Rdb/VMS
Management Utility (RMU).
The V2.3 VAX Rdb/VMS Pocket Guide and the RDML
Pocket Guide are now called the VAX Rdb/VMS Quick
Reference Guide and the RDML Quick Reference Guide,
respectively. In addition, these quick reference
guides are printed using the same page size as for
the other manuals.
1-21
New and Changed Features
__________________________________________________________________
1.17 RDML New Features and Changes
This section describes new and changed features
relating to the Rdb/VMS Relational Data Manipulation
Language (RDML)
___________________________
1.17.1 Enhancements to RDML Permit Intermodule Communication
Enhancements to RDML allow modules produced by it
to coexist and work with those produced by RDBPRE
and SQLPRE. RDBPRE and SQLPRE use program sections
(COMMONs) to communicate between separate modules,
whereas prior to this release, RDML used only global
symbols. RDML has been modified to use either program
sections or global symbols. The user can select which
of the two mechanisms to use using a new qualifier
(/LINKAGE) on the RDML command.
This new functionality includes:
o Changes to the names of some RDML variables.
The process of changing RDML to use RDBPRE-style
intermodule communication, required a name change
to several several variables so that they will
conform with the names used by RDBPRE and SQLPRE.
o /LINKAGE, a new RDML qualifier
This new qualifier allows you to specify which of
two intermodule communication mechanisms to use.
o Default Scope of Database changed to GLOBAL
o /[NO]INITIALIZE_HANDLES, A new RDML qualifier
This new qualifier allows you to determine whether
RDML will automatically initialize database,
transaction, and request handles.
1-22
New and Changed Features
_____________________
1.17.1.1 Change in RDML Variable Names
RDB$MSG_VECTOR, the old RDML name of the message
vector has been changed to RDB$MESSAGE_VECTOR. All
future explicit references to the message vector
should be to the new name, RDB$MESSAGE_VECTOR. Any
existing references to the old name should be changed
to the new name at the earliest opportunity. The old
name is still defined for the purpose of backwards
compatibility, but may be absent in future versions.
RDB$LU_TRHANDLE, the old RDML name of the
default transaction handle has been changed to
RDB$TRANSACTION_HANDLE. The new name is NOT guaranteed
to remain constant across releases. The old name is
still defined in case any code depends on it, but
any such references should be changed to use the new
name at the earliest opportunity. The old name may
be absent in future releases. Digital recommends that
you avoid explicit references to either the old name
or the new name of the default transaction handle,
instead use an explicitly named transaction handle
when you need to refer to a transaction handle across
modules.
RDB$LU_DBHANDLE, the old RDML name of the default
database handle has been changed to RDB$DBHANDLE.
The new name is not guaranteed to remain constant
across releases. The old name is still defined in
case any code depends on it, but any such references
should be changed to use the new name at the earliest
opportunity, since the old name may be absent in
future releases. Digital recommends that you avoid
explicit references to either the old name or the
new name of the default database handle, instead use
an explicitly named database handle when you need to
refer to a database handle across modules.
1-23
New and Changed Features
_____________________
1.17.1.2 RDML Databases Default Scope Changed
The scope of a database handle has been changed
to GLOBAL in RDML programs. This conforms with the
default scope of RDBPRE and SQLPRE.
_____________________
1.17.1.3 New /LINKAGE Qualifier with the RDML
Command
A new qualifier, /LINKAGE, has been added to the
RDML command to allow you to choose which of the
two intermodule communication mechanisms to use. The
choices are:
o /LINKAGE=PROGRAM_SECTIONS
This option is the default. This will allow modules
produced by RDML to work with those produced by
RDBPRE and SQLPRE, and will also allow existing
RDML applications to work in virtually all caes.
o /LINKAGE=GLOBAL_SYMBOLS
This option is provided only to allow existing
applications that experience problems using program
sections to revert to using global symbols. This
is not expected to be a common problem, and so
/LINKAGE=GLOBAL_SYMBOLS should be used only when it
is determined that it is absolutely necessary.
The following two programs, PASCAL_TEST.RPA and
BASIC_TEST.RBA are an RDML/Pascal and an RDBPRE BASIC
program, respectively. After preprocessing them each
separately, you can link these two programs together
by entering:
$ LINK PASCAL_TEST.RPA, BASIC_TEST.RPA, RDMLOPT/OPT
Note that by default the programs will be linked with
the /LINKAGE = PROGRAM_SECTIONS qualifier. If you
specify the /LINKAGE=GLOBAL_SECTIONS qualifier, the
two programs will not link properly.
1-24
New and Changed Features
PASCAL_TEST.RPA
program main(output);
DATABASE FILENAME 'PERSONNEL'; { Default database handle, GLOBAL }
type
EMPLOYEE_ID_TYPE = BASED ON EMPLOYEES.EMPLOYEE_ID;
DEPT_NAME_TYPE = BASED ON DEPARTMENTS.DEPARTMENT_NAME;
var
dept_name : DEPT_NAME_TYPE;
procedure find_dept( %STDESCR emp_id : EMPLOYEE_ID_TYPE;
%STDESCR dept_name: DEPT_NAME_TYPE ); external;
begin
READY;
START_TRANSACTION READ_ONLY;
{ Do a query in this module }
FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = '00166'
write(E.LAST_NAME);
find_dept(E.EMPLOYEE_ID, dept_name);{ Do a query in the other module }
writeln ('is the manager of ', dept_name);
END_FOR;
ROLLBACK;
FINISH;
end.
BASIC_TEST.RBA
SUB find_dept( STRING emp_id, STRING dept_name )
! RDBPRE module to test coexistence with RDML module.
declare string dept
&RDB& DATABASE FILENAME 'PERSONNEL'
1-25
New and Changed Features
&RDB& FOR FIRST 1 D IN DEPARTMENTS WITH D.MANAGER_ID = emp_id
&RDB& GET
&RDB& dept = D.DEPARTMENT_NAME
&RDB& END_GET
dept_name = dept
&RDB& END_FOR
END SUB
_____________________
1.17.1.4 New Qualifier to Initialize Handles
There is a new qualifier, /[NO]INITIALIZE_HANDLES,
available on the RDML command. This allows you to
instruct RDML whether to automatically initialize
database, transaction, and request handles when they
are declared. The default is /INITIALIZE_HANDLES.
This qualifier has no effect on whether or when
handles are cleared in the generated code; it only
controls initialization of handles in declarations.
Database handles are only initialized (when the
/INITIALIZE_HANDLES qualifier is specified or
defaulted) for GLOBAL and LOCAL scope. EXTERNAL scope
database handles are never initialized. Transaction
handles and request handles explicitly named by
the user must be explicitly declared by the user,
and should be explicitly initialized (or not), as
appropriate, in the declaration. The /INITIALIZE_
HANDLES qualifier has no effect on user-declared
handles.
1-26
New and Changed Features
___________________________
1.17.2 GET Statement Added to RDML Syntax
The RDML GET statement is added to the RDML syntax.
This new GET statement gives you most of the
functionality provided by the RDO GET statement.
The RDML GET statement assigns values from data
records in a record stream to host variables in RDML
programs. You can use the GET statement in three
different ways:
o When you establish a record stream with the FOR or
START_STREAM statement, you use the GET statement
to assign values from the current record in the
stream to variables in your program. In the case of
the START_STREAM statement, you also need a FETCH
statement to indicate the current record in the
stream.
o You can use GET within a STORE operation to
retrieve fields from the record currently being
stored. This includes the use of GET ... RDB$DB_
KEY in a STORE ... END_STORE block to retrieve the
database key (dbkey) of a record just stored.
o You can also use the GET statement alone, without
a FOR, FETCH, or STORE statement to retrieve the
result of a statistical expression. The record
stream is formed by the record selection expression
within the statistical expression.
Note that GET used with statistical expressions
allows you to check for errors with the ON ERROR
clause. Statistical expressions alone do not
have an ON ERROR clause. However, when used with
statistical expression, the ON ERROR clause in the
GET statement will trap for errors if one should
occur during execution of the statistical function.
For example:
1-27
New and Changed Features
GET
ON ERROR
.
.
.
END_ERROR;
host_var = (COUNT OF E IN EMPLOYEES)
END_GET;
The format for the GET statement is:
For information on the GET statement, see the RDML
Reference Manual.
___________________________
1.17.3 Enhancements to STORE Statement
RDML now supports the use of a GET statement within
the bounds of the STORE ... END_STORE block. Note that
any valid format of the GET statement is permitted
within this block. However, the GET statement must
be the last statement before the END_STORE when it is
used in a STORE operation.
You may find it particularly useful to use the GET
statement to place the database key (dbkey) of the
record you are storing into a host variable. Use the
GET...RDB$DB_KEY construct to assign the value of the
dbkey to the host variable. The new format for the
STORE statement is:
1-28
New and Changed Features
For information on the STORE statement, see the RDML
Reference Manual.
___________________________
1.17.4 RDML/[NO]DEFAULT_TRANSACTIONS Qualifier
The /[NO]DEFAULT_TRANSACTIONS qualifier has been added
to the RDML command. /DEFAULT_TRANSACTIONS is the
default; however, for optimum performance /NODEFAULT_
TRANSACTIONS is recommended.
This qualifier allows the programmer to control
the generation of default transaction code by the
RDML preprocessor. The default for this qualifier
is /DEFAULT_TRANSACTIONS, which retains the former
behavior of the preprocessor: attach to the databases
in the application and start a read-only transaction
should none be active before any query.
Specifying /NODEFAULT_TRANSACTIONS eliminates the
overhead associated with checking the database and the
transaction state, and offers improved performance for
large applications. The /NODEFAULT_TRANSACTION command
qualifier requires that the application explicitly
attach to the database using the READY statement
and start a transaction using the START_TRANSACTION
statement before reading or writing any data.
Specifying /NODEFAULT_TRANSACTIONS also changes the
behavior of the FINISH statement. By default the
FINISH statement first commits the default transaction
(if it is active) before actually detaching from any
database. The /NODEFAULT_TRANSCTION qualifier disables
this behavior; and as a result, if a transaction
is active on a database when a FINISH statement is
executed for that database, the following error will
be returned:
%RDB-F-OPEN_TRANS, detach failed because 1 transaction is active
1-29
New and Changed Features
This behavior ensures that an application has properly
completed any active transaction with an explicit
COMMIT or ROLLBACK statement.
___________________________
1.17.5 DATABASE Statement DBKEY SCOPE Clause
The DBKEY SCOPE clause of the DATABASE statement
can now be used in RDML programs. The function and
syntax are as documented for the statement in RDO. For
information, see the RDO or RDML help information on
INVOKE, or refer to the VAX Rdb/VMS Reference Manual.
___________________________
1.17.6 START_TRANSACTION Statement: ON and EVALUATING Clauses
The ON clause and the EVALUATING clause (transaction
option) of the START_TRANSACTION statement can now
be used in RDML programs. The function and syntax
are as documented for the statement in RDO. For
information, see the RDO or RDML help information
on START_TRANSACTION, or refer to the VAX Rdb/VMS
Reference Manual.
___________________________
1.17.7 Context-Variable.* with STORE and MODIFY Statements
The STORE and MODIFY statements can now specify an
asterisk (*) with the context variable to indicate
that all fields in the relation are affected. For
example:
STORE E in EMPLOYEES
USING E.* = record-variable;
END_STORE;
To use this approach, you must first have defined the
appropriate record structure in your host language and
filled in the necessary data in that record structure.
1-30
_______________________________________________________
2 Software Errors Fixed
The following sections describe problems with previous
versions of the Rdb/VMS software that are fixed in
V3.0. These software problems no longer exist.
__________________________________________________________________
2.1 Database Administration and Maintenance
The following sections describe software errors fixed
pertaining to database administration and maintenance.
___________________________
2.1.1 CONTROL Access Right to a Database
Prior to this release, Rdb/VMS erroneously allowed a
database user with the CONTROL access right to delete
his or her only access control entry when he or she
had nothing more powerful than CONTROL privileges.
This problems is fixed in Rdb/VMS V3.0; a user with
nothing more powerful than CONTROL privileges cannot
delete his or her only access control entry.
Furthermore, the documentation stated that it was
impossible to deny yourself CONTROL access rights.
This is incorrect; any user with the VMS BYPASS
privilege enabled can bypass the checks made to
prevent the deletion of CONTROL access.
2-1
Software Errors Fixed
___________________________
2.1.2 Incorrect Cardinality Maintained
Prior to this release, Rdb/VMS would not always
maintain the correct cardinality on a relation when
an update transaction containing alot of updates
was run at the same time as an update transaction
containing a few updates. Under these conditions
Rdb/VMS would sometimes record the cardinality change
as determined by the small update transaction and
ignore the cardinality change as determined by the
large update transaction.
This problem is fixed in Rdb/VMS V3.0
___________________________
2.1.3 RESTORE Statement
In Rdb/VMS V2.3, the RESTORE ... SET INDEX options
failed and returned a "LIB-F-INVNBDS, invalid numeric
byte data string" error message. The workaround for
this problem was to perform the RESTORE operation
in one RDO command and then issue a CHANGE INDEX
statement in a second RDO command.
This problem is fixed in Rdb/VMS V3.0; the workaround
is no longer necessary.
__________________________________________________________________
2.2 Data Definition and Data Manipulation
The following sections describe software errors fixed
pertaining to data definition and data manipulation.
2-2
Software Errors Fixed
___________________________
2.2.1 Views and Conditional Expressions
Queries that reference views and are qualified
by conditional expressions might have resulted in
incorrect record streams prior to Rdb/VMS V3.0
The following example illustrates the problem.
The statements illustrated defined a view and
then retrieved records from it. One retrieval
shows a simple retrieval using the view; the other
view retrieval used a conditional expression. The
conditional expression was applied incorrectly and an
invalid record stream resulted.
RDO> INVOKE DATABASE FILENAME PERSONNEL
RDO> START_TRANSACTION READ_WRITE
RDO> DEFINE VIEW viewed_with
cont> OF C IN employees
cont> WITH C.SEX = 'M'
cont> AND C.EMPLOYEE_ID <> ''
cont> AND NOT ANY
cont> CX IN employees
cont> WITH C.EMPLOYEE_ID = CX.EMPLOYEE_ID
cont> AND CX.BIRTHDAY = MIN CZ.BIRTHDAY
cont> OF CZ IN EMPLOYEES
cont> WITH CX.EMPLOYEE_ID = CZ.EMPLOYEE_ID.
cont> C.EMPLOYEE_ID.
cont> END VIEW.
%RDO-W-NOCDDUPDAT, database invoked by filename, the CDD will not be updated
RDO>
RDO> FOR FIRST 1 R IN EMPLOYEES PRINT R.* END_FOR
EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIAL
ADDRESS_DATA_1 ADDRESS_DATA_2
CITY STATE POSTAL_CODE SEX
BIRTHDAY STATUS_CODE
00164 Toliver Alvin A
146 Parnell Place
Chocorua NH 03817 M
28-MAR-1947 00:00:00.00 1
2-3
Software Errors Fixed
RDO>
RDO> FOR FIRST 1 R IN EMPLOYEES WITH R.EMPLOYEE_ID
<> "00164" PRINT R.* END-F
EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIAL
ADDRESS_DATA_1 ADDRESS_DATA_2
CITY STATE POSTAL_CODE SEX
BIRTHDAY STATUS_CODE
00165 Smith Terry D
120 Tenby Dr.
Chocorua NH 03817 M
15-MAY-1954 00:00:00.00 2
RDO>
RDO> FOR T IN VIEWED_WITH
cont> PRINT T.EMPLOYEE_ID
cont> END_FOR
RDO>
RDO> FOR T IN VIEWED_WITH WITH T.EMPLOYEE_ID <>"00164"
cont> PRINT T.EMPLOYEE_ID
cont> END_FOR
EMPLOYEE_ID
00164
RDO>
The last query erroneously retrieved a record; it
should have returned none. The error occurred due
to the way view queries were compiled. First, the
view was expanded to include the relations named
in the view definition and then another conditional
expression was applied. Because the queries are
evaluated from left to right, the user's conditional
expression was applied last -- too late to correctly
restrict the records.
This problem has been corrected for V3.0. The last
query will correctly return no records.
2-4
Software Errors Fixed
___________________________
2.2.2 CHANGE DATABASE Statement
A problem existed in Rdb/VMS V2.3 whereby the RDO
statement CHANGE DATABASE FILENAME <database-name>
OPEN IS MANUAL did not work correctly. When more than
one user was attached to the database, RDO returned
error messages instead of returning confirmation
that the change had taken place ("Changed open mode
to manual"). The following example demonstrates the
problem:
RDO> change database filename personnel open is manual.
%RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error opening database root file DUA0:[TEST]PERSONNEL;1
-SYSTEM-W-ACCONFLICT, file access conflict
RDO>
This problem is fixed in Rdb/VMS V3.0.
___________________________
2.2.3 CHANGE FIELD Statement and Views
Prior to this release, for a given database you could
not issue a CHANGE FIELD statement for a field that
was used in a view. This problem is fixed in Rdb/VMS
V3.0; you can now issue a CHANGE FIELD statement for a
field that is used in a view.
___________________________
2.2.4 DESCRIPTION IS Clause and SHOW INDEX Statement
Previously, when you issued the SHOW INDEX statement
from RDO, the text of the DESCRIPTION IS clause was
not displayed. However, when you issued the SHOW INDEX
index_name statement, the text of the DESCRIPTION
IS clause was displayed. Starting in Rdb/VMS V3.0,
the SHOW INDEX statement will display the text of
the DESCRIPTION IS clause regardless of whether
you specify the index name. The following example
demonstrates the results you can expect to see in
V3.0:
2-5
Software Errors Fixed
RDO> define index temp_emp
cont> description is /*just a test*/
cont> for employees.
cont> sex.
cont> end temp_emp index.
RDO> show indexes for employees
Indexes for relation EMPLOYEES
EMP_EMPLOYEE_ID with field EMPLOYEE_ID
No duplicates allowed
TEMP_EMP with field SEX
Duplicates are allowed
description JUST A TEST
SHOW INDEX TEMP_EMP
Indexes for relation EMPLOYEES
TEMP_EMP with field SEX
description JUST A TEST
Duplicates are allowed
___________________________
2.2.5 Defining a Default Value of Data Type TEXT for
DATATRIEVE
Prior to Rdb/VMS V3.0, you could not define a default
value of data type text for DATATRIEVE. Although the
RDO statement appeared to work, a bugcheck occurred
when the next RDO statement was executed. For example:
RDO> data file personnel
RDO> start_transaction read_write
RDO> change relation employees.
cont> change birthday
cont> default_value for dtr is "99999".
cont> end employees relation.
RDO> commit
RDO> show fields for employees
2-6
Software Errors Fixed
Fields for relation EMPLOYEES
EMPLOYEE_ID text size is 5
based on global field ID_NUMBER
LAST_NAME text size is 14
FIRST_NAME text size is 10
MIDDLE_INITIAL text size is 1
ADDRESS_DATA_1 text size is 25
ADDRESS_DATA_2 text size is 25
CITY text size is 20
STATE text size is 2
POSTAL_CODE text size is 5
SEX text size is 1
BIRTHDAY Date
based on global field STANDARD_DATE
%RDO-F-BUGCHK, there has been a fatal error;
please submit an SPR; no dump was produced
This problem is fixed in Rdb/VMS V3.0.
___________________________
2.2.6 Invoking Two Databases in the Same RDO Session
Rdb/VMS V2.3 returned an incorrect error message when
the following conditions existed:
o Two different databases had a relation with the
same name (for example, databases db1 and db2 both
have a relation named SALARY_HISTORY)
o The relation in one database is a subset of the
relation in the second database. (For example,
SALARY_HISTORY in db1 contains the field SALARY_
START and SALARY_HISTORY in db2 does not.)
o The database with the relation containing the most
fields (db1) is invoked, the relation common to
both databases is used in an RSE (SALARY_HISTORY),
then the database (db1) is finished, but the user
does not exit from RDO.
2-7
Software Errors Fixed
o The second database (db2) that contains the
relation with a subset of the fields in the common
relation (SALARY_HISTORY in db2 does not contain
the field SALARY_START) is invoked and information
from the relation (SALARY_HISTORY) is requested.
For example:
RDO> DATA FILE TEMP_PERSONNEL
RDO> FOR SH IN SALARY_HISTORY PRINT SH.* END_FOR
.
.
.
RDO> FINISH
RDO> DATA FILE COMPUTED_TEST2
RDO> FOR S IN SALARY_HISTORY PRINT S.* END_FOR
%RDB-E-OBSOLETE_METADATA, request references metadata objects that no longer exist
-RDMS-F-BAD_SYM, unknown field symbol - SALARY_START
This problem is fixed in Rdb/VMS V3.0
___________________________
2.2.7 Estimated Cost of Indexed Retrieval for a BETWEEN
Operation
Prior to this release, the cost calculated by Rdb/VMS
for an indexed retrieval of records selected using the
BETWEEN operator was approximately twice the value it
should have been. In some cases this may have caused
the optimizer to incorrectly select a sequential
retrieval over an indexed retrieval.
This problem is fixed in Rdb/VMS V3.0
2-8
Software Errors Fixed
___________________________
2.2.8 Deadlocks on START_TRANSACTION
In previous versions of Rdb/VMS, it was possible
for users to deadlock on START_TRANSACTION just by
using the RESERVING clause to reserve relations in
different orders. For example, with the right timing
the following statements could have resulted in a
deadlock:
User 1: START_TRANSACTION...RESERVING SALARY_HISTORY SHARED READ
RESERVING EMPLOYEES EXCLUSIVE WRITE
User 2: START_TRANSACTION...RESERVING EMPLOYEES SHARED READ
RESERVING SALARY_HISTORY EXCLUSIVE WRITE
Furthermore, when you reserved both a view and a
relation within that view, Rdb/VMS would not allow
you to write to the reserved relation if you specified
the view first and reserved it for shared read, and
specified the relation second and reserved it for
shared write. Rdb/VMS incorrectly used the logic
that since it had reserved a view that contained
the relation, the relation itself did not need to
be reserved. On the other hand, if you reserved the
relation for shared write first, and the view for
shared read second, Rdb/VMS would yield the desired
results.
In the following example, Rdb/VMS would not allow
you to write to the EMPLOYEES relation because it had
already been reserved for shared read (the START_
TRANSACTION statement would have worked, but the
actual write operation would have failed).
START_TRANSACTION...RESERVING CURRENT_SALARY FOR SHARED READ
RESERVING EMPLOYEES FOR SHARE WRITE
In V3.0, Rdb/VMS builds a list of relations that need
to be readied as it processes the reserving clause.
Views are "expanded" into their component relations
and the list is maintained in order by relation
identification number. If a relation is mentioned
2-9
Software Errors Fixed
multiple times (either explicitly or because it is
mentioned once and also is part of a view) then the
most restrictive protection (EXCLUSIVE supersedes
PROTECTED which supersedes SHARED) and maximum
permission (UPDATE supersedes Read) are used.
Because relations are always readied in the order of
their relation identification numbers, deadlocks of
the type previously described do not occur in Rdb/VMS
V3.0.
__________________________________________________________________
2.3 Programming
The following sections describe software errors fixed
pertaining to programming.
___________________________
2.3.1 RDML Checks for Proper Statement Termination
RDML now checks to see that the following statements
are terminated with the appropriate END_ statement:
FOR
GET
MODIFY
STORE
ON ERROR
In addition, FETCH must also be logically ended
(although it does not require a physical END_FETCH).
If any of these statements is not properly terminated,
RDML issues the following warning message:
%RDML-E-NOENDSTMT, Statement was not terminated by a matching end statement
The listing file produced by RDML indicates the
statement referred to by this message.
2-10
Software Errors Fixed
Undeclared streams require that START_STREAM and END_
STREAM statements be balanced, that there be one (and
only one) END_STREAM statement to balance the START_
STREAM statement, and that the END_STREAM occur after
the START_STREAM in the source file. RDML now checks
that this occurs, and issues the following error
message if not:
%RDML-W-UNBALSTRM, Undeclared stream '<stream-name>' has no END_STREAM statement
Note that these are warning messages. This allows
existing programs that do not finish START_STREAM
statements with an END_STREAM to continue to work;
however, users are encouraged to supply the END_STREAM
statement.
___________________________
2.3.2 Path Name and the RDML DATABASE Statement
Previously, RDML did not extract the run-time file
name from the CDD when you specified the compile-
time path name option of the DATABASE statement
only. If you chose to specify the compile-time path
name, you also had to supply the run-time file name.
If you did not supply the run-time file name under
these conditions, RDML used the CDD path name as the
run-time file name. For instance, RDML would have
mistakenly used 'CDD$TOP.PERSONNEL' as the run-time
database file name in the following example:
DATABASE COMPILETIME PATHNAME 'CDD$TOP.PERSONNEL';
This problem has been fixed in Rdb/VMS V3.0. RDML
will now extract the run-time file name from the data
dictionary when you specify the compile-time path name
option of the DATABASE statement.
2-11
Software Errors Fixed
___________________________
2.3.3 RDML START_STREAM Statement
Since RDML was introduced in Rdb/VMS V2.3, successive
START_STREAM and END_STREAM pairs with the same stream
name resulted in syntax errors. This problem is fixed
in Rdb/VMS V3.0
___________________________
2.3.4 STORE Statement With Segmented Strings
Previously, RDML erroneously allowed a STORE statement
with segmented strings to be nested within a FOR
statement. STORE statements with segmented strings
must be used in the context of a STORE statement or
a MODIFY statement. With V3.0, this problem is fixed
and such a coding error results in the following error
message:
%RDML-E-NOTSTORECV, 'R' is not a STORE or MODIFY context variable
where 'R' was the context variable used in the
segmented string STORE statement.
___________________________
2.3.5 FOR Segmented String Statement
Previously, RDML would not detect errors that may have
resulted from the retrieval of segmented strings when
an ON ERROR clause was used on the segmented string
FOR statement. With V3.0, this problem is fixed, and
errors are correctly detected and handled.
2-12
Software Errors Fixed
___________________________
2.3.6 Pascal [HIDDEN] Attribute in RDML/Pascal
Prior to this release, the RDMLVPAS.PAS file included
in the RDML kit did not contain the necessary [HIDDEN]
attribute specifications to allow use of environment
files in RDML/Pascal programs. Additionally, the
code generated by RDML did not contain the necessary
attribute specifications. This caused the Pascal
compiler to report multiple declarations of variables
when an environment file was used due to the fact that
multiple variables that were not hidden were declared
in both the environment file and your program module
and that the RDMLVPAS.PAS file was included in both
the file you used to produce the environment file and
your program module.
This problem is fixed in Rdb/VMS V3.0.
___________________________
2.3.7 Success Status Returned on START_TRANSACTION Failures
A START_TRANSACTION statement that refers (either
explicitly or implicitly) to multiple databases can
return an incorrect success status if the START_
TRANSACTION statement fails. This situation is most
common when there are concurrent executions of the
same program and a lock conflict occurs for one of the
program executions. Prior to Rdb/VMS V3.0, under these
conditions, program execution would proceed, only to
fail at some later point with Rdb/VMS errors such as
READ_ONLY_TRANS and REQ_WRONG_DB.
This problem is fixed in Rdb/VMS V3.0.
2-13
_______________________________________________________
3 Problems, Restrictions, and Other Notes
This chapter describes problems and restrictions
relating to Rdb/VMS V3.0, and includes workarounds
where appropriate. It also contains other information
that does not fit logically into the preceding
chapters.
__________________________________________________________________
3.1 General Information
This section contains notes and problem descriptions
of a general nature.
___________________________
3.1.1 RDBVMS$PARAMETERS Logical Name
With V3.0, the logical name RDBVMS$PARAMETERS
is defined on monitor startup (that is, when
SYS$MANAGER:RMONSTART.COM is run). If this logical
name is not defined with the equivalence name
specified in RMONSTART.COM, all attempts to use
Rdb/VMN V3.0 will fail with the error status RDB$_
UNAVAILABLE.
For this and other reasons, it is strongly recommended
that the Rdb/VMS monitor be started using the
RMONSTART.COM file provided with the Rdb/VMS kit.
3-1
Problems, Restrictions, and Other Notes
___________________________
3.1.2 Rdb/VMS V3.0 Not Supported During VAXcluster Rolling
Upgrade
If VAX Rdb/VMS V3.0 is used in a VMS V5.0 VAXcluster
environment, all nodes in the VAXcluster must be
running VMS V5.0 before Rdb/VMS V3.0 is installed.
Rdb/VMS V3.0 is not supported during a "rolling
upgrade."
___________________________
3.1.3 VMS V4.7 or Higher Required
VAX Rdb/VMS V3.0 can be used only on systems running
VMS (or MicroVMS) V4.7 or a higher version.
___________________________
3.1.4 VAX DATATRIEVE V4.2 or Higher Required
VAX Rdb/VMS V3.0 is incompatible with VAX DATATRIEVE
V4.1 or previous versions. You must use VAX DATATRIEVE
Version 4.2 or higher.
___________________________
3.1.5 VAX Data Distributor V2.0 or Higher Required
VAX Data Distributor Versions 1.0 and 1.1 do not work
with Rdb/VMS V3.0. You must use VAX Data Distributor
Version 2.0 or higher.
___________________________
3.1.6 VAX TEAMDATA Versions 1.1 and 1.2
Rdb/VMS V3.0 is incompatible with TEAMDATA V1.1
unless a patch to the TEAMDATA V1.1 software has
been applied. Contact your DIGITAL software support
representative for information about which patch to
use.
TEAMDATA V1.2 runs correctly with Rdb/VMS V3.0. If
you cannot install TEAMDATA V1.2 at this time, contact
your DIGITAL software support representative.
3-2
Problems, Restrictions, and Other Notes
___________________________
3.1.7 Cross-Product Manuals Do Not Include New Features
VAX Information Architecture documentation contains
two cross-product manuals:
o Introduction to Database Development
o Introduction to Application Development
These manuals describe how to use VAX Information
Architecture and VAXset products together to design
and implement a sample database and transaction-
processing application. They have not been updated
for the current release of VAXinfo and, therefore,
do not contain information about new product features
listed in these release notes.
Because these manuals present design methodologies
and implementation strategies, the information in them
should still be useful. Note, however, that sections
comparing VAX DBMS with VAX Rdb/VMS and describing how
to use VAX Rdb/VMS with the VAX Common Data Dictionary
are obsolete.
__________________________________________________________________
3.2 Database Administration and Maintenance
This section describes problems and restrictions
related to database administration and maintenance.
___________________________
3.2.1 Avoid Having Single-File Databases with Same Names
You are encouraged to avoid allowing more than one
single-file database with the same file name and file
type (differing only in version number) to exist in
a directory or search list of directories. If two
or more single-file databases with the same name do
exist, each must have a snapshot (SNP) file. (That is,
there must be an exact correspondence of RDB and SNP
files in such a case.)
3-3
Problems, Restrictions, and Other Notes
Be especially sure to delete unwanted single-file
database files (or to guarantee correspondence between
RDB and SNP files) before performing a backup/restore
or export/import operation.
___________________________
3.2.2 INTEGRATE Operation Must Terminate with COMMIT
The RDO INTEGRATE statement must be followed by a
COMMIT statement for the integrate operation to
take effect. This is documented in the VAX Rdb/VMS
Reference Manual; it is mentioned here also to
emphasize the need for committing the results of an
integrate operation, to avoid the potential loss of
considerable processing work.
___________________________
3.2.3 RMU/CONVERT Requires AIJ Be Disabled
RMU/CONVERT will fail if the database being converted
has after-image journaling enabled (that is, if the
CHANGE DATABASE statement was used specifying the
JOURNAL FILE IS clause).
You must disable after-image journaling before using
RMU/CONVERT on the database by using the CHANGE
DATABASE statement specifying NOJOURNAL. (See the VAX
Rdb/VMS Reference Manual for the format of the CHANGE
DATABASE STATEMENT.)
__________________________________________________________________
3.3 Data Definition and Data Manipulation
This section describes problems and restrictions
related to data definition and data manipulation.
3-4
Problems, Restrictions, and Other Notes
___________________________
3.3.1 Relation Name Must Match Dictionary Record Name
If you define a relation using a CDD/Plus path name,
the relation name must match the record name. For
example, the following statement contains an error.
(The statement will be processed; however, problems
will occur later.)
define relation AAAA from pathname "cdd$top.test.XXXX" end.
The correct form of the statement is as follows:
define relation AAAA from pathname "cdd$top.test.AAAA" end.
___________________________
3.3.2 No Data Type Checking on Limit Clause
If you use one or more WITH LIMIT OF clauses with the
DEFINE STORAGE MAP or CHANGE STORAGE MAP statement,
or with the DEFINE INDEX OR CHANGE INDEX statement,
Rdb/VMS does not check whether the limit specification
uses a data type incompatible with the field's
definition. Therefore, you must be sure to use the
proper specification.
For example, in the following excerpt from the
procedure that defines the multifile sample personnel
database, the quotation marks around the limits are
necessary because the global field ID_NUMBER (upon
which EMPLOYEE_ID is based) is defined as text, not
numeric.
DEFINE STORAGE MAP EMPLOYEES_MAP
DESCRIPTION IS /*EMPLOYEES partitioned by EMPLOYEE_ID */
FOR EMPLOYEES RELATION
STORE USING EMPLOYEE_ID
WITHIN
EMPIDS_LOW WITH LIMIT OF "00200";
EMPIDS_MID WITH LIMIT OF "00400";
EMPIDS_OVER
END EMPLOYEES_MAP STORAGE MAP.
3-5
Problems, Restrictions, and Other Notes
If there is an incompatibility between the data type
specified in the WITH LIMIT OF clause and the field's
definition, no error is returned, and unpredictable
results can occur in the storage of records for the
relation.
___________________________
3.3.3 Field Definition Change and Invalid Data
Rdb/VMS does not prevent a change in a field
definition that makes a VALID IF check more stringent
when existing data fail the new check. The following
scenario illustrates the problem:
1 Create a field SAL1 that has a VALID IF SAL1 >
8000
2 Create a field SAL2 that has a VALID IF SAL2 >
9000
3 COMMIT
4 Change the EMPLOYEES relation to contain the field
SAL1
5 COMMIT
6 Modify a record in EMPLOYEES and put the value 8500
in the field SAL1
7 COMMIT
8 Change the EMPLOYEES relation and make the field
SAL1 be BASED on SAL2, which has a VALID IF SAL2 >
9000
9 COMMIT
At this point, the database contains "invalid" data
(that is, the employee with a salary amount of 8500),
and no error was generated. Moreover, any future
RESTORE or IMPORT operation specifying this database
will fail because of the presence of the invalid data.
3-6
Problems, Restrictions, and Other Notes
___________________________
3.3.4 Performance Suggestion for Hashed Index Use
If you define a hashed index and define a storage map
to control placement of records according to the index
value and if you wish to store the records and their
corresponding index buckets on the same pages, you
may achieve slightly better performance by omitting
the WITH LIMIT OF clauses from the DEFINE STORAGE MAP
statement.
For example, the following statements from the
RDM$DEMO:MF_BUILDPERS.RDO command procedure do not
include this performance enhancement technique:
DEFINE INDEX EMPLOYEES_HASH
DESCRIPTION IS /* hash index for employees */
FOR EMPLOYEES
DUPLICATES ARE NOT ALLOWED
STORE USING EMPLOYEE_ID
WITHIN
EMPIDS_LOW WITH LIMIT OF "00200";
EMPIDS_MID WITH LIMIT OF "00400";
EMPIDS_OVER;
TYPE IS HASHED.
EMPLOYEE_ID.
END EMPLOYEES_HASH.
!
DEFINE STORAGE MAP EMPLOYEES_MAP FOR EMPLOYEES
DESCRIPTION IS /* employees partitioned by "00200" "00400" */
STORE USING EMPLOYEE_ID
WITHIN
EMPIDS_LOW WITH LIMIT OF "00200";
EMPIDS_MID WITH LIMIT OF "00400";
EMPIDS_OVER
PLACEMENT VIA INDEX EMPLOYEES_HASH
END EMPLOYEES_MAP STORAGE MAP.
3-7
Problems, Restrictions, and Other Notes
The following statements do illustrate the suggested
approach. The only difference from the preceding
example is the omission of the WITH LIMIT OF clauses
in the DEFINE STORAGE MAP statement.
DEFINE INDEX EMPLOYEES_HASH
DESCRIPTION IS /* hash index for employees */
FOR EMPLOYEES
DUPLICATES ARE NOT ALLOWED
STORE USING EMPLOYEE_ID
WITHIN
EMPIDS_LOW WITH LIMIT OF "00200";
EMPIDS_MID WITH LIMIT OF "00400";
EMPIDS_OVER;
TYPE IS HASHED.
EMPLOYEE_ID.
END EMPLOYEES_HASH.
!
DEFINE STORAGE MAP EMPLOYEES_MAP FOR EMPLOYEES
DESCRIPTION IS /* employees partitioned by "00200" "00400" */
STORE USING EMPLOYEE_ID
WITHIN
EMPIDS_LOW;
EMPIDS_MID;
EMPIDS_OVER
PLACEMENT VIA INDEX EMPLOYEES_HASH
END EMPLOYEES_MAP STORAGE MAP.
__________________________________________________________________
3.4 Programming
This sections describes problems and restrictions
related to programming database applications.
3-8
Problems, Restrictions, and Other Notes
___________________________
3.4.1 Conversion and Coexistence: RDBPASCAL and RDML/Pascal
This section contains information and advice to
help users convert from RDBPASCAL to RDML/Pascal,
and at the same time allow RDBPASCAL, RDML, RDBPRE,
and SQLPRE modules to coexist in your development
environment.
The following simple example shows how to get a
module preprocessed with RDML to coexist with one
preprocessed by RDBPASCAL. The following module can be
preprocessed with RDBPASCAL :
program emps (input, output);
DATABASE PERS = [GLOBAL] FILENAME 'PERSONNEL';
procedure call_rdml; extern;
begin
READY PERS;
START_TRANSACTION;
writeln('First 10 employees:');
FOR FIRST 10 E IN EMPLOYEES
writeln(E.FIRST_NAME, E.LAST_NAME);
END_FOR;
{ Call RDML module }
call_rdml;
COMMIT;
FINISH;
end.
The following module can be preprocessed with
RDML/Pascal:
3-9
Problems, Restrictions, and Other Notess , module colls (input, output); ? DATABASE PERS = [EXTERNAL] FILENAME 'PERSONNEL';_ , [global] procedure call_rdml; varK RDB$LU_TRHANDLE : [COMMON, ALIGNED(2)] RDML$HANDLE_TYPE; begino 2 writeln('First 10 colleges :'); I FOR (TRANSACTION_HANDLE RDB$LU_TRHANDLE) C IN COLLEGES , writeln(C.COLLEGE_NAME); END_FOR;c end; end.o 8 Notice that a transaction handle is explicitly: declared in the second module (RDB$LU_TRHANDLE),8 and that the COMMON and ALIGNED attributes are9 specified. This allows sharing of the RDBPASCALm8 default transaction handle, which is different; from the default transaction handle used by other ? preprocessors. The attributes make sure that the same_>