VAX_Rdb/VMS_________________________________________
Release Notes
November 1992
This document contains the Release Notes for
VAX Rdb/VMS Version 4.2. It describes software
errors fixed and problems, restrictions, and other
information relating to Version 4.2.
Revision/Update Information This manual is a
revision and supersedes
previous versions.
Operating System: VMS
Software Version: VAX Rdb/VMS Version 4.2
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.
Restricted Rights: Use, duplication, or disclosure by the
U.S. Government is subject to restrictions as set forth in
subparagraph (c)(1)(ii) of the Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013.
© Digital Equipment Corporation 1992.
All Rights Reserved.
The Reader's Comments form in the Preface to this document
requests your critical evaluation to assist in preparing
future documentation.
The following are trademarks of Digital Equipment
Corporation: ACMS, ALL-IN-1, Bookreader, CDD/Plus,
CDD/Repository, CI, DEC, DECdecision, DECdtm, DECforms,
DECintact, DECnet, DECnet-DOS, DECplan, DECpresent, DECtp,
DECtrace, DECwindows, HSC, MASSBUS, MicroVAX, PATHWORKS,
RA, Rdb Language Translator, Rdb/VMS, SPM, ULTRIX, UNIBUS,
VAX, VAX Ada, VAX BASIC, VAX C, VAX CDD, VAX COBOL, VAX
DATATRIEVE, VAX DBMS, VAX DOCUMENT, VAX FMS, VAX FORTRAN,
VAX MACRO, VAX Pascal, VAX Performance Advisor, VAX RALLY,
VAX Rdb/ELN, VAX RMS, VAX SCAN, VAX 6000, VAX TEAMDATA,
VAX Xway, VAXcluster, VAXELN, VAXset, VAXstation, VIDA,
VMS, and the DIGITAL logo.
IBM and OS/2 are registered trademarks of International
Business Machines Corporation. AppleTalk, Macintosh,
MacTerminal, and MPW are registered trademarks of Apple
Computer, Inc. MS-DOS is a registered trademark and
Windows is a trademark of Microsoft Corporation. SunOS
and SPARCstation are trademarks of Sun Microsystems, Inc.
PostScript is a registered trademark of Adobe Systems Inc.
This document is available on CD-ROM.
This document was prepared using VAX DOCUMENT, Version 2.1.
_________________________________________________________________
Contents
Send Us Your Comments..................................... xix
Preface................................................... xxi
1 Software Errors Fixed
1.1 Software Errors Fixed in V4.2 That Apply to All
Interfaces....................................... 1-1
1.1.1 Bugcheck at RDMS$$COMPILE_INDEX_MAPS + 413
Forced Exit Due to Improper Check of the
CRTV........................................... 1-1
1.1.2 Bugcheck at ADD_STRG_TO_STBL_LISTS +
00000037....................................... 1-2
1.1.3 Bugcheck at RDMS$$INSERT_SYMBOL + 0BC and Other
Offsets........................................ 1-3
1.1.4 Bugcheck at DBR$ASSIGN_WORK_FILE + 0000018B
When Starting Monitor from Invalid Directory
with FAST COMMIT Enabled....................... 1-3
1.1.5 Bugcheck at MON$CREATE_TROOT_SECTION + CB When
Monitor Generated Section Name That is Not
Unique......................................... 1-4
1.1.6 Bugcheck at PSIISCAN$END_SCAN + 26 Occurred
After Lock Exceptions.......................... 1-5
1.1.7 Bugcheck Produced by Restoring Storage Area to
Bound-Volume Set............................... 1-5
1.1.8 Bugcheck at RDMS$$EXE_OPEN + 78 on Query ...... 1-6
1.1.9 Bugchecks May Result from Database Access
During Recovery................................ 1-7
1.1.10 Bugcheck at KOD$UNBIND + 133 Affected Unbinding
From Database.................................. 1-7
1.1.11 Possible Database Corruption from Fragmented
Segmented String Records....................... 1-7
iii
1.1.12 Memory Corruption Error Fixed ................. 1-9
1.1.13 RMU/CLOSE/CLUSTER/ABORT=FORCEX Caused Monitor
Abnormal Termination........................... 1-9
1.1.14 Monitor Exhausted Virtual Memory .............. 1-11
1.1.15 Too Many Operands in Field Caused Stack
Overflow....................................... 1-13
1.1.16 DBR Processes May Hang Due To Waiting Lock
Requests....................................... 1-14
1.1.17 .AIJ File Could Contain Duplicate Data
Records........................................ 1-15
1.1.18 REORGANIZE PAGES Clause Now Supports Single
Storage Area................................... 1-16
1.1.19 REORGANIZE Now Succeeds When SQL ALTER STORAGE
MAP or RDO CHANGE STORAGE MAP Lacks PLACEMENT
VIA INDEX Clause............................... 1-16
1.1.20 REORGANIZE PAGES Clause Moves Data More
Efficiently.................................... 1-16
1.1.21 A Self-Insert Query With Mapped Columns
Incorrectly Stored NULL Values................. 1-16
1.1.22 Runtime Error Message About Inaccessible .AIJ
File Added..................................... 1-17
1.1.23 Unnecessary Arithmetic Exceptions for Divide
and Multiply Operations Corrected.............. 1-18
1.1.24 Number of I/O Channels Increased to Correct
IMPORT Error................................... 1-18
1.1.25 Trailing Spaces in Selection Value Caused
Incorrect Data Retrieval....................... 1-19
1.1.26 Expression Within GROUP BY Clause May Cause
Incorrect Results When Selecting Rows from a
View........................................... 1-20
1.1.27 Update Attempt Generated Incorrect
RDB-E-READ_ONLY_REL Error...................... 1-22
1.1.28 Incorrect Value Returned by Index-Only
Retrieval on Mapped Index...................... 1-22
1.1.29 Segmented Index Search Returned Incorrect
Results........................................ 1-24
1.1.30 Multisegment Index Retrieval Using Variables
May Return Incorrect Results................... 1-24
1.1.31 RDMS$RUJ Logical Defined As Filename Instead of
Directory Specification Caused RUJ Problems.... 1-25
1.1.32 Default AIP Length for List Storage Areas
Increased...................................... 1-26
iv
1.1.33 Virtual Memory Now Released by a Failing SET
TRANSACTION Statement with a Large Transaction
Parameter Block (TPB).......................... 1-26
1.1.34 Metadata Corruption No Longer Results from
Committing Failed ALTER, CREATE, or DROP
Statements..................................... 1-27
1.1.35 Storage Map Recovery Problem Corrected ........ 1-29
1.1.36 Clearer Error Message for List Storage Area
Deletions...................................... 1-29
1.1.37 RDO and SQL IMPORT Statements Map List Tables
and Columns Correctly.......................... 1-29
1.1.38 RDO and SQL IMPORT Statement TRACE Option
Displays SORT Usage............................ 1-30
1.1.39 Singleton Select with View Returned Zero
Dbkeys......................................... 1-31
1.1.40 Failure to Delete or Update Existing Records .. 1-31
1.1.41 Error on a Two-Phase Commit Protocol Start
Transaction Caused an Access Violation......... 1-32
1.1.42 SPAM Pages Are Not Initialized by an
Incremental Restore Operation if the Restore
Operation Is Adding a Storage Area............. 1-32
1.1.43 CREATE VIEW Problem with Included Column
Derived from DBKEY Corrected................... 1-32
1.1.44 List Records Should Match the Page Size When
Stored on WORM Optical Disk Devices............ 1-33
1.1.45 Mapping Values for an INDEX Can Now Be Used in
an RDO or SQL Import Operation................. 1-33
1.1.46 Column RDB$FILE_NAME in Table RDB$DATABASE
Returns Value.................................. 1-34
1.1.47 ALTER TABLE DROP CONSTRAINT Failed with VAX
Data Distributor Replication Transfer.......... 1-35
1.1.48 Setting the Number of VAXcluster Nodes Did
Not Work Correctly in Previous Versions of
Rdb/VMS........................................ 1-35
1.1.49 RDB-E-UNRES_REL Error Could Be Returned After
Performing an ALTER STORAGE MAP................ 1-36
1.1.50 Performance Improvement for Storing Unique
Sorted Indexes................................. 1-36
1.1.51 Clearer Error Message on CREATE/DEFINE STORAGE
MAP............................................ 1-37
1.1.52 Clearer Error Message When Dropping Index Used
by Storage Map................................. 1-38
v
1.1.53 Many Attaches to and Detaches from the Same or
Multiple Databases While Using Search Lists
to Point to the Database Used Up I/O Channel
Quota.......................................... 1-38
1.1.54 Enhanced Security Checking Implemented ........ 1-39
1.1.55 Sequential Retrieval No Longer Causes Problems
with Dynamic Optimizer......................... 1-39
1.2 SQL Software Errors Fixed in V4.2................ 1-39
1.2.1 Date/Time INTERVAL Arithmetic Returns Incorrect
Results........................................ 1-40
1.2.2 SUBSTRING Built-in Function FOR Clause
Restriction Lifted............................. 1-41
1.2.3 Metadata Corruption No Longer Results After
Committing Failed Metadata Changes for a DROP
TABLE CASCADE.................................. 1-41
1.2.4 CREATE TABLE Followed by SELECT Statement No
Longer Generates OBSOLETE_METADA Error......... 1-43
1.2.5 SET ALL CONSTRAINTS ON Statement Checks All
Attached Databases............................. 1-44
1.3 RMU Software Errors Fixed in V4.2................ 1-44
1.3.1 RMU/BACKUP/AFTER_JOURNAL Got Deadlock on Freeze
if Another DBR Process Ran At The Same Time.... 1-44
1.3.2 Restriction Lifted on the Use of the /NOSPAMS
Qualifier...................................... 1-46
1.3.3 .AIJ Files Are Now Validated When First
Opened......................................... 1-47
1.3.4 Problem with Displaying RMU/SHOW STATISTICS
Menus Fixed.................................... 1-47
1.3.5 RMU/SHOW STATISTICS Now Identifies Remote
Processes...................................... 1-48
1.3.6 Certain RMU Commands Can Now Be Performed on
Closed Databases............................... 1-48
1.3.7 RMU/EXTRACT Output for an SQL Constraint Check
Clause in a CREATE TABLE Statement for a
Multischema Database Returned a Syntax Error... 1-48
1.3.8 RMU/EXTRACT of RDO Trigger Fixed .............. 1-50
1.3.9 RMU/EXTRACT Now Produces Correct Results for
Views with Subexpressions...................... 1-51
1.3.10 RMU/EXTRACT Now Recognizes the Keyword ALL in
View Definitions............................... 1-52
1.4 RMU Software Errors Fixed But Not Documented in
V4.1............................................. 1-52
1.4.1 RMU/COPY DATABASE Error Fixed ................. 1-53
vi
1.5 RDO and RDBPRE Software Errors Fixed in V4.2..... 1-53
1.5.1 RDBPRE Detects Illegal ERASE and MODIFY Usage
With Cross Clause.............................. 1-53
1.5.2 RDO Concatenated Expressions in Nested FOR
Loops Returned Incorrect Results............... 1-54
1.5.3 RDO Concatenated Expressions Referencing
Multiple Databases Returned Incorrect
Results........................................ 1-54
1.5.4 STORE WITHIN and DISABLE/ENABLE COMPRESSION
Clauses Cannot Both Be Specified............... 1-55
1.6 RDML Software Errors Fixed in V4.2............... 1-55
1.6.1 Problem Running RDML on a System with No
Rdb/VMS License................................ 1-56
1.6.2 RDML No Longer Generates Incorrect
RDML-E-READ_ONLY Error......................... 1-56
1.6.3 RDML No Longer Generates Incorrect
RDML-W-JOIN_ATTRIBUTE Error.................... 1-56
1.7 SQL/Services Errors Fixed in V4.2................ 1-57
1.7.1 Undeleted Mailbox Channels Can Cause Server
Failure........................................ 1-57
1.7.2 SQL/Services Support for MS-DOS Windows
TCP/IP......................................... 1-58
2 Known Problems, Restrictions, and Other Notes
2.1 Known Problems and Restrictions in All Interfaces
for V4.2......................................... 2-1
2.1.1 Interaction of CDD/Repository and RMU
Privileges Access Control Lists................ 2-1
2.1.1.1 CDD/Repository Default Access Control....... 2-3
2.1.1.2 Problems Involving ACLs..................... 2-3
2.1.1.3 CDD Conversion Procedure.................... 2-5
2.1.1.4 Installing the Corrected CDDSHR Images...... 2-5
2.1.2 Layered Products May Alter Database Root Access
Privileges..................................... 2-7
2.1.3 Real Number Value Returned Incorrectly During
Index-Only Retrieval on Descending Index....... 2-8
2.1.4 UPDATE Privilege Checked Unnecessarily ........ 2-8
2.1.5 Access Violation at RDMS$$PRE_EXECUTION +
58 Results From Attempts to Access Certain
Views.......................................... 2-9
2.1.6 Bugcheck in RDMS$$COMPILE_INDEX_MAPS + 413 With
Sorted Partitioned Indexes..................... 2-10
vii
2.1.7 Timeout on Lock Conflict in Metadata May Cause
Bugcheck....................................... 2-10
2.1.8 Problem Creating Descending Partitioned Sorted
Index.......................................... 2-11
2.1.9 Restrictions on SQL ALTER STORAGE MAP
Statement...................................... 2-12
2.1.10 Timer Problem with C Functions ................ 2-14
2.1.11 Use of RDMS$BIND_SEGMENTED_STRING_COUNT May
Cause Virtual Memory Leakage................... 2-16
2.1.12 Read-Only Transactions Are Always ISOLATION
LEVEL SERIALIZABLE............................. 2-17
2.1.13 Delete Constraints Before Changing Field Data
Type........................................... 2-17
2.1.14 You Cannot Create or Access Databases on
DFS-mounted Disks.............................. 2-18
2.2 SQL Known Problems and Restrictions for V4.2..... 2-18
2.2.1 SQL Name Length Restrictions Affect RMU/LOAD
and RMU/UNLOAD Commands........................ 2-18
2.2.2 RMU/LOAD Record Definition Restricted to Table
and Domain Names From MCS Character Set........ 2-19
2.2.3 List Storage Maps Cannot Be Referenced Across
Catalogs....................................... 2-20
2.2.4 Images Required for Privileged Applications ... 2-21
2.2.5 SQL Pascal Precompiler Processes ARRAY OF
RECORD Declarations Incorrectly................ 2-21
2.2.6 Clarification of Cursors and USING CONTEXT
Clause......................................... 2-22
2.2.7 Using UPDATE ONLY Cursors With Selective
Indexes May Reduce I/O and Locking Problems.... 2-23
2.2.8 Positioned Insert Statement Does Not Allow
RETURNING Clause............................... 2-24
2.3 RMU Known Problems and Restrictions for V4.2..... 2-25
2.4 SQL/Services Known Problems and Restrictions for
V4.2............................................. 2-25
2.4.1 SQL/Services TCP/IP Support Doesn't Work for
Messages That Exceed the Client Write Buffer
Size........................................... 2-25
2.4.2 Problem Deinstalling SQL/Services in a
Multiversion Environment....................... 2-25
2.4.3 SQL/Services IVP May Fail if SYS$NODE Is Not
Defined........................................ 2-27
2.4.4 You Must Call SQLSRV_CLOSE_CURSOR() before
COMMIT WORK.................................... 2-27
viii
2.5 Documentation Errors, Omissions, and
Clarifications of Software Behavior for V4.2..... 2-27
2.5.1 Information Omitted from the VAX Rdb/VMS
Installation Guide Regarding the Installation
of the SQL$INT.EXE and SQL$SHRnn.EXE Shareable
Images......................................... 2-28
2.5.2 Using Global Buffers .......................... 2-28
2.5.2.1 Enabling Global Buffers..................... 2-29
2.5.2.2 Applications That Benefit from Using Global
Buffers..................................... 2-29
2.5.3 Changes to the Optimizer for Rdb/VMS V4.2 ..... 2-41
2.5.3.1 Setting Optimization Levels................. 2-41
2.5.3.2 Operators That Override the User-Selected
Optimization Level.......................... 2-45
2.5.3.3 Foreground-Background Competition
Implemented in Fast First Strategy.......... 2-45
2.5.3.4 Dbkey List Sort in the Leaf Strategy........ 2-46
2.5.4 RDMS$BIND_QG_CPU_TIMEOUT Logical Name
Implemented in Rdb/VMS V4.2.................... 2-47
2.5.5 Minimum Value for the SPAM Interval Changed
from 256 to 216................................ 2-48
2.5.6 RDM$BIND_CKPT_TRANS_LIMIT Logical Name Changed
to RDM$BIND_CKPT_TRANS_INTERVAL................ 2-48
2.5.7 Error in V4.1 VAX Rdb/VMS SQL Reference Manual,
Section D.6.1.................................. 2-48
2.5.8 Error in V4.1 VAX Rdb/VMS SQL Reference Manual,
ALTER DATABASE Statement....................... 2-49
2.5.9 Descriptions of Fields in RMS Record Definition
Files Produced by the RMU/ANALYZE Commands..... 2-49
2.5.10 Select-expr Argument Incorrectly Documented in
CREATE VIEW Statement.......................... 2-57
2.5.11 Initializing the Parameter in the PREPARE
Statement...................................... 2-57
2.5.12 Dropping Multiple Triggers in Single Command
Not Permitted.................................. 2-58
2.5.13 SQL Reference Manual Refers to Nonexistent
Statement...................................... 2-58
2.5.14 Query Governor Logicals Incorrectly
Documented..................................... 2-58
2.5.15 Cannot Specify Snapshot File Name for
Single-File Database........................... 2-58
2.5.16 DROP TABLE CASCADE Drops Associated Storage
Maps........................................... 2-59
ix
2.5.17 .OAIJ File Can Be Displayed Using the
RMU/DUMP/AFTER_JOURNAL Command................. 2-60
2.5.18 CAST Function Documentation Errors ............ 2-60
2.5.19 The VAX Rdb/VMS RMU Reference Manual Is
Unclear on When You Can Optimize .AIJ Files and
Incorrectly States You Cannot Optimize an .AIJ
File on Tape................................... 2-61
2.5.20 Clarification of How to Use the /[NO]CLUSTER
and /[NO]WAIT Qualifiers for the RMU/CLOSE
Command........................................ 2-62
2.5.21 Tape Requests and Problems Are Reported Only to
the Tape Operator for RMU Commands Issued from
a Batch Job.................................... 2-64
2.5.22 Buffer Management Changes for V4.0 ............ 2-65
2.5.23 Logical Name RDM$MON_USERNAME Is Documented
Only in V4.1 Release Notes..................... 2-67
2.5.24 Maintenance Operations for and Characteristics
of WORM Media Described Only in the V4.1
Release Notes.................................. 2-68
2.5.24.1 Maintenance Operations on WORM Media........ 2-68
2.5.24.2 WORM Media, Characteristics, and
Assumptions................................. 2-71
2.5.25 Database Key Recommendation Is Clarified ...... 2-74
2.5.26 Specification of Correlation Name in Table
References Is Restricted....................... 2-74
2.5.27 Correction for Database Keys Example .......... 2-75
2.5.28 RMU/SHOW STATISTICS Formatted Binary Output
File Changes Are Not Documented................ 2-75
2.5.29 Description of the Space Used by the New
Segmented String Structures on WORM Disks in
the VAX Rdb/VMS Guide to Database Maintenance
Is Incorrect................................... 2-78
2.5.30 SQLDA2 Null Indicator Data Type Is Incorrect .. 2-79
2.5.31 SQL ALTER DOMAIN and RDO CHANGE FIELD Statement
Restriction Is Undocumented.................... 2-79
2.5.32 Examples of Specifying Preferred Optimization
Mode Show Incorrect SQL Syntax................. 2-79
2.5.33 Reference to Example of Initialized Parameter
Is Incorrect................................... 2-80
2.5.34 INSERT Statement VALUES Clause Is Missing an
Argument....................................... 2-80
2.5.35 Value Returned by AVG Function ................ 2-80
x
2.5.36 Not All CDO and DTR Edit Strings Are Accepted
by SQL......................................... 2-81
2.5.37 Corrections to Tables in VAX Rdb/VMS Guide to
Using SQL/Services............................. 2-82
2.5.38 The VAX Rdb/VMS RDO Reference Manual Appendix C
Omits VAX Data Distributor Commands............ 2-84
2.5.39 RDB$MISSING Is Evaluated at Compile Time, Not
Run Time....................................... 2-85
2.5.40 SORTWORKn Logical Name Description Is
Inaccurate..................................... 2-87
2.5.41 Clarification on Setting the Read-Only
and Read/Write Attributes for the
RDB$SYSTEM Storage Area and Using the
RMU/ANALYZE/CARDINALITY/UPDATE Command......... 2-88
2.5.42 Clarification on the Relationship Between
the Number of Users and the Number of Nodes
Supported on a Database........................ 2-88
2.5.43 Clarification on Why Snapshot Files Grow in
Size........................................... 2-89
2.5.44 Request Handle Syntax Treated Differently in
Statistical Expressions........................ 2-91
2.5.45 Description of RMU/SHOW STATISTICS Checkpoint
Display Needs Clarification.................... 2-92
2.5.46 Using RDML and the Two-Phase Commit Protocol
by Calling the DECdtm System Service Calls
Implicitly and Explicitly Is Not Fully
Documented..................................... 2-92
2.5.47 Explanation of the Lock Conflict on Freeze
Errors......................................... 2-94
2.5.48 Explanation of RMU/SHOW STATISTICS Blocking
AST............................................ 2-96
2.5.49 Explanation of RMU/SHOW STATISTICS Stall
Messages....................................... 2-97
2.5.50 GROUP Privilege Is Not Necessary To Use
RMU/SHOW LOCKS................................. 2-99
2.5.51 V4.2 HELP For RMU States Incorrect MAX
Density........................................ 2-99
2.5.52 Error in COBOL Version of SQL$DIST_TRANS
Example........................................ 2-99
2.5.53 Syntax Diagram for ALTER STORAGE MAP Statement
in Rdb/VMS V4.2 SQL Online Help is Incorrect... 2-100
2.6 RDO and RDBPRE Known Problems and Restrictions
for V4.2......................................... 2-101
xi
2.6.1 Unexpected Constraint Failure When Using Nested
FOR Loops...................................... 2-101
2.6.2 TYPE IS ASCENDING and TYPE IS DESCENDING
Ignored for Hashed Indexes..................... 2-102
2.7 RMU Known Problems and Restrictions for V4.2..... 2-103
2.7.1 RMU/SET PRIVILEGE/EDIT Command Requires
Database To Be Offline......................... 2-103
2.8 CDD/Repository Notes of General Interest for
V4.2............................................. 2-103
2.8.1 Compatibility of CDD/Repository and Rdb/VMS ... 2-103
2.8.2 COUNT Function with DISTINCT Clause Generates
Dictionary Syntax Error........................ 2-107
2.9 CDD/Repository Restrictions...................... 2-108
2.9.1 Interaction of CDD/Repository and RMU
Privileges ACLs................................ 2-108
2.9.2 CDD/Repository Does Not Support Multiple
Character Sets................................. 2-108
2.9.3 CDD/Repository Does Not Support Delimited
Identifiers.................................... 2-109
2.9.4 Minimum Supported Version of CDD/Plus ......... 2-109
2.10 Restrictions Retained from V4.1.................. 2-109
2.10.1 Known Problems and Restrictions for All
Interfaces in V4.1............................. 2-109
2.10.1.1 Error Message Files Are Altered by
DECpresent V1.0............................. 2-109
2.10.1.2 Detaching from the Database Sometimes
Results in a Bugcheck....................... 2-110
2.10.1.3 Performance Problem Is Observed with
Rdb/VMS Distributed Update Transactions in
a Mixed VMS V5.4 and V5.5 Operating System
Environment................................. 2-110
2.10.1.4 Distributed Transaction Abort Error Will
Change from a Warning to an Error in a
Future Release of Rdb/VMS................... 2-111
2.10.1.5 VMS Lock Remastering Changed in VMS V5.4.... 2-111
2.10.1.6 Multiversion Problem Exists in Process
Environment When You Run RMONSTOP and
RMONSTART Procedures for Either V4.0 or
V4.0A....................................... 2-111
2.10.1.7 System Table Changes from V4.0 to V4.2 Cause
DEC RdbExpert for VMS V1.0 to Fail with
xii
NONULLIND Error............................. 2-113
2.10.1.8 Comparing Integer and Text Fields Causes
Problems.................................... 2-114
2.10.1.9 Fractional Seconds Precision Is Not Handled
Correctly................................... 2-114
2.10.1.10 Placement Using Sorted Indexes Can Result in
Performance Degradation over Time as Rows
Are Added and Index Key Values Updated...... 2-115
2.10.1.11 Deleted Space Is Not Reused Until the Next
Database Attach............................. 2-116
2.10.1.12 Digital Does Not Support Access to Rdb/VMS
Through an Asychronous System Trap (AST)
Service Routine in a User Application....... 2-118
2.10.1.13 Multiplex Feature Should Be Disabled
if Remotely Attaching to V3.1 or V4.0
Databases................................... 2-119
2.10.1.14 Using Quoted Threshold Values for Binary
Data Types for Partitioning Data or Indexes
Results in Data or Index Corruption......... 2-119
2.10.1.15 Triggers That Affect Subject Table Rows Can
Cause Loops or Inconsistent Results......... 2-120
2.10.1.16 Collating Sequences Producing Too Many Nulls
May Result in a Bugcheck Dump............... 2-121
2.10.1.17 You Cannot Correctly Import a Database That
Contains Computed-By Columns That Reference
Other Computed-By Columns................... 2-122
2.10.1.18 RDO Relation Name Must Match Dictionary
Record Name................................. 2-123
2.10.1.19 Certain Reserved Words Cannot Be Used as
Database Handles for RDBPRE or as Aliases
for SQL$PRE and SQL$MOD..................... 2-123
2.10.2 SQL Note of General Interest for V4.1 ......... 2-123
2.10.2.1 Using the SMALLINT Data Type and VAX C...... 2-124
2.10.3 SQL Known Problems and Restrictions in V4.1 ... 2-125
2.10.3.1 CREATE DATABASE Statement Must Lexically
Precede Any DECLARE TABLE Statement in
Precompiled Module or Module Language....... 2-126
2.10.3.2 SQL Users Using the Multiversion Kit Must
Link with the SQL$USER Logical Name......... 2-126
2.10.3.3 You Cannot Import a Multischema Database to
Earlier Versions............................ 2-126
2.10.3.4 You Cannot Use EXPORT WITH NO EXTENSIONS if
INTERVAL Is Defined......................... 2-126
xiii
2.10.3.5 SQL Object Module Incompatibility........... 2-127
2.10.3.6 Confusion over the Use of ASCII and ASCIZ in
Dynamic SQL and C Programs.................. 2-128
2.10.4 SQL/Services Known Problems and Restrictions in
V4.1........................................... 2-128
2.10.4.1 Process Logical Names Are Not Supported in
SQL/Services................................ 2-128
2.10.4.2 SQL/Services IVP Fails with-2034 Error Under
Rdb/VMS V4.1................................ 2-129
2.10.4.3 SQL/Services Compatibility Issue with the
Order of Include Files...................... 2-129
2.10.4.4 New DATE, TIME, TIMESTAMP, and INTERVAL
Data Types Are Not Directly Supported by
SQL/Services................................ 2-130
2.10.4.5 Problem with SQL/Services Cdev for the
Macintosh and the New Release of PATHWORKS
for Macintosh V1.1.......................... 2-131
2.10.4.6 Invalid Length Is Returned by SQLSRV_VARBYTE
Data Type................................... 2-132
2.10.4.7 Allocating Space for SQLSRV_VARCHAR and
SQLSRV_VARBYTE Data Types Can Cause a
Problem..................................... 2-132
2.10.4.8 SQL/Services Compatibility Issues........... 2-132
2.10.4.8.1 SQL/Services (V4.0 or Higher) Server Uses
Proxy-Like and Default Access to Authorize
V3.0 or 3.1 Client Applications........... 2-133
2.10.4.8.2 SQL/Services V4.0, V4.0A, V4.0B, or V4.1
Server Error -2031 Returned to V3.1 Client
APIs...................................... 2-133
2.10.4.8.3 Queue Manager Must Be Started for the
SQL/Services IVP to Work.................. 2-133
2.10.4.8.4 SQL/Services IVP Failure Caused by -2003
Network Error............................. 2-134
2.10.5 RDO Known Problems and Restrictions in V4.1 ... 2-134
2.10.5.1 Transaction Handle and Messages Vector Are
Not Always Available in Callable RDO........ 2-134
2.10.5.2 RDO Provides Limited Support for SQL
Date-Time Data Types........................ 2-135
2.10.5.3 RDO CONVERT Operation on V3.0 Databases
Causes Database Corruption When the Database
xiv
Is Converted to V4.0, V4.0A, V4.0B, V4.1, or
V4.2........................................ 2-136
2.10.5.4 RDO Export Operation May Return SQL Error
Messages.................................... 2-136
2.10.5.5 Aggregate Expressions in RDO Return an
Error....................................... 2-137
2.10.5.6 Loss of Precision for Text to Quadword
Assignment in RDB$INTERPRET................. 2-137
2.10.6 RDBPRE Known Problems and Restrictions for
V4.1........................................... 2-138
2.10.6.1 RDBPRE Upgrade from Rdb/VMS V3.0B to V4.0A
Results in Run-Time Error BAD_REQ_HANDLE On
Recompilation............................... 2-138
2.10.7 RMU Known Problems and Restrictions in V4.1 ... 2-140
2.10.7.1 Problems Using RMU Commands with SYSMAN..... 2-140
2.10.7.2 Problem Using the VMS ALLOCATE Command with
RMU Commands................................ 2-140
2.10.7.3 Restrictions on Using RMU Commands with the
/WORM and /NOSPAMS Qualifiers............... 2-141
2.10.7.4 Do Not Delete After-Image Journal (.AIJ)
Backup Files if the AIJ Backup Fails or Is
Terminated.................................. 2-141
2.10.7.5 RMU/EXTRACT Known Problems and Restrictions
in V4.1..................................... 2-142
2.10.7.5.1 VALID IF Clauses Are Converted to Domain
Level CHECK Constraints................... 2-143
2.10.7.5.2 Triggers in RDO Allow Users to Define a
Trigger Action Within a Join of Two or
More Tables............................... 2-143
2.10.7.5.3 VMS Style Dates and CURRENT_TIMESTAMP .... 2-146
2.10.7.5.4 RDO Removes Blank Lines in Multiline
Descriptions.............................. 2-146
2.10.7.5.5 RMU/EXTRACT Column Default Value
Restriction............................... 2-147
2.10.7.6 Clarification on the Meaning of Granted
and Requested in RMU/SHOW LOCKS Output
Displays.................................... 2-147
2.10.7.7 False BADFNMAIJ Errors Are Returned from
RMU/VERIFY During Root Verification......... 2-149
xv
2.10.8 CDD/Repository Known Problems, Restrictions,
and Notes for V4.1............................. 2-151
2.10.8.1 Problem with CDD/Repository and Views....... 2-151
2.10.8.2 Using CDD/Repository Global Fields with
Rdb/VMS..................................... 2-152
2.10.8.3 CDD/Repository, Rdb/VMS: Record and Field
Interaction................................. 2-156
2.10.8.4 Index Loses Attributes After an Integrate
Operation................................... 2-157
2.10.8.5 Compatibility of CDD/Repository and
Rdb/VMS..................................... 2-157
2.10.9 CDD/Plus V4.2A and V4.3 Known Problems and
Restrictions for V4.1.......................... 2-158
2.10.9.1 Importing a Multischema Database Referencing
CDD/Plus Causes Error....................... 2-158
2.10.9.2 Using CDD/Plus in a Multiversion
Environment................................. 2-159
2.10.9.3 SQL Interface Restrictions for CDD/Plus V4.3
and Earlier Versions........................ 2-160
2.10.9.4 Integrate Sometimes Fails with a
NO_META_UPDATE Error........................ 2-160
2.10.9.5 INTEGRATE Does Not Clear Change Messages.... 2-161
2.11 Restrictions Retained from V4.0.................. 2-161
2.11.1 Known Problems and Restrictions for All
Interfaces for V4.0............................ 2-161
2.11.1.1 Improving the Performance of the Export
Operation Using the DCL SET Command to
Change the Default Extend Parameter Value... 2-161
2.11.1.2 SNAPSHOTS DEFERRED May Stall Transactions... 2-162
2.11.1.3 PLACEMENT VIA INDEX Clause Prohibits Shadow
Clustering.................................. 2-162
2.11.1.4 RDB$SYSTEM Storage Area Cannot Be Read-Only
When a Relation Is Readied in Exclusive or
Batch-Update Mode........................... 2-163
2.11.1.5 Joined Relations Do Not Allow "MODIFY" if
Using the WITH Clause....................... 2-163
2.11.1.6 DECLARE and START Stream Are No Longer
Allowed for Certain Views................... 2-164
2.11.1.7 A Clarification of the Storage Algorithm for
Mixed Pages................................. 2-165
2.11.1.8 SELECT on DATABASE (READ on DATABASE) ACE Is
Now Required................................ 2-166
2.11.1.9 Rdb/VMS Network Link Failure Does Not Allow
xvi
FINISH (in V4.1, DISCONNECT) to Tidy Up
Transactions................................ 2-166
2.11.1.10 VAX Data Distributor Copy Processes Do
Not Process Database Pages Ahead of an
Application................................. 2-167
2.11.1.11 Setting an Appropriate WSEXTENT Relative to
WSQUOTA for SORT/MERGE Operations........... 2-168
2.11.1.12 Attempting to Acquire a Lock Could Cause an
Infinite Loop............................... 2-168
2.11.2 SQL Known Problems and Restrictions for V4.0 .. 2-169
2.11.2.1 SQL Allows False Redefinition of the DATE
Data Type................................... 2-169
2.11.2.2 Module Language Passes Extraneous Characters
with Inexact Dynamic Descriptors............ 2-170
2.11.2.3 Close List Cursor Before Fetching Rows from
Table Cursor................................ 2-170
2.11.2.4 When Using the BETWEEN Operator, You Should
Specify the Lower Value First............... 2-172
2.11.2.5 Cautions on Using ANY, ALL, or IN Clauses in
Constraint Definitions...................... 2-172
2.11.2.6 Release of Cursor Statements Referencing
Prepared Statements Causes Problems......... 2-172
2.11.2.7 SQL Does Not Translate Logical Names
Referencing Source Databases................ 2-173
2.11.2.8 Problem with Transferring a Table to an
Existing Database Containing the Same Table
Name........................................ 2-174
2.11.3 RDO and RDBPRE Known Problems and Restrictions
for V4.0....................................... 2-175
2.11.3.1 RDO SHOW USERS and SHOW MONITOR Statements
Do Not Work for Remotely Accessed
Databases................................... 2-175
2.11.4 RDML Known Problems and Restrictions for
V4.0........................................... 2-175
2.11.4.1 RDML Generates an Error Message When
Attempting to Store or Modify Read-Only
(COMPUTED BY) Fields........................ 2-175
2.11.5 RMU Known Problems and Restrictions for V4.0 .. 2-175
2.11.5.1 Single-File Databases Require the /ROOT
Qualifier When Using the RMU/MOVE_AREA
Command..................................... 2-176
2.11.5.2 The RMU/BACKUP/AFTER_JOURNAL /CONTINUOUS
/UNTIL="TOMORROW:+00:50" Command Fails for
xvii
V3.1A and VMS V5.3 or V5.4.................. 2-176
2.11.6 CDD/Plus Restrictions for V4.0 ................ 2-176
2.11.6.1 Problem Adding a New Field to CDO Defined
Record and Not to Last Position............. 2-176
2.11.6.2 SQL Does Not Recognize a Record During SQL
Precompile Time............................. 2-178
2.11.6.3 Some Views Are Not Accepted by VAX CDD/Plus
V4.2........................................ 2-178
2.11.7 Restrictions Lifted by CDD/Repository V5.0 .... 2-179
2.11.7.1 GRANT and REVOKE Statements Generate
MBLRSYNERR Message if Attached by Path
Name........................................ 2-179
2.11.8 Restrictions Lifted by CDD/Plus V4.2 .......... 2-179
2.11.8.1 Incompatibilities Between Rdb/VMS V4.0
and CDD/Plus That Have Been Lifted by
VAX CDD/Plus V4.2........................... 2-179
2.12 Restrictions Retained from V3.1.................. 2-179
2.12.1 Known Problems and Restrictions for All
Interfaces for V3.1............................ 2-179
2.12.1.1 Object Modules Created with V3.1 and V4.0
Are Not Downward-Compatible................. 2-180
2.12.1.2 With the Exception of Views, Do Not Add
Fields to Relations, or Define Indexes,
Triggers, and Other Database Objects Based
on System Relation Fields................... 2-180
2.12.1.3 Performance Considerations for Using VARYING
STRING or COLLATING SEQUENCE Attribute for
Index Keys.................................. 2-180
2.12.1.4 Sorting or Implied Sorting for Projection on
a Dbkey Is Not Worthwhile................... 2-183
2.12.1.5 IMPORT Statement Fails to Complete Index
Definition with Users Attached to the
Database.................................... 2-183
2.12.1.6 Using LIB$DT_INPUT_FORMAT to Change Date
Input Format Sometimes Causes Access
Violation................................... 2-183
2.12.1.7 Operations on F-Floating Data Round to Whole
Numbers..................................... 2-184
2.12.1.8 Rdb/VMS Interaction with Data Distributor
V2.1 May Generate Bugcheck Dumps............ 2-184
2.12.1.9 Problem Defining COLLATING SEQUENCE IS
NORWEGIAN NORWEGIAN......................... 2-185
2.12.1.10 Snapshot File Name, File Type, or Version
xviii
Number Cannot Be Changed for Single-File
Databases................................... 2-186
2.12.1.11 Rdb/VMS and VMS Debugger Interaction........ 2-187
2.12.1.12 Using Rdb/VMS from a VMS Detached Process... 2-189
2.12.2 SQL Known Problems and Restrictions for V3.1 .. 2-190
2.12.2.1 DDL Statements Cannot Refer to Objects
Before Their Creation....................... 2-190
2.12.2.2 SQL Schema Compilation Fails on the First
Fatal Error................................. 2-190
2.12.2.3 COMMENT ON Statement Cannot Be Used in
CREATE SCHEMA Statement..................... 2-191
2.12.2.4 Dynamic Cursors Cannot Access Views Created
with GROUP BY or UNION Clause............... 2-191
2.12.2.5 You Cannot Use INCLUDE Statement in Variable
Declaration................................. 2-191
2.12.2.6 SQL Ada Precompiler Does Not Support the
Correct Overloading of Subprograms.......... 2-191
2.12.2.7 SQL Precompiler Does Not Evaluate
Expressions in Variable Declarations or
Understand Literals......................... 2-192
2.12.2.8 SQL Ada Precompiler Does Not Support Named
Literals or Ranges.......................... 2-193
2.12.2.9 SQL Module Language Processor Fails on the
First Fatal Error........................... 2-193
2.12.3 RDO and RDBPRE Known Problems and Restrictions
for V3.1....................................... 2-194
2.12.3.1 Database Handle Scope....................... 2-194
2.12.3.2 Problem of Different Optimizations of the
Same Query from Different Environments...... 2-194
2.12.3.3 Restrictions on Using Missing Value Fields
in Nested Queries........................... 2-195
2.12.4 RDML Known Problems and Restrictions for
V3.1........................................... 2-196
2.12.4.1 Variables Cannot Be Database Handles........ 2-196
2.12.4.2 RDML Run-Time Object Library No Longer
Requires You to Link with VAXCRTL or
VAXCRTLG Object Libraries or Shareable
Images...................................... 2-198
2.12.4.3 RDML/EPascal Ignores
/LINKAGE=PROGRAM_SECTION Qualifier.......... 2-198
2.12.4.4 RDML/Pascal Does Not Understand Some
Character String Value Expressions.......... 2-199
xix
2.12.4.5 RDML/Pascal Does Not Accept All Possible
Valid Pascal Host Language Variables........ 2-199
2.12.4.6 RDML Does Not Allow Nested Comments......... 2-200
2.12.4.7 C Host Variables............................ 2-200
2.12.4.8 C String Continuation Character............. 2-201
2.12.4.9 Path Name and the DATABASE Statement........ 2-201
2.12.5 RMU Known Problems and Restrictions for V3.1 .. 2-202
2.12.5.1 RMU/SHOW STATISTICS Command Does Not Record
All Statistics in the Binary File........... 2-202
2.12.5.2 Dumping the .AIJ File Is Incompatible with
Normal Usage................................ 2-202
2.12.6 DSRI Notes and Restrictions Retained from
V3.1........................................... 2-203
2.12.6.1 RCI Instantiation Number Must Be Zero for
Remote Access............................... 2-203
2.12.6.2 Context Variables That Are Not Unique Within
a Request Cause Invalid BLR................. 2-203
2.12.7 CDD/Plus Restrictions Retained from Rdb/VMS
V3.1........................................... 2-204
2.12.7.1 CDD/Plus COMPUTED BY Fields Are Not
Currently Supported in Rdb/VMS Relations or
Views....................................... 2-204
A How to Order Additional Documentation
Tables
2-1 Compatibility Between Storage Area Attributes
and Disk Drive Types........................... 2-73
2-2 CDO Edit Strings Supported by SQL ............. 2-81
2-3 SQL Statements That Can Be Dynamically
Executed....................................... 2-82
2-4 SQL Statements That Cannot Be Dynamically
Executed....................................... 2-84
2-5 Compatibility of the Data Dictionary and
Rdb/VMS........................................ 2-104
xx
_________________________________________________________________
Send Us Your Comments
We welcome your comments on this manual or any Rdb/VMS
manual. If you have suggestions for improvement or find
any errors, please indicate the chapter, section, and page
number (if available). Your input is valuable in improving
future releases of our documentation.
You can send comments to us in the following ways:
o Electronic mail - DATABASE_DOC@WEORG.ENET.DEC.COM
o FAX - 603-884-0829 Attn: Rdb/VMS Documentation
o Postal service
Digital Equipment Corporation
Information Design and Consulting
55 Northeastern Boulevard, NUO1-1/G10
Nashua, NH 03062-3187
USA
___________________________________________________________
If you like, you can use the following questionnaire
to give us feedback. (Edit the online file
SYS$HELP:RDBVMS042.RELEASE_NOTES, extract a copy of this
questionnaire, and send it to us.)
xix
Name _____________________________Title____
________________________
Company __________________________Department
__________________
Mailing Address Telephone Number
_____________________________ ____________
___________________________________________________________________________
Book Title _______________________Version_Number
______________
1. Did you encounter any delays or obstacles in obtaining
your documentation order from Digital Equipment
Corporation? If so, please describe.
2. How can we improve the usability of our documentation
set?
3. Which do you usually use first-online help or the
reference manuals? Why?
4. Interviews, telephone surveys, user observation,
questionnaires, and other similar activities help us
to improve our documentation. May we contact you about
participating in future efforts?
5. Other comments:
xx
_________________________________________________________________
Preface
VAX Rdb/VMS software, Version 4.2, often referred to as
V4.2 in this text, is a general-purpose database management
system based on the relational data model.
This text describes problems fixed in this release, current
problems, restrictions, and other notes.
Unlike the Release Notes for previous versions of Rdb/VMS,
this text does not describe new and changed features. For
V4.2, new and changed features are described in the VAX
Rdb/VMS New and Changed Features.
________________________ Note ________________________
The release notes are supplied in online form in
SYS$HELP. Both PostScript and .TXT files are provided.
The .TXT form is called RDBVMS042.RELEASE_NOTES and
the PostScript form is called RDBVMS042_RELEASE_
NOTES.PS.
______________________________________________________
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 documentation set.
To get the most from your reading, you should be familiar
with Rdb/VMS, data processing procedures, and basic
database management concepts and terminology.
xxi
A Note on the Terminology
When the SQL, RDO, and RDML interfaces use different terms
to describe the same entity or concept, this manual uses
the SQL term, unless the discussion is specifically about
RDO or RDML. (This is also true of most of the other
manuals in the Rdb/VMS documentation set.) For example,
this manual normally uses table instead of relation,
column instead of field (of a relation), and row instead
of record.
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 compatibility information about other software products
used with this version of Rdb/VMS, refer to the System
Support Addendum (SSA) that is included 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 the following chapters:
Chapter 1 Describes known software errors in versions
prior to Rdb/VMS V4.2 that were fixed in V4.2.
Chapter 2 Describes problems, restrictions, and
workarounds known to exist in Rdb/VMS. This
chapter also includes restrictions retained
from previous versions of Rdb/VMS.
Related Manuals
VAX Rdb/VMS Release Notes are provided only as part of the
software kit. PostScript and .TXT source files for the VAX
Rdb/VMS Release Notes are available in SYS$HELP.
All other books are available in both Bookreader and
printed form. An appendix in the VAX Rdb/VMS New and
Changed Features contains ordering information.
xxii
For more information on VAX Rdb/VMS, see the following
books in the Rdb/VMS documentation set:
o VAX Rdb/VMS New and Changed Features
Describes the new features and technical changes
provided in Rdb/VMS Version 4.2. Includes general
changes, changes to each interface, and changes in
glossary terms and logical names.
o Getting Started with VAX Rdb/VMS
Introduces VAX Rdb/VMS, the Digital relational database
management system for VMS software environments.
Explains relational database concepts. Introduces using
SQL to retrieve, store, and update data.
o VAX Rdb/VMS Glossary and Master Index
Defines terms used in the documentation for Rdb/VMS and
related products. Provides a master index to the entire
Rdb/VMS documentation set.
o VAX Rdb/VMS Guide to Using SQL
Introduces the Rdb/VMS SQL (Structured Query Language)
interface, and shows how to retrieve, store, and update
data interactively and through application programs. Can
be used as a tutorial for learning the major features of
SQL.
o VAX Rdb/VMS Guide to Using SQL/Services
Describes how to develop application programs that use
SQL/Services, a client/server software component of
Rdb/VMS. SQL/Services allows programs invoked on various
remote computers running the Macintosh, MS-DOS, OS/2,
SunOS, ULTRIX, ULTRIX for RISC, or VMS operating systems
to access Rdb/VMS as well as other databases supported
by SQL on a VMS server system.
o VAX Rdb/VMS Guide to Distributed Transactions
Describes the two-phase commit protocol and distributed
transactions, explains how to start and complete
distributed transactions using SQL, RDBPRE, and RDML,
and how to recover from unresolved transactions using
RMU commands.
o VAX Rdb/VMS Guide to Database Design and Definition
xxiii
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
Explains how to use the database maintenance utilities
to perform such operations as database monitoring,
security auditing, opening and closing a database,
verifying and altering a database, backing up,
restoring, and recovering a database, journaling
database activity, modifying database characteristics,
and handling bugcheck dumps.
o VAX Rdb/VMS Guide to Database Performance and Tuning
Describes how to analyze the elements that affect
database performance and how to tune those elements
to optimize performance. Contains decision trees that
provide an organized approach to identifying and solving
common database performance problems.
o VAX Rdb/VMS SQL Reference Manual
Provides reference material and a complete description
of the statements, the interactive, dynamic, and
module language interfaces, and the syntax for SQL,
the structured query language interface for Rdb/VMS.
o VAX Rdb/VMS RMU Reference Manual
Provides reference material and a complete description
of the commands and syntax of the Rdb/VMS Management
Utility (RMU).
o VAX Rdb/VMS RDO Reference Manual
Provides reference material and a complete description
of the statements and syntax of the Rdb/VMS Relational
Database Operator (RDO) interface.
o VAX Rdb/VMS Installation Guide
Describes how to install Rdb/VMS and SQL/Services
Application Programming Interface (API) Software.
xxiv
Conventions
In examples, an implied carriage return occurs at the end
of each line, unless otherwise noted. You must press the
Return key at the end of a line of input.
Often in examples the prompts are not shown. Generally,
they are shown where it is important to depict an
interactive sequence exactly; otherwise, they are omitted
in order to focus full attention on the statements or
commands themselves.
This section explains the conventions used in this manual:
Vertical ellipsis points in an example mean that
. information not directly related to the example
. has been omitted.
.
. . . Horizontal ellipsis points in statements or
commands mean that parts of the statement or
command not directly related to the example have
been omitted.
< > Angle brackets enclose user-supplied names.
[ ] Brackets enclose optional clauses from which you
can choose one or none.
$ The dollar sign represents the DIGITAL Command
Language prompt. This symbol indicates that the
DCL interpreter is ready for input.
References to Products
The Rdb/VMS documentation to which this document belongs
often refers to products by their abbreviated names:
o CDD/Repository software is referred to as
CDD/Repository. Its predeccessor, VAX CDD/Plus software,
is referred to as CDD/Plus. Both products are often
referred to as the data dictionary, the dictionary, or
the repository.
o DEC RdbExpert for VMS software is referred to as
RdbExpert.
o DECtrace for VMS software is referred to as DECtrace.
o PL/I for VAX VMS software is referred to as PL/I.
xxv
o VAX ACMS software is referred to as ACMS.
o VAX Ada software is referred to as Ada.
o VAX BASIC software is referred to as BASIC.
o VAX C software is referred to as C.
o VAX COBOL software is referred to as COBOL.
o VAX Data Distributor software is referred to as Data
Distributor.
o VAX DATATRIEVE software is referred to as DATATRIEVE.
o VAX DBMS software is referred to as VAX DBMS.
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 environments. In the latter case,
either VAXELN Pascal or VAX Pascal is specified.
o VAX RALLY software is referred to as RALLY.
o VAX Rdb/ELN software is referred to as Rdb/ELN.
o VAX Rdb/VMS software is referred to as Rdb/VMS. VAX
Rdb/VMS software Versions 3.1, 3.1A, and 3.1B, are often
referred to as V3.1, V3.1A, and V3.1B respectively. VAX
Rdb/VMS software Versions 4.0, 4.0A, and 4.0B are often
referred to as V4.1, V4.0, V4.0A, V4.0B respectively.
o VAX SQL software is referred to as VAX SQL whenever it
is correct to refer to V2.0 or earlier of SQL. The use
of SQL by itself indicates the SQL interface included as
part of VAX Rdb/VMS V3.1 and higher.
o VAX TEAMDATA software is referred to as TEAMDATA.
o VAX TDMS software is referred to as TDMS.
xxvi
1
_________________________________________________________________
Software Errors Fixed
The following sections describe problems with previous
versions of the Rdb/VMS software that are fixed in V4.2.
The chapter begins with information pertinent to all users.
Later sections contain material specifically for users of
SQL, RMU, RDO, RDML, and SQL/Services.
The notes in this chapter may use different database terms
to mean the same thing. For example, some terms used by SQL
differ from terms used by other interfaces, such as RDO or
RDML. Table 1 in the VAX Rdb/VMS New and Changed Features
shows some of the different terms used.
1.1 Software Errors Fixed in V4.2 That Apply to All Interfaces
This section describes problems fixed in all interfaces for
V4.2.
1.1.1 Bugcheck at RDMS$$COMPILE_INDEX_MAPS + 413 Forced Exit Due
to Improper Check of the CRTV
Prior to V4.2, a section of code that handled the
compilation of index maps by reading through the CRTV
(current index retrieval block) for a given index caused
bugchecks due to the way the code handled the check. Rather
than exiting the loop at the end of the CRTV for the given
index, it continued to other CRTVs in the chain.
The problem occurred when a partitioned index was defined
where the index is partitioned and more than one index
segment defines the partition criteria.
For example:
Software Errors Fixed 1-1
SQL> CREATE INDEX PH_IDX02
cont> ON PERFORMANCE_HISTORY (
cont> YEAR
cont> ASC,
cont> MONTH
cont> ASC,
cont> DAY_OF_WEEK
cont> ASC,
cont> HOUR
cont> ASC,
cont> MINUTE
cont> ASC,
cont> NODE_NAME
cont> ASC,
cont> MODE
cont> ASC)
cont> TYPE IS SORTED
cont> NODE SIZE 2006
cont> PERCENT FILL 90
cont> PERCENT FILL 90
cont> STORE USING (YEAR, MONTH) <------ use of YEAR *and* MONTH
cont> IN PH_IDX02_1
cont> (THRESHOLDS ARE (70, 90, 95))
cont> WITH LIMIT OF ('1992', '03')
cont> IN PH_IDX02_2
cont> (THRESHOLDS ARE (70, 90, 95))
cont> WITH LIMIT OF ('1992', '04')
cont> IN PH_IDX02_3
cont> (THRESHOLDS ARE (70, 90, 95))
cont> WITH LIMIT OF ('1992', '05')
cont> OTHERWISE IN PH_IDX02_4
cont> (THRESHOLDS ARE (70, 90, 95));
SQL>COMMIT WORK;
This problem is fixed in Rdb/VMS V4.2.
1.1.2 Bugcheck at ADD_STRG_TO_STBL_LISTS + 00000037
In versions prior to V4.2, when Rdb/VMS deleted or updated
objects such as constraints, triggers, and indexes, the
tables that are referenced by the deleted object were
marked so that the metadata associated with the tables
was updated the next time a reference is made to the table.
1-2 Software Errors Fixed
In most circumstances Rdb/VMS reloads table metadata
correctly; however, in rare cases, on creation of a new
trigger, previous versions of Rdb/VMS referred to a table
that does not yet have its metadata reloaded.
In these cases, Rdb/VMS bugchecked with the following
exception:
***** Exception at 00274118 : ADD_STRG_TO_STBL_LISTS + 00000037
A workaround for this problem was to disconnect from the
database and attach again immediately before creating any
new triggers.
This problem is fixed in Rdb/VMS V4.2.
1.1.3 Bugcheck at RDMS$$INSERT_SYMBOL + 0BC and Other Offsets
Bugchecks have been observed with an exception at
RDMS$$INSERT_SYMBOL + 0BC under Rdb/VMS V4.1 and previous
versions. (They also occur under other offsets, such as
+ B8.) This bugcheck is rare and is generally caused by a
lock conflict on freeze or timeouts when Rdb/VMS tries to
load metadata information for a table.
The lock conflict forces unloading of the metadata
information. However, the unload operation does not clean
up some symbol table information. When a metadata reload is
attempted, the bugcheck occurs because the reload operation
tries to insert information into the symbol table that
already exists.
This problem is fixed in Rdb/VMS V4.2.
1.1.4 Bugcheck at DBR$ASSIGN_WORK_FILE + 0000018B When Starting
Monitor from Invalid Directory with FAST COMMIT Enabled
A problem occurred in Rdb/VMS V4.1 in which database
recovery (DBR) might fail if the process being recovered
had not yet created an .RUJ file. This problem occurred
only when the FAST COMMIT feature was enabled and one of
the following conditions was true:
o You started the monitor from a directory that did not
exist.
o The default directory was subsequently removed while the
monitor is running.
Software Errors Fixed 1-3
You must start the monitor from a valid directory.
DBR failed because it tried to create a work file in its
default directory, which it inherited from the monitor.
Of course, if the default directory did not exist, the
creation of the work file failed.
If DBR fails because it cannot create the work file, the
database will be shut down by the monitor. No database
corruption results from this problem, because there is
nothing to REDO and, of course, nothing to UNDO.
The problem is aggravated by running the IVP during product
installation. Running the IVP starts the monitor from a
directory that will be deleted when the IVP completes.
The problem can be identified in the bugcheck file produced
by DBR. The exception will be at "DBR$ASSIGN_WORK_FILE
+ 0000018B" (error creating work file). The name of the
deleted directory is also displayed.
If this problem occurs, you must stop and then restart the
monitor, from an existing directory, before the database
can be used again.
This problem is fixed in Rdb/VMS V4.2. DBR now properly
determines whether transaction REDO is required.
1.1.5 Bugcheck at MON$CREATE_TROOT_SECTION + CB When Monitor
Generated Section Name That is Not Unique
Prior to Rdb/VMS V4.2, the monitor occasionally failed at
MON$CREATE_TROOT_SECTION with the following error:
Exception At MON$CREATE_TROOT_SECTION+CB
%RDMS-F-BUGCHECK, fatal, unexpected error detected
This problem, which is exceptionally rare, occurs when the
monitor generates a random global section name that already
exists. The random-name generation routine for the monitor
relies on the PID (process ID) for uniqueness. Because the
monitor is a persistant process whose PID never changes, it
is possible to generate a duplicate global section name if
multiple sections were created in rapid succession.
This problem is fixed in Rdb/VMS V4.2. Now each global
section name produced by a process with a particular PID
must also be unique.
1-4 Software Errors Fixed
1.1.6 Bugcheck at PSIISCAN$END_SCAN + 26 Occurred After Lock
Exceptions
Prior to Rdb/VMS V4.2, a bugcheck could occur after a lock
exception such as %RDMS-F-DEADLOCK, deadlock on freeze. In
engineering tests, this bugcheck occurred at PSIISCAN$END_
SCAN + 26, although offsets could vary. Such bugchecks were
caused by a timing window problem when Rdb/VMS cleaned up
the lock failure.
This problem is fixed in Rdb/VMS V4.2.
1.1.7 Bugcheck Produced by Restoring Storage Area to Bound-Volume
Set
Prior to Rdb/VMS V4.2, attempts to restore a database
storage area to a bound-volume set could produce a bugcheck
with the following exception:
%RMU-F-FILACCERR, error truncating file
DISK$DEVICE:[DIRECTORY]DATABASE.RDB;1
-SYSTEM-W-ACCONFLICT, file access conflict
This problem occured because Rdb/VMS attempted to spread
the file allocation evenly over all the volumes of the
bound volume. Rdb/VMS does this to spread the I/O requests
to the file over all the volumes and to thus reduce
bottlenecks due to individual disk performance.
In spreading the file, Rdb/VMS attempts to allocate the
same fractional size of the file on each bound volume. (For
example, an 80,000 block file on an eight-volume bound-
volume set would be allocated as approximately eight 10,000
block segments, one on each volume.)
However, VMS actually allocates a file segment in multiples
of the disk cluster size. (For the preceding 80,000 block
file example above, when the cluster size is 24 blocks,
VMS allocates 7 file segments of 10,008 blocks and one
file segment of 9960 blocks, for a total of 80,016 blocks
allocated.) This is normally not a problem when the total
file allocation is large relative to the product of the
cluster size and the number of volumes.
Software Errors Fixed 1-5
However, when the file size is relatively small, each
file segment may actually be less than half the cluster
size; this condition causes the problem described. For
example, using an 80-block file with the bound volume in
our example, the first segment is requested as 10 blocks,
but 24 blocks are allocated by VMS. The second segment
is requested as 10 blocks, for a total allocation of 20
blocks; however, because the physical allocation is already
24 blocks, this second segment represents not an extension
of the file but a truncation. The truncation, had it been
successful, would not have actually changed the allocation
of the file. Consequently, the 80-block file would be
allocated as 24, 0, 24, 0, 24, 0, 0, 24 blocks respectively
for a total allocation of 96 blocks.
A file can be extended while other processes have the file
open; unfortunately, VMS does not permit file truncation
unless the file is accessed EXCLUSIVE (no other readers or
writers allowed). This restriction results in the reported
error.
This problem is fixed in Rdb/VMS V4.2.
1.1.8 Bugcheck at RDMS$$EXE_OPEN + 78 on Query
Prior to V4.2, the following query resulted in a bugcheck
at RDMS$$EXE_OPEN + 78 because a structure containing
information about a loaded table was not properly loaded
before the second open cursor. For example:
SQL> ATTACH 'FILENAME TEST';
SQL> CREATE TABLE TAB (COL SMALLINT);
SQL> INSERT INTO TAB VALUES (100);
SQL> DECLARE C1 CURSOR FOR SELECT COL FROM TAB ORDER BY COL;
SQL> OPEN C1;
SQL> FETCH C1;
SQL> COMMIT;
SQL> OPEN C1;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file DISK4:[WD]RDSBUGCHK.DMP;1
%SQL-I-BUGCHKDMP, generating bugcheck dump file DISK4:[WD]SQLBUGCHK.DMP;1
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=00000034, PC=00000000, PSL=00000000
SQL>
This is a known problem in V3.1B, V4.0, V4.0A, V4.0B, and
V4.1. This problem is fixed in Rdb/VMS V4.2.
1-6 Software Errors Fixed
1.1.9 Bugchecks May Result from Database Access During Recovery
In Rdb/VMS V4.1, the following bugcheck exceptions could
occur if a database metadata index scan was started while a
database recovery was in progress:
***** Exception at 00244FF0 : PSIISCAN$END_SCAN + 00000026
%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual
address=FFE0F310, PC=00244FF0, PSL=01400004
...
***** Exception at 002337E2 : LCK$HANDLE_DEADLOCK + 00000063
%RDMS-F-DEADLOCK, deadlock on freeze
The access violation (ACCVIO) in the routine PSIISCAN$END_
SCAN is due to an invalid attempt to free some virtual
memory after the freeze lock deadlock exception was
received.
This problem is fixed in Rdb/VMS V4.2.
1.1.10 Bugcheck at KOD$UNBIND + 133 Affected Unbinding From
Database
Prior to V4.2, users might encounter a bugcheck at
KOD$UNBIND + 133 with an error of %SYSTEM-F-SUBLOCKS
when lock remastering occurs and a process that was doing
Rdb/VMS activity ends (normally or abnormally).
When this problem occurs, the database remains locked: you
can only release the lock by deleting all processes that
have locks associated with the database.
To avoid the problem, disable dynamic lock remastering
on VMS V5.5 systems by setting the "PE1" SYSGEN parameter
(online) to "1" on all nodes in the cluster.
This problem is fixed in Rdb/VMS V4.2.
1.1.11 Possible Database Corruption from Fragmented Segmented
String Records
In Rdb/VMS V4.1, database corruption can occur if the
segmented string record becomes fragmented. Rdb/VMS V4.0
introduced an optimization when allocating segmented
strings. This optimization avoids extending the area
by reusing space that was made available in the current
transaction. In other words, if a segmented string was
previously deleted (either by deleting the row, assigning
Software Errors Fixed 1-7
NULL to the column, or replacing the value with new data)
the old segments were saved and recycled.
Unfortunately, in cases where the old segment was too
small for the new data, the segment could be fragmented.
In addition, if the old segment was less than 10 bytes long
(including a standard 5-byte header) then the fragmentation
information would not fit in the available space, thus
corrupting the database page.
This corruption cannot occur in V4.0, or in V4.1 with the
RDMS$USE_OLD_SEGMENTED_STRING logical defined, because
the smallest segmented string segment is 13 bytes long.
However, in V4.1, segments can be stored that are less than
10 bytes long. An example would be any segment of a LIST OF
BYTE VARYING that is less than 5 bytes long.
To avoid this problem, define the RDMS$USE_OLD_SEGMENTED_
STRING logical system wide so that Rdb/VMS always uses the
old style segmented strings. For example:
$ DEFINE SYSTEM/EXECUTIVE/NOLOG RDMS$USE_OLD_SEGMENTED_STRING TRUE
________________________ Note ________________________
This corruption does not occur in the following
situations:
o If you use WORM (WRITE ONCE) areas, this corruption
will not occur in those areas because the segmented
string data is never revised.
o If you use CDD/Plus or CDD/Repository, this
corruption cannot occur within dictionary database
because the data dictionary always uses the old
style segmented strings.
______________________________________________________
This problem is corrected in Rdb/VMS V4.1A and Rdb/VMS
V4.2. The correction to the problem may also improve
retrieval performance of segmented strings because Rdb/VMS
no longer fragments any segmented string segments that are
recycled.
1-8 Software Errors Fixed
1.1.12 Memory Corruption Error Fixed
Prior to V4.2, random bugchecks, looping, and other
abnormal behavior occurred due to memory corruption. The
most common bugchecks reported for this particular problem
occurred in the routine KOD$GET_VM at any of the queue
related instructions (INSQHI, REMQHI, etc.). The exception
was typically a SYSTEM-F-ACCVIO or a SYSTEM-F-ROPRAND.
When the following sequence of events occurred while
initializing a buffer allocated for a fragmented record,
Rdb/VMS would incorrectly write past the end of the buffer
and would zero any data structures that resided in memory
after the buffer:
1. A large record was written.
2. A smaller record was written. The record was too big for
the storage area it would be stored in and it had to be
fragmented.
When this was done, Rdb/VMS erroneously initialized
the buffer for the fragmented record using the previous
record's longer length and therefore wrote past the end of
the buffer that was actually allocated. Whatever resided in
virtual memory after the allocated buffer got zeroed. This
problem was very timing dependent and the exact sequence of
events described above must occur for it to happen.
There is no recommended workaround. This problem is fixed
in Rdb/VMS V4.2
1.1.13 RMU/CLOSE/CLUSTER/ABORT=FORCEX Caused Monitor Abnormal
Termination
Prior to V4.2, the monitor terminated abornormally when you
used a command like the following to close the database:
$ RMU /CLOSE /ABORT=FORCEX /CLUSTER
The error log was one of the following:
"***** Exception at 000068D4 : MON$RELEASE_LCKTRM_USER + 0000006C"
"***** Exception at 00004DD2 : MON$FREE_VM + 0000001B"
Software Errors Fixed 1-9
This problem was caused by a timing condition in the
cluster-wide database close procedure, where it was
possible for a database recovery process (DBR) to be
started because a user process was abnormally terminated
(CTRL-Y/STOP or DELETE/QUEUE) while the database was in the
process of being closed on a cluster with the /ABORT=FORCEX
qualifier.
________________________ Note ________________________
This problem only occured when using the /CLUSTER
qualifier. It did not occur when using the
/ABORT=DELPRC qualifier.
______________________________________________________
To reproduce this problem in the debugger, use the
following time line diagram:
Time Node A Node B
==== =============== ================
1 P1 binds DB
2 P2 binds DB
3 P2 does CTRL-Y (no STOP yet!)
4 P3 issues RMU/CLOSE/DATABASE
/ABORT=FORCEX/WAIT command
5 P2 does STOP at DCL prompt
6 monitor dies with exception
If was possible to prevent this problem from occurring
by ensuring that no processes are in the process of being
recovered when you closed the database. Therefore, the
workaround was to use the RMU/SHOW USERS command to verify
that no processes are being recovered before issuing the
RMU/CLOSE/ABORT=FORCEX/CLUSTER command.
This problem is fixed in Rdb/VMS V4.2.
1-10 Software Errors Fixed
1.1.14 Monitor Exhausted Virtual Memory
Using Rdb/VMS V4.1 with databases containing a large number
of global buffers or a large number of storage areas, the
database monitor could exhaust virtual memory, prohibiting
additional database attaches, as follows:
o When the database parameters were set to "OPEN IS
MANUAL", successive or repetitive opening and closing
of the databases eventually caused the database monitor
to run out of virtual memory.
o When the database parameters were set to "OPEN IS
AUTOMATIC", repetitive "first" user binds eventually
caused the database monitor to run out of virtual
memory. This condition was harder to detect and prevent.
The problem was caused by the monitor creating a global
section that contained more than 32,000 VMS pages of
memory.
________________________ Note ________________________
A VMS page does not correspond to a database page.
Each VMS page is 512 bytes.
______________________________________________________
When a global section containing more than 32,000 VMS pages
was created and subsequently deallocated, the memory became
inaccessible for subsequent global sections larger than
32,000 VMS pages. Note that the large global section memory
was still accessible for other databases whose global
sections contained fewer than 32,000 VMS pages.
To identify the problem, check the monitor's peak virtual
size occasionally, using the DCL SHOW PROCESS/ACCOUNT
command. If, when you open and close a database repeatedly,
the monitor's peak virtual size increases uniformly,
the monitor will eventually exhaust its virtual memory
quota. After the virtual memory quota is exhausted, Rdb/VMS
prohibits any subsequent database opens.
Software Errors Fixed 1-11
For example:
$ SHOW SYSTEM
VAX/VMS V5.5 on node LLAMA 2-SEP-1992 14:45:25.26 Uptime 0 05:45:29
Pid Process Name State Pri I/O CPU Page flts Ph.Mem
00000213 RDMS_MONITOR41 LEF 15 26 0 00:00:00.70 388 137
$ ! **** Show the monitor peak virtual size.
$ SHOW PROCESS/ACCOUNT /ID=00000213
2-SEP-1992 14:45:58.84 User: SYSTEM Process ID: 00000213
Node: LLAMA Process name: "RDMS_MONITOR41"
Accounting information:
Buffered I/O count: 8 Peak working set size: 594
Direct I/O count: 18 Peak virtual size: 2735
Page faults: 390 Mounted volumes: 0
Images activated: 0
Elapsed CPU time: 0 00:00:00.70
Connect time: 0 05:44:29.32
$ ! ***** Open the database with global buffers
$ RMU/OPEN SQL$DATABASE /GLOBAL=(TOTAL=10000, USER=100)
$ ! **** Show the monitor peak virtual size.
$ SHOW PROCESS/ACCOUNT /ID=00000213
2-SEP-1992 14:47:49.50 User: SYSTEM Process ID: 00000213
Node: LLAMA Process name: "RDMS_MONITOR41"
Accounting information:
Buffered I/O count: 20 Peak working set size: 3415
Direct I/O count: 34 Peak virtual size: 213064
Page faults: 11468 Mounted volumes: 0
Images activated: 0
Elapsed CPU time: 0 00:00:18.57
Connect time: 0 05:46:19.98
$ RMU/CLOSE SQL$DATABASE
$ ! **** Reopen the database
$ RMU/OPEN SQL$DATABASE /GLOBAL=(TOT=10000, USER=100)
$ ! **** Show the increased monitor peak virtual size.
$ SHOW PROCESS/ACCOUNT /ID=00000213
1-12 Software Errors Fixed
2-SEP-1992 14:49:06.17 User: SYSTEM Process ID: 00000213
Node: LLAMA Process name: "RDMS_MONITOR41"
Accounting information:
Buffered I/O count: 27 Peak working set size: 5852
Direct I/O count: 45 Peak virtual size: 283550
Page faults: 30868 Mounted volumes: 0
Images activated: 0
Elapsed CPU time: 0 00:00:40.85
Connect time: 0 05:47:36.64
$ RMU/CLOSE SQL$DATABASE
$ RMU/OPEN SQL$DATABASE /RMU/OPEN SQL$DATABASE /GLOBAL=(TOTAL=10000, USER=100)
$ SHOW PROCESS/ACCOUNT /ID=00000213
2-SEP-1992 14:50:16.67 User: SYSTEM Process ID: 00000213
Node: LLAMA Process name: "RDMS_MONITOR41"
Accounting information:
Buffered I/O count: 34 Peak working set size: 7016
Direct I/O count: 56 Peak virtual size: 354036
Page faults: 45640 Mounted volumes: 0
Images activated: 0
Elapsed CPU time: 0 00:01:02.74
Connect time: 0 05:48:47.14
The only known workaround was to change the database
parameters to "OPEN IS MANUAL" and leave the database
permanently open instead of automatically open.
You could delay the problem by increasing the monitor's
PGFLQUOTA parameter value, using the VMS Authorize utility.
However, it is possible for active databases to eventually
exhaust any PGFLQUOTA setting.
This problem is fixed in Rdb/VMS V4.2.
1.1.15 Too Many Operands in Field Caused Stack Overflow
Prior to Rdb/VMS V4.2, if you tried to create an object
such as a view or a trigger that contained a field
expression with more than 35 operands, a memory stack
overflow might occur, terminating the executing process.
Software Errors Fixed 1-13
For example, the following trigger definition caused a
premature termination of the executing process:
SQL> CREATE TABLE A (FIELD1 INT);
SQL> CREATE TABLE B (FIELD1 INT);
SQL> CREATE TRIGGER TRIG1 AFTER INSERT ON A
cont> (INSERT INTO B VALUES
cont> (
cont> f1+f1+f1+f1+f1+f1+f1+f1+f1+f1+
cont> f1+f1+f1+f1+f1+f1+f1+f1+f1+f1+
cont> f1+f1+f1+f1+f1+f1+f1+f1+f1+f1+
cont> f1+f1+f1+f1+f1+f1+f1+f1+f1+f1
cont> )
cont> ) FOR EACH ROW;
You can prevent this problem by partitioning the operands
into groups of 30 or fewer by the use of brackets.
This problem is fixed in Rdb/VMS V4.2. Rdb/VMS V4.2 reduces
the actual stack memory required for each operand within
the field expression, thus allowing a greater number of
operands. In addition, an extra check is carried out when
each operand is evaluated. If the expression encroaches on
the stack limit, this check raises the following exception:
XPR_STACK_OFLO expression forces too many levels of recursion
1.1.16 DBR Processes May Hang Due To Waiting Lock Requests
Prior to V4.2, under certain circumstances, DBR (database
recovery) might hang forever. Because of the VMS lock
manager behavior of granting WAIT queue lock requests
only when the CONVERT queue for that lock resource was
empty, the DBR could be starved of an area lock. This
problem could be identified by examining the RMU/SHOW LOCKS
utility output and identifying storage area locks for the
DBR process waiting on the WAIT queue.
Consider an area A that process 1 and process 2 had in
Concurrent Write (CW). Let process 3 be on the CONVERT
queue for area A and let the requested mode be Protected
Write (PW). If process 2 died and a DBR came up for the
dead process, it tried to get area A in CW. However,
because this was a new lock request, the VMS lock manager
placed this request on the WAIT queue and would not service
the request until the PW was granted. Because the mode
requested by the DBR was compatible with the currently
1-14 Software Errors Fixed
granted mode, process 1 was not blasted to release the lock
and thus the DBR was starved of the lock.
This problem is fixed in Rdb/VMS V4.2.
The DBR is now made to get an area lock in NL (expedite)
mode, which places future lock requests for that resource
on the convert queue instead of the wait queue. Because the
default behavior for convert queue lock requests is jump (a
conversion request is granted if the currently granted mode
is compatible with itself, no matter what process is ahead
on the queue), the DBR gets the area lock ahead of the PW.
1.1.17 .AIJ File Could Contain Duplicate Data Records
Prior to V4.2, .AIJ data records could be duplicated in the
.AIJ file under two conditions:
o During large group commit operations, where the data
being written to the .AIJ file exceeded 64 blocks
o During .AIJ lock rebuild operations
You could not distinguish between the two conditions by
analyzing the .AIJ file. However, you could sometimes
identify the problem by dumping the .AIJ file and
examining the "TAD=" line. Every "TAD=" date-time should
be equal to or greater than the previous date-time. This
detection algorithm only works for single-node systems;
on VAXclusters, it may not work due to differences in the
real-time clocks on the various nodes.
Note that, while .AIJ data is merely duplicated, not lost,
the resulting .AIJ file may be considered "corrupt" by the
roll-forward utility if it encounters .AIJ data records it
did not expect.
There is no workaround for this problem, although Digital
highly recommends that you back up the database often.
This problem is fixed in Rdb/VMS V4.2. Data is now
journaled in the .AIJ file without being duplicated.
Rdb/VMS V4.2 corrects the formatting of .AIJ request
blocks (ARBs) into the .AIJ cache, so that ARBs are always
atomically formatted, not partially formatted. In addition,
when Rdb/VMS rebuilds the .AIJ lock value block, if the
number of bytes used is nonzero, then the last written .AIJ
block must be the first block in the .AIJ cache.
Software Errors Fixed 1-15
1.1.18 REORGANIZE PAGES Clause Now Supports Single Storage Area
Prior to V4.2, when a REORGANIZE PAGES clause occured
within an SQL ALTER STORAGE MAP statement or an RDO CHANGE
STORAGE MAP command that specified only one storage area,
Rdb/VMS ignored the REORGANIZE PAGES clause.
This is because the REORGANIZE function moved only records
that could be directly placed on the newly hashed data
pages, and when only one area was available, there were not
enough "holes" in the area to do this.
Starting in V4.2, this restriction is removed. The
REORGANIZE PAGES clause will now execute when only one
area is specified in the storage map.
1.1.19 REORGANIZE Now Succeeds When SQL ALTER STORAGE MAP or RDO
CHANGE STORAGE MAP Lacks PLACEMENT VIA INDEX Clause
Prior to V4.2, when an SQL ALTER STORAGE MAP statement or
an RDO CHANGE STORAGE MAP command specified both REORGANIZE
PAGES and a PLACEMENT VIA INDEX clause, Rdb/VMS ignored the
REORGANIZE PAGES and only recognized the REORGANIZE AREAS
clause.
This problem is fixed in Rdb/VMS V4.2. The REORGANIZE PAGES
clause now executes either using the current settings of
the storage map or overriding the current settings with new
/changed attributes from the ALTER STORAGE MAP statement.
1.1.20 REORGANIZE PAGES Clause Moves Data More Efficiently
Prior to V4.2, when an ALTER STORAGE MAP statement
included the REORGANIZE PAGES clause, data was not moved
efficiently.
Starting in V4.2, the reorganize facility recognizes tuples
that have already been relocated within an operation.
1.1.21 A Self-Insert Query With Mapped Columns Incorrectly Stored
NULL Values
Prior to Rdb/VMS V4.2, Rdb/VMS inserts NULL values instead
of aggregated values when both of the following conditions
are true:
o The query selected the data from and inserted into the
same table.
1-16 Software Errors Fixed
o The columns in the SELECT list were mapped columns
(either GROUP BY plus aggregate columns or UNION
columns).
For example, NULL values would be inserted into queries
like the following:
SQL> INSERT INTO MY_TAB
cont> SELECT SUM(A), SUM(B), SUM(C), SUM(D)
cont> FROM MY_TAB
cont> GROUP BY A;
This problem could have also occured if the SELECT
statement had an UNION clause.
This problem is fixed in Rdb/VMS V4.2.
1.1.22 Runtime Error Message About Inaccessible .AIJ File Added
If the .AIJ file fills up or becomes inaccessible because
of media failure or disk drive problems, the database
also becomes inaccessible. While this is correct behavior,
previous versions of Rdb/VMS gave no runtime information,
and minimal offline information to identify the cause
of the problem. The only hint was a single line from the
RMU/DUMP utility that said the .AIJ file was inaccessible.
The error returned from a process that subsequently
attempted to access the database was RMDS-F-TERMINATE;
however, the monitor log file showed nothing other than
abnormal terminations. In other words, the error message to
the process said that the monitor was forcing you out, but
the monitor log seemed to indicate that the process gave
up. This was inconsistent and confusing.
In V4.2, when a process detects that an .AIJ file is
inaccessible, the database will be marked as inaccessible
(as previously occurred), and the process will terminate
with a new exit status, RDMS-F-AIJTERMINATE. This status
code has the message "inaccessible .AIJ file forced image
exit to protect database," which should serve to indicate
the exact cause of the problem. Also, the status code help
information indicates what actions are necessary to correct
the problem.
The actions necessary to recover from an inaccessible .AIJ
file are correctly documented in Section 6.2.8 of the VAX
Rdb/VMS Guide to Database Maintenance.
Software Errors Fixed 1-17
1.1.23 Unnecessary Arithmetic Exceptions for Divide and Multiply
Operations Corrected
Under certain circumstances, Rdb/VMS unnecessarily
generated arithmetic exceptions for queries involving
division and multiplication operations. This occured when
Rdb/VMS evaluated a division expression involving a divisor
value of 0, or a multiplication of two large values, prior
to applying a selection predicate that would have excluded
the row under consideration (thus making the performed
operation unnecessary).
The following sequence of statements demonstrates the
unnecessary arithmetic exception for a division operation.
The first row causes a divide-by-zero exception, even
though the WHERE clause excludes this row from the returned
results.
SQL> CREATE TABLE FOO (
cont> COL1 INTEGER(2), COL2 INTEGER(2),
cont> COL3 INTEGER(2), COL4 INTEGER(2));
SQL>
SQL> INSERT INTO FOO VALUES ( 1.00, 0.00, 0.00, 2.00);
SQL> INSERT INTO FOO VALUES ( 1.00, 1.00, 0.00, 2.00);
SQL>
SQL> SELECT (COL1/(COL2+COL3)), COL4
cont> FROM FOO WHERE (COL2+COL3) <> 0
cont> ORDER BY 1,COL4;
%RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime
-SYSTEM-F-FLTDIV_F, arithmetic fault, floating divide by zero at PC=003D9D46,
PSL=01C00004
This problem is fixed in Rdb/VMS V4.2.
1.1.24 Number of I/O Channels Increased to Correct IMPORT Error
Prior to Rdb/VMS V4.2, attempts to import large databases
with many storage areas might fail with the following
error:
%SQL-F-NOIDXRES, unable to import index SX_CONS_MONEY_PREM_DT
%RDB-F-SYS_REQUEST, error from system services request
-RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-FILACCERR, error opening storage area file {filename}
-SYSTEM-F-NOIOCHAN, no I/O channel available
1-18 Software Errors Fixed
The error happens because Rdb/VMS has a hardcoded limit on
the number of open channels that it will allow from EXEC
mode for each stream. For previous versions of Rdb/VMS, the
limit was 512 open channels per database attach.
You could work around the problem by using fewer storage
areas, or by adding DROP INDEX statements to the IMPORT
to reduce the number of storage areas opened during index
creation for each table.
This problem is fixed in Rdb/VMS V4.2. The maximum number
of open I/O channels has been increased from 512 to 1536.
You must increase CHANNELCNT parameter (the maximum number
of open channels allowed by VMS) correspondingly, using the
SYSGEN utility.
1.1.25 Trailing Spaces in Selection Value Caused Incorrect Data
Retrieval
When all of the following were true, Rdb/VMS did not return
the correct set of database rows:
o The database was defined with a collating sequence.
o An index was defined and used for the table being
accessed.
o The selection value contained one or more trailing
spaces.
The trailing spaces in the selection value caused Rdb/VMS
to incorrectly retrieve the data values from the index.
The following sequence of statements demonstrates this
problem:
Software Errors Fixed 1-19
SQL> CREATE DATABASE FILENAME DB1
cont> COLLATING SEQUENCE IS GERMAN GERMAN;
SQL> CREAtE TABLE TABLE1 (FIELD1 CHAR (5));
SQL> INSERT INTO table1 (FIELD1) VALUES ('one');
SQL> INSERT INTO TABLE1 (FIELD1) VALUES ('one');
SQL> --
SQL> -- Put some spaces after the value. The data is returned correctly.
SQL> SELECT * FROM TABLE1 WHERE FIELD1 = 'one ';
FIELD1
one
one
2 rows selected
SQL> -- Create an index to be used in the subsequent retrieval.
SQL> CREATE INDEX TABLE1_INDEX ON TABLE1 (FIELD1);
SQL> --
SQL> -- Issue the same query as above. The data is no longer returned.
SQL> SELECT * FROM TABLE1 WHERE FIELD1 = 'one ';
0 rows selected
To avoid the problem, do not specify selection values that
include spaces.
This problem is fixed in Rdb/VMS V4.2.
1.1.26 Expression Within GROUP BY Clause May Cause Incorrect
Results When Selecting Rows from a View
Rdb/VMS returns incorrect results when you select rows
from a view and specify an expression within a GROUP BY
clause. This problem occurs only when the GROUP BY clause
includes a column that is defined as an expression within
the original view definition. Examples of expressions
are arithmetic operations (such as COL1 + COL2) and cast
operations (such as CAST(COL1 AS REAL)). The following
example illustrates the problem:
1-20 Software Errors Fixed
SQL> CREATE TABLE TT (A INTEGER, B INTEGER);
SQL> CREATE VIEW VV (X, Y) AS SELECT A+B, B FROM TT;
SQL> CREATE VIEW CAST_VV (M, N) AS SELECT CAST(A AS REAL), B FROM TT;
SQL> --
SQL> INSERT INTO TT (A, B) VALUES (1, 1);
1 row inserted
SQL> INSERT INTO TT (A, B) VALUES (2, 1);
1 row inserted
SQL> INSERT INTO TT (A, B) VALUES (1, 2);
1 row inserted
SQL> INSERT INTO TT (A, B) VALUES (2, 2);
1 row inserted
SQL> --
SQL> -- This query returns the correct results.
SQL> SELECT A, B, A+B FROM TT GROUP BY A, B;
A B
1 1 2
1 2 3
2 1 3
2 2 4
4 rows selected
SQL> -- This query returns incorrect results for the first row.
SQL> SELECT X, Y FROM VV GROUP BY X, Y;
X Y
0 1
3 1
3 2
4 2
4 rows selected
SQL> -- This query returns incorrect results for every row.
SQL> SELECT M, N FROM CAST_VV GROUP BY M, N;
M N
0.0000000E+00 1
0.0000000E+00 2
0.0000000E+00 1
0.0000000E+00 2
4 rows selected
This problem is fixed for Rdb/VMS V4.2.
Software Errors Fixed 1-21
1.1.27 Update Attempt Generated Incorrect RDB-E-READ_ONLY_REL
Error
Rdb/VMS V4.1 returned an incorrect RDB-E-READ_ONLY_REL
error when you use a reserved table as the source for an
update statement. The following example shows the sequence
of commands that generate the error:
SQL> SET TRANSACTION READ WRITE
cont> RESERVING TABLE1 FOR SHARED WRITE,
cont> TABLE2 FOR SHARED READ;
SQL> UPDATE TABLE1
cont> SET FIELD1 = (SELECT FIELD1 FROM TABLE2);
%RDB-E-READ_ONLY_REL, relation TABLE2 was reserved for read access;
updates not allowed
This problem is fixed for Rdb/VMS V4.2. The READ_ONLY_REL
error message no longer appears in this situation.
1.1.28 Incorrect Value Returned by Index-Only Retrieval on Mapped
Index
Due to a problem in the decompression of compressed
integers within a mapped index, incorrect values may be
returned during queries that carry out index-only retrieval
on the mapped index.
For example:
1-22 Software Errors Fixed
SQL> CREATE TABLE T1 (F1 INTEGER, F2 INTEGER, F3 INTEGER);
SQL> CREATE INDEX I1 ON T1
(F1 , F2 MAPPING VALUES 70000000 TO 99999999);
SQL> INSERT INTO T1 VALUE ( 1, 79999991, 1);
1 row inserted
SQL> INSERT INTO T1 VALUE ( 1, 79999994, 1);
1 row inserted
SQL> INSERT INTO T1 VALUE ( 1, 79999998, 1);
1 row inserted
SQL> SELECT * FROM T1;
Get Retrieval by index of relation T1
Index name I1 [0:0]
F1 F2 F3
1 79999991 1
1 79999994 1
1 79999998 1
3 rows selected
SQL> SELECT F2 FROM T1;
Index only retrieval of relation T1
Index name I1 [0:0]
F2
79999991
79999991
79999995
3 rows selected
If this problem occurs, use one of the following
workarounds:
o Drop the mapped index and recreate the index with the
same columns but without mapped values.
o Alter the query so that index-only retrieval is not
chosen by the optimizer. For example, select a column
that is not used in the mapped index in addition to the
columns you require:
SQL> SELECT F2, F3 FROM T1;
This problem is fixed in Rdb/VMS V4.2.
Software Errors Fixed 1-23
1.1.29 Segmented Index Search Returned Incorrect Results
After you upgraded to Rdb/VMS v4.1, queries that used
segmented indexes might return incorrect results.
The problem occurred because a select statement that has
value qualifiers that fall between two existing index
keys used the btree index. The btree search algorithm
incorrectly chose the lesser index key as matching the
search criteria.
For example:
SQL> CREATE DATABASE FILENAME 'RDB41_MIN_FAIL';
SQL> CREATE TABLE TABLE_MIN_FAIL (C1 SMALLINT, C2 SMALLINT, C3 SMALLINT);
SQL> INSERT INTO TABLE_MIN_FAIL (C1,C2,C3) VALUES (1,1,1);
SQL> INSERT INTO TABLE_MIN_FAIL (C1,C2,C3) VALUES (2,1,1);
SQL> COMMIT WORK;
SQL> SELECT MIN(C2) FROM TABLE_MIN_FAIL WHERE C1=1 AND C2=2;
NULL
1 row selected
SQL> CREATE UNIQUE INDEX IND_MIN_FAIL ON TABLE_MIN_FAIL (C1,C2,C3);
SQL> CREATE WORK;
SQL> SELECT MIN(C2) FROM TABLE_MIN_FAIL WHERE C1=1 AND C2=2;
1 << ---------------
1 row selected
This problem is fixed in Rdb/VMS V4.2.
1.1.30 Multisegment Index Retrieval Using Variables May Return
Incorrect Results
In Rdb/VMS V4.1, a query may return incorrect results if
each of the following circumstances are true:
o The query predicate contains a nondistributed Boolean
clause (AND, OR) and also a column that uses variables
for comparison values.
o There is a multisegment index defined and used for the
table being queried.
o The predicate column using variables for comparison
values is not the first segment of the multisegment
index.
1-24 Software Errors Fixed
The problem is that for this type of multisegment index
retrieval, when Rdb/VMS internally distributes the pieces
of the Boolean clause over the remaining pieces of the
predicate, it fails to recognize that these remaining
pieces might have contained variables. This causes Rdb/VMS
to execute the index key value assignment code during the
query compilation stage, rather than at query execution
time, yielding incorrect results.
The following example illustrates the problem, using the
PERSONNEL database:
! First create the multisegment index using SQL.
ATTACH 'FILENAME PERSONNEL';
CREATE INDEX INDEX1 ON EMPLOYEES (SEX, BIRTHDAY);
! Then, execute the following SQL$PRE query, where the variable
! date_1 contains a binary date value. Both segments of the INDEX1 index
! (SEX and BIRTHDAY) will be used for the retrieval, however incorrect
! results are returned because Rdb does not properly recognize that
! the BIRTHDAY column uses a variable.
EXEC SQL SELECT COUNT(*) INTO :count FROM EMPLOYEES
WHERE ((SEX = 'M' OR SEX = 'F') AND BIRTHDAY = :date_1);
To avoid the problem, distribute the contents of the OR
clause. For example, rewriting the preceding query as
follows returns the correct results:
EXEC SQL SELECT COUNT(*) INTO :count FROM EMPLOYEES
WHERE ((SEX = 'M' AND BIRTHDAY = :date_1)
OR
(SEX = 'F' AND BIRTHDAY = :date_1));
This problem is fixed in Rdb/VMS V4.2.
1.1.31 RDMS$RUJ Logical Defined As Filename Instead of Directory
Specification Caused RUJ Problems
In previous releases of Rdb/VMS, a problem could occur
when you defined the RDMS$RUJ logical name to include a
filename, as shown in the following example:
$ DEFINE RDMS$RUJ DISK:[DIR]FILE.RUJ
Software Errors Fixed 1-25
If several users used this logical name definition at the
same time, all .RUJ files would exist in the same directory
and have the same RUJ filename. If anyone subsequently
purged the directory while other users were accessing the
database, one or more RUJ files could be deleted.
To avoid this problem in versions prior to V4.2, specify
only a device and directory when defining the RDMS$RUJ
logical name: do not include a filename.
This problem is fixed in Rdb/VMS V4.2.
If you define the RDMS$RUJ logical name to include a
filename, Rdb/VMS V4.2 ignores the filename. Note that
Rdb/VMS does not issue an error status code if the you
define the logical incorrectly.
1.1.32 Default AIP Length for List Storage Areas Increased
The area inventory page (AIP) points to the area bit map
for each table. When a list is mapped to a storage area
(other than the default) the AIP length is set to 5 (the
size of the on-disk record header). This causes poor store
sequence because many almost full pages are read, but are
not used.
In V4.2, the default length is set to 150 (as is used for
the default list storage area).
1.1.33 Virtual Memory Now Released by a Failing SET TRANSACTION
Statement with a Large Transaction Parameter Block (TPB)
An SQL SET TRANSACTION statement is translated into a
transaction parameter block (TPB). In certain previous
versions of Rdb/VMS, an application with a TPB greater than
128 bytes that repeatedly attempted to start a transaction
but failed (due to lock conflicts, for example), would not
release the virtual memory for the TPB.
A SET TRANSACTION statement with many tables in a RESERVING
list or many constraints in an EVALUATING list can generate
a TPB greater than 128 bytes. In this case, the virtual
memory (VM) will exceed the standard size reserved by
Rdb/VMS. Therefore, VM is allocated for the transaction
parameter buffer, which is normally released on a commit
or rollback operation. However, due to a lock conflict (or
1-26 Software Errors Fixed
some other failure), the VM is never released because a
commit or rollback operation is not possible.
This is a known problem in V4.0, V4.0A, V4.0B, and V4.1.
This problem may occur less frequently in V4.1 because
a TPB size of up to 512 bytes is possible before VM
is allocated. Therefore, under the scenario previously
described, this problem is less likely to consume VM.
This problem is fixed in Rdb/VMS V4.2.
1.1.34 Metadata Corruption No Longer Results from Committing
Failed ALTER, CREATE, or DROP Statements
In previous versions of Rdb/VMS, metadata data corruption
could occur if you executed a COMMIT statement after
receiving an error during a CREATE, DROP, or ALTER
statement.
This problem does not affect user data in any way. If
the view, trigger, or constraint definitions are not
referenced, they cause only an inconvenience.
Symptoms of the corruption include error messages when
referencing those database objects after using a COMMIT
statement. The SHOW command or a data manipulation
statement may produce the following errors:
SQL> SELECT * FROM RESUME_VIEW;
%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no longer associated
with a record
-RDMS-F-NODBK, 1:670:0 does not point to a data record
SQL> SELECT * FROM RESUME_VIEW;
%RDB-E-OBSOLETE_METADA, request references metadata objects that no longer
exist
-RDMS-F-BAD_SYM, unknown relation symbol - RESUME_VIEW
Additionally, database objects may be displayed with
information from other objects. For example, an SQL SHOW
TRIGGER command may show the source of a constraint.
The problem involves an optimization for segmented strings
that was added in Rdb/VMS V3.1. In this release, deleted
segmented string segments were placed on a delete-deferred
list, rather than being deleted immediately.
Software Errors Fixed 1-27
When a new segmented string segment is needed, Rdb/VMS
recycles the previously deleted segments from the delete-
deferred list instead of requesting that a new storage
segment be created. This optimization allows Rdb/VMS to
reuse space and avoid storage area extensions.
When a failure occurs during a metadata update, the
recycling is not undone correctly, leaving segmented string
segments on the delete-deferred list. Failures during
metadata updates might include:
o Lock conflicts during attempts to perform concurrent
metadata operations while the table is in use
o Constraint failures
o Failures during integration with the CDD/Repository
If you execute a COMMIT statement, the delete-deferred
list is scanned and the segments (even though still in
use) are deleted. This results in definitions pointing
to nonexistent segments, causing the NODBK and NO_RECORD
errors shown in the preceding example.
Conversely, if you create a new definition before a COMMIT
statement, Rdb/VMS finds segmented string segments on
the delete-deferred list and reuses them. This results
in two (or more) definitions using the same segmented
string segment. Because the last usage determines the
contents, the SQL SHOW command will show source definitions
associated with different objects.
A workaround is to use the DROP RESTRICT option rather
than the DROP CASCADE option in SQL, or to issue a ROLLBACK
statement after any data definition command (CREATE, DROP,
ALTER) failure. The Rollback operation always correctly
undoes the changes made by metadata operations. The BAD_SYM
error is caused by a failure to correctly undo the failed
metadata operation. If the application or interactive user
attaches to the database again, then the object will be
referenced correctly.
This is a known problem in V3.1, V3.1A, V3.1B, V3.1C, V4.0,
V4.0A, V4.0B, and V4.1. This problem is fixed in Rdb/VMS
V4.2.
1-28 Software Errors Fixed
1.1.35 Storage Map Recovery Problem Corrected
When an ALTER STORAGE MAP statement failed for a list
storage area, the memory copy of the map was corrupted.
A subsequent ALTER STORAGE MAP statement, followed by a
COMMIT statement, could leave the database corrupt.
In V4.2, the old storage map is now correctly recovered.
1.1.36 Clearer Error Message for List Storage Area Deletions
Previous versions of Rdb/VMS returned the following error
message when you attempted to delete a list storage map:
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-BADSEGSTROPT, option specified is incompatible
with segmented string storage maps
This error message has been replaced by the message shown
in the following example:
SQL> DROP STORAGE MAP LISTS_MAP;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-SSAREANOTEMPTY, segmented string area RESUME_LISTS is not empty,
it may not be deleted
You will receive this error whenever you attempt to delete
a list storage map. This is because the default segmented
string storage area (which must appear in the map) still
has data, namely the system relations segmented strings.
1.1.37 RDO and SQL IMPORT Statements Map List Tables and Columns
Correctly
In previous versions, the IMPORT statement did not inform
Rdb/VMS of the table and column name when importing a list
(segmented string). Therefore the list storage map could
not be used during creation of the list, and the mapping
was deferred until the creation of the row. In some cases
this resulted in an error: because the list was too large
to write to a buffer, and it was forced to the default list
storage area.
A workaround was to use the RDMS$BIND_SEGMENTED_STRING_
BUFFER logical to allocate a large list buffer for use
during the import operation.
Software Errors Fixed 1-29
This is corrected for Rdb/VMS V4.2. The IMPORT statement
now informs Rdb/VMS of the mapping so that even if the
buffer size is too small the list will always be written to
the correct storage area.
1.1.38 RDO and SQL IMPORT Statement TRACE Option Displays SORT
Usage
When a table has a storage map that specifies placement
via a hashed index (PLACEMENT VIA INDEX clause), the IMPORT
statement automatically presorts the data by target dbkey
to reduce I/O operations during the data import stage.
The IMPORT TRACE statement now displays information about
the usage of SORT in such cases as shown in the following
example:
.
.
.
IMPORTing relation EMPLOYEES
...defining index EMPLOYEES_HASH needed for storage map EMPLOYEES_MAP
Sort for PLACEMENT VIA INDEX --------------------- Version: V5-000
Records Input: 100 Sorted: 100
RecLen Input: 149 Intern: 151 Output: 149
Nodes in SortTree: 1312 Work File Alloc: 0
Completed EMPLOYEES. DIO = 227, CPU = 0:00:00.81, FAULTS = 849
Starting INDEX definition EMP_EMPLOYEE_ID
Completed EMP_EMPLOYEE_ID. DIO = 31, CPU = 0:00:00.06, FAULTS = 1
.
.
.
The IMPORT statement uses this information to estimate
disk space requirements for sort work files used by IMPORT
during this phase. The "Work File Alloc" value displays the
number of sort work files in use and is controlled by the
logical name RDMS$BIND_SORT_WORKFILES. In this example, no
work files were used, because the entire set of records was
sorted in memory. The "Records Input" value is the number
of records in the table, and the "RecLen Intern" value is
the byte length of the internal representation of the row
to be sorted; it includes the eight bytes for the dbkey of
the target page.
1-30 Software Errors Fixed
1.1.39 Singleton Select with View Returned Zero Dbkeys
Prior to Rdb/VMS V4.2, Rdb/VMS returned a zero dbkey to a
parameter in a module or an embedded SQL program instead
of returning the dbkey for a single record selected. The
following statement is an example of a singleton select
statement that elicited the problem behavior:
EXEC SQL CREATE VIEW V1 AS SELECT * FROM EMPLOYEES LIMIT TO 1 ROW;
This problem is fixed in Rdb/VMS V4.2. Rdb/VMS returns the
correct dbkey values.
1.1.40 Failure to Delete or Update Existing Records
Under certain circumstances, previous versions of Rdb/VMS
failed to select records to delete or update.
This failure occured, in general, under the following
conditions:
o An index exists on the table that will be operated on,
and that index is used for selection of the records to
be deleted or updated.
o The display of the strategy using the RDMS$DEBUG_FLAG =
"S" shows that a temporary table is being used.
o A substring expression is used on a column within the
table to select the appropriate records.
o The last record selected by the selection criteria is
not the last record that exists within the index.
An example of a query failed to correctly delete records is
:
DELETE FROM TAB1 WHERE SUBSTRING(F1 FROM 1 FOR 3) = 'AAA';
where an index exists on column F1.
This problem is fixed in Rdb/VMS V4.2.
Software Errors Fixed 1-31
1.1.41 Error on a Two-Phase Commit Protocol Start Transaction
Caused an Access Violation
In V4.1, it was possible to get an access violation
starting a distributed transaction. The access violation
occurs only if there was an error when starting the
transaction.
SQL> ATTACH 'ALIAS ONEDB FILENAME WORK$DB:PERSONNEL.RDB';
SQL> ATTACH 'ALIAS TWODB FILENAME WORK$DB:PERSONNEL.RDB';
SQL> SET TRANSACTION ON ONEDB USING (READ ONLY WAIT 3) AND ON TWODB
cont> USING (RESERVING TWODB.EMPLOYEES FOR PROTECTED WRITE WAIT 3);
If there is an error on the SQL SET TRANSACTION statement,
for example, due to a lock timeout condition, an access
violation can occur.
This is a known problem in V4.0, V4.0A, V4.0B, and V4.1.
This problem is fixed in Rdb/VMS V4.2.
1.1.42 SPAM Pages Are Not Initialized by an Incremental Restore
Operation if the Restore Operation Is Adding a Storage
Area
In V4.1, when an incremental backup operation followed a
restructuring operation that included adding a new storage
area and the database is later fully and incrementally
restored, the incremental restore operation generates
warnings and fails to regenerate the database because it
cannot initialize the SPAM pages for the new storage area.
This problem is fixed in Rdb/VMS V4.2.
1.1.43 CREATE VIEW Problem with Included Column Derived from
DBKEY Corrected
Prior to V4.2, attempts to create views referencing dbkey
columns generated the BAD_CODE error. This error occurred
when you created a view that included a column from another
view that was derived from a dbkey, as in the following
example:
1-32 Software Errors Fixed
SQL> CREATE TABLE TABLE_ONE (FIELD_ONE CHAR(5));
SQL> ! Create a view based on TABLE_ONE.
SQL> CREATE VIEW VIEW_ONE (DBKEY, FIELD_ONE) AS
cont> SELECT DBKEY, FIELD_ONE FROM TABLE_ONE;
SQL> ! Create a second view based on VIEW_ONE, and reference the DBKEY column.
SQL> CREATE VIEW VIEW_TWO (DBKEY, FIELD_ONE) AS
cont> SELECT DBKEY, FIELD_ONE FROM VIEW_ONE;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-E-BAD_CODE, corruption in query string
The problem is fixed in Rdb/VMS V4.2.
1.1.44 List Records Should Match the Page Size When Stored on
WORM Optical Disk Devices
In V4.1, every list record designated for storage in a
write-once, read-many (WORM) optical disk device is stored
in a separate page. The intended use of the WORM optical
disk device is to store large objects such as image, audio,
large text, and so forth. Digital recommends that such
objects be split into segments of the same size as that
of a page, minus page and record overhead. In V4.1, using
a WORM optical disk device to store segments that were
small relative to the size of a page resulted in low space
utilization.
This problem is fixed in Rdb/VMS V4.2.
________________________ Note ________________________
Creating a segment larger than a page will degrade
performance.
______________________________________________________
1.1.45 Mapping Values for an INDEX Can Now Be Used in an RDO or
SQL Import Operation
Prior to V4.2, the MAPPING VALUES clause in an index
definition within an IMPORT statement generated an error
in RDO or SQL. For example:
Software Errors Fixed 1-33
SQL> IMPORT DATABASE
cont> FROM F
cont> FILENAME A>
cont> CREATE INDEX X ON R
cont> (F1 MAPPING VALUES 1.2 TO 2.2);
%SQL-F-NOMAPIMPO, Mapping Values on CREATE INDEX within an IMPORT
is not supported
This was because the limit literals could not be converted
until the table and column existed in the database.
This restriction is lifted in Rdb/VMS V4.2.
________________________ Note ________________________
This restriction remains for IMPORT with the PATHNAME
clause (SQL) or the DICTIONARY IS USED clause (RDO).
In these cases, the following error is reported by
CDD/Repository:
%CDD-E-MBLRSYNERR, syntax error in MBLR buffer at offset 0
This problem will be corrected in a future release
of CDD/Repository. In the meantime, do not perform
the import operation with a pathname, but perform
an integrate operation after the import operation is
complete.
______________________________________________________
1.1.46 Column RDB$FILE_NAME in Table RDB$DATABASE Returns Value
Prior to V4.2, a select of the field RDB$FILE_NAME returned
only spaces. Rdb/VMS V4.2 returns the file specification of
the current database root file.
________________________ Note ________________________
The root file specification is not actually stored on
disk (that is, RMU/DUMP/AREA will show that this field
is still blank), and is returned to queries only at
run time. This means that the root file specification
will still be correct even after using RMU/MOVE_AREA,
RMU/COPY_DATABASE, RMU/BACKUP, and EXPORT/IMPORT.
______________________________________________________
1-34 Software Errors Fixed
The following example shows the output from an SQL SELECT
statement that selects the field RDB$FILE_NAME:
SQL> ATTACH 'FILENAME DB$:MF_PERSONNEL';
SQL> SELECT RDB$FILE_NAME FROM RDB$DATABASE;
RDB$FILE_NAME
DISK4:[ELLINGSWORTH.DATABASES.APPL]MF_PERSONNEL.RDB;1
>>
>>
>>
1 row selected
This change allows an application to determine easily the
name of the database being accessed.
1.1.47 ALTER TABLE DROP CONSTRAINT Failed with VAX Data
Distributor Replication Transfer
Previous versions of Rdb/VMS returned an error when an
application attempted to drop a constraint in a database
on a table that was defined in a VAX Data Distributor
replication transfer, as in the following example:
SQL> ALTER TABLE R1 DROP CONSTRAINT R1_PRIMARY_F1;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-RELUSETRA, relation R1 is used in a transferred definition
-RDMS-F-RELNOTCHG, relation R1 has not been changed
This problem is fixed in Rdb/VMS V4.2.
1.1.48 Setting the Number of VAXcluster Nodes Did Not Work
Correctly in Previous Versions of Rdb/VMS
Prior to V4.2, setting the NUMBER OF VAXCLUSTER NODES
parameter during database creation or modification did
not work correctly.
In V4.2, Rdb/VMS prevents you from opening a database that
is already open on the maximum allowable number of nodes,
and issues the following error message:
%SQL-F-ERRATTDEC, Error attaching to database V42_TEST
-RDMS-F-EXNODECNT, database cannot be opened on this node, maximum node
count (1) exceeded
Rdb/VMS now recognizes this parameter as the maximum number
of nodes that a database can be open on.
Software Errors Fixed 1-35
1.1.49 RDB-E-UNRES_REL Error Could Be Returned After Performing
an ALTER STORAGE MAP
An RDB-E-UNRES_REL error was observed in Rdb/VMS V4.0 and
V4.1 under the following circumstances. A CREATE INDEX
statement was performed on a table explicitly reserved
exclusive write with a commit operation, followed by
an ALTER STORAGE MAP statement performed on the same
table explicitly reserved exclusive write as shown in the
following example:
SQL> DECLARE SCHEMA FILENAME MF_PERSONNEL;
SQL> SET TRANSACTION READ WRITE RESERVING CANDIDATES FOR EXCLUSIVE WRITE;
SQL> CREATE INDEX OST ON CANDIDATES (LAST_NAME) STORE IN RDB$SYSTEM;
SQL> COMMIT;
SQL> SET TRANSACTION READ WRITE RESERVING CANDIDATES FOR EXCLUSIVE WRITE;
SQL> ALTER STORAGE MAP CANDIDATES_MAP STORE IN EMPIDS_LOW;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDB-E-UNRES_REL, relation CANDIDATES in specified request is not a relation
reserved in specified transaction
SQL> ROLLBACK;
This problem is fixed in Rdb/VMS V4.2.
1.1.50 Performance Improvement for Storing Unique Sorted Indexes
Prior to V4.2, creation of indexes forced the logical area
nominal length stored in the AIP to be set to 215 rather
than the actual node size, which was usually a value larger
than 215. (The size 215 was chosen as an average for the
cases where the index allowed duplicates.) This sometimes
led to excessive page checking when creating index nodes
if the node size was large, because candidate pages were
always searched to determine if the pages had sufficient
space. This is because a value of 215 underestimated the
space available on data pages.
In Rdb/VMS V4.2, the creation of unique, sorted indexes
uses the node size specified by the user as the value
stored in the AIP entry. This improves performance because
pages are marked full sooner and, therefore, not checked.
Rdb/VMS searches only pages with sufficient space, as
determined by the AIP entry, for record storage.
1-36 Software Errors Fixed
Current exceptions to this are:
o If the NODE SIZE clause is not specified, the behavior
reported in Rdb/VMS V4.1 is in effect.
o Duplicate indexes retain the default behavior.
To view the record length of an index, enter the following:
$ RMU/DUMP/LAREA=RDB$AIP PERSONNEL
1.1.51 Clearer Error Message on CREATE/DEFINE STORAGE MAP
Prior to V4.2, Rdb/VMS sometimes issued the INDEXTS error
message when defining a storage map. For example:
RDO> DEFINE STORAGE MAP X FOR FOO
cont> STORE WITHIN EMPIDS_MID;
cont> END.
%RDO-F-INDEXTS, there is another index named, X, in this database
This message was confusing as it appeared that an attempt
to define an index was being executed by SQL or RDO.
Both CREATE/DEFINE INDEX statements and CREATE/DEFINE
STORAGE MAP statements can potentially create storage
map information from the STORE clauses available in the
two statements. In CREATE/DEFINE INDEX, the STORE clause
creates a special storage map with the same name as
the index. This error was reported when Rdb/VMS found a
conflict in the name of an existing index and a storage
map.
In Rdb/VMS V4.2 this message has been changed to provide
more information, as shown in the following example:
RDO> DEFINE STORAGE MAP X FOR FOO
cont> STORE WITHIN EMPIDS_MID;
cont> END.
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-MAPNMINUSE, map name X is already in use in this database
-RDMS-F-INDEXTS, there is already an index named X in this database
Software Errors Fixed 1-37
1.1.52 Clearer Error Message When Dropping Index Used by Storage
Map
Prior to V4.2, when you dropped an index that was
referenced by a PLACEMENT VIA INDEX clause, Rdb/VMS returns
an error; however, the error message did not inform you
which storage map referenced the index.
In Rdb/VMS V4.2, the INDINMAP message includes the name of
the storage map that references the index. For example:
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> DROP INDEX EMPLOYEES_HASH;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-INDINMAP, index EMPLOYEES_HASH is used in storage map EMPLOYEES_MAP
1.1.53 Many Attaches to and Detaches from the Same or Multiple
Databases While Using Search Lists to Point to the
Database Used Up I/O Channel Quota
Prior to VMS V5.4, continually attaching to or detaching
from the same database, or to or from multiple databases
that are referred to by logical names that contain search
lists, caused your process eventually to exceed its channel
quota, and a message such as %SYSTEM-E-NOIOCHAN to be
issued.
This problem occured frequently during use of RALLY
applications and search lists, because RALLY can attach
to or detach from a database quite frequently while the
application is running. This problem could also occur
elsewhere.
The problem occured because one of the logical names that
is used to point to the database is a search list. The
logical name is SPACE$DB, which is defined as:
"SPACE$DB" [exec] = "$1$DUA12:" (LNM$SYSTEM_TABLE)
= "$1$DUA5:"
If you remove this search list, you do not have the
problem.
This problem was fixed in VMS V5.4.
1-38 Software Errors Fixed
1.1.54 Enhanced Security Checking Implemented
As discussed in VAX Rdb/VMS New and Changed Features,
Version 4.2 implements an upgraded RMU security scheme.
An additional 14 access modes are enabled on the Rdb/VMS
root file ACL. Each access mode can be toggled to enable
certain RMU operations (or logical group of operations) for
specific users or groups of users. This new scheme removes
the need for VMS privileges and also removes the need
to attach to the database to check for internal database
privileges. It also provides the ability to audit all RMU
operations.
Starting with V4.2 RMU.EXE must always be installed with
privileges; however, RMU will always demote privileges
while carrying out file creations so that the executor's
privileges are used for file and directory access.
This enhanced security checking may cause privilege
violation problems in systems where unrestricted access
to restricted directories was previously allowed.
1.1.55 Sequential Retrieval No Longer Causes Problems with
Dynamic Optimizer
For Rdb/VMS V4.1, when the dynamic optimizer determined
that index retrieval was unproductive, it switched to
sequential retrieval. The switch to sequential retrieval
sometimes caused locking to be escalated from row level
to table level. Possible side effects of this switch were
reduced concurrency and increased risk of deadlocks.
The suggested workaround for Rdb/VMS V4.1 to achieve
optimal performance for your application was to modify
the buffer sizes.
This problem is fixed in Rdb/VMS V4.2. The dynamic
optimizer no longer switches to sequential retrieval.
1.2 SQL Software Errors Fixed in V4.2
This section describes problems fixed in the SQL interface
for V4.2.
Software Errors Fixed 1-39
1.2.1 Date/Time INTERVAL Arithmetic Returns Incorrect Results
In Rdb/VMS V4.1, multiplication and division of INTERVAL
data by scalar values returned incorrect results if the
scalar values were floating point or exact numeric values
with fractional portions. This was because Rdb/VMS rounded
the scalar value to a whole number before proceeding with
the operation.
This is corrected in Rdb/VMS V4.2. The arithmetic is now
performed using floating point arithmetic, if necessary,
thus preserving a higher accuracy. The following example
shows the correct results:
SQL> CREATE DOMAIN TIM INTERVAL HOUR TO SECOND;
SQL> CREATE DOMAIN NUM1 SMALLINT(2);
SQL> CREATE DOMAIN NUM2 SMALLINT(2);
SQL> CREATE TABLE TQAR (TIM TIM,NUM1 NUM1,NUM2 NUM2);
SQL> INSERT INTO TQAR (TIM,NUM1,NUM2) VALUES
cont> (INTERVAL '10:00:00.00' HOUR TO SECOND,10,2);
1 row inserted
SQL> INSERT INTO TQAR (TIM,NUM1,NUM2) VALUES
cont> (INTERVAL '10:00:00.00' HOUR TO SECOND,10,2.4);
1 row inserted
SQL> INSERT INTO TQAR (TIM,NUM1,NUM2) VALUES
cont> (INTERVAL '10:00:00.00' HOUR TO SECOND,10,2.5);
1 row inserted
SQL> INSERT INTO TQAR (TIM,NUM1,NUM2) VALUES
cont> (INTERVAL '10:00:00.00' HOUR TO SECOND,10,3);
1 row inserted
SQL>
SQL> SELECT *, TIM / CAST(NUM2 AS REAL), NUM1 / CAST(NUM2 AS REAL) FROM TQAR;
TIM NUM1 NUM2
10:00:00.00 10.00 2.00 05:00:00.00 5.0000000E+0
10:00:00.00 10.00 2.40 04:10:00.00 4.1666665E+0
10:00:00.00 10.00 2.50 04:00:00.00 4.0000000E+0
10:00:00.00 10.00 3.00 03:20:00.00 3.3333333E+0
4 rows selected
SQL> SELECT *, TIM * CAST(NUM2 AS REAL), NUM1 * CAST(NUM2 AS REAL) FROM TQAR;
TIM NUM1 NUM2
10:00:00.00 10.00 2.00 20:00:00.00 2.0000000E+0
10:00:00.00 10.00 2.40 24:00:00.00 2.4000000E+0
10:00:00.00 10.00 2.50 25:00:00.00 2.5000000E+0
10:00:00.00 10.00 3.00 30:00:00.00 3.0000000E+0
4 rows selected
1-40 Software Errors Fixed
1.2.2 SUBSTRING Built-in Function FOR Clause Restriction Lifted
The SUBSTRING builtin function has the following syntax:
SUBSTRING(char-value-expr FROM numeric-value-expr [ FOR numeric-value-expr ] )
Prior to V4.2, SUBSTRING returned erroneous results in some
cases if you used a complex value expression for the FOR
clause.
To avoid the problem, you had to omit the FOR clause, or
if this was not possible, restrict the FOR clause to simple
numeric literals, a host variable reference or a column
reference.
This problem is fixed in Rdb/VMS V4.2. Complex value
expressions can be used for all parts of the SUBSTRING
operation.
1.2.3 Metadata Corruption No Longer Results After Committing
Failed Metadata Changes for a DROP TABLE CASCADE
In certain previous versions of Rdb/VMS, committing a
failed SQL DROP TABLE (DROP TABLE CASCADE for V4.1)
statement could result in metadata corruption. This has
been observed under the following conditions:
o A table has associated views, constraints, indexes,
triggers, or storage maps.
o An SQL DROP TABLE (DROP TABLE CASCADE for V4.1) command
fails. An example of a failure is a lock conflict due to
another user accessing the table.
o A COMMIT statement is executed after the failure.
The following example shows the problem:
o Create the database.
$ SQL
SQL> CREATE DATABASE FILENAME LLAMA;
SQL> CREATE TABLE T1 (F1 CHAR(10));
SQL> CREATE VIEW V1 (F1) AS SELECT c1.F1 FROM T1 c1;
SQL> CREATE VIEW V2 (F1) AS SELECT c1.F1 FROM T1 c1;
SQL> COMMIT WORK;
SQL> EXIT;
Software Errors Fixed 1-41
o At terminal 1 do the following:
$ SQL
SQL> ATTACH 'FILENAME LLAMA';
SQL> SELECT COUNT(*) FROM T1;
o At terminal 2 drop the table with an implicit cascade
(in V4.0). The following errors are returned:
$ SQL
SQL> ATTACH 'FILENAME LLAMA';
SQL> SET TRANSACTION READ WRITE NOWAIT;
SQL> DROP TABLE T1;
%SQL-I-DEPIMPCAS, Implicit cascading may not be supported in a future version
View V1 is also being dropped.
View V2 is also being dropped.
%RDB-E-LOCK_CONFLICT, request failed due to locked resource; no-wait
parameter specified for transaction
-RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-LCKCNFLCT, lock conflict on client
SQL> COMMIT;
SQL> SELECT * FROM V1;
o A SELECT statement performed after a COMMIT statement
results in the following error:
%RDB-E-OBSOLETE_METADA, request references metadata objects that no
longer exist
-RDMS-F-BAD_SYM, unknown relation symbol - V1
o If you detach and reattach to the database and attempt
the same SELECT statement, the following error is
returned:
%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no
longer associated with a record
-RDMS-F-NODBK, 1:126:10 does not point to a data record
o Any further attempts to drop the table or access the
views will result in dbkey failures.
This problem results because the DROP TABLE (CASCADE)
statement removes information from the system tables
and their associated segmented strings about metadata
objects (views in the following example). If the DROP
TABLE statement fails, the changes to the system tables
are undone, but their associated lists remain deleted.
Performing a commit operation makes this change permanent.
1-42 Software Errors Fixed
The following workarounds to this problem are known:
o Always roll back failed metadata changes.
o Use RDO to delete metadata objects one-by-one and then
delete the table.
o Use a transaction mode of wait for metadata changes to
reduce the possibilty of lock conflict failures.
o Perform an RMU/BACKUP operation to back up your database
before making metadata changes.
o Use an exclusive transaction on the table to reduce the
possibility of lock conflict failures.
This was a known problem in V3.1, V3.1A, V3.1B, V3.1C,
V4.0, V4.0A, V4.0B, and V4.1. This problem is fixed in
Rdb/VMS V4.2.
1.2.4 CREATE TABLE Followed by SELECT Statement No Longer
Generates OBSOLETE_METADA Error
Prior to V4.2, a SQL CREATE TABLE statement containing a
COMPUTED BY definition that referenced the table being
created failed with an OBSOLETE_METADA error, as in the
following example:
SQL> CREATE TABLE FOO (A INTEGER, B INTEGER,
cont> C COMPUTED BY (SELECT SUM(F.A) FROM FOO F));
SQL> SHOW TABLE (COLUMN) FOO
Information for table FOO
Columns for table FOO:
Column Name Data Type Domain
----------- --------- ------
A INTEGER
B INTEGER
C BIGINT
Computed: by (SELECT SUM(F.A) FROM FOO F)
SQL> SELECT * FROM FOO;
%RDB-E-OBSOLETE_METADA, request references metadata objects that
no longer exist
-RDMS-F-BAD_SYM, unknown field symbol - C
Software Errors Fixed 1-43
The self-reference to the table caused the Rdb/VMS symbol
tables to be loaded before all the columns were defined.
Subsequent reference to those columns by SQL generated
Rdb/VMS errors about obsolete or undefined fields. A commit
operation would reload the table: adding a COMMIT statement
after the CREATE statement allowed these commands to work.
This problem is fixed in Rdb/VMS V4.2.
1.2.5 SET ALL CONSTRAINTS ON Statement Checks All Attached
Databases
The following problem affected both SQL Module Language and
Precompiled SQL for Rdb/VMS V4.1.
When you used a context variable or parameter for a
distributed transaction with multiple databases and
multiple transactions, the SQL SET ALL CONSTRAINTS
statement checked only the constraints in the first
database attached.
Consider the following example:
o You attach two databases
o A COMMIT TIME constraint is violated in the second
database attached
o A SET ALL CONSTRAINTS ON statement checks for constraint
violations
In this example, the SET ALL CONSTRAINTS statement would
succeed, even though the constraint was violated.
This problem is fixed in Rdb/VMS V4.2.
1.3 RMU Software Errors Fixed in V4.2
This section describes problems fixed in RMU for V4.2.
1.3.1 RMU/BACKUP/AFTER_JOURNAL Got Deadlock on Freeze if Another
DBR Process Ran At The Same Time
If a process died while the RMU/BACKUP/AFTER_JOURNAL
utility was trying to perform a critical operation on
the .AIJ file, such as truncating it, it is possible
for the AIJ backup utility to fail because of a deadlock
with the resulting DBR process on the freeze lock. This
problem occurred because the AIJ backup utility did not
1-44 Software Errors Fixed
make certain critical lock operations completable with
respect to the freeze lock protocol.
No database corruption or damage resulted from the abnormal
failure of the AIJ backup utility. However, it was possible
for the .AIJ file to become inaccessible as a direct result
of the failure; using the documented procedures for making
the .AIJ file accessible again solved this problem.
Furthermore, the backed-up .AIJ file is completely
usable for subsequent recovery purposes and should not
be discarded nor reused. The AIJ backup utility failure
occured while the utility was attempting to clean up and
shut down the backup operation; the actual backup operation
completed successfully.
There are no known workarounds. Using the /NOQUIET_POINT
command qualifier will not avoid the problem.
Note that this problem only occurred if a process was
abnormally terminated, so that the DBR (Database Recovery)
was invoked during an AIJ backup-critical section. This
problem will not occur if no processes are abnormally
terminated.
Furthermore, the problem was more likely to occur on
high-volume, update-intensive applications. If there is
no database update activity during the AIJ backup, this
problem will not occur.
This problem could also affect the database runtime system,
but only if the .AIJ extension database parameter value
was modified online (which occurs infrequently). It is
therefore recommended that the .AIJ extension database
parameter not be modified while the database is active.
For example:
$ RMU/BACKUP/AFTER/LOG PERSONNEL.RDB BACKUP.AIJ
%RMU-I-LOGCREBCK, created backup file DISK$:[DIRECTORY]BACKUP.AIJ;5
%RMU-I-LOGBCKAIJ, backing up AIJ file DISK$:[DIRECTORY]PERSONNEL.AIJ;2
%RMU-I-AIJBCKSEQ, backing up current AIJ file sequence number 4
%RMU-I-LOGAIJBCK, backed up 2 committed transactions at 16:02:09.67
%RMU-F-DEADLOCK, deadlock on freeze
Software Errors Fixed 1-45
The RMU/BACKUP/AFTER_JOURNAL utility now completes
certain critical lock operations outside the scope of
the freeze lock protocol. This means that critical AIJ
backup operations, such as the .AIJ file truncation, will
not be subject to the freeze, and consequently will not
encounter the possible deadlock on freeze problem. This
makes it possible for the AIJ backup utility to complete
its operations successfully, even if other processes are
recovered by DBR while the AIJ backup is being performed.
The database runtime software also completes critical
AIJ lock operations outside the scope of the freeze lock
protocol.
The problem stems from the fact that DBR acquires one or
more of the following locks after obtaining the freeze
lock: RTUPB, STAREA, SAC, LAREA, PLN, local AIJ, global
AIJ, AIJOPEN, RWROOT, TSNBLK, FILID and the KROOT.
Of these locks, the AIJ backup utility acquires the
following: global AIJ, RTUPB, TSNBLK and the KROOT. There
is a deadlock situation between the AIJ backup utility and
DBR with the global AIJ lock and the KROOT lock.
Of these locks, the runtime system acquires the following
locks: global AIJ and the KROOT. This also represents a
potential deadlock situation with DBR.
Consequently, the solution to this problem is the following
protocol: Once an .AIJ lock is acquired with the NOFREEZE_
FLG=TRUE, then all subsequent lock requests (including
those unknown to the AIJ code due to calling routines in
other modules) must also use the no-freeze protocol, until
the original AIJ lock is released.
This problem is fixed in Rdb/VMS V4.2.
1.3.2 Restriction Lifted on the Use of the /NOSPAMS Qualifier
Prior to V4.2, use of the /NOSPAMS qualifier (SPAMS
disabled feature) with the RMU/RESTORE or RMU/MOVE_AREA
command reserved space for SPAM pages; however, this
reserved space was not always initialized.
Some operations (such as RMU/BACKUP) examine every page of
the database. Uninitialized pages (which may contain any
bit pattern), will cause these operations to fail, because
they cannot interpret the contents of the page.
1-46 Software Errors Fixed
Digital recommends that the /NOSPAMS qualifier be used
only in conjunction with the WORM storage attribute (/WORM
qualifier) for write-once storage areas on WORM devices.
Therefore, do not disable SPAM pages in read/write storage
areas on read/write devices.
This restriction is lifted in Rdb/VMS V4.2.
1.3.3 .AIJ Files Are Now Validated When First Opened
Prior to V4.2, when an .AIJ file was opened, the open
record was not validated to ensure that the file really
contained AIJ information. In most cases, this was not a
serious problem because the database properly initialized
and carefully managed the AIJ file.
However, using RMU/ALTER, it was possible to activate an
.AIJ file that was not produced by the database system.
Also, with proper privileges, it was possible to manipulate
.AIJ files from DCL, so that an improper .AIJ file was
accessed by the database.
In Rdb/VMS V4.2, the .AIJ file is validated when it
is first opened, normally when the first read/write
transaction is started. If an improper .AIJ file is
detected, the start transaction operation fails with an
error indicating the reason.
1.3.4 Problem with Displaying RMU/SHOW STATISTICS Menus Fixed
In previous versions, if you generated the RMU/SHOW
STATISTICS menu using the "D" keystroke, some of the menu
options were not visible on 24-line terminal screens.
For V4.2, if you use a 24-line terminal screen, the
RMU/SHOW STATISTICS menus are divided into several columns,
so that all menu entries are always displayed. If you use
a terminal screen that contains enough lines to display
the menu items in a single-column list, RMU/SHOW STATISTICS
uses a single-column list for the menu.
Software Errors Fixed 1-47
1.3.5 RMU/SHOW STATISTICS Now Identifies Remote Processes
In V4.1, the RMU/SHOW STATISTICS Stall Messages screen did
not identify remote processes. In versions before 4.1, the
RMU/SHOW STATISTICS Stall Messages screen identified remote
processes by adding the suffix (r) to the process ID.
In Rdb/VMS V4.2, the RMU/SHOW STATISTICS Stall Messages
screen identifies remote processes by adding the suffix r
to the process ID. Note the absence of the parentheses.
1.3.6 Certain RMU Commands Can Now Be Performed on Closed
Databases
The following RMU commands can now be performed on a closed
database:
o RMU/ANALYZE
o RMU/ANALYZE/CARDINALITY
o RMU/ANALYZE/INDEXES
o RMU/ANALYZE/PLACEMENT
o RMU/LOAD
o RMU/UNLOAD
o RMU/SET AUDIT
o RMU/SHOW AUDIT
If any of these commands are issued for a closed database,
the command will execute without other users being able to
attach to the database. Previously these commands could be
performed only for an open database, which meant that other
users could attach to the database when the command was
executing.
1.3.7 RMU/EXTRACT Output for an SQL Constraint Check Clause in a
CREATE TABLE Statement for a Multischema Database Returned
a Syntax Error
In V4.1, the RMU/EXTRACT utility produced a constraint
check clause for the column using the table_name.column_
name format that worked for a non-multischema database.
However, for a multischema database using the catalog_
name.schema_name.table_name.column_name subordinate names,
the RMU/EXTRACT utility produced output that returned a
syntax error. The following example shows the problem:
1-48 Software Errors Fixed
SQL> CREATE TABLE HUMAN_RESOURCES.PERSONNEL.EMPLOYEES (
cont> ID HUMAN_RESOURCES.PERSONNEL.BADGE_NUMBER,
cont> DEPT_CODE HUMAN_RESOURCES.PERSONNEL.DEPT_CODE,
cont> FIRST_NAME HUMAN_RESOURCES.PERSONNEL.NAME,
cont> LAST_NAME HUMAN_RESOURCES.PERSONNEL.NAME,
cont> BIRTHDAY
cont> DATE VMS,
cont> ADDRESS_1 HUMAN_RESOURCES.PERSONNEL.ADDRESS_LINE,
cont> ADDRESS_2 HUMAN_RESOURCES.PERSONNEL.ADDRESS_LINE,
cont> CITY_NAME HUMAN_RESOURCES.PERSONNEL.NAME,
cont> POSTAL_CODE HUMAN_RESOURCES.PERSONNEL.PCODE,
cont> SEX
cont> CHAR (1)
cont> CHECK(((HUMAN_RESOURCES.PERSONNEL.EMPLOYEES.SEX = 'M')
cont> or (HUMAN_RESOURCES.PERSONNEL.EMPLOYEES.SEX = 'F')))
cont> CONSTRAINT HUMAN_RESOURCES.PERSONNEL.EMPLOYEES_CHECK1);
%SQL-F-CONVARUND, Column qualifier EMPLOYEES is not defined
A workaround is to edit the RMU/EXTRACT output for the
constraint check clause for a multischema database and
remove the catalog_name.schema_name.table_name subordinate
names and specify only the column_name subordinate name, as
follows:
SQL> CREATE TABLE HUMAN_RESOURCES.PERSONNEL.EMPLOYEES (
cont> ID HUMAN_RESOURCES.PERSONNEL.BADGE_NUMBER,
cont> DEPT_CODE HUMAN_RESOURCES.PERSONNEL.DEPT_CODE,
cont> FIRST_NAME HUMAN_RESOURCES.PERSONNEL.NAME,
cont> LAST_NAME HUMAN_RESOURCES.PERSONNEL.NAME,
cont> BIRTHDAY
cont> DATE VMS,
cont> ADDRESS_1 HUMAN_RESOURCES.PERSONNEL.ADDRESS_LINE,
cont> ADDRESS_2 HUMAN_RESOURCES.PERSONNEL.ADDRESS_LINE,
cont> CITY_NAME HUMAN_RESOURCES.PERSONNEL.NAME,
cont> POSTAL_CODE HUMAN_RESOURCES.PERSONNEL.PCODE,
cont> SEX
cont> CHAR (1)
cont> CHECK(((SEX = 'M')
cont> or (SEX = 'F')))
cont> CONSTRAINT HUMAN_RESOURCES.PERSONNEL.EMPLOYEES_CHECK1);
This problem is fixed in Rdb/VMS V4.2.
Software Errors Fixed 1-49
1.3.8 RMU/EXTRACT of RDO Trigger Fixed
In Rdb/VMS V4.1, the RMU/EXTRACT command did not correctly
extract a trigger definition when the definition was
written in RDO and contained more than one STORE clause
in a FOR loop. For example, the RMU/EXTRACT command did
not extract the second STORE statement in the following
trigger:
DEFINE TRIGGER AUDIT_SALARY_HISTRY
AFTER MODIFY OF SALARY_AMOUNT
OLD CONTEXT OLD
FOR NEW IN SALARY_HISTORY
WITH (OLD.SALARY_AMOUNT <> NEW.SALARY_AMOUNT)
EXECUTE
STORE AH IN AUDIT_HISTORY
USING AH.EMP_ID = OLD.EMPLOYEE_ID;
AH.STATUS = 'OLD';
AH.SALARY = OLD.SALARY_AMOUNT
END_STORE;
STORE AH IN AUDIT_HISTORY
USING AH.EMP_ID = OLD.EMPLOYEE_ID;
AH.STATUS = 'NEW';
AH.SALARY = NEW.SALARY_AMOUNT
END_STORE
FOR EACH RECORD.
This problem is fixed in Rdb/VMS V4.2. RMU/EXTRACT now
correctly extracts the definition, as the following example
shows:
DEFINE TRIGGER AUDIT_SALARY_HISTRY
AFTER MODIFY OF SALARY_AMOUNT
OLD CONTEXT C2
FOR C1 IN SALARY_HISTORY
WITH (C2.SALARY_AMOUNT <> C1.SALARY_AMOUNT)
EXECUTE
STORE C3 IN AUDIT_HISTORY
USING C3.EMP_ID = C2.EMPLOYEE_ID;
C3.STATUS = 'OLD';
C3.SALARY = C2.SALARY_AMOUNT
END_STORE;
1-50 Software Errors Fixed
STORE C4 IN AUDIT_HISTORY
USING C4.EMP_ID = C2.EMPLOYEE_ID;
C4.STATUS = 'NEW';
C4.SALARY = C1.SALARY_AMOUNT
END_STORE
FOR EACH RECORD.
1.3.9 RMU/EXTRACT Now Produces Correct Results for Views with
Subexpressions
In Rdb/VMS V4.1, RMU/EXTRACT did not produce a correct view
definition when the view contained a subexpression that was
a projection.
This is fixed in V4.2. The following view definition is now
extracted correctly:
CREATE VIEW TEST
(LAST_NAME)
AS SELECT C1.LAST_NAME
FROM EMPLOYEES C1
WHERE (C1.EMPLOYEE_ID = (select distinct C1.EMPLOYEE_ID
FROM EMPLOYEES C2
WHERE (C1.FIRST_NAME = 'JANE')));
The following example shows the incorrect definition as
extracted by Version 4.1:
CREATE VIEW TEST
(LAST_NAME)
AS SELECT
C1.LAST_NAME
FROM EMPLOYEES C1
WHERE (C1.EMPLOYEE_ID = (SELECT C1.EMPLOYEE_ID DISTINCT C1.EMPLOYEE_ID
FROM EMPLOYEES C2
WHERE (C1.FIRST_NAME = 'JANE')));
The following example shows that V4.2 extracts the
definition correctly:
Software Errors Fixed 1-51
create view TEST
(LAST_NAME)
AS SELECT
C1.LAST_NAME
FROM EMPLOYEES C1
WHERE (C1.EMPLOYEE_ID = (SELECT DISTINCT C1.EMPLOYEE_ID
FROM EMPLOYEES C2
WHERE (C1.FIRST_NAME = 'JANE')));
1.3.10 RMU/EXTRACT Now Recognizes the Keyword ALL in View
Definitions
In V4.1, RMU/EXTRACT did not recognize the keyword ALL
in view definitions. For example, the following view
definition generated an error:
CREATE VIEW APL_LIC_BUS_VIEW
(EMPLOYEE_ID)
AS SELECT C1.EMPLOYEE_ID
FROM EMPLOYEES C1
WHERE (((C1.FIRST_NAME IS NULL)
AND (C1.LAST_NAME = ANY (SELECT C2.LAST_NAME
FROM EMPLOYEES C2
WHERE (C1.EMPLOYEE_ID = C2.EMPLOYEE_ID))))
AND (C1.CITY <> ALL (SELECT C3.CITY
FROM EMPLOYEES C3
WHERE (C1.EMPLOYEE_ID = C3.EMPLOYEE_ID))));
%RMU-F-BLRINV, internal error - BLR string 66 for APL_LIC_BUS_VIEW. is invalid
-RDMS-E-BAD_CODE, corruption in the query string
This problem is fixed in Rdb/VMS V4.2. However, if you
use the /LANG=RDO qualifier, RMU/EXTRACT will return the
following error if the view definition contains the keyword
ALL:
%RMU-W-NORDOALL, the expression ALL cannot be represented using RDO
1.4 RMU Software Errors Fixed But Not Documented in V4.1
This section describes problems in RMU that were fixed but
not documented in RMU in V4.1.
1-52 Software Errors Fixed
1.4.1 RMU/COPY DATABASE Error Fixed
When RMU/COPY_DATABASE was performed online in a high
update environment it sometimes incorrectly determined
the TSN of the last committed transaction. This caused
the copied database root TSN to be lower than the TSN
associated with some committed data in the copied database,
and some TSN values were reused. If a transaction read the
data in the copied database before the root TSN advanced
beyond the TSN associated with the transaction that stored
the data in the original database, a bugcheck resulted.
This problem also affected databases restored from an
online backup.
This error was not documented in Rdb/VMS V4.1, but was
fixed in V4.1
1.5 RDO and RDBPRE Software Errors Fixed in V4.2
This section describes problems fixed in the RDO and RDBPRE
interfaces for Rdb/VMS V4.2.
1.5.1 RDBPRE Detects Illegal ERASE and MODIFY Usage With Cross
Clause
Prior to V4.2, RDBPRE did not generate any message if you
attempted to update a relation that was part of a join. For
example:
&rdb& for sh in salary_history cross
&rdb& e in employees
&rdb& with sh.employee_id = e.employee_id
&rdb& modify e using
&rdb& e.last_name = '?';
&rdb& end_modify
&rdb& end_for
Such constructs are illegal in Rdb/VMS because they can
lead to unpredictable results.
In V4.2, RDBPRE detects when an ERASE or MODIFY operation
is performed on a context used in a CROSS clause and
generates the following warning message:
%RDO-W-UPDATEJOIN, relation EMPLOYEES is part of join cannot be updated
Software Errors Fixed 1-53
1.5.2 RDO Concatenated Expressions in Nested FOR Loops Returned
Incorrect Results
Prior to V4.2, using nested FOR loops could cause
incorrect results. A problem occurs with relations where
a concatenated expression was executed on fields without
referencing any field from the innermost FOR loop. The
following example shows this problem:
RDO> FOR X IN TABLE1
cont> FOR Y IN TABLE2
cont> FOR Z IN TABLE3
cont> PRINT X.FIELD1|Y.FIELD2
cont> END_FOR
cont> END_FOR
cont> END_FOR
.....7777777
AAAAA7777777
The correct result should be:
AAAAA7777777
BBBBB7777777
This problem is fixed in Rdb/VMS V4.2.
1.5.3 RDO Concatenated Expressions Referencing Multiple Databases
Returned Incorrect Results
Another problem with concatenated expressions and nested
FOR loops affected attempts to reference multiple
databases. Concatenating fields from two different
databases could cause incorrect results in the concatenated
field, as shown in the following example:
1-54 Software Errors Fixed
RDO> DEFINE DATABASE LLAMA DICTIONARY IS NOT USED.
RDO> DEFINE FIELD F1 DATA SIGNED WORD.
RDO> DEFINE RELATION R1. F1. END.
RDO> STORE R IN R1 USING R.F1=1 END-STORE
RDO> STORE R IN R1 USING R.F1=2 END-STORE
RDO> COMMIT
RDO> FINISH
RDO> DATA DB1=FILE LLAMA
RDO> DATA DB2=FILE LLAMA
RDO> FOR A IN DB1.R1
cont> FOR B IN DB2.R1 WITH A.F1=B.F1
cont> PRINT A.F1|B.F1,A.F1,B.F1
cont> END_FOR
cont> END_FOR
F1 F1
01 1 1
F1 F1
12 2 2
The results in the first column should be 11 and 22.
This problem is fixed in Rdb/VMS V4.2.
1.5.4 STORE WITHIN and DISABLE/ENABLE COMPRESSION Clauses Cannot
Both Be Specified
Prior to V4.2, the STORE WITHIN and the DISABLE/ENABLE
COMPRESSION clauses could not both be specified in the
same CHANGE STORAGE MAP statement. A statement like the
following would fail:
RDO> CHANGE STORAGE MAP CANDIDATES_MAP
cont> STORE WITHIN EMPIDS_MID DISABLE COMPRESSION
cont> END.
This problem is fixed in Rdb/VMS V4.2.
1.6 RDML Software Errors Fixed in V4.2
This section describes problems fixed in RDML for Rdb/VMS
V4.2.
Software Errors Fixed 1-55
1.6.1 Problem Running RDML on a System with No Rdb/VMS License
Running RDML on a system with no Rdb/VMS license generated
the following error prior to V4.2:
$ RUN RDML41
%LICENSE-F-NOAUTH, DEC RDB-ELN use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager
This problem was fixed in Rdb/VMS V4.2. RDML now generates
the correct message and checks the correct license.
1.6.2 RDML No Longer Generates Incorrect RDML-E-READ_ONLY Error
When you use STORE and MODIFY statements, RDML attempts to
detect assignments into COMPUTED BY fields, which are read-
only. In previous releases, RDML incorrectly determined
that an assignment from a COMPUTED BY field to a read-write
was illegal.
RDML generated an incorrect %RDML-E-READ_ONLY error when
processing queries like the following:
FOR R1 IN REL1
FOR R2 IN REL2
MODIFY R2 USING
R2.F2 = R1.F1 (R1.F1 is a COMPUTED BY field)
END_MODIFY
END_FOR
END_FOR
FOR R1 IN REL1
STORE R2 in REL2 USING
R2.F2 = R1.F1 (R1.F1 is a COMPUTED BY field)
END_STORE
END_FOR
This problem is fixed in Rdb/VMS V4.2.
1.6.3 RDML No Longer Generates Incorrect RDML-W-JOIN_ATTRIBUTE
Error
In Rdb/VMS V4.1, RDML sometimes incorrectly determined that
a relation was part of a CROSS.
1-56 Software Errors Fixed
RDML issues an error when an ERASE or MODIFY statement
operates on a context used in a CROSS clause. This
construct is illegal in Rdb/VMS because it can lead to
unpredictable results. For example:
FOR E IN APPL$HANDLE.EMPLOYEES WITH E.EMPLOYEE_ID = CUR_ID_CODE
FOR E0 IN APPL$HANDLE.EMPLOYEES WITH E0.RDB$DB_KEY = E.RDB$DB_KEY
MODIFY E0 USING
ON ERROR
$PUTMSG (RDB$MSG_VECTOR);
END_ERROR
E0.EMPLOYEE_ID := NEW_ID_CODE;
END_MODIFY;
REC_MODIFIED := TRUE;
END_FOR;
END_FOR;
Preprocessing this code produces the following error:
%RDML-W-JOIN_ATTRIBUTE, Relation 'EMPLOYEES' is part of a join
cannot be updated
%RDML-I-ATLINE, at line 36 in
the file DISK02:[ELLINGSWORTH.RDB]TEST.RPA
This problem is fixed in Rdb/VMS V4.2. In addition, RDML
detects additional illegal cases of ERASE and MODIFY usage.
1.7 SQL/Services Errors Fixed in V4.2
This section describes problems fixed in SQL/Services for
Rdb/VMS V4.2.
1.7.1 Undeleted Mailbox Channels Can Cause Server Failure
In Rdb/VMS Version 4.1, the communications server did not
delete mailbox channels. Under some circumstances this
problem can cause the server to fail. This problem was not
present in releases prior to V4.1.
The following factors affect whether or not a given
configuration experiences this problem:
o Insufficient system resources
o Low idle timer setting
o High number of execute server processes created
Software Errors Fixed 1-57
o System up for a longer than average time (Life of the
system)
This problem is fixed in Rdb/VMS V4.2. The modification
is in the communications server and requires no changes to
clients or applications.
1.7.2 SQL/Services Support for MS-DOS Windows TCP/IP
Support for TCP/IP (Transmission Control Protocol/Internet
Protocol) in SQL/Services was introduced with V4.1 for
some client API platforms. Due to problems with the
communications code, MS-DOS Windows TCP/IP was specifically
excluded in V4.1 from the documentation.
For V4.2, Windows TCP/IP support is available. Sites using
MS-DOS Windows can select either DECnet or TCP/IP for:
o SQL/Services client API install steps
o Application development
The SQL/Services sample program SQSDYNW.EXE prompts at run
time for the specification of a transport mechanism and
accepts either DECnet or TCP/IP.
The SQL/Services IVP program SQSIVPW.EXE does not yet
accept a transport specification. DECnet is required.
________________________ Note ________________________
PATHWORKS for DOS (TCP/IP) V2.0 software is a
requirement for SQL/Services MS-DOS Windows
applications using TCP/IP.
Efforts to use earlier versions of TCP/IP will yield
the Windows message "Unrecoverable Application Error."
This message is returned for many Windows errors.
One way to check your TCP/IP version is to check the
creation dates on TCP/IP libraries WSOCKETS.DLL and
WSOCKETS.LIB. Files created before 09-30-91 do not
meet the requirement.
______________________________________________________
1-58 Software Errors Fixed
2
_________________________________________________________________
Known Problems, Restrictions, and Other Notes
This chapter describes problems and restrictions
relating to Rdb/VMS V4.2, and includes workarounds where
appropriate. It also contains other information, such
as documentation errors and omissions and restrictions
retained from V4.1, V4.0, and V3.1, that are not discussed
in Chapter 1.
The notes in this chapter may use different database terms
to mean the same thing. For example, some terms used by SQL
differ from terms used by other interfaces, such as RDO or
RDML. Table 1 in the VAX Rdb/VMS New and Changed Features
shows some of the different terms used.
2.1 Known Problems and Restrictions in All Interfaces for V4.2
This section describes known problems and restrictions for
all interfaces effective with V4.2.
2.1.1 Interaction of CDD/Repository and RMU Privileges Access
Control Lists
Prior to V4.2, you needed to have either VMS privileges
or database level access controls defined within the
database. For some database users, it was inconvenient
or impossible to use VMS system privileges (for example,
against company security policy). In other cases, the
database was not available to access the database access
controls (for example, you couldn't use the RMU/CLOSE
command on a corrupt database), or access to the RMU
operations and database operations needed to be kept
distinct and separate.
Rdb/VMS V4.2 introduces a new mechanism for managing the
granting of access to RMU utility functions. Rdb/VMS now
uses the unused portion of the VMS access control list
(ACL) to provide special RMU privileges. Only the .RDB or
root file can have these privileges added. Two new tools,
Known Problems, Restrictions, and Other Notes 2-1
RMU/SET PRIVILEGE and RMU/SHOW PRIVILEGE, can be used to
set and show the RMU privileges.
The DCL SHOW ACL and DIRECTORY/ACL commands also show
the added access control information; however these tools
cannot translate the names defined by Rdb/VMS. For example,
compare the output from the following three commands:
Output from the DCL DIRECTORY command:
$ DIRECTORY/ACL/SIZE/DATE MF_PERSONNEL.RDB
Directory DISK1:[PROJECT.DATABASES]
MF_PERSONNEL.RDB;1 99 29-JUL-1992 13:22:19.79
(IDENTIFIER=[ACCT,SMITH],ACCESS=READ+WRITE+CONTROL+BIT_5+BIT_6+BIT_7+
BIT_8+BIT_9+BIT_10+BIT_11+BIT_12+BIT_13+BIT_14+BIT_15+BIT_16+BIT_17+
BIT_18)
Total of 1 file, 99 blocks.
Output from the DCL SHOW ACL command:
$ SHOW ACL MF_PERSONNEL.RDB
Object type: file, Object name: DISK1:[PROJECT.DATABASES]MF_PERSONNEL.RDB;1,
on 9-OCT-1992 15:59:58.39
(IDENTIFIER=[ACCT,SMITH],ACCESS=READ+WRITE+CONTROL+BIT_5+BIT_6+BIT_7+
BIT_8+BIT_9+BIT_10+BIT_11+BIT_12+BIT_13+BIT_14+BIT_15+BIT_16+BIT_17+
BIT_18)
Output from the RMU/SHOW PRIVILEGE command (shows expanded
privilege names):
$ RMU/SHOW PRIV DB$:MF_PERSONNEL.RDB
Object type: file, Object name: DISK1:[PROJECT.DATABASES]MF_PERSONNEL.RDB;1,
on 9-OCT-1992 15:59:44.22
(IDENTIFIER=[ACCT,SMITH],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
This change is designed to make it easier for you to use
RMU and manage its functions.
________________________ Note ________________________
The RMU/CONVERT command propagates the database
internal ACL to the root file for access control
2-2 Known Problems, Restrictions, and Other Notes
entries that possess the SECURITY, and DBADM
(ADMINISTRATOR) privileges.
______________________________________________________
2.1.1.1 CDD/Repository Default Access Control
CDD/Repository protects its repository (or dictionary)
by placing the CDD$SYSTEM rights identifier on each
file created within the anchor directory. CDD$SYSTEM
is a specially reserved rights identifier created by
CDD/Repository.
When CDD/Repository executes the DEFINE REPOSITORY
command, it adds (or augments) a VMS default ACL to the
anchor directory. Typically this ACL allows access to
the repository files for CDD$SYSTEM and denies access to
everyone else. All files created in the anchor directory
inherit this default ACL, including the repository
database.
2.1.1.2 Problems Involving ACLs
Unfortunately, there is an interaction between the default
ACL added by CDD/Repository that will be placed on the
repository database and the RMU privileges ACL processing.
Within the ACL on the repository database, the default
access control entries (ACEs) that were inherited from
the anchor directory will precede the ACEs added by
RMU/RESTORE. As a result, the CDD$SYSTEM identifier will
not have any RMU privileges granted to it.
Without these privileges, if the user does not have the VMS
SYSPRV privilege enabled, RMU operations such as CONVERT
and RESTORE will not be allowed on the repository database.
The following problems may be observed by users that do not
have the SYSPRV privilege enabled:
o While executing a CDO DEFINE REPOSITORY or DEFINE
DICTIONARY command:
- If the CDD$TEMPLATEDB backup (.RBF) was created
by a previous version of Rdb/VMS, the automatic
RMU/CONVERT that will be carried out on the RBF file
will fail because SYSPRV is required.
Known Problems, Restrictions, and Other Notes 2-3
- If the CDD$TEMPLATEDB backup (.RBF) was created by
the current version of Rdb/VMS, the restore of the
repository database will fail because the default
ACEs that already existed on the repository file
that was backed up will take precedence, preventing
RMU$CONVERT and RMU$RESTORE privileges being granted
to CDD$SYSTEM or the user.
- If no CDD$TEMPLATEDB is available, the repository
database will be created without a template,
inheriting the default ACL from the parent directory.
The ACE containing all the required RMU privileges
will be added to the end of the ACL; however, the
pre-existing default ACEs will prevent any RMU
privilege from being granted.
o As in previous versions of Rdb/VMS, you must use the
RMU/CONVERT command to upgrade the database disk format
to Rdb/VMS Version 4.2 after installing V4.2. This
operation requires the SYSPRV privilege.
During the conversion, RMU/CONVERT adds the ACE
containing the RMU privileges at the end of the
ACL. Because the repository database already has the
default CDD/Repository ACL associated with it, the
CDD/Repository ACL will take precedence, preventing
the granting of the RMU privileges.
o During a CDO MOVE REPOSITORY command, the RMU privilege
checking may prevent the copy as the RMU$COPY privilege
has not been granted on the repository database.
o When you execute the CDD template builder CDD_BUILD_
TEMPLATE, the step involving RMU/BACKUP may fail because
RMU$BACKUP privilege has not been granted.
A version of the CDD/Repository software that corrects
this problem and allows new repositories to be created
using Rdb/VMS V4.2 is provided on the Rdb/VMS V4.2 kit. See
Section 2.1.1.4 for details.
Rdb/VMS V4.2 provides RDBVMS_CONVERT_CDD$DATABASE.COM,
a command procedure that both corrects the anchor directory
ACL and performs the RMU/CONVERT operation.
2-4 Known Problems, Restrictions, and Other Notes
________________________ Note ________________________
You must have SYSPRV enabled before you execute
RDBVMS_CONVERT_CDD$DATABASE.COM because an RMU/CONVERT
operation will be performed.
______________________________________________________
2.1.1.3 CDD Conversion Procedure
Use the
procedure SYS$LIBRARY:RDBVMS_CONVERT_CDD$DATABASE.COM to
process the anchor directory and update the ACLs for both
the directory and, if available, the repository database.
This procedure accepts one parameter: the name of the
anchor directory that contains, or will contain, the
repository files.
For example:
$ @SYS$LIBRARY:RDBVMS_CONVERT_CDD$DATABASE [PROJECT.CDD_REP]
If many repositories exist on a system, you may wish to
create a DCL command procedure to locate them, set the RMU
privileges ACL, and convert the databases. Use DCL commands
similar to the following:
$ LOOP:
$ REP_SPEC = F$SEARCH("[000000...]CDD$DATABASE.RDB")
$ IF REP_SPEC .NES. ""
$ THEN
$ @SYS$LIBRARY:RDBVMS_CONVERT_CDD$DATABASE -
'F$PARSE(REP_SPEC,,,"DIRECTORY")'
$ GOTO LOOP
$ ENDIF
2.1.1.4 Installing the Corrected CDDSHR Images
________________________ Note ________________________
The following procedure must be carried out if you
have installed or plan to install Rdb/VMS Rdb V4.2 and
have already installed CDD/Plus V4.3, CDD/Repository
V5.0, CDD/Repository V5.1, or DECdesign on your
system.
Known Problems, Restrictions, and Other Notes 2-5
When you install DECdesign, CDD/Repository performs an
RMU/RESTORE command with CDD$SYSTEM rights enabled to
create a DECdesign library.
______________________________________________________
Due to the enhanced security checking associated with
RMU commands in Rdb/VMS V4.2, existing CDDSHR images for
CDD/Plus V4.3 and CDD/Repository V5.0 and V5.1 must be
upgraded to ensure that the correct RMU privileges are
applied to newly created or copied repository databases.
Included in the distribution kit containing the Rdb/VMS
V4.2 kits is a CDD upgraded image kit, called CDDRDB042,
that must be installed after you have installed the Rdb/VMS
V4.2 kit.
This upgrade kit should be installed using VMSINSTAL. It
automatically checks which version of CDDSHR you have
installed and replaces the existing CDDSHR.EXE with the
corrected image file. The existing CDDSHR.EXE will be
renamed SYS$LIBRARY:OLD_CDDSHR.EXE.
The upgrade installation will also place a new CDD_
BUILD_TEMPLATE.COM procedure in SYS$LIBRARY for use with
CDD/Repository V5.0 or V5.1.
The following is a excerpt from an sample installation of
the CDD upgraded image kit:
$ @SYS$UPDATE:VMSINSTAL cddrdb042 kitdev:[kits]
VAX/VMS Software Product Installation Procedure V5.5-1
It is 21-OCT-1992 at 11:17.
Enter a question mark (?) at any time for help.
%VMSINSTAL-W-ACTIVE, The following processes are still active:
_FTA22:
* Do you want to continue anyway [NO]? y
* Are you satisfied with the backup of your system disk [YES]?
The following products will be processed:
CDDRDB V4.2
Beginning installation of CDDRDB V4.2 at 14:41
2-6 Known Problems, Restrictions, and Other Notes
%VMSINSTAL-I-RESTORE, Restoring product save set A ...
Installing patched version of CDD V5.0-7...
* Do you want to purge files replaced by this installation [YES]?
%VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories...
*************************************************************
The CDD patch has been successfully installed.
The old CDDSHR image has been renamed and may be deleted.
It is located in SYS$LIBRARY:OLD_CDDSHR.EXE
Please convert all of your CDD dictionaries using
@SYS$LIBRARY:RDBVMS_CONVERT_CDD$DATABASE <anchor-directory>
*************************************************************
Installation of CDDRDB V4.2 completed at 14:43
VMSINSTAL procedure done at 14:43
________________________ Note ________________________
If you upgrade your repository to CDD/Repository
V5.0 or V5.1 after you install Rdb/VMS V4.2, you
must install the corrected CDDSHR image again to
ensure that the correct CDDSHR images have been made
available.
The CDD/Repository upgrade kit determines which
version of CDD/Repository (or CDD/Plus) is installed
and replaces the existing CDDSHR.EXE with the
appropriate version of the corrected image.
______________________________________________________
2.1.2 Layered Products May Alter Database Root Access Privileges
A layered product may manipulate VMS directory or file
ACLs. This can result in the unintentional alteration of an
RMU access right.
For example, CDD/Repository may use the following ACE:
(IDENTIFER=[*,*],OPTIONS=DEFAULT+PROPAGATE,ACCESS=NONE)
If this ACE is propagated to an Rdb/VMS database such as
CDD$DATABASE or CDD$TEMPLATE, VMS privilege may be required
to manage that database.
Known Problems, Restrictions, and Other Notes 2-7
You can use the RMU/SET PRIVILEGE or RMU/SET PRIVILEGE/EDIT
command to change the ACL on any affected database.
2.1.3 Real Number Value Returned Incorrectly During Index-Only
Retrieval on Descending Index
Rdb/VMS returns incorrect values from real (floating point)
fields that are retrieved during index-only retrieval from
a descending index.
For example:
SQL> CREATE TABLE TABLE_1 (COL_1 Char(8), COL_2 REAL);
SQL> INSERT INTO TABLE_1 VALUES ('Test1',0);
1 row inserted
SQL> SELECT * FROM TABLE_1;
COL_1 COL_2
Test1 0.0000000E+00
1 row selected
SQL> CREATE INDEX INDEX_1 ON TABLE_1 (COL_2 DESCENDING);
SQL> SELECT COL_2 FROM TABLE_1;
COL_2
1.7014117E+38
1 row selected
This problem only occurs if index-only retrieval is chosen
on a descending index. Alteration of the query by selecting
a field that does not take part in the descending index
will force Rdb/VMS to either use another index or retrieve
the actual data record, thus returning the correct value,
as follows:
SQL> SELECT COL_1, COL_2 FROM TABLE_1;
COL_1 COL_2
Test1 0.0000000E+00
1 row selected
This problem will be fixed in a future release of Rdb/VMS.
2.1.4 UPDATE Privilege Checked Unnecessarily
A problem in Rdb/VMS causes the UPDATE (RDO MODIFY)
privilege to be checked unnecessarily for tables that
were only used within the SELECT assigment clause of the
UPDATE statement. This is incorrect behavior, because
SELECT privilege should be sufficient for access to these
tables.
2-8 Known Problems, Restrictions, and Other Notes
The following example illustrates the problem:
SQL> SHOW PROTECTION ON TABLE P.TABLEA;
Protection on Table P.TABLEA
(IDENTIFIER=[*,*],ACCESS=SELECT+UPDATE)
SQL> SHOW PROTECTION ON TABLE P.TABLEB;
Protection on Table P.TABLEB
(IDENTIFIER=[*,*],ACCESS=SELECT)
! This update to TABLEA should succeed, but fails because Rdb/VMS is
! also checking for UPDATE privilege for TABLEB.
SQL> UPDATE P.TABLEA A
cont> SET A.FLDA2 = A.FLDA2 * (SELECT B.FLDB2 FROM P.TABLEB B
cont> WHERE B.FLDB1 = A.FLDA1);
%RDB-E-NO_PRIV, no privilege for attempted operation
This problem will be corrected in a future release of
Rdb/VMS.
2.1.5 Access Violation at RDMS$$PRE_EXECUTION + 58 Results From
Attempts to Access Certain Views
You may receive an ACCVIO at RDMS$$PRE_EXECUTION + 58
exception when accesssing views under the following
circumstances:
o The database was created with Rdb/VMS V4.0 or older,
and,
o The database was converted to Rdb/VMS V4.1 or later,
and,
o The views contain subqueries.
Prior to Rdb/VMS V4.1, the rdb$dbkey_length field in the
rdb$relations system table could have been incorrect for
some views. This incorrect length is carried over on an
RMU/CONVERT. Rdb/VMS V4.1 and later versions can bugcheck
at the above exception if the rdb$dbkey_length field is
incorrect.
You can avoid the problem by redefining the views under
Rdb/VMS V4.1 or later.
Known Problems, Restrictions, and Other Notes 2-9
2.1.6 Bugcheck in RDMS$$COMPILE_INDEX_MAPS + 413 With Sorted
Partitioned Indexes
A bugcheck may occur at RDMS$$COMPILE_INDEX_MAPS + 413 when
all of the following apply:
o The query selects data from a table that has a sorted
partitioned index.
o The index is multisegmented, and partitioned using more
than one segment.
o The query contains a "=" or ">" or ">=", STARTING WITH,
IS NULL, or BETWEEN predicate on first segment.
o The optimizer chooses the partitioned index to access
data from the table.
A query for which all of the above is true, but that
compiles without a bugcheck, will execute correctly.
To eliminate the bugcheck, drop the partitioned index and
create a new index with partitioning based on no more than
one segment.
This problem will be corrected in a future release of
Rdb/VMS.
2.1.7 Timeout on Lock Conflict in Metadata May Cause Bugcheck
While Rdb/VMS is accessing metadata records within a
database that has a lock timeout interval set, a lock
conflict may cause a bugcheck to occur.
For example, a lock conflict on metadata may occur if,
during metadata updates such as building an index or adding
a column to a table, a second process tries to compile a
query against the changing index or table. If the database
does not have lock timeouts enabled, then the second
process would wait until the metadata updates are complete;
however, if a lock timeout interval has been specified for
the database, then if the second process does not obtain
its required lock by the end of the timeout interval, an
exception is raised.
You may see this problem during the handling of this
lock timeout exception. The following example shows the
exceptions you may see within this type of bugcheck:
2-10 Known Problems, Restrictions, and Other Notes
***** Exception at 002A15D9 : LCKCCH$COMMIT_SUBTREE + 00000030
%SYSTEM-F-ACCVIO, access violation, reason mask=00, . . .
14 more lines...
***** Exception at 0029FA6F : LCK$HANDLE_TIMEOUT + 0000006D
%RDMS-F-TIMEOUT, timeout on record aa:pp:ll
-SYSTEM-F-ABORT, abort
To avoid this problem, do metadata updates off line, or
change the lock timeout interval to a large number so
that the locks have long waits during metadata updates,
as follows:
SQL> ALTER DATABASE FILE DB lock timeout interval 9999999;
SQL> ATTACH 'FILENAME DB';
SQL>... <do the metadata changes >
SQL> COMMIT;
SQL> DISCONNECT ALL;
SQL> ALTER DATABASE FILE DB lock timeout interval <orginal value>;
This problem is due to an erroneous interaction of
exception handlers within Rdb/VMS that will be corrected
in a future release of the product.
2.1.8 Problem Creating Descending Partitioned Sorted Index
In Rdb/VMS versions beginning with 4.0, some users could
not create or import a descending partitioned sorted
index on a table with existing records. The CREATE INDEX
statement puts all of the index records into the last
partition. Rdb/VMS does not return an error until a user
attempts delete or modify operations (where the key value
changes).
Records inserted after the index is created go into the
correct partitions.
The CREATE INDEX statement in the following example
illustrates the problem:
Known Problems, Restrictions, and Other Notes 2-11
SQL> CREATE DATABASE FILENAME LLAMAS
cont> CREATE STORAGE AREA AR1 FILENAME AR1 ALLOCATION IS 20 PAGES
cont> CREATE STORAGE AREA AR2 FILENAME AR2 ALLOCATION IS 20 PAGES
cont> CREATE STORAGE AREA AR3 FILENAME AR3 ALLOCATION IS 20 PAGES
cont> CREATE TABLE LLAMAS (F1 CHAR(4), F2 CHAR(2), F3 CHAR(4), F4 SMALLINT,
cont> F5 CHAR(4), F6 CHAR(4), F7 SMALLINT, F8 CHAR(6), F9 SMALLINT);
SQL>INSERT INTO LLAMAS VALUES ('MSGL',' ',' ',1,'1000','SSTR',8,'000006',0);
SQL>INSERT INTO LLAMAS VALUES ('DEC ',' ',' ',1,'01 ','INV1',1,'000002',0);
SQL>COMMIT;
SQL> CREATE UNIQUE INDEX I1 ON LLAMAS
cont> (F1 DESC,F2 DESC,F3 DESC,F4 DESC, F5 DESC, F6 DESC,F7 DESC,F8 DESC, F9 DESC)
cont> STORE USING (F1) IN AR1 WITH LIMIt OF ('ASOC') IN AR2 WITH LIMIT OF (DEC')
cont> IN AR3 WITH LIMIT OF ('FS') OTHERWISE IN RDB$SYSTEM;
SQL> COMMIT;
SQL> UPDATE LLAMAS SET F2='99',F9=99 WHERE F1='DEC' AND F2=' ' AND F7=1 AND
cont>F8='000002';
SQL> ROLLBACK;
SQL> EXIT;
________________________ Note ________________________
All workarounds for this problem have a major
drawback: you must load records after the index is
created. This can be done initially, but maintenance
becomes a problem because you must unload all of the
records, create the index, then reload the records.
______________________________________________________
This problem will addressed in a future version of Rdb/VMS.
2.1.9 Restrictions on SQL ALTER STORAGE MAP Statement
In versions prior to and including V4.2, two restrictions
affect the SQL ALTER STORAGE MAP statement:
o The DROP COLUMN clause of the SQL ALTER TABLE statement
does not delete the list data associated with the
dropped column. A subsequent ALTER STORAGE MAP statement
fails because the list area is not empty, as shown in
the following example:
2-12 Known Problems, Restrictions, and Other Notes
SQL> ALTER TABLE RESUMES DROP COLUMN RESUME;
SQL> ALTER STORAGE MAP LISTS_MAP STORE LISTS IN RDB$SYSTEM;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-E-SSAREANOTEMPTY, segmented string area RESUME_LISTS is not empty, it may
not be deleted
To avoid this problem, you must explicitly delete the
lists and then perform the ALTER TABLE statement, as
follows:
SQL> UPDATE RESUMES
cont> SET RESUME = NULL;
3 rows updated
SQL> ALTER TABLE RESUMES DROP COLUMN RESUME;
SQL> COMMIT;
SQL> ALTER STORAGE MAP LISTS_MAP STORE LISTS IN RDB$SYSTEM;
SQL> COMMIT;
o The SQL DROP TABLE statement does not immediately delete
the list data associated with the dropped table. For
example:
SQL> DROP TABLE RESUMES;
SQL> ALTER STORAGE MAP LISTS_MAP STORE LISTS IN RDB$SYSTEM;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-E-SSAREANOTEMPTY, segmented string area RESUME_LISTS is not empty, it may
not be deleted
The DROP TABLE code does perform the deletion of the
lists. However, list delete is performed by saving
the segmented-string-id in a cache and executing the
delete at commit time. This process allows deleted
lists to be recycled by subsequent INSERT or UPDATE
statements within the same transaction. This reduces
area extensions when large lists are modified and
replaced with new data because the old space is reused
for the new list.
Therefore, when the ALTER STORAGE MAP action tests the
existence of data in the storage area, it does find that
the lists still exist. To avoid this problem, issue a
COMMIT statement after the DROP TABLE statement and
before the ALTER STORAGE MAP statement. For example:
Known Problems, Restrictions, and Other Notes 2-13
SQL> DROP TABLE RESUMES;
SQL> COMMIT;
SQL> ALTER STORAGE MAP LISTS_MAP STORE LISTS IN RDB$SYSTEM;
SQL> COMMIT;
These problems will be corrected in a future release of
Rdb/VMS.
2.1.10 Timer Problem with C Functions
C programs using the signal() and alarm() functions
while executing Rdb queries could fail with various error
messages. The nature of the error messages depends on
whether the SQL or RDML interface is used and on the moment
when the signal is generated.
The C alarm function apparently generates an AST and an
ASTFLT exception signal. For example, the SQL exception
handlers are not set up to handle this exception if it is
delivered while they are on the call frame. They get the
signal and unwind the stack, which causes unpredictable
results in the original program. If the exception is
delivered while only the user program's alarm handler is
active, then everything works fine. However, it is more
likely that the exception will be delivered while the
program is accessing the SQL or RDML code, which always
has a runtime handler enabled.
The following SQL program uses a SIGALRM handling routine
to catch a timer interrupt at regular intervals:
#include stdio
#include signal
#define SQL_SUCCESS 0
#define STREAM_EOF 100
int alarm_counter = 0;
char timer_interval_s[32];
int timer_interval;
char employee_id[6];
char last_name[15];
char first_name[11];
EXEC SQL INCLUDE SQLCA;
EXEC SQL DECLARE SCHEMA FILENAME 'PERSONNEL';
2-14 Known Problems, Restrictions, and Other Notes
EXEC SQL DECLARE REPORT_CURSOR CURSOR FOR
SELECT EMPLOYEE_ID, LAST_NAME, FIRST_NAME
FROM EMPLOYEES;
EXEC SQL WHENEVER SQLERROR GOTO error_handler;
sigalarm_handler()
{
alarm_counter++;
signal (SIGALRM,sigalarm_handler);
alarm (timer_interval);
}
main (int argc, char *argv[])
{
signal (SIGALRM,sigalarm_handler);
if (argc > 1)
{
timer_interval = atoi (argv[1]);
}
else
{
printf ("Timer interval ?\n");
gets (timer_interval_s);
timer_interval = atoi (timer_interval_s);
}
if (timer_interval > 0)
alarm (timer_interval);
printf ("Connecting to database ... \n");
EXEC SQL SET TRANSACTION READ ONLY;
printf ("Opening Cursor ...\n");
EXEC SQL OPEN REPORT_CURSOR;
Known Problems, Restrictions, and Other Notes 2-15
printf ("Fetching rows ...\n");
do
{
EXEC SQL FETCH REPORT_CURSOR INTO
:employee_id, :last_name, :first_name;
if (SQLCA.SQLCODE == SQL_SUCCESS)
printf ( "%2.2d - %5s %15s %12s\n",
alarm_counter, employee_id, last_name, first_name);
}
while (SQLCA.SQLCODE == SQL_SUCCESS);
EXEC SQL CLOSE REPORT_CURSOR;
EXEC SQL COMMIT;
exit();
error_handler:
printf("\nAn unexpected error was encountered %d", SQLCA.SQLCODE);
SQL$SIGNAL();
}
All the program's signal handler does is to increment a
counter and re-arm the timer interrupt. Depending on the
time delay between timer interrupts, various failures will
occur.
A workaround for this problem is to replace the alarm and
signal functions with a call to SYS$SETIMR. This will work
as desired, because SETIMR generates only the AST, not the
ASTFLT exception.
2.1.11 Use of RDMS$BIND_SEGMENTED_STRING_COUNT May Cause Virtual
Memory Leakage
The logical name RDMS$BIND_SEGMENTED_STRING_COUNT is used
to presize a data structure used with Rdb/VMS. A problem
has been found when this logical is used with multiple
database attaches. Each additional attach causes virtual
memory to be allocated unnecessarily. This extra virtual
memory is not released until image rundown.
Digital suggests that this logical name not be used if
more than one database attach is performed per session.
Alternatively, because this logical name is usually
associated with importing large databases with many
segmented strings, make sure you exit the SQL or RDO
interactive utilities between IMPORT and ATTACH (INVOKE)
statements.
2-16 Known Problems, Restrictions, and Other Notes
This problem will be corrected in a future release of
Rdb/VMS.
2.1.12 Read-Only Transactions Are Always ISOLATION LEVEL
SERIALIZABLE
Read-only transactions use a snapshot of the database. For
this reason, they are immune to interference from other
transactions and are always serializable by default.
For example, the following SQL statements are illegal:
SQL> SET TRANSACTION READ ONLY ISOLATION LEVEL READ COMMITTED
SQL> SET TRANSACTION READ ONLY ISOLATION LEVEL REPEATABLE READ
In Rdb/VMS V4.2, you will receive the following error
message if you use a SET TRANSACTION statement that
specifies conflicting transaction options.
SQL> SET TRANSACTION READ ONLY
cont> ISOLATION LEVEL REPEATABLE READ;
%RDB-F-BAD_TPB_CONTENT, invalid transaction parameters in the transaction
parameter block (TPB)
-RDMS-E-CONFTRANOPT, conflicting transaction options specified
A statement that specifies the following transaction
options is acceptable, although Digital does not recommend
using it, because this combination of transaction options
has been deprecated in SQL:
SQL> SET TRANSACTION READ ONLY CONSISTENCY LEVEL 2
Prior to Rdb/VMS V4.2, Rdb/VMS interpreted this combination
as SERIALIZABLE.
For more information about serializable transactions, see
the VAX Rdb/VMS New and Changed Features.
2.1.13 Delete Constraints Before Changing Field Data Type
You must drop any constraint that references a field
before you change the data type of that field directly
or indirectly. Field characteristics affected by this
restriction include type, length, character set, segment
length, and scale.
Known Problems, Restrictions, and Other Notes 2-17
In previous versions of Rdb/VMS, you could change the data
type of a field so that data would no longer be consistent
with existing constraints. For example, you could shorten
the number of characters in a particular text field that
was referenced by a primary key or unique constraint.
Data inconsistency resulted because constraints are not
re-evaluated after a field change.
2.1.14 You Cannot Create or Access Databases on DFS-mounted Disks
You cannot create or access a database on a disk mounted
by the Distributed File Server (DFS), because DFS does not
support shared write.
Attempts to create such a database generate an error like
the following:
%SQL-F-ERRCRESCH, Error creating database filename ACMS_CONFIG
-SYSTEM-F-NOACLSUPPORT, ACLs not supported on selected object
To avoid this problem, create database files only on disks
that support shared write.
2.2 SQL Known Problems and Restrictions for V4.2
This section contains known problems and restrictions for
the SQL interface for Rdb/VMS V4.2.
2.2.1 SQL Name Length Restrictions Affect RMU/LOAD and RMU/UNLOAD
Commands
The following name length restrictions affect RMU/LOAD and
RMU/UNLOAD commands that specify SQL objects.
o Specifying a name longer than 31 characters corrupts
internal storage and causes the operation to fail with
an ACCVIO exception or with an RDB$_BAD_DPB_CONTENT
error.
o Specifying a name shorter than 31 characters but in
multischema format generates an RMU-F-RELNOTFND error,
as shown in the following example:
$ RMU/UNLOAD MY_DATABASE CAT.SCHEMA.TABLE OUTPUT.UNL
%RMU-E-OUTFILDEL, Fatal error, output file deleted
-RMU-F-RELNOTFND, Relation (CAT.SCHEMA.TABLE) not found
2-18 Known Problems, Restrictions, and Other Notes
To avoid these errors, use the SQL external name for the
table. The external name is stored in the RDB$RELATIONS
system table.
2.2.2 RMU/LOAD Record Definition Restricted to Table and Domain
Names From MCS Character Set
If your database uses some character set other than MCS for
table and domain names, or if you edit a record definition
file to use names from such a character set, RMU/LOAD may
fail with the following error:
$ RMU/UNLOAD/RMS_RECORD_DEF=FILE=STRINGS MIA -
"TAB_°¡°¢abcd°§ABCD°©°ª" -
STRINGS.UNL
%RMU-I-DATRECUNL, 4 data records unloaded
$ RMU/LOAD/RMS_RECORD_DEF=FILE=STRINGS MIA -
"TAB_°¡°¢abcd°§ABCD°©°ª" -
STRINGS.UNL
DEFINE FIELD DEC_MCS_CHAR DATATYPE IS TEXT SIZE IS 20.
DEFINE FIELD KANJI_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS KANJI.
DEFINE FIELD HANZI_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS HANZI.
DEFINE FIELD HANYU_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS HANYU.
DEFINE FIELD KOREAN_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS KOREAN.
DEFINE FIELD KATAKANA_CHAR DATATYPE IS TEXT SIZE IS 20 CHARACTERS -
CHARACTER SET IS KATAKANA.
DEFINE FIELD DEC_KANJI_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS DEC_KANJI.
DEFINE FIELD DEC_HANZI_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS DEC_HANZI.
DEFINE FIELD DEC_KOREAN_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS DEC_KOREAN.
DEFINE FIELD DEC_SICGCC_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS DEC_SICGCC.
DEFINE FIELD DEC_HANYU_CHAR DATATYPE IS TEXT SIZE IS 5 CHARACTERS -
CHARACTER SET IS DEC_HANYU.
DEFINE FIELD ISOLATINGREEK_CHAR DATATYPE IS TEXT SIZE IS 20 CHARACTERS -
CHARACTER SET IS ISOLATINGREEK.
DEFINE FIELD ISOLATINHEBREW_CHAR DATATYPE IS TEXT SIZE IS 20 CHARACTERS -
CHARACTER SET IS ISOLATINHEBREW.
DEFINE FIELD ISOLATINARABIC_CHAR DATATYPE IS TEXT SIZE IS 20 CHARACTERS -
Known Problems, Restrictions, and Other Notes 2-19
CHARACTER SET IS ISOLATINARABIC.
DEFINE FIELD ISOLATINCYRILLIC_CHAR DATATYPE IS TEXT SIZE IS 20 CHARACTERS -
CHARACTER SET IS ISOLATINCYRILLIC.
DEFINE FIELD DEVANAGARI_CHAR DATATYPE IS TEXT SIZE IS 20 CHARACTERS -
CHARACTER SET IS DEVANAGARI.
DEFINE FIELD DDCS_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS DEC_KANJI.
DEFINE FIELD NAT_CHAR DATATYPE IS TEXT SIZE IS 10 CHARACTERS -
CHARACTER SET IS DEC_KANJI.
DEFINE RECORD TAB_°¡°¢abcd°§ABCD°©°ª.
%RMU-F-RECDEFSYN, Syntax error in record definition file
DEFINE RECORD TAB_''°¡°¢ABCD°§ABCD°©°ª.
When this problem occurs, edit the record definition file
and modify the names so that they can be represented with
the MCS character set.
2.2.3 List Storage Maps Cannot Be Referenced Across Catalogs
In a multischema database with multiple catalogs, you
cannot reference a list storage map that is defined in
another catalog. For example, the database in the following
example has six lists in three different catalogs-RECS,
TXT_OBSERVATIONS, and PHOTO_OBS_REC. An attempt to
reference the other list columns by their fully qualified
names generates an error.
SQL> CREATE STORAGE MAP SEG_STR_MAP
cont> STORE LISTS IN FOR
cont> IN LOC1 FOR (RECS.ORIGINAL_FILE)
cont> IN LOC1 FOR (RECS.PROCESSED_FILE)
cont> IN LOC1 FOR (RECS.PROCESSED_LOG)
cont> IN COMMENTS FOR (TXT_OBSERVATIONS.OBSERVATIONS.OBSERVING_REC.COMMENT)
cont> IN COMMENTS FOR (PHOTO_OBS_REC.COMMENT)
cont> IN COMMENTS FOR (RECS.COMMENT)
IN COMMENTS FOR (TXT_OBSERVATIONS.OBSERVATIONS.OBSERVING_REC.COMMENT)
^
%SQL-W-LOOK_FOR_STT, Syntax error, looking for:
%SQL-W-LOOK_FOR_CON, ,, ),
%SQL-F-LOOK_FOR_FIN, found . instead
To reference list storage maps in other catalogs, attach
to the appropriate database with multischema disabled and
refer to the external name of the storage map.
2-20 Known Problems, Restrictions, and Other Notes
2.2.4 Images Required for Privileged Applications
To install a privileged SQL application, you must first
install the image SYS$SHARE:SQL$INT.EXE.
You must also install one of the following images:
o SYS$SHARE:SQL$SHR.EXE for a standard kit
o SYS$SHARE:SQL$SHR42.EXE for a multiversion kit
If you do not install these images, you could get the no
entry point error message.
2.2.5 SQL Pascal Precompiler Processes ARRAY OF RECORD
Declarations Incorrectly
The Pascal precompiler for SQL gives an incorrect %SQL-
I-UNMATEND error when it parses a declaration of an array
of records. It does not associate the END statement with
the record definition, and the resulting confusion in host
variable scoping causes a fatal error.
To avoid the problem, declare the record as a type and then
define your array of that type. For example:
main.spa:
program main (input,output);
type
exec sql include 'bad_def.pin'; !gives error
exec sql include 'good_def.pin'; !ok
var
a : char;
begin
end.
---------------------------------------------------------------
bad_def.pin
Known Problems, Restrictions, and Other Notes 2-21
x_record = record
y : char;
variable_a: array [1..50] of record
a_fld1 : char;
b_fld2 : record;
t : record
v : integer;
end;
end;
end;
end;
---------------------------------------------------------------
good_def.pin
good_rec = record
a_fld1 : char;
b_fld2 : record
t : record
v: integer;
end;
end;
end;
x_record = record
y : char
variable_a : array [1..50] of good_rec;
end;
2.2.6 Clarification of Cursors and USING CONTEXT Clause
In any one module in a precompiled SQL program, if one
statement that refers to a cursor contains the USING
CONTEXT clause, all statements that refer to that cursor
must contain the USING CONTEXT clause. The only exception
is the DECLARE CURSOR statement, which does not take a
USING CONTEXT clause.
For example, if a statement that opens a cursor contains
a USING CONTEXT clause, all other statements that open or
otherwise operate on that same cursor in the same module
must contain a USING CONTEXT clause. Although the second
OPEN statement in the following example is illegal, SQL
does not return an error:
2-22 Known Problems, Restrictions, and Other Notes
main ()
{
exec sql declare a_cursor cursor for select * from employees;
exec sql using context :ctx open a_cursor;
.
.
.
exec sql open a_cursor;
}
In a future release, SQL will return an error during
compilation in this situation.
2.2.7 Using UPDATE ONLY Cursors With Selective Indexes May Reduce
I/O and Locking Problems
In Rdb/VMS V4.1, new syntax and semantics were added to the
SQL DECLARE TABLE CURSOR and searched UPDATE statements.
Table cursors are declared UPDATE by default.
When a cursor is declared as UPDATE ONLY, SQL assumes that
all (or at least a large proportion) of the rows will be
modified by subsequent UPDATE . . . WHERE CURRENT OF or
DELETE WHERE CURRENT OF statements.
For an UPDATE ONLY cursor, all rows fetched from the
database are locked for UPDATE. If you do not specify
the UPDATE ONLY clause, the rows are locked for READ,
and these locks will be converted later to UPDATE locks.
In general, using the UPDATE ONLY clause avoids lock
conversion operations and possible deadlocks resulting
from them.
The side effect of UPDATE ONLY operations is that all rows
will be locked for UPDATE, even those records that will be
finally filtered out using the select expression.
The following DECLARE CURSOR statement illustrates this
problem.
SQL> DECLARE C TABLE CURSOR AS
cont> SELECT *
cont> FROM TABLE_NAME
cont> WHERE COLUMN_NAME1 > 'AA'
cont> AND COLUMN_NAME2 = 10;
Known Problems, Restrictions, and Other Notes 2-23
Assume that the index on COLUMN_NAME1 is selected by
the optimizer to fetch rows from the database. Next, the
fetched rows are filtered with the extra boolean conditions
(such as COLUMN_NAME2 = 10). The resulting set of rows
are then updated. However, because the index on COLUMN_
NAME1 was not very selective, it is possible that many more
records are locked and journalled than are strictly needed
for the update.
To reduce the locking and journal I/O impact on the table,
use a more selective index to fetch only those rows that
will be updated. For example, in the preceding DECLARE
TABLE statement, create an index on both columns used in
the select expression (COLUMN_NAME1, COLUMN_NAME2).
Searched updates (UPDATE statements that do not use a
cursor) do not use the UPDATE ONLY semantics.
Digital is investigating ways to reduce the locking and
I/O impact of UPDATE ONLY cursors for a future release of
Rdb/VMS.
2.2.8 Positioned Insert Statement Does Not Allow RETURNING Clause
You cannot insert a row into an insert-only table cursor
using the RETURNING DBKEY clause.
For example:
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> DECLARE CURSOR1 INSERT ONLY TABLE CURSOR FOR SELECT * FROM COLLEGES;
SQL> OPEN CURSOR1;
SQL> INSERT INTO CURSOR CURSOR1 (COLLEGE_CODE, COLLEGE_NAME)
cont> VALUES ('ASU','Arizona State University') RETURNING DBKEY;
%SQL-F-NORETURN, Specifying a RETURNING clause is incompatible with a
positioned insert statement
SQL> CLOSE CURSOR1;
SQL>
SQL> DECLARE CURSOR2 INSERT ONLY TABLE CURSOR FOR SELECT * FROM RESUMES;
SQL> OPEN CURSOR2;
SQL> INSERT INTO CURSOR CURSOR2 (EMPLOYEE_ID) VALUES ('00169') RETURNING DBKEY;
%SQL-F-NORETURN, Specifying a RETURNING clause is incompatible with a
positioned insert statement
SQL> CLOSE CURSOR2;
SQL> DISCONNECT ALL;
2-24 Known Problems, Restrictions, and Other Notes
To avoid this problem, specify the SQL INSERT statement
without using a cursor. Use the "INSERT INTO table-
name . . . RETURNING DBKEY INTO . . . " syntax.
2.3 RMU Known Problems and Restrictions for V4.2
This section describes known problems and restrictions for
the RMU interface effective with V4.2.
2.4 SQL/Services Known Problems and Restrictions for V4.2
Sections 2.4.1 through 2.4.4 describe known problems and
restrictions for SQL/Services for Rdb/VMS V4.2.
2.4.1 SQL/Services TCP/IP Support Doesn't Work for Messages That
Exceed the Client Write Buffer Size
SQL/Services TCP/IP support fails when client messages
exceed the client write buffer size. The default write
buffer size is 1300 bytes. If a client message is larger
than the write buffer size, SQL/Services breaks the message
into packets. The SQL/Services communications server
incorrectly expects to receive the same number and size
packets that the client sent. This may not be assumed with
TCP/IP. If the server reads faster than the client sends
packets, the SQL/Services execution server will bugcheck,
displaying the following error:
SQL Services Internal Error: 41
2.4.2 Problem Deinstalling SQL/Services in a Multiversion
Environment
In its multiple version implementation, SQL/Services
replaces most existing SQL/Services API and server images
and files with compatible ones for V4.2. If there is
another version of SQL/Services installed, the V4.2
installation will replace it. The few SQL/Services files
and images that are version specific are installed with
varianted file names.
When you use RDBVMS$DEINSTALL_DELETE.COM to deinstall
a multiversion install, it incorrectly deletes the
nonvarianted SQL/Services images and files, whether or
not there are other versions of SQL/Services installed.
Known Problems, Restrictions, and Other Notes 2-25
For example:
$ @SYS$MANAGER:RDBVMS$DEINSTALL_DELETE 4.2 Y
You are about to delete Rdb 4.2
Are you sure - enter Y[ES] to continue delete: Y
If you must do a multiversion delete and there are other
versions installed, you must first preserve the SQL
/SERVICES APIs and server images and files so they can
be restored after the multiversion delete.
You can archive API and server images and files as follows:
o Preserving APIs on the server system
You can preserve the entire set of SQL/Services APIs on
the server system by renaming the SYS$COCMMON:SQLSRV]
directory.
o Preserving the server images and files
Preserve the following files and images:
SYS$SYSTEM:SQLSRV$.EXE
SYS$SYSTEM:SQLSRV$EXE.EXE
SYS$SYSTEM:SQLSRV$UTL.EXE
SYS$STARTUP:SQLSRV$PROXY.DAT
SYS$STARTUP:SQLSRV$RUN.COM
SYS$STARTUP:SQLSRV$RUNEXE.COM
SYS$STARTUP:SQLSRV$STARTUP.COM
SYS$STARTUP:SQLSRV$SHUTDOWN.COM
SYS$HELP:SQLSRV$MSG.DOC
SYS$LIBRARY:SQLSRV$API.EXE
SYS$LIBRARY:SQLSRV$API.OLB
SYS$LIBRARY:SQLSRV$API.OPT
SYS$LIBRARY:SQLSRV.H
SYS$LIBRARY:SQLSRVCA.H
SYS$LIBRARY:SQLSRVDA.H
SYS$MESSAGE:SQLSRV$MSG.EXE
2-26 Known Problems, Restrictions, and Other Notes
2.4.3 SQL/Services IVP May Fail if SYS$NODE Is Not Defined
You must be sure that the DECnet nodename (SYS$NODE) is
properly defined. SYS$NODE is usually defined when the
network is started. To check the SYS$NODE definition, enter
a SHOW LOGICAL command. For example, a user logged into a
node named LLAMA should see output like the following:
$ SHOW LOGICAL SYS$NODE/FULL
"SYS$NODE" [exec,crelog] = "LLAMA::" [terminal] (LNM$SYSTEM_TABLE)
If SYS$NODE is not defined, you may see an error like the
following when you run the SQL/Services IVP:
***** Connecting to GENERIC class *****
***** SQL Services IVP Error *****
SQLCA: SQLCODE: -2003
SQLERRD[0]: 652 SQLERRD[2] 0
%SYSTEM-F-NOSUCHNODE, remote node is unknown
*** SQL/Services IVP failed when accessing the GENERIC class ***
If this error occurs, correct the network initialization
problem and restart SQL/Services.
2.4.4 You Must Call SQLSRV_CLOSE_CURSOR() before COMMIT WORK
SQL/Services indicates that a cursor is open even though
its transaction has ended. Within SQL, executing a COMMIT
statement implies that all open cursors are closed: this
assumption is not true for SQL/Services. SQL/Services does
not parse the SQL statements it passes, but requires that
the sqlsrv_close_cursor() call be issued to release the
cursor-related data structures prior to a commit operation.
To reuse the same cursor name, you must close that cursor
before executing a COMMIT or ROLLBACK statement.
2.5 Documentation Errors, Omissions, and Clarifications of
Software Behavior for V4.2
This section contains known documentation errors, errors of
omission, and clarification of software behavior for V4.2.
Documentation errors apply to books that are not being
revised and reissued for V4.2.
Known Problems, Restrictions, and Other Notes 2-27
2.5.1 Information Omitted from the VAX Rdb/VMS Installation
Guide Regarding the Installation of the SQL$INT.EXE and
SQL$SHRnn.EXE Shareable Images
The following information was omitted from the V4.1 VAX
Rdb/VMS Installation Guide and is described here to
clarify the proper installation of the SQL$INT.EXE and
SQL$SHRnn.EXE shareable images.
Currently, none of the SQL images are installed with the
INSTALL utility. Instead, Section 3.11.2 in the VAX Rdb/VMS
Installation Guide explains how a user would do this. What
is omitted is the following sentence:
If you are trying to run a privileged image you must
install both the SQL$INT.EXE and SQL$SHR.EXE images using
the INSTALL utility.
Other causes for receiving the SQL-F-NOENTRYPT message
were also omitted. In addition to the actions listed in
the SQLMSG.MSG file, the user should make sure that the
correct version of SQL$INT.EXE is in SYS$COMMON:[SYSLIB]
and that the shareable images are installed correctly to
run privileged images.
2.5.2 Using Global Buffers
The following important information from the V4.1 Release
Notes was omitted from the V4.2 SQL Online Help.
With global buffering, user processes map global sections
to their virtual memory instead of making copies of the
buffer in physical memory. Although more than one user
process can read a page at the same time, there is only
one copy of the page in the global buffer pool. Improved
performance is achieved because I/O operations are reduced
and memory is better utilized.
Prior to V4.1, all page buffering was local to the user
process. Beginning with V4.1, global page buffering is
optional. Existing buffer qualifiers have not changed.
Page-locking protocol has been adjusted to support global
buffering on VAXclusters. By default, global buffering
is not enabled, and local buffering is used. Note that in
a VAXcluster environment, local buffering is enabled by
default for all nodes in the VAXcluster. You can optionally
enable global buffering for all nodes and then individually
2-28 Known Problems, Restrictions, and Other Notes
tune each node. However, you cannot mix the use of global
and local buffers together on individual nodes within the
same VAXcluster environment. That is, you exclusively use
either global buffers or local buffers for all nodes in the
VAXcluster environment, but not both.
2.5.2.1 Enabling Global Buffers
To enable global buffering, establish the number of buffers
for a database, and set a global buffer limit per user, a
new qualifier has been added to the RMU/OPEN command, and
a new clause has been added to the SQL CREATE DATABASE and
ALTER DATABASE statements:
RMU/OPEN/GLOBAL_BUFFERS = (TOTAL = integer,USER_LIMIT = integer)
See RMU online help for a brief description of this new
qualifier.
In the SQL CREATE DATABASE or ALTER DATABASE statement,
global buffers are specified as follows:
(GLOBAL BUFFERS ARE ENABLED|DISABLED
NUMBER IS number-glo-buffers,
USER LIMIT IS max-glo-buffers)
See the VAX Rdb/VMS SQL Reference Manual, and the VAX
Rdb/VMS Guide to Database Performance and Tuning for
more information on specifying and setting global buffer
parameters.
Global buffers may require a higher global section quota.
See the VAX Rdb/VMS Installation Guide for information
on defining the maximum number of pages for the global
sections with the GBLPAGFIL system parameter. See the VAX
Rdb/VMS SQL Reference Manual for more information on the
SQL CREATE and ALTER statements. See the VAX Rdb/VMS Guide
to Database Design and Definition for more information on
how database pages are buffered with global buffering.
2.5.2.2 Applications That Benefit from Using Global Buffers
Global buffers are most suitable for applications in
which shared data is predominant. When global buffers are
enabled, this can save I/O operations, especially in read
applications. The benefits, however, are not restricted to
transactions that use snapshot files.
Known Problems, Restrictions, and Other Notes 2-29
Tests were run to stress-test the global buffers feature
and these tests provided the following results and
conclusions.
In V4.2 and all previous versions of Rdb/VMS, Rdb/VMS
always creates a global section; that is, with the first
database attach, the Rdb/VMS monitor creates a global
section. Before V4.1, Rdb/VMS used this global section
to maintain the database root data structures.
With Rdb/VMS V4.1 and V4.2 applications using global
buffers, this global section is extended to include the
global buffer pool and the necessary data structures
required to maintain the integrity of its resident data.
These data structures are used to maintain the following
information:
Global buffer control blocks
Global buffer page table
Allocate set block counted lists
Global buffer journaling logs
Process local lock (PLL) for system-owned DB and storage
area locks
The following series of questions and explanations
describes how to determine the number of global buffers
you need and how to verify this value, what VMS parameters
to check, how global buffers are used, and the performance
gains that might be expected from their use.
o How many global buffers do you need?
The following example shows how to enable and set global
buffer parameters.
SQL> ALTER DATABASE FILENAME MYDABASE GLOBAL BUFFERS ARE ENABLED
cont> (NUMBER 1000, USER LIMIT 30);
There are two parameters the database admnistrator (DBA)
specifies when altering the database to enable global
buffers.
The NUMBER parameter determines the total number of
global buffers the DBA deems necessary to accommodate
the full set of data pages intended for sharing. Because
global buffers share the root global section and because
the number of data structures maintained in this global
section can vary widely, the DBA should focus on how
2-30 Known Problems, Restrictions, and Other Notes
much space is needed to store the information; that is,
determine the size of the database data that must reside
in the global section and allow Rdb/VMS to determine the
overall space required for the overall global section.
The USER LIMIT parameter is the maximum number of global
buffers to which a user's allocate-set can grow. If the
maximum number is set to 100 buffers and the DBA defines
the logical name RDM$BIND_BUFFERS to be 100, then the
user will be allocated 100 buffers. A user cannot exceed
this limit.
o What VMS parameters should you watch for?
Whether global buffers are enabled or not, one global
section is allocated for the database root on your
system when the first user attaches to the database.
Since global buffers share this same section, there is
no impact on the number of global sections (GBLSECTIONS)
specific to Rdb/VMS V4.1 or V4.2.
The GBLPAGES is the parameter that determines the number
of global page entries and the global pages that can
be created on the system. This and VIRTUALPAGECNT are
probably the most critical parameters. VIRTUALPAGECNT
determines the number of pages a process can map on the
system.
The GBLSECTIONS, GBLPAGES, and VIRTUALPAGECNT parameters
are modifiable; however, because of their nondynamic
nature, any change requires a system reboot. Digital
recommends that any modifications to the SYSGEN
parameters be made through the MODPARAMS.DAT file and
the VMS AUTOGEN facility. It is possible to hang a
system on reboot due to hardcoded parameters.
o How do you verify these parameters?
The use of GBLPAGES and GBLSECTIONS may be verified
using the VMS INSTALL utility. Issuing the command
"LIST/GLOBAL" at the INSTALL> prompt before and after
attaching to the database provides the information
necessary to determine the number of global page entries
allocated for your database.
$ INSTALL
INSTALL> LIST/GLOBAL/SUMMARY
290 Global Sections Used, 104340/68260 Global Pages Used/Unused
Known Problems, Restrictions, and Other Notes 2-31
This means that 290 global sections are used out of the
total defined on the system using the SYSGEN utility;
68260 global page entries are available.
The INSTALL utility can be quite verbose on systems with
too many installed products. It will list the whole set
of products installed before displaying the information
you need. There are two ways of avoiding this problem:
o Use the INSTALL utility and specify the LIST command
with the /GLOBAL/SUMMARY qualifiers to obtain used
global page and global section summary information.
o Define lexical functions to obtain unused global page
and global section information.
When you specify the LIST command with the /GLOBAL
/SUMMARY qualifiers, the following used estimates of
the global page and global section parameters display:
$ INSTALL
INSTALL> LIST/GLOBAL/SUMMARY
Summary of Local Memory Global Sections
290 Global Sections Used, 104340/68260 Global Pages Used/Unused
The lexical function F$GETSYI provides a way of easily
getting unused estimates of the global page and global
section parameters. Define symbols as follows and invoke
them at the DCL level or in interactive RDO and SQL to
display the values of GBLPAGES and GBLSECTIONS.
$ GBLPAGES :== "write sys$output f$getsyi("""free_gblpages""")
$ GBLSECTIONS :== "write sys$output f$getsyi("""free_gblsects""")
With these symbols defined, you can check how many
GBLPAGES and GBLSECTIONS are available on your system:
$GBLPAGES
122634
$GBLSECTIONS
109
These results indicate the number of global page entries
still available; that is, 122634 entries out of the
150000 entries that the VMS System Generation Utility
(SYSGEN) has on the system. The total number of global
sections available is 109 out of 400 that SYSGEN has on
this system.
2-32 Known Problems, Restrictions, and Other Notes
Before altering your database to enable global
buffering, perform a simple database attach with local
buffers enabled. This can reveal that you have allocated
a global section and a number of global page entries to
the database root structures, as the following example
shows:
$SQL
SQL> ATTACH 'FILE MYDATABASE';
SQL>$GBLSECTIONS
108
SQL>
SQL> $GBLPAGES
122112
The "$GBLSECTIONS" shows that you have allocated the
109th section and the GBLSECTIONS left on your system
now stands at 108. The "GBLPAGES" shows that the number
of global page entries dropped from 122634 to 122112
(522 entries have been allocated).
Next, enable global buffers and allocate 1000 buffers
with a buffer size of 4 blocks.
$ SQL
SQL> ALTER DATABASE FILENAME MYDATABASE GLOBAL BUFFERS ARE ENABLED
cont> (NUMBER 1000, USER LIMIT 30);
Before attaching to the database, the number of global
page entries stood at 122634. What is this value after
attaching to the database? A process using interactive
SQL attaches to the database then checks the VMS
parameters:
$ SQL
SQL> ATTACH 'FILE MYDATABASE';
SQL> $GBLPAGES
117344
SQL> $GBLSECTIONS
308
The number of GBPAGES dropped from 122634 to 117344
entries; 5290 entries are allocated to the 1000 buffers
of 4 blocks each. The ALTER DATABASE statement is
expected to allocate 4000 entries (1000 * 4 blocks).
It did this plus an additional 1290 entries on behalf of
Known Problems, Restrictions, and Other Notes 2-33
the data structures used to maintain the global buffer
pool.
o Is it possible to reduce the GBLPAGES entries?
The size of the global page pool allocated when global
buffers are active depends on many factors, such as
the number of global buffers, the maximum number of
global buffers per user, the number of users, the number
of storage areas in the database, and so forth. These
factors and others make it difficult to provide a simple
formula that you can use.
The number of users is one database parameter the DBA
has control over. Often, the DBA tends to leave certain
database parameters set as default values because
these values may be acceptable and have had no real
impact on system resources or performance. When a
database is created with no explicit total number of
users parameter specified, the default is set to 160.
Most applications do not require that high a value,
especially applications running on a single node, or
applications running with a TP monitor (such as ACMS).
For systems where memory is a critical resource, the DBA
may want to manually adjust the total number of users to
a more realistic value and conserve memory.
The following table shows how the GBLPAGES entries
allocated increases as the number of users increases.
Request made for 500 buffers at 4 blocks each
Number of users Global pages allocated.
20 2742
60 2872
80 3110
100 3156
200 3378
300 3600
400 3824
500 4048
o What other default values should a DBA watch for?
2-34 Known Problems, Restrictions, and Other Notes
The following is an extract from the RMU/DUMP command
for a database.
- Global buffers are enabled
- Global buffer count is 1024
- Maximum global buffer count per user is 5
- Default database buffer count is 45
The overriding global buffer count is the maximum count
per user that defaults to 5. With global buffers,
the defined or default database buffer count can be
overridden with the logical name RDM$BIND_BUFFERS.
However, the maximum global buffer count per user
can override the value defined by this logical name.
With local buffers, the logical name RDM$BIND_BUFFERS
overrides the defined or default database buffer count.
Using an SQL ALTER DATABASE or RDO CHANGE DATABASE
statement, it is best to explicitly specify the maximum
global buffer count per user at or slightly over what
you would expect users to have, then use the logical
name RDM$BIND_BUFFERS to adjust the user allocate set
as needed. Otherwise, users will get 5 buffers each in
their allocate set regardless of what the DBA specifies
with the RDM$BIND_BUFFERS logical name.
Occasionally a user may require 100 buffers, although
in most cases 20 would suffice. For example, report
generation done nightly may require data from multiple
tables and, therefore, 100 buffers may be needed. Daily
activities may only require 20 or 30 buffers. Setting
the maximum at 100 allows the user to switch as needed.
Setting the limit to 20 or 30 does not meet the report
generation requirements.
Similarly, when the maximum global buffer count is set
high, the DBA must ensure that enough buffers are in the
global buffer pool for all database users; otherwise,
processes with even a low allocate set will fail. For
example, if the DBA sets the total number of global
buffers to 1000 buffers, sets the user limit to 100,
then defines RDM$BIND_BUFFERS to 100, an 11th process
attaching to the database is rejected. The advice to the
DBA is to keep a few spare buffers for that occasional
extra user (11th process in this case). In this example,
Known Problems, Restrictions, and Other Notes 2-35
an additional 100 buffers would be good to accommodate
extra users who may need only 2 to 3 buffers each.
o Are there any other defaults to watch for?
In Rdb/VMS V4.1 and V4.2, the carry-over lock
optimization is on by default. With this optimization
on, a process does not relinquish locks on resources
unless they are requested by a contending process. This
optimization works well in cases where a process updates
the same set of pages often, and there is little or no
contention over the resources this process owns.
In tests, users randomly generated keys and performed
updates based on records with those randomly generated
keys. Using the RMU/SHOW STATISTICS command, you can
observe that the system throughput reaches a peak,
drops to zero every few seconds, then goes back up
to peak throughput and so forth. The carry-over lock
optimization is the reason for this behavior. When
the database is altered and you turn off the carry-
over lock optimization, the system maintains its peak
throughput throughout the test. In high contention
situations, carry-over locks may not be useful. The
DBA may want to verify the default setting in V4.1 or
V4.2 to determine whether they are suitable for their
particular application. Note that this problem is not
specific to only global buffers.
o What happens when you allocate more global buffers than
your system parameters can handle?
Rdb/VMS does not give you an error message when you
alter the database and specify a number of global
buffers larger than your system can handle. However,
on the first attempt to attach to the database, you will
get the following or a similar error message:
%RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-EXQUOTA, exceeded quota
-LIB-F-INSVIRMEM, insufficient virtual memory
Your database at this time is in a limbo state because
the DBA cannot attach to the database using either SQL
or RDO to alter the database global buffer parameters.
To recover from this situation, use the RMU/OPEN command
2-36 Known Problems, Restrictions, and Other Notes
and lower the global buffer parameters to a level your
system can handle.
This same user action also applies to cases where a
database backup is restored on a smaller system or a
system configured with low SYSGEN parameters relative to
your database and application requirements. An example
of the RMU/OPEN command follows:
$ RMU/OPEN/GLOBAL_BUFFERS = (TOTAL=n,USER_LIMIT=z) MYDATABASE
where the parameter n is a value likely to match your system parameters.
You must then follow up with the necessary changes to
the system parameters using the MODPARAMS.DAT file and
the AUTOGEN utility.
o Are there a lot of page faults with global buffers?
With global buffers active, a higher than usual number
of GLOBAL VALID faults is observed. A GLOBAL VALID FAULT
indicates that the page that caused the fault is in the
global buffer pool but is in some other user's allocate
set. These are soft faults and are harmless. The VMS
monitor (MONITOR PAGE) and VAX SPM give a breakdown of
page faults by category.
o Are there more lock operations with global buffers than
with local buffers?
Global buffers do incur more lock operations than
local buffers. Some of the additional lock operations
are system-owned page locks, which can be costly,
while others are local locks. The system-owned page
locks maintain page version numbers among nodes in a
VAXcluster. Local inexpensive locks synchronize access
to the global buffer data structures. The increase in
locks that is noticed in these tests are mostly page
locks and some record locks. The DBA should ensure the
LOCKIDTBL has enough entries in it to accommodate the
additional locking. Use the VMS MONITOR LOCK command
to show the total locks on the system, then verify this
total against the LOCKIDTBL entries on the system.
o What performance gains can be expected from global
buffering?
Known Problems, Restrictions, and Other Notes 2-37
Because global buffers require a number of data
structures to maintain data integrity and consistency,
you should expect a certain level of performance
overhead. The following tests compared global buffers
to local buffers.
The first set of tests consisted of loading 60,000
records in 10 storage areas, submitting 15 users to
execute light update transactions against the database
with redo logging, checkpointing, and commit to journal
optimization applied.
The database was partitioned among 15 users such that
there was no data sharing whatsoever. With each process
working in a separate database partition, there was no
use for global buffering. In fact, global buffers added
overhead and caused the TPS rate to drop from 68.5 to
62.8 or approximately a 9% drop in throughput.
Global buffering was exercised in read-only environments
and the results were compared to local buffers. One
thousand records were loaded in several database storage
areas and ten batch processes submitted to perform read
transactions. Ten users randomly generated keys between
1 and 1000. Each key was then applied to retrieve a
record from the database. The exercise consisted of
retrieving two, three, and four records using unique
keys. The results for two-, three-, and four-record
retrievals are as follows:
Read-Only Environment VAX 6320 - 128MB memory
Number of GBL
Test style TPS Read I/Os Memory Locks %CPU %Increase
Local Buffers 60 2 20.8% 32.6 100%
Global buffers 72 0 22.2% 42.7 100% 20
Local Buffers 42.7 3 21.6% 35.4 100%
Global buffers 51.5 0 22.2% 50.9 100% 22
Local Buffers 32.8 4 22.2% 65.2 100%
Global buffers 40.5 0 22.2% 85.2 100% 23
With global buffers, the full set of records was cached
and no read I/O operations were performed. With local
buffers it would have taken 1000 buffers for each of the
10 users to achieve no I/O operation read status.
2-38 Known Problems, Restrictions, and Other Notes
In read-only environment tests, global buffers increased
locking. With zero reads in all cases and in spite of
overhead due to the additional locking, an approximately
20% performance increase was achieved over the use of
local buffers. No memory savings were observed in these
tests.
In read/write environment tests, users performed an
update on each record they read with instances of two-,
three-, and four-record updates being performed. The
results are as follows:
Read/Write Environment VAX 6320 - 128MB memory
GBL
Test style TPS I/Os Memory Locks %CPU %Increase
R W
Local Buffers 35.5 2 2 21.6% 39.3 ~100%
Global buffers 38.5 0 2 22.5% 53.3 ~100% 8
Local Buffers 25.5 3 3 22.7% 56.8 ~100%
Global buffers 28.0 0 3 23.1% 76.9 ~100% 10
Local Buffers 19.8 4 4 22.4% 79.4 ~100% 12.5
Global buffers 22.3 0 4 23.4% 106.5 ~100%
In read/write environment tests with global buffers
there were no read I/O operations because all data was
cached in global memory. There were, however, as many
writes as with local buffers. The tests were set up such
that no page in a user's allocate set was modified twice
by the same process in the same checkpoint period. The
random nature of the key generation was such that pages
did not last long in the user's allocate set. Modified
data pages leaving the user's allocate set were flushed
to disk because there was no mechanism by which to flush
all modified pages database-wide.
As with the read-only environment tests, global buffers
do incur more overhead than local buffers as shown in
the locking column. However, where there is a level of
data sharing, global buffers do save on I/O operations
and can achieve better throughput than local buffers.
________________________ Note ________________________
To ensure a proper comparison of global buffers
to local buffers performance test results, the
Known Problems, Restrictions, and Other Notes 2-39
equivalence case should be kept in mind. That is,
a special case of the settings is when the local and
global buffers settings are equivalent. The basis
of this equivalence is memory usage and this can be
expanded into the following two rules.
o The total number of buffers used by all the
users must be equal for local and global
buffers.
o The number of buffers used by each user must be
equal for local and global buffers.
One way to set up buffering parameters is as follows.
Set up the default number of buffers to be B. Set up
the "maximum global buffers per user" also to be B.
If you are going to have N users for the performance
test, set up the number of global buffers to be B
times N. Do not use any buffering logicals to keep
it simple. Following these guidelines permits you to
enable and disable global buffers and run performance
tests.
______________________________________________________
To help determine the benefits from enabling global
buffers, the RMU/SHOW STATISTICS command is enhanced to
include both I/O and locking information. When you select
the PIO Statistics Screen, the "found in gb pool" field
describes the number of times that the requested page
was found in the database global buffer pool; that is,
the number of I/O operations saved due to enabling global
buffers because the requested page was found in the global
buffer page.
The global buffer page table (GBPT) slot lock is a new type
of lock added in V4.1. It is a VMS local lock mastered on
the same node and therefore is not as expensive as other
distributed locks in a VAXcluster environment. The GBPT
slot locks protect global buffer data structures from being
inconsistently updated by different users. GBPT slot locks
are requested and released whenever a database page is
brought into or purged from the allocate sets of users.
2-40 Known Problems, Restrictions, and Other Notes
The RMU/SHOW STATISTICS command is enhanced to show both
the GBPT slot lock type information for all lock operations
as well as showing information about a particular lock
operation for all lock types that includes the GBPT lock
type.
The "found in gb pool" statistic represents the savings
in I/O due to global buffers, whereas the total number of
GBPT slot locks represents the locking overhead associated
with global buffers. Thus, you can use the new statistics
to determine if global buffers are helpful for your
application.
Note that the global buffer defaults are derived in the
following manner. As previously mentioned, setting the
total number of global buffers is determined by system
quotas (GBLPAGES and GBLPAGFIL), available physical memory,
and process VM quotas. Therefore, a low enough number of
global buffers, 250, is chosen as the default value because
that value can be accommodated by existing system settings.
The default maximum global buffer count per user, 5, is
determined by dividing the default value (250) by the
default number of users (50). Because these default values
are not good for every system, your system manager and
database administrator need to determine values for these
two global buffer parameters appropriate for your system
and database application.
2.5.3 Changes to the Optimizer for Rdb/VMS V4.2
This section describes changes to the optimizer for Rdb/VMS
V4.2. The following information was omitted from the V4.2
VAX Rdb/VMS New and Changed Features.
2.5.3.1 Setting Optimization Levels
With Rdb/VMS V4.2, you can request either the fast first
record retrieval strategy or total time retrieval strategy
of optimization for any given query. You can also set or
reset the defaults for either the fast first retrieval
strategy or total time retrieval strategy. Prior to Rdb/VMS
V4.2, you could request the fast first retrieval strategy
or total time retrieval strategy only for each given cursor
declaration.
The SQL SET OPTIMIZATION LEVEL statement is used to request
either the fast first or total time retrieval strategy.
Known Problems, Restrictions, and Other Notes 2-41
Use the following statement if the majority of the queries
in your session are not going to be closed before all the
result records are delivered:
SQL> SET OPTIMIZATION LEVEL 'TOTAL TIME';
Use the following statement if the majority of the queries
in your session are going to be terminated after examining
the first few records (that is, before all the result
records are delivered):
SQL> SET OPTIMIZATION LEVEL 'FAST FIRST';
The following statement sets the optimization back to the
default behavior (when no SET OPTIMIZATION LEVEL strategy
has been specified). The default behavior is to try the
fast first retrieval strategy first, then select the total
time retrieval strategy if it will retrieve the records
faster than the fast first strategy:
SQL> SET OPTIMIZATION LEVEL 'DEFAULT';
If different portions of your session need different
optimization levels, use the SQL SET OPTIMIZATION LEVEL
statements to set the desired level before each such
portion.
The following example shows the use of the SET OPTIMIZATION
LEVEL statement:
2-42 Known Problems, Restrictions, and Other Notes
$ DEFINE RDMS$DEBUG_FLAGS "S"
$ SQL :== $SQL$
$ SQL
SQL> ATTACH 'FILENAME PERSONNEL';
SQL> !
SQL> ! No optimization level has been selected. The optimizer
SQL> ! selects the fast first (FFirst) retrieval strategy to
SQL> ! retrieve the rows from the EMPLOYEES table in the
SQL> ! following query:
SQL> SELECT EMPLOYEE_ID, LAST_NAME
cont> FROM EMPLOYEES
cont> WHERE EMPLOYEE_ID IN ('00167', '00168');
Leaf#01 FFirst RDB$RELATIONS Card=19
BgrNdx1 RDB$REL_REL_NAME_NDX [1:1] Fan=8
Sort
Cross block of 2 entries
Cross block entry 1
Leaf#01 BgrOnly RDB$RELATION_FIELDS Card=71
BgrNdx1 RDB$RFR_REL_NAME_FLD_ID_NDX [1:1] Fan=8
Cross block entry 2
Get Retrieval by index of relation RDB$FIELDS
Index name RDB$FIELDS_NAME_NDX [1:1] Direct lookup
Leaf#01 FFirst EMPLOYEES Card=100
BgrNdx1 EMP_EMPLOYEE_ID [1:1...]2 Fan=17
EMPLOYEE_ID LAST_NAME
00167 Kilpatrick
00168 Nash
2 rows selected
SQL> !
SQL> ! Use the SET OPTIMIZATION LEVEL statement to specify that
SQL> ! you want the total time (BgrOnly) retrieval strategy to
SQL> ! be used. Note that when the previous query is executed
SQL> ! again, the total time (BgrOnly) retrieval strategy is
SQL> ! selected, instead of fast first:
SQL> SET OPTIMIZATION LEVEL 'TOTAL TIME';
SQL> SELECT EMPLOYEE_ID, LAST_NAME
cont> FROM EMPLOYEES
cont> WHERE EMPLOYEE_ID IN ('00167', '00168');
Leaf#01 BgrOnly EMPLOYEES Card=100
BgrNdx1 EMP_EMPLOYEE_ID [1:1...]2 Fan=17
EMPLOYEE_ID LAST_NAME
00167 Kilpatrick
00168 Nash
Known Problems, Restrictions, and Other Notes 2-43
2 rows selected
SQL> !
SQL> ! When the SET OPTIMIZATION LEVEL 'DEFAULT' statement
SQL> ! is specified, either the fast first or total time
SQL> ! strategy will be selected. The fast first strategy
SQL> ! will be tried first, then total time will be selected
SQL> ! if it will retrieve the rows faster than the fast
SQL> ! first strategy.
SQL> SET OPTIMIZATION LEVEL 'DEFAULT';
SQL> !
SQL> ! Because the fast first strategy is faster than the total
SQL> ! time strategy for this query, the fast first strategy
SQL> ! is used to retrieve the rows:
SQL> SELECT EMPLOYEE_ID, LAST_NAME
cont> FROM EMPLOYEES
cont> WHERE EMPLOYEE_ID IN ('00167', '00168');
Leaf#01 FFirst EMPLOYEES Card=100
BgrNdx1 EMP_EMPLOYEE_ID [1:1...]2 Fan=17
EMPLOYEE_ID LAST_NAME
00167 Kilpatrick
00168 Nash
2 rows selected
SQL>
You can also set the most commonly used optimization
level in your initialization procedure (the SQLINI.SQL
or RDOINI.RDO procedure that is automatically executed in
the beginning of each session).
You can change the optimization level default for a
particular query (not just for cursors as with previous
versions of Rdb/VMS) by specifying a SELECT statement with
the following format:
SQL> SELECT * FROM EMPLOYEES
cont> OPTIMIZE FOR FAST FIRST;
SQL>
SQL> SELECT * FROM EMPLOYEES
cont> OPTIMIZE FOR TOTAL TIME;
2-44 Known Problems, Restrictions, and Other Notes
2.5.3.2 Operators That Override the User-Selected Optimization
Level
Certain operators in a compiled query tree override the
user-selected optimization level for the entire tree branch
defined by the operator. For instance, SORT or TEMPORARY
TABLE tree nodes set TOTAL TIME optimization, FIRST_N node
sets FAST FIRST optimization. In Rdb/VMS V4.2, the list of
such nodes extends to:
o EXISTS operator
Sets FAST FIRST optimization
o Aggregates (AVG, COUNT, MAX, MIN, and SUM) with no GROUP
BY clause
Set TOTAL TIME optimization
2.5.3.3 Foreground-Background Competition Implemented in Fast
First Strategy
Sometimes when the fast first leaf strategy is selected
for record retrieval, no records or very few records are
selected. In this case, the foreground process of the leaf
node does many record fetches in attempt to deliver them,
but they all (or almost all) are rejected based on the
selection criterion.
In Rdb/VMS V4.2, a competition between the foreground
and background processes is implemented which terminates
the foreground fetches and switch to the background-only
strategy when the cost of the foreground fetches exceeds
half of the projected background cost. This feature reduces
unnecessary foreground cost and chooses the guaranteed
efficient strategy as soon as the chance of the foreground
success becomes unreasonably low.
The new competition mechanism provides better performance
in cases when the user has incorrectly chosen fast
first optimization or when the previously unknown data
distribution makes the total time optimization more
efficient than the fast first optimization.
Known Problems, Restrictions, and Other Notes 2-45
2.5.3.4 Dbkey List Sort in the Leaf Strategy
This new feature is a significant step in increasing
performance and concurrency for the background only,
fast first, and index only tactics of the dynamic leaf
optimization strategy. The feature modifies the dynamic
optimization behavior in three major areas:
1. The first background index scan is now always performed
to its end and therefore no switch to the sequential
table scan ever takes place.
This arrangement resolves the following concurrency
problem that occurred in previous versions of Rdb/VMS.
Before V4.2, the leaf node scanned its background
indexes and locked the records gradually, one index
page at a time. If another transaction had a page locked
for update, the scanning transaction simply waited until
the page was freed and then continued. However, upon
the decision to switch to the sequential scan, a lock
for the entire table was requested. In a heavy update
environment such lock escalation rarely succeeded and
the whole transaction had to roll back in the middle of
its execution.
With the new feature, the leaf strategy always locks the
table gradually and thus almost always succeeds.
2. After the background completion, the created dbkey list
is now always sorted in ascending dbkey order. This way
the problem of reading the same data page multiple times
during the final retrieval stage is fully resolved.
There is a substantial performance improvement (up
to a decimal order and more) for the queries that use
the leaf strategy and retrieve a significant amount
of records from a given table. However, if the table
is clustered along the last successfully processed
background index, a small slowdown (at the order of
1-10% or less) can be experienced. The reason for this
slowdown is that if the rows of the table are already
stored together in sorted order (because the table's
storage map specified PLACEMENT VIA INDEX), then the
sort operation to put the dbkeys in ascending order will
probably be unnecessary and will only add some time to
the retrieval time.
2-46 Known Problems, Restrictions, and Other Notes
In the future the sort overhead for clustering indexes
will be removed, but the overall system performance,
starting with V4.2, is going to be almost as good as if
all indexes were clustering. This raises the question
of whether clustering indexes remain useful at all. The
answer is yes. Clustering indexes provide a significant
performance advantage over nonclustering indexes for
queries that specify a range retrieval (this was also
true with previous versions of Rdb/VMS).
Even in those cases where the clustering index is used
for delivering a sorted order or when it contributes
directly to the fast first optimization, the clustering
performance advantage will still remain significant.
3. During the background execution, estimation of the final
retrieval I/Os is now measuring the number of table
page buffers to read, not the number of records to read.
The new estimation is significantly more precise than
the old one and thus contributes to a more precisely
measured competition that skips the unproductive indexes
in the multi-index background case.
To observe the final stage buffers estimate, set the
execution trace print ON with the following command:
$ DEFINE RDMS$DEBUG_FLAGS "SE"
At the end of some ~E lines, a new item, "#Bufs=n", is
printed, as in the following example:
~E#0002.01(1) BgrNdx1 EofData DBKeys=9 Fetches=1+0 RecsOut=0 #Bufs=3
2.5.4 RDMS$BIND_QG_CPU_TIMEOUT Logical Name Implemented in
Rdb/VMS V4.2
In Rdb/VMS V4.2 a new logical was introduced but not
documented.
The logical name RDMS$BIND_QG_CPU_TIMEOUT is used to
restrict the amount of CPU time used to optimize a query
for execution. If the query is not optimized and prepared
for execution before the CPU time limit is reached, an
error message is returned.
The default is unlimited CPU time for query compilation.
Dynamic SQL options are inherited from the compilation
qualifier.
Known Problems, Restrictions, and Other Notes 2-47
This logical name is translated at attach time and
supersedes all options specified in an application.
2.5.5 Minimum Value for the SPAM Interval Changed from 256 to 216
In V4.1 of Rdb/VMS, the minimum value for the SPAM interval
changed from 256 to 216 pages, allowing a user to define a
1-block page size and 1-block buffer size.
Except for the VAX Rdb/VMS Release Notes, no books in the
V4.1 documentation set included this information. This
information will be added to the next version of the VAX
Rdb/VMS SQL Reference Manual and the (via_rdb_gd_maint).
2.5.6 RDM$BIND_CKPT_TRANS_LIMIT Logical Name Changed to
RDM$BIND_CKPT_TRANS_INTERVAL
During V4.1 of Rdb/VMS, the logical name RDM$BIND_CKPT_
TRANS_LIMIT was changed to RDM$BIND_CKPT_TRANS_INTERVAL.
Some of the manuals in the Rdb/VMS V4.1 documentation set
reflected this change, but other manuals did not.
The Rdb/VMS V4.2 documentation set has been updated to use
the correct RDM$BIND_CKPT_TRANS_INTERVAL logical name.
2.5.7 Error in V4.1 VAX Rdb/VMS SQL Reference Manual, Section
D.6.1
In the V4.1 VAX Rdb/VMS SQL Reference Manual, Section
D.6.1, Page D-11 there is a documentation error. The second
paragraph incorrectly states:
" . . . containing the word SQLDA, followed by
two spaces."
This should read:
" . . . containing the word SQLDA2, followed by
two spaces."
This will be corrected in the next release of the VAX
Rdb/VMS SQL Reference Manual.
2-48 Known Problems, Restrictions, and Other Notes
2.5.8 Error in V4.1 VAX Rdb/VMS SQL Reference Manual, ALTER
DATABASE Statement
In the V4.1 VAX Rdb/VMS SQL Reference Manual, the
journal-fast-commit clause of the ALTER DATABASE statement
incorrectly shows the syntax:
NOCOMMIT TO JOURNAL OPTIMIZATION
The following syntax is correct:
NO COMMIT TO JOURNAL OPTIMIZATION
The correct syntax diagram appears in the Rdb/VMS V4.2
online help. The syntax diagram and text will be corrected
in the next release of the VAX Rdb/VMS SQL Reference
Manual.
2.5.9 Descriptions of Fields in RMS Record Definition Files
Produced by the RMU/ANALYZE Commands
This section describes the fields in the RMS record
definition files that are produced by specifying the
/BINARY_OUTPUT qualifier with the following commands:
o RMU/ANALYZE
o RMU/ANALYZE/INDEX
o RMU/ANALYZE/PLACEMENT
RMU/ANALYZE Command
The following RMU/ANALYZE command outputs the results
into an RMS record definition file called DB.RRD that is
compatible with the data dictionary:
$ RMU/ANALYZE/BINARY_OUTPUT=RECORD_DEFINITION=DB.RRD MF_PERSONNEL
$!
$! Display the DB.RRD file created by the previous command:
$ TYPE DB.RRD
DEFINE FIELD RMU$DATE DATATYPE IS DATE.
DEFINE FIELD RMU$AREA_NAME DATATYPE IS TEXT SIZE IS 32.
DEFINE FIELD RMU$STORAGE_AREA_ID DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$FLAGS DATATYPE IS SIGNED WORD.
Known Problems, Restrictions, and Other Notes 2-49
DEFINE FIELD RMU$TOTAL_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$EXPANDED_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$FRAGMENTED_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$EXPANDED_FRAGMENT_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$TOTAL_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$FRAGMENTED_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$FRAGMENT_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$PAGE_LENGTH DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$MAX_PAGE_NUMBER DATATYPE IS SIGNED LONGWORD.
DEFINE FIELD RMU$FREE_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$OVERHEAD_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$AIP_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$ABM_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$SPAM_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$INDEX_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$BTREE_NODE_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$HASH_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATES_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$OVERFLOW_BYTES DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$LOGICAL_AREA_ID DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$RELATION_ID DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$RECORD_ALLOCATION_SIZE DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$TOTAL_SPACE DATATYPE IS F_FLOATING.
DEFINE RECORD RMU$ANALYZE_AREA.
The following list describes each of the fields in the
DB.RRD record definition:
o RMU$DATE
Contains the date that the ANALYZE operation was
performed.
o RMU$AREA_NAME
Contains the name of the storage area that was analyzed.
o RMU$STORAGE_AREA_ID
Contains the area id of the storage area that was
analyzed.
o RMU$FLAGS
The three possible values in this field have the
following meanings:
- 3-this value indicates that data compression is
enabled for the logical area.
2-50 Known Problems, Restrictions, and Other Notes
- 1-this value indicates that data compression is not
enabled for the logical area.
- 0-this value indicates that the record is a storage
area record, not a logical area record.
o RMU$TOTAL_BYTES
Contains the total size of the data stored in the
logical area
o RMU$EXPANDED_BYTES
Contains the total size of the stored data in the
logical area after decompression
o RMU$FRAGMENTED_BYTES
Contains the number of bytes in the stored fragments
o RMU$EXPANDED_FRAGMENT_BYTES
Contains the number of bytes in the stored fragments
after decompression
o RMU$TOTAL_COUNT
Contains the total number of records stored
o RMU$FRAGMENTED_COUNT
o Contains the number of records that are fragmented
o RMU$FRAGMENT_COUNT
Contains the number of stored fragments
o RMU$PAGE_LENGTH
Contains the length in bytes of a database page in the
storage area
o RMU$MAX_PAGE_NUMBER
Contains the page number of the last initialized page in
the storage area
o RMU$FREE_BYTES
Contains the number of free bytes in the storage area
o RMU$OVERHEAD_BYTES
Contains the number of bytes used for overhead in the
storage area
o RMU$AIP_COUNT
Known Problems, Restrictions, and Other Notes 2-51
Contains the number of AIP pages in the storage area
o RMU$ABM_COUNT
Contains the number of ABM pages in the storage area
o RMU$SPAM_COUNT
Contains the number of SPAM pages in the storage area
o RMU$INDEX_COUNT
Contains the number of index records in the storage area
o RMU$BTREE_NODE_BYTES
Contains the number of bytes for sorted indexes in the
storage area
o RMU$HASH_BYTES
Contains the number of bytes for hashed indexes in the
storage area
o RMU$DUPLICATES_BYTES
Contains the number of bytes for duplicate key values
for sorted indexes in the storage area
o RMU$OVERFLOW_BYTES
Contains the number of bytes for hash bucket overflow
records in the storage area
o RMU$LOGICAL_AREA_ID
Contains the logical area id of the logical area that
was analyzed
o RMU$RELATION_ID
Contains the record type of the row in the logical area
that was analyzed
o RMU$RECORD_ALLOCATION_SIZE
Contains the size of a row when the table was initially
defined
o RMU$TOTAL_SPACE
Contains the number of bytes available for storing user
data in the logical area (used space + free space +
overhead)
2-52 Known Problems, Restrictions, and Other Notes
RMU/ANALYZE/INDEX Command
The following RMU/ANALYZE/INDEX command produces an RMS
record definition file called INDEX.RRD that is compatible
with the data dictionary:
$ RMU/ANALYZE/INDEX/BINARY_OUTPUT=RECORD_DEFINITION=INDEX.RRD MF_PERSONNEL
$!
$! Display the INDEX.RRD file created by the previous command:
$ TYPE INDEX.RRD
DEFINE FIELD RMU$DATE DATATYPE IS DATE.
DEFINE FIELD RMU$INDEX_NAME DATATYPE IS TEXT SIZE IS 32.
DEFINE FIELD RMU$RELATION_NAME DATATYPE IS TEXT SIZE IS 32.
DEFINE FIELD RMU$LEVEL DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$FLAGS DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$USED DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$AVAILABLE DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_USED DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_AVAILABLE DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$KEY_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DATA_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_KEY_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_DATA_COUNT DATATYPE IS F_FLOATING.
DEFINE RECORD RMU$ANALYZE_INDEX.
The following list describes each of the fields in the
INDEX.RRD record definition:
o RMU$DATE
Contains the date that the ANALYZE operation was
performed
o RMU$INDEX_NAME
Contains the name of the index that was analyzed
o RMU$RELATION_NAME
Contains the name of the table for which the index is
defined
o RMU$LEVEL
Contains the maximum number of index levels
o RMU$FLAGS
Known Problems, Restrictions, and Other Notes 2-53
The four possible values in this field have the
following meanings:
- 3-this value indicates the index is a unique and
hashed index
- 2-this value indicates the index is a hashed but not
unique index
- 1-this value indicates the index is a unique sorted
index
- 0-this value indicates the index is a sorted but not
unique index
o RMU$COUNT
Contains the number of index nodes
o RMU$USED
Contains the amount of available space that is used
o RMU$AVAILABLE
Contains the amount of initially available space in the
index records
o RMU$DUPLICATE_COUNT
Contains the number of duplicate records
o RMU$DUPLICATE_USED
Contains the amount of available space used in the
duplicate records
o RMU$DUPLICATE_AVAILABLE
Contains the amount of initially available space in the
duplicate records
o RMU$KEY_COUNT
Contains the number of keys
o RMU$DATA_COUNT
Contains the number of records
o RMU$DUPLICATE_KEY_COUNT
Contains the number of duplicate keys
o RMU$DUPLICATE_DATA_COUNT
2-54 Known Problems, Restrictions, and Other Notes
Contains the number of duplicate records
RMU/ANALYZE/PLACEMENT command
The following RMU/ANALYZE/PLACEMENT command outputs
the results into an RMS record definition file called
PLACEMENT.RRD that is compatible with the data dictionary:
$ RMU/ANALYZE/PLACEMENT/BINARY_OUTPUT=RECORD_DEFINITION=PLACEMENT.RRD -
_$ MF_PERSONNEL
$!
$! Display the PLACEMENT.RRD file created by the previous command:
$ TYPE PLACEMENT.RRD
DEFINE FIELD RMU$DATE DATATYPE IS DATE.
DEFINE FIELD RMU$INDEX_NAME DATATYPE IS TEXT SIZE IS 32.
DEFINE FIELD RMU$RELATION_NAME DATATYPE IS TEXT SIZE IS 32.
DEFINE FIELD RMU$LEVEL DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$FLAGS DATATYPE IS SIGNED WORD.
DEFINE FIELD RMU$COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$KEY_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_KEY_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DATA_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$DUPLICATE_DATA_COUNT DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$TOTAL_KEY_PATH DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$TOTAL_PAGE_PATH DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$TOTAL_BUFFER_PATH DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$MAX_KEY_PATH DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$MAX_PAGE_PATH DATATYPE IS F_FLOATING.
DEFINE FIELD RMU$MIN_BUF_PATH DATATYPE IS F_FLOATING.
DEFINE RECORD RMU$ANALYZE_PLACEMENT.
The following list describes each of the fields in the
PLACEMENT.RRD record definition:
o RMU$DATE
Contains the date that the ANALYZE operation was
performed
o RMU$INDEX_NAME
Contains the name of the index that was analyzed
o RMU$RELATION_NAME
Contains the name of the table for which the index is
defined
o RMU$LEVEL
Known Problems, Restrictions, and Other Notes 2-55
Contains the maximum number of index levels
o RMU$FLAGS
The four possible values in this field have the
following meanings:
- 3-this value indicates the index is a unique and
hashed index.
- 2-this value indicates the index is a hashed but not
unique index.
- 1-this value indicates the index is a unique sorted
index.
- 0-this value indicates the index is a sorted but not
unique index.
o RMU$COUNT
Contains the number of index nodes
o RMU$DUPLICATE_COUNT
Contains the number of duplicate records
o RMU$KEY_COUNT
Contains the number of keys
o RMU$DUPLICATE_KEY_COUNT
Contains the number of duplicate keys
o RMU$DATA_COUNT
Contains the number of records
o RMU$DUPLICATE_DATA_COUNT
Contains the number of duplicate records
o RMU$TOTAL_KEY_PATH
Contains the total number of keys touched to access all
the records
o RMU$TOTAL_PAGE_PATH
Contains the total number of pages touched to access all
the records
o RMU$TOTAL_BUFFER_PATH
Contains the total number of buffers touched to access
all the records
2-56 Known Problems, Restrictions, and Other Notes
o RMU$MAX_KEY_PATH
Contains the largest number of keys touched to access
any of the records
o RMU$MAX_PAGE_PATH
Contains the largest number of pages touched to access
any of the records
o RMU$MIN_BUF_PATH
Contains the smallest number of buffers touched to
access any of the records
2.5.10 Select-expr Argument Incorrectly Documented in CREATE VIEW
Statement
In the V4.1 VAX Rdb/VMS SQL Reference Manual, the
documentation for the select-expr argument in the CREATE
VIEW statement is incomplete. The documentation should
read:
A select expression that defines which columns and rows of
the specified tables SQL includes in the view. The select
expression for a non-multischema database can name only
tables in the same schema as the view. A select expression
for a multischema database can name a table in any schema
in the database; the schema need not be in the same catalog
as the view being created.
This will be fixed in the next release of the VAX Rdb/VMS
SQL Reference Manual.
2.5.11 Initializing the Parameter in the PREPARE Statement
The V4.1 VAX Rdb/VMS SQL Reference Manual states in
the Usage Notes to the PREPARE statement that you must
initialize the second parameter to zero. This is incorrect.
However, if you use the statement-id parameter, and if
that parameter is an integer, then you must explicitly
initialize that integer to zero before executing the
PREPARE statement.
This error will be corrected in the next release of the VAX
Rdb/VMS SQL Reference Manual.
Known Problems, Restrictions, and Other Notes 2-57
2.5.12 Dropping Multiple Triggers in Single Command Not Permitted
The V4.1 VAX Rdb/VMS SQL Reference Manual indicates that
you can drop multiple triggers in a single command. This
is incorrect. You can only drop one trigger at a time. This
error will be fixed in the next release of the VAX Rdb/VMS
SQL Reference Manual.
2.5.13 SQL Reference Manual Refers to Nonexistent Statement
Section 3.2.5 in the V4.1 VAX Rdb/VMS SQL Reference Manual
contains a reference to an interactive statement, SET
ANSI AUTHORIZATION, that does not exist. This reference
will be deleted in the next version of the VAX Rdb/VMS SQL
Reference Manual.
2.5.14 Query Governor Logicals Incorrectly Documented
The V4.1 VAX Rdb/VMS SQL Reference Manual incorrectly
documented the logical names for the query governor as:
o RDM$BIND_QG_TIMEOUT
o RDM$BIND_QG_REC_LIMIT
The correct logical names are:
o RDMS$BIND_QG_TIMEOUT
o RDMS$BIND_QG_REC_LIMIT
This will be corrected in the next release of the VAX
Rdb/VMS SQL Reference Manual.
2.5.15 Cannot Specify Snapshot File Name for Single-File Database
The documentation about snapshot files for a single-file
database is misleading.
You cannot specify a snapshot file name for a single-file
database. This restriction applies to the following SQL
statements and RMU commands:
o CREATE DATABASE
o ALTER DATABASE
o IMPORT
o RMU/MOVE_AREA
o RMU/RESTORE
2-58 Known Problems, Restrictions, and Other Notes
When you create a snapshot file, Rdb/VMS does not store the
file specification of the snapshot file. Instead, it uses
the file specification of the root file (.RDB) to determine
the file specification of the snapshot file.
If you want to place the snapshot file on a different
device or directory, Digital recommends that you create
a multifile database. However, you can work around the
restriction by defining a search list for a concealed
logical name.
To create a database with a snapshot file on a different
device or directory, define a search list using a concealed
logical name. Specify the location of the root file
as the first item in the search list. When you create
the database, use the logical name for the directory
specification. Then, copy the snapshot file to the second
device. The following example demonstrates the workaround:
$ ! Define a concealed logical name.
$ DEFINE /TRANS=CONCEALED/SYSTEM TESTDB USER$DISK1:[DATABASE], -
_$ USER$DISK2:[SNAPSHOT]
$
$ SQL
SQL> ! Create the database.
SQL> !
SQL> CREATE DATABASE FILENAME TESTDB:TEST;
SQL> EXIT
$ !
$ ! Copy the snapshot file to the second disk.
$ COPY USER$DISK1:[DATABASE]TEST.SNP USER$DISK2:[SNAPSHOT]TEST.SNP
$ !
$ ! Delete the snapshot file from the original disk.
$ DELETE USER$DISK1:[DATABASE]TEST.SNP;
You can use the same workaround with the all SQL statements
and RMU commands to which the restriction applies.
2.5.16 DROP TABLE CASCADE Drops Associated Storage Maps
The following information was omitted from the V4.1 VAX
Rdb/VMS SQL Reference Manual and V4.1 SQL help file:
The SQL DROP TABLE CASCADE statement also drops storage
maps associated with the table.
Known Problems, Restrictions, and Other Notes 2-59
2.5.17 .OAIJ File Can Be Displayed Using the
RMU/DUMP/AFTER_JOURNAL Command
The following information on .OAIJ files was omitted from
the V4.1 VAX Rdb/VMS RMU Reference Manual and V4.1 RMU help
file.
You can use the RMU/DUMP/AFTER_JOURNAL command to display
an optimized after-image journal (.OAIJ) file in ASCII
format.
The documentation did mention that you can use the RMU/DUMP
/AFTER_JOURNAL command to display an after-image journal
(.AIJ) file in ASCII format and this is still true.
2.5.18 CAST Function Documentation Errors
The CAST function documentation in the VAX Rdb/VMS SQL
Reference Manual for V4.1 is incomplete and misleading.
The CAST function syntax is included in the date-time-
function diagram Section 3.6. The use of CAST is not
limited to translating date-time columns into other data
types. CAST can be used to translate the data type of a
column from any data type (except LIST OF BYTE VARYING)
into any other data type (except LIST OF BYTE VARYING).
If you specify the name of a domain in the AS clause,
Rdb/VMS uses the current data type of that domain as the
output data type of the CAST function. The domain-name
clause was omitted from the date-time-function diagram in
VAX Rdb/VMS SQL Reference Manual, Section 3.6.
These errors are corrected in the V4.1 SQL help. The
corrected syntax diagram for the CAST function also appears
in the Value Expressions section of the "SQL: New and
Changed Features" chapter in the V4.2 VAX Rdb/VMS New and
Changed Features.
The following example uses the data type of the domain
STANDARD_DATE to format the BIRTHDAY field. You can alter
the data type of STANDARD_DATE from DATE VMS to DATE ANSI
without changing the SELECT statement you use to access the
data. For example:
2-60 Known Problems, Restrictions, and Other Notes
SQL> CREATE DOMAIN STANDARD_DATE DATE VMS;
SQL>
SQL> SELECT LAST_NAME, FIRST_NAME, CAST(BIRTHDAY AS STANDARD_DATE)
cont> FROM EMPLOYEES;
SQL>
SQL> ALTER DOMAIN STANDARD_DATE DATE ANSI;
SQL> SELECT LAST_NAME, FIRST_NAME, CAST(BIRTHDAY AS STANDARD_DATE)
cont> FROM EMPLOYEES;
2.5.19 The VAX Rdb/VMS RMU Reference Manual Is Unclear on When
You Can Optimize .AIJ Files and Incorrectly States You
Cannot Optimize an .AIJ File on Tape
The VAX Rdb/VMS RMU Reference Manual in Section 1.25 states
the following:
You cannot link the optimization procedure with the backup
procedure. You must optimize before or after a backup
operation.
These two sentences read more clearly as follows:
You cannot optimize an .AIJ file in the process of backing
it up. In practice, you must first back up the .AIJ
file using the RMU/BACKUP/AFTER_JOURNAL command and then
optimize it.
You can optimize an inactive .AIJ file that results, for
example, from changing the name of the .AIJ file prior to
a database backup operation. This process creates a new
active, primary .AIJ file and makes the previous .AIJ file
inactive. After optimizing the inactive .AIJ file, you can
use the VMS BACKUP command to backup the .OAIJ file. Note
that you cannot optimize an active, primary .AIJ file.
The VAX Rdb/VMS RMU Reference Manual, Section 1.25, also
states the following:
However, optimizing after a backup operation will not work
if the .AIJ file was backed up to tape. You cannot reach
the .AIJ file from tape during an optimization operation.
These two sentences are incorrect and should be replaced
with the following statement:
Known Problems, Restrictions, and Other Notes 2-61
The RMU/OPTIMIZE/AFTER_JOURNAL command can read an .AIJ
file on disk or a backed up .AIJ file on disk or on tape
that is in the OLD_RMS format and writes the optimized .AIJ
file (.OAIJ) to disk or to tape in either OLD_RMS or NEW_
TAPE format.
This will be corrected in the next version of the VAX
Rdb/VMS RMU Reference Manual.
2.5.20 Clarification of How to Use the /[NO]CLUSTER and /[NO]WAIT
Qualifiers for the RMU/CLOSE Command
The explanation of the following /[NO]CLUSTER and /[NO]WAIT
qualifiers for the RMU/CLOSE command supersedes the
explanation found in the V4.1 VAX Rdb/VMS RMU Reference
Manual:
/CLUSTER
/NOCLUSTER
Specifying the /CLUSTER qualifier causes RMU to attempt to
close a database on all nodes in a VAXcluster environment
that currently have the database open. Specifying /CLUSTER
is similar to issuing the RMU/CLOSE command on every node
in the cluster. Specifying /NOCLUSTER causes RMU to close a
database only on the cluster node from which you issue the
RMU/CLOSE command.
The default is /CLUSTER if you specify the /WAIT qualifier.
The default is /NOCLUSTER if you specify the /NOWAIT
qualifier.
You can use the /[NO]CLUSTER and /[NO]WAIT qualifiers
together in the following four ways:
o /CLUSTER and /WAIT
When you specify /CLUSTER and /WAIT, the RMU/CLOSE
command closes the database on every node in the
cluster, even if the database is not opened on the node
from which the command was issued. Specifying /CLUSTER
and /WAIT is equivalent to issuing the RMU/CLOSE
/NOCLUSTER/WAIT command on every node in the cluster.
Because you specified the /WAIT qualifier, the RMU/CLOSE
/CLUSTER/WAIT command closes and recovers the database
on every node in the cluster before the DCL prompt is
returned to you.
2-62 Known Problems, Restrictions, and Other Notes
o /CLUSTER and /NOWAIT
When you specify /CLUSTER and /NOWAIT, the RMU/CLOSE
command attempts to close the database on every node in
the cluster. If the database is not opened on the node
from which the RMU command was issued, the command will
not be able to close the database on any node, and you
will receive the following error message:
%RDMS-F-CANTCLOSEDB, database could not be closed as requested
-RDMS-F-DBNOTACTIVE, database is not being used
%RMU-W-FATALERR, fatal error on DISK1:[USER1]DATABASE.RDB;1
Because you used the /NOWAIT qualifier, the database
may not yet be closed on one or more nodes when the DCL
prompt is returned to you. With /NOWAIT, you can receive
SYS-F-ACCONFLICT errors when you attempt to access a
database after you issued the RMU/CLOSE/CLUSTER/NOWAIT
command and the DCL prompt is returned, but before the
monitor has closed the database on all nodes in the
cluster.
o /NOCLUSTER and /WAIT
When you specify /NOCLUSTER and /WAIT, the database
is closed only on the node from which you issued the
command, regardless of whether or not the database is
opened on other nodes.
Because the /WAIT qualifier is specified, the database
is closed and recovered on the node from which you
issued RMU/CLOSE/NOCLUSTER/WAIT command before the DCL
prompt is returned to you.
o /NOCLUSTER and /NOWAIT
When you specify /NOCLUSTER and /NOWAIT, the database
is closed only on the node from which you issued the
command, regardless of whether or not the database is
opened on other nodes.
Because you used the /NOWAIT qualifier, the database
may not yet be closed on the node from which you issued
the command when the DCL prompt is returned to you. With
/NOWAIT, you can receive SYS-F-ACCONFLICT errors when
you attempt to access a database on the node from which
you issued the RMU/CLOSE/NOCLUSTER/NOWAIT command after
the DCL prompt is returned, but before the monitor has
closed the database.
Known Problems, Restrictions, and Other Notes 2-63
/WAIT
/NOWAIT
Specifying the /WAIT qualifier causes RMU to close and
recover the database before the DCL prompt is returned to
you.
The default is /NOWAIT. With the /NOWAIT qualifier, the
database may not be closed when the DCL prompt is returned
to you. With /NOWAIT, you can receive SYS-F-ACCONFLICT
errors when you attempt to accesss a database after
you issued the RMU/CLOSE command and the DCL prompt is
returned, but before the monitor has closed the database.
2.5.21 Tape Requests and Problems Are Reported Only to the Tape
Operator for RMU Commands Issued from a Batch Job
When any of the following RMU commands are issued from a
batch job, tape requests and problems are reported to the
tape operator:
o RMU/BACKUP
o RMU/BACKUP/AFTER_JOURNAL
o RMU/DUMP/BACKUP_FILE
o RMU/OPTIMIZE/AFTER_JOURNAL
o RMU/RECOVER
o RMU/RESTORE
o RMU/RESTORE/ONLY_ROOT
The reason tape requests and problems are reported to the
tape operator is because these problems often require
manual intervention; and if the command was issued from
a batch job, the only person who may be available is the
operator.
When these commands are issued interactively and a tape
request or problem arises, RMU notifies the person who
issued the command through the I/O channel assigned to
the logical name SYS$COMMAND. After being notified of the
problem, the user who issued the command can either fix
the problem (if the user has access to the tape drive) or
contact the tape operator to ask the tape operator to fix
the problem. You can use the following REQUEST command to
notify the tape operator:
2-64 Known Problems, Restrictions, and Other Notes
$ REQUEST/REPLY/TO=TAPES -
_$ "Please Write Enable tape ATOZBG on drive $255$MUA6:"
2.5.22 Buffer Management Changes for V4.0
The following information was not documented in the V4.0
VAX Rdb/VMS Guide to Database Maintenance and Performance
or the V4.1 VAX Rdb/VMS Guide to Database Maintenance.
In Rdb/VMS V3.1, one queue of buffer control blocks was
maintained in a least recently used (LRU) fashion. The
least recently used buffer in the queue (the one at the
tail) was chosen as the buffer to be used to read another
buffer of pages, whether or not the buffer was marked.
One disadvantage to this scheme was the need to do a
synchronous write operation when a marked (updated) buffer
had to be cleaned out to read a new buffer. Synchronous
write operations force the disk head to move to the
appropriate cylinder on disk and also make the user process
stall during the write operation. Asynchronous write
operations are better than synchronous write operations
because the user process is not stalled. In addition, if
a number of write operations are issued asynchronously
at the same time, Rdb/VMS reduces the disk head movement
by performing the write operations in the optimal order.
Because the time needed to move the disk head is the most
significant expense in an I/O operation, this factor is
important. For these reasons, the buffer management scheme
was changed in Rdb/VMS V4.0.
Rdb/VMS V4.0 has two queues of buffer control blocks. One
queue corresponds to a set of marked buffers and the other
queue corresponds to a set of unmarked buffers. Whenever
a buffer is marked (updated), it is moved to the head of
the marked queue. Similarly, whenever a buffer is unmarked
(written to disk), it is moved to the head of the unmarked
queue. Therefore, each queue is managed in an LRU fashion,
but there is no global LRU function for the entire buffer
pool.
Whenever a buffer is to be chosen, the unmarked queue is
searched first from the end (in an LRU fashion) and then
the marked queue is searched. By postponing the write
operations, Rdb/VMS can gather a good batch and flush the
batch asynchronously at commit time. Although this change
Known Problems, Restrictions, and Other Notes 2-65
usually removes the disadvantages previously described for
V3.1, occasionally the problem remains.
The following examples demonstrate situations in which this
two-buffer queue management system improves performance and
situations in which it does not. For these examples, assume
that there is only one page per buffer.
The first process is updating 50 pages, and is running
an application with 100 buffers. In Rdb/VMS V3.1, this
could have resulted in 50 synchronous write operations.
The process would have stalled 50 times, for the duration
of 50 I/O operations in total. In Rdb/VMS V4.0, the 50
marked buffers remain unmarked until the end of the
transaction, when they are written in one batch during
commit processing. Because the batch write operation lets
Rdb/VMS optimize the write operations in Rdb/VMS V4.0, the
process stalls only once for a total time corresponding to
approximately 10 buffers. The two-buffer queue management
system provided with Rdb/VMS V4.0 improves performance for
this process.
The second process is also running an application with 100
buffers. This process is updating records on 100 pages, and
then reading the records repeatedly. In V3.1, this could
have resulted in 100 synchronous write operations. However,
because the 50 pages are soon cached in the buffer pool,
they involve no read operations. In V4.0, after the 100
pages are updated, all the buffers are marked. Then for
every read operation, only one buffer is used. The two-
buffer queue management system drastically increases the
number of data file read operations and adversely affects
performance for this process.
To clarify the explanation, consider another case. A
third process is updating 100 pages and then reading 100
pages. In Rdb/VMS V3.1, this would have resulted in 100
synchronous write operations and then 100 read operations.
In V4.0, after the first 100 update operations, all buffers
are marked. Then Rdb/VMS uses only one buffer to read the
100 buffers. Thus, Rdb/VMS V4.0 still performs 100 read
I/O operations, but submits the 100 asynchronous write
operations as a batch at commit time. The two-buffer queue
management system improves performance for this process.
2-66 Known Problems, Restrictions, and Other Notes
In general, the two-queue buffer management system improves
overall system performance and response time for processes.
However, the performance will be worse when both of the
following conditions are true:
o When the number of pages being updated is greater than
the number of buffers
o When a number of pages are read repeatedly after being
updated
There are also more complicated scenarios in which this
two-queue buffer management scheme can result in poorer
performance. Whether your application is affected adversely
by the two-queue buffer management scheme depends on the
pattern of read and write operations to the data pages.
The mandatory update for Rdb/VMS V4.0 (V4.0A) improved the
poor performance of the V4.0 two-queue buffer management
scheme, although performance continued to be slower in
Rdb/VMS V4.0 than it was under Rdb/VMS V3.1; this problem
was fixed in Rdb/VMS V4.1.
2.5.23 Logical Name RDM$MON_USERNAME Is Documented Only in V4.1
Release Notes
The logical name RDM$MON_USERNAME, new for Rdb/VMS V4.1,
is not documented in any of the books in the V4.1 or V4.2
documentation sets except the VAX Rdb/VMS Release Notes.
The logical name RDM$MON_USERNAME designates the name of
the user whose quotas the monitor process, upon startup, is
to inherit.
During normal system startup, an RMU/MONITOR/START command
is performed. If global buffers are enabled, the default
PGFLQUOTA of 20,480 (the original process quotas) may not
be sufficient for the monitor process to be created if many
global buffers are used.
When a monitor is started using the RMU/MONITOR START
command, the quota limit that the monitor process uses
is determined as the larger of three factors: a hardcoded
"minimum-necessary" value, the quota value from the
designated user, or the quota value from the user who is
performing the startup.
Known Problems, Restrictions, and Other Notes 2-67
For example, the hardcoded minimum value of the PGFLQUOTA
process quota is 20,480. If the quota value for the user
SYSTEM is 40,960 and the quota value for the user starting
the monitor is 30,720, then the monitor is started with a
PGFLQUOTA of 40,960.
The hardcoded minimum values for each monitor quota are as
follows:
ASTLM 256
BIOLM 256
BYTLM 20,480
DIOLM 256
ENQLM 8,192
FILLM 1,024
PGFLQUOTA 20,480
PRCCNT 64
TQCNT 64
WSEXTENT 512
WSQUOTA 512
The following example shows how to use the RDM$MON_USERNAME
logical name to specify that the user GOOD_QUOTAS can be
defined so that the monitor process can inherit this user's
quotas according to the alogrithm previously mentioned.
$ DEFINE RDM$MON_USERNAME GOOD_QUOTAS
2.5.24 Maintenance Operations for and Characteristics of WORM
Media Described Only in the V4.1 Release Notes
Section 2.5.24.1 and Section 2.5.24.2 describe maintenance
operations for and some characteristics of WORM optical
disk drives; the information is described in the VAX
Rdb/VMS Release Notes and does not appear elsewhere in
the V4.1 documentation.
2.5.24.1 Maintenance Operations on WORM Media
Beginning with V4.1, Rdb/VMS supports WORM (write-once,
read-many) optical disk drives as storage media for storing
list (segmented string) data in write-once storage areas.
A WORM optical disk offers a relatively inexpensive way to
store large amounts of stable database list data compared
to other storage media. Optical WORM media can be used
in two ways to efficiently store database list data. Each
2-68 Known Problems, Restrictions, and Other Notes
method permits a slightly different maintenance strategy.
These storage strategies can be described as follows:
o Stable list data can be archived to WORM media.
List data that is either permanently stable or stable
for long periods of time can be archived and moved from
a read/write storage area residing on a read/write disk
device to a write-once storage area on a WORM device
for read-only access. Permanent list data, such as
bank transaction records, can be permanently archived.
List data that needs to be periodically updated can be
moved back to a read/write storage area on a read/write
disk device, updated, and then archived again to the
WORM media. This process is repeated as necessary.
For example, an information catalog might be made
available for read-only access on a WORM device and
updated quarterly, biannually, or annually.
o Stable list data can be written continuously to WORM
media.
Stable list data can be written continuously to write-
once storage areas on WORM media. In this instance, list
data is always written to the next unwritten block on
the WORM media. An example of this type of application
is a database containing one or more archive storage
areas in which list data is continuously archived and
written to these write-once storage areas. The list
data becomes permanently stable information along with
the list data already within the storage area on the
WORM media. An example of this type of application is
storing image data. Some image data can be relatively
stable and each image may require 10 megabytes or more
of storage space. It is costly to store such list data
in read/write or read-only storage areas on read/write
disk media. In addition, if the images are stable and
only read from a storage medium, it is feasible to
permanently store these images in write-once storage
areas on WORM media. New images can be continuously
archived to the WORM media for efficient, cost-effective
storage and use.
Known Problems, Restrictions, and Other Notes 2-69
With the ability to store list data in write-once storage
areas on WORM media, you perform maintenance operations
on the WORM area as you would with any other read/write or
read-only storage area in your database. These operations
include:
o Verifying the data in the WORM area
o Backing up the WORM area
o Restoring and recovering WORM areas
o Displaying the contents of WORM areas
o Moving storage areas containing list data to and from
WORM media
o Copying databases that contain WORM areas with list data
The maintenance strategies you develop for list data
residing on WORM media will depend on whether the list
data within write-once storage areas on WORM media are
permanently stable, stable for long periods of time, or
whether new list data are continuously being archived
to the write-once storage areas on WORM media. As the
system manager, you should periodically back up the entire
database, including all write-once storage areas on all
WORM optical disks. Between backup operations of the entire
database, periodically back up only the storage areas that
contain new and updated data and exclude all permanently
stable write-once storage areas on the WORM media and read-
only storage areas on read/write disks, as this data is
unchanged. Because the unchanged data can be restored from
a full and complete backup of the entire database, this
data need not be backed up as often as new and changed
data.
As an alternative, if new list data is continuously
archived to write-once storage areas on WORM media, then
these areas should be backed up as frequently as any
read/write storage areas in your database. You could back
up each WORM area separately or always back up all WORM
areas with all read/write areas in each backup operation.
Which strategy you select depends upon the relative size
of the entire database, the volume of new data added or
updated each day, the type of database application, how
available the database must be, the time required to backup
2-70 Known Problems, Restrictions, and Other Notes
the entire database, and the time required to restore and
recover the database in the event of a failure. These
factors are weighed against the time required and the
relative difficulty involved in restoring the database
if there is a major problem and, if after-image journaling
is enabled, the time it might take to roll forward to the
most current transaction.
These strategies are similar to those described for read-
only storage areas in the backup and restore chapters of
the VAX Rdb/VMS Guide to Database Maintenance.
2.5.24.2 WORM Media, Characteristics, and Assumptions
Rdb/VMS supports WORM media that allows only one write
operation to a block on the media. Thus, the WORM media
blocks that are written to cannot be used again. This means
the following:
o Pages are allocated and initialized as each process
needs them.
Because of the write-once characteristic of WORM media,
pages are allocated and initialized as each process
needs them. The process of initializing a page requires
that information (such as the page header, the page
tail, the system record, the TSN index, and the Line
index) be written to the page. Once written to, the
page cannot be written to again. Hence, the pages are
initialized as needed. This contrasts with read/write
storage areas on read/write disk media, for which all
pages are allocated and initialized when the area is
first created or later extended.
o SPAM pages are not used in write-once storage areas on
WORM media.
Because of the write-once characteristic of WORM
media, the storage algorithm used to store lists on
WORM media always stores the list data on the next
sequential unwritten page within the storage area.
Because SPAM pages are not necessary in this type of
storage algorithm, SPAM pages are not used. However,
space is allocated for SPAM pages in write-once storage
areas to facilitate creating SPAM pages again when a
write-once storage area is moved to a read/write storage
area on read/write disk media. Write-once storage areas
Known Problems, Restrictions, and Other Notes 2-71
on WORM media must be of mixed page format because SPAM
pages are required in uniform page format storage areas.
The smallest amount of space used in a write operation
to WORM media is 1024 bytes (2 blocks). To minimize
wasted space when writing lists to WORM media, specify
the page size for the storage area as an even number of
blocks.
Because storage area files on WORM media are like any
other database storage area file, they can be created and
extended on WORM media as well. Storage area pages are
initialized as they are allocated by each user process. Any
unwritten pages within a write-once storage area on WORM
media are always read as zero-filled pages.
Because list data written to WORM media cannot be undone
when a transaction aborts, it is not necessary to write
before-image information for the WORM media to the .RUJ
file. Rollback of a transaction only requires undoing the
pointers to the aborted list data on the WORM media. In
this case, if the transaction aborts, information that
is written to the WORM media remains there and is simply
ignored. Uninitialized pages in write-once storage areas on
WORM media are called WORM holes. These uninitialized pages
on WORM media are read as zeros. Because read/write media
only work with initialized pages, an uninitialized page
occurring on a read/write device in a write-once storage
area appears as corrupt data to Rdb/VMS. Magnetic media
are not supported for storing write-once storage areas
because these WORM holes are not filled when transactions
are aborted, and are always detected by RMU utilities as
corrupt data in the database. RMU utilities are enhanced
in Rdb/VMS V4.1 to ignore these WORM holes for write-
once storage areas on WORM media. When WORM storage
area information is written to read/write media with the
RMU/MOVE_AREA or RMU/RESTORE command, the WORM holes are
synthesized as empty, zero-filled pages and later verify on
the read/write media with no problems.
If after-image journaling is enabled and a transaction
storing a list commits, the committed transaction is
also written to the .AIJ file. When planning applications
that use large amounts of list data in which the lists
are also very large, you should place the .AIJ file on a
large capacity disk drive that has the sufficient space
2-72 Known Problems, Restrictions, and Other Notes
to store these journal records. Similarly, you should plan
to frequently or continuously back up the .AIJ file to
magnetic tape to keep from exceeding the storage capacity
of the disk drive. Furthermore, you should consider this
information when you plan your by-area backup strategy.
When you create a storage area on WORM media to contain
list data, you must ensure that the snapshot area remains
as a read/write area residing on read/write media. A
snapshot file must neither be given the WORM attribute
nor moved to WORM media.
Deleting segmented string data in WORM areas is
accomplished by making the pointer null. When a WORM area
is moved to read/write media, the space containing the
deleted string data is not reclaimed. Only an export/import
operation, or a REORGANIZE clause performed in an ALTER or
a CHANGE STORAGE MAP statement, would reclaim this space.
Table 2-1 shows the compatibility between storage area
attributes and disk drive types:
Table 2-1 Compatibility Between Storage Area Attributes and
__________Disk_Drive_Types_________________________________
Storage Disk Drive Type
Area _________________________________________________
Type______RW______WORM____RO_______________________________
RW Yes No No
WORM No[1] Yes No
RO Yes Yes Yes
[1]No,_because_the_uninitialized_pages_are_not_zero-filled_
and will be interpreted as corrupt.
Key to Disk Drive Types
RW-Read/Write
WORM-Write-Once, Read-Many
_RO-Read-Only______________________________________________
________________________ Note ________________________
If the device driver makes a WORM optical disk device
appear as a read/write disk device, then the user can
Known Problems, Restrictions, and Other Notes 2-73
decide whether to place read/write storage areas on a
WORM optical disk device.
______________________________________________________
2.5.25 Database Key Recommendation Is Clarified
Section 3.6.2 of the VAX Rdb/VMS SQL Reference Manual
states that applications planning to use database keys
should declare databases with the DBKEY SCOPE IS ATTACH
clause. This statement is misleading. The DBKEY SCOPE IS
ATTACH clause should be used only by applications that need
to keep DBKEYs across transaction boundaries.
Some space on the page will not be reclaimed until a
DISCONNECT statement is executed for that database. It
is recommended that databases using the DBKEY SCOPE IS
ATTACH clause periodically disconnect and reattach to the
database to allow this space to be reused. Reattaching at
every COMMIT statement wastes resources; use an interval
determined by the application designer, such as every three
hours, instead.
2.5.26 Specification of Correlation Name in Table References Is
Restricted
You cannot specify a correlation name in a table reference
that is the same as any other correlation name already
specified in the containing FROM clause, or the same as
the table identifier of any table name exposed in the
containing FROM clause. This restriction was implemented
to comply with the SQL-89 standard and is not documented in
the V4.1 VAX Rdb/VMS SQL Reference Manual.
This restriction causes the error message that appears in
the following example:
SQL> CREATE VIEW OVERALL.DEPT.SELECT_COLS
cont> AS SELECT
cont> O.LAST_NAME,
cont> NAME.FIRST_NAME
cont> FROM OVERALL.EMPLOYMENT.NAME O, COMPANY.NAME NAME
cont> WHERE O.LAST_NAME = NAME.LAST_NAME;
%SQL-F-CONVARDEF, Column qualifier NAME is already defined.
2-74 Known Problems, Restrictions, and Other Notes
2.5.27 Correction for Database Keys Example
An example in the VAX Rdb/VMS SQL Reference Manual, Section
3.6.2, Database Keys, contains a syntax error. The example
appears on page 3-78 of the V4.1 VAX Rdb/VMS SQL Reference
Manual.
The incorrect example reads:
EXEC SQL GET_DBKEYS DECLARE CURSOR FOR
SELECT DBKEY FROM EMPLOYEES;
This example should read:
EXEC SQL DECLARE GET_DBKEYS CURSOR FOR
SELECT DBKEY FROM EMPLOYEES;
2.5.28 RMU/SHOW STATISTICS Formatted Binary Output File Changes
Are Not Documented
Section 2.2.9 of the VAX Rdb/VMS Guide to Database
Performance and Tuning describes how to use the RMU/SHOW
STATISTICS command to write statistics to a formatted
binary file. While the procedural information is correct,
the sample output that shows the available record
definitions in the binary file does not include statistics
that were added for Rdb/VMS V4.1, such as global buffer
statistics and checkpoint statistics.
Existing procedures, for example DATATRIEVE programs, that
use RMU binary statistics will continue to work. However,
you should update your binary file definitions and programs
if you want to access the new statistics.
The Rdb/VMS V4.1 installation kit includes a text file that
lists and defines all the records available in the RMU/SHOW
STATISTICS binary file. You can find this text file in the
following location:
SYS$LIBRARY:RMU$SHOW_STATISTICS.CDO
The following example shows how the RMU/SHOW STATISTICS
binary file can be defined in the CDD using the file
SYS$LIBRARY:RDMU$SHOW_STATISTICS.CDO. Digital recommends
that you place the definitions contained in this file in a
separate CDD dictionary. In the example, the dictionary is
called CDD$TOP.RDB$EXAMPLES.
Known Problems, Restrictions, and Other Notes 2-75
First, create the new CDD dictionary:
$ DICTIONARY
CDO> DEFINE DIRECTORY CDD$TOP.RDB$EXAMPLES.
Next, define the fields and records:
CDO> SET DEFAULT CDD$TOP.RDB$EXAMPLES
CDO> @SYS$LIBRARY:RDMU$SHOW_STATISTICS.CDO
The following VAX DATATRIEVE example uses statistics
collected with the RMU/SHOW STATISTICS/OUTPUT command along
with the previously defined record and field definitions
found in CDD$TOP.RDB$EXAMPLES.
$ DATATRIEVE / INTERFACE=CHAR
! Define the domain
! The domain must refer to the file generated with the /OUTPUT qualifier
! of RMU/SHOW STATISTICS command, such as:
! $ RMU/SHOW STATISTICS/OUTPUT=DATABASE.STATS personnel
!
! Uses the previously defined CDD record definition for the RMU/SHOW
! STATISTICS record definition that is defined in CDD$TOP.RDB$EXAMPLES
!
SET DICTIONARY CDD$TOP.RDB$EXAMPLES
!
REDEFINE DOMAIN RMU_STATS_HEADER USING HEADER_REC ON DATABASE.STATS;
! Define record for the first record in the stats file
REDEFINE RECORD HEADER_REC USING
01 HEADER_REC.
05 DATE_TIME_STAMP USAGE DATE.
05 NODE_NAME PIC X(17).
05 ROOT_FILE_NAME PIC X(256).
05 FILLER PIC X(1767).
;
!
! Define the domain and record format for the second and all other records
!
REDEFINE DOMAIN RMU_STATS USING RMU$ROOT_STATISTICS ON DATABASE.STATS;
!
! Generate a DTR plot using collected statistics
! Read the first record from the file to obtain the database root name,
! node, and date the stats were generated on
!
READY RMU_STATS_HEADER
DECLARE ROOT PIC X(256).
2-76 Known Problems, Restrictions, and Other Notes
DECLARE NODE PIC X(17).
DECLARE STATS_DATE USAGE DATE.
FOR FIRST 1 RMU_STATS_HEADER
BEGIN
ROOT = ROOT_FILE_NAME
NODE = NODE_NAME
STATS_DATE = DATE_TIME_STAMP
END
PRINT ""
PRINT ""
PRINT ""
PRINT "All plots for database: ", ROOT (-) USING X(80)
PRINT "On node: ", NODE (-)
PRINT "On date: ", STATS_DATE (-)
PRINT ""
PRINT ""
FINISH RMU_STATS_HEADER
!
!
READY RMU_STATS
! Find last record which contains the cumulative statistics
FIND RMU_STATS
FIND CURRENT WITH RUNNING COUNT = COUNT OF CURRENT
SET PLOTS CDD$TOP.DTR$LIB.PLOTS
!
! Sample bar graph
PLOT RAW_BAR ALL RMU$RT_TOTAL_LCK_LOCK ('locks requested'),
RMU$RT_TOTAL_LCK_UNLOCK ('locks released'),
RMU$RT_TOTAL_LCK_PROMOTE ('locks promoted'),
RMU$RT_TOTAL_LCK_DEMOTE ('locks demoted') ON NL:
PLOT TITLE "Summary of All locks"
PLOT PAUSE
FINISH
$EXIT
Known Problems, Restrictions, and Other Notes 2-77
2.5.29 Description of the Space Used by the New Segmented String
Structures on WORM Disks in the VAX Rdb/VMS Guide to
Database Maintenance Is Incorrect
In Section 12.4.5.2 of the V4.1 VAX Rdb/VMS Guide to
Database Maintenance, there is a description of the new
list (segmented string) format that is used for storing
lists on WORM optical disk devices. The structures are
described accurately; however, the space used by these
structures and space available in the first and subsequent
pointer segments and the data segments is incorrect. The
first pointer segment consists of 44 bytes of overhead + 5
bytes of control information, leaving 65486 bytes (65535-
44-5) of remaining space to store the array of 12-byte data
segment pointers. Second and subsequent pointer segments
contain only 12 bytes of overhead + 5 bytes of control
information, leaving 65518 bytes (65535-12-5) of remaining
space to store the array of 12-byte data segment pointers.
Each data segment contains 5 bytes of control information,
leaving 65530 bytes (65535-5) of space in which to store
list or segmented string data. Note however, that the
largest page size that can be defined for a storage area
is 64 blocks. This new list format is the default format
for storing list data on read/write media and WORM optical
disk drives.
Therefore, for page sizes of 2 to 64 blocks, each pointer
segment is sized such that it will fit on a page so that
the pointers do not fragment. A page size of 1 block is
not possible for storage areas on WORM optical disks, but
is possible for read/write media. The space available on a
page for storing pointer segments or data is determined by
taking the page size for the storage area and subtracting
the overhead required for either the first pointer segment,
or second or subsequent pointer segment, or data segment.
Thus, you can determine the available space left on the
page for storing data pointers on pointer segment pages or
data on data pages based on the page size for the storage
area minus the overhead.
2-78 Known Problems, Restrictions, and Other Notes
2.5.30 SQLDA2 Null Indicator Data Type Is Incorrect
Example D-7 in the VAX Rdb/VMS SQL Reference Manual
incorrectly shows the null indicator value (SQLIND)
declared as a SHORT WORD. The null indicator value should
be declared as a LONGWORD, as is correctly shown in Table
D-3 in the VAX Rdb/VMS SQL Reference Manual.
2.5.31 SQL ALTER DOMAIN and RDO CHANGE FIELD Statement
Restriction Is Undocumented
Suppose you perform an SQL ALTER DOMAIN or RDO CHANGE FIELD
operation that causes a conversion error on retrieval of a
record. In an attempt to avoid the error, you might try to
delete the record. This will not work because the delete
operation will attempt to do the same incorrect conversion.
A workaround to this problem is to alter or change the
domain back to the original data type and then remove or
change the offending records. Then you can use the SQL
ALTER DOMAIN or RDO CHANGE FIELD statements to alter the
domain to the new required data type.
This behavior was first documented in the V4.1 VAX Rdb/VMS
Release Notes.
2.5.32 Examples of Specifying Preferred Optimization Mode Show
Incorrect SQL Syntax
The SQL syntax that illustrates specifying a preferred
optimization mode, in Section 5.7.4 of the VAX Rdb/VMS
Guide to Database Performance and Tuning, is incorrect.
The current, incorrect syntax reads:
SQL> DECLARE CEMP TABLE CURSOR
cont> OPTIMIZE FOR FAST FIRST
cont> FOR
cont> SELECT *
cont> FROM EMPLOYEES
cont> WHERE EMPLOYEE_ID > '01100';
SQL> DECLARE TEMP TABLE CURSOR
cont> OPTIMIZE FOR TOTAL TIME
cont> FOR
cont> SELECT LAST_NAME, FIRST_NAME
cont> FROM EMPLOYEES;
Known Problems, Restrictions, and Other Notes 2-79
In both examples, the OPTIMIZE FOR clause is misplaced;
it should follow the select expression as shown in the
following two examples:
SQL> DECLARE CEMP TABLE CURSOR
cont> FOR
cont> SELECT *
cont> FROM EMPLOYEES
cont> WHERE EMPLOYEE_ID > '01100'
cont> OPTIMIZE FOR FAST FIRST;
SQL> DECLARE TEMP TABLE CURSOR
cont> FOR
cont> SELECT LAST_NAME, FIRST_NAME
cont> FROM EMPLOYEES
cont> OPTIMIZE FOR TOTAL TIME;
2.5.33 Reference to Example of Initialized Parameter Is Incorrect
In the V4.1 VAX Rdb/VMS SQL Reference Manual, Section 7.29,
the next to last Usage Note is incorrect. The Usage Note
should read as follows:
o You must initialize the parameter that will hold the
statement identifier to zero before issuing a PREPARE
statement, as shown in Example 1.
2.5.34 INSERT Statement VALUES Clause Is Missing an Argument
The column select expression is missing from the list of
arguments that can be supplied to the INSERT statement
VALUES clause in the V4.1 VAX Rdb/VMS SQL Reference Manual,
Section 7.63. See the SQL Online Help topic INSERT EXAMPLES
for an example that shows an INSERT statement with a column
select expression.
2.5.35 Value Returned by AVG Function
The V4.1 VAX Rdb/VMS SQL Reference Manual, Section 3.6.1.3,
describes the behavior of the AVG function for interactive
and precompiled SQL only. In SQL module language and
dynamic SQL, as in precompiled SQL, the value returned
by AVG is rounded off to two decimal places.
The value returned by the AVG function inherits its scale
from the data type of the column being averaged. If the
column the AVG function refers to has the SMALLINT data
type, the result has no scale factor.
2-80 Known Problems, Restrictions, and Other Notes
2.5.36 Not All CDO and DTR Edit Strings Are Accepted by SQL
The V4.1 VAX Rdb/VMS SQL Reference Manual, Section 3.5.2,
describes the edit string characters accepted by SQL. Note
that the character colon (:), which is legal in DTR edit
strings, is not allowed in SQL edit strings.
Table 2-2 lists the CDO edit string characters accepted by
SQL.
Table_2-2_CDO_Edit_Strings_Supported_by_SQL________________
Character CDO Character
Type________________or_String______________________________
Alphabetic A
Alphanumeric T
X
Comma ,
Date, Day, and D
Time
J
M
N
P
R
W
Y
%
*
Decimal Point .
Digit 9
Encoded Sign C
Exponent E
Floating S
Z"string"
(continued on next page)
Known Problems, Restrictions, and Other Notes 2-81
Table_2-2_(Cont.)_CDO_Edit_Strings_Supported_by_SQL________
Character CDO Character
Type________________or_String______________________________
-
+
$
Literal "string"
Logical B
Minus Parentheses (( ))
Missing Separator ?
Repeat_Count________x(n)___________________________________
2.5.37 Corrections to Tables in VAX Rdb/VMS Guide to Using
SQL/Services
In Rdb/VMS V4.1, VAX Data Distributor statements can be
dynamically executed in SQL. The following corrections
apply to tables in the VAX Rdb/VMS Guide to Using
SQL/Services.
Table 2-3 contains corrections to Table 2-1 in the V4.1 VAX
Rdb/VMS Guide to Using SQL/Services.
Table_2-3_SQL_Statements_That_Can_Be_Dynamically_Executed__
ParameterSelect
Markers List Associated Dynamic SQL
Statement___________Allowed?_Items?_Statements_____________
SELECT Yes Yes PREPARE
Dynamic
DECLARE CURSOR
DESCRIBE (optional)
OPEN
FETCH
CLOSE
RELEASE (optional)
(continued on next page)
2-82 Known Problems, Restrictions, and Other Notes
Table 2-3 (Cont.) SQL Statements That Can Be Dynamically
__________________Executed_________________________________
ParameterSelect
Markers List Associated Dynamic SQL
Statement___________Allowed?_Items?_Statements_____________
INSERT Yes No PREPARE
UPDATE DESCRIBE (optional)
DELETE EXECUTE
ATTACH RELEASE (optional)
CONNECT EXECUTE IMMEDIATE (if
no parameter markers)
CREATE No No PREPARE
ALTER EXECUTE
DROP RELEASE (optional)
DECLARE EXECUTE IMMEDIATE
TRANSACTION
SET TRANSACTION
COMMIT
ROLLBACK
GRANT
REVOKE
COMMENT ON
VAX Data
Distributor
Statements:
CREATE SCHEDULE
CREATE TRANSFER
DROP SCHEDULE
DROP TRANSFER
REINITIALIZE
TRANSFER
START TRANSFER
STOP_TRANSFER______________________________________________
Table 2-4 shows corrections that apply to Table 2-2 in the
V4.1 VAX Rdb/VMS Guide to Using SQL/Services:
Known Problems, Restrictions, and Other Notes 2-83
Table 2-4 SQL Statements That Cannot Be Dynamically
__________Executed_________________________________________
SQL_Statement_______Related_SQL/Services_Routine___________
BEGIN DECLARE none
CLOSE sqlsrv_close_cursor
DECLARE ALIAS none
DECLARE CURSOR sqlsrv_declare_cursor
DECLARE STATEMENT none
DECLARE TABLE none
DESCRIBE sqlsrv_prepare (implicit in)
END DECLARE none
EXECUTE sqlsrv_execute
EXECUTE IMMEDIATE sqlsrv_execute_immediate
FETCH sqlsrv_fetch, sqlsrv_fetch_many
INCLUDE none
OPEN sqlsrv_open_cursor
PREPARE sqlsrv_prepare
RELEASE sqlsrv_release_statement
SELECT . . . INTO none
(singleton select)
SHOW TRANSFER none
(VAX Data
Distributor)
WHENEVER____________none___________________________________
2.5.38 The VAX Rdb/VMS RDO Reference Manual Appendix C Omits VAX
Data Distributor Commands
The VAX Rdb/VMS RDO Reference Manual, Appendix C, does not
include the VAX Data Distributor commands. All of these
commands are available to users of the Rdb/VMS run-time
only (RTO) software. For a list of these commands, see the
SQL Online Help topic RUN_TIME_ONLY_KIT.
2-84 Known Problems, Restrictions, and Other Notes
2.5.39 RDB$MISSING Is Evaluated at Compile Time, Not Run Time
The RDB$MISSING() function is a facility provided by the
precompilers RDBPRE and RDML and the interactive interface
RDO. When this function is used in a precompiled source
its value is set at compile time, not at run time. This
behavior is described in Section 2.6 of the RDML Reference
Manual, but was omitted from the VAX Rdb/VMS RDO Reference
Manual.
Therefore, if the missing value for a field is changed,
then sources that contain references to RDB$MISSING() for
that field still use the old missing value. To correct
this problem, all sources that contain a reference
to RDB$MISSING on the field that was changed must be
recompiled.
The RDO missing value is not actually stored in the
records in the relation. If RDO (or the CDD/Repository CDO
interface) is used to specify a missing value for a field,
the missing value is returned to an application if the
field is NULL. However, SQL does not recognize any missing
value specified by RDO. SQL instead displays NULL for any
field that has no value stored (that is, the null flag is
set). An SQL application can use the INDICATOR variable to
detect the case of a NULL field.
________________________ Note ________________________
Digital recommends that you use SQL and indicator
variables to detect whether or not the field is NULL
rather than using the RDB$MISSING function.
______________________________________________________
The following short SQL program demonstrates the use of
indicator variables. For more information on indicator
variables, see the V4.1 VAX Rdb/VMS Guide to Using SQL.
program EXAMPLE(input, output);
Known Problems, Restrictions, and Other Notes 2-85
exec sql include sqlca;
exec sql declare alias filename 'EXAMPLE';
exec sql declare acursor
cursor for
select y.x_text
from y_table y;
var
x_text : varying [80] of char;
text_ind : integer;
begin
write('x_text: ');
readln(x_text);
if x_text.length <> 0
then
text_ind := 0
else
text_ind := -1;
exec sql set transaction read write;
exec sql insert into y_table
values (:x_text indicator :text_ind);
exec sql open acursor;
repeat
exec sql fetch acursor
into :x_text indicator :text_ind;
if sqlca.sqlcode = 0
then
begin
if text_ind = 0
then
writeln('returned: ', x_text)
else
writeln('returned: NULL');
2-86 Known Problems, Restrictions, and Other Notes
into :x_text indicator :text_ind;
if sqlca.sqlcode = 0
then
begin
if text_ind = 0
then
writeln('returned: ', x_text)
else
writeln('returned: NULL');
end;
until sqlca.sqlcode <> 0;
exec sql close acursor;
end.
2.5.40 SORTWORKn Logical Name Description Is Inaccurate
The description of the logical name SORTWORKn in Section
A.12 of the VAX Rdb/VMS Guide to Database Performance and
Tuning is inaccurate and incomplete.
SORTWORKn is a work file, where n is a number from 0
through 9. This logical enables you to assign the location
of temporary sort work files to different disks. The
description incorrectly states that " . . . you must define
these logical names [SORTWORK0, . . . ,SORTWORK9] to be
pointing to a disk device that has a writeable directory
with the same name as the user's directory." This implies
that to assign 10 work files to 10 different devices for
100 users, you would have to create 1,000 directories. The
true behavior of SORTWORKn is described as follows:
There are two ways you can use the logical name SORTWORKn:
o If you define SORTWORKn and specify a device, Rdb/VMS
creates a hidden temporary file. No root directory is
necessary, but users must have disk quotas enabled on
the specified device.
o If you define SORTWORKn and specify a device and a
directory name, Rdb/VMS creates a visible temporary
file. Users do not need disk quotas enabled on the
specified device. Instead, you can add an ACL for a
resource identifier and grant the resource identifier to
each user. The disk quota for the resource identifier is
then used. This is a good alternative when there are a
Known Problems, Restrictions, and Other Notes 2-87
large number of database users that may be concurrently
using the sort work files because this alternative
requires only one directory for all of the active users.
2.5.41 Clarification on Setting the Read-Only and Read/Write
Attributes for the RDB$SYSTEM Storage Area and Using the
RMU/ANALYZE/CARDINALITY/UPDATE Command
The V4.1 VAX Rdb/VMS Guide to Database Maintenance, Section
1.2.5, states that if you have exclusive access to a
storage area, you can change the read-only and write-once
attributes for the storage area online, that is, with other
users attached to the database. How this applies to the
RDB$SYSTEM storage area is not described.
This same requirement of exclusive access to the storage
area applies to the RDB$SYSTEM storage area. However,
in this case, because only the user who has exclusive
access to the RDB$SYSTEM storage area can set the read-only
attribute, this in effect is an offline operation, as it is
the only way to guarantee exclusive access to this storage
area. Note that you cannot set the write-once attribute for
the RDB$SYSTEM storage area.
If the RDB$SYSTEM storage area is set to read-only,
you must close the database before you can perform an
RMU/ANALYZE/CARDINALITY/UPDATE command. This command can
be performed only if you have exclusive access to the
database because the system relations are updated with
current cardinality values for all logical areas. This
information is not described in the V4.1 documentation.
2.5.42 Clarification on the Relationship Between the Number of
Users and the Number of Nodes Supported on a Database
This information is a clarification of behavior that is
described in RDO Help and the V4.1 VAX Rdb/VMS Guide to
Database Maintenance. The following paragraphs describe the
relationship between the number of users and the number
of nodes supported on a database and explain why when
you specify 2032 users and 4 nodes in an SQL CREATE/ALTER
DATABASE or RDO DEFINE/CHANGE DATABASE statement and then
dump the database root file, 2032 users and 41 nodes are
the values displayed.
2-88 Known Problems, Restrictions, and Other Notes
Rdb/VMS uses a data structure called a TSN block (TSNBLK)
to keep track of transaction activity on a node and
transaction information for each user on a particular node.
Each TSNBLK is owned by a particular node and can handle
up to 50 users. For each group of 50 users, one TSNBLK is
allocated per node to cover the maximum number of users
and VAXclusters nodes the database is expected to support,
which is determined as either one TSNBLK per VAXcluster
node, or one TSNBLK per 50 users, whichever is larger. The
maximum number of TSN blocks is equal to the value of the
current maximum number of VAX nodes that are supported for
a database (currently 96) for Rdb/VMS V4.1.
For example, if the DBA specifies 2032 users and 4 nodes,
this is calculated as 2032/50 for a total of 41 TSNBLKs,
and this equates to 41 nodes. The algorithm selects the
maximum value of (number of nodes specified, number of
nodes calculated). So in this example, 41 is the maximum
calculated value (calculated 41 > specified 4).
Had the DBA specified 2032 users and 50 nodes, 50 would be
the maximum value for the number of nodes (specified 50 >
calculated 41) and 50 TSNBLKs would be allocated, one for
each node.
If the DBA specifies 50 users and 10 nodes, the maximum
value is 10 nodes (specified 10 > calculated 1), so 10
TSNBLKs would be allocated, one for each node.
2.5.43 Clarification on Why Snapshot Files Grow in Size
The following explanation describes why snapshot files
can grow quite large in size. This explanation will appear
in a future version of the VAX Rdb/VMS Guide to Database
Maintenance.
Every read/write transaction keeps track of a TSN called
the CUTOFF_TSN. This CUTOFF_TSN is the TSN of the oldest
active transaction at the time this read/write transaction
started. The CUTOFF_TSN is used to decide which pages in
a snapshot file may be reclaimed. All snapshot pages that
contain snapshot records for TSNs less than the CUTOFF_TSN
may be reclaimed.
Known Problems, Restrictions, and Other Notes 2-89
Snapshot files will grow during long-running transactions.
A long-running transaction will inhibit the reclamation
of snapshot pages by other transactions. An example will
clarify this point.
If at some time a transaction T1 is started and keeps
active forever, then every transaction that starts after
this one will have T1's TSN as the CUTOFF_TSN (oldest
active transaction). Because this CUTOFF_TSN will never
change (because T1 never commits), snapshot pages will
never get reclaimed.
There are two causes for long-running transactions:
o Some transactions remain active for extended periods of
time.
There is not much that you can do about this situation
other than changing the application program to have
shorter transactions.
o A process commits a transaction and then does not do
anything for a long time.
When the transaction commits, Rdb/VMS prestarts another
transaction. This is done as a performance optimization.
Unfortunately, this makes it appear as if there is a
transaction active when there actually is not. Hence,
other transactions cannot update their CUTOFF_TSN. (It
is not possible to differentiate from one transaction's
context whether another transaction is pre-started or
active.)
If your application has infrequent read/write transactions
and long pauses in between, the following workaround will
remedy this situation. Mask every commit of a read/write
transaction to appear as follows:
COMMIT
START_TRANSACTION READ_ONLY
ROLLBACK.
Starting and rolling back a read-only transaction as soon
as the read/write transaction commits will disable the pre-
started transaction. Hence, other read/write transactions
get accurate values for the CUTOFF_TSN. Unfortunately,
doing this is expensive, but it will allow snapshot space
to be reclaimed.
2-90 Known Problems, Restrictions, and Other Notes
2.5.44 Request Handle Syntax Treated Differently in Statistical
Expressions
The RDML precompiler implements REQUEST_HANDLE syntax
differently than the RDBPRE precompiler in a standalone
GET statement used to fetch statistical information (COUNT,
MAX, MIN, AVERAGE).
RDBPRE allows the syntax (REQUEST_HANDLE rh) to go on the
GET keyword, and it is used by all statistical expressions
in the GET . . . END_GET block.
RDML allows the syntax (REQUEST_HANDLE rh) to go on each
statistical expression in the GET . . . END_GET block, and
there is one request per statistical expression.
RDML RDBPRE
GET GET (request_handle r)
a = COUNT a = COUNT ...;
(request_handle r1)
...;
b = MAX b = MAX ...;
(request_handle r2)
...;
END_GET END_GET
Refer to the RDML Reference Manual for details of the GET
statement syntax for RDML. The VAX Rdb/VMS RDO Reference
Manual omits the handle-options clause shown in the
following syntax diagram:
FOR ----+-------------------+--+-------------+--+-> get-item -+--> END_GET
| | | | | |
+-> handle-options -+ +-> on-error -+ +------ ; <---+
The handle-options clause is identical to that described
for the FOR statement.
Known Problems, Restrictions, and Other Notes 2-91
2.5.45 Description of RMU/SHOW STATISTICS Checkpoint Display
Needs Clarification
The description of the RMU/SHOW STATISTICS display in
Section 4.1.1.5 of the V4.1 VAX Rdb/VMS Guide to Database
Performance and Tuning should be updated with the following
information:
o In the bulleted list following the sample display,
the Transactions statistic is described as "The total
number of transactions." This statistic represents all
transactions (committed or rolled back) completed by all
users of the database, including transactions that read
from the database as well as transactions that modify
the database.
o In the same list, under the bullet Intervals, there is
a metric called Number of transactions. This statistic
also represents transactions completed by all database
users, but does not include transactions that only read
the database.
o In the paragraph that begins "To find the average
interval . . . ", the last sentence ends with the
phrase, " . . . so the average number of intervals for
a time-triggered checkpoint is 593." Replace the word
"intervals" with the word "seconds."
o In the sentence that reads "Likewise, the transactions
interval is 800 and the total number of checkpoints
is 100, so the average time between checkpoints is 8
seconds", replace the word "time" with the words "number
of transactions", and delete the word "seconds."
2.5.46 Using RDML and the Two-Phase Commit Protocol by Calling
the DECdtm System Service Calls Implicitly and Explicitly
Is Not Fully Documented
In the VAX Rdb/VMS RDML Reference Manual and the VAX
Rdb/VMS Guide to Using RDO, RDBPRE, and RDML, using RDML
and the two-phase commit protocol by calling the DECdtm
system service calls implicitly and explicitly is not fully
documented. A full description is provided here for using
RDML with distributed transactions.
2-92 Known Problems, Restrictions, and Other Notes
The implementation of RDML with distributed transactions is
very similar to using RDBPRE with distributed transactions.
See the VAX Rdb/VMS Guide to Distributed Transactions for
a complete description of using RDBPRE with distributed
transactions and the VAX Rdb/VMS RDML Reference Manual and
the VAX Rdb/VMS Guide to Using RDO, RDBPRE, and RDML for
more information.
To use the two-phase commit protocol with RDML, you must
either recompile any existing application programs that
were compiled with Rdb/VMS V3.1 or earlier, or you must
write new application programs. With RDML, the two-phase
commit protocol is not the default.
Applications can use the two-phase commit protocol by
calling the DECdtm system service calls implicitly
or explicitly. RDML provides the following ways for
application programs to use the two-phase commit protocol:
o By implicitly calling DECdtm system services calls in
the following two ways:
- For application programs that were written under
Rdb/VMS V3.1 or earlier, use the two-phase commit
protocol simply by recompiling your programs. You
must use the /DISTRIBUTED_TRANSACTION qualifier
in the precompiler command line. When you do this,
Rdb/VMS invokes the DECdtm system service calls for
your application.
- For new application programs that invoke only
Rdb/VMS databases, or Rdb/VMS databases and VIDA
databases, use the DISTRIBUTED_TRANSACTION keyword
in the START_TRANSACTION statement. When you do this,
Rdb/VMS invokes the DECdtm system service calls for
your application. For example, to recompile the C
program SAMPLE.RC with the RDML preprocessor, use the
following command:
$ RDML :== $RDML/C
$ RDML
SOURCE FILE> SAMPLE /DISTRIBUTED_TRANSACTION
o By explicitly calling the DECdtm system service calls
and using variables to pass the value of the distributed
transaction identifier (TID)
Known Problems, Restrictions, and Other Notes 2-93
If your application starts a distributed transaction
that includes other read/write database management
products that support the two-phase commit protocol,
your application must explicitly invoke the DECdtm
system service calls. For example, if your application
starts a distributed transaction using Rdb/VMS and
VAX DBMS, your application must explicitly call
SYS$START_TRANS and SYS$END_TRANS.
In addition, you must use the full DISTRIBUTED_
TRANSACTION clause in the START_TRANSACTION statement.
2.5.47 Explanation of the Lock Conflict on Freeze Errors
The following explanation is information that will appear
in a future version of the VAX Rdb/VMS Guide to Database
Performance and Tuning. The following lock conflict on
freeze error for a read-only NOWAIT transaction represents
proper operation of the database. This brief explanation
may help to clear up any confusion regarding why a lock
conflict is sometimes possible even though the process uses
a NOWAIT transaction.
Consider the following potentially dangerous scenario:
Process A Process B
Holds lock on resource 1
Request lock on resource 1 and is
waiting
Modifies resource 1
Process A is terminated prematurely
VMS releases all locks held by A
B is granted the lock on resource 1
and may see uncommitted changes
made by A
When Rdb/VMS is running in a cluster, it is necessary to
ensure that termination of a process does not result in
granting locks to other application processes before the
database monitor has detected the error and recovered the
transactions for the failed user (if necessary).
2-94 Known Problems, Restrictions, and Other Notes
The "freeze protocol" is used to ensure that any new lock
request by another application process is not granted until
the monitor has had a chance to do any cleanup (recovery)
operations that are necessary for the terminated process.
Here is how the "freeze protocol" algorithm works. Note
that this explanation omits the intricate details to
simplify the explanation.
Every user process has the FREEZE lock in CW mode.
Whenever there is a potential need to recover the database
(that is, a process aborts abnormally, a node in the
cluster fails, and so forth), the FREEZE lock is requested
by the recovery process (DBR) in an incompatible mode (PR),
thus generating blocking ASTs for every user process.
Every process gives up the FREEZE lock, thus enabling the
recovery process to acquire the lock. After a lock request
by a user process is granted, Rdb/VMS checks whether the
FREEZE lock is held by that process in CW mode. If the lock
is not CW, then Rdb/VMS knows that the monitor is trying to
recover the database and return it to a consistent state.
Hence, the lock that was granted should be given up so that
recovery can obtain the lock and recover the database.
Rdb/VMS releases the granted lock and (if the lock request
was a WAIT request) requests the FREEZE lock in CW mode.
After this is granted, Rdb/VMS reissues the original lock
request.
If the lock request was a NOWAIT lock request, Rdb/VMS
flags the conflict on freeze message to indicate that
the lock request cannot be granted because (potentially)
recovery is in progress. Any of the following events (and
perhaps others) could cause the "Lock Conflict on Freeze"
error message to occur.
o The lock request is a NOWAIT request.
o If recovery is taking place; as shown by DBR processes
in the monitor logs.
o A node failed while users are accessing the database.
Known Problems, Restrictions, and Other Notes 2-95
o The monitor log has logged events such as: "cluster
recovery completed successfully" or "received request
from remote node to join . . . ". This indicates that
new database activity is occurring on a node, or there
are no more users on a node accessing a database. When
these events happen, the monitor has to ensure that this
transition did not leave the database in an inconsistent
state.
2.5.48 Explanation of RMU/SHOW STATISTICS Blocking AST
This is a clarification of the definition of the number of
blocking ASTs reported by the RMU/SHOW STATISTIC utility
that will appear in a future version of the VAX Rdb/VMS
Guide to Database Performance and Tuning.
The number of lock-blocking ASTs reported by the RMU/SHOW
STATISTICS utility is actually comprised of two different
types of blocking ASTs, those blocking ASTs externally
generated and those blocking ASTs internally generated:
o An externally generated blocking AST occurs when a
blocking AST is actually received by the process from
the operating system in response to some lock conflict
with another process. A blocking AST routine is executed
and the RMU/SHOW STATISTICS utility records the blocking
AST activity.
o An internally generated blocking AST occurs when a
lock-blocking AST routine is executed by the process
in anticipation that the same work would have to be
performed anyway if a blocking AST were to be received
from the operating system, even when no blocking AST
from the operating system actually occurred. This
algorithm serves as an optimistic code optimization;
it is assumed that the process would eventually
receive a blocking AST for the particular lock, so
it optimistically executes the blocking AST routine.
The RMU/SHOW STATISTICS utility does not differentiate
between these two types of blocking ASTs.
2-96 Known Problems, Restrictions, and Other Notes
2.5.49 Explanation of RMU/SHOW STATISTICS Stall Messages
The following description identifies all of the messages
displayed by the RMU/SHOW STATISTICS utility's "Stall
Messages" screen, and provides a brief explanation of
the cause of the messages. In most cases, the messages
are informational and should cause little concern. The
following undocumented information will appear in a future
version of the VAX Rdb/VMS Guide to Database Performance
and Tuning:
o Extending .AIJ file
This message displays whenever the .AIJ file is
physically extended. This message should occur very
seldom.
o Extending .RUJ file
This message displays whenever the .RUJ file is
physically extended. This message should occur very
seldom.
o Extending storage area !UL
This message displays whenever a storage area
(identified by its numeric identifier-see RMU/DUMP
output) file is physically extended. This message should
occur only occasionally; this message may occur more
frequently when using WORM areas, because pages cannot
be re-used once they have been written.
o Reading .AIJ file
This message displays whenever the AIJ lock information
needs to be refreshed; this typically only occurs the
first time a user attaches to the database. The .AIJ
file is read to determine the AIJ logical EOF (not to be
confused with the VMS logical EOF).
o Reading ROOT file
This message displays whenever the in-memory database
root information is determined to be out-of-date and
must be reread from the disk. This message normally
occurs only when a database parameter is modified by a
user online, or some information in the database root
is modified by the system (such as the AIJ sequence
number).
Known Problems, Restrictions, and Other Notes 2-97
o Reading .RUJ file
This message displays whenever an undo operation needs
to read the next RUJ page to acquire the rollback
information necessary to complete the operation. The
.RUJ file is read one block at a time.
o Reading pages !UL:!UL to !UL:!UL
This message displays whenever one or more pages is
read into either a user's local buffer or the global
buffer. One buffer full of pages is being read. The
format string "!UL:!UL" identifies the physical area and
the page number.
o Waiting for !AD (!AC)
This message displays whenever a process requests a
lock "with wait" and another process is holding the lock
in an incompatible mode. This message may indicate a
database "hot-spot" and should be investigated using
the RMU/SHOW LOCKS utility. The format string "!AD"
identifies the lock type (that is, storage area, page,
membit, etc.) and the string "!AC" identifies the
requested lock mode (PR, CR, EX, etc.).
o Writing .AIJ file
This message displays whenever a group commit process
actually performs the write of commit information to the
.AIJ file. The write buffer length will be as close to
32k as possible.
o Writing ROOT file
This message displays whenever the in-memory database
root information is modified by a user online, or some
information in the database root is modified by the
system (such as the AIJ sequence number).
o Writing .RUJ file
This message displays whenever a user process writes
data page modification information to the .RUJ file.
This message always precedes the next message.
o Writing pages back to database
2-98 Known Problems, Restrictions, and Other Notes
This message displays whenever one or more data pages is
written to the database. This is typically caused by a
request to access those pages from another process, or
by detaching from the database.
2.5.50 GROUP Privilege Is Not Necessary To Use RMU/SHOW LOCKS
The VAX Rdb/VMS RMU Reference Manual states incorrectly
in a Usage Note for RMU/SHOW LOCKS that GROUP privilege is
necessary to achieve some command functionality.
Ignore all references to the GROUP privilege in RMU/SHOW
LOCKS documentation. You need the VMS WORLD privilege to
use the RMU/SHOW LOCKS command.
This error will be corrected in a future version of the VAX
Rdb/VMS RMU Reference Manual.
2.5.51 V4.2 HELP For RMU States Incorrect MAX Density
The RMU HELP incorrectly states that MAX density is 32768.
The correct value of MAX density is 70000.
2.5.52 Error in COBOL Version of SQL$DIST_TRANS Example
The error handling in the COBOL version of the sample
application SQL$DIST_TRANS does not check all possible
conditions. After the call to SYS$START_TRANSW, the
program checks for the return condition status of SS$_
SYNCH only; however, the SYS$START_TRANSW could also return
the condition SS$_NORMAL.
Checking for failure using the COBOL keyword FAILURE after
all system service calls is better coding practice.
The following example, from SQL$DIST_TRANS.COB, shows the
SYS$START_TRANSW call and incorrect error handling:
* Start the transaction.
CALL "SYS$START_TRANSW" USING OMITTED, BY VALUE DDTM$M_SYNC
BY REFERENCE IOSB,
OMITTED, OMITTED, BY REFERENCE TID
GIVING RET-STATUS.
* Check return status of the call.
IF RET-STATUS NOT EQUAL SS$_SYNCH THEN
CALL "LIB$STOP" USING BY VALUE RET-STATUS.
Known Problems, Restrictions, and Other Notes 2-99
The following example shows the corrected code:
* Start the transaction.
CALL "SYS$START_TRANSW" USING OMITTED, OMITTED,
BY REFERENCE IOSB,
OMITTED, OMITTED, BY REFERENCE TID
GIVING RET-STATUS.
* Check return status of the call.
IF RET-STATUS IS FAILURE THEN
CALL "LIB$STOP" USING BY VALUE RET-STATUS.
* Check the IOSB.
IF COND-VAL IS FAILURE THEN
CALL "LIB$STOP" USING BY VALUE COND-VAL.
The following example shows the original error handling
after the calls to SYS$END_TRANSW and SYS$ABORT_TRANSW
in the programs SQL$DIST_TRANS.COB and SQL$DIST_TRANS_
ERROR.SCO:
* Check the return status of the call.
IF RET-STATUS EQUAL SS$_NORMAL THEN
IF COND-VAL OF IOSB NOT EQUAL SS$_NORMAL THEN
CALL "LIB$STOP" USING BY VALUE COND-VAL OF IOSB
END-IF
ELSE
CALL "LIB$STOP" USING BY VALUE RET-STATUS.
The following example shows the corrected error handling:
* Check the return status of the call.
IF RET-STATUS IS FAILURE THEN
CALL "LIB$STOP" USING BY VALUE RET-STATUS.
* Check the IOSB.
IF COND-VAL IS FAILURE THEN
CALL "LIB$STOP" USING BY VALUE COND-VAL.
2.5.53 Syntax Diagram for ALTER STORAGE MAP Statement in Rdb/VMS
V4.2 SQL Online Help is Incorrect
In the V4.1 VAX Rdb/VMS SQL Reference Manual, there is a
usage note that states:
"You can store lists and tables in separate storage areas, but you
cannot alter a storage map that is a list storage map. . . .
"
2-100 Known Problems, Restrictions, and Other Notes
This is an accurate statement, however, the syntax diagram
conflicts with this usage note. The store-lists-clause
should not appear with the SQL ALTER STORAGE MAP statement.
It is valid only with the SQL CREATE STORAGE MAP statement.
The syntax diagram in the V4.2 VAX Rdb/VMS New and Changed
Features is correct. The next release of the VAX Rdb/VMS
New and Changed Features will also reflect this correction.
However, online help for V4.2 still shows the incorrect
syntax and cannot be corrected at this late date. This will
be corrected in the next release of Rdb/VMS.
2.6 RDO and RDBPRE Known Problems and Restrictions for V4.2
This section contains known problems and restrictions for
the RDO and RDBPRE interfaces for V4.2.
2.6.1 Unexpected Constraint Failure When Using Nested FOR Loops
The interactive RDO utility unbundles loops when an inner
loop does not reference the context of an outer loop, such
as shown in the following example:
FOR F1 IN F1 WITH F1.F11 = "1"
PRINT F1.*
FOR F2 IN F2 WITH F2.F21 = "1"
PRINT F2.*
ERASE F2
END_FOR
ERASE F1
END_FOR
This loop will be executed as two discrete loops because
RDO considers them independent.
FOR F1 IN F1 WITH F1.F11 = "1"
PRINT F1.*
ERASE F1
END_FOR
FOR F2 IN F2 WITH F2.F21 = "1"
PRINT F2.*
ERASE F2
END_FOR
This simplifies the internal processing performed by RDO
and in general will result in the desired action upon the
database.
Known Problems, Restrictions, and Other Notes 2-101
However, if there is a FOREIGN KEY (or similar constraint)
relationship from F2 to F1 and the constraint is evaluated
as VERB TIME then this loop unbundling will result in an
unexpected constraint violation like the following:
%RDB-E-INTEG_FAIL, violation of constraint F2_FOREIGN_0001
caused operation to
-RDB-F-ON_DB, on database DISK1:[SMITH.WORK]FORKEY_
TEST.RDB;1
To avoid such problems, you should either evaluate the
constraint at COMMIT TIME, or modify the nested loop so
that there is a reference in the inner loop to context of
the outer loop. See the underlined portion of the following
example.
FOR F1 IN F1 WITH F1.F11 = "1"
PRINT F1.*
FOR F2 IN F2 WITH F2.F21_=_F1.F11
PRINT F2.*
ERASE F2
END_FOR
ERASE F1
END_FOR
2.6.2 TYPE IS ASCENDING and TYPE IS DESCENDING Ignored for Hashed
Indexes
RDO issues a warning message if you specify TYPE IS
ASCENDING or TYPE IS DESCENDING clauses for a hashed index
in commands such as IMPORT or DEFINE INDEX. For example:
RDO> DEFINE INDEX NEW_INDEX FOR EMPLOYEES
cont> TYPE IS HASHED.
cont> LAST_NAME ASCENDING.
cont> FIRST_NAME.
cont> END.
%RDO-W-ASCEIGNOR, ascending/descending ignored for HASH index
The TYPE IS ASCENDING and TYPE IS DESCENDING clauses are
not meaningful for hashed indexes because the hashed index
has no need to sort key values, since it never returns more
than one key value.
2-102 Known Problems, Restrictions, and Other Notes
2.7 RMU Known Problems and Restrictions for V4.2
This section contains known problems and restrictions for
the RMU interfaces for Rdb/VMS V4.2
2.7.1 RMU/SET PRIVILEGE/EDIT Command Requires Database To Be
Offline
You cannot use the RMU/SET PRIVILEGE/EDIT command online
because the ACL editor requires exclusive write access to
the database. Attempts to use the RMU/SET PRIVILEGE/EDIT
command while accessing the database generate errors like
the following.
$ RMU/OPEN MF_PERSONNEL.RDB ! (database is OPEN IS MANUAL)
$ RMU/SET PRIVILEGE/EDIT MF_PERSONNEL.RDB
%RMU-F-FILACCERR, error opening database root file DISK:[DIRECTORY]MF_PERSONNEL
-SYSTEM-W-ACCONFLICT, file access conflict
You can avoid the problem by avoiding the use of the /EDIT
qualifier.
2.8 CDD/Repository Notes of General Interest for V4.2
This section describes notes of general interest for using
Rdb/VMS V4.2 with the CDD/Repository.
2.8.1 Compatibility of CDD/Repository and Rdb/VMS
Many Rdb/VMS features are not fully supported by all
versions of CDD/Repository. Table 2-5 shows which versions
of the dictionary support such features, and the extent of
support. Table 2-5 also shows similar information for those
data dictionary features that are not fully supported by
all versions of Rdb/VMS.
Known Problems, Restrictions, and Other Notes 2-103
Table_2-5_Compatibility_of_the_Data_Dictionary_and_Rdb/VMS_
Earliest Earliest Data
Feature_Supported_____Rdb/VMS_Version__Dictionary_Version__
CDO DEFINE Generates error V4.0
DICTIONARY command in multiversion
environment and
V3.1B[1]
CDO DEFINE Generates error V5.0
REPOSITORY command in multiversion
environment and
V3.1B[1]
CDO MOVE DICTIONARY Generates error V4.0
command in multiversion
environment and
V3.1B[1]
CDO MOVE REPOSITORY Generates error V5.0
command in multiversion
environment and
V3.1B[1]
CDO SHOW command Not applicable Fixed in V5.1
incorrectly displays
segmented string
length
CDO syntax for SQL V3.1 V5.1
default values
Collating sequences V3.1 V5.1
Constraints, V3.0 No CDO syntax[2]
indexes, triggers,
storage maps
[1]Full_support_for_the_Rdb/VMS_multiversion_environment___
will be provided in a future release of CDD/Repository.
[2]This problem will be corrected in a future release of
CDD/Repository.
(continued on next page)
2-104 Known Problems, Restrictions, and Other Notes
Table 2-5 (Cont.) Compatibility of the Data Dictionary and
__________________Rdb/VMS__________________________________
Earliest Earliest Data
Feature_Supported_____Rdb/VMS_Version__Dictionary_Version__
HASHED attribute is V3.0 V5.1
correctly restored
when a hashed index
is deleted during an
INTEGRATE operation
Logical area V4.1 Not supported
thresholds for
storage maps and
indexes
Multilevel naming V4.1 Not supported
scheme
Multischema V4.1 Supports only a
databases single reference
from an Rdb/VMS
database to a
dictionary record
Multiversion V4.1 V5.1
environment
NODE SIZE and V3.0 V5.1
PERCENT FILL are
correctly restored
when a SORTED index
is deleted during
an INTEGRATE (for
example, a field
data type change
forces delete and
redefinition of the
index)
(continued on next page)
Known Problems, Restrictions, and Other Notes 2-105
Table 2-5 (Cont.) Compatibility of the Data Dictionary and
__________________Rdb/VMS__________________________________
Earliest Earliest Data
Feature_Supported_____Rdb/VMS_Version__Dictionary_Version__
Relation level V3.1 Not supported[2]
constraints (such
as PRIMARY KEY, NOT
NULL, CHECK)
SQL CAST(expression V4.1 Not supported[2]
AS data-type/domain-
name) function
SQL CURRENT_DATE V4.1 Not supported[2]
and CURRENT_TIME
functions
SQL date arithmetic V4.1 Not supported
SQL DATE, TIME, V4.1 CDD/Repository
TIMESTAMP, and supports only DATE
INTERVAL data types VMS
SQL Expressions V4.1 Not supported
containing the new
date-time data types
such as COMPUTED
BY (JOB_END - JOB_
START) INTERVAL
MONTH
SQL EXTRACT(option V4.1 Not supported[1]
FROM expression)
function
SQL GRANT/REVOKE V4.0 V5.0 accepts but
statements does not store
information
[1]Full_support_for_the_Rdb/VMS_multiversion_environment___
will be provided in a future release of CDD/Repository.
[2]This problem will be corrected in a future release of
CDD/Repository.
(continued on next page)
2-106 Known Problems, Restrictions, and Other Notes
Table 2-5 (Cont.) Compatibility of the Data Dictionary and
__________________Rdb/VMS__________________________________
Earliest Earliest Data
Feature_Supported_____Rdb/VMS_Version__Dictionary_Version__
SQL V4.0 V5.0 supports
SUBSTRING(expression all but V4.2 MIA
FROM start [FOR features[3]
length])
Storage map V3.0 V5.1
definitions are
correctly restored
when an index is
deleted during an
INTEGRATE operation.
Unique SORTED V4.1 V5.0[2,4]
indexes
[2]This_problem_will_be_corrected_in_a_future_release_of___
CDD/Repository.
[3]Multivendor Integration Architecture features include
the CHAR_LENGTH clause and the TRANSLATE function. MIA
features are documented in the VAX Rdb/VMS New and Changed
Features.
[4]Integration causes the index to be redefined, allowing
duplicates.
___________________________________________________________
2.8.2 COUNT Function with DISTINCT Clause Generates Dictionary
Syntax Error
An error occurrs when you use SQL to create a view based
on a table created using a CDD/Plus or CDD/Repository
dictionary record. When you use a CREATE VIEW statement
that specifies the COUNT function and the DISTINCT clause
as part of its SELECT clause, the dictionary issues an
error, as shown in the following example.
Known Problems, Restrictions, and Other Notes 2-107
CDO>DEFINE FIELD FIELD1 DATATYPE IS WORD.
CDO>DEFINE RECORD FOO.
FIELD1.
END RECORD.
SQL>CREATE DATABASE FILENAME FOOBAR PATHNAME CDD$DEFAULT.FOOBAR;
SQL> CREATE TABLE FROM CDD$DEFAULT.FOO;
SQL> CREATE VIEW BAR (NUMBER) AS
cont> SELECT COUNT (DISTINCT FIELD1) FROM FOO;
%CDD-E-MBLRSYNERR, syntax error in MBLR buffer at offset 0
This problem will be fixed in a future release of
CDD/Repository after CDD/Repository V5.1.
2.9 CDD/Repository Restrictions
This section describes known problems and restrictions in
CDD/Repository V5.0.
2.9.1 Interaction of CDD/Repository and RMU Privileges ACLs
See Section 2.1.1 for important information about a
procedure that must be carried out if you have installed or
plan to install Rdb/VMS Rdb V4.2 and have already installed
CDD/Plus V4.3, CDD/Repository V5.0, CDD/Repository V5.1 or
DECdesign on your system.
2.9.2 CDD/Repository Does Not Support Multiple Character Sets
CDD/Repository supports only the DEC_MCS character set. You
can continue to use Rdb/VMS with CDD/Plus or CDD/Repository
as long as you do not use any of the new clauses for
multiple character set support. Avoid the following SQL
statements:
o CREATE DATABASE PATHNAME path-name DEFAULT CHARACTER SET
support
o INTEGRATE DATABASE PATHNAME path-name-1 ALTER DICTIONARY
o INTEGRATE DATABASE FILENAME file-name CREATE PATHNAME
path-name-2
2-108 Known Problems, Restrictions, and Other Notes
2.9.3 CDD/Repository Does Not Support Delimited Identifiers
The data dictionary does not preserve the distinction
between uppercase and lowercase identifiers. If you use
delimited identifiers with Rdb/VMS, you must be careful
to ensure that the record definition does not include
objects with names that are duplicates except for the case.
For example, the data dictionary considers the delimited
identifiers "Employee_ID" and "EMPLOYEE_ID" to be the same
name.
2.9.4 Minimum Supported Version of CDD/Plus
If you are running VMS V5.4, the minimum CDD/Plus version
number is V4.3. Running with earlier versions of CDD/Plus
under VMS V5.4 may lead to unexpected image exits and other
problems.
2.10 Restrictions Retained from V4.1
This section begins with V4.1 restrictions pertinent to all
users and ends with restrictions specific to SQL, RDO, and
RDML.
2.10.1 Known Problems and Restrictions for All Interfaces in V4.1
Sections 2.10.1.1 through 2.10.5.1 contain known problems
and restrictions for all interfaces. These restrictions
also apply to Rdb/VMS V4.2.
2.10.1.1 Error Message Files Are Altered by DECpresent V1.0
A problem in V1.0 of DECpresent converts files with
the .DOC suffix in SYS$HELP to DDIF format. If you have
installed V1.0 of DECpresent, you will not be able to type,
print, or search the error message files for RMU, RDML,
RDO, Rdb/VMS, or SQL. You will see an error message similar
to the following if you try to do so:
$ TYPE SQL$MSG.DOC
%TYPE-W-OPENIN, error opening SYS$COMMON:[SYSHLP]SQL$MSG.DOC;6 as input
-RMS-F-RFM, invalid record format
To correct this problem, issue the following command using
a privileged account:
$ SET FILE/NOSEM SYS$HELP:*MSG*.DOC
Known Problems, Restrictions, and Other Notes 2-109
This problem will be corrected in a future version of
DECpresent.
2.10.1.2 Detaching from the Database Sometimes Results in a
Bugcheck
When detaching from a database, under certain unknown
conditions it is possible to receive a bugcheck with either
one of the two following exceptions:
***** Exception at ???????? : LCK$DEMOTE + 000000BA
%SYSTEM-F-SUBLOCKS, cannot dequeue a lock with sublocks
The stack trace for this exception is as follows:
LCK$DEMOTE
PIO$UNBIND
KOD$UNBIND
. . .
***** Exception at ???????? : KOD$UNBIND + 000000F9
%SYSTEM-F-SUBLOCKS, cannot dequeue a lock with sublocks
The stack trace for this exception is as follows:
KOD$UNBIND
. . .
The bugcheck occurs because the internal state of the
database does not match that of specific process data
structures. This problem does not occur frequently; when
it does occur, no database corruption results because the
problem occurs very late in the database detach sequence.
Note that this problem seems to occur more frequently when
using VMS V5.5. The reason for this is not known.
There are no known workarounds for this problem. Please
submit an SPR and provide the bugcheck dump as supporting
documentation if you experience this problem.
2.10.1.3 Performance Problem Is Observed with Rdb/VMS Distributed
Update Transactions in a Mixed VMS V5.4 and V5.5
Operating System Environment
If you are using Rdb/VMS V4.1 or later versions on a system
running VMS V5.4 and on another system running VMS V5.5,
when you do a two-phase commit update transaction you may
observe a drop in performance. The decline in performance
is due to the different versions of DECdtm that run on
2-110 Known Problems, Restrictions, and Other Notes
VMS V5.4 and VMS V5.5. Distributed transactions that are
started on different systems running the same version of
the VMS operating system run as expected.
2.10.1.4 Distributed Transaction Abort Error Will Change from a
Warning to an Error in a Future Release of Rdb/VMS
The following warning message displays when a distributed
transaction aborts:
%RDB-W-DISTABORT, distributed transaction was aborted
In a future release of Rdb/VMS, the warning message will
change to an error message:
%RDB-E-DISTABORT, distributed transaction was aborted
2.10.1.5 VMS Lock Remastering Changed in VMS V5.4
Because VMS changed the lock remastering algorithm in VMS
V5.4, the lock trees mastered on one node might migrate
to another node. If the new node (where the locks get
remastered) is a slower node, Rdb/VMS lock requests
might take more time to be processed. You can force the
lock manager to avoid certain nodes as candidates for
remastering by setting the value for LCKDIRWT to 0 for the
respective nodes using SYSGEN. See the VMS documentation
set for more information.
2.10.1.6 Multiversion Problem Exists in Process Environment When
You Run RMONSTOP and RMONSTART Procedures for Either
V4.0 or V4.0A
If you have the multiversion kit installed and either V4.0
or V4.0A are also installed on your system, there is a
problem if you set your process environment to V4.1 or
V4.2 and then execute the RMONSTART or RMONSTOP procedures.
The problem is that the RMU symbol is defined to RMUA and
activates the wrong RMU image. Note that this is not a
problem in procedures such as RMONSTART41 or RMONSTOP41
because these procedures call RMUA directly.
This is a known problem for V4.0 and V4.0A running with the
multiversion V4.1 or V4.2.
There are four workarounds to this problem:
o Delete the RMU symbol before you execute RMONSTOP or
RMONSTART.
Known Problems, Restrictions, and Other Notes 2-111
o Run RDBVMS_SETVER S before you execute RMONSTOP or
RMONSTART.
o Make sure that you have not run RDBVMS_SETVER before
executing RMONSTOP or RMONSTART.
o Modify the RMU section of the RMONSTART.COM and
RMONSTOP.COM procedure files.
The V4.0 or V4.0A RMONSTART.COM procedure file should be
modified as follows:
$ ! Look for the following code:
$ RMU/MONITOR START 'P1
$ IF $SEVERITY THEN GOTO GOOD_NEWS
$ GOTO EXIT
$ !
$ ! Replace that code with what follows:
$ !
$ IF CUR_VAR .EQS. "" THEN GOTO START_MON_STANDARD
$ START_MON_MV:
$ RMU/MONITOR START 'P1
$ IF $SEVERITY THEN GOTO GOOD_NEWS
$ GOTO EXIT
$ START_MON_STANDARD:
$ IF F$TYPE(RMU) .EQS. "STRING"
$ THEN
$ SAVE_RMU = ""'RMU'""
$ DELETE/SYMBOL/GLOBAL RMU
$ ENDIF
$ RMU/MONITOR START 'P1
$ IF F$TYPE(SAVE_RMU) .EQS. "STRING" THEN RMU :== 'SAVE_RMU
$ IF $SEVERITY THEN GOTO GOOD_NEWS
$ GOTO EXIT
The V4.0 or V4.0A RMONSTOP.COM procedure file should be
modified as follows:
2-112 Known Problems, Restrictions, and Other Notes
$ ! Look for the following code:
$ RMU/MONITOR STOP/WAIT
$ IF $SEVERITY THEN GOTO GOOD_NEWS
$ GOTO BAD_NEWS
$ !
$ ! Replace that code with what follows:
$ !
$ IF CUR_VAR .NES. "" THEN GOTO STOP_MON_MV
$ STOP_MON_STANDARD:
$ IF F$TYPE(RMU) .EQS. "STRING"
$ THEN
$ SAVE_RMU = ""'RMU'""
$ DELETE/SYMBOL/GLOBAL RMU
$ ENDIF
$ RMU/MONITOR STOP/WAIT
$ IF F$TYPE(SAVE_RMU) .EQS. "STRING" THEN RMU :== 'SAVE_RMU
$ IF $SEVERITY THEN GOTO GOOD_NEWS
$ GOTO BAD_NEWS
$ STOP_MON_MV:
$ RMU/MONITOR STOP/WAIT
$ IF $SEVERITY THEN GOTO GOOD_NEWS
$ GOTO BAD_NEWS
2.10.1.7 System Table Changes from V4.0 to V4.2 Cause DEC
RdbExpert for VMS V1.0 to Fail with NONULLIND Error
The columns RDB$QUERY_NAME and RDB$EDIT_STRING take
up considerable space in the Rdb/VMS V4.0 and earlier
databases for system tables. These columns appear in the
tables RDB$FIELDS, RDB$RELATION_FIELDS, and RDB$FIELD_
VERSIONS.
In Rdb/VMS V4.1, the structure of the system tables was
modified so that these columns are now set to NULL and
take up very little space for columns that do not use
these attributes. (These attributes are used mainly for
DATATRIEVE and interactive SQL support.) In addition,
the new column RDB$SECURITY_CLASS is also NULL unless the
database is created using DEC SERdb for Security-Enhanced
VMS software.
In general, you should treat all columns from system tables
as if they could return a NULL value; that is, you should
supply an INDICATOR variable for each column on all queries
against the system tables.
Known Problems, Restrictions, and Other Notes 2-113
This change also shows an error in DEC RdbExpert for VMS
V1.0, which fails with the error NONULLIND when you try to
import the schema definition under Rdb/VMS V4.1 or V4.2.
This error has been fixed in DEC RdbExpert for VMS V2.0.
2.10.1.8 Comparing Integer and Text Fields Causes Problems
Versions of Rdb/VMS after V4.0 do not tolerate using a
text field with leading zeroes for qualification against
a numeric field in the database in a program. Although
this was not good coding practice, Rdb/VMS returned a
'data not found' message rather than a message indicating
that the syntax was unacceptable.
In addition, in interactive SQL an informational message
displayed whenever an integer-to-text conversion was
carried out during comparisons:
SQL> SELECT * FROM EXTRACT_SERIAL WHERE
cont> X_SER_INDEX_NO = '0328913';
%SQL-I-NUMCMPTXT, Numeric column will be compared with string literal as text
This problem will be fixed in a future release of Rdb/VMS.
2.10.1.9 Fractional Seconds Precision Is Not Handled Correctly
Fractional seconds precision can be specified for the new
data types TIME, TIMESTAMP, and INTERVAL (which contains
the SECOND field). The value for fractional seconds
precision can be 2, 1, or 0, which represents 100ths of
a second, tenths of a second, or no fractional seconds,
respectively.
When converting data types containing a large fractional
seconds precision to a lower precision, Rdb/VMS does
not correctly truncate the value, but simply carries the
same fractional portion to the new column. For example,
when storing data from a TIMESTAMP(2) column into TIME(0)
column, it carries over the the time column fractional
seconds from the timestamp to instead of truncating them.
This can result in a mismatch on equality queries where
only the whole seconds are supplied.
In addition the CURRENT_TIME and CURRENT_TIMESTAMP values
when assigned to columns of type TIME(1), TIME(0),
TIMESTAMP(1), and TIMESTAMP(0), will also result in
unexpected fractional second values.
2-114 Known Problems, Restrictions, and Other Notes
To view the actual stored values you can use the CAST
operator to convert the data to DATE VMS.
SELECT CAST(TIME_STAMP AS DATE VMS)
FROM T;
This problem will be corrected in a future release of
Rdb/VMS. In the meantime use INTERVAL . . . SECOND(2),
TIME(2), and TIMESTAMP(2) definitions.
2.10.1.10 Placement Using Sorted Indexes Can Result in
Performance Degradation over Time as Rows Are Added and
Index Key Values Updated
When a sorted placement index is used to store rows in a
storage area, each row is stored in index key sequence near
its pointer record in the index node record. Storage begins
at the first available page in the storage area immediately
following the space area management (SPAM) page. As each
page is filled, the next available page in sequence is
used to store rows, and so forth. Once an index node
record becomes full, a new index node record is written
on the next available page. A forward pointer is written
in the original node record, chaining it to the new index
node record. Thus, each row is stored in the storage area
in index key sequence in close proximity to its pointer
record, starting at the beginning of the storage area and
continuing until all table rows and index node records are
stored.
After a data load operation, range retrieval performance
is optimal because rows and their pointer records are as
closely placed to one another as possible under the default
or specified tuning parameters. Range retrieval of rows
is possible in one to a few I/O operations assuming that
page size, index parameters such as node size and percent
fill, and buffer sizes are tuned to optimize retrieval
performance for the application.
It is only after new rows are inserted in the database
or many updates are made to index key column data values
following an initial data load operation that you can
expect range retrieval performance to slowly degrade. The
reason is simple. New rows are stored on the next available
page with space, usually after the last full page in the
storage area.
Known Problems, Restrictions, and Other Notes 2-115
Index row pointer entries, however, are inserted in each
respective index node record that should contain the new
index key column value. This results in a row and index
pointer record page displacement greater than what normally
occurs under an initial data load operation. Furthermore,
as row pointers are added to index nodes, node records
are forced to split and rebalance. New node records are
then written on the next page after the last full page
in the storage area, causing additional displacement from
existing rows. As rows are updated, rows never move but
their pointer records are updated and relocated if the
index key column value for the rows changes; the pointer
record is relocated to the appropriate node record to
maintain index key sequence. Again, as node records split
and rebalance, rows and their node record pointers can be
displaced further and further from each other. Therefore,
page displacement is possible with the addition of new rows
or update of existing rows.
This physical page displacement of each node pointer record
from its data row leads to a degradation in retrieval
performance. Over time with the addition of more new data
and changed key index column values, more I/O operations
are needed to bring a specified range retrieval of index
key values and associated rows into a buffer. Eventually,
performance can be poor.
The workaround to this problem is to occasionally unload
and reload the data in the storage area to optimally
minimize the page displacement of each index node record
pointer with its row. Prior to reloading the data,
reexamine index and storage space parameters to see
if further tuning is possible to optimize retrieval
performance.
2.10.1.11 Deleted Space Is Not Reused Until the Next Database
Attach
A CREATE INDEX statement following a DROP INDEX statement
does not reuse the space made available by the previous
statement, as shown in the following MF_PERSONNEL database
example. As a result, when you display the page numbers
used, they are different.
2-116 Known Problems, Restrictions, and Other Notes
SQL> CREATE INDEX INDEX1 ON EMPLOYEES (LAST_NAME) STORE IN RDB$SYSTEM;
SQL> COMMIT;
SQL> $ RMU/DUMP/LAREA=INDEX1 MF_PERSONNEL
SQL> DROP INDEX INDEX1;
SQL> COMMIT;
SQL> CREATE INDEX INDEX1 ON EMPLOYEES (LAST_NAME) STORE IN RDB$SYSTEM;
SQL> COMMIT;
SQL> $ RMU/DUMP/LAREA=INDEX1 MF_PERSONNEL
This behavior is a restriction in Rdb/VMS V4.1.
Rdb/VMS V4.1 does not reclaim clumps belonging to a table
or index until the process that deleted that clump has
disconnected using the DISCONNECT or FINISH statement.
Technically the restriction could be that the clump cannot
be reclaimed until the transaction that deleted the page
has committed. The following clarification explains why.
For uniform areas, a table (or index) is deleted by marking
all the entries in the space area management (SPAM) page
for that table as deleted. Furthermore, the entry for
that table in the area inventory page (AIP) is marked as
deleted. Note that the actual clumps belonging to that
table have not been touched. Also, when the SPAM pages and
AIP are marked as deleted, the transaction ID (TID) of the
deleting process is written into these data structures.
Now assume that one of these deleted clumps is reclaimed.
This clump is marked as belonging to the new table (or
index) and the pages in the clump are initialized to look
like empty pages. Note that doing this eliminates all
the records belonging to the deleted table. Because no
information on this page was journaled to the RUJ when
the table was deleted, there is no way to bring back these
records in case of transaction rollback. For this reason,
deleted clumps cannot be reclaimed while the transaction
that deleted them is still active.
Now the problem is that when a clump is deleted the TID
of the deleting process is put in the SPAM page (and not
the transaction sequence number (TSN) of the deleting
transaction). Hence, Rdb/VMS has no way of knowing whether
a clump was deleted in the current transaction or in a
previously committed transaction. Why not store the TSN
instead of the TID? Unfortunately, TIDs are 2 bytes in size
Known Problems, Restrictions, and Other Notes 2-117
and TSNs are 4 bytes in size. Hence, there is not enough
space in the SPAM page to store TSNs; this would require
all existing databases to be converted.
Digital is examining ways of changing this algorithm to
allow the reuse of clumps in a more efficient way (given
the previous restrictions) in a future version of Rdb/VMS.
2.10.1.12 Digital Does Not Support Access to Rdb/VMS Through an
Asychronous System Trap (AST) Service Routine in a User
Application
Digital does not support access to Rdb/VMS through an AST
service routine in a user application. This means Digital
cannot guarantee predictable behavior for any application
that accesses Rdb/VMS through an AST service routine and
cannot guarantee that an application will behave the same
way from one release to the next. Digital will not be
responsible for problems that ensue due to any application
accessing Rdb/VMS through an AST service routine.
In the Introduction to VMS System Services, the text under
the heading "AST delivery" states:
An AST cannot be delivered under...the following conditions:
An AST service routine is currently executing at the same or at a more
privileged access mode.
Digital does not support access to Rdb/VMS through an AST
service routine in a user application because several of
the functional components of Rdb/VMS, such as Rdb/Dispatch,
run in user mode and may make use of AST service routines.
Also, the use of AST service routines in these user mode
components may vary from one release to the next. Because
an AST cannot be delivered while an AST service routine is
"currently executing at the same mode or more privileged
access mode," it is possible that the AST service routine
in an application could prevent delivery of an AST in one
of the user mode components of Rdb/VMS. This could lead
to unpredictable behavior or even application failure.
Applications that currently contain such AST service
routines should be rewritten to avoid accessing Rdb/VMS
through an AST service routine.
2-118 Known Problems, Restrictions, and Other Notes
2.10.1.13 Multiplex Feature Should Be Disabled if Remotely
Attaching to V3.1 or V4.0 Databases
If you need to remotely attach databases to V4.1 or higher
and a previous version such as V3.1.B or V4.0, you will
need to disable the multiplex feature. To do this, define
the logical name RDB$REMOTE_MULTIPLEX_OFF as "1".
Defining this logical name will disable the multiplex
feature available in V4.1 or higher. The client and server
capabilities are incompatible when versions are mixed.
2.10.1.14 Using Quoted Threshold Values for Binary Data Types for
Partitioning Data or Indexes Results in Data or Index
Corruption
Data or index corruption can result from using quotes
around threshold values for the signed quadword, signed
longword, signed word, and signed byte data types when you
partition data and indexes, as the following example shows:
RDO> DEFINE DATABASE MIKE DICTIONARY IS NOT USED
cont> DEFINE STORAGE AREA ST1 FILENAME ST1 END ST1 STORAGE AREA
cont> DEFINE STORAGE AREA ST2 FILENAME ST2 END ST2 STORAGE AREA
cont> DEFINE STORAGE AREA ST3 FILENAME ST3 END ST3 STORAGE AREA
cont> DEFINE STORAGE AREA ST4 FILENAME ST4 END ST4 STORAGE AREA
cont> DEFINE STORAGE AREA ST5 FILENAME ST5 END ST5 STORAGE AREA
cont> DEFINE STORAGE AREA ST6 FILENAME ST6 END ST6 STORAGE AREA
cont> DEFINE STORAGE AREA ST7 FILENAME ST7 END ST7 STORAGE AREA.
RDO> DEFINE FIELD BILL DATA SIGNED QUADWORD.
%RDO-W-NOCDDUPDAT, database invoked by filename, the CDD will not be
updated
RDO> DEFINE FIELD ACCT_NO DATA TEXT SIZE 5.
RDO> DEFINE RELATION ACCT. BILL. ACCT_NO. END.
RDO> COMMIT
RDO> DEFINE INDEX I1 FOR ACCT DUPLICATES ARE NOT ALLOWED
cont> STORE USING BILL WITHIN
cont> IST1 WITH LIMIT OF "01";IST2 WITH LIMIT OF "03";IST3 WITH LIMIT OF "05";
cont> IST4 WITH LIMIT OF "07";IST5 WITH LIMIT OF "09";IST6 WITH LIMIT OF "11";
cont> IST7.
cont> BILL. ACCT_NO. END.
Known Problems, Restrictions, and Other Notes 2-119
RDO> COMMIT
RDO> DEFINE STORAGE MAP ACCT_MAP FOR ACCT RELATION
cont> STORE USING BILL WITHIN
cont> ST1 WITH LIMIT OF "01";ST2 WITH LIMIT OF "03";ST3 WITH LIMIT OF "05";
cont> ST4 WITH LIMIT OF "07";ST5 WITH LIMIT OF "09";ST6 WITH LIMIT OF "11";
cont> ST7 END.
RDO> COMMIT
RDO> START_TRANSACTION READ_WRITE
cont> STOR A IN ACCT USING A.BILL=1;A.ACCT_NO="1" END_STORE
cont> STOR A IN ACCT USING A.BILL=11;A.ACCT_NO="11" END_STORE
cont> STOR A IN ACCT USING A.BILL=3;A.ACCT_NO="3" END_STORE
cont> STOR A IN ACCT USING A.BILL=5;A.ACCT_NO="5" END_STORE
cont> STOR A IN ACCT USING A.BILL=15;A.ACCT_NO="15" END_STORE
cont> STOR A IN ACCT USING A.BILL=7;A.ACCT_NO="7" END_STORE
cont> STOR A IN ACCT USING A.BILL=9;A.ACCT_NO="9" END_STORE
RDO> COMMIT
RDO> FOR A IN ACCT WITH A.BILL EQ 5 PRINT A.* END_FOR
RDO> FOR A IN ACCT WITH A.BILL LE 5 PRINT A.* END_FOR
If you have data and index records stored in the wrong
partition for a table, reload the table with a storage
map that does not use quotes around the threshold values
for the signed quadword, signed longword, signed word, and
signed byte data types. Quotes are permitted around the
TEXT data type values and work correctly.
This is a known restriction for Rdb/VMS V4.1 and V4.2.
2.10.1.15 Triggers That Affect Subject Table Rows Can Cause Loops
or Inconsistent Results
Triggers that update rows of the trigger subject table or
add rows to the trigger subject table can cause infinite
loops or inconsistent results to be returned, as in the
following two conditions:
o A BEFORE UPDATE trigger on table X that inserts a row
into table X
o An UPDATE statement affecting all the rows in table X
Considering these two conditions, the UPDATE statement will
loop until all resources are consumed because for each row
updated, a new row will be added, which in turn will be
updated, and so forth.
2-120 Known Problems, Restrictions, and Other Notes
When subject table rows are being retrieved using an index,
a triggered action operating on the same table could affect
the index (by changing index key values or adding new keys)
such that the triggering statement behaves in a different
manner than when no trigger is involved.
Currently, only avoidance methods can be suggested for
this problem. The best avoidance method is to construct any
such triggers to operate only on rows that are either the
current subject table row, or that will never be selected
by the triggering statement. A more difficult avoidance
method is to restructure triggering statements such that
they never select a row that could have been updated or
added by a trigger action. Some circumstances will require
a combination of these methods.
2.10.1.16 Collating Sequences Producing Too Many Nulls May Result
in a Bugcheck Dump
If you attempt to define a database with the following
collating sequence, a bugcheck dump results with an
exception at RDMS$$MCS$NCS_RECODE_8 + 00000665.
native_2_upper_lower = cs(
sequence = (%X00,"#"," ","A","a","B","b","C","c","D","d","E",
"e","8","F","f","5"-"4","G","g","H","h","I","i","J","j","K","k",
"L","l","M","m","N","n","9","O","o","1","P","p","Q","q","R","r",
"S","s","7"-"6","T","t","3"-"2","U","u","V","v","W","w","X","x",
"Y","y","Z","z"),
modifications = (%X01-%X1F=%X00,"!"-""""=%X00,"$"-"0"=%X00,":"-"@"=%X00,
"{"-%XFF=%X00,""="A"));
The modifications portion of the collating sequence results
in too many characters being converted to NULL. Rdb/VMS can
handle only about 80 character conversions to NULL. This is
a restriction in V4.1 and previous versions of Rdb/VMS.
A workaround is to modify the MULTINATIONAL2 character set
to sort in the desired order.
Known Problems, Restrictions, and Other Notes 2-121
2.10.1.17 You Cannot Correctly Import a Database That Contains
Computed-By Columns That Reference Other Computed-By
Columns
In an import operation, if a database contains a table
with a computed-by column that is dependent on another
computed-by column in another table, the import operation
completes, but all computed-by columns in the group fail
to be created. Rdb/VMS cannot define the computed-by column
because the computed-by column that is referenced is not
yet defined.
Beginning with V4.0, and continuing to V4.0A, V4.0B, and
V4.1, you cannot use computed-by columns that reference
other computed-by columns in a database. The database
cannot be imported correctly. This change was made to
the import operation to improve performance of tables
containing many computed-by columns. In versions previous
to V4.0, each computed-by column was created one column
at a time, causing excessive numbers of table versions
(RDB$FIELD_VERSIONS) to be created. Starting in V4.0 all
computed-by columns are defined as a group, thus saving
hours of import operation time. The side effect is that if
one of the computed-by columns contains a dependency on a
computed-by column in another table then all the computed-
by columns in the group fail to be created.
There are two workarounds to this problem.
o Redefine the computed-by columns so that there are no
references to other computed-by columns.
o Before exporting the database, delete all computed-
by columns that reference other computed-by columns.
After the import operation, re-create the computed-by
columns that reference other computed-by columns. To
simplify this procedure, you can create a short SQL or
RDO script to run before each export operation and after
each import operation that accomplishes this action.
2-122 Known Problems, Restrictions, and Other Notes
2.10.1.18 RDO Relation Name Must Match Dictionary Record Name
If you define a relation using a CDD/Repository path name,
the relation name must match the record name. For example,
the following statement contains an error. (The statement
can be processed, but problems will occur later.)
RDO> DEFINE RELATION AAAA FROM PATHNAME 'CDD$TOP.TEST.XXXX'.
The correct form of the statement is as follows:
RDO> DEFINE RELATION AAAA FROM PATHNAME 'CDD$TOP.TEST.AAAA'.
This is a known restriction that was first documented in
the V3.0 VAX Rdb/VMS Release Notes. This restriction does
not occur in SQL.
2.10.1.19 Certain Reserved Words Cannot Be Used as Database
Handles for RDBPRE or as Aliases for SQL$PRE and
SQL$MOD
The following words cannot be used as database handles for
RDBPRE or as aliases for SQL$PRE and SQL$MOD (the ALIAS or
DBHANDLE is used to name a PSECT or GLOBAL SYMBOL):
o IV
o R0, R1, R2 . . . R15
o AP
o SP
o FP
Though not documented in the current release of VAX MACRO,
these words are all reserved symbols in VAX MACRO. For
this reason, these symbols cannot be used in the generated
code. This will be documented as a restriction in a future
version of VAX MACRO. Note that these reserved symbols are
also not trapped in the language precompilers so no warning
message is generated by Rdb/VMS.
2.10.2 SQL Note of General Interest for V4.1
Section 2.10.2.1 describes a note of general interest to
SQL users.
Known Problems, Restrictions, and Other Notes 2-123
2.10.2.1 Using the SMALLINT Data Type and VAX C
If you have a column in a table that uses the SMALLINT(2)
data type, because VAX C does not support scaled exact
numerics, you must have SQL do the conversion for you. For
example, if you are fetching three columns from a table,
use a cursor. The SQL module language module might look as
follows:
MODULE MUMBLE
LANGUAGE C
AUTHORIZATION RUMBLE
DECLARE my_cursor CURSOR FOR
SELECT X, Y, Z
FROM T
WHERE W = IN_DATA
PROCEDURE OPEN_CURSOR
SQLCODE
IN_DATA CHAR(4);
OPEN my_cursor;
PROCEDURE FETCH_EM
SQLCODE
A CHAR(5)
B CHAR(10)
C REAL; -- this corresponds to column Z of type
SMALLINT(2)
FETCH my_cursor INTO A, B, C;
PROCEDURE CLOSE_CURSOR
SQLCODE;
CLOSE my_cursor;
The C program might look as follows:
main()
{
long sqlcode;
static char in[5] = "0001";
static char out_a[6];
static char out_b[11];
static float out_c;
2-124 Known Problems, Restrictions, and Other Notes
OPEN_CURSOR(&sqlcode, in);
if (sqlcode < 0)
{
printf("Error opening cursor\n");
return;
}
while (1)
{
FETCH_EM(&sqlcode, out_a, out_b, &out_c);
if (sqlcode == 100)
break;
if (sqlcode < 0)
{
printf("Error fetching from cursor\n");
return;
}
printf("%s, %s, %f\n", out_a, out_b, out_c);
}
CLOSE_CURSOR(&sqlcode);
if (sqlcode < 0)
{
printf("Error closing cursor\n");
return;
}
}
Note the mapping of the REAL parameter to a float host
variable.
If you use DOUBLE PRECISION, remember that Rdb/VMS and
SQL use G_FLOAT by default, whereas VAX C uses D_FLOAT
by default. Your application will need to handle this
situation.
2.10.3 SQL Known Problems and Restrictions in V4.1
Sections 2.10.3.1 through 2.10.3.6 describe known problems
and restrictions in SQL for V4.1. See also Section 2.10.5.4
for more information on RDO import and export known
problems and restrictions in V4.1.
Known Problems, Restrictions, and Other Notes 2-125
2.10.3.1 CREATE DATABASE Statement Must Lexically Precede Any
DECLARE TABLE Statement in Precompiled Module or Module
Language
If a DECLARE TABLE statement appears before a CREATE
DATABASE statement, your compilation could fail with an
error message indicating that SQL$DATABASE could not be
opened or that certain database objects could not be found
in your database.
The SQL precompiler and module language compiler process
metadata statements before other statements. If your
DECLARE TABLE statement is found before the CREATE DATABASE
(or CREATE ALIAS) statement that defines it, then SQL will
try to attach to SQL$DATABASE for the metadata lookups.
A workaround is to place your CREATE DATABASE or CREATE
ALIAS statement before your DECLARE TABLE statements.
2.10.3.2 SQL Users Using the Multiversion Kit Must Link with the
SQL$USER Logical Name
If you are using the multiversion kit and the SQL
interface, you must link with the SQL$USER logical name
instead of SYS$SHARE:SQL$USER.OLB.
2.10.3.3 You Cannot Import a Multischema Database to Earlier
Versions
If an exported database had multischema enabled, the
interchange file produced cannot be used by earlier
versions of Rdb/VMS to create a similar database. If a
limited amount of information is lost, Digital recommends
exporting the database using the NO EXTENSIONS clause.
Alternatively, the database could be exported and imported
within V4.1 by disabling MULTISCHEMA in the SQL IMPORT
statement (specifying MULTISCHEMA is OFF). Then, an
interchange file produced for the database should be
useable in earlier versions.
2.10.3.4 You Cannot Use EXPORT WITH NO EXTENSIONS if INTERVAL Is
Defined
It is not possible to export a database using the WITH
NO EXTENSIONS clause if it contains INTERVAL domains.
Digital recommends either removing the offending domains
(and related columns) or performing the EXPORT operation
without the WITH NO EXTENSIONS clause.
2-126 Known Problems, Restrictions, and Other Notes
2.10.3.5 SQL Object Module Incompatibility
Incompatibilities between object modules were created
in Rdb/VMS V4.0A and previous versions of Rdb/VMS. This
means that if you relinked an application with V3.1B object
modules (especially ones with cursors), you received error
messages. For example, you might receive the following
SQLCODE-1005 message:
%RDB-E-BAD_TRANS_HANDL, invalid transaction handle
These incompatibilities were addressed in Rdb/VMS V4.0B.
The current status is as follows:
o V4.0 and V4.0A object modules (.OBJ) are compatible
with each other, but not compatible with object modules
compiled with any other version of SQL.
o Executable images (.EXE) compiled using V3.1B (or
earlier) are compatible with all versions of SQL. Users
who upgrade directly from V3.1B to V4.0B do not have to
recompile.
o V4.0 and V4.0A executable images are compatible with
each other, but not compatible with V4.0B and future
releases. Users with V4.0 or V4.0A object modules must
recompile those V4.0 or V4.0A modules prior to relinking
under V4.0B or later versions.
o V3.1B (and earlier) object modules are compatible with
V4.0B (and future release) object modules.
o When fixing a problem with handling null terminated
strings in C programs, an incompatibility was
introduced.
A workaround is to use the following SQL$MOD qualifier:
/[NO]FIXED_CDD_STRINGS
This SQL$MOD qualifier is the same as the SQL$PRE
qualifier /SQLOPTIONS=[NO]FIXED_CDD_STRINGS.
These qualifiers set the default behavior for how text
n fields are interpreted from CDD records for the C
preprocessor. The default behavior is that a text field
is treated as a null terminated string of n-1 data bytes
and 1 null byte. The /FIXED_CDD_STRINGS qualifier treats
the field as n data bytes and no null byte.
Known Problems, Restrictions, and Other Notes 2-127
In summary, if you relink and do not recompile under V4.0
and V4.0A, you will encounter errors.
The goal is to maintain compatibility between versions,
implying the following:
o Executable images from previous versions work in newer
versions.
o Object modules from previous versions can be linked with
newly compiled object modules.
2.10.3.6 Confusion over the Use of ASCII and ASCIZ in Dynamic SQL
and C Programs
When a CHAR data type is written to the database using
INSERT or UPDATE, the string is not blank-padded; it
contains a null-terminated character, which makes it
difficult to access the data.
SQL does not know what the host language is when using
dynamic SQL; it returns the data type of the field as
in the DESCRIBE statement, (CHAR(n)), and not the data
type of the user's host variable. The interpretation of
CHAR(n) being ASCIZ is for host variables and not database
variables.
If you change the SQLDA's SQLTYPE to ASCIZ and increase
SQLLEN by 1, no truncation should occur and the CHAR STRING
fields will be blank-padded accordingly (where incrementing
SQLLEN by 1 accounts for the null terminator).
2.10.4 SQL/Services Known Problems and Restrictions in V4.1
Sections 2.10.4.1 through 2.10.4.8.4 describe known
problems and restrictions in SQL/Services for V4.1.
2.10.4.1 Process Logical Names Are Not Supported in SQL/Services
When you provide the file specification for an Rdb/VMS
database within the SQL/Services system, use one of the
following methods to specify a database:
o Use a system or group logical name.
o Provide a full file specification.
Process logical names are ignored by SQL/Services.
2-128 Known Problems, Restrictions, and Other Notes
You can find database file specifications in client API
applications, the SQL/Services sample application, or in
configuration file definitions.
2.10.4.2 SQL/Services IVP Fails with-2034 Error Under Rdb/VMS
V4.1
This problem can occur when the IVP is being run separate
from the original Rdb/VMS V4.1 installation, and no
systemwide default version of Rdb/VMS has been declared
by using the SYS$LIBRARY:RDBVMS_SETVER command file.
The SQL/Services IVP fails with the following error:
Running the SQL/Services tests.
Running SQL/Services D_FLOAT test
Assigning System-wide SQLSRV Logicals
Starting the SQL Services Server
VAX SQL Services sample program failed
SQLCA: SQLCODE: -2034 SQLERRD[0]: 0 SQLERRD[2] 0
%NONAME-E-NOMSG, Message number 00000002
**** VAX SQL Services test failed ****
The SQL Services IVP program expects to find the Rdb/VMS
multiversion logical names defined, and will fail with the-
2034 (GETACCINF) error when the multiversion logical names
are not defined.
A workaround is to define the systemwide Rdb/VMS
multiversion logical names using the following command
and run the SQL/Services IVP again, for example:
$ @SYS$LIBRARY:RDBVMS_SETVER 4.1 /SYSTEM
2.10.4.3 SQL/Services Compatibility Issue with the Order of
Include Files
With Rdb/VMS V4.1, direct access to SQLDA and SQLCA
structures is supported but is not recommended by Digital.
If direct access is used, the order of the SQL/Services
include files must be as follows:
#include <sqlsrvca.h>
#include <sqlsrvda.h>
#include <sqlsrv.h>
Known Problems, Restrictions, and Other Notes 2-129
Compile errors will result if the include files are not in
this order.
The sample program provided with SQL/Services releases
before V4.1 uses direct access to the SQLDA and SQLCA and
does not have the include files in the preceding order. If
the V4.0 sample program (or an application modeled after
the sample program) is compiled against the V4.1 include
files, the include files must first be reordered.
2.10.4.4 New DATE, TIME, TIMESTAMP, and INTERVAL Data Types Are
Not Directly Supported by SQL/Services
The SQLDA structure is used by dynamic SQL to represent
the full data type information for a column. That is, it
is used to return the column or values data type, length,
scale, and so forth. This structure is used by SQL/Services
to pass information.
The new date-time data types contain more attributes than
can be described by the SQLDA, so the new SQLDA2 is used.
This structure in Rdb/VMS V4.1 is currently not supported
by SQL/Services.
Applications that need to use these new data types should
use the following workarounds:
o When a DATE (ANSI), TIME, TIMESTAMP, or INTERVAL data
type is selected it should be embedded in a CAST()
function and cast to either CHAR, VARCHAR, or DATE VMS.
For example, assume AGE is an INTERVAL YEAR TO MONTH.
SELECT CAST(AGE AS VARCHAR(20))
INTO ?
FROM table;
o Alternately, the EXTRACT() function can be used to
extract each field of the DATE (ANSI), TIME, TIMESTAMP,
or INTERVAL.
For example, assume AGE is an INTERVAL YEAR TO MONTH.
SELECT EXTRACT(YEAR FROM AGE), EXTRACT(MONTH FROM AGE)
INTO ?, ?
FROM table;
This will cause the data to be returned in a format that
can be described in the SQLDA.
2-130 Known Problems, Restrictions, and Other Notes
2.10.4.5 Problem with SQL/Services Cdev for the Macintosh and the
New Release of PATHWORKS for Macintosh V1.1
The SQL/Services Cdev for the Macintosh does not function
properly with the new release of PATHWORKS for Macintosh
V1.1. You are not able to select an AppleTalk-DECnet
Gateway as explained in the following excerpt from the
PATHWORKS release notes:
AppleTalk-DECnet Gateway changes
With PATHWORKS for Macintosh V1.1, it is no longer possible to
select the AppleTalk-DECnet Gateway from the Chooser. Gateway
selection is now done with the AppleTalk Gateway Tool, itself.
Desktop ACMS V1.0
Because Desktop ACMS V1.0 does not yet support the new mechanism
for selecting the AppleTalk-DECnet Gateway, installing the
AppleTalk-DECnet Tool from PATHWORKS for Macintosh V1.1 breaks
current Desktop ACMS solutions that use this tool.
There are two workarounds for this problem:
o Install the PATHWORKS for Macintosh V1.1 kit. Before running
your Desktop ACMS client programs, select some other program
such as MacTerminal that allows you to specify the
AppleTalk-DECnet Tool when setting connection parameters
within the context of the application. After selecting the
tool and specifying the gateway you want to use, exit
MacTerminal and run your Desktop ACMS clients.
o Before installing PATHWORKS for Macintosh V1.1, rename your
current AppleTalk-DECnet Tool. After completing the
PATHWORKS for Macintosh installation, delete the V1.1
AppleTalk-DECnet Tool and restore the V1.0 AppleTalk-DECnet
Tool to its original name.
Most PATHWORKS for Macintosh V1.1 facilities can run with the
V1.0 tool; however, you will lose certain enhancements in the
tool itself.
Known Problems, Restrictions, and Other Notes 2-131
2.10.4.6 Invalid Length Is Returned by SQLSRV_VARBYTE Data Type
The SQL/Services sqlsrv_prepare routine returns incorrect
SQLLEN values for SQLSRV_VARBYTE data type fields not
created with an explicit length. Digital recommends
that tables be created with explicit values as specified
by the LIST OF BYTE VARYING option of the CREATE TABLE
statement. See the VAX Rdb/VMS SQL Reference Manual for
syntax details.
When an explicit length is not specified, programmers can
obtain the valid maximum segment size within the result
stream from a call to the sqlsrv_open_cursor routine.
Refer to the VAX Rdb/VMS Guide to Using SQL/Services for
the values that SQL puts in the SQLCA SQLERRD array after
successful execution of a sqlsrv_open_cursor routine for
list cursors.
Programmers are responsible for setting field lengths and
allocating buffers, either by direct modification of the
SQLLEN field in the SQLDA data structure or by using the
sqlsrv_sqlda_bind_data routine. Look for information about
the sqlsrv_sqlda_bind_data functional interface routine in
the VAX Rdb/VMS Guide to Using SQL/Services.
2.10.4.7 Allocating Space for SQLSRV_VARCHAR and SQLSRV_VARBYTE
Data Types Can Cause a Problem
Be sure to specify the correct length for the SQLSRV_
VARCHAR and SQLSRV_VARBYTE data types in your API
applications. SQL/Services does not issue an error message
when the size of the data fields for SQLSRV_VARCHAR and
SQLSRV_VARBYTE data types exceeds the size of the SQLLEN
field in the SQLDA data structure.
2.10.4.8 SQL/Services Compatibility Issues
This section describes the differences among various
versions of SQL/Services that affect software
compatibility.
2-132 Known Problems, Restrictions, and Other Notes
2.10.4.8.1 SQL/Services (V4.0 or Higher) Server Uses Proxy-
Like and Default Access to Authorize V3.0 or 3.1 Client
Applications Explicit access authorization is never
granted to an SQL/Services API client application (Rdb/VMS
V3.1) seeking access to an SQL/Services server (Rdb/VMS
V4.0 or higher, here referred to as V4.x); however, the
SQL/Services communication server (V4.x) does authorize
access to incoming SQL/Services client application (V3.1)
requests using either the proxy-like or default access
method.
For the SQL/Services server (V4.x) to grant explicit
access, you must upgrade your Rdb/VMS V3.0 or 3.1 system to
Rdb/VMS V4.x. As an interim measure, should you choose to
upgrade Rdb/VMS at a later date, set up an SQLSRV$PROXY.DAT
file on the server system to link incoming user names with
local server system accounts. Refer to the VAX Rdb/VMS
Guide to Using SQL/Services for further information.
2.10.4.8.2 SQL/Services V4.0, V4.0A, V4.0B, or V4.1 Server
Error -2031 Returned to V3.1 Client APIs The SQL/Services
V3.1 Application Programming Interface (API) receives the
SQLSRV_APINOTSUP (-2031) error mnemonic when it cannot
interpret information returned by the SQL/Services Rdb/VMS
V4.0, 4.0A, 4.0B, or V4.1 communication server. For
example, the SQL/Services Rdb/VMS V3.1 API receives the
SQLSRV_APINOTSUP error when a V3.1 API application attempts
to access list cursor data.
2.10.4.8.3 Queue Manager Must Be Started for the
SQL/Services IVP to Work The queue manager must be
started for the SQL/Services installation verification
procedure (IVP) to work. If the VMS queue manager is not
started when the SQL/Services IVP runs, the IVP fails with
the following error:
SQLCA: SQLCODE: -2003 SQLERRD[0]: x20a4 SQLERRD[2] 0
Known Problems, Restrictions, and Other Notes 2-133
2.10.4.8.4 SQL/Services IVP Failure Caused by -2003 Network
Error SQL/Services displays a set of secondary status
codes when the SQL/Services IVP fails with a -2003 error,
indicating an error that is issued from the network.
SQL/Services displays the status codes placed in the SQLCA
SQLERRD[0] field in a message like the one that follows:
SQLCA: SQLCODE: -2003 SQLERRD[0]: error-status-code SQLERRD[2]0
The SQL/Services IVP for Rdb/VMS V4.0 or higher fails
with either the 8436 - SS$_LINKEXIT or 8348 - SS$_INVLOGIN
status code if SQLSRV is defined as a DECnet object.
With Rdb/VMS V4.0 or higher, the SQL/Services communication
server automatically declares itself as a network object.
This differs from the approach taken in Rdb/VMS V3.1, where
the SQL$STARTUP.COM procedure defines SQLSRV as a DECnet
object.
To correct this condition, delete the DECnet object from
the DECnet database by entering the following command at
the VMS Network Control Program (NCP) prompt:
NCP> CLEAR OBJECT SQLSRV ALL
2.10.5 RDO Known Problems and Restrictions in V4.1
Sections 2.10.5.2 through 2.10.5.6 describe known problems
and restrictions in RDO for V4.1. See also Section 2.10.3
for more information on SQL import and export known
problems and restrictions in V4.1.
2.10.5.1 Transaction Handle and Messages Vector Are Not Always
Available in Callable RDO
If the program that uses Callable RDO (RDB$INTERPRET) is
linked implicitly with SYS$SHARE:RDBINTSHR (that is, if
the program allows the LINKER to resolve the reference
using SYS$LIBRARY:IMAGELIB.OLB), then the message vector
and transaction handle values are not returned to the
caller. This is true for programs linked on VMS versions
prior to 5.5. Programs linked on VMS versions 5.5 and later
will have access to message vector and transaction handle
values.
2-134 Known Problems, Restrictions, and Other Notes
However, if the program is linked explicitly with
SYS$SHARE:RDBINTSHR as the following example shows, then
message vector and transaction handle values are returned.
In this case, there must be two PSECTs declared and named
RDB$TRANSACTION_HANDLE (8 bytes long) and RDB$MESSAGE_
VECTOR (20 longwords, or 80 bytes long) in the caller's
program. For example:
$ LINK PROGRAM,SYS$INPUT/OPT
SYS$SHARE:RDBINTSHR.EXE/SHARE
PSECT_ATTR=RDB$MESSAGE_VECTOR,SHR
PSECT_ATTR=RDB$TRANSACTION_HANDLE,SHR
However, note that the explicit linking with the shareable
image SYS$SHARE:RDBINTSHR is not upwardly compatible
between Rdb/VMS versions and the application will need
to be relinked for each new version of Rdb/VMS released.
Thus, a program linked explicitly with RDBINTSHR under
4.0B, which had no multiversioning on the system, might
generate Access Violations when run under 4.1, 4.2 or even
4.0B on a multiversion system.
Relinking is not required between versions when both the
following circumstances apply:
o The program is linked explicitly with RDBINTSHR or is
linked under VMS V5.5 or later.
o The program is linked with V4.0B in a multiversion
environment or with V4.1 or V4.2.
There is no workaround for this problem.
2.10.5.2 RDO Provides Limited Support for SQL Date-Time Data
Types
The new SQL date-time data types have limited support
in RDO. You must use SQL to define and manipulate these
data types. RDBPRE and RDML applications cannot access
INTERVAL data types, and all DATE, TIME, and TIMESTAMP
data is converted to DATE VMS. Digital recommends all new
applications be written using SQL.
Known Problems, Restrictions, and Other Notes 2-135
2.10.5.3 RDO CONVERT Operation on V3.0 Databases Causes Database
Corruption When the Database Is Converted to V4.0,
V4.0A, V4.0B, V4.1, or V4.2
The RDO CONVERT operation for V3.0x reorders the fields
of some system relations so they no longer have the
correct on-disk structure. Consequently, if you try to
integrate the database into the data dictionary (CDD/Plus),
export it, or perform a SHOW TABLE RDB$FIELDS operation, a
bugcheck results with the following exception:
PIOFETCH$WITHIN_DB + 142
Because normal DML access to these relations continues to
work, the corruption usually is not noticed with V3.0x or
even if the database is converted to V3.1x. However, the
corruption causes the database to be incompatible with
V4.0, V4.0A, V4.0B, and V4.1. After using the RMU/CONVERT
command to convert the V3.0x or V3.1 database to V4.0,
V4.0A, 4.0B, or V4.1, you can no longer attach to the
database.
The solution is to perform an export/import operation after
converting to V3.0x and before converting to V4.0, V4.0A,
V4.0B, or V4.1. Alternately, the database can be converted
by using the EXPORT/IMPORT statements rather than by using
the RMU/CONVERT command.
Only databases converted from V2.n to V3.0x using the RDO
CONVERT statement and never imported since the conversion
are affected.
2.10.5.4 RDO Export Operation May Return SQL Error Messages
An RDO export operation may return SQL error messages. The
export code is shared between RDO and SQL. As a result, if
an RDO export operation fails for some reason, SQL error
messages may be returned. For example, if the RDO export
operation is executed but the database file does not exist,
an SQL error message is returned as follows:
RDO> EXPORT TEST_NOEXIST INTO NOEXIST.RBR
%SQL-F-DELBACKUP, EXPORT errors, interchange file deleted
-RDB-E-BAD_DB_FORMAT, TEST_NOEXIST does not reference a database known to Rdb
-RMS-E-FNF, file not found
2-136 Known Problems, Restrictions, and Other Notes
2.10.5.5 Aggregate Expressions in RDO Return an Error
If you invoke multiple databases in the RDO interface and
declare an aggregate expression, Rdb/VMS returns an %RDB-E-
INVALID_BLR error.
For example:
RDO> INVOKE DATABASE FEE = FILENAME USER1:[STUDENT_FEES]STUDENTDB
RDO> INVOKE DATABASE STA = FILENAME USER2:[STUDENT_FEES]STATS
RDO>
RDO> START_TRANSACTION ON FEE USING
cont> (READ_ONLY RESERVING FEE.TRANS FOR SHARED READ) AND
cont> ON STA USING (READ_WRITE RESERVING STA.STATDATA FOR EXCLUSIVE WRITE)
RDO>
RDO> FOR TX IN FEE.TRANS SORTED BY TX.SNO, TX.SESS, TX.TYPE
cont> REDUCED TO TX.SNO, TX.SESS, TX.TYPE
cont> WITH TX.SESS = "91S"
cont> STORE SX IN STA.STATDATA USING
cont> SX.SNO = TX.SNO;
cont> SX.SESS = TX.SESS;
cont> SX.TYPE = TX.TYPE;
cont> SX.AMOUNT = (TOTAL T1.AMOUNT OF T1 IN FEE.TRANS WITH
cont> T1.SNO = TX.SNO AND
cont> T1.SESS = TX.SESS AND
cont> T1.TYPE = TX.TYPE);
cont> END_STORE
cont> END_FOR
%RDB-E-INVALID_BLR, request BLR is incorrect at offset 172
RDO> ROLLBACK;
2.10.5.6 Loss of Precision for Text to Quadword Assignment in
RDB$INTERPRET
Numeric string literals are converted by Rdb/VMS to G_
FLOATING intermediate variables before being assigned
to the target column. The accuracy of G_FLOATING is 15
decimal digits. Therefore, with large values (16 digits
precision or more), precision is lost because of the
conversion to the intermediate G_FLOATING result for this
text to quadword assignment. Note that the RMU/LOAD command
converts text strings to quadword using the same internal
G_FLOATING data type with similar precision loss for large
values.
Known Problems, Restrictions, and Other Notes 2-137
A workaround is to use LIB$CVT_DX_DX in application
programs to convert the text string to quadword and pass
the quadword descriptor to RDB$INTERPRET as the following
example shows:
PROGRAM TEST16
IMPLICIT NONE
INCLUDE '($DSCDEF)'
STRUCTURE /DSC_STRUCTURE/
INTEGER*2 LENGTH
BYTE DTYPE
BYTE CLASS
INTEGER*4 POINTER
END STRUCTURE
INTEGER*4 QUAD(2)
RECORD /DSC_STRUCTURE/ OUT_DSC
OUT_DSC.LENGTH = 8
OUT_DSC.DTYPE = DSC$K_DTYPE_Q
OUT_DSC.CLASS = DSC$K_CLASS_S
OUT_DSC.POINTER = %LOC(QUAD)
call lib$cvt_dx_dx('9111151110000001', out_dsc)
call rdb$interpret('invoke data file DDD')
call rdb$interpret('start_trans read_write')
call rdb$interpret('store a in RRR using a.QQQ=!val end_sto', out_dsc)
call rdb$interpret('commit')
call rdb$interpret('finish')
end
2.10.6 RDBPRE Known Problems and Restrictions for V4.1
Section 2.10.6.1 describes a known problem for RDBPRE in
V4.1
2.10.6.1 RDBPRE Upgrade from Rdb/VMS V3.0B to V4.0A Results in
Run-Time Error BAD_REQ_HANDLE On Recompilation
An upgrade from Rdb/VMS V3.0B to V4.0A results in an
RDBPRE run-time error BAD_REQ_HANDLE on recompilation.
This problem is caused because the END_STREAM statement is
required when a START_STREAM statement has been declared
in versions of Rdb/VMS V4.0 and higher. However, RDBPRE
does not generate correct code for a routine that contains
the GET MAX function if this routine was located between
the routines that contain START_STREAM and END_STREAM
statements.
2-138 Known Problems, Restrictions, and Other Notes
A workaround is to move the routine that contains the GET
statistical function outside of routines that contain
START_STREAM and END_STREAM statement constructs as
stated in the line following the GET MAX statement in this
example:
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
....
&RDB& INVOKE DATABASE FILENAME "RDB$DB:PERSONNEL"
PROCEDURE DIVISION.
00000-MAIN.
*---------
&RDB& START-TRANSACTION READ-ONLY
PERFORM 71000-Get-Max-Salary
THRU 71000-EXIT.
..
70500-INVREQ.
*------------
&RDB& START-STREAM EMP-STREAM
&RDB& USING EMP-CONTEXT
&RDB& IN EMPLOYEES
70500-EXIT.
*==========
EXIT.
71000-GET-MAX-SALARY.
*^^^^^^^^^^^ move this routine outside the start-stream and end_stream
construct
&RDB& GET
&RDB& ON ERROR
PERFORM 95000-TRAP-ERROR
THRU 95000-EXIT
&RDB& END-ERROR
&RDB& MAX-SALARY = MAX JOB3.MAXIMUM-SALARY
&RDB& OF JOB3
&RDB& IN JOBS
&RDB& END-GET.
71000-EXIT.
*==========
EXIT.
Known Problems, Restrictions, and Other Notes 2-139
72000-END.
*---------
&RDB& END-STREAM EMP-STREAM
72000-EXIT.
*==========
EXIT.
2.10.7 RMU Known Problems and Restrictions in V4.1
Section 2.10.7.1 through Section 2.10.7.7 describe known
problems and restrictions in RMU for V4.1.
2.10.7.1 Problems Using RMU Commands with SYSMAN
You can experience problems such as a bugcheck dump when
you try to use the VMS System Management Utility (SYSMAN)
in VMS V5.4 to perform various RMU commands (RMU/OPEN and
RMU/SHOW USERS) across a VAXcluster. For example, you may
get the following exception:
***** Exception at 0024AE36 : LCK$HANDLE_ENQ_FAILURE + 00000060
%RDMS-F-EXQUOTA, exceeded quota
-SYSTEM-F-EXENQLM, exceeded enqueue quota
What happens is that when your system boots, the
startup procedure creates a detached process, called
SMISERVER, which processes SYSMAN requests. The startup
procedure gives the process absolute minimum quotas.
To solve this problem you must edit the file called
SYS$STARTUP:VMS$BASEENVIRON-050_SMISERVER.COM and raise
these quota values to appropriate values.
2.10.7.2 Problem Using the VMS ALLOCATE Command with RMU Commands
RMU tape operations do not automatically allocate the tape
drives used.
In an environment where many users compete for a few tape
drives, it is possible for another user to seize a drive
while RMU is waiting for you to load the next tape volume.
To prevent this, issue a VMS ALLOCATE command for the
drives you will be using before you issue the RMU command,
and then issue a VMS DEALLOCATE command after you complete
the RMU command.
2-140 Known Problems, Restrictions, and Other Notes
2.10.7.3 Restrictions on Using RMU Commands with the /WORM and
/NOSPAMS Qualifiers
It is reasonable to attempt to create, move, or restore an
area as a write-once storage area on a WORM device using
the /WORM qualifier with an RMU command. When prototyping
an application it might also seem reasonable to attempt to
create the write-once storage area on a read/write disk.
However, there is a problem with creating a write-once
storage area on a read/write disk. Rdb/VMS supports write-
once storage areas on WORM devices by assuming that storage
allocated on the WORM disk device has never been written,
and consequently contains zeros. Storage allocated on a
read/write disk device contains random data. This random
data may pose a security risk, and may at some future time
result in CHECKSUM errors from the RMU utility or your
application.
Correct operation requires that write-once storage areas
actually reside on WORM hardware devices.
Several RMU commands also include a /NOSPAMS qualifier
option. There are no restrictions on the use of this
qualifier option with mixed page format storage areas,
but the use of the /NOSPAMS qualifier typically causes
severe performance degradation. The /NOSPAMS qualifier is
only useful where updates are rare and batched, and access
is primarily by dbkey.
2.10.7.4 Do Not Delete After-Image Journal (.AIJ) Backup Files if
the AIJ Backup Fails or Is Terminated
If an AIJ backup process fails or is terminated
prematurely, the user might discard the resultant .AIJ
backup file because the backup operation was not completed.
However, all .AIJ backup files, including those produced
by a failed backup process, are necessary to recover a
database. If an .AIJ backup file of a failed backup process
is discarded, the database is not recoverable from that
point forward. This is especially important if you use
magnetic tapes as the AIJ backup media; in this case,
preserve this magnetic tape and do not reuse it.
Known Problems, Restrictions, and Other Notes 2-141
When an AIJ backup process, especially one running in
continuous (/CONTINUOUS) mode, writes to the .AIJ backup
file, it is possible for the transferred data to be
deleted from the database .AIJ file. If the backup process
subsequently fails or is prematurely terminated (for
example with Ctrl/Y or the STOP command), it might not
be possible to retransfer the data to the subsequent .AIJ
backup file because the data was deleted from the active
database .AIJ file.
Therefore, it is extremely important that you preserve
all .AIJ backup files, even those produced by failed or
terminated backup processes. If the resultant .AIJ backup
file is discarded, the next .AIJ backup file could contain
a "gap" in transactions, so that no transactions would ever
be rolled forward from that point on.
________________________ Note ________________________
If this problem occurs, the database is not
inconsistent or corrupt. Rather, the database cannot
be rolled forward past the discarded .AIJ backup file.
______________________________________________________
The solution to this problem is to preserve all .AIJ
backup files to ensure that a database can be completely
recovered.
If you have discarded an .AIJ backup file, perform a
complete database backup immediately to ensure that the
database can be recovered up to the current transaction.
2.10.7.5 RMU/EXTRACT Known Problems and Restrictions in V4.1
This section describes known problems and restrictions
for the RMU/EXTRACT command. In each case, the RMU/EXTRACT
command performs best-try conversion of RDO constructions
to SQL. The following sections describe constructions that
can be defined using RDO but cannot be completely specified
using SQL.
2-142 Known Problems, Restrictions, and Other Notes
2.10.7.5.1 VALID IF Clauses Are Converted to Domain Level
CHECK Constraints RDO and the CDD/Repository have the
concept of validation clauses at the domain level. The
ANSI/ISO SQL92 draft standard allows CHECK constraints
defined on domains.
While the actions of the ANSI/ISO CHECK constraint do
differ from VALID IF in some respects, RMU/EXTRACT has
chosen to extract the VALID IF clauses as domain CHECK
constraints if you use /LANGUAGE=SQL/OPTION=FULL.
The generated syntax is not currently accepted by the SQL
interface to Rdb/VMS, and is generated only as a guide for
users.
2.10.7.5.2 Triggers in RDO Allow Users to Define a Trigger
Action Within a Join of Two or More Tables Triggers in
RDO allow the user to define a trigger action within a join
of two or more tables, as shown in the following example.
DEFINE TRIGGER EXAMPLE
AFTER ERASE
FOR C1 IN EMPLOYEES
EXECUTE
FOR C2 IN JOB_HISTORY
CROSS C3 IN EMPLOYEES
WITH (((C2.EMPLOYEE_ID = C3.EMPLOYEE_ID)
AND (C2.JOB_END MISSING))
AND (C3.EMPLOYEE_ID = C2.EMPLOYEE_ID))
ERASE C2
END_FOR
FOR EACH RECORD.
This trigger includes a join with an embedded ERASE (or
MODIFY) statement. This will be translated by RMU/EXTRACT
to the following SQL update operation:
CREATE TRIGGER EXAMPLE
AFTER DELETE ON EMPLOYEES
(DELETE FROM JOB_HISTORY C2, EMPLOYEES C3
WHERE (((C2.EMPLOYEE_ID = C3.EMPLOYEE_ID)
AND (C2.JOB_END IS NULL))
AND (C3.EMPLOYEE_ID = C2.EMPLOYEE_ID))
) FOR EACH ROW;
Known Problems, Restrictions, and Other Notes 2-143
This syntax (and the syntax generated for update) is not
legal SQL. This syntax is provided only as a guide to
users. Please note that the trigger definition shown is
not recommended by Digital.
Starting in Rdb/VMS V4.1, new update rules are enforced by
default. With new update rules it is no longer possible to
modify or delete rows from a table that is directly joined
with other tables. However, rows from a table can still
be modified or deleted if the table is joined with other
tables that are in a subquery. Because SQL does not have
syntax that allows rows from a table to be modified or
deleted and at the same time allows that table to be joined
with other tables, the new update rules have no affect
on SQL applications. However, those RDO applications that
contain join update queries, that is, the update queries
that modify or delete rows from a table that is joined with
other tables will be affected and will have to be fixed.
Rdb/VMS now gives an error diagnostic for the following
join update query:
FOR E IN EMPLOYEES CROSS D IN DEGREES OVER EMPLOYEE_ID
WITH D.DEGREE = 'MA'
ERASE E
END_FOR
%RDMS-E-JOIN_CTX_UPD, relation EMPLOYEES is part of a join, cannot be updated
In the preceding update query, if an employee has two
MA degrees, the same employee row will be joined to two
different degree rows. Therefore Rdb/VMS will try to
delete the same row twice. Or if instead of using the ERASE
verb, the previous update query used a MODIFY verb on the
EMPLOYEES table, then Rdb/VMS might modify the row more
than once.
In prior versions of Rdb/VMS, join update queries similar
to the previous query worked correctly or produced an error
diagnostic trying to delete the same row more than once,
or-even worse-produced a bugcheck.
The previous update query can be reworded into an
equivalent form to achieve the same result as follows:
2-144 Known Problems, Restrictions, and Other Notes
FOR E IN EMPLOYEES WITH (ANY D IN DEGREES WITH D.EMPLOYEE_ID = E.EMPLOYEE_ID
AND D.DEGREE = 'MA')
ERASE E
END_FOR
The rows can now be erased because the EMPLOYEES table is
no longer directly joined to the DEGREES table. The use
of a modified update query guarantees that an employee row
will not be deleted more than once.
To ease the transition for applications that depend on the
old update rules, Rdb/VMS supports either new or old update
rules in V4.2. By default, Rdb/VMS will enforce new update
rules. To make Rdb/VMS continue to use the old update
rules, define the logical name RDMS$USE_OLD_UPDATE_RULES
to "1". The dual support of new as well as old update rules
is provided to give users time to change their applications
(if necessary) to conform to the new update rules.
The support for old update rules will be removed from
Rdb/VMS in the release following V4.2.
The following join update query will no longer work with
the new update rules. Also this update query will modify
some salary history rows more than once and gives multiple
salary raises to some managers!
! Give a 10% salary raise to all managers who have an MA degree.
FOR S IN SALARY_HISTORY CROSS D IN DEGREES CROSS DP IN DEPARTMENTS
WITH S.EMPLOYEE_ID = D.EMPLOYEE_ID AND
S.EMPLOYEE_ID = DP.MANAGER_ID AND
S.SALARY_END MISSING AND
D.DEGREE = 'MA'
MODIFY S USING S.SALARY_AMOUNT = S.SALARY_AMOUNT * 1.1
END_FOR
This query can be reworded using a subquery as follows:
FOR S IN SALARY_HISTORY
WITH S.SALARY_END MISSING AND
(ANY D IN DEGREES CROSS DP IN DEPARTMENTS
WITH S.EMPLOYEE_ID = D.EMPLOYEE_ID AND
S.EMPLOYEE_ID = DP.MANAGER_ID AND
D.DEGREE = 'MA')
MODIFY S USING S.SALARY_AMOUNT = S.SALARY_AMOUNT * 1.1
END_FOR
Known Problems, Restrictions, and Other Notes 2-145
This revised query will work with the new as well as the
old update rules and it will ensure that each qualified
manager gets a single salary raise.
________________________ Note ________________________
Some examples in Sections 6.7 and 9.2.6.3 of the VAX
Rdb/VMS Guide to Using RDO, RDBPRE, and RDML will no
longer work with the new update rules. To run these
examples, reword them using the ANY subquery mentioned
previously.
______________________________________________________
2.10.7.5.3 VMS Style Dates and CURRENT_TIMESTAMP
Databases created in V4.0 could define a DATE field with a
default of CURRENT_TIMESTAMP. RMU/EXTRACT always generates
databases with SET ANSI DATE ON. Therefore, old style dates
such as this will cause error messages from SQL when the
SQL output is executed.
CREATE DOMAIN TSTAMP DATE VMS
DEFAULT CURRENT_TIMESTAMP;
%SQL-F-DEFVALINC, You specified a default value for TSTAMP
which is inconsistent with its data type
This will remain a restriction for RMU/EXTRACT for V4.2
as well as V4.1. The workaround is to edit the source
generated by the RMU/EXTRACT command and either remove
the SET ANSI DATE ON command, or place SET ANSI DATE OFF
and SET ANSI DATE ON commands around the domain or table
definition.
2.10.7.5.4 RDO Removes Blank Lines in Multiline
Descriptions The RDO interface strips out blank lines
in multiline descriptions, and so the description saved
in the metadata is not identical to that entered by the
database definer. RMU/EXTRACT therefore cannot completely
reconstruct the original description.
2-146 Known Problems, Restrictions, and Other Notes
2.10.7.5.5 RMU/EXTRACT Column Default Value Restriction
RMU/EXTRACT tries to best represent the information that is
stored in the metadata. In addition, beginning with V4.1,
SQL checks that the data type of DEFAULT (or DEFAULT VALUE
FOR DATATRIEVE) is compatible with the column.
For example, in Rdb/VMS V4.1 the following example returns
an error message:
CREATE DOMAIN KS_TOEP_KD
CHAR(1)
DEFAULT VALUE 1
or
CREATE DOMAIN KS_TOEP_KD
INTEGER
DEFAULT VALUE 1
ALTER DOMAIN KS_TOEP_KD CHAR(1)
%SQL-F-DEFVALINC, You specified a default value for KS_TOEP_KD which
is inconsistent with its data type and this domain is not created or altered.
However, in Rdb/VMS V4.0, the previous example can be run
without getting any error message. The information for this
domain in the metadata is stored as type CHAR(1) and the
default value is data type INTEGER 1, rather than character
"1".
Therefore, when RMU/EXTRACT is used on databases created
before Rdb/VMS V4.1, it may extract a default or default
value that is inconsistent with the data type. In this
case, the only workaround is to modify the RMU/EXTRACT
output file to make the data type compatible; that is,
change the default value 1 to "1".
2.10.7.6 Clarification on the Meaning of Granted and Requested in
RMU/SHOW LOCKS Output Displays
When displaying locks using the RMU/SHOW LOCKS utility,
the Requested and Granted modes of the given lock are
displayed. Some confusion has arisen over the exact usage
of these fields. This is the current definition:
o Requested
Known Problems, Restrictions, and Other Notes 2-147
This is the mode for which the process has requested
the lock. Valid modes are NL, PR, PW, CR, CW, and EX.
This mode is not guaranteed to be granted; some locks
are intentionally held in conflicting modes forever (for
example, the "termination" lock).
o Granted
This is the mode that the process was last granted
for the lock. Valid modes are NL, PR, PW, CR, CW, and
EX. Furthermore, if the lock has never been previously
granted, the lock mode is displayed as NL mode.
If the "requested" and "granted" lock modes differ, then
the lock requested is currently blocked on either the
"wait" or "conversion" queue. If the modes are the same,
then the lock has been granted.
The VMS distributed lock manager does not always update
the Requested lock mode. This means that potentially
conflicting information can be displayed by the RMU/SHOW
LOCKS utility.
The Requested lock mode is only updated under the following
situations:
o The lock request is for a remote resource.
o The lock request is a NOWAIT request.
o The lock request could not be granted due to a lock
conflict (that is, it was cancelled by the application
or aborted due to lock timeout/deadlock).
o The lock request is the first for the resource.
Consider the following RMU/SHOW LOCKS output:
-------------------------------------------------------------------------------
Resource Name: page 533
Granted Lock Count: 1, Parent Lock ID: 01000B6C, Lock Access Mode:
Executive,
Resource Type: Global, Lock Value Block: 03000000 00000000 00000000 00000002
-Master Node Info- --Lock Mode Information-- -Remote Node Info-
ProcessID Lock ID SystemID Requested Granted Queue Lock ID SystemID
2040021E 0400136A 00010002 EX CR GRANT 0400136A 00010002
--------------------------------------------------------------------------------
2-148 Known Problems, Restrictions, and Other Notes
In this example, it is ordinarily difficult to explain how
such a combination of lock modes could occur. Note that the
CR (concurrent read) mode is on the GRANT queue (not the
CONVERSION queue).
Knowledge of the operating environment is necessary to
know that there was only one node on this system. It turns
out that two lock requests actually occurred to generate
this output, in the opposite order of what appears to have
occurred.
The first lock request was for EX (exclusive), which was
immediately granted. Thus, the Requested and Granted modes
were updated according to situation 4. Then, the lock was
demoted from EX to CR mode, which was also immediately
granted. However, the Requested field was not updated
because none of the four preceding rules was true, so the
Requested mode was never updated to reflect the CR lock
request.
This information will be added to the VAX Rdb/VMS RMU
Reference Manual in a future release.
2.10.7.7 False BADFNMAIJ Errors Are Returned from RMU/VERIFY
During Root Verification
If an .AIJ file is created using a rooted-device logical
name to specify the database name, and root verification
is then performed using a non-rooted-device logical name
to specify the database name, an RMU/VERIFY operation will
report a false BADFNMAIJ error.
For example, assume there is a database at
$111$DUA0:[USER1.DB]X.RDB;1 and there is a logical name
DISK1 with translation $111$DUA0:
Known Problems, Restrictions, and Other Notes 2-149
$! Define a rooted-device logical for the database.
$ DEFINE/TRANSLATION_ATTR=CONCEALED DB_ROOTED$ DISK1:[USER1.]
$!
$! Define a non-rooted-device logical for the database.
$ DEFINE DB$ DISK1:[USER1.DB]X.RDB;1
$!
$! Create an .AIJ file for the database, specifying the database with the
$! rooted-device logical.
$ SQL
ALTER DATABASE FILENAME DB_ROOTED$:[DB]X.RDB;1
JOURNAL FILE X.AIJ;1;
$!
$! Do root verification of the database, specifying the database with the
$! non-rooted-device logical.
$ RMU/VERIFY/ROOT DB$
%RMU-E-BADFNMAIJ, after-image journal file contains references to wrong database
expected: "$111$DUA0:[USER1.DB]X.RDB;1"
found: "$111$DUA0:[USER1.][DB]X.RDB;1",
For a workaround to this problem, do the verification
specifying the database with the rooted-device logical
name as follows:
RMU/VERIFY/ROOT DB_ROOTED$:[DB]X.RDB;1.
Similarly, if the .AIJ file is created with the non-rooted-
device database specification and the root verifcation
is done using the rooted-device database specification, a
false BADFNMAIJ error will again be reported as follows:
$! Create an .AIJ file for the database, specifying the database with the
$! rooted-device logical.
$ SQL
ALTER DATABASE FILENAME DB$
JOURNAL FILE X.AIJ;1;
$!
$! Do root verification of the database, specifying the database with the
$! non-rooted-device logical.
$ RMU/VERIFY/ROOT DB_ROOTED$:[DB]X.RDB;1
%RMU-E-BADFNMAIJ, after-image journal file contains references to wrong database
expected: "$111$DUA0:[USER1.][DB]X.RDB;1",
found: "$111$DUA0:[USER1.DB]X.RDB;1"
2-150 Known Problems, Restrictions, and Other Notes
For a workaround to this problem, do the verification
specifying the database with the non-rooted-device logical
name as follows:
RMU/VERIFY/ROOT DB$
2.10.8 CDD/Repository Known Problems, Restrictions, and Notes for
V4.1
Sections 2.10.8.1 through 2.10.8.5 describe known problems,
restrictions, and notes of general interest for using
CDD/Repository V5.0. See the V5.0 VAX CDD/Repository
Release Notes for additional known problems using Rdb/VMS
and CDD/Repository. See Section 2.10.9 for problems
relating to CDD/Plus, the predecessor of CDD/Repository.
2.10.8.1 Problem with CDD/Repository and Views
An error occurs when you create a view in SQL based on a
table created from the dictionary using the function COUNT
with DISTINCT specified.
The following example using views shows the problem:
CDO>DEFINE FIELD FIELD1 DATATYPE IS WORD.
CDO>DEFINE RECORD FOO. FIELD1. END RECORD.
SQL>CREATE SCHEMA FILENAME FOOBAR PATHNAME CDD$DEFAULT.FOOBAR;
SQL> CREATE TABLE FROM CDD$DEFAULT.FOO;
SQL> CREATE VIEW BAR (NUMBER) AS
cont> SELECT COUNT (DISTINCT FIELD1) FROM FOO;
%CDD-E-MBLRSYNERR, syntax error in MBLR buffer at offset 0
The problem can also appear if the view is defined while
the database is attached by FILENAME and then later
integrated into the repository using the INTEGRATE command,
for example:
SQL> INTEGRATE SCHEMA FILENAMERDB$TEST_SYSTEM:[TEST_EXECUTE.CAROL.TEST]TEST_
EXPORT CREATE PATHNAME RDB$TEST_SYSTEM:[TEST_EXECUTE.CAROL.CDD]TEST_EXPORT;
%CDD-E-MBLRSYNERR, syntax error in MBLR buffer at offset 0
The following workaround temporarily solves this problem:
o If this error occurs, you should locate any views,
computed by columns, constraints, or triggers that
contain SELECT COUNT (DISTINCT n) clauses. This clause
is not currently understood by CDD/Repository. The
Known Problems, Restrictions, and Other Notes 2-151
RMU/EXTRACT utility can assist in the search for these
objects on created databases.
o Drop the views, computed by columns, constraints, or
triggers containing SELECT COUNT (DISTINCT n) clauses.
o Integrate the database into the repository.
o Attach to the database by file name.
o Redefine the objects that were deleted.
This is a known problem for CDD/Repository V5.0 and will be
fixed in a future version of CDD/Repository.
2.10.8.2 Using CDD/Repository Global Fields with Rdb/VMS
Rdb/VMS and CDD/Repository support the definition of fields
(domains) and records (relations or tables). The model
supported by Rdb/VMS is a single level of global fields
referenced by relations. However, CDD/Repository allows
a much more general model that allows multiple levels of
global fields. When using Rdb/VMS and CDD/Repository you
should change the global fields using only CDD/Repository
tools. If you use SQL or RDO to alter the field, they will
only change the first level of indirection.
Use of global fields from the CDD/Repository can lead to
messages such as the following:
%CDD-E-BOGLOBAL, global field based on global field in same database
________________________ Note ________________________
A future release of CDD/Repository will display the
names of the two fields causing the error: %CDD-E-
BOGLOBAL, global field AREA_NUMBER based on global
field NUMBER in same database.
______________________________________________________
This error indicates that a global field depends on
another global field for its full definition and that both
fields are included at the same level. These examples and
guidelines should help you to avoid this type of error.
2-152 Known Problems, Restrictions, and Other Notes
The syntax for RDO and the CDD/Repository CDO interface is
very similar. However, RDO allows field renaming, as shown
in the following example.
RDO> DEFINE FIELD FIELD_A DATATYPE TEXT 1.
RDO> DEFINE RELATION RECORD_A.
cont> FIELD_A.
cont> END.
RDO> DEFINE RELATION RECORD_B.
cont> FIELD_B BASED ON FIELD_A.
cont> END.
This command creates two records with a dependency on
the global field FIELD_A. The local field name in the
relation for RECORD_A is FIELD_A (the same as the global
field name); for RECORD_B the name is changed to FIELD_B
(although it still depends on the global field FIELD_A).
If users try to do something similar to this RDO example in
CDO they receive the BOGLOBAL message:
CDO> DEFINE FIELD FIELD_A DATATYPE TEXT 1.
CDO> DEFINE FIELD FIELD_B BASED ON FIELD_A.
CDO> DEFINE RECORD RECORD_A.
cont> FIELD_A.
cont> END.
CDO> DEFINE RECORD RECORD_B.
cont> FIELD_B.
cont> END.
RDO> DEFINE RELATION RECORD_A FROM PATHNAME 'RECORD_A'.
RDO> DEFINE RELATION RECORD_B FROM PATHNAME 'RECORD_B'.
%CDD-E-BOGLOBAL, global field based on global field in same database
CDO does not have the rename capability, so users of CDO
often define new global fields to achieve the same result.
Logically this seems the same as the RDO example. However,
this generates different dependencies in the CDD than shown
in the previous example.
A preferable set of definitions would include only BASED
ON fields in the record definitions. Then there will be
separate global fields created by Rdb/VMS with dependencies
on the CDD/Repository, rather than the two previously
defined (or attempted), which had dependencies between
global fields not supported by Rdb/VMS.
Known Problems, Restrictions, and Other Notes 2-153
CDO> DEFINE FIELD FIELD_BASE DATATYPE TEXT 1.
CDO> DEFINE FIELD FIELD_A BASED ON FIELD_BASE.
CDO> DEFINE FIELD FIELD_B BASED ON FIELD_BASE.
CDO> DEFINE RECORD RECORD_A.
cont> FIELD_A.
cont> END.
CDO> DEFINE RECORD RECORD_B.
cont> FIELD_B.
cont> END.
RDO> DEFINE RELATION RECORD_A FROM PATHNAME 'RECORD_A'.
RDO> DEFINE RELATION RECORD_B FROM PATHNAME 'RECORD_B'.
RDO> SHOW FIELDS
User Fields in Database with pathname DISK1:[SMITH.DICT1]SAMPLE;1
FIELD_A text size is 1
FIELD_B text size is 1
RDO> SHOW FIELD FIELD_A
FIELD_A text size is 1
CDD pathname: DISK1:[SMITH.DICT1]FIELD_A;2
RDO> SHOW FIELD FIELD_B
FIELD_B text size is 1
CDD pathname: DISK1:[SMITH.DICT1]FIELD_B;2
This scheme will result in a correct representation of the
dependencies and also provide the field renaming required.
Note that the global fields need not be explicitly defined
as fields in RDO, or domains in SQL; this will happen
automatically.
Now a change of the original global field FIELD_BASE using
CDO will cause a notice to be placed on the CDD$DATABASE
object, "SAMPLE":
$ REPOSITORY
Welcome to CDO V2.0
The CDD/Repository V5.0 User Interface
Type HELP for help
CDO> CHANGE FIELD FIELD_BASE DATATYPE TEXT 10.
Subsequent attempts to attach to the database using
interactive utilities, or precompilers, will generate a
message from interactive SQL:
2-154 Known Problems, Restrictions, and Other Notes
SQL> ATTACH 'PATHNAME SAMPLE';
%SQL-I-DIC_DB_CHG1, A dictionary definition used by database
DISK1:[SMITH.DICT1]SAMPLE;1 has changed
-SQL-I-DIC_DB_CHG2, Use the INTEGRATE statement to resolve any differences
between the dictionary and the database
%CDD-I-MESS, entity has messages
To see what was changed in the dictionary use the SHOW
NOTICES command in CDO, for example:
CDO> SHOW NOTICES SAMPLE
DISK1:[SMITH.DICT1]SAMPLE;1 is possibly invalid, triggered by
CDD$DATA_ELEMENT DISK1:[SMITH.DICT1]FIELD_BASE;1
These changes can be merged with the database by performing
an INTEGRATE operation that updates the fields (domains)
in the database. Rdb/VMS also propagates the changes in the
fields (domains) to all relations (tables) that use those
fields, as shown in the following example:
RDO> INTEGRATE DATABASE SAMPLE FROM 'SAMPLE'
RDO> SHOW FIELD
User Fields in Database with filename SAMPLE
FIELD_A text size is 10
FIELD_B text size is 10
RDO> SHOW FIELD FIELD_A
FIELD_A text size is 10
CDD pathname: DISK1:[SMITH.DICT1]FIELD_A;2
RDO> SHOW FIELD FIELD_B
FIELD_B text size is 10
CDD pathname: DISK1:[SMITH.DICT1]FIELD_B;2
RDO> SHOW FIELDS FOR RECORD_A
Fields for relation RECORD_A
FIELD_A text size is 10
RDO> SHOW FIELDS FOR RECORD_B
Fields for relation RECORD_B
FIELD_B text size is 10
Known Problems, Restrictions, and Other Notes 2-155
2.10.8.3 CDD/Repository, Rdb/VMS: Record and Field Interaction
It is possible when using CDD/Repository to define record
and field structures that are not acceptable to Rdb/VMS.
CDD/Repository is intended as a generic data repository
that can hold data structures available to many layered
products and languages.
These data structures may not always be valid when applied
to the relational data model used by Rdb/VMS.
The following are some of the common incompatibilites
between the data structures of CDD/Repository and Rdb/VMS:
o %CDD-E-PRSMISSNG, attribute value is missing
This error occurs when a record definition in
CDD/Repository contains a VARIANTS clause.
This error occurs when a field definition in
CDD/Repository contains a FILLER clause.
o %CDD-E-INVALID_RDB_DTY, datatype of field is not
supported by Rdb/VMS
This error occurs when a record definition in
CDD/Repository contains an OCCURS clause.
This error occurs when a field definition in
CDD/Repository contains an ARRAY clause.
o %CDD-E-DTYPE_REQUIRED, field must have a datatype for
inclusion in an Rdb/VMS database
This error occurs when a record definition in
CDD/Repository contains another nested record
definition. Rdb/VMS can only accept field definitions
in a record definition.
o %CDD-E-HAS_DIMENSION, Rdb/VMS fields cannot have
dimension
This error occurs when a field definition in
CDD/Repository contains an OCCURS clause.
o %CDD-E-INVALID_RDB_DIM, record !AS has dimension and
cannot be used by Rdb/VMS
This error occurs when a record definition in
CDD/Repository contains an ARRAY clause.
2-156 Known Problems, Restrictions, and Other Notes
For more information on using CDD/Repository fields and
records in an Rdb/VMS database, refer to the VAX Rdb/VMS
SQL Reference Manual, Part II, Create Domain and Create
Table commands.
2.10.8.4 Index Loses Attributes After an Integrate Operation
If you modify a column used by an index, the INTEGRATE
operation needs to drop the index before changing the
field. After the index is restored it loses the following
index attributes:
o Node size
o Percent fill
o HASH attribute
o DUPLICATES attribute
o Storage map information
This limitation of the dictionary is being addressed in a
future release.
2.10.8.5 Compatibility of CDD/Repository and Rdb/VMS
CDD/Plus V4.3 is the minimum version required for Rdb/VMS
V4.1. However, CDD/Repository can use Rdb/VMS V3.1B or
later for its database storage.
No new features of Rdb/VMS V4.1 are supported by CDD/Plus
V4.3 or CDD/Repository V5.0.
For more information about the compatibility of the data
dictionary and Rdb/VMS, see Table 2-5.
The following Rdb/VMS problems will be addressed in future
versions of CDD/Repository:
o Changing the data type of a domain can result in loss of
hashed index functionality
During an integrate operation, a hashed index that needs
to be recreated due to a change to a domain's data type
will be redefined as a SORTED index.
o Two-phase commit is not used between SQL or RDO and the
data dictionary. Therefore, an operation may succeed in
SQL or RDO but the matching operation will fail in the
data dictionary.
Known Problems, Restrictions, and Other Notes 2-157
If this is a concern, then you should issue a ROLLBACK
statement in SQL or RDO to ensure correct rollback of
the operation.
o %CDD-E-INV_VAL_EXP with SQL views
The error %CDD-E-INV_VAL_EXP is generated by INTEGRATE
when you try to "use" a view definition from the
dictionary created with an expression containing one
of the following SQL constructs: COUNT, AVERAGE, MAX,
MIN, or SUM. The translator that converts the view
definition to the dictionary's internal format creates
an invalid expression buffer in the dictionary. It is
not until the actual dictionary buffer is retranslated
for presentation to Rdb/VMS that the %CDD-E-INV_VAL_EXP
error is generated.
The only workaround is to avoid these functions in SQL
view definitions.
2.10.9 CDD/Plus V4.2A and V4.3 Known Problems and Restrictions
for V4.1
Sections 2.10.9.1 through 2.10.9.5 describe known problems
and restrictions in CDD/Plus V4.2A and CDD/Plus V4.3.
2.10.9.1 Importing a Multischema Database Referencing CDD/Plus
Causes Error
CDD/Plus does not support databases defined with the
multischema attribute. Consequently, if you attempt to
import a multischema database and do not specify the RDO
DICTIONARY IS NOT USED clause or the SQL DICTIONARY IS NOT
REQUIRED clause, the following error message is returned:
.
.
.
IMPORTing view DAILY_WAGE
IMPORTing view WEEKLY_WAGES
IMPORTing view REVIEW_DATE
IMPORTing view CURRENT_INFO
IMPORTing view CURRENT_SALARY
IMPORTing view CURRENT_JOB
%CDD-E-BLRSYNERR, syntax error in BLR buffer at offset 0
RDO>
2-158 Known Problems, Restrictions, and Other Notes
This restriction applies to CDD/Plus V4.3 and lower. The
workaround is to specify the DICTIONARY IS NOT USED clause
in the import operation because the default clause is
DICTIONARY IS USED. See the VAX Rdb/VMS Release Notes for
V4.1 for more information.
2.10.9.2 Using CDD/Plus in a Multiversion Environment
When you use the CDO command DEFINE DICTIONARY, CDD/Plus
normally copies an empty data dictionary from a directory
pointed to by the logical name CDD$TEMPLATE. The logical
name is usually defined system-wide.
Once the database is copied, CDO accesses the empty copy
and updates it to reflect the DEFINE DICTIONARY command.
CDO does not detect that the CDD$TEMPLATE database
CDD$DATABASE.RDB was created by an earlier version of
Rdb/VMS until after the copy is performed. This may result
in "obsolete version of database" error messages.
There are several corrections to this problem to support
Rdb/VMS multiversioning:
o Use the RMU/CONVERT command to convert the system-wide
CDD$TEMPLATE directory.
Digital does not recommend doing this in a production
environment because now all new CDD/Plus dictionaries
that are created must be accessed using Rdb/VMS V4.1.
o Create an empty directory and redefine the CDD$TEMPLATE
logical name as follows:
$ CREATE/DIRECTORY SYS$SYSDEVICE:[CDD$TEMPLATE_RDB41]
Then each process that uses Rdb/VMS V4.1 should define
CDD$TEMPLATE as a process logical using the following
command:
$ DEFINE/PROCESS CDD$TEMPLATE SYS$SYSDEVICE:[CDD$TEMPLATE_RDB41]
When CDO detects the empty directory it will create the
dictionary database and associated files rather than
copying them from CDD$TEMPLATE.
This option takes longer because of the extra work
that must be performed during the CDO DEFINE DICTIONARY
command.
Known Problems, Restrictions, and Other Notes 2-159
o Populate the directory after setting the Rdb/VMS
environment to V4.1, then execute the following
commands:
$ ! Set the Rdb/VMS environment to V4.1, then...
$ CREATE/DIRECTORY SYS$SYSDEVICE:[CDD$TEMPLATE_RDB41]
$ DEFINE/PROCESS CDD$TEMPLATE SYS$SYSDEVICE:[CDD$TEMPLATE_RDB41]
$ DICTIONARY OPERATOR DEFINE DICTIONARY CDD$TEMPLATE.
2.10.9.3 SQL Interface Restrictions for CDD/Plus V4.3 and Earlier
Versions
CDD/Plus V4.3 and earlier versions do not support certain
new features in the SQL interface to Rdb/VMS V4.1.
Table 2-5 lists which versions of CDD/Plus support
particular Rdb/VMS features.
2.10.9.4 Integrate Sometimes Fails with a NO_META_UPDATE Error
When you use CDD/Plus V4.3 and Rdb/VMS V4.0 (or higher)
and you execute an RDO or SQL INTEGRATE statement, the
integrate operation may fail with the following error
message:
-CDD-E-RDB_ERROR, element RDBVMS$STO_REL_NAM_NDX caused Rdb/VMS
operation to abort
-RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-NOMETSYSREL, metadata may not be created/altered on system relations
This happens when you perform an SQL INTEGRATE ALTER FILES
operation. CDD/Plus incorrectly attempts to upgrade the
Rdb/VMS system relations to match the CDD$RDB_SYSTEM_
METADATA entries in the dictionary when it detects that
a system relations index has been changed (in this case the
index was changed in V4.0 to allow duplicate rows, when in
previous versions it was a unique index).
This problem is corrected by CDD/Repository V5.0 software.
The workaround is to first perform an INTEGRATE CREATE
PATHNAME (or CREATE SCHEMA PATHNAME) operation, which
forces the CDD$RDB_SYSTEM_METADATA entries to be updated
to match the current version of Rdb/VMS.
2-160 Known Problems, Restrictions, and Other Notes
2.10.9.5 INTEGRATE Does Not Clear Change Messages
INTEGRATE in CDD/Plus V4.2 and V4.3 does not clear messages
for changes due to CDO DEFINE commands, only those changes
generated by CHANGE commands.
This problem is corrected in CDD/Repository Version 5.0.
2.11 Restrictions Retained from V4.0
This section begins with V4.0 restrictions pertinent to
all users and ends with restrictions specific to SQL, RDO,
RDBPRE, RDML, and CDD/Plus.
Therefore, the notes in this section may use different
database terms to mean the same thing. For example,
some terms used by SQL differ from terms used by other
interfaces, such as RDO or RDML. Table 1 in the VAX Rdb/VMS
New and Changed Features lists the different terms used.
2.11.1 Known Problems and Restrictions for All Interfaces for
V4.0
Section 2.11.1.1 through Section 2.11.1.12 contain known
problems and restrictions for all interfaces for V4.0.
These restrictions also apply to V4.1 and V4.2.
2.11.1.1 Improving the Performance of the Export Operation
Using the DCL SET Command to Change the Default Extend
Parameter Value
Normally, during an export operation, the Rdb/VMS
interchange file (RBR), which uses the RMS default extent,
will extend for every 3 blocks the RBR file grows in size.
To prevent this, define the following SET command to change
the process default RMS extent quantity:
$ SET RMS_DEFAULT/EXTEND_QUANTITY=30000
Now, rather than "extending" the RBR file for every 3
blocks (which involves many extend operations), the RMS
EXTEND command is only invoked once per 30,000 blocks. By
specifying a larger value for the file extend parameter,
the run time of the export operation can be significantly
improved.
Known Problems, Restrictions, and Other Notes 2-161
2.11.1.2 SNAPSHOTS DEFERRED May Stall Transactions
If your database has snapshots set to ENABLED DEFERRED,
users may not be able to attach to the database once you
have issued one of the following statements:
o RDO DEFINE, CHANGE, or DELETE RELATION
o SQL CREATE, ALTER, or DROP TABLE
o RDO DEFINE or DELETE INDEX
o SQL CREATE or DROP INDEX
During database attach, Rdb/VMS locks certain key metadata
relations and reads them to construct the metadata
information cache used to process requests against the
database. When one of the previously listed statements
executes a read-write transaction that updates these
metadata relations, any subsequent database attach
(equivalent to a read-only transaction) will stall until
the read-write transaction is completed. Users that were
attached to the database before the statement was issued
can continue accessing the database.
This is a known restriction. Use of deferred snapshots will
cause conflict when using data definition language (DDL)
statements in a production environment because snapshot
copies of the system metadata cannot be written to the
snapshot file.
To avoid this problem, modify the database so that
snapshots are set to ENABLED IMMEDIATE. You can use any
of the following statements to set snapshots to ENABLED
IMMEDIATE:
o SQL CREATE SCHEMA or RDO DEFINE DATABASE
o SQL ALTER SCHEMA or RDO CHANGE DATABASE
o SQL or RDO IMPORT
2.11.1.3 PLACEMENT VIA INDEX Clause Prohibits Shadow Clustering
Shadow clustering of records that use the PLACEMENT VIA
INDEX clause of the CREATE STORAGE MAP statement for any
index to cluster records in a uniform storage area does not
work in Rdb/VMS V3.1, V3.1A, V3.1B, or V4.0. The remedy for
this problem is being investigated for a future release.
2-162 Known Problems, Restrictions, and Other Notes
2.11.1.4 RDB$SYSTEM Storage Area Cannot Be Read-Only When a
Relation Is Readied in Exclusive or Batch-Update Mode
When a relation is readied in exclusive or batch-update
mode, the RDB$SYSTEM storage area must not be read-only. An
exception message is returned if the RDB$SYSTEM storage
area is read-only and you try to ready a relation in
exclusive or batch-update mode.
This is an Rdb/VMS restriction. Exclusive access to a
relation or index must always write to the RDB$SYSTEM
storage area because this type of access does not write
the "before" images of the modified data into the snapshot
file. Consequently, a read-only access to the same relation
or index must have a way of knowing whether the snapshot
file will be capable of materializing the generation of the
data that it requires.
Each exclusive access must record that it is not
maintaining snapshots on a per index or per relation basis,
as this is the unit of data for which Rdb/VMS permits the
setting of the access mode. The natural location to store
the fact that snapshots are not being maintained is with
the relation or index definition, because the definition
must be accessed when the relation or index is reserved.
Storing it elsewhere would incur additional overhead.
The relation and index definitions are stored in the
RDB$SYSTEM area.
Consequently, if the RDB$SYSTEM area has been set to read-
only you are not permitted to access any relation of index
in the exclusive mode. This condition affects all database
access.
2.11.1.5 Joined Relations Do Not Allow "MODIFY" if Using the WITH
Clause
The Rdb/VMS V3.0 and V3.1 documentation indicates that
views do not allow updates to returned data. They do not
specify this restriction on a cross of two relations from
the same database. Rdb/VMS allows it to work if you use a
WITH clause.
Any field that appears in the record selection expression
(RSE) is marked as read-only. You cannot update these
fields as this may remove the record from the join, or
add a new record to the join that will not be recognized.
Known Problems, Restrictions, and Other Notes 2-163
In general, the record stream created by a join (CROSS)
is not updatable. A workaround is to fetch the RDB$DB_KEY
in the loop and generate a separate FOR loop to modify the
value. The following example shows this situation:
#include stdio
DATABASE MAPB = FILENAME "[rdml]PERSONNEL";
main()
{
READY MAPB;
START_TRANSACTION READ_WRITE;
printf("Entering EMPLOYEES & JOB_HISTORY relations:\n\n");
FOR E IN EMPLOYEES
CROSS JH IN JOB_HISTORY OVER EMPLOYEE_ID
WITH (JH.EMPLOYEE_ID > "00000" OR E.FIRST_NAME STARTING WITH "A-")
SORTED BY E.LAST_NAME
FOR E1 IN EMPLOYEES WITH E1.RDB$DB_KEY = E.RDB$DB_KEY
printf("\n\n%s %s < found ",E1.FIRST_NAME ,E1.LAST_NAME);
MODIFY E1 USING
strcpy(E1.FIRST_NAME,"Xavier ");
printf("\n%s %s < changed",E1.FIRST_NAME,E.LAST_NAME);
END_MODIFY;
END_FOR;
END_FOR;
printf("\n\nRolling Back the modifys");
ROLLBACK;
FINISH;
printf("\n\nFinished");
}
2.11.1.6 DECLARE and START Stream Are No Longer Allowed for
Certain Views
RDO does not allow a record stream from which data values
cannot be fetched (views that retrieve values from streams
defined using the SQL GROUP BY or UNION clauses) to be
declared or started. Such attempts produce the following
exception:
VWNOFETCH view 'view-name' cannot be fetched within a stream
2-164 Known Problems, Restrictions, and Other Notes
2.11.1.7 A Clarification of the Storage Algorithm for Mixed Pages
A problem was found when clustering records of two
different relations on one page, in a mixed storage area,
and storing duplicate records for one of the relations.
The first duplicate record was stored on a consecutive
page, while additional records were stored on the target
page until the SPAM value indicated that the page was
full. A display of the contents of the data page showed
sufficient free space on the target page for storing the
first duplicate record. Even thought there was sufficient
space, the first duplicate record was not stored on the
target page.
This is a known restriction in V4.0. Whenever a process
holds a lock (for example a read lock) on a page and at the
same time another process is trying to store a record on
that page, the record is stored on a nearby page.
When Rdb/VMS stores a record, it tries to optimize the
storage process. Therefore, if the page where the record
would ideally be stored is not immediately available,
Rdb/VMS simply finds a nearby page that is immediately
available and stores it there. This algorithm does quite
well for many database designs.
There is a trade-off between storage performance and
retrieval performance. If Rdb/VMS chose to wait during a
store operation, the resulting clustering would be good,
but the storage performance would suffer. On the other
hand, if Rdb/VMS did not wait during a store operation
(as it does now), the clustering might suffer. However,
this lack of clustering happens only when other processes
holding locks on the same page at the same time that store
operations are being attempted. If the page in which
the record is actually stored is in the same buffer, the
retrieval will not incur more I/O operations.
This condition will be considered for further investigation
in a future release.
Known Problems, Restrictions, and Other Notes 2-165
2.11.1.8 SELECT on DATABASE (READ on DATABASE) ACE Is Now
Required
The Rdb/VMS security mechanism now requires users to have
the SELECT privilege on the access control entry (ACE)
(in V4.1, SELECT privilege on the DATABASE ACE) or READ
privilege on the DATABASE access control entry (RDO).
The SELECT schema privilege (in V4.1, the SELECT database
privilege) has always been enforced, but not explicitly.
A user must now have the SELECT schema privilege in the
schema ACE in order to attach to a schema (in V4.1, a user
must now have the SELECT database privilege in the database
ACE in order to attach to a database).
Rdb/VMS schema privileges (in V4.1, database privileges)
DBADM, OPERATOR, and SECURITY; and VMS privileges SYSPRV,
BYPASS, READALL, OPERATOR, and SECURITY can bypass this
check. These privileges receive an implicit schema SELECT
privilege (in V4.1, database SELECT privilege).
2.11.1.9 Rdb/VMS Network Link Failure Does Not Allow FINISH (in
V4.1, DISCONNECT) to Tidy Up Transactions
If you have a program that attaches to a database on a
remote node and you lose the connection before the COMMIT
statement is issued, there is nothing you can do except
exit the program and start again.
The problem occurs when a program is connected to a
remote database and does an update but then just before
it commits, the network fails. When the commit executes,
the SQL code shows as it normally should that the program
has lost the link. Perhaps the user would like to wait
for a minute or two, then try the transaction again. The
problem is that when the start transaction is issued for
the second time, it fails because old information still
exists about the previous failed transaction. This occurs
even if the user issues a FINISH statement (in V4.1, a
DISCONNECT statement), which also fails with an RDB-E-IO_
ERROR error message.
2-166 Known Problems, Restrictions, and Other Notes
2.11.1.10 VAX Data Distributor Copy Processes Do Not Process
Database Pages Ahead of an Application
When a group of copy processes initiated by VAX Data
Distributor begins running after an application has begun
modifying the database, the copy processes will catch up
to the application and will not be able to process database
pages that are logically ahead of the application in the
RDB$CHANGES relation. The copy processes will all align
waiting for the same database page and will not move on
until the application has released it. The performance of
each copy process degrades because it is being paced by the
application.
When a copy process completes updates to its respective
remote database, it updates the RDB$TRANSFERS relation and
then tries to delete any RDB$CHANGES records not needed
by any transfers. During this process the RDB$CHANGES
relation cannot be updated by any application process,
holding up any database updates until the deletion process
is complete. The application will stall while waiting for
RDB$CHANGES. The resulting contention for RDB$CHANGES
SPAM pages and data pages severely impacts performance
throughput, requiring user intervention with normal
processing.
This is a known restriction in V4.0 and higher. Rdb/VMS
uses page locks as latches. These latches are held only
for the duration of an action on the page and not to the
end of transaction. The page locks also have blocking
asynchronous system traps (ASTs) associated with them.
Therefore, whenever a process requests a page lock, the
process holding that page lock is sent a blocking AST
(blast) by VMS. The process that receives such a blast
queues the fact that the page lock should be released as
soon as possible. However, the page lock cannot be released
immediately.
Such work requests to release page locks are handled at
verb commit time. An Rdb/VMS verb is an Rdb/VMS query that
executes atomically, within a transaction. In general, one
RDO statement is a verb. Therefore, verbs that require the
scan of a large relation, for example, can be quite long.
An updating application does not release page locks until
its verb has completed.
Known Problems, Restrictions, and Other Notes 2-167
The reasons for holding on to the page locks until the
end of the verb are fundamental to the database management
system.
This condition is being investigated further in a future
release of Rdb/VMS.
2.11.1.11 Setting an Appropriate WSEXTENT Relative to WSQUOTA for
SORT/MERGE Operations
If you are performing any explicit sorting operations that
include projection (SQL ORDER BY and DISTINCT, and RDO
SORTED BY and REDUCE TO) or an implicit sort operation
as performed by the query optimizer, and the query is
taking more time than expected to complete and you notice
lots of disk accesses, you should check your WSEXTENT and
WSQUOTA parameter values to see if they are set properly
for the operation. For example, if the WSEXTENT value is
42,000 pages and the WSQUOTA value is 20,000 pages, try
setting the WSEXTENT parameter value closer to the value
for WSQUOTA. That is, WSEXTENT=WSQUOTA+2000. Sort (which
is called many times during this query execution) uses the
difference between these two parameters (in this case 2000
pages) to allocate VM for scratch space. This results in
excessive paging when a disk-based temporary file would be
more efficient.
The VMS Sort/Merge Utility Manual states that sometimes
less memory is desirable for these kinds of operations. If
the system is heavily used, the VMS operating system may be
unable to allocate all the pages in the working set extent
to your process. To avoid excessive paging in a heavily
used system, you could make the working set extent lower.
See the VMS Sort/Merge Utility Manual for more information.
2.11.1.12 Attempting to Acquire a Lock Could Cause an Infinite
Loop
In some rare cases, Rdb/VMS can go into an infinite loop
while attempting to acquire a lock. This problem occurs
only during contention situations with heavily loaded
systems and does not cause data corruption.
The looping process consumes the CPU and degrades
performance on that node. The process must be stopped
manually to correct the problem.
2-168 Known Problems, Restrictions, and Other Notes
2.11.2 SQL Known Problems and Restrictions for V4.0
Section 2.11.2.1 through Section 2.11.2.8 describe
known problems and restrictions in SQL for V4.0. These
restrictions also apply to V4.1 and V4.2.
2.11.2.1 SQL Allows False Redefinition of the DATE Data Type
If a domain is defined that redefines the DATE data type,
SQL returns no errors; however, it ignores the domain
definition.
Using SQL (Rdb/VMS V3.0B-001), you can issue the following
commands to show this:
SQL> CREATE DOMAIN DATE CHAR (100);
SQL> CREATE TABLE ABC
cont> (FIELD_1 DATE,
cont> FIELD_2 DATE);
SQL>
SQL> SHOW TABLE ABC;
SQL assigns the native mode data type of DATE to the
columns FIELD_1 and FIELD_2. Table ABC will show fields
FIELD_1 and FIELD_2 as data type DATE, and not as DOMAIN
date.
This continues as a restriction for V4.2. SQL allows SQL
keywords to be used as an identifier; that is, they are not
reserved words. This is an extension to the ANSI standard.
In any context where an identifier is expected, the
SQL keyword may be used, and it is understood to be an
identifier. However, in any context where the SQL keyword
is allowed, it is understood to be the keyword. In other
words, when SQL expects either a particular set of keywords
or an identifier, if the user attempts to use one of those
particular keywords as an identifier, SQL selects the
keyword meaning over the identifier meaning.
In table definitions, the data type of a column may be an
SQL data type (a keyword such as INTEGER, DATE, etc.) or a
domain (identifier). Because SQL is looking for either an
SQL data type name keyword or an identifier, when it sees
one of the SQL data type keywords, it has the SQL data type
meaning and not the domain meaning.
Known Problems, Restrictions, and Other Notes 2-169
A workaround is to use the authorization id of the domain
instead of the domain name alone. That is, if the schema is
the default schema, the authorization id is RDB$DBHANDLE,
and the statement distinguishes between the DATE domain
with the SQL data type by the same name. Similarly, in a
DECLARE <auth-id> SCHEMA statement, the <auth-id> allows
the domain to be used. For example:
SQL> CREATE DOMAIN DATE CHAR (100);
SQL> CREATE TABLE ABC
cont> (FIELD_1 RDB$DBHANDLE.DATE,
cont> FIELD_2 RDB$DBHANDLE.DATE);
2.11.2.2 Module Language Passes Extraneous Characters with
Inexact Dynamic Descriptors
Although SQL module language processes dynamic strings
correctly in other contexts, you must use either a static
descriptor or a dynamic descriptor of exact length whenever
you use the GENERAL language.
When you create an SQL module language source file
specifying the GENERAL language, you can define character
parameters that are passed by descriptor. The restriction
only applies when calling the module language from a
language that uses dynamic instead of static string
descriptors (such as BASIC or VAX SCAN), in particular
when passing a parameter to an INSERT operation. Instead
of padding the string with blanks, SQL stores extraneous
characters in the data field character positions after
those in the original dynamic string.
You can prevent this problem from occurring in a language
such as BASIC by putting the string definition in a MAP
declaration, which makes the string static instead of
dynamic.
2.11.2.3 Close List Cursor Before Fetching Rows from Table Cursor
When accessing SQL segmented strings, you must be careful
to close a list cursor before you fetch the next row in the
table cursor. If you fetch some, but not all, rows from a
list cursor and move to the next row in the table cursor
without closing the list cursor, you continue to fetch rows
from the previous list cursor.
2-170 Known Problems, Restrictions, and Other Notes
SQL does not issue a warning or error message telling you
that you have opened two list cursors. For example:
SQL>! Define a cursor of Board Manufacturing Department Managers
SQL>!
SQL> DECLARE BM_MGR CURSOR FOR
cont> SELECT EMPLOYEE_ID, RESUME FROM RESUMES R, CURRENT_INFO CI
cont> WHERE R.EMPLOYEE_ID = CI.ID AND DEPARTMENT
cont> CONTAINING "BOARD MANUFACTURING" AND JOB = "Department Manager";
SQL>!
SQL>! Define a cursor for resumes of those managers
SQL> DECLARE THE_RESUME LIST CURSOR FOR
cont> SELECT RESUME WHERE CURRENT OF BM_MGR;
SQL>!
SQL>! Build the manager's cursor
SQL> OPEN BM_MGR;
SQL>!
SQL>! Fetch the manager's row
SQL> FETCH BM_MGR;
R.EMPLOYEE_ID R.RESUME
00164 72:2:3
SQL>!
SQL>! Get part of the resume
SQL> OPEN THE_RESUME;
SQL> FETCH THE_RESUME;
RESUME
This is the resume for Alvin Toliver
SQL>!
SQL>! Do not close the resume, and access the next manager
SQL> FETCH BM_MGR;
R.EMPLOYEE_ID R.RESUME
00166 72:2:9
SQL>! SQL continues to fetch from Toliver's resume (00164)
SQL>! because the list cursor was not closed.
SQL>! If it were a new resume, you would see
SQL>! a new "This is the resume for ..." line.
SQL> FETCH THE_RESUME;
RESUME
Boston, MA
Known Problems, Restrictions, and Other Notes 2-171
2.11.2.4 When Using the BETWEEN Operator, You Should Specify the
Lower Value First
SQL now evaluates the BETWEEN operator differently to
comply with the ANSI/ISO standard. When using the BETWEEN
operator, you must specify the lower value first to obtain
the correct result:
BETWEEN 10 AND 20
With previous versions of SQL, the BETWEEN operator
returned the same results whether you specified the higher
or lower value first.
2.11.2.5 Cautions on Using ANY, ALL, or IN Clauses in Constraint
Definitions
For Rdb/VMS V3.1, a change was made to correct the results
returned by the ANY (SOME) and ALL predicates to conform
to the ANSI SQL standard. The changes required for ANSI
compliance produced a different type of query for ANY and
ALL (and for the IN predicate when a query expression is
used) such that the query can no longer be selectively
evaluated when used in a constraint. The workaround for
any performance problems introduced by this change is re-
creating the affected constraint with an EXISTS predicate
(or equivalent) applied to a column select expression, as
shown in the following example:
CHECK (T1.F1 IN (SELECT T2.F1 FROM T2))
- to -
CHECK (EXISTS (SELECT * FROM T2 WHERE T2.F1 = T1.F1))
- or -
CHECK ((SELECT COUNT (*) FROM T2 WHERE T2.F1 = T1.F1) <> 0)
2.11.2.6 Release of Cursor Statements Referencing Prepared
Statements Causes Problems
When a prepared statement refers to a cursor that is
destroyed by a release of its own statement, the first
statement becomes dangerous in this way. This is a known
problem that has existed since SQL V1.0. The following
example shows the problem:
2-172 Known Problems, Restrictions, and Other Notes
DECLARE A CURSOR FOR A_STMT;
PREPARE A_STMT FROM 'SELECT * FROM T';
PREPARE B_STMT FROM 'DELETE T WHERE CURRENT OF A';
OPEN A;
FETCH A;
EXECUTE B_STMT;
CLOSE A;
RELEASE A_STMT;
EXECUTE B_STMT; <--- This is dangerous as the cursor is gone.
2.11.2.7 SQL Does Not Translate Logical Names Referencing Source
Databases
When you create an extraction or extraction rollup transfer
and you want to use a source database that requires the
/TYPE access string, you must first enter a DECLARE SCHEMA
statement for that database. One method of referencing the
source database is to define a logical name, as shown in
the following example:
$ DEFINE SOURCE_DB "/TYPE=VIDA2/DATABASE=SHIPPING..."
$ SQL
SQL> DECLARE SCHEMA FILENAME SOURCE_DB;
SQL> CREATE TRANSFER FROM_SHIPPING TYPE IS EXTRACTION ...
However, SQL does not translate the logical name into
the access string when the source schema is declared by
referring to a logical name. In the previous example,
examination of the transfer definition will show
"From . . . SOURCE_DB" instead of "From . . . /TYPE=VIDA2
/DATABASE=SHIPPING . . . ".
The transfer will fail to execute properly unless the
SOURCE_DB logical name is defined when the copy process
runs. A copy process runs as a detached process using
the same VMS account that you use to create the transfer.
Therefore, the SOURCE_DB logical name will be properly
translated if you define it in your LOGIN.COM file. The
logical name can also be defined in your group or system
logical name tables. The logical name "SOURCE_DB" is used
here as an example; you can use any name you want.
Known Problems, Restrictions, and Other Notes 2-173
2.11.2.8 Problem with Transferring a Table to an Existing
Database Containing the Same Table Name
If you define a transfer to an existing database and
specify a table name in the transfer definition that
already exists in the target database, SQL checks to
determine if the table was created by the current transfer.
o If the transfer owns the table, then the transfer
definition is valid.
o If the transfer does not own the table, SQL issues an
error message and the transfer fails. You must use the
INTO keyword with the table-name parameter to rename the
duplicated table.
However, in SQL V4.0, SQL looks for the source table
name in the target database instead of the table name
specified in the INTO table-name clause. Because the source
table name does exist but does not belong to the current
transfer, SQL issues an error message declaring that the
transfer does not own the table.
The following example illustrates this situation. Assume
that EMP_ COLLEGES in the target database PERS_1 is not
owned by transfer XYZ.
SQL> DECLARE SCHEMA FOR FILENAME "PERSONNEL";
SQL> CREATE TRANSFER XYZ TYPE IS REPLICATION
cont> MOVE TABLES
cont> SELECT * FROM COLLEGES INTO EMP_COLLEGES
cont> TO EXISTING FILENAME DISK1:[DIR1]PERS_1
cont> LOG FILE IS DISK1:[DIR1]XYZ.LOG
cont> ;
%SQL-F-TRANOTOWNER, This transfer is not the owner of table EMP_COLLEGES
You can resolve this problem by using the WITH NO CHECKING
qualifier with the CREATE TRANSFER statement, as shown in
the following example:
SQL> DECLARE SCHEMA FOR FILENAME "PERSONNEL";
SQL> CREATE TRANSFER XYZ TYPE IS REPLICATION
cont> MOVE TABLES
cont> SELECT * FROM COLLEGES INTO EMP_COLLEGES
cont> TO EXISTING FILENAME DISK1:[DIR1]PERS_1 WITH NO CHECKING
cont> LOG FILE IS DISK1:[DIR1]XYZ.LOG
2-174 Known Problems, Restrictions, and Other Notes
2.11.3 RDO and RDBPRE Known Problems and Restrictions for V4.0
Section 2.11.3.1 describes a known problem and restriction
in RDO for V4.0.
2.11.3.1 RDO SHOW USERS and SHOW MONITOR Statements Do Not Work
for Remotely Accessed Databases
If you access a database remotely, you cannot use the
RDO SHOW USERS or SHOW MONITOR statements. The following
example shows this problem.
RDO> SHOW USERS
Database with filename ARTIC::personnel
%RDMS-F-BAD_NAME, illegal filename
-RDMS-F-NONODE, no node name is allowed in the file specification
RDO>
Note that for V4.1 both of these RDO statements are
obsolete. The comparable RMU commands must be used to
display this information.
2.11.4 RDML Known Problems and Restrictions for V4.0
Section 2.11.4.1 contains an RDML known problem and
restriction for V4.0 that also applies to V4.1 and V4.2.
2.11.4.1 RDML Generates an Error Message When Attempting to Store
or Modify Read-Only (COMPUTED BY) Fields
In RDML, if you use a PATHNAME clause in combination
with a STORE * clause or a MODIFY * clause on a relation
containing a COMPUTED BY field, RDML generates the
following error:
%RDML-E-READ_ONLY, Invalid attempt to update a read only field 'FLD3'
%RDML-I-ATLINE, at line 32 in the file DISK1:[TTEMP]TEST.RPA;
%RDML-I-NODMLOUTPUT, No output file generated due to errors
%RDML-I-SUMMARY, Completed with 1 Error, 0 warnings, and
1 informational message
2.11.5 RMU Known Problems and Restrictions for V4.0
Section 2.11.5.1 through Section 2.11.5.2 describe known
problems and restrictions in RMU for V4.0.
Known Problems, Restrictions, and Other Notes 2-175
2.11.5.1 Single-File Databases Require the /ROOT Qualifier When
Using the RMU/MOVE_AREA Command
You must specify the /ROOT qualifier when you use the
RMU/MOVE_AREA command on a single-file database. If
you omit the /ROOT qualifier, you will receive an error
message. When you specify the /ROOT qualifier, specify the
location where you want the root file moved. For example:
RMU/MOVE_AREA/ROOT=DISK1:[DATABASE.TEST] PERSONNEL
2.11.5.2 The RMU/BACKUP/AFTER_JOURNAL /CONTINUOUS
/UNTIL="TOMORROW:+00:50" Command Fails for V3.1A
and VMS V5.3 or V5.4
When the RMU/BACKUP/AFTER_JOURNAL/CONTINUOUS
/UNTIL="TOMORROW:+00:50" command is performed, it works
correctly for V3.0B and VMS 5.1 or VMS 5.4 but fails with
the following errors in V3.1A and higher (through V4.1) and
VMS V5.3 and VMS V5.4:
RMU-F-BADVALUE, invalid value "TOMORROW:+00:50"
LIB-F-AMBDATTIM, ambiguous date-time
The reason for this problem is that VMS did not make the
library routine LIB$CONVERT_DATE_STRING fully compatible
with the $BINTIM system service. Your time specification is
acceptable to $BINTIM but not to the library routine.
A workaround is to replace the part of the command
"TOMORROW:+00:50:" with the date for the following day
and the command will work correctly.
2.11.6 CDD/Plus Restrictions for V4.0
Section 2.11.6.1 through Section 2.11.7.1 describe known
problems and restrictions in CDD/Plus V4.2.
2.11.6.1 Problem Adding a New Field to CDO Defined Record and Not
to Last Position
If a new field is added to a CDO defined record and not
to the last position, it causes a mismatch on field order
if the record is used as a basis for a relation. Because
the new field is put at the end of the Rdb/VMS relation, a
one-to-one correspondence no longer exists.
2-176 Known Problems, Restrictions, and Other Notes
This also causes problems for precompiled SQL code when
it passes all the fields from the relation into a storage
area within the program. However, similar constructs using
RDBPRE handle the mapping correctly.
This problem was fixed in V4.0. An error message is now
displayed.
A workaround is to use the PATHNAME qualifier to declare
the schema to ensure that the dictionary record and the
table are synchronized.
The INCLUDE FROM DICTIONARY statement builds an internal
representation of the structure that the host language
will get from the dictionary; the dictionary is used to
determine which fields are in the record and in what order.
If the schema is declared with the FILENAME qualifier,
the precompiler uses the system relations to determine
which columns are in each table and in what order. On the
other hand, if the schema is declared by PATHNAME, the
precompiler uses the dictionary to determine which columns
are in each table and in what order.
When the schema is declared with the FILENAME qualifier and
the dictionary is used to define a data structure, the star
of the SELECT statement for the UPDATE_CHG cursor expands
to a list of columns in the order in which they are known
to Rdb/VMS (which never reorders them) and the dbord_rel
structure contains fields in the order in which they are
known to the dictionary. They do not match, and the FETCH
statement attempts to assign values to the wrong fields.
They do match, however, when the schema is declared by
PATHNAME. The start of the SELECT statement expands to a
list of columns in the same order as the fields of the
dbord_rel structure.
The reason for the difference between SQLPRE and RDBPRE
is that RDBPRE uses a different mechanism for building the
source column list.
Known Problems, Restrictions, and Other Notes 2-177
2.11.6.2 SQL Does Not Recognize a Record During SQL Precompile
Time
During SQL precompile time, SQL does not recognize a record
used in the program by its language process name. The error
detected is:
%SQL-F-HVNOTDECL, (1) Host variable xxx was not declared.
This problem occurs in V3.0B, V3.1, and V4.0.
When you define fields and records in CDD/Plus with CDO,
and insert a PROCESS NAME for a language with the CDO
editor, SQL is not able to use it.
In COBOL, for example, the COPY FROM DICTIONARY retrieves
the PROCESS NAME for COBOL as expected in spite of the
PROCESSING NAME. But, when you use the specified PROCESS
NAME for COBOL in an SQL sentence like:
EXEC SQL DECLARE xxx CURSOR FOR
SELECT ....
FROM ....
WHERE e.employee_id = :my_process_name_record.a_field
END_EXEC.
You will get the following error:
%SQL-F-HVNOTDECL, (1) Host variable A_FIELD was not declared.
If you use the processing name of the record, no error
occurs on its field; however CDD/Plus has lost some of its
functionality.
In V4.0 of Rdb/VMS, SQL does not support the process name
in the dictionary.
2.11.6.3 Some Views Are Not Accepted by VAX CDD/Plus V4.2
Views that contain subqueries are not accepted by
VAX CDD/Plus (V4.0, V4.1, and V4.2). Attempts to define
these views will result in the following error during the
CREATE VIEW command:
CREATE VIEW V5 AS
SELECT * FROM AAA
UNION
SELECT H1 FROM BBB
WHERE H1 = (SELECT G1 FROM CCC WHERE G1 > 1);
%CDD-E-BLRSYNERR, syntax error in BLR buffer at offset 0
2-178 Known Problems, Restrictions, and Other Notes
The workaround is to attach to the database by using the
FILENAME qualifier before defining the view. This problem
will be corrected in a future version of VAX CDD/Plus.
2.11.7 Restrictions Lifted by CDD/Repository V5.0
2.11.7.1 GRANT and REVOKE Statements Generate MBLRSYNERR Message
if Attached by Path Name
The GRANT and REVOKE statements are not fully supported
by CDD/Plus V4.2. Attach by file name when changing access
control.
This restriction is corrected in CDD/Repository V5.0.
2.11.8 Restrictions Lifted by CDD/Plus V4.2
Section 2.11.8.1 describes a known problem and restriction
lifted in CDD/Plus V4.2.
2.11.8.1 Incompatibilities Between Rdb/VMS V4.0 and CDD/Plus That
Have Been Lifted by VAX CDD/Plus V4.2
Collating sequences, ascending and descending index
attributes, and view definitions containing the UNION
operator, the WITH CHECK OPTION, and the USER literal are
now accepted by CDD/Plus V4.2.
2.12 Restrictions Retained from V3.1
This section begins with V3.1 restrictions pertinent to all
users and ends with restrictions specific to SQL, RDO, and
RDML.
Therefore, the notes in this section may use different
database terms to mean the same thing. For example,
some terms used by SQL differ from terms used by other
interfaces, such as RDO or RDML. Table 1 in the VAX Rdb/VMS
New and Changed Features lists the different terms used.
2.12.1 Known Problems and Restrictions for All Interfaces for
V3.1
Section 2.12.1.1 through Section 2.12.1.12 contain known
problems and restrictions for all interfaces for V3.1.
These restrictions also apply to V4.0, V4.1 and V4.2.
Known Problems, Restrictions, and Other Notes 2-179
2.12.1.1 Object Modules Created with V3.1 and V4.0 Are Not
Downward-Compatible
Due to enhancements in Rdb/VMS V3.1 and V4.0 (to
support two-phase commit), object modules created by the
precompilers RDBPRE, SQL$PRE, and the SQL module language
compiler SQL$MOD are not compatible with previous versions
of Rdb/VMS. Therefore, executable images created using
these object modules also will not function correctly
if run on a system with a previous version of Rdb/VMS
installed.
These precompilers now generate extra parameters for
certain calls. Attempts to move and execute these modules
will result in errors similar to the following:
%RDB-E-WRONUMARG, wrong number of arguments on call to facility
________________________ Note ________________________
Note that remote access through DECnet is not affected
in any way by these changes. This restriction only
applies to the movement of compiled and linked
modules.
______________________________________________________
2.12.1.2 With the Exception of Views, Do Not Add Fields to
Relations, or Define Indexes, Triggers, and Other
Database Objects Based on System Relation Fields
You should not add fields to relations based on system
relation fields. You can however, add fields to views
based on system relation fields as this portion of the
restriction was lifted for views beginning with V4.0A. In
addition, you should not define indexes, triggers, or any
other database objects on any system relation fields.
2.12.1.3 Performance Considerations for Using VARYING STRING or
COLLATING SEQUENCE Attribute for Index Keys
Database designers should be aware of the following
optimizer restrictions concerning references to fields
with the COLLATING SEQUENCE attribute, or fields whose data
type is VARCHAR (VARYING STRING). These restrictions affect
performance with respect to I/O operations.
2-180 Known Problems, Restrictions, and Other Notes
The optimizer Index Only Retrieval and Key-Only Boolean
strategies are disabled if any field in the index has a
collating sequence defined, or is a VARYING STRING field.
These two retrieval strategies require Rdb/VMS to return
data stored in the index node, or perform comparisons based
on the index node key fields, thus saving I/O operations
to the data record. However, the original user data cannot
be reconstructed from the encoded index if these attributes
are used. Therefore, the optimizer forces a Retrieval by
Index strategy instead, which requires I/O operations to
the data record.
These restrictions may affect the choice of data type for
fields to be used in indexes. For example, PRODUCT_ID,
which has a data type of CHAR(20), is part of an index P_
INDEX. A query that uses STARTING WITH against PRODUCT_ID
allows the user to enter a partial product code. It then
fetches the matched PRODUCT_ID field for display to the
user, but does not fetch any other fields. This query would
normally be optimized to reference the index PRODUCT_ID_IX
only (that is, using an Index Only Retrieval strategy).
However, if the field were defined as VARCHAR(20), the
optimizer would be required to reference the data record
to fetch the PRODUCT_ID. This will add some extra I/O
operations to the translation query. Therefore, CHAR (TEXT)
data type may be preferable to VARCHAR (VARYING STRING) if
the field is involved in index retrieval.
The following example demonstrates this simple case.
Note that the optimizer strategy as displayed when the
RDMS$DEBUG_FLAGS logical is set to "S" has been inserted
after each query:
Known Problems, Restrictions, and Other Notes 2-181
SQL> SHOW TABLE PRODUCTS
Columns for table PRODUCTS:
Column Name Data Type Domain
----------- --------- ------
PRODUCT_ID_V VARCHAR(20) PRODUCT_ID_V
PRODUCT_ID_T CHAR(20) PRODUCT_ID_T
.
.
.
Indexes on table PRODUCTS:
P_INDEX_T with column PRODUCT_ID_T
duplicates are allowed
type is sorted
P_INDEX_V with column PRODUCT_ID_V
duplicates are allowed
type is sorted
.
.
.
SQL>
SQL> SELECT PRODUCT_ID_T
cont> FROM PRODUCTS
cont> WHERE PRODUCT_ID_T STARTING WITH "AAA";
Conjunct Get Index only retrieval
Retrieval by index of relation PRODUCTS Index name P_INDEX_T
00000001 Segments in low Ikey 00000001 Segments in high Ikey
0 rows selected
SQL>
SQL> SELECT PRODUCT_ID_V
cont> FROM PRODUCTS
cont> WHERE PRODUCT_ID_V STARTING WITH "AAA";
Conjunct Get Retrieval by index of relation PRODUCTS
Index name P_INDEX_V 00000001 Segments in low Ikey
00000001 Segments in high Ikey
0 rows selected
SQL>
SQL> COMMIT;
________________________ Note ________________________
Most queries use indexes as a fast access method
to reference rows (records) of data so that an
2-182 Known Problems, Restrictions, and Other Notes
I/O operation to the data record will normally be
required.
______________________________________________________
2.12.1.4 Sorting or Implied Sorting for Projection on a Dbkey Is
Not Worthwhile
Sorting (or any implied sorting for projection) will not
sort dbkeys in such a way that the dbkeys can be used to
retrieve records in sequential order.
The reason for this behavior is that dbkeys are treated
as fixed-length text strings of 8 * n bytes, where n in
the number of tables concerned (may be one or more for
views). Therefore, sorting dbkeys will order the text bytes
according to the default ASCII collating sequence.
2.12.1.5 IMPORT Statement Fails to Complete Index Definition with
Users Attached to the Database
If users attach to the database before an IMPORT statement
has completed, Rdb/VMS displays the following messages:
RDO-E-NOIDXREV, unable to import index indexname
RDB-E-LOCKCONFLICT, request failed ..
RDB-E-NOMETAUPDATE, ...
RDMS-F-LCKCONFLCT, lock conflict on client.
These messages appear on two of the indexes (both sorted),
and the IMPORT statement fails to create those indexes.
The behavior of the IMPORT statement requires that no other
users attach to the database while it is being imported,
or alternately, that the indexes are defined in a separate
operation.
2.12.1.6 Using LIB$DT_INPUT_FORMAT to Change Date Input Format
Sometimes Causes Access Violation
There is a known problem with the VMS V5.3 Run-Time Library
function LIB$CONVERT_DATE_STRING. This is the routine
Rdb/VMS uses in precompiled programs, SQL module language,
and the RDO and SQL interactive interfaces to convert dates
to internal format. When the logical name LIB$DT_INPUT_
FORMAT is used to change the date input format, the run-
time library sometimes causes an access violation that
probably prevents the precompiler or module language
compiler from continuing, but does not cause any loss of
Known Problems, Restrictions, and Other Notes 2-183
data from interactive SQL. The access violation is shown in
the following example:
%SQL-F-DATCONERR, Data conversion error
-SYSTEM-F- ACCVIO, access violation, ...
The problem is in LIB$CONVERT_DATE_STRING, in the logic
that handles meridian indicators.
The only workaround is to use a different date format.
2.12.1.7 Operations on F-Floating Data Round to Whole Numbers
When Rdb/VMS performs any arithmetic addition, and either
or both of the operands is in F-floating format, the result
is rounded to the nearest whole number. For example, if the
statistical function TOTAL is used on a field (or the SQL
equivalent) defined as F-floating, and if data with decimal
values is stored in that field, the result is rounded to a
whole number. If the F-floating field contained the values
4.51 and 5.01, TOTAL would return the value 10, rather than
9.52 (the actual sum).
To avoid this rounding of floating-point results, use
another data type (such as quadword) for the fields rather
than the F-floating data type.
2.12.1.8 Rdb/VMS Interaction with Data Distributor V2.1 May
Generate Bugcheck Dumps
Under certain circumstances, Rdb/VMS generates bugcheck
dumps when interacting with VAX Data Distributor V2.1.
Typically, this situation occurs when you execute an
RDO STORE, MODIFY, or ERASE statement (or their SQL
equivalents), and have many Boolean expressions on
transfers for one relation.
The exception for the bugcheck is usually RDMS$$EXECUTE_
ECON. The problem is that the amount of code generated to
test the Boolean expressions for the relation is greater
than 32767 bytes. A BRW instruction is used to exit the
Boolean comparison, and the BRW has a range of -32768 to
32767.
The following workarounds are suggested:
o Use fewer transfers on the relation, or use fewer
Boolean expressions.
2-184 Known Problems, Restrictions, and Other Notes
o Create a dummy transfer to transfer the entire relation
to a local database. This will cause Rdb/VMS to
ignore the Boolean comparison, as all records must be
journaled.
2.12.1.9 Problem Defining COLLATING SEQUENCE IS NORWEGIAN
NORWEGIAN
There is a problem in the collating sequence file currently
provided by the VMS kit for the Norwegian language.
The following example produces a bugcheck dump:
CREATE SCHEMA ... COLLATING SEQUENCE IS NORWEGIAN NORWEGIAN;
You can correct this problem on your system by doing the
following:
1. Use the command NCS/OUT=NORWEGIAN/EXT=NORWEGIAN to
obtain a file, NORWEGIAN.NCS. This file contains the
following assignments:
..............................................................
NORWEGIAN = CS(
SEQUENCE = (%X00-"N", "Ñ", "O"-"Z", "Æ", "Ö", "Å", "["-"`", "{"-"¿", %XD0,
%XDE, %XF0, %XFE-%XFF),
MODIFICATIONS=("a"-"z" = "A"-"Z", "À"-"Ã" = "A", "Ç" = "C", "È"-"Ë" = "E",
"Ì"-"Ï" = "I", "Ò"-"Õ" = "O", "Ø" = "Ö", "Ù"-"Û" = "U", "Ü"-"Ý" = "Y"
"à"-"ã" = "A", "Å"-"æ" = "Å"-"Æ", "ç" = "C", "è"-"ë" = "E",
"ì"-"ï" = "I", "ñ" = "Ñ", "ò"-"õ" = "O", "ö" = "Ö", "ø" = "Ö",
"ù"-"û" = "U", "ü"-"ý" = "Y", "Ä" = "AE", "×" = "OE", "ß" = "SS",
"ä" = "Ä", "÷" = "×", "" < %X00))
+ CS( SEQUENCE = (%X00-"A", "À"-"Ä", "B"-"C", "Ç", "D"-"E", "È"-"Ë",
"F"-"I", "Ì"-"Ï", "J"-"N", "Ñ", "×", "O", "Ò"-"Ö", "P"-"R", "ß",
"S"-"U", "Ù"-"Ü", "V"-"Y", "Ý", "Z", "Æ", "Ø", "Å", "["-"`", "{"-"¿",
%XD0, %XDE, %XD0, %XFE-%XFF),
MODIFICATIONS=("a"-"z" = "A"-"Z", "à"-"ï" = "À"-"Ï", "ñ"-"ý" = "Ñ"-"Ý"))
+ REVERSE(_NATIVE);
..............................................................
2. Correct the assignment: "Ä" = "AE" to "Ä" = "Æ".
3. Insert or replace the corrected definition in your
NCS.NLB.
Known Problems, Restrictions, and Other Notes 2-185
One way to insert the corrected definition is to
create a file, NORWEGIAN_CORRECTED.NCS, that contains
a corrected sequence:
..............................................................
NORWEGIAN_CORRECTED = CS(
SEQUENCE = (%X00-"N", "Ñ", "O"-"Z", "Æ", "Ö", "Å", "["-"`", "{"-"¿", %XD0,
%XDE, %XF0, %XFE-%XFF),
MODIFICATIONS=("a"-"z" = "A"-"Z", "À"-"Ã" = "A", "Ç" = "C", "È"-"Ë" = "E",
"Ì"-"Ï" = "I", "Ò"-"Õ" = "O", "Ø" = "Ö", "Ù"-"Û" = "U", "Ü"-"Ý" = "Y"
"à"-"ã" = "A", "Å"-"æ" = "Å"-"Æ", "ç" = "C", "è"-"ë" = "E",
"ì"-"ï" = "I", "ñ" = "Ñ", "ò"-"õ" = "O", "ö" = "Ö", "ø" = "Ö",
"ù"-"û" = "U", "ü"-"ý" = "Y", "Ä" = "Æ", "×" = "OE", "ß" = "SS",
"ä" = "Ä", "÷" = "×", "" < %X00))
+ CS( SEQUENCE = (%X00-"A", "À"-"Ä", "B"-"C", "Ç", "D"-"E", "È"-"Ë",
"F"-"I", "Ì"-"Ï", "J"-"N", "Ñ", "×", "O", "Ò"-"Ö", "P"-"R", "ß",
"S"-"U", "Ù"-"Ü", "V"-"Y", "Ý", "Z", "Æ", "Ø", "Å", "["-"`", "{"-"¿",
%XD0, %XDE, %XD0, %XFE-%XFF),
MODIFICATIONS=("a"-"z" = "A"-"Z", "à"-"ï" = "À"-"Ï", "ñ"-"ý" = "Ñ"-"Ý"))
+ REVERSE(_NATIVE);
..............................................................
4. Issue the VMS command NCS/INS NORWEGIAN_CORRECTED.
This command inserts the corrected sequence in your
NCS.NLB. You may then choose to replace the erroneous
sequence in your NCS.NLB with this corrected one.
2.12.1.10 Snapshot File Name, File Type, or Version Number Cannot
Be Changed for Single-File Databases
If you change the file name, file type, or version of a
snapshot file and then try to access the database through
the SQL interface, you get the following error messages:
SQL> ATTACH 'FILENAME PERSONNEL';
%SQL-F-ERRATTDEC, Error attaching to database personnel
-RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error opening storage area file
SQL_USER:[ELLINGSWORTH.SQL]PERSONNEL.SNP;1
-RMS-E-FNF, file not found
SQL>
The name of the snapshot file in a single-file database
is always derived from the root file name. Users must not
change the file name, file type, or version of the snapshot
file for a single-file database.
2-186 Known Problems, Restrictions, and Other Notes
It is possible to use logical names to relocate the
snapshot file to another directory or device. The
RMU/RESTORE/SNAPSHOT=(FILE= . . . ) command permits this
relocation. Users must define the appropriate logical name
to relocate the snapshot file.
If you experience this restriction, simply rename the
snapshot file (using the VMS RENAME command) to its correct
file name, file type, and version number.
2.12.1.11 Rdb/VMS and VMS Debugger Interaction
There are often reports of unexpected interaction between
Rdb/VMS and the VMS Debugger when application programmers
are debugging code. Programs running under the control
of the debugger, usually with a watchpoint enabled, may
receive one of the following error messages:
%RDB-F-BAD_DB_HANDLE, invalid database handle
%RDB-F-BAD_REQ_HANDLE, invalid request handle
%RDB-F-BAD_TRANS_HANDLE, invalid transaction handle
%RDB-F-NOARGACC_WRITE, database facility cannot write to argument !UL
%RDB-F-NOARGACC_READ, database facility cannot read argument !UL
The application runs as expected if the application is
modified slightly or when no trace or watchpoints are
established in the debugger.
To explain what is happening in Rdb/VMS, it helps to
understand how the VMS Debugger implements the SET WATCH
command, and this involves some understanding of the VMS
operating system.
Pages in the working set allow access to four security
levels:
o Kernel mode-the most privileged
o Executive mode-most Record Management System (RMS) code,
the Rdb/VMS executive, most system services
o Supervisor mode-mostly DCL
o User mode-most user-written application code
When a watchpoint is established, the VMS Debugger changes
the protection of the page in P1 space so that the image
running in user mode will not be able to write to the
specified address.
Known Problems, Restrictions, and Other Notes 2-187
When the page is accessed by the application, an exception
occurs that is handled by the debugger's exception handler.
The address of the access violation is examined to see if
it is being watched and, if so, the debugger executes the
required trace actions and executes the failed instruction
again.
Privileged code, such as the Rdb/VMS executive and the
VMS system services, performs operations on behalf of
nonprivileged users running in user mode. For security
reasons, code running in executive and kernel mode must
ensure that the memory locations passed from the user
application not only exist, but can also be accessed from
the user's current (usually nonprivileged) mode. The VMS
instruction set provides two instructions to check access
rights to memory locations-PROBER (probe for read access)
and PROBEW (probe for write access).
The Rdb/VMS executive uses these instructions to ensure
that all application memory locations can be accessed at
the appropriate security level (sometimes access must be
at user mode). If the access fails, Rdb/VMS will signal an
error. This checking completely bypasses the exception
and trapping required by the debugger. Therefore, the
application's behavior is different because of the changed
page protections.
Because the programmer usually is not actually watching
any Rdb/VMS variables, such as transaction and request
handles, the Rdb/VMS error comes as a surprise. The error
results because the protection is at the page level, which
is rather coarse, and the location being traced happens to
fall on the same page as the Rdb/VMS variables.
It is possible for a knowledgeable programmer to avoid
this problem by defining a large array so that the data
locations are pushed onto separate pages. This is the
reason the error message often disappears after editing
and recompiling the code or simply recompiling with a
/NOOPTIMIZE qualifier.
For more information, see the sections on watchpoint
options, and on how the debugger controls program execution
in the VMS Debugger Manual.
2-188 Known Problems, Restrictions, and Other Notes
2.12.1.12 Using Rdb/VMS from a VMS Detached Process
Rdb/VMS V3.1 documentation omits necessary detail on
running Rdb/VMS from a detached process.
Applications run from detached processes must ensure that
the VMS environment is established correctly before running
Rdb/VMS, otherwise Rdb/VMS will not execute.
Attempts to attach to a database and execute an Rdb/VMS
query from applications running as detached processes will
result in an error similar to the following:
%RDB-F-SYS_REQUEST, error from system services request
-SORT-E-OPENOUT, error opening !AS as output
-RMS-F-DEV, error in device name or inappropriate device type for operation
The problem occurs because a detached process does not
normally have the logical names SYS$LOGIN or SYS$SCRATCH
defined.
There are two methods that can be used to correct this:
o Solution 1:
$ RUN/DETACH/AUTHORIZE SYS$SYSTEM:LOGINOUT/INPUT=RUN-PROCEDURE
The DCL command procedure RUN-PROCEDURE runs the
ACCOUNTS application:
$ RUN ACCOUNTS_REPORT
This solution executes SYS$SYSTEM:LOGINOUT so that the
default command language interface (CLI) is activated
(this is usually DCL). This causes the logical names
SYS$LOGIN and SYS$SCRATCH to be defined for the detached
process. The /AUTHORIZE qualifier also ensures that
the users' process quota limits (PQLs) are used from
the system authorization file rather than relying on
the default PQL system parameters, which are often
insufficient for Rdb/VMS.
o Solution 2:
If DCL is not desired, and SYS$LOGIN and SYS$SCRATCH
are not defined, then prior to executing any Rdb/VMS
statement, you must define the following logical names:
- RDMS$BIND_WORK_FILE
Known Problems, Restrictions, and Other Notes 2-189
Define the RDMS$BIND_WORK_FILE logical name to allow
you to reduce the overhead of disk I/O operations for
matching operations when used in conjunction with the
RDMS$BIND_WORK_VM logical name.
For more information on RDMS$BIND_WORK_FILE, see the
V4.1 VAX Rdb/VMS Guide to Database Performance and
Tuning.
- SORTWORK0, SORTWORK1, and so forth
The VMS Sort utility attempts to create sort work
files in SYS$SCRATCH. If the SORTWORK logical names
exist, the utility will not require the SYS$SCRATCH
logical. However, note that not all queries will
require sorting, and that some sorts will be
completed in memory and so will not necessarily
require disk space.
If you use the logical RDMS$BIND_SORT_WORKFILES, you
will need to define further SORTWORK logical names as
described in the V4.1 VAX Rdb/VMS Guide to Database
Performance and Tuning.
You should also verify that sufficient process quotas
are specified on the RUN/DETACH command line, or
defined as system PQL parameters to allow Rdb/VMS to
execute.
2.12.2 SQL Known Problems and Restrictions for V3.1
Section 2.12.2.1 through Section 2.12.2.9 describe known
problems and restrictions in SQL for V3.1.
2.12.2.1 DDL Statements Cannot Refer to Objects Before Their
Creation
CREATE SCHEMA and CREATE TABLE statements in programs must
precede (in the source file) all other data definition
language (DDL) statements that refer to the schema or
table, respectively.
2.12.2.2 SQL Schema Compilation Fails on the First Fatal Error
When compiling schemas, SQL fails on the first fatal error.
That means it is necessary to compile more than once to
find multiple fatal errors.
In V4.0 and higher, there is no way to avoid the
inconvenience of multiple compilations.
2-190 Known Problems, Restrictions, and Other Notes
2.12.2.3 COMMENT ON Statement Cannot Be Used in CREATE SCHEMA
Statement
The COMMENT ON statement cannot be used in a CREATE SCHEMA
statement.
2.12.2.4 Dynamic Cursors Cannot Access Views Created with GROUP
BY or UNION Clause
Views that contain a GROUP BY or UNION clause in their
definition cannot be accessed using dynamic cursors. Note
that in interactive SQL, these views may be accessed with
the SELECT statement; in precompiled SQL or SQL module
language, these views may be accessed with singleton SELECT
statements and with nondynamic cursors. The problem shows
up only with dynamic cursors. If a user attempts to access
one of these views with a dynamic cursor, the following
error will be returned when the cursor is opened:
"RDMS-F-VIEWNORET, view cannot be retrieved by database key".
The workaround for this problem is to use nondynamic
cursors to access the view. If a dynamic cursor must be
used, the statement should access the base tables that
make up the view (with the GROUP BY and UNION clauses, as
appropriate) and not the view itself.
2.12.2.5 You Cannot Use INCLUDE Statement in Variable Declaration
The SQL$PRE precompiler will not process an INCLUDE
statement in the middle of a variable declaration. The
following segment from a COBOL program illustrates an
INCLUDE statement that does not get processed:
01 dept_rec pic x(24).
01 commarea.
EXEC SQL INCLUDE "A.DAT" END-EXEC.
2.12.2.6 SQL Ada Precompiler Does Not Support the Correct
Overloading of Subprograms
The SQL Ada precompiler does not support overloading
(overlaying) of subprograms correctly. It treats all of
the overloaded programs as a single name space.
Known Problems, Restrictions, and Other Notes 2-191
There are three workarounds to this problem in the current
version of the SQL interface to Rdb/VMS:
o The best workaround is to use the module language
interface instead of the precompiler. The module
language is an interface for defining procedures to
execute SQL statements. You then import these procedures
into Ada and use them as you would use any other
external subprogram. Because SQL no longer processes
the Ada program, using the module language removes
all of the compile-time restrictions imposed by the
precompiler on what Ada features you can use. The run-
time performance and features of the module language
interface are identical to the run-time performance and
features of the precompiled interface.
o The second workaround is to use the separate compile-
time feature of Ada for all of your loaded subprograms.
Using this approach, all of your overloaded subprograms
would be precompiled separately so the Ada precompiler
would handle the name spaces correctly. The disadvantage
of this approach is that the SQL statements in the
subprogram would not be able to refer to types,
variables, and so forth, that were declared in the main
program unit because SQL would not know anything about
them.
o The third workaround is to make sure that all of
the names used in SQL statements in the overloaded
procedures are unique in all of the overloaded
procedures. If you want to limit yourself to using
ANSI standard features, the names of all host language
variables used in SQL statements must be unique in the
entire file.
2.12.2.7 SQL Precompiler Does Not Evaluate Expressions in
Variable Declarations or Understand Literals
The SQL$PRE precompiler for the C language gives the
following error message when an SQL statement refers to
a host language variable declared as a character array
whose declaration includes anything other than a straight
numeric value:
%SQL-F-BAD_ARRAY, Host variable address contains an array syntax error
in its declaration.
2-192 Known Problems, Restrictions, and Other Notes
For example, this error occurs when the declaration
contains a named constant or an expression:
#define NAME_LEN (20)
#define ADDRESS_LEN (31)
char name [NAME_LEN + 1] /* This cannot be used */
char address [ADDRESS_LEN] /* This cannot be used */
Note that this has always been a restriction.
There is a workaround that requires two actions:
1. Remove the expressions from the declarations and
update the #define line accordingly; also remove the
parentheses from the #define line:
#define NAME_LEN 21
#define ADDRESS_LEN 31
char name [NAME_LEN]
char address [ADDRESS_LEN]
2. Run the C code through the C preprocessor before
invoking the SQL precompiler. This will force all named
constants to be translated before the precompiler tries
to use them:
CC/PREPROCESS=filename.SCP filename.SC
SQL$PRE/CC filename.SCP
2.12.2.8 SQL Ada Precompiler Does Not Support Named Literals or
Ranges
The SQL Ada precompiler does not support the use of named
literals or ranges.
It is possible to avoid this restriction by using the
module language interface instead of the precompiled
interface.
2.12.2.9 SQL Module Language Processor Fails on the First Fatal
Error
The SQL module processor fails on the first fatal error.
That means it is necessary to perform multiple compilations
to find multiple fatal errors.
In Rdb/VMS V4.0 and higher, there is no way to avoid the
inconvenience of multiple compilations.
Known Problems, Restrictions, and Other Notes 2-193
2.12.3 RDO and RDBPRE Known Problems and Restrictions for V3.1
Section 2.12.3.1 through Section 1.5.4 describe known
problems and restrictions in RDO and RDBPRE for V3.1. These
problems continue in Rdb/VMS V4.0, V4.1, and V4.2.
2.12.3.1 Database Handle Scope
Both the RDML and RDO reference manuals state that the
default database handle scope is GLOBAL. This is true
except for the following cases:
o RDBPRE
- The default database handle is declared GLOBAL by
default:
INVOKE DATABASE FILENAME 'PERSONNEL'
- A named database handle is declared as LOCAL by
default:
INVOKE DATABASE PERS = FILENAME 'PERSONNEL'
o RDML
- Both the default and named database handle are
declared as GLOBAL by default.
2.12.3.2 Problem of Different Optimizations of the Same Query
from Different Environments
In some cases, the same query is optimized differently
from different environments (RDO and RDBPRE/COBOL, for
example). This problem is due to the fact that queries are
handled differently by the interfaces, in this case, RDO
and RDBPRE, and different BLRs are generated.
RDBPRE is a batch environment as opposed to the interactive
RDO environment. Therefore, in some cases, RDBPRE can
consolidate two or more statements into one and produce
a more compact BLR than RDO. For example, for the following
query, RDBPRE generates a single BLR identifying three
output fields:
2-194 Known Problems, Restrictions, and Other Notes
START_STREAM S USING R IN REL WITH R.FLD1 < 123
FETCH S
GET
HOST_VAR1 = R.FLD1;
HOST_VAR2 = R.FLD2;
HOST_VAR3 = R.FLD3
END_GET
An equivalent RDO query produces two BLRs, one for the
START_STREAM statement and one for the FETCH and PRINT
statements:
START_STREAM S USING R IN REL WITH R.FLD1 < 123
FETCH S
PRINT R.FLD1, R.FLD2, R.FLD3
2.12.3.3 Restrictions on Using Missing Value Fields in Nested
Queries
Within a single context, such as the context of a single
request, if an arithmetic expression contains the MISSING
operator, the resulting expression will evaluate to
MISSING. In the following example, A.FIELD_1 contains
missing (unknown) values, and the query correctly
interprets the values in A.FIELD_1 as missing (unknown),
causing the expression A.FIELD_3 = VARIABLE + A.FIELD_1 to
evaluate to MISSING:
RDO> FOR A IN RELATION_A
cont> MODIFY A USING
cont> A.FIELD_3 = VARIABLE + A.FIELD_1
cont> END_MODIFY
cont> END_FOR
However, in nested queries that use multiple database
requests, such as the following example, if B.FIELD_2
contains missing (unknown) values, the expression A.FIELD_
3 = VARIABLE + B.FIELD_2 returns different results. The
second query (which begins with FOR A) retrieves a value,
in this case the value defined as the field's MISSING_
VALUE, from B.FIELD_2 for its RSE. However, because of RDO
language limitations, the second query cannot use the fact
that the field B.FIELD_2 has an unknown value and instead
uses the missing value defined for the field with the
DEFINE FIELD or CHANGE FIELD statement. Using this value
for B.FIELD_2 instead of treating the value as unknown
Known Problems, Restrictions, and Other Notes 2-195
means that the A.FIELD_3 = VARIABLE + B.FIELD_2 expression
does not evaluate to MISSING.
RDO> FOR B IN RELATION_B
cont> FOR A IN RELATION_A WITH A.FIELD_1 = B.FIELD_1
cont> MODIFY A USING
cont> A.FIELD_3 = VARIABLE + B.FIELD_2
cont> END_MODIFY
cont> END_FOR
cont> END_FOR
The workaround is to use the SQL interface to Rdb/VMS.
You can use the SQL indicator variables to detect the
NULL attribute of the column (field) and therefore set
the appropriate value for the column.
2.12.4 RDML Known Problems and Restrictions for V3.1
Section 2.12.4.1 through Section 2.12.4.9 contain RDML
known problems and restrictions for V3.1. These problems
remain in Rdb/VMS V4.0, V4.1 and V4.2.
2.12.4.1 Variables Cannot Be Database Handles
The example program shown here illustrates a problem
with RDML. It is written in VAX C, and although the
precompilation is clean, the C compiler gives errors at the
READY statement. This problem only occurs when the READY
statement contains a database handle that is incorrectly
specified as a variable rather than specified in a DATABASE
statement.
This program works if a database handle specified in one
of the database statements is used in the READY statement,
whether the READY statement is in a function or a main
module. For example:
2-196 Known Problems, Restrictions, and Other Notes
#include stdio
DATABASE first_db = FILENAME 'the_first';
DATABASE second_db = FILENAME 'the_second';
main()
{
one_ready(first_db);
one_ready(second_db);
printf("%d\n",first_db);
printf("%d\n",second_db);
START_TRANSACTION READ_WRITE;
COMMIT;
}
one_ready(the_handle)
unsigned long the_handle;
{
READY the_handle ON ERROR printf("an error\n"); END_ERROR;
return(the_handle);
}
The READY statement, as documented in the VAX Rdb/VMS RDML
Reference Manual (Rdb/VMS V3.0 and V3.1), states that the
database handle (or multiple database handles) used in the
READY statement must be specified in a DATABASE statement.
Digital does not support user-specified database handles
in RDML; database handles are automatically declared
and used in RDML as a result of their specification in a
DATABASE statement (which is really a declaration). This
program attempts to use a database handle that is declared
explicitly (as opposed to being specified in a DATABASE
statement), and RDML therefore does not recognize it as
a database handle. Because a READY statement by itself is
valid, RDML simply recognizes that the READY statement
syntax has terminated at that point, and so it fails
to detect the ON ERROR clause later in the same line.
(It assumes that the rest of the line was host language
syntax.)
To enable RDML to recognize your database handle, associate
a unique number with each database handle, and use it to
identify which database handle to use. The example shown
here is a possible approach:
Known Problems, Restrictions, and Other Notes 2-197
#include <stdio.h>
DATABASE first_db = FILENAME 'PERSONNEL';
DATABASE second_db = FILENAME 'PERSONNEL';
main()
{
one_ready(1);
one_ready(2);
printf("%d\n", first_db);
printf("%d\n", second_db);
START_TRANSACTION READ_WRITE;
COMMIT;
}
one_ready(int which_handle)
{
switch (which_handle)
{
case 1:
READY first_db ON ERROR printf("an error\n"); END_ERROR;
break;
case 2:
READY second_db ON ERROR printf("an error\n"); END_ERROR;
break;
}
}
2.12.4.2 RDML Run-Time Object Library No Longer Requires You
to Link with VAXCRTL or VAXCRTLG Object Libraries or
Shareable Images
The RDMLRTL.OLB no longer requires you to link against
either the VAXCRTL or VAXCRTLG object libraries or
shareable images. However, if you are programming in
RDML/C, then you must still link against one of these
because VAX C requires it.
2.12.4.3 RDML/EPascal Ignores /LINKAGE=PROGRAM_SECTION Qualifier
RDML/EPascal ignores the /LINKAGE=PROGRAM_SECTION qualifier
and issues a warning message. RDML/EPascal only supports
the /LINKAGE=GLOBAL_VARIABLE mechanism for linking multiple
modules.
2-198 Known Problems, Restrictions, and Other Notes
2.12.4.4 RDML/Pascal Does Not Understand Some Character String
Value Expressions
RDML/Pascal does not generate the correct length for a
character string value expression in the form:
FOR E IN EMPLOYEES WITH E.LAST_NAME = ('T' | host_variable)
... some statements ...
END_FOR;
This statement generates an error from VAX Pascal, such as:
00470 0 0 RDB$PORT_FIELD_0 : VARYING[0] OF CHAR;
1
%PASCAL-E-MAXLENRNG, (1) Max-length must be in range 1..65535
%PASCAL-E-ENDDIAGS, Pascal completed with 1 diagnostic
To avoid this problem, construct the value needed before
issuing the query, using a method such as the following:
host_variable1 := 'T' + host_variable2;
FOR E IN EMPLOYEES WITH E.LAST_NAME = host_variable1
... some statements ...
END_FOR;
This method is recommended for all RDML statements when
possible because it generally improves the performance of
the query.
2.12.4.5 RDML/Pascal Does Not Accept All Possible Valid Pascal
Host Language Variables
RDML/Pascal does not accept all possible valid Pascal host
language variables, and it issues the following error if
one it does not accept is encountered:
%RDML-W-HOST_VARIABLE, error detected in host variable syntax
The set of possible values is limited to the syntax
described in the VAX Rdb/VMS RDML Reference Manual, with
the restriction that the expression allowed in an array
index must be a simple name or expression. The following
illustrates an unacceptable statement:
FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = emparray[empstruct.index]
... some statements...
END_FOR;
Known Problems, Restrictions, and Other Notes 2-199
In the preceding example, empstruct.index is a reference to
a structure member. To avoid this problem, you would assign
empstruct.index to an intermediate variable and use that
variable in the FOR statement WITH clause.
2.12.4.6 RDML Does Not Allow Nested Comments
The RDML C and Pascal preprocessors do not allow nested
comments and identify such comments with an informational
message. RDML does not allow comments because they are not
allowed by the ANSI/ISO C standard or by VAX C (when you
use the /STANDARD= PORTABLE qualifier).
2.12.4.7 C Host Variables
The following restrictions affect the use of C host
variables:
o Host variables in C of the form *host_variable that
appear directly after a host variable in an RSE are
not detected correctly. For instance, *year_ptr is
interpreted incorrectly as part of the host variable
emp_id in the following example:
FOR D IN DEGREES WITH D.EMPLOYEE_ID = emp_id
*year_ptr = D.YEAR_GIVEN;
END_FOR;
The workaround for this restriction is to use braces
around the host language statements, or parentheses
around the WITH clause. For example, either of the
following RSEs will preprocess correctly:
FOR D IN DEGREES WITH D.EMPLOYEE_ID = emp_id
{
*year_ptr = D.YEAR_GIVEN;
}
END_FOR;
FOR D IN DEGREES WITH (D.EMPLOYEE_ID = emp_id)
*year_ptr = D.YEAR_GIVEN;
END_FOR;
o Although host variables with parentheses are permitted
in non-RDML statements, they cannot be used as host
variables in RDML statements. For example, the following
syntax is not permitted:
2-200 Known Problems, Restrictions, and Other Notes
FOR E IN EMPLOYEES
WITH E.LAST_NAME = (name)[offset].element
.
.
.
END_FOR;
However, the following is permitted:
FOR E IN EMPLOYEES
WITH E.LAST_NAME = name[offset].element
.
.
.
END_FOR;
2.12.4.8 C String Continuation Character
The C string continuation character (a backslash, \) in
string constants followed immediately by a new line is not
recognized by RDML. Do not use this method of continuation
with this version of RDML. RDML generates an error if it
finds a string constant that does not begin and end on the
same line within quotation marks.
For example, the following C lines cause a syntax error in
Rdb/ELN:
printf ("abcdefg\
hijklmnopqrstuvwxyz");
2.12.4.9 Path Name and the DATABASE Statement
RDML does not extract the run-time file name from the
CDD when you specify the compile-time path name option
of the DATABASE statement only. If you choose to specify
the compile-time path name, you must also supply the run-
time file name. If you do not supply the run-time file name
under these conditions, RDML will use the CDD path name as
the run-time file name. For instance, RDML will mistakenly
use 'CDD$TOP.PERSONNEL' as the run-time database file name
in the following example:
DATABASE COMPILETIME PATHNAME 'CDD$TOP.PERSONNEL';
Known Problems, Restrictions, and Other Notes 2-201
However, RDML will interpret the following DATABASE
statement correctly:
DATABASE COMPILETIME PATHNAME 'CDD$TOP.PERSONNEL'
RUNTIME FILENAME 'PERSONNEL';
2.12.5 RMU Known Problems and Restrictions for V3.1
Section 2.12.5.1 through Section 2.12.5.2 describe known
problems and restrictions in RMU for V3.1. These problems
remain for Rdb/VMS V4.0, V4.1 and V4.2.
2.12.5.1 RMU/SHOW STATISTICS Command Does Not Record All
Statistics in the Binary File
The following restrictions were not previously documented
for the RMU/SHOW STATISTICS command. When you use the
RMU/SHOW STATISTICS/OUTPUT command, the following
information is not recorded in the binary file, and
therefore cannot be replayed using the /INPUT qualifier:
o The information contained in the Stall Messages screen
This information is highly dynamic, and is not recorded
in the binary file.
o Individual storage area I/O statistics
Currently all the file I/O statistics are combined into
a single gross value for the database.
Digital recognizes that individual file statistics are
considerably more useful than a single gross value for
tuning in a multifile database. The RMU/SHOW STATISTICS
command will be enhanced in a future release of Rdb/VMS
to record I/O statistics for individual storage areas.
2.12.5.2 Dumping the .AIJ File Is Incompatible with Normal Usage
Dumping the .AIJ file from one process and writing to
the .AIJ file from another process are mutually exclusive
actions within the current Rdb/VMS architecture.
For example, if you try to modify a record in a database
for which after-image journaling is enabled while someone
else is dumping the .AIJ file with the RMU/DUMP/AFTER
command, then it is possible for your transaction to cause
a bugcheck dump when it attempts to access the .AIJ file:
2-202 Known Problems, Restrictions, and Other Notes
***** Exception at 001F5796 : AIJ$OPEN + 000002C9
%RDMS-F-FILACCERR, error opening after-image journal file DUA0:[SMITH.RDB]M
-SYSTEM-W-ACCONFLICT, file access conflict"
To prevent this error from occurring, ensure that there
are no active users updating the database before issuing an
RMU/DUMP/AFTER command, or make a copy of the .AIJ file and
dump that copy.
2.12.6 DSRI Notes and Restrictions Retained from V3.1
Section 2.12.6.1 through Section 2.12.6.2 contain known
problems and restrictions related to the DIGITAL Standard
Relational Interface (DSRI).
Digital recommends that applications avoid the use of DSRI
interfaces to avoid version compatibility problems, and
suggests the use of the SQL interface to Rdb/VMS wherever
possible.
2.12.6.1 RCI Instantiation Number Must Be Zero for Remote Access
DSRI allows multiple instances of a request to execute
against different databases. Rdb/VMS supports only a single
instance for each database attach. However, the Relational
Call Interface (RCI) does allow the specification of
INSTANTIATION for each request. In V3.1 and higher of
Rdb/VMS, this instantiation number must have the value
0 for remote access to succeed. This problem exists in
the remote access server, so local database access is not
affected.
The Rdb/VMS precompilers always generate a value of 0 for
the instantiation number, so this restriction will be
observed only by Rdb/VMS users who use the RCI directly
from application programs.
2.12.6.2 Context Variables That Are Not Unique Within a Request
Cause Invalid BLR
A program that contained non-unique context variables and
ran on a Rdb/VMS V3.0 system, generates an invalid binary
length record (BLR) error in Rdb/VMS V3.1 and higher.
Enhancements to Rdb/VMS V3.1 require that the restriction
that context variables be unique within a request must be
enforced.
Known Problems, Restrictions, and Other Notes 2-203
This restriction requires applications that generate BLR to
generate a unique context variable for each BLR$K_RELATION,
BLR$K_RELATION_ID, BLR$K_FETCH, BLR$K_ERASE, BLR$K_STORE,
BLR$K_STORE2, or BLR$K_MODIFY used in a single request.
These context variables are represented as unsigned byte
data types; therefore, a request might have as many as 256
context variables.
An INVALID BLR exception is generated under these
circumstances. The exception status will be returned from
the RDB$COMPILE_REQUEST call and the message vector will
contain the offset in the BLR string of the duplicate
context variable. For example, the message vector, when
formatted with SYS$PUTMSG, appears as:
%RDB-E-INVALID_BLR, request BLR is incorrect at offset 301
________________________ Note ________________________
This restriction does not apply to code (BLR)
generation performed by Digital language processors,
RDBPRE, RDML, SQL$PRE, and SQL$MOD, which always
generate unique context variables when compiling
requests.
______________________________________________________
2.12.7 CDD/Plus Restrictions Retained from Rdb/VMS V3.1
The following sections contain known problems and
restrictions retained from Rdb/VMS V3.1 related to CDD/Plus
V4.1. These problems remain for Rdb/VMS V4.0, V4.1, and
V4.2.
2.12.7.1 CDD/Plus COMPUTED BY Fields Are Not Currently Supported
in Rdb/VMS Relations or Views
If you define a COMPUTED BY field in CDO and use it in
a record, that record will not be usable in Rdb/VMS.
Incompatible data type errors will occur if you try to
use an RDO INTEGRATE statement when the record containing
the COMPUTED BY field will be used as an Rdb/VMS relation.
RDO COMPUTED BY fields are computed in the context of a
relation, while CDO COMPUTED BY fields are not. The two
concepts do not have a semantic mapping. This restriction
was not noted in CDD/Plus documentation. It is currently
2-204 Known Problems, Restrictions, and Other Notes
not considered a problem but rather a possible enhancement
to be considered for some future release.
It is possible to use Rdb/VMS compatible COMPUTED BY fields
in record definitions stored in the data dictionary if
they are actually defined in RDO and then entered into
the data dictionary. The COMPUTED BY field may be defined
in Rdb/VMS as part of a relation using the INVOKE PATH
option. A record with a COMPUTED BY field defined in RDO
and entered in the data dictionary can be included in other
databases.
Known Problems, Restrictions, and Other Notes 2-205
A
_________________________________________________________________
How to Order Additional Documentation
Technical Support
If you need help deciding which documentation best meets
your needs, call 800-DIGITAL (800-344-4825) and press 2 for
technical assistance.
Electronic Orders
If you wish to place an order through your account at the
Electronic Store, dial 800-234-1998, using a modem set
to 2400- or 9600-baud. You must be using a VT terminal or
terminal emulator set at 8 bits, no parity. If you need
assistance using the Electronic Store, call 800-DIGITAL
(800-344-4825) and ask for an Electronic Store specialist.
Telephone and Direct Mail Orders
___________________________________________________________
From__________Call______________Write______________________
U.S.A. DECdirect Digital Equipment
Phone: 800- Corporation
DIGITAL P.O. Box CS2008
(800-344-4825) Nashua, New Hampshire 03061
FAX: (603) 884-
5597
Puerto Rico Phone: (809) Digital Equipment
781-0505 Caribbean, Inc.
FAX: (809) 749- 3 Digital Plaza, 1st Street
8377 Suite 200
Metro Office Park
San Juan, Puerto Rico 00920
How to Order Additional Documentation A-1
___________________________________________________________
From__________Call______________Write______________________
Canada Phone: 800-267- Digital Equipment of Canada
6215 Ltd.
FAX: (613) 592- 100 Herzberg Road
1946 Kanata, Ontario, Canada K2K
2A6
Attn: DECdirect Sales
International -- Local Digital subsidiary or
approved distributor
Internal DTN: 241-3023 Software Supply Business
Orders[1] (508) 874-3023 (SSB)
(for Digital Equipment
software Corporation
documentation) 1 Digital Drive
Westminster, MA 01473
Internal DTN: 234-4325 Publishing & Circulation
Orders (508) 351-4325 Services
(for FAX: (508) 351- Digital Equipment
hardware 4467 Corporation
documentation) NR02-2
444 Whitney Street
Northboro, MA 01532
[1]Call_to_request_an_Internal_Software_Order_Form_(EN-____
01740-07)._________________________________________________
A-2 How to Order Additional Documentation