1 New_Features See the following topics for more information about new features for DEC DATATRIEVE Version 7.1. 2 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. 3 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. 3 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: <====> 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] 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 3 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. 3 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 ; 2 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. 2 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>