See the following topics for more information about new features
for DEC DATATRIEVE Version 7.1.
1 – DEC DATATRIEVE Textfile-based Dictionary
DEC DATATRIEVE Version 7.1 supports a text-file based dictionary in
addition to Oracle CDD/Repository. This new functionality has
been added for customers who have to buy Oracle CDD/Repository
just as a prerequisite for DEC DATATRIEVE. From now on they will
be able to avoid this dependency because a simple alternative
storage for DEC DATATRIEVE objects is available.
DEC DATATRIEVE Version 7.1 is able to work without Oracle
CDD/Repository while keeping its current functionalities for
the following commands and statements:
o DEFINE
- DOMAIN
- DATABASE
- RECORD (clauses FROM FIELD and FROM GROUP are also
supported)
- PROCEDURE
- TABLE
- PORT
- PLOT
o READY domains and databases
o Execute (:) procedures
o Use of tables in VIA expressions
o Use of records in WITH_FORM statements
o Use of plots with PLOT statements
o DELETE
o EDIT with all clauses related to dictionary objects
o EXTRACT with all clauses related to dictionary objects
o PURGE
o REDEFINE
o SET
- DICTIONARY
- PLOTS
o SHOW
- ALL, DATABASES, DICTIONARIES, DICTIONARY, DOMAINS, PLOTS,
PROCEDURES, RECORDS, TABLES
- path-name
- PRIVILEGES for path-name
o Directory Services for DECwindows Motif interface and Windows
Client Dictionary Browsers
o ACL control
- DEFINEP
- DELETEP
- SHOWP
Some customers are interested in associating ACLs to
definitions that define the access control for the defined
objects (data) rather than the definition (metadata).
DEC DATATRIEVE Version 7.1 does not support:
o WITH RELATIONSHIPS clauses in DEFINE.
This is a specific clause for CDO objects. No strict
dependency relationship is supported for text file
definitions. This is the same as for DMU objects.
o CDD$DATABASE objects.
They are specific CDO objects.
o READY of CODASYL DBMS databases and domains based on them.
CODASYL DBMS support still requires the use of Oracle
CDD/Repository. Even if Oracle CODASYL DBMS Version 6.1 no
longer requires Oracle CDD/Repository, DEC DATATRIEVE depends
on Oracle CDD/Repository to get DBMS matadata because no
direct access to DBMS provides the same info.
o CDO command.
This is explicitly targetted to a linked CDO image
o General support of fields is not offered (no DEFINE FIELD),
since it should be restricted to CDO repositories because
fields as individual elements are not supported by DMU
dictionaries. However the capability of defining global fields
(fields that are stored by themselves) is interesting. Oracle
CDD/Repository users currently can define them via the CDO
utility and access them via the FROM FIELD clause.
1.1 – Using Oracle CDD/Repository
When using DEC DATATRIEVE with Oracle CDD/Repository the
following happens:
o DEC DATATRIEVE stores/retrieves all its specific objects
(domains, databases, procedures, tables and plots) from a
Oracle CDD/Repository dictionary.
o DEC DATATRIEVE stores/retrieves record definitions (data
aggregates definitions) from a Oracle CDD/Repository
dictionary. Record definitions can be created by other
products (e.g. CDO utility) and shared by other products.
o DEC DATATRIEVE gets Oracle CODASYL DBMS metadata from a Oracle
CDD/Repository dictionary.
1.2 – Using the Textfile-based Dictionary
The new textfile-based dictionary stores objects created by DEC
DATATRIEVE (such as: domains, databases, tables, procedures, plots
and objects potentially shareable as records) in textual format
with the corresponding DEC DATATRIEVE code used by the user. The
stored format reproduces exactly the text used by the user as far
as indentation and comments are concerned; actual code is however
converted to uppercase. This corresponds to the current mechanism
used by DEC DATATRIEVE to store the text of an object into Oracle
CDD/Repository.
1. Drawbacks:
o Records created by DEC DATATRIEVE cannot be understood by
other products via a common protocol (protocol is the DEC
DATATRIEVE language syntax here).
2. Advantages:
o Objects are portable (they depend only on the DEC
DATATRIEVE syntax.
o Objects can be directly read by users and by applications.
o Objects can be created by other products.
o SHOW operations are faster.
Every object is stored in an individual disk file. The file name
is built with a suffix determined by the object type (e.g. _DOM
for a domain) and the object name. File type is .DTR. Example:
"define domain yachts using yacht on t.dat" creates the file
YACHTS_DOM.DTR whose content is DOMAIN YACHT USING YACHT ON
T.DAT. The file is stored in a disk directory that corresponds
to the dictionary pathname.
Note that you can also define dictionaries, these will have no
suffix and file type is .DIR.
Note that from DEC DATATRIEVE you will not see any difference,
the disk file YACHTS_DOM.DTR will always be shown as domain
YACHTS.
Objects pathnames are supported in DMU or CDO format and matched
to file specifications.
1. Object name:
The DEC DATATRIEVE object name corresponds to a file name
according to the following rules: <obj-name> <====> <obj-
name><type_suffix><file_type>
Suffixes are: _DOM for domains, _REC for records, _DBS for
databases, _PRC for procedures, _TAB for tables, _PLT for
plots, _FLD for fields. Example: DEFINE RECORD YACHT...
creates the file YACHT_REC.DTR. DEFINE DOMAIN YACHTS...
creates the file YACHTS_DOM.DTR.
Two objects with the same name and different types cannot
be stored in the same directory: even if they have different
file name, they cannot be distinguished by DEC DATATRIEVE when
commands as SHOW, EDIT, DELETE are used. These commands don't
refer to a specific type.
File type is DTR that is already registered as file extension
for DEC DATATRIEVE code: the text contents of these objects is
actually DEC DATATRIEVE code.
2. Directory path:
The directory paths in Oracle CDD/Repository format will be
converted to disk directory paths, according to documented
rules. For example:
o If CDD$TOP is involved (you are using the DMU side of the
Oracle CDD/Repository dictionary), you must define the
logical name DTR$TOP to point to a directory.
o A CDO anchor is already a disk directory.
o The name series that follows CDD$TOP or an anchor until
the last name excluded, is considered as a list of
subdirectories. Example: CDD$TOP.DTR$LIB.DEMO.YACHTS ==>
if CDD$TOP points to OUR_DISK:[DICT] disk directory is OUR_
DISK:[DICT.DTR$LIB.DEMO]
1.3 – Installing DEC DATATRIEVE with/without Oracle CDD/Repository
If Oracle CDD/Repository is available at DEC DATATRIEVE
installation time, the installer can select whether the Oracle
CDD/Repository shareable image has to be linked to DEC DATATRIEVE
or not. If Oracle CDD/Repository is linked to DEC DATATRIEVE,
its use can dynamically be disabled and enabled at run time. If
Oracle CDD/Repository is not linked to DEC DATATRIEVE or its use
is disabled and cannot be enabled at run time; the alternative
dictionary is enabled.
When DEC DATATRIEVE is not linked with Oracle CDD/Repository, or
when you start DEC DATATRIEVE having defined the DTR$ENVIRONMENT
logical name to be without Oracle CDD/Repository (see Enabling
and Disabling Oracle CDD/Repository), the SHOW SET_UP command
will display:
NO CDD/Repository Available
1.4 – Enabling and Disabling Oracle CDD/Repository
If Oracle CDD/Repository is linked to DEC DATATRIEVE, its use
can dynamically be enabled and disabled at run time in one of the
following ways:
o Using the DEC DATATRIEVE SET CDD and SET NO CDD commands.
SET NO CDD means that DEC DATATRIEVE must use the
textfile-based dictionary.
SET CDD means that DEC DATATRIEVE must use Oracle
CDD/Repository as the repository system.
The SHOW SET_UP command always displays the status. If you
enter SET CDD, SHOW SET_UP displays:
CDD/Repository enabled.
If you enter SET NO CDD, SHOW SET_UP displays:
CDD/Repository disabled.
o Using the DTR$ENVIRONMENT logical name
$ DEFINE DTR$ENVIRONMENT "/NOCDD"
Note that when you define the DTR$ENVIRONMENT logical name to
be NOCDD, you cannot use SET CDD, SET NO CDD commands from DEC
DATATRIEVE.
1.5 – Compatibility Between CDD/NOCDD Versions
DEC DATATRIEVE provides the EXTRACT command that allows
definitions (all of them, or restricted by type, or individual
ones) to be copied to files. An extracted definition contains the
DEC DATATRIEVE REDEFINE command that allows to redefine the same
object in another environment.
The EXTRACT command is supported by all DEC DATATRIEVE versions
and allows to get DEC DATATRIEVE command files that are able to
redefine the same objects in the same or another system.
DEC DATATRIEVE provides a new utility (DTREXTRE) to
allow a user to extract all the DATATRIEVE objects stored in
a directory tree starting from a base directory.
DTREXTRE is a C program linked with the DATATRIEVE shareable
image, that calls recursively the DATATRIEVE interpreter to
EXTRACT all the objects in the current directory and then
moves down to the subdirectories.
DEFINE DICTIONARY and SET DICTIONARY commands are inserted at
the beginning of each set of definitions belonging to the same
directory to allow to recreate the objects in proper directories.
DTREXTRE is activated by a DCL Run command; and prompts for
the required information.
$ RUN SYS$SYSTEM:DTREXTRE
... initializing DATATRIEVE ...
Enter output file name: MY_DEF.COM
... opening output file ...
2 – UNSIGNED Field Attribute
DEC DATATRIEVE Version 7.1 supports a new field attribute:
UNSIGNED. The UNSIGNED field attribute is valid for fields
of format: BYTE, LONG, WORD, and QUADWORD. The UNSIGNED field
attribute allows you to extend the range of the specified field
values because it considers only the positive values.
In the following example F1 is declared as a LONG therefore
its range is from -2**31 to +2**31 - 1. F2 is decleare as LONG
UNSIGNED, having a double range of positive values.
DTR> DECLARE F1 LONG .
DTR> F1 = 3000000000
Variable "F1" may contain an incorrect value due to error during assignment.
Truncation during assignment.
DTR> DECLARE F2 LONG UNSIGNED .
DTR> F2 = 3000000000
DTR>
DEC DATATRIEVE V7.1 manages
unsigned quadword fields and variables as signed quadwords.
DTR> DECLARE RECORD R
DFN> 01 R.
DFN> 05 LL2.
DFN> 10 L0 LONG.
DFN> 10 L1 LONG.
DFN> 05 ULL2 REDEFINES LL2.
DFN> 10 L2 UNSIGNED LONG.
DFN> 10 L3 UNSIGNED LONG.
DFN> 05 Q0 REDEFINES LL2 UNSIGNED QUAD .
DFN> 05 Q1 REDEFINES LL2 QUAD . ;
[Record is 8 bytes long.]
DTR>
DTR> DECLARE DOMAIN D USING R ON UNSIGNED_Q.DAT
DTR> DEFINE FILE FOR D ;
DTR> READY D WRITE ;
DTR> STORE D USING BEGIN L0 = -1 ; L1 = -1 ; END ;
DTR> PRINT L0, L1, L2, L3 OF D ;
3 – Client/Server TPC/IP Transport
The DEC DATATRIEVE Client/Server connection is provided via TCP
/IP in addition to DECnet. If you are using the TCP/IP network
transport to communicate between a DEC DATATRIEVE Server on
OpenVMS and DEC DATATRIEVE Client for Windows, you can use
PATHWORKS, Windows NT, or Windows 95, since they all contain
the TCP/IP protocol.
For more information on how to set up the TCP/IP network
transport both on Client and Server, see the DEC DATATRIEVE
Client for Windows documentation.
4 – Temporary Definition of DEC DATATRIEVE Objects
DEC DATATRIEVE objects can be defined as temporary so that no
permanent storage is required. The objects' time scope is limited
to the DEC DATATRIEVE session.
This is a useful feature to create DEC DATATRIEVE applications
that:
o Don't depend on any dictionary system (objects are temporary
stored in main memory).
o Don't conflict with existing objects and directories.
o Don't need to delete objects and clean up directories.
Temporary objects are defined using the DECLARE command. You can
declare the following objects:
o Domains
o Records
o Procedures
o Tables
o Databases
Temporary objects can be identified by entering a SHOW command;
those objects preceeded by a # sign are temporary. See the
following example:
DTR> DECLARE DOMAIN TEMP_YACHTS USING YACHT ON YACHT.DAT;
DTR> SHOW DOMAINS
Domains:
* ACCOUNT_BALANCES;1 * ANNUAL_REPORT;1
# TEMP_YACHTS;1 * YACHTS;1
DTR>