unisys Distributed Processing Middleware Enterprise Database SQL Query Processor for ClearPath MCP Installation and Operations Guide imagine it. done.

Transcription

1 unisys imagine it. done. Distributed Processing Middleware Enterprise Database SQL Query Processor for ClearPath MCP Installation and Operations Guide ClearPath MCP 13.0 April

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders.

3 Contents Section 1. Overview Documentation Updates What s New? What Is SQL Query Processor? Section 2. Installing SQL Query Processor Hardware and Software Requirements Hardware Requirements MCP Environment Software Requirements Windows Environment Software Requirements Installing the SQL Query Processor Software in the MCP Environment Manually Assigning the SQL Query Processor Library Function Names to the Server Library Code File Titles Creating the SQL Query Processor Configuration File (DMSQL/CONFIG) Changing the Name and Location of the SQL Query Processor Configuration File Creating the Server Configuration File (DMSQL/SERVER/CONFIG) Configuring the TCP/IP Distributed Systems Services (DSS) Optional Installation Tasks Installing the SQL Query Processor Utilities in the Windows Environment Migrating from an Earlier Release Updating an SQL Database Definition Updating an Enterprise Database Server Database Removing the SQL Query Processor Software Reinstalling the SQL Query Processor Software Troubleshooting Updating Enterprise Database Server Databases with SQL Queries Updating Enterprise Database Server Data Sets with SQL Queries Section 3. Using the Query Design Center Starting the Query Design Center Understanding the Query Design Center Interface iii

4 Contents Setting the Look and Feel of the Interface Determining Connection Status Catalog Window Opening Tables Viewing Table Results Viewing Column Results Analyze Query Window Analyze Query Window Commands Preparing and Executing a Query Saving a Query Saving Query Results Opening a Query Enabling Manual Commit Mode Setting Transaction Isolation Levels Creating a Savepoint Rolling Back to a Savepoint Setting the Row Limit Generating a QGraph Generating a QDump Design Query Window Designing a Query Customizing the Query Design Center Section 4. Using the Relational Design Center Utility Starting the Relational Design Center Understanding the Relational Design Center Interface Using the Menu Bar Understanding Relational Mappings for SQL Default SQL Names Global Data Defaults Disjoint Data Set Defaults Embedded Data Set and Occurring Item Defaults Initial Values Set and Access Defaults as Indexes Set and Subset Defaults as Views Data Item Defaults Link Defaults Group Defaults Physical Option Defaults Restart Data Set Defaults SQL Referential Integrity Constraints Date Construct Security View Construct Grant Construct Working with Servers Adding a Server Removing a Server Importing a Relational Schema Creating an SQL Database iv

5 Contents Working with Databases Opening a Database Removing a Database Refreshing a Database Restoring a Database Getting the SQL Schema Saving the Schema Loading a Schema Applying Schema Modifications Modifying an SQL Database Working with Database Schemas Modifying Data Sets Modifying Occurring Items Modifying Variable-Format Items Modifying Indexes (Sets and Subsets) Modifying Data Items (Columns and Primary Keys) Assigning Access Rights to Database Structures Modifying Access Rights for Database Structures Creating SQL Dates Modifying SQL Dates Creating Integrity Constraints Modifying Integrity Constraints Creating SQL Views Modifying SQL Views Section 5. SQL Query Processor Server Administration Configuring SQL Query Processor Server Resources Preparing a Database to Be a Resource Controlling the SQL Query Processor Server Starting and Stopping the SQL Query Processor Server Obtaining Help Information Automating SQL Query Processor Server Initialization Creating the *DMSQL/SERVER/CONFIG File Setting the SQL Query Processor Server Timeout Intervals Obtaining SQL Query Processor Server Status Viewing Server Log Information in the MCP Environment Identifying the Server Log Understanding Server Log Contents Viewing Trace Information on the Server Diagnostic Trace Identifying the Trace File Enabling the Trace Facility Closing Trace Files Automatically Retrieving Dump Files Identifying the Dump File Displaying the Dump File v

6 Contents Section 6. SQL Query Processor Configuration Control Facility Using the SQL Query Processor Configuration Control Facility Understanding the SQL Query Processor Configuration File Creating the SQL Query Processor Configuration File Release Specification User Specification Program Specification Default Release Specification Resource Specification Using the CCS Clause Using the Limit Clause Setting a Default Release Limit Limit Clause Enforcement Sample SQL Query Processor Configuration Files Section 7. Using the Schema Administrator Ensuring Description File and Control File Accessibility Reviewing the Results File of a SQLVIEW Command Generation Viewing the Schema Using the Schema Administrator Input File Manually Enabling SQL Access to an Enterprise Database Server Database Generating the SQL Descriptions Listing the Description Section 8. Using the DMQUERY Utility What Is the DMQUERY Utility? Using DMQUERY Utility Commands BYE CANCEL CLOSE COMMIT WORK DEFINE DIAGNOSE DO OPEN PARSE QD REPEAT ROLLBACK WORK SAVEPOINT SET SHOW Running the DMQUERY Utility Interactively Through CANDE Running the DMQUERY Utility in Batch Mode DMQUERY Utility Files vi

7 Contents Appendix A. Setting Up Kerberos Authentication in the Windows Environment in the Windows Environment Appendix B. Troubleshooting Index vii

8 Contents viii

9 Section 1 Overview Purpose Audience This guide explains how to install and administer the SQL Query Processor for ClearPath MCP, including the Windows-based utilities Query Design Center and Relational Design Center. This guide is intended for the experienced database administrator (DBA) who understands the Unisys Enterprise Database Server for ClearPath MCP, Windows operating systems, and the SQL specification. Terminology Conventions In this guide, the term ClearPath MCP servers refers to ClearPath LX and CS servers, and FS and Libra Series servers. For simplicity, the name of the SQL Query Processor for ClearPath MCP product is shortened to SQL Query Processor and is referred to as such throughout this guide. Documentation Updates This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE) To obtain a copy of the PLE, contact your Unisys representative or access the current PLE from the Unisys Product Support Web site: Note: If you are not logged into the Product Support site, you will be asked to do so

10 What s New? What s New? The following table identifies new and revised information for this release. New or Revised Information The database types with which you can work in the Relational Design Center is updated. The procedure for opening a database in the Relational Design Center is updated. The effect of using the refresh database operation in the Relational Design Center is updated. The procedure for restoring a database in the Relational Design Center is updated. The procedure for assigning access rights to database structures in the Relational Design Center is updated. The procedure for modifying access rights to database structures in the Relational Design Center is updated. The procedure for creating SQL views in the Relational Design Center is updated. The procedure for modifying SQL views in the Relational Design Center is updated. Location in Guide Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center Section 4 Using the Relational Design Center

11 What Is SQL Query Processor? What Is SQL Query Processor? The SQL Query Processor is a Structured Query Language (SQL) parser, optimizer, and query execution engine. The SQL Query Processor accepts and executes SQL commands according to a chosen plan and interacts with the Enterprise Database Server storage engine to return the expected results. The optimizer chooses the fastest execution plan. In the optimization phase, the SQL Query Processor chooses Any indexes to use The order in which joins are executed The order in which constraints (such as WHERE clauses) are applied The algorithms that lead to the best performance The query execution engine executes the query plan chosen during query optimization. The execution engine also determines the algorithms available to the query optimizer. For example, SQL Query Processor implements an indexed-loops join algorithm. The SQL Query Processor enables you to Access business-critical data stored in the highly robust and scalable Enterprise Database Server using standard SQL commands from JDBC, COBOL, or ALGOL applications. Create SQL databases that can be queried using the SQL data manipulation language (DML) Build, deploy, and manage applications on your ClearPath MCP server that are secure, scalable, and reliable. The SQL Query Processor is compliant with the SQL-92, entry level with extensions, data manipulation language (DML) as defined by the American National Standards Institute (ANSI) document X , Database Language SQL. The SQL Query Processor provides an ALGOL and a COBOL call-level application program interface (API) that conforms to a subset of the SQL-99 call-level interface (CLI). Administration tools are provided to Create a relational view of an existing Enterprise Database Server database. Create an SQL database based on an SQL data definition language (DDL)

12 What Is SQL Query Processor? Benefits of Using the SQL Query Processor The SQL Query Processor provides the following benefits: Reduced network traffic The SQL Query Processor runs entirely on the ClearPath MCP server. This feature eliminates any network traffic that would result from switching between the ClearPath MCP server and a Windows or other server. Scalability The SQL Query Processor is scalable and supports multiple user sessions at the same time. Simplified enterprise development Using the COBOL or ALGOL API or the JDBC interface, you can easily develop applications to interface to the Enterprise Database Server. Comprehensive software localization International customers are able to interact with the SQL Query Processor and its tools on all levels, in their own language, and using their own cultural conventions. Localization entails translation of all dialog boxes, on-line help, error messages, and other user interface text. SQL Query Processor supports various character sets and collation based on the Unisys CCSVERSION defined for the Enterprise Database Server database. Using the SQL Query Processor administration tools, you can specify the coded character set (CCS) to be used when connecting to the database and when translating database data and identifiers to and from Unicode. Components and Capabilities The SQL Query Processor provides the following components and capabilities: Query Design Center The Query Design Center is an interactive query tool that developers and system administrators can use to issue queries against the Enterprise Database Server. This tool makes it easy to develop and design queries against Enterprise Database Server databases and test them outside of user applications. Relational Design Center The Relational Design Center is an interactive schema administration tool that enables SQL access to Enterprise Database Server databases. Database administrators can import, define, and save schema modifications. Schema administration functions include Generating an SQL schema for Enterprise Database Server databases Defining and modifying schema attributes to be used for mapping an Enterprise Database Server description file Diagnosing errors including error reporting, event logging, and tracing

13 What Is SQL Query Processor? Call-Level Interface (CLI) The CLI is a single, open SQL API that enables a client application on a ClearPath MCP system to access Enterprise Database Server databases. CLI interfaces include JDBC, COBOL, and ALGOL. Module language The module language supports the SQL module language interfaces. The module language enables you to partition and centralize code and develop routines that can be called by other applications

14 What Is SQL Query Processor?

15 Section 2 Installing SQL Query Processor This section provides information on the following topics: Hardware and software requirements Installing SQL Query Processor software in the MCP environment Installing SQL Query Processor utilities in the Windows environment Migrating from an earlier release Removing the SQL Query Processor software Reinstalling the SQL Query Processor software Troubleshooting Requirements for updating Enterprise Database Server databases with SQL queries Requirements for updating Enterprise Database Server data sets with SQL queries

16 Installing SQL Query Processor Hardware and Software Requirements As you consider the hardware and software requirements, note the following factors: Processor size and the amount of available memory affect performance. The available memory and disk space must be sufficient for the demands of your operating environment, the SQL Query Processor software, and the client applications using the services of the SQL Query Processor. Hardware Requirements Platform MCP environment Hardware Requirements One of the following MCP systems: ClearPath LX server ClearPath NX server ClearPath CS server FS Series servers Libra Series servers Windows environment Intel Pentium processor, 2.0 GHz or greater 256 MB of RAM or greater 4 MB of hard disk space or greater MCP Environment Software Requirements Software Requirements MCP Enterprise Database Server TCP/IP DALICENSESUPPORT ClearPath MCP release 11.0 or later Refer to the compatibility matrix on the Unisys Product Support Web site: pla=as&nav=as Enterprise Database Server release 10.1 or later Refer to the compatibility matrix on the Unisys Product Support Web site: pla=as&nav=as Network Services release 10.0 or later The same version as the SQL Query Processor software or later

17 Installing SQL Query Processor Windows Environment Software Requirements Software Windows operating system Requirements One of the following operating systems: Windows Server 2003 Windows 2000 or XP Professional SQL Query Processor Relational Design Center Query Design Center Other software Java Runtime Environment (JRE) 1.4 or greater Installing the SQL Query Processor Software in the MCP Environment Notes: On new ClearPath MCP servers, the MCP host software, including the SQL Query Processor product, comes preloaded. Unless you are installing an Interim Correction (IC) update to the SQL Query Processor, you do not need to perform an installation in the MCP environment. For this installation process, the MCP environment is considered to be a ClearPath MCP server, unless otherwise stated. For the MCP environment, the SQL Query Processor software, including the utilities, is packaged on CD-ROM media. Run the Simple Installation (SI) program or use the Installation Center to install the SQL Query Processor software package. The following files are installed on the MCP environment: SYSTEM/SQL/ADMIN SYSTEM/SQL/ADMIN/DIAGNOSTICS SYSTEM/SQL/ETINQ SYSTEM/SQL/ETINQ/DIAGNOSTICS SYSTEM/SQL/SCODE SYSTEM/SQL/SCODE/DIAGNOSTICS SYSTEM/SQL/CONFIG SYSTEM/SQL/CONFIG/DIAGNOSTICS SYSTEM/SQL/DRIVER SYSTEM/SQL/DRIVER/DIAGNOSTICS SYSTEM/SQL/PARSER SYSTEM/SQL/PARSER/DIAGNOSTICS SYSTEM/SQL/SERVER SYSTEM/SQL/SERVER/DIAGNOSTICS SYSTEM/SQL/WORKER SYSTEM/SQL/WORKER/DIAGNOSTICS SYSTEM/SQL/DMQUERY

18 Installing SQL Query Processor SYSTEM/SQL/DMQUERY/DIAGNOSTICS SYSTEM/SQL/MODLANG SYSTEM/SQL/MODLANG/DIAGNOSTICS SYSTEM/SQL/SUPPORT SYSTEM/SQL/SUPPORT/DIAGNOSTICS SYSTEM/SQL/COBOLDESC SYSTEM/SQL/COBOLDESC/DIAGNOSTICS SYSTEM/SQL/INTERFACE SYSTEM/SQL/INTERFACE/DIAGNOSTICS SYSTEM/SQL/DMSIIMAPPER SYSTEM/SQL/DMSIIMAPPER/DIAGNOSTICS SYSTEM/SQL/FILESUPPORT SYSTEM/SQL/FILESUPPORT/DIAGNOSTICS SYSTEM/SQL/SCODESUPPORT SYSTEM/SQL/SCODESUPPORT/DIAGNOSTICS SYMBOL/SQL/CLI/PROPERTIES/ALGOL SYMBOL/SQL/CLI/PROPERTIES/COBOL SYSTEM/INSTALLS/DMSQLUTILITIES/"README.TXT" SYSTEM/INSTALLS/DMSQLUTILITIES/"DMSQLUTILS.MSI" EXAMPLE/SQL/CLI/ALGOL EXAMPLE/SQL/CLI/COBOL EXAMPLE/DMSQL/CONFIG DESCRIPTION/SQLDIR/DMSQL-CATALOG For information about the SI program, refer to the Simple Installation Operations Guide. For information about Installation Center, refer to the Installation Center Operations Guide. Manually Assigning the SQL Query Processor Library Function Names to the Server Library Code File Titles When you use the SI program to install the SQL Query Processor in the MCP environment, four SL assignments are automatically performed. The SQL Query Processor requires these assignments to run in the MCP environment. To perform the SL assignments manually, ensure that you have system user privileges and enter the following SL (Support Library) system commands: SL DMSQLSERVER = *SYSTEM/SQL/SERVER ON <pack name>: LINKCLASS = 1, TRUSTED SL DMSQLCONFIG = *SYSTEM/SQL/CONFIG ON <pack name> SL DMSQLSCODE = *SYSTEM/SQL/SCODE ON <pack name> SL DMSQLCLI= *SYSTEM/SQL/INTERFACE ON <pack name>: TRUSTED The <pack name> construct is the name of the pack to which you copied the code file. The : LINKCLASS = 1, TRUSTED and the TRUSTED clause are required

19 Installing SQL Query Processor Creating the SQL Query Processor Configuration File (DMSQL/CONFIG) During installation of the SQL Query Processor on the ClearPath MCP host, you use CANDE to create the SQL Query Processor configuration file called DMSQL/CONFIG under the same usercode and on the same pack as the *SYSTEM/SQL/CONFIG code file. The information in the configuration file is used by the system to determine the version of the SQL Query Processor software to which a particular user has access. Perform the following steps to create the configuration file: 1. Use the EXAMPLE/DMSQL/CONFIG file as a template. This file is included with the SQL Query Processor software. 2. Copy the file EXAMPLE/DMSQL/CONFIG as DMSQL/CONFIG under your usercode. 3. Update the following sections in the DMSQL/CONFIG file to reflect your environment: RELEASE RELEASE DIAGNOSTICS USER DEFAULT RESOURCE Refer to Section 6, SQL Query Processor Configuration Control Facility, for details on configuring these items to fit your environment. 4. Save the updated example file as *DMSQL/CONFIG ON DISK. Note: If you want to save the configuration file under another name and location, refer to Changing the Name and Location of the SQL Query Processor Configuration File later in this section. 5. From CANDE, issue the following statement to verify the accuracy of the syntax in the DMSQL/CONFIG file: RUN *SYSTEM/SQL/CONFIG ON <pack name> If the contents of the file are valid, a message similar to the following is displayed: #RUNNING 8864 > The DMSQL/CONFIG file just validated is: > *DMSQL/CONFIG ON HL511D0 10/11/ :03:05 > No errors. #ET=0.1 PT=0.0 IO=0.1 If errors are returned, refer to Section 6, SQL Query Processor Configuration Control Facility, to determine how to correct the errors

20 Installing SQL Query Processor Changing the Name and Location of the SQL Query Processor Configuration File You can change the name and disk location of the SQL Query Processor configuration file. By default, the name and location of the configuration file is DMSQL/CONFIG ON <pack name>. The variable <pack name> identifies the pack where the SQL Query Processor is installed. The default usercode and family are the same as those in the SYSTEM/SQL/CONFIG file title. That is, if the SQL Query Processor is installed under the asterisk (*) usercode on the family named PACK, the default configuration file title is *DMSQL/CONFIG ON PACK. Perform the following steps to modify the name and location of the SQL Query Processor configuration file: 1. From CANDE, enter the following statement: WFL MODIFY *SYSTEM/SQL/CONFIG ON <pack name>;file CONFIG=<new configurati on file name> ON <pack name> 2. Enter the following SL (Support Library) system command: SL DMSQLCONFIG = *SYSTEM/SQL/CONFIG ON <pack name> Creating the Server Configuration File (DMSQL/SERVER/CONFIG) During installation of the SQL Query Processor server on the ClearPath MCP host, you use CANDE to create the SQL Query Processor server configuration file called DMSQL/SERVER/CONFIG under the same usercode and on the same pack as the *SYSTEM/SQL/SERVER code file. The server configuration file specifies TCP/IP attributes and the distributed systems services (DSS) provider name. The file is optional, and if it is not installed or is not found, all attributes take on their default values as defined in the following text. The syntax for defining these attributes and the SQL Query Processor name follows: TCPIP <port number> : <timeout specification>, DSSPROVIDER <provider name>, MAXBUFFSIZE <integer> <timeout specification> <BLOCKEDTIMEOUT value> : <DIALOGCHECKINTERVAL value>

21 Installing SQL Query Processor The following table explains the elements of the syntax diagrams. Element <port number> <BLOCKEDTIMEOUT value> <DIALOGCHECKINTERVAL value> <provider name> <integer> Definition Identifies the port number of the SQL Query Processor server. The default port number is The port number must also be defined in the DSS DMSQL_TCPIP endpoint and in either the connection attributes file or the connection defaults file. Specifies the length of time, in minutes, that the connection between the workstation and the server stays open after the workstation has stopped responding to inactivity handshaking procedures. This value must be an integer. The default BLOCKEDTIMEOUT value is 10 minutes. Specifies the length of time, in minutes, that the server waits without a response from an attached system before it automatically invokes inactivity handshaking procedures. This value must be an integer. The default DIALOGCHECKINTERVAL value is 5. A value of 0 (zero) prevents inactivity handshaking procedures from being invoked. Specifies the name of the DSS provider that provides the SQL Query Processor DSS. The default DSS provider name is DMSQLPROV. Identifies the buffer size in bytes. The default buffer size is

22 Installing SQL Query Processor Configuring the TCP/IP Distributed Systems Services (DSS) The SQL Query Processor Windows-based utilities use a TCP/IP connection to the ClearPath MCP server. This connection is managed as a distributed systems service (DSS). You can manually configure the DSS connection using the following ClearPath MCP commands. However, if you use the Simple Installation (SI) program, the DSS connection is automatically configured, and it is not necessary to enter the following commands. Note: You must be a system user to run the following commands. NA REG ADD PROVIDER DMSQLPROV DSS = DMSQL, SUPPORTLIBRARY = DMSQLSERVER, TASK TYPE = NONMONITOREDSUPPORTLIBRARY, INTERFACE = MESSAGE; NA REG ADD DSS DMSQL ENDPOINT = DMSQL_TCPIP, CLASS = OTHER, INITIALIZE = TRUE, RECOVER = FALSE; NA REG ADD EP DMSQL_TCPIP FILENAME = DMSQL_TCPIP, MYNAME = "1897", PUBLIC = TRUE; You can also copy the preceding commands to a ClearPath MCP sequential data file and load them using the following command: NA LOAD <file title>

23 Installing SQL Query Processor Optional Installation Tasks As part of the SQL Query Processor product installation, you can optionally direct the MCP host to use a pack other than the pack on which the SQL Query Processor is installed for The logging and tracing capabilities of the SQL Query Processor server By default, the system writes requested log and trace files to the pack on which the *SYSTEM/SQL/SERVER code file resides. The location of the *DMSQL/SERVER/CONFIG file By default, the system looks for the server configuration file (*DMSQL/SERVER/CONFIG) on the pack on which the *SYSTEM/SQL/SERVER code file resides. Perform the following steps to change the location of the log or trace files, or the *DMSQL/SERVER/CONFIG file: 1. Stop the SQL Query Processor server by entering the following system command: NA DMSQL QUIT NOW 2. Remove the function name specification for DMSQLSERVER by entering the following system command: SL - DMSQLSERVER 3. Execute the following commands: WFL MODIFY *SYSTEM/SQL/SERVER ON <pack name>; FILE LOG_FILE (FAMILYNAME = <pack name>); FILE TRACE_FILE (FAMILYNAME = <pack name>); FILE DMSQL_SERVER_CONFIG (FAMILYNAME = <pack name>); 4. Map the function name DMSQLSERVER to the SQL Query Processor server code file by entering the following SL (Support Library) system command: SL DMSQLSERVER = *SYSTEM/SQL/SERVER ON <pack name>:linkclass = 1, TRUSTED The pack name represents the name of the pack to which you copied the code file *SYSTEM/SQL/SERVER. The :LINKCLASS = 1, TRUSTED clause of the preceding command is required. 5. Type the following command to start the SQL Query Processor server software: NA DMSQL

24 Installing SQL Query Processor 6. Type the following command to display the status of the SQL Query Processor connection: NA DMSQL STATUS The status report includes the following information. DSS name is DMSQL. DSS provider name is DMSQLPROV. TCP/IP options are as follows: Using port is BlockedTimeout value is 10 min. DialogCheckInterval value is 5 min

25 Installing SQL Query Processor Installing the SQL Query Processor Utilities in the Windows Environment After the release media is installed on the ClearPath MCP server, the SQL Query Processor installation package is accessible from the Windows environment on the MCP share called INSTALLS. Note: If you do not have the INSTALLS share on your ClearPath MCP server, you must set up the share using the Administration Center. (Refer to the Administration Center Help.) The preferred installation method is through MCP Installation Assistant. However, you can install the SQL Query Processor directly from the \DMSQLUtilities folder on the INSTALLS share. Installing by Using MCP Installation Assistant Perform the following steps to install the SQL Query Processor using MCP Installation Assistant: 1. From the Windows environment, map a network drive to the INSTALLS share on your MCP server. 2. Double-click the file setup.exe. MCP Installation Assistant appears. 3. Expand the Database Query and Reporting group. 4. Select the SQL Query Processor Utilities for ClearPath MCP check box. Note: By default, Installation Assistant installs only the Query Design Center. To install both utilities, right-click the product name and click Install Options, select the Relational Design Center check box, and click Apply. You can also right-click the product name to view the readme file. 5. Click Next. 6. Click Install. The SQL Query Processor software is installed in the following path on the Windows environment: Program Files\Unisys\MCP\DMSQLUtilities Note: The Installation Assistant automatically installs the Java Runtime Environment (JRE) if you do not have the JRE version 1.4 or later installed. Refer to the MCP Implementation Guide for additional details on MCP Installation Assistant

26 Installing SQL Query Processor Installing by Using the SQL Query Processor.msi File Perform the following steps to install the SQL Query Processor directly from the.msi file in the \DMSQLUtilities folder on the INSTALLS share: 1. Ensure that the Java Runtime Environment (JRE) version 1.4 or later is installed. If not, install it from the INSTALLS share under the Redist\SUN folder. 2. From the Windows environment, map a network drive to the INSTALLS share on your ClearPath MCP server. 3. Double-click the INSTALLS folder. 4. Double-click the DMSQLUtilities folder. 5. Double-click the DMSQLUtils.msi file. An installation wizard is initiated. 6. Follow the instructions on the screen. Be sure to select the appropriate options for your type of installation. Note: When installing using the.msi file, you can choose to perform a complete or a custom installation. The complete setup installs both utilities. To install only one utility, select Custom. On the Custom Setup page, select Query Design Center (the default in a custom setup) or Relational Design Center, and then click Next. Migrating from an Earlier Release The format of the catalog file has changed to accommodate new functionality. Therefore, if you have an earlier release of the SQL Query Processor software installed, you must update your SQL database definition or Enterprise Database Server database on which the SQLVIEW command was processed. Updating an SQL Database Definition To update your SQL database definition to the current release of SQL Query Processor, run the Schema Administrator with the UPDATE command. You can also use the UPDATE command to update an SQL database to the current level of Enterprise Database Server software. Updating an Enterprise Database Server Database Perform the following steps to update an Enterprise Database Server database that was previously generated with the SQLVIEW command: 1. On the ClearPath MCP server, remove the file named DESCRIPTION/<database name>/dmsql-catalog

27 Installing SQL Query Processor 2. Run the following command if you made changes to the SQL schema (such as renaming a column or table) and want to preserve those changes: RUN *SYSTEM/SQL/ADMIN ("SQLVIEW DATABASE <database name> :ACCESSCONTROL=UPDATEOK"); FILE CARD=DDLRESULTS/<database name>/semantic Note: If the database must be mapped for read-only access, use the ACCESSCONTROL = INQUIRYONLY clause or omit the ACCESSCONTROL declaration. For further details, refer to Section 7, Using the Schema Administrator. 3. Start the Relational Design Center, remove the database name from the tree view, and reimport the database. Removing the SQL Query Processor Software MCP Environment Removing the SQL Query Processor software from the MCP environment involves deleting the server library, worker code files, DMSQL/CONFIG file, and the DSS entities. Perform the following steps to remove the SQL Query Processor software from the MCP environment: 1. Stop the SQL Query Processor server by entering the following system command: NA DMSQL QUIT NOW 2. Remove the function name specification for DMSQLSERVER by entering the following system commands: SL - DMSQLSERVER SL - DMSQLCONFIG SL - DMSQLSCODE SL - DMSQLCLI 3. Delete the DSS entities by entering the following system commands: NA REG DEL PROV DMSQLPROV NA REG DEL DSS DMSQL NA REG DEL EP DMSQL_TCPIP

28 Installing SQL Query Processor 4. Remove the SQL Query Processor server files by entering the following system commands: REM *SYSTEM/SQL/ADMIN ON <pack name> *SYSTEM/SQL/ADMIN/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/ETINQ ON <pack name> *SYSTEM/SQL/ETINQ/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/SCODE ON <pack name> *SYSTEM/SQL/SCODE/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/CONFIG ON <pack name> *SYSTEM/SQL/CONFIG/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/DRIVER ON <pack name> *SYSTEM/SQL/DRIVER/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/PARSER ON <pack name> *SYSTEM/SQL/PARSER/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/SERVER ON <pack name> *SYSTEM/SQL/SERVER/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/WORKER ON <pack name> *SYSTEM/SQL/WORKER/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/DMQUERY ON <pack name> *SYSTEM/SQL/DMQUERY/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/MODLANG ON <pack name> *SYSTEM/SQL/MODLANG/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/SUPPORT ON <pack name> *SYSTEM/SQL/SUPPORT/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/COBOLDESC ON <pack name> *SYSTEM/SQL/COBOLDESC/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/INTERFACE ON <pack name> *SYSTEM/SQL/INTERFACE/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/DMSIIMAPPER ON <pack name> *SYSTEM/SQL/DMSIIMAPPER/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/FILESUPPORT ON <pack name> *SYSTEM/SQL/FILESUPPORT/DIAGNOSTICS ON <pack name> *SYSTEM/SQL/SCODESUPPORT ON <pack name> *SYSTEM/SQL/SCODESUPPORT/DIAGNOSTICS ON <pack name> *SYMBOL/SQL/CLI/PROPERTIES/ALBOL ON <pack name> *SYMBOL/SQL/CLI/PROPERTIES/COBOL ON <pack name> *EXAMPLE/SQL/CLI/ALGOL ON <pack name> *EXAMPLE/SQL/CLI/COBOL ON <pack name> *EXAMPLE/DMSQL/CONFIG ON <pack name> *DESCRIPTION/SQLDIR/DMSQL-CATALOG ON <pack name> *DMSQL/SERVER/CONFIG ON <pack name> *DMSQL/LOG/= ON <pack name> *DMSQL/TRACE/= ON <pack name> *DMSQL/CONFIG ON <pack name>

29 Installing SQL Query Processor Windows Environment The Windows uninstall program removes the SQL Query Processor software only. The program does not remove the log, trace, and schema files, which you can remove manually. Perform the following steps to uninstall the SQL Query Processor software from your Windows environment: 1. Double-click the Add or Remove Programs icon on Control Panel. The Add or Remove Programs Properties dialog box is displayed. 2. Select Unisys SQL Query Processor Utilities for ClearPath MCP. 3. Click OK. The uninstall program begins and removes the SQL Query Processor software. Reinstalling the SQL Query Processor Software MCP Environment To reinstall the SQL Query Processor software in the MCP environment, follow the directions explained earlier in this section under the heading Installing the SQL Query Processor Software in the MCP Environment. Windows Environment You can reinstall the SQL Query Processor software by repeating the installation procedure. However, it is recommended that you uninstall the product first using the following procedure to ensure trouble-free operation after you have reinstalled the product: 1. Uninstall the SQL Query Processor software. Refer to the topic Removing the SQL Query Processor Software earlier in this section. 2. Install the SQL Query Processor software as outlined under Installing the SQL Query Processor Utilities in the Windows Environment earlier in this section. Note: The server maintains your previous configuration when you reinstall the SQL Query Processor software

30 Installing SQL Query Processor Troubleshooting The following procedures can help you determine if the SQL Query Processor server installation completed correctly. These procedures are not required. If you had any problems during the installation process, or if you want to confirm that all components of the SQL Query Processor server were installed, you can run some or all of the troubleshooting procedures. Verifying Release Identifiers Action To verify the installation of the most recent support libraries, enter the following CANDE commands: FAM LFILES *SYSTEM/SQL ON SYSNEW :RELEASEID LFILES *DESCRIPTION/SQLDIR/DMSQL-CATALOG :RELEASEID Result The following number of files are returned. File Type Number Returned *SYSTEM/SQL 32 *DESCRIPTION/SQLDIR/DMSQL-CATALOG 1 Solution If an incorrect number of files are returned or if the RELEASEID attribute of the files is not correct, perform the following procedures. If... Then... You are installing files from an Interim Correction (IC) tape You are installing the base release Recopy the appropriate files from the IC tape. Complete the following steps: 1. Run the Simple Installation (SI) program. 2. Ensure the product identifier is SQL. 3. Specify the appropriate release identifier. Verifying the SQL Query Processor Configuration System Library Action Enter the following ODT command:

31 Installing SQL Query Processor SL *DMSQLCONFIG Result The following statement is displayed: SL DMSQLCONFIG = *SYSTEM/SQL/CONFIG ON SYSNEW Solution If the DMSQLCONFIG statement points to another file or if the SQL Query Processor configuration system library function does not exist, enter the following ODT command: SL DMSQLCONFIG = *SYSTEM/SQL/CONFIG ON SYSNEW Verifying the SCode Compiler System Library Action Enter the following ODT command: SL * DMSQLSCODE Result The following statement is displayed: SL DMSQLSCODE = *SYSTEM/SQL/SCODE ON SYSNEW Solution If the DMSQLCODE statement points to an incorrect file or if the Scode compiler system library function does not exist, enter the following ODT command: SL DMSQLSCODE = *SYSTEM/SQL/SCODE ON SYSNEW

32 Installing SQL Query Processor Verifying the SQL Driver System Library Action Enter the following ODT command: SL *DMSQLCLI Result The following statement is displayed: SL DMSQLCLI = *SYSTEM/SQL/INTERFACE/ ON SYSNEW TRUSTED Solution If the DMSQLCLI statement points to another file, if the TRUSTED parameter is missing, or if the SQL driver system library function does not exist, enter the following ODT command: SL DMSQLCLI = *SYSTEM/SQL/INTERFACE ON SYSNEW :TRUSTED Verifying the Existence and Location of the SQL Query Processor Configuration File Action Enter the following CANDE command: RUN $SYSTEM/SQL/CONFIG ON SYSNEW Result The following text is displayed: #RUNNING 8864 > The DMSQL/CONFIG file just validated is: > *DMSQL/CONFIG ON HL511D0 10/11/ :03:05 > No errors. #ET=0.1 PT=0.0 IO=0.1 Solution If the SQL Query Processor configuration file does not exist, refer to Creating the SQL Query Processor Configuration File (DMSQL/CONFIG) earlier in this section for instructions on creating an SQL Query Processor configuration file. If the SQL Query Processor configuration file does exists, but syntax errors occur, refer to Section 6, SQL Query Processor Configuration Control Facility, for instructions about creating an SQL Query Processor configuration file

33 Installing SQL Query Processor Verifying the Contents of the SQL Query Processor Configuration File Action After verifying the existence and location of the SQL Query Processor configuration file, enter the following command to display the contents of the SQL Query Processor configuration file: LIST *DMSQL/CONFIG ON SYSNEW Result The exact text of your SQL Query Processor configuration file might differ, but ensure the following information is contained in your file: RELEASE MYSQL (PACK = SYSNEW) Solution If the RELEASE or VIEWCONNECTION option is missing from your SQL Query Processor configuration file, modify your SQL Query Processor configuration file to include these options. For detailed information about the SQL Query Processor configuration file, refer to Section 6, SQL Query Processor Configuration Control Facility. Verifying the SQL Query Processor Server Code File Action Enter the following ODT command: SL *DMSQLSERVER Result The following text is displayed: SL DMSQLSERVER = *SYSTEM/SQL/SERVER ON SYSNEW :TRUSTED, LINKCLASS=1 Solution If the DMSQLSERVER statement points to an incorrect file, if either the TRUSTED parameter or the LINKCLASS parameter is missing, or if the code file does not exist, enter the following ODT command: SL DMSQLSERVER = *SYSTEM/SQL/SERVER ON SYSNEW :TRUSTED, LINKCLASS=

34 Installing SQL Query Processor Verifying the SQL Query Processor Server Provider Action Enter the following ODT command: NA REG SHOW PROV DMSQLPROV Result The following text is displayed: Provider name: DMSQLPROV, Task type: NonMonitoredSupportLibrary Interface: Message SL: DMSQLSERVER DSSes provided: DMSQL Solution If the displayed information differs from the preceding result, enter the following ODT command: NA REG ADD PROV DMSQLPROV SL=DMSQLSERVER, TASK TYPE=NMSL, INTERFACE=MESSAGE, DSS=DMSQL Verifying SQL Query Processor Distributed Systems Services (DSS) Information Action Enter the following ODT command: NA REG SHOW DSS DMSQL Result The following text is displayed: DSSName: DMSQL, Class: OTHER Recovery after Halt/Load: FALSE, Initialize DSS: TRUE Endpoints: DMSQL_TCPIP Note: Your settings for Recovery after Halt/Load and Initialize DSS might differ. Solution If the displayed information differs from the preceding result, enter the following ODT command: NA REG ADD DSS DMSQL EP=(DMSQL_TCPIP), CLASS=OTHER, INIT=TRUE

35 Installing SQL Query Processor Verifying the TCP/IP Endpoint Action Enter the following ODT command: NA REG SHOW EP DMSQL_TCPIP Result The following text is displayed: Endpoint Name: DMSQL_TCPIP, Public Endpoint: TRUE Filename: DMSQL_TCPIP, Applicationgroup: Myname: "1897" Solution If the displayed information differs from the preceding result, enter the following ODT command: NA REG ADD EP DMSQL_TCPIP FILENAME=DMSQL_TCPIP, MYNAME="1897", PUBLIC=TRUE Note: MYNAME must be a TCP/IP port number unique to the system. The number 1897 is the default service number used for the SQL Query Processor. You can specify a different port number by registering this endpoint with a different port number for MYNAME, and by entering this number in the SQL Query Processor configuration file. Failure to choose a unique number could cause conflicts between different TCP/IP-based services. Listing the Status of the SQL Query Processor Server Action Enter the following ODT commands: NA DMSQL - NA DMSQL + NA DMSQL STATUS Note: The NA DMSQL command closes all SQL Query Processor connections and stops the SQL Query Processor server. Result The following text is displayed: DMSQL Server Status Report for job 4318/4318. Monday, October 11, :50: DSS Name is DMSQL. DSS Provider Name is DMSQLPROV. DMSQL Server [ ]. Server : *SYSTEM/SQL/SERVER ON DMSQL

36 Installing SQL Query Processor Trace Information not available. 0 DMSQL connections TCPIP Options : BlockedTimeout: 10 mins DialogCheckInterval: 5 mins Subfiles offered: 3 Using port: 1897 Solution If the required information is missing from your SQL Query Processor server configuration file (DMSQL/SERVER/CONFIG), modify your server configuration file. Updating Enterprise Database Server Databases with SQL Queries If you want an Enterprise Database Server database to be updated by SQL queries, the database must meet the following requirements: The database must be audited and include the REAPPLYCOMPLETED and INDEPENDENTTRANS options. Refer to the DASDL Reference Manual for details on these options. The database must be imported through the Relational Design Center utility with the Read-only access control option reset. See Importing a Relational Schema in Section 4 for more information. Or, the clause ACCESSCONTROL = UPDATEOK must be included as part of the Schema Administrator RUN statement. Refer to Manually Enabling SQL Access to an Enterprise Database Server Database in Section 7 for more information. The database resource must specify MODE UPDATE. Refer to the DMQUERY utility OPEN command in Section 8 for more information. Although updates to an Enterprise Application Environment (EAE) database can be performed using the SQL Query Processor, such direct updates are not recommended as they might violate EAE application business rules and corrupt the application integrity of an EAE system. Updating Enterprise Database Server Data Sets with SQL Queries If you want an Enterprise Database Server data set to be updated by SQL queries, the data set must meet the following requirements. The data set must not contain any LINK items. For some applications, the data set must have at least one set with no duplicates. Note: Ordered data sets with duplicates allowed cannot be updated

37 Section 3 Using the Query Design Center The Query Design Center is an interactive tool that administrators and developers can use to design and execute ad-hoc SQL requests against the SQL Query Processor for ClearPath MCP. This tool makes it easy to design and execute queries against Enterprise Database Server and test these queries outside of user applications. Using the Query Design Center, you specify your solution in terms of joins, ordering, columns to display, and so on. You do not use SQL syntax. The Query Design Center automatically builds the syntax of your queries based on your input. However, if you are fluent in SQL, you can manually enter and execute SQL syntax. Starting the Query Design Center Perform the following steps to start the Query Design Center: 1. On the Start menu, point to Programs, Unisys MCP, and then SQL Query Processor for ClearPath MCP Utilities, and click Query Design Center. The Open Connection dialog box appears

38 Using the Query Design Center 2. Perform one of the following actions: Type your log-in credentials without a resource name, and click OK. Refer to Usercode and Password Conventions later in this section for details on specifying your usercode and password. The Catalog window is displayed. Type your log-in credentials including a resource name, and click OK. Refer to Usercode and Password Conventions later in this section for details on specifying your usercode and password. Notes: The Analyze Query window is displayed. To authenticate log-in credentials using your ClearPath MCP usercode and password, select the MCP option in the Authentication list and type your log-in credentials. To authenticate log-in credentials using Kerberos credentials, select the Kerberos option in the Authentication list. To encrypt your Kerberos credentials, select the Encryption option in the Encryption list. If only read access is allowed on the database, select the Read Only check box. The ReadOnly property in the qdc.properties file controls the default setting of this option. The value 1 indicates read-only access. 3. Proceed with your work as desired. Usercode and Password Conventions The usercode can consist of usercode, accesscode, and chargecode combinations as shown in the following syntax. Accesscode and chargecode requirements are defined by your system administrator. <usercode> /<accesscode> /<chargecode> /<accesscode>/<chargecode> The password can consist of a password and an optional accesscode password as shown in the following syntax: <password> /<accesscode password>

39 Using the Query Design Center Understanding the Query Design Center Interface The Query Design Center consists of a main window with a menu bar and the following internal windows: Catalog The Catalog window enables you to view the available resources, the tables and columns of a given resource, and their respective properties. You can also access the Analyze Query window and the Design Query window. Analyze Query The Analyze Query window enables you to enter and execute SQL statements, and view the results. To use this window, it is recommended that you have experience in SQL syntax and semantics. Design Query The Design Query window enables you to interactively build queries and automatically generate an SQL statement. The internal window that appears in the main window of the Query Design Center depends on the task you are performing

40 Using the Query Design Center Using the Menu Bar The following table describes the menu bar located at the top of the Query Design Center window. Menu Item File Query View Options Description Enables you to connect to a resource for a server, disconnect from a server, open an existing query, save a query, or save a query result. You can also exit the Query Design Center. The following commands are available: Prepare Validates the syntax of an SQL statement and prepares the SQL statement for execution. Execute Executes the SQL statement. Commit Commits the current transaction when the Manual Commit Mode command is set. Abort Aborts the current transaction when the Manual Commit Mode command is set. Savepoint Creates a named savepoint when the Manual Commit Mode command is set. Rollback to Savepoint Rolls back the current transaction to a selected savepoint when the Manual Commit Mode command is set. Enables you to view the Catalog window. The following commands are available: QGraphs Generates a QGraph which contains information that is useful when you are manually optimizing queries. QDumps Generates a QDump which contains diagnostic information used by Unisys support personnel to analyze and troubleshoot problems you report to the Unisys Support Center. Manual Commit Mode Commits the results of each SQL statement to the database. Manual commit mode is disabled by default. You can enable Manual Commit Mode and then use the Commit and Abort commands to manually manage transactions. Isolation level Sets the transaction isolation level

41 Using the Query Design Center Menu Item Options (cont.) Window Change Row Limit Description Sets the number of rows returned for queries. Look and feel Sets the look and feel of the Query Design Center interface to the Windows, Metal (Java), or Motif (UNIX) environment. Enables you to switch between currently opened windows. Setting the Look and Feel of the Interface You can set the Query Design Center interface to have the look and feel of a Java, UNIX, or Windows environment. The default look and feel is the Windows environment. Perform the following steps to set the look and feel of the Query Design Center interface: 1. On the Options menu, point to Look and Feel. 2. Click one of the following options: Metal Motif Windows The Query Design Center adopts the selected look and feel for the current session. Determining Connection Status Perform the following steps to determine the connection status of a database: 1. Right-click in any window and click Connection Status. The Connection Status dialog box appears. 2. Review the details of the resource connection. 3. Click OK to dismiss the dialog box

42 Using the Query Design Center Catalog Window The Catalog window provides a view of resources against which you can design and execute queries. Tree View The Catalog window has two views: a tree view and a properties view. The left pane of the Catalog window displays a tree view of databases that you can access, assuming you have the proper privileges to access a particular resource. The resources are defined in the SQL Query Processor configuration file named DMSQL/CONFIG file that is used by the DMSQLCONFIG library. Note: If the number of resources exceeds the number specified for the rowlimit property, the list of available resources in the tree view is truncated. Refer to Default Properties later in this section for more information about the rowlimit property. Icons The Catalog window uses the following icons to represent the different objects in the tree view. Icon Description Identifies a database. Identifies a table. Identifies a column

43 Using the Query Design Center Icon Description Identifies a primary key. Identifies a view. Properties View The right pane of the Catalog window displays the properties of the object selected in the tree view. The properties and their and values vary depending on the selected object. Resource Properties The following properties appear in the properties view when a resource is selected in the tree view. The tree view presents the database schema in a hierarchical fashion. For a given server, the root node is the database. The properties view displays the following information for a database. Property Resource Name Database Title Description Identifies the logical name of the data source. Identifies the file title of the physical database. Table Properties The following properties appear in the properties view when a table is selected in the tree view. Property Resource Name Table Name Owner Name Type Primary Key Description Identifies the logical name of the data source. A resource maps a data source identifier to one or more physical databases. Identifies the name of the table or view of the resource. Identifies the name of the owner of the table or view. Identifies the item as a table or view. Identifies the column names of the primary key for the table or view

44 Using the Query Design Center Column Properties The following properties appear in the properties view when a column is selected in the tree view. Property Resource Name Table Name Column Name Type Length Precision Scale Required Description Identifies the logical name of the data source. A resource maps a data source identifier to one or more physical databases. Identifies the name of the table or view of the resource. Identifies the column name. Identifies the data type of the column. For a character type, identifies the number of bytes for a fixed length type and the maximum number of bytes for a variable length type. For a fixed point number (numeric or decimal type), identifies the maximum number of digits representing the value. For a fixed point number (numeric or decimal type), identifies the maximum number of digits representing the value to the right of the decimal point. Indicates whether the column can contain NULL values. Primary Key Properties The following properties appear in the properties view when a primary key is selected in the tree view. Property Resource Name Table Name Column Name Type Length Description Identifies the logical name of the data source. A resource maps a data source identifier to one or more physical databases. Identifies the name of the table or view of the resource. Identifies the column name. Identifies the data type of the column. For a character type, identifies the number of bytes for a fixed length type and the maximum number of bytes for a variable length type

45 Using the Query Design Center Property Description Precision Scale Required Primary Key Sequence Index For a fixed point number (numeric or decimal type), identifies the maximum number of digits representing the value. For a fixed point number (numeric or decimal type), identifies the maximum number of digits representing the value to the right of the decimal point. Indicates whether the column can contain NULL values. Identifies the ordinal number for each column of that is part of the primary key. There can be more than one column that is part of the primary key. Identifies the name of the index if an index exists over this column. This property could apply to any column. Opening Tables You can open tables contained in a resource. The Query Design Center automatically executes the appropriate SQL query on the table to enable you to see the rows of the table. Perform the following steps to open a table: 1. From the Catalog window, expand a resource to expose the underlying tables. 2. Right-click the desired table and click Open. The Analyze Query window appears with the SELECT statement in the text pane and the rows of the table in the results pane. Viewing Table Results Perform the following steps to display the tables of a resource and related information: 1. From the Catalog window, right-click a resource, point to View, and click SQLTables. The separate window appears listing tables contained in the resource in the results pane. 3. To save the results as a text file, right-click the results pane and click Save Result Set As. The Save dialog box appears. 4. Navigate to the desired folder, type a name in the File name box, and click Save. The file is saved

46 Using the Query Design Center Viewing Column Results Perform the following steps to display the information related to columns: 1. From the Catalog window, expand a resource, right-click the desired table, and point to View. 2. Click one of the following commands on the shortcut menu: SQLColumns Displays the columns of the selected table. SQLPrimaryKeys Displays the columns that make up the primary key for the selected table. SQLForeignKeys, related Displays the list of foreign keys in the selected table and their related primary keys. SQLForeignKeys, in this Displays the list of foreign keys in the selected table and their related primary keys. SQLStatistics Displays a list of statistics about a single table and the indexes associated with the table. A separate window appears with the results in the results pane. 3. To save the results as a text file, right-click the results pane and click Save Result Set As. The Save dialog box appears. 4. Navigate to the desired folder, type a name in the File name box, and click Save. The file is saved

47 Using the Query Design Center Analyze Query Window Text Pane The Analyze Query window enables you to Interrogate and update data in a database using SQL syntax and semantics. Experiment with the SQL Query Processor call-level interface (CLI) without having to write a COBOL or ALGOL program. Obtain diagnostic information about queries for purposes of optimization and to send to Unisys support for analysis. View result sets translated using the coded character set of the database. Through the Analyze Query window, you can enter and execute the following SQL statements, and view their results: SELECT INSERT UPDATE DELETE The Analyze Query window has two panes: a text pane and a results pane. The top pane of the Analyze Query window enables you to type the text of an SQL query statement and perform a number of operations such as statement execution and syntax checking. You can also load a query from a text fie into the text pane. In the following example, a SELECT statement was typed in the text pane. A shortcut menu appears when you right-click the text pane enabling you to perform actions against the statement

48 Using the Query Design Center Results Pane The bottom pane of the Analyze Query window displays the results of syntax checking (along with item descriptions) and the results of the executed query statement. You can also save results of a query to a text file. In the following example, the syntax of the statement SELECT * FROM sqlexample.car in the text pane is validated and the item descriptions displayed in the results pane. The following example shows the results of the executed query statement. Note: From the shortcut menu for a table or view, you can access the Analyze Query window to display the contents of the selected table (Open) or access the Design Query window to design a query involving the selected table

49 Using the Query Design Center Analyze Query Window Commands The following commands are available on the shortcut menu when you right-click in the Analyze Query window. Command Copy Result Set Clear Execute Prepare Commit Abort Savepoint Rollback to savepoint Open Query Save Query As Save Result Set As View Catalog Design Query Description Copies the table of results to the clipboard. You can only execute this command from the results pane. Removes the contents of the text pane or results pane, depending on the pane from which you execute the command. Executes the SQL statement in the text area, or executes the SQL statement that the user has selected in the text area. Parses the SQL statement in the text pane. The Query Design Center validates the syntax without attempting to execute the query. The results of a successful validation appear in the results pane along with item descriptions. If the syntax is not valid, an error message provides a description of the error. Commits the current transaction when in manual commit mode. Aborts the current transaction when in manual commit mode. Saves a named savepoint when in manual commit mode. Rolls back the current transaction to a selected savepoint when in manual commit mode. Enables you to place the contents of a saved query into the text pane. Saves the contents of the text pane to a file. Saves the results of an executed query to a text file. Displays the Catalog window. Displays the Design Query window

50 Using the Query Design Center Preparing and Executing a Query Perform the following steps to prepare and execute a query. Note: Queries are limited to a maximum number of 5000 rows by default. See the section on Customizations later in this document.) 1. From the Catalog window, right-click the desired resource and click Analyze Query. The Analyze Query window appears. 2. In the text pane (top pane), type your query statement. 3. Right-click and choose Prepare. The Query Design Center checks the syntax of your statement. If the syntax is valid, the outcome along with item descriptions is displayed in the results pane (bottom pane). The following message also appears: Statement was prepared successfully. See item descriptions above. If the SQL syntax is not valid, an error message appears containing a description of the error. You must correct the syntax before proceeding. 4. Right-click and choose Execute. If your SQL statement contains parameters, the Enter Parameters dialog box appears. Continue with step 5. Otherwise, the Query Design Center executes the query and the outcome appears in the results pane. 5. Type the desired parameters in the Parameter 1 box, and click OK. The outcome of the query appears in the results pane. Note: The Enter Parameters dialog box continues to appear depending on the number of parameters declared in your SQL statement. 6. To save the results as a text file, right-click the results pane and click Save Result Set As. The Save dialog box appears. 7. Navigate to the desired folder, type a name in the File name box, and click Save. The file is saved. Saving a Query You can save a query statement that you enter in the text pane and use it later. Perform the following steps to save a query: 1. Right-click the text pane and click Save Query As. The Save dialog box appears. 2. Navigate to the desired folder, type a name in the File name box, and click Save. The file is saved with the.sql extension, for example, mystatement.sql

51 Using the Query Design Center Saving Query Results Perform the following steps to save query results: 1. Right-click the results pane and click Save Result Set As. The Save dialog box appears. 2. Navigate to the desired folder, and select a file format from the Files of type list. Note: Selecting All Files saves the file as a.txt file. 3. Type a name in the File name box and click Save. Opening a Query The file is saved with the extension that corresponds to the format you chose (that is,.txt,.csv, or.tsv). You can reuse a query that you previously saved in the Query Design Center. This action eliminates the need for you to retype the query or recall syntax of an intricate SQL statement. Perform the following steps to open a query: 1. From the Analyze Query window, right-click and click Open Query. The Open dialog box appears. 2. Navigate to the folder containing the.sql file (for example, myquery.sql) of the query you want to open, and select the file. The file name appears in the File name box. 3. Click Open. The Open dialog box is closed and the query appears in the text pane of the Analyze Query window. Enabling Manual Commit Mode By default, the results of each SQL statement executed in the Query Design Center are automatically committed in the database. However, you can override this action by enabling manual commit mode. Once this mode is enabled, you can then use the Commit and Abort commands to manually manage transactions. Refer to Commands earlier in this section for a description of the Commit and Abort commands. Perform the following steps to enable manual commit mode: 1. On the Options menu, click Manual Commit Mode. A check mark appears to the left of the command to indicate that manual commit mode is enabled. You can now initiate the Commit and Abort commands for SQL statements you execute in the Query Design Center

52 Using the Query Design Center 2. To disable the option, click Manual Commit Mode on the Options menu to remove the check mark next to the command. Setting Transaction Isolation Levels The Query Design Center supports the following isolation levels for transactions: Read Committed The Read Committed isolation level allows a transaction to acquire a read lock (if it only reads the data) or a write lock (if it updates or deletes data) on the current record of data with which it is working. The record being used by the transaction cannot be changed or removed by other transactions until the lock is released. Read locks are released when the transaction moves off the current record. Write locks are held until the transaction is committed or rolled back. Transactions using the Read Committed isolation level wait until records of data that are write-locked by other transactions are unlocked before they acquire their own locks. Dirty reads are not possible. Nonrepeatable reads and phantom reads are possible. Read Uncommitted The Read Uncommitted isolation level does not lock records. Dirty reads, nonrepeatable reads, and phantom reads are possible. Repeatable Read The Repeatable Read isolation level places a shared lock on records. Dirty reads and nonrepeatable reads are not possible. Phantom reads are possible. Serializable The Serializable isolation level locks an entire structure. Dirty reads, nonrepeatable reads, and phantom reads are not possible. Note: If you do not specify an isolation level, the level Read Committed is applied to automatic and manual transactions. To set the isolation level for transactions, click the Options menu, point to Isolation Level, and click the level you want to apply to transactions. A check mark appears to the left of the isolation level to indicate that it is enabled

53 Using the Query Design Center Creating a Savepoint A savepoint is a special mark inside a transaction that allows all commands that are executed after it is established to be rolled back, restoring the transaction state to what it was at the time of the savepoint. The Query Design Center enables you to create savepoints for transactions you perform. Note: You can only create a savepoint when manual commit mode is enabled. Perform the following steps to create a savepoint: 1. On the Options menu, click Manual Commit Mode. A check mark appears to the left of the command to indicate that manual commit mode is enabled. 2. Perform the desired actions. 3. Right-click the Analyze Query window and click Savepoint. The New Savepoint dialog box appears. 4. Type the desired name in the Savepoint Name box, and click OK. A message is displayed indicating that the savepoint was successfully created. Rolling Back to a Savepoint Note: You can only roll back the current transaction to a selected savepoint when manual commit mode is enabled. Perform the following steps to roll back the current transaction to a selected savepoint: 1. Right-click the Analyze Query window and click Rollback to savepoint. The Rollback to Savepoint dialog box appears. 2. Type the desired name in the Savepoint Name box and click OK. A message is displayed indicating that the transaction was rolled back to the savepoint. Setting the Row Limit The Query Design Center enables you to set the maximum number of rows returned for queries made in the current session. Perform the following steps to set the row limit: 1. On the Options menu, click Change Row Limit. The Set Row Limit dialog box appears. 2. Type the desired value in the Number of Rows box and click OK. The new limit takes effect

54 Using the Query Design Center Generating a QGraph A QGraph is a useful aid when manually optimizing queries. You enable and disable QGraphs from the Options menu when the Analyze Query window is displayed. When you enable QGraphs, a graph is generated for each SQL statement executed in the Analyze Query window. Note: You cannot enable or disable QGraphs from the other windows of the Query Design Center. Perform the following steps to generate a QGraph: 1. Display the Analyze Query window, and click QGraphs on the Options menu. A check mark appears to the left of the command indicating that QGraphs is enabled. 2. Type a valid SQL statement in the text pane. 3. Right-click and click Execute or Prepare. The text editor Notepad appears containing a QGraph for the executed query. The following example shows sample QGraph output. 4. If desired, save the QGraph output to a text file

55 Using the Query Design Center Generating a QDump A QDump serves as a diagnostic aid to Unisys support personnel to analyze and troubleshoot problems you report. You enable and disable QDumps from the Options menu when the Analyze Query window is displayed. When you enable QDumps, a graph is generated for each SQL statement executed in the Analyze Query window. Note: You cannot enable or disable QDumps from the other windows of the Query Design Center. Perform the following steps to generate a QDump: 1. Display the Analyze Query window, and click QDumps on the Options menu. A check mark appears to the left of the command indicating that QDumps is enabled. 2. Type a valid SQL statement in the text pane. 3. Right-click and click Execute or Prepare. The text editor Notepad appears containing a QDump for the executed query. The following example shows sample QDump output. 4. If desired, save the QDump output to a text file

56 Using the Query Design Center Design Query Window The Design Query window enables you to interactively build queries and automatically generate the SQL statements. Join Pane The Design Query window has four panes: join pane, query table pane, text pane, and results pane. The top pane of the Design Query window is used to specify joins. You use the join pane along with the query table pane to enter your SQL statement. Query Table Pane The second pane of the Design Query window contains a query table and enables you to specify various attributes of database columns in the query. You use the query table pane along with the join pane to enter your SQL statement. Column Attributes The following attributes appear in the query table pane of the Design Query window. Attribute Column Alias Description Identifies a database column that can be entered as text or selected from a list box. In general, this is an SQL expression. Each row of the query table must have something specified in this query table column. There is no validity checking of the text that is entered except when the SQL statement is generated. Identifies another name for the query column. If the Output attribute is selected for the column, the alias becomes the column title of the result set of the query when the query is executed. You do not have to specify an alias unless the column is not a simple database column name and it is to be used in the sort order of the query

57 Using the Query Design Center Attribute Table Output Aggregate Group By Sort Order Column Sequence Conditions Description Identifies the database table name for the column. This read-only query column is the database table name for the column if the column contains a simple database column. Indicates that the column is to be part of the result set for the query. Indicates that the aggregate functions of the column is to be aggregated (that is, a set function is to be applied). The functions are count, average, maximum, minimum, and sum. There is no validity checking to determine whether the selected function is compatible with the data type of the column. (For example, if sum is selected, the column should be a numeric type.) Indicates that the query results are to be grouped by the column. Grouping is a well-defined SQL concept. Indicates whether the rows in the result set are to be in ascending or descending order. Indicates whether the rows in the result set are to be ordered by the value of more than one column. Specify the sequence of the value of this column when determining the order of the row. Specifies search conditions in the last three query table columns: Conditions, OR Condition, and OR Condition. For example, if the you wants to select database rows for which the value of the column is greater than 100, less than 10, or equal to 50, then you would enter the following in the corresponding columns: Conditions: >100 OR cond: <10 OR cond: =50 If you want an AND condition using the same column, make two query table rows by using the same value for the column in each row. For example, if you want to select database rows for which the value of the column is greater than 100 but less than 200, you use two query table rows each with the same column value and the following values in the two rows: Conditions: >100 Conditions: <

58 Using the Query Design Center Text Pane Results Pane The third pane of the Design Query window is automatically populated with the SQL statement derived from the top two panes. The bottom pane of the Design Query window displays the results of syntax checking (along with item descriptions) and the results of the executed query statement. You can also save results of a query to a text file. Designing a Query Note: Before using the Design Query window, you should already have designed your query at the SQL concepts level using grouping, aggregation, ordering, and search conditions. Perform the following steps to design and execute a query in the Design Query window: 1. From the Catalog window, right-click a resource and click Design Query. The Design Query window appears with the Add Tables dialog box displayed in the join pane. 2. Select a table or view from the list and click Add. The table or view appears in the join pane. The SELECT statement automatically appears in the text pane. However, the statement is not executed. 3. Add the tables and views involved in the query using the join pane. An SQL join is represented by a line between two columns. When you add a table, a join is automatically assumed between columns having the same name. Refer to the following illustration for an example. 4. Add any remaining joins between tables by using the join pane. Select a column in the join pane and drag the column to another column

59 Using the Query Design Center 5. From the join pane, place a check mark on the database columns whose values are to be part of the query result, are to be part of search conditions, are involved in ordering, and are to be aggregated. All the checked database columns appear in the query table pane with a check mark in the Output column. Refer to the following illustration as an example. 6. In the query table pane, clear the check marks from the Output column of all database columns that are not to be part of the query result set. (In this example, uncheck reg_no.) 7. Add the other attributes of each column: aggregation, group by, sort order, and search conditions. 8. If desired, add aliases for database columns to be part of the result set and database columns involved in ordering. Enclose in quotation marks the aliases containing spaces or special characters. The following lists the generated SQL for the examples illustrated in this procedure. SELECT AVG(car1.price) AS "avg_price", car_owner1.person_id FROM car car1 JOIN car_owner car_owner1 ON car1.reg_no = car_owner1.reg_no GROUP BY car_owner1.person_id HAVING (COUNT(DISTINCT car1.reg_no) >1) ORDER BY person_id ASC 9. In the text pane, right-click the generated SQL statement and click Execute to see whether the statement produces the desired results

60 Using the Query Design Center Customizing the Query Design Center You can customize the Query Design Center to suit your operational preferences by overriding the default properties of the utility. These properties affect areas such as server connection, look and feel, tracing, and fonts. Perform the following steps to customize the Query Design Center: 1. Execute the Query Design Center. A directory named \.dmsql is created in your user home directory. A file named qdc.properties is also created with all property settings commented out. 2. Using a text editor, change the properties for which you want to use values other than the defaults. You change a property by removing the number sign character (#) at the beginning of a property name and editing the corresponding value. Refer to Default Properties later in this section for a list of the properties you can customize. 3. Save the file in the \.dmsql directory. Default Properties The modified properties take effect the next time you launch the Query Design Center. The following lists the default properties contained in the Query Design Center properties file: #qdc properties file #default connection attributes #hostname= #portnumber=1897 #usercode= #password= #resource= #authentication and encryption attributes # authentication: 0=MCP 1=Kerberos # encryption: 0=None 1=Kerberos #authtype=0 #encrypttype=0 #servicename= #readonly= #limit on the number of rows to fetch #rowlimit=5000 #time in seconds between query status messages #statustimeinterval=

61 Using the Query Design Center #look and feel. default is windows #lookandfeel=javax.swing.plaf.metal.metallookandfeel #lookandfeel=com.sun.java.swing.plaf.motif.motiflookandfeel #lookandfeel=com.sun.java.swing.plaf.windows.windowslookandfeel #lookandfeel=com.sun.java.swing.plaf.gtk.gtklookandfeel #default directory to find and save queries #dir= #tool to run to display text files #notepad=notepad #tool to run to display binary files #mspaint=mspaint #enable/disable dialog boxes being displayed as a result of query errors #batchmode=1 #enable tracing #trace=1 #tracefile=qdc.trc #default frame will be either the query analyzer or query designer. default defaultframe is analyzer. #defaultframe=analyzer #defaultframe=designer #font #syntax: #fontfamilyname[-style][-pointsize] or #fontfamilyname [style] [pointsize] # in which style is one of the three case-insensitive strings: # "BOLD", "BOLDITALIC", or "ITALIC", and pointsize is a decimal representati on of the point size. # For example, if you want a font that is Arial, bold, and a point size of 1 2, # you would call this method with: "Arial-BOLD-12". #font=courier #1.4.font is the font to use when using jre 1.4.x #1.4.font=Batang-12 #tool tip delays #initialdelay=250 #reshowdelay=250 #localserver implementation. the default is DMSQLConnection #localserver=com.unisys.dmsql.server.serverimpl.dmsqlconnection #set for experimental version. for example, sending query driver messages #experimental=

62 Using the Query Design Center Note: The rowlimit property affects all calls sent to the SQL Query Processor. Queries and catalog calls are affected by this limit. Enabling Trace You enable code tracing in the Query Design Center by uncommenting the trace property in the qdc.properties file. Refer to Default Properties earlier in this section for the location of the trace property. The default location of the trace file produced by the Query Design Center is <user home>\.dmsql\qdc.trc. A corresponding Provider trace file named qdc-provider.trc is saved to the same directory. If you enable tracing and also set the tracefile property to a different directory than the default, the Provider trace is saved in the same directory

63 Section 4 Using the Relational Design Center Utility The Relational Design Center is a schema administration tool that enables SQL access to Enterprise Database Server databases. The Relational Design Center enables you to perform a variety of tasks against the databases. Depending on the type of database or file processed, you can perform the following tasks: Generate an SQL schema (relational view) for Enterprise Database Server databases. Define and modify schema attributes to be used for mapping an Enterprise Database Server description file. View a mapped Enterprise Database Server database definition. Once you have created an SQL description of your database, you can perform inquiries or updates against the data in the database by using any tool or application that generates SQL data manipulation language (DML) statements compatible with the Unisys implementation of SQL. For example, these tools or applications include: SQL Query Processor for ClearPath MCP Query Design Center JDBC for ClearPath MCP ClearPath MCP environment applications that use the SQL call-level interface (CLI) such as COBOL or ALGOL The Relational Design Center offers the following features: Creation of SQL descriptions for existing Enterprise Database Server databases SQL security using grants and views, including row and column security Referential integrity Ability to disable all updates Concurrent access to Enterprise Database Server databases with Enterprise Database Server and SQL applications Enterprise Database Server items specified as SQL date items Use of Enterprise Database Server data names while using SQL facilities New SQL names for Enterprise Database Server data sets, sets, and data items Exclusion of certain Enterprise Database Server data sets, sets, or data items from the generated SQL descriptions

64 Using the Relational Design Center Utility Multiple interfaces from which to generate SQL descriptions of existing Enterprise Database Server databases Starting the Relational Design Center Perform the following steps to start the Relational Design Center: 1. From the Start menu, point to Programs, Unisys MCP, and then SQL Query Processor for ClearPath MCP Utilities, and click Relational Design Center. The Relational Design Center window is displayed. 2. Proceed with your work using the desired servers and databases. Understanding the Relational Design Center Interface The interface of the Relational Design Center is similar in appearance to that of Windows Explorer. The main window of the Relational Design Center is divided into the following views: Tree view Properties view User assistance view Output view The main window also has a menu bar from which you can access commands to perform various tasks

65 Using the Relational Design Center Utility Tree View The left pane of the Relational Design Center window displays a tree view of servers and databases. The view displays the schema of a database organized by structure and data items within a structure. The tree view contains nodes for the tables, columns, constraints, dates, indexes, grants, and views of the database. Note: When the Relational Design Center is reopened, the database nodes do not expose the underlying structures. To expose the underlying structures, you must rightclick the database and choose Open Database from the shortcut menu. Icons The Relational Design Center uses icons in the tree view to represent the different objects in the tree view. The following table describes the icons that appear in the Relational Design Center window. Icon Description Identifies the root node. Identifies a server. Identifies a database. Depending on the context, identifies a data set, occurring item or group, or variable format item. Identifies a data item or column. Identifies a set or subset. Identifies a constraint. Identifies a date. Identifies a grant. Identifies a view. Note: Right-clicking the root, server, or database object in the tree view displays a shortcut menu from which you can select an action to perform against the object. Properties View The top-right pane of the Relational Design Center window displays the properties associated with structural elements of a database. The properties for a selected object are displayed in columnar fashion. The number of columns and their values change depending on the selected object. Note: For constraints, dates, grants, and views, this area of the Relational Design Center window displays input fields enabling you to define the selected item. The following text identifies the properties associate with the various objects that appear in the tree view

66 Using the Relational Design Center Utility Database The tree view presents the database schema in a hierarchical fashion. For a given server, the root node is the database. The properties view displays the following information for a database. Property Database Name Usercode Pack Family Description File Location Control File Location Database Update Timestamp Database Type Description Identifies the name of the Enterprise Database Server Database. You cannot change the value for this property. Identifies the usercode of the database owner. You cannot change the value for this property. Identifies the pack family of the database owner. You cannot change the value for this property. Identifies the location of the database description file. You cannot change the value for this property. Identifies the location of the control file. You cannot change the value for this property. Indicates the date and time the database was last updated. You cannot change the value for this property. Identifies the database type. You cannot change the value for this property. Data Set The properties view displays the following information for a data set. Property Data Set Name Alias Table Name Ignore Description Identifies the data set names. You cannot change the value for this property. Identifies the name used for the SQL table represented by the data set. The alias for the global data set is GLOBALDATA. Indicates whether the data set is accessible to SQL queries. Data Items (Columns and Primary Keys) The properties view displays the following information for a data item. Property Enterprise Database Server Item Name Description Identifies the item name. You cannot change the value for this property

67 Using the Relational Design Center Utility Property Alias Column Name Alias Primary Key Name Primary Key Position Ignore Description Identifies the name used for the SQL table represented by the column. Identifies the name used for the SQL table represented by the primary key. Designates the item or items that compose the primary key. The number defines the position the item has in the primary key. Indicates whether the column is accessible to SQL queries. Indexes (Sets and Subsets) The properties view displays the following information for an index. Property Enterprise Database Server set or subset name Alias Index Name Ignore Description Identifies the Enterprise Database Server set or subset name. You cannot change the value for this property. Identifies the name used for the SQL table represented by the set or subset. Indicates whether the set or subset is accessible to SQL queries. Occurring Item or Occurring Group The properties view displays the following information for occurring items or occurring groups. Property Enterprise Database Server Data Set Name Occurring Item Table Name Occurring Index Column Name Occurring Index Is REQUIRED Ignore Description Identifies the data set name. You cannot change the value for this property. Identifies the name used for the SQL table representing the occurring item. The alias for the global data set is GLOBALDATA. Identifies the name used for the column representing an items occurrence. Indicates if you want the occurring index column to be required, not a null column. Indicates whether this table is accessible to SQL queries

68 Using the Relational Design Center Utility Variable-Format Item The properties view displays the following information for variable-format part items. Property Parent Table Name Alias Table Name Variable Format number Ignore Description Identifies the name of the owning SQL table. You cannot change the value for this property. Identifies the name used for the SQL table represented by the variable-format part. Identifies the variable-format part number associated with this SQL table. Indicates whether the variable-format part is accessible to SQL queries. User Assistance View Output View The pane below the properties view of the Relational Design Center window is the user assistance view, which displays information related to the selected object in the tree view or related to a given task. The bottom pane of the Relational Design Center window displays status returned from the SQL Query Processor server and SQL schema listings

69 Using the Relational Design Center Utility Using the Menu Bar The following table describes the menu bar at the top of the Relational Design Center window. Menu Item Command File Save Schema Saves schema modifications to a file for later use. Load Schema Exit Merges saved schema modifications with the current schema. Exits the Relational Design Center. Action Add Server (top node only) Validates the server and adds the server to the tree view. The server contains a list of the Enterprise Database Server databases that you map through the Relational Design Center. Import Relational Schema (server node only) Creates a relational mapping of an existing Enterprise Database Server database. Create SQL Database (server node only) Creates an SQL database from an SQL schema. Remove Server (server node only) Removes the selected server node including all the Relational Design Centers and SQL databases. Add Schema Modifications (database node only) Applies schema modifications to the the Relational Design Center of the database. Get SQL Schema (database node only) Displays the SQL schema listing for the database. Refresh Database (database node only) Updates the mapping on the selected database if modifications are detected. Remove Database (database node only) Removes the selected database and all saved database modifications from the tree view

70 Using the Relational Design Center Utility Understanding Relational Mappings for SQL When you perform an import operation on an Enterprise Database Server in the Relational Design Center, a relational schema of the database is created and visible in the tree view. (Refer to Importing a Relational Schema later in this section for details on the import operation.) It is important for you to understand the concepts associated with the relational schema and how you can use the Relational Design Center to make modifications to the schema. This subsection discusses the following topics: Default SQL names Global data defaults Disjoint data set defaults Embedded data set and occurring item defaults Initial values Set and access defaults as indexes Set and subset defaults as views Data item defaults Link defaults Group defaults Physical option defaults Restart data set defaults SQL referential integrity constraints Date construct Security View construct Grant construct

71 Using the Relational Design Center Utility Default SQL Names As much as possible, the Relational Design Center uses Enterprise Database Server names in the descriptions it generates. However, the SQL names are different if the Enterprise Database Server names are modified through additional semantics or if there is a naming conflict. The rules for names are slightly different between SQL and Enterprise Database Server. For example, the Relational Design Center sometimes needs to substitute names for new tables when mapping occurring items. These new table names might conflict with other names in an Enterprise Database Server database or with other substituted table names. These naming conflicts must be resolved. Handling Naming Conflicts If the Relational Design Center encounters a naming conflict between SQL and Enterprise Database Server, it resolves the conflict by altering the Enterprise Database Server name in the SQL description as follows: For the first occurrence of a conflict, the Relational Design Center appends the type of the SQL object to the Enterprise Database Server name, connecting them with an underscore character (_). For additional occurrences of a naming conflict, the Relational Design Center appends a unique name. Typically, item name conflicts are resolved by truncating the name to 24 characters and then appending _COLnn to the name. Structure name conflicts are resolved by truncating the name to 22, 23, or 24 characters and appending _INDEXnn, _VIEWnn, or _TBLnn to the name. The variable nn is a unique integer. For example, the first occurrence of an item named SELECT would become SELECT_COL00 because SELECT is a reserved word in SQL. Another occurrence of SELECT would become SELECT_COL01. The Relational Design Center records any name changes in the results file. For more information about Enterprise Database Server naming conventions, refer to the Data and Structure Definition Language (DASDL) Programming Reference Manual. For more information about SQL naming conventions, refer to the SQL Query Processor Programming Guide

72 Using the Relational Design Center Utility Global Data Defaults All Enterprise Database Server global data items are mapped into a single SQL table called GLOBALDATA. This table always contains exactly one row. You can access or modify the contents of the row using the DML statements SELECT or UPDATE, but you cannot use the INSERT or DELETE statements. Disjoint Data Set Defaults Disjoint data sets are modeled as SQL tables, with the following exceptions: Ordered data sets with duplicates allowed are modeled as tables in which all columns have READONLY column access specified. You can access these tables only for selection. This restriction occurs because no suitable primary key is available for this type of data set. Variable-format data sets (both standard and unordered) are modeled using multiple SQL tables and an SQL view. If the length of the default name exceeds the SQL maximum name length, the default name is truncated to the maximum name length of 30 single-byte characters or 14 double-byte characters. If this truncation causes a naming conflict, it is resolved according to the method outlined under Handling Naming Conflicts earlier in this section. Data Set Example The following example illustrates how a simple data set can be mapped in SQL: Enterprise Database Server PERSON DATA SET ( NAME ALPHA(20); INSTRUCTOR-ID NUMBER(10); ); BY-NAME SET OF PERSON KEY IS NAME NO DUPLICATES; SQL Description with Default Names CREATE TABLE PERSON (NAME CHAR(20) NOT NULL, INSTRUCTOR_ID NUMERIC(10), PRIMARY KEY (NAME) ) CREATE VIEW BY_NAME AS SELECT * FROM PERSON --ORDER BY : NAME INDEX BY_NAME_INDEX ON PLAYER (ASCENDING NAME) UNIQUE

73 Using the Relational Design Center Utility Variable-Format Data Set Example The following example illustrates how an Enterprise Database Server variable-format data set can be mapped in SQL: Enterprise Database Server PERSON DATA SET (NAME ALPHA(20); PROFESSION RECORD TYPE(2)) 1: (STUDENT-ID NUMBER(10)), % Student data 2: (INSTRUCTOR-ID NUMBER(10)); % Instructor data SQL Description with Default Names CREATE TABLE PERSON (NAME CHAR(20), PROFESSION INTEGER READONLY NOT NULL DEFAULT 0) CREATE TABLE PERSON_FORMAT_1 (NAME CHAR(20), PROFESSION INTEGER READONLY NOT NULL DEFAULT 1, STUDENT_ID NUMERIC(10)) CREATE TABLE PERSON_FORMAT_2 (NAME CHAR(20), PROFESSION INTEGER READONLY NOT NULL DEFAULT 2, INSTRUCTOR_ID NUMERIC(10)) CREATE VIEW PERSON_VIEW (NAME, PROFESSION) AS SELECT NAME, PROFESSION FROM PERSON UNION ALL SELECT NAME, PROFESSION FROM PERSON_FORMAT_1 UNION ALL SELECT NAME, PROFESSION FROM PERSON_FORMAT_

74 Using the Relational Design Center Utility SQL Description Modified with More Meaningful Names CREATE TABLE PERSON (NAME CHAR(20), PROFESSION INTEGER READONLY NOT NULL DEFAULT 0) CREATE TABLE STUDENT (NAME CHAR(20), PROFESSION INTEGER READONLY NOT NULL DEFAULT 1, STUDENT_ID NUMERIC(10)) CREATE TABLE INSTRUCTOR (NAME CHAR(20), PROFESSION INTEGER READONLY NOT NULL DEFAULT 2, INSTRUCTOR_ID NUMERIC(10)) CREATE VIEW PERSON_VIEW (NAME, PROFESSION) AS SELECT NAME, PROFESSION FROM PERSON UNION ALL SELECT NAME, PROFESSION FROM STUDENT UNION ALL SELECT NAME, PROFESSION FROM INSTRUCTOR As shown in this example, for variable-format data sets the Relational Design Center normally uses identifiers that are named with the following format: <data set name>_format_<format number> You can make the identifier names created by the Relational Design Center more meaningful by defining schema modifications

75 Using the Relational Design Center Utility Variable-Format Data Set Behavior The STUDENT table contains only those records from the Enterprise Database Server data set that have PROFESSION equal to 1 as shown by the DEFAULT value for PROFESSION. Similarly, the INSTRUCTOR table contains only those records from the Enterprise Database Server data set that have PROFESSION equal to 2 as shown by the DEFAULT value for PROFESSION. The PERSON table contains only those records with no variable-format part. When PROFESSION is equal to 0, a record contains no variable-format parts. The view PERSON_VIEW contains all records in the Enterprise Database Server data set, regardless of their PROFESSION value. Normally, updates to a view based on multiple tables would not be allowed in SQL. However, updates are allowed for a view created for a variable-format data set such as PERSON_VIEW because the underlying Enterprise Database Server construct is really a single data set. Updates to the view PERSON_VIEW also appear in the PERSON, INSTRUCTOR, and STUDENT tables. If you insert a row into the PERSON, INSTRUCTOR, or STUDENT table, that row automatically becomes part of the view table. In the preceding example, when a row is added to the STUDENT or INSTRUCTOR table, that row automatically belongs to the PERSON_VIEW view. If you delete a row from the PERSON_VIEW table, that row is automatically deleted from the PERSON, STUDENT, or INSTRUCTOR table. When a row is deleted from the STUDENT or INSTRUCTOR table (the variable-format part tables), the whole record is deleted, including the fixed-format part. To provide the functionality described in the preceding text, the system must always have access to the column representing the record type item. Therefore, if any security is specified through modifying the schema, then a GRANT statement allowing all users to select the record type column is implicitly added to all of the tables and to the view that represents the variable-format data set

76 Using the Relational Design Center Utility Embedded Data Set and Occurring Item Defaults Embedded data sets and occurring items are both modeled as embedded tables. Modeling Rules Modeling embedded data sets is similar to the method the Relational Design Center uses to model disjoint data sets as tables. All modeling rules described earlier in Disjoint Data Set Defaults apply to embedded data sets. In addition, embedded partitioned data sets are not modeled. A set spanning an embedded data set is not usable by the SQL query optimizer and cannot be modeled as an index or used as an index during query processing. However, the set is used by the system to access the embedded data set. Limitations on Levels of Embedding For occurring items, a limit is imposed on the number of rows that can exist in the embedded table for each row in the master table. This limit is equal to the maximum number of occurrences. Embedded data sets are modeled as separate tables with no limit on the number of rows for each row in the master table. One or more additional columns are logically added to the SQL description and are used to join the embedded table to its master table. These additional columns are copies of the primary key columns in the master table. For more information on the primary key, refer to How a Primary Key Is Chosen later in this section. Modeling embedded tables is limited to two embedded levels within a disjoint data set. For example, assume that data set DS1 is disjoint, data set DS2 is embedded in DS1, data set DS3 is embedded in DS2, and data set DS4 is embedded in DS3. In this example, DS1, DS2, and DS3 are modeled since DS1 is disjoint; DS2 is the first embedded level, and DS3 is the second embedded level. DS4 is not modeled because it is the third embedded level. Each occurring item also adds an embedded level. If data set DS1 contains occurring item DS1-G1, which in turn contains occurring item DS1-G2, both DS1-G1 and DS1-G2 are modeled because they are the first two embedded levels. If embedded data set DS2 contains occurring item DS2-G1, which in turn contains occurring item DS2-G2, then DS2-G1 is modeled because it is the second embedded level. However, DS2-G2 is not modeled because it is the third embedded level. Within DS3, no occurring items would be modeled because it is already the second embedded level. Modeling is further limited by the absence of primary keys

77 Using the Relational Design Center Utility Deleting Embedded Tables For a first-level embedded table, the master table is the disjoint data set that contains the embedded table. For a second-level embedded table, the master table is the first-level embedded table that contains the second-level embedded table. If you want to delete a master row that contains an embedded data set, you must first delete all the embedded data set rows contained in the master row. If a master table contains embedded occurring tables, you can delete the master rows at any time. When you delete a master row, all the embedded occurring rows contained in that master row are automatically deleted at the same time. Occurring Item Mapping The Relational Design Center processes occurring items in one of the following ways: If the occurring item is contained in a group, the nonoccurring items in the group are modeled as columns in their containing (master) table. Any occurring item contained in the group is modeled as a separate table. An occurring item that is not in a group is modeled as a separate table. An occurring item in global data is modeled as a fixed-length string. The string length is equal to the length of the occurring area. Individual items within such an occurring item are not modeled. Occurrence Index Mapping The Relational Design Center represents the occurrence index of an occurring item as a column of type INTEGER with the STATIC option defined. The STATIC option is used because SQL does not support the modification of the occurrence index. Modifying the occurrence index would involve moving the contents of one row to another row and deleting the previous row. The Relational Design Center defines a check constraint for the column to ensure that the value assigned to the occurrence index falls within the allowed bounds. The occurrence index can be retrieved as a target item, tested in a selection expression, or assigned when inserting an occurrence of the row into its embedded table. By default, the name of the occurrence index column is <occurring item name>_inx. In the Relational Design Center, you can modify the schema to specify a more meaningful name for the occurrence index column

78 Using the Relational Design Center Utility Maintenance Options By default, the system maintains the occurrence index column. However, in the Relational Design Center, you can specify whether the column is system-maintained or user-maintained as follows: If you do not specify that the index is required for the column, the occurrence index column can be maintained by the system or the user. Values are assigned either by the user or automatically by the system. Users can insert data into a known open slot, or users can insert data without knowing which occurrence slot is available and allow the system to assign the slot. The system searches for the first open slot and inserts data into that slot. If you specify that the index is required for the column, the user must maintain the occurrence index column. The user must provide a value for the occurrence index when inserting data. Having the user provide the value allows specific occurrence index slots to be assigned by the user and requires the user to know which is the correct slot. This option is useful if the assigned occurrence index makes the data meaningful, such as if an item occurs seven times once for each day of the week. How Embedded Tables Are Modeled If a table has a primary key, the contained occurring items and embedded data sets are modeled as embedded tables at the first or second embedded level. The primary key columns of the containing (master) table are logically copied to the embedded table columns with the options NOT NULL and STATIC. These copied columns constitute the foreign key in the embedded table and can be used to join the embedded table to its master table. For a SELECT statement, failure to join the embedded table to a particular master tuple results in a linear search of the master table. For an INSERT statement, the values specified for the copied columns much match the existing values of some rows in the master table or a Matching Primary Key Not Found error occurs. If an attempt is made to delete a master table entry when a corresponding entry exists in the embedded table, the system issues an error message related to the foreign key constraint violation. For an embedded table mapped from an embedded data set, the user-specified or default primary key columns constitute a partial primary key, which is appended to the columns copied from its master table to form the full primary key for the embedded table. For an embedded table mapped from an occurring item, the occurrence index is the partial primary key, which is appended to the columns copied from its master table to form the full primary key for the embedded table. For a second-level embedded table, the master table is the containing embedded table at the first embedded level, and the copied columns are the columns of the full primary key at the first embedded level

79 Using the Relational Design Center Utility For an occurring item within an occurring item within a disjoint data set, the full primary key consists of the disjoint data set primary key, the first occurring item occurrence index, and the second occurring item occurrence index. The first two of these three keys are the copied primary key from the master table (the higher level occurring item). Occurring Item and Embedded Data Set Examples The following examples illustrate how a DASDL occurring item and a DASDL embedded data set are modeled in SQL: DASDL Example DASDL Occurring Item PERSON DATA SET (NAME ALPHA(20); CHILD ALPHA(20) OCCURS 10 TIMES); PERSON-SET SET OF PERSON KEY NAME NO DUPLICATES; DASDL Embedded Data Set PERSON DATA SET (NAME ALPHA(20); CHILD DATA SET (CHILDNAME ALPHA (20)) ;CHILD-SET SET OF CHILD KEY CHILD NAME); PERSON-SET SET OF PERSON KEY NAME NO DUPLICATES; SQL Example SQL Occurring Table CREATE TABLE PERSON (NAME CHARACTER (20) NOT NULL PRIMARY KEY (NAME) ) CREATE TABLE CHILD (NAME CHARACTER (20) NOT NULL, STATIC,CHILD CHARACTER (20),CHILD_INX INTEGER STATIC,PRIMARY KEY (NAME, CHILD_INX ),CONSTRAINT CHILD_INX_CHECK CHECK (CHILD_INX >= 1 AND CHILD_INX <= 10) ) CREATE VIEW PERSON_SET AS SELECT * FROM PERSON --ORDER BY: NAME SQL Embedded Table CREATE TABLE PERSON (NAME CHARACTER (20) NOT NULL PRIMARY KEY (NAME) ) CREATE TABLE CHILD (NAME CHARACTER (20) NOT NULL STA TIC,CHILDNAME CHARACTER (20),PRIMARY KEY (NAME, CHILDNAME) ) CREATE VIEW PERSON_SET AS SELECT * FROM PERSON ORDER BY: NAME CREATE VIEW PERSON_SET AS SELECT * FROM PERSON --ORDER BY: NAME

80 Using the Relational Design Center Utility In the preceding example, SQL constructs for the DASDL occurring item and embedded data set are nearly identical. The only difference is that the number of rows in the CHILD table for the occurring item is limited to 10 for each master row. The number of rows in the CHILD table for the embedded data set is unlimited. In both cases, the NAME column is the primary key and is copied as the foreign key. Queries for the Occurring Item In the following example, a query to look at the name of Fred s fifth child might be SELECT CHILD FROM CHILD WHERE CHILD_INX = 5 AND NAME = Fred SQL recognizes that the NAME column is the foreign key link to the master record and it optimizes accordingly. Any query on an embedded table that does not have a selection condition on the foreign key searches sequentially through all the master table records in the database. A query to insert into the CHILD table a sixth child for Fred might be as follows: INSERT INTO CHILD (CHILD, CHILD-INX, NAME) VALUES ( ETHEL, 6, FRED ) A query to modify Fred s fourth child s name might be as follows: UPDATE CHILD SET CHILD = Diane WHERE NAME = Fred AND CHILD_INX = 4 In the occurring item example, a query to look at the third child for all persons might be as follows: SELECT CHILD FROM CHILD WHERE CHILD_INX = 3 In the embedded table example, a query to find all persons who have a child with the same name as the parent might be as follows: SELECT PERSON.NAME FROM CHILD, PERSON WHERE PERSON.NAME = CHILD.CHILD PERSON_SET appears as an index in the Enterprise Database Server options of the SQL description. PERSON_SET is still in the database and is available to the SQL query optimizer to improve the performance of queries

81 Using the Relational Design Center Utility If the PERSON_SET index is declared so that duplicates are allowed in the DASDL description, and if no primary key is specified, then the Relational Design Center models the PERSON data set with the following SQL constructs: DASDL Example DASDL Occurring Item PERSON DATA SET (NAME ALPHA(20); CHILD ALPHA(20) OCCURS 10 TIMES); PERSON-SET SET OF PERSON KEY NAME DUPLICATES; DASDL Embedded Data Set PERSON DATA SET (NAME ALPHA(20); CHILD DATA SET (CHILDNAME ALPHA (20))); PERSON-SET SET OF PERSON KEY NAME DUPLICATES; SQL Example SQL Occurring Table CREATE TABLE PERSON (NAME CHARACTER (20) NOT NULL) CREATE VIEW PERSON_SET AS SELECT * FROM PERSON --ORDER BY: NAME SQL Embedded Table CREATE TABLE PERSON (NAME CHAR(20) NOT NULL) CREATE VIEW PERSON_SET AS SELECT * FROM PERSON --ORDER BY: NAME Because the PERSON data set does not have a suitable primary key, CHILD must be ignored. The following examples illustrate how a DASDL occurring item embedded in another occurring item is modeled in SQL: DASDL Example STORE-SALES DATA SET (STORE-NUM NUMBER (4) REQUIRED; SALESPERSON GROUP (NAME ALPHA (20); MONTHLY-SALES NUMBER (5,2) OCCURS 12 TIMES ) OCCURS 7 TIMES ); STORES SET OF STORE-SALES KEY IS STORE-NUM NO DUPLICATES;

82 Using the Relational Design Center Utility SQL Example CREATE TABLE STORE_SALES (STORE_NUM NUMERIC (4) NOT NULL,PRIMARY KEY (STORE_NUM) ) CREATE TABLE SALESPERSON (STORE_NUM NUMERIC (4) NOT NULL STATIC,NAME CHARACTER (20),SALESPERSON_INX INTEGER STATIC,PRIMARY KEY (STORE_NUM, SALESPERSONS_INX),CONSTRAINT SALESPERSON_CHECK CHECK (SALESPERSON_INX >= 1 AND SALESPERSON_INX <= 7) ) CREATE TABLE MONTHLY_SALES (STORE_NUM NUMERIC (4) NOT NULL STATIC,SALESPERSON_INX INTEGER NOT NULL STATIC,MONTHLY_SALES NUMERIC (5,2),MONTHLY_SALES_INX INTEGER STATIC,PRIMARY KEY (STORE_NUM, SALESPERSON_INX, MONTHLY_SALES_INX),CONSTRAINT MONTHLY_SALES_CHECK CHECK (MONTHLY_SALES_INX >= 1 AND MONTHLY_SALES_INX <= 12) ) CREATE VIEW STORES AS SELECT * FROM STORE_SALES --ORDER BY: STORE_NUM A query to look at the May sales for the first salesperson of all stores might be as follows: SELECT MONTHLY_SALES FROM MONTHLY_SALES WHERE MONTHLY_SALES_INX = 5 AND SALESPERSON_INX = 1 A query to find those salespersons who made more than $100 in June at store 2 might be as follows: SELECT NAME FROM SALESPERSON, MONTHLY_SALES WHERE MONTHLY_SALES > 100 AND MONTHLY_SALES_INX = 6 AND SALESPERSON.STORE_NUM = 2 AND (SALESPERSON.STORE_NUM = MONTHLY_SALES.STORE_NUM AND SALESPERSON.SALESPERSON_INX = MONTHLY_SALES.SALESPERSON_INX)

83 Using the Relational Design Center Utility The following is the same example except one of the occurring items is changed to an embedded data set. The check constraint on MONTHLY_SALES_INX limits the number of entries but does not limit the number of salespersons allowed. DASDL Example STORE-SALES DATA SET (STORE-NUM NUMBER (4) REQUIRED ;SALESPERSON DATA SET (NAME ALPHA (20) ;MONTHLY-SALES NUMBER (5,2) OCCURS 12 TIMES ) ;PERSONS SET OF SALESPERSON KEY NAME ); STORES SET OF STORE-SALES KEY STORE-NUM NO DUPLICATES; SQL Example CREATE TABLE STORE_SALES (STORE_NUM NUMERIC (4) NOT NULL,PRIMARY KEY (STORE_NUM) ) CREATE TABLE SALESPERSON (STORE_NUM,NAME NUMERIC (4) NOT NULL STATIC CHARACTER (20) NOT NULL,PRIMARY KEY (STORE_NUM, NAME) ) CREATE TABLE MONTHLY_SALES (MONTHLY_SALES_INX INTEGER STATIC,STORE_NUM NUMERIC (4) NOT NULL STATIC,NAME CHARACTER (20) NOT NULL STATIC,MONTHLY_SALES NUMERIC (5,2),PRIMARY KEY (STORE_NUM, NAME, MONTHLY_SALES_INX),CONSTRAINT MONTHLY_SALE_CHECK CHECK (MONTHLY_SALES_INX >= 1 AND MONTHLY_SALES_INX <= 12) ) CREATE VIEW STORES AS SELECT * FROM STORE_SALES --ORDER BY: STORE_NUM The default rules described under Disjoint Data Set Defaults earlier in this section also apply to embedded data sets

84 Using the Relational Design Center Utility Initial Values Enterprise Database Server initial values (global defaults or local specifications) cause an anomaly from the SQL viewpoint when applied to occurring items. The Relational Design Center creates a new embedded table for each occurring item. When a Enterprise Database Server record is created and an occurring item has an initial value specification or inherits an initial value from a global default initial value, all occurrences of the item are initialized to the same value. Therefore, a maximum number of occurring rows are created when the master row is created. In addition, all the rows are automatically deleted when the master row is deleted. Inserting a New Row The anomaly appears when you attempt to insert a new row into one of these embedded tables after the master row is created. You must first delete a row of the embedded table before attempting to insert a new occurring row. If you fail to delete the applicable row, the number of rows exceeds the maximum number allowed. Exceeding the maximum limit causes the program to receive an exception and the insertion fails. If no global default initial value and no local initial value for an occurring item exist, then the embedded table rows are not created and this anomaly does not occur. Enterprise Database Server Boolean items, field items, and field bit items cannot have null values. The system assigns default initial values to these items. (For a table of default initial values, refer to the Data and Structure Definition Language (DASDL) Programming Reference Manual.) Once the master row is created, all the occurring item rows that are themselves one of these types, or that contain one of these types, are also created. In addition, these rows can be deleted only by deleting their master row

85 Using the Relational Design Center Utility Set and Access Defaults as Indexes Enterprise Database Server sets and accesses are mapped by the Relational Design Center as follows: Sets and accesses spanning disjoint data sets are modeled as indexes of the SQL table corresponding to the spanned data set. The key or keys of the set or the access are the key or keys of the SQL index. Key data are not modeled. Sets and accesses spanning embedded data sets are not modeled. All physical set organizations are modeled, except for the following set organization types: Unordered list Bit vector SQL indexes can have internationalized keys. Set and Subset Defaults as Views Disjoint sets and automatic subsets are modeled as SQL views of the base tables that represent the Enterprise Database Server data sets spanned by the set or subset. During updates to the set or subset-mapped view, the Relational Design Center alters the appropriate base table. These views may be used only to select or update a row. Manual subsets, embedded subsets, bit vector subsets, and unordered list subsets are not modeled in SQL. Data Item Defaults Simple data items are modeled as described in the following table. Enterprise Database Server Data Item Type SQL Column Type Notes AGGREGATE(i) Numeric(i) Read-only AGGREGATE(i,j) Numeric(i,j) Read-only AGGREGATE(Si) Numeric(i) Read-only AGGREGATE(Si,j) Numeric(i,j) Read-only ALPHA(n) ALPHA(n) Character(n) of EBCDIC Character(n) varying When used with USAGE EBCDIC, the ALPHA data items with a specified ccsversion are type CHAR based on the specified ccsversion. When used with SIZE VARYING WITH, the ALPHA data items with a specified ccsversion are type CHAR based on the specified ccsversion

86 Using the Relational Design Center Utility Enterprise Database Server Data Item Type SQL Column Type Notes BOOLEAN Integer Never null. COUNT Integer Read-only FIELD(n), n <= 39 Integer Defines an inherent verification, which is reflected in the schema, from the size of FIELD data items. For example, a FIELD(4) data item is capable of holding only the numbers 0 to 15. The Relational Design Center automatically defines a verify condition for the data item that checks that the value assigned to the data item falls between 0 and 15, inclusive. FIELD(n), n > 39 Real FIELD data items do not support a true REAL type; therefore, they are READONLY. FIELD of n BOOLEANS FILLER GROUP n integers Not modeled Not separately modeled unless occurring Never null. NUMBER(i) Numeric(i) Always signed. NUMBER(i,j) Numeric(i,j) Always signed. NUMBER(Si) Numeric(i) Always signed. NUMBER(Si,j) Numeric(i,j) Always signed. POPULATION Integer Read-only REAL REAL(i) Real Integer REAL(i,j) Numeric(i,j) Always signed. REAL(Si) Integer REAL(Si,j) Numeric(i,j) Always signed. RECORD SERIAL NUMBER RECORD TYPE Real Integer This data type is only modeled if the record serial number (RSN) is explicitly declared in the DASDL. Read-only The data item options REQUIRED and INITIALVALUE are modeled in SQL as NOT NULL and DEFAULT column constraints, respectively

87 Using the Relational Design Center Utility Link Defaults The Relational Design Center does not model links in SQL. Group Defaults Enterprise Database Server groups are modeled in SQL according to the following rules and default mappings: Occurring groups are modeled as separate tables. For more information, see Embedded Data Set and Occurring Item Defaults earlier in this section. Nonoccurring groups are not modeled. However, all nonoccurring, nongroup items contained in the group are modeled as columns in the containing table. Nonoccurring items contained in nested nonoccurring groups are also modeled as columns in the containing table. Occurring items in nonoccurring groups are modeled as separate tables. For more information, see Embedded Data Set and Occurring Item Defaults earlier in this section. Physical Option Defaults The Relational Design Center does not change the previously defined physical options for your database and data items. Restart Data Set Defaults The restart data set declared in the Enterprise Database Server database is modeled as an SQL table in the Relational Design Center description, but it is not implicitly used in SQL as it is in Enterprise Database Server. Therefore, SQL applications that need to use the restart data set require different handling to work with SQL and the Relational Design Center. The application must explicitly modify the table that models the restart data set while in transaction state. When the application restarts, the contents of the table that models the restart data set reflect the data present at the end of the last completed transaction. You can suppress the restart data set by using the Ignore option. SQL Referential Integrity Constraints In SQL, you can set referential integrity constraints to ensure that the information contained in one or more columns of one table is consistent with the information contained in other columns of the same table and in other tables. The basic concept in referential integrity is that you designate one or more columns in the referencing table as a foreign key. Items including the CCSVERSION option can also be designated as foreign keys. When a record is inserted, updated, or modified, the foreign key is then checked against a primary key in the referenced table. The number of the columns designated as a foreign key in the referencing table must match the number of the columns you designate as a primary key in the referenced table. Also, the data

88 Using the Relational Design Center Utility types of the columns designated as a foreign key must be compatible with the data types of the columns designated as a primary key. Even though a foreign key can point to only one primary key, multiple foreign keys can point to the same primary key. If the selected items do not fit the preceding conditions, you cannot use the items to form an SQL referential integrity constraint. Note: Native Enterprise Database Server applications are not affected by referential integrity constraints added to an existing Enterprise Database Server database using Relational Design Center. If you add referential constraints to an Enterprise Database Server database through the Relational Design Center, the enforcement only occurs when updates, deletes, or inserts are executed through SQL statements. This might result in inconsistent data for databases updated by non-sql applications. Primary Keys and Foreign Keys An example of a primary key is an employee number used to uniquely identify an employee in a data set named EMPLOYEE. An example of a foreign key is an employee number in another structure such as PROJECT. By defining the employee number as the key in two sets that refer to the EMPLOYEE and PROJECT data sets, you can set up a logical linking mechanism. This linking mechanism enables you to traverse various data sets through the use of one data item. You can even use multiple items to set up a single logical linking mechanism. If a data set does not have an obvious candidate for a primary key (that is, if the data set does not have an index with NO DUPLICATES specified), and if that data set contains occurring or embedded data, the occurring items and embedded data are not available through SQL. Date Construct Combine one or more Enterprise Database Server items using a specified format to create a virtual SQL column of type Date. A name is required for each date column defined as type Date. This name is used in a query specification to access the information as a date. A date can be used anywhere a column can be used. Single-Field Date The single-field date is based on one Enterprise Database Server item that is treated as an SQL-92 date. This item is specified according to one of the following formats: YYMMDD MMDDYY DDMMYY YYDDD DDDYY YYYYMMDD MMDDYYYY

89 Using the Relational Design Center Utility DDMMYYYY YYYYDDD DDDYYYY DDDDDD If the Enterprise Database Server item is of type ALPHA or NUMBER, its length must match the width of the chosen date format. If the type is REAL or FIELD, the item is assumed to contain an n-digit integer where n is the length of the chosen date format. For type FIELD, the length must be long enough to handle the chosen date format. Multi-field Date The multi-field date is based on two or three Enterprise Database Server items. The two-item date represents the year and a 3-digit day. The three-item date represents the year, month, and day. The items must be of type ALPHA or NUMBER. The year item must have a length of 2 or 4. The month item must have a length of 2. The day item must have a length of 2 if a month item is specified or a length of 3 if a month item is not specified. Determining the Century You can define the century for each 2-digit year mapping. You specify a base year that indicates which years belong to which century for a particular date. For example, If the base year is 57, then 57 through 99 are interpreted as 1957 through 1999 and 00 through 56 are interpreted as 2000 through If the base year is 1900, then 00 through 99 are interpreted as 1900 through If the base year is 2129, then 29 through 99 are interpreted as 2129 through 2199 and 0 through 28 are interpreted as 2200 through If a base year is not specified, 1900 is the default base year. Caution When information is stored into a date that is based on a 2-digit year, the century information is not stored. It is derived using the base year when the date is retrieved. This might cause a date stored as to be retrieved as depending on the specified base year. User Access All items mapped to a date have an access type of read-only. This read-only access prevents users from updating both the virtual date value as well as the underlying items. To prevent viewing the underlying items as columns, mark the items using the Ignore option

90 Using the Relational Design Center Utility Primary Key Security An item mapped as a date cannot be used in the specification of relationships or in the primary key. A key with an item mapped to a date is not chosen as the default primary key. The Relational Design Center fully supports data access security by usercode to the row and column levels. This security enables you to control who can see specific tables, rows, and columns when using SQL interfaces. You can define security in the Relational Design Center using either SQL views or grants. Grants and views are added to the SQL description through the Relational Design Center. The SQL option in the Relational Design Center is the default mode of operations. This mode enables the definition of grants and views. For more information about system security, refer to the Security Administration Guide. SQL Security Constructs If no explicit security is defined, access rights are as defined by the guard file specified for the physical database. If there is no guard file for the physical database, all users are granted full access to the entire database, including any defined views. Once you specify the first grant definition, access to data is not allowed except where the access privileges have been explicitly granted. You can define views and grants for items mapped by default as well as for items created with additional semantics. The Relational Design Center provides item and record subsystem-level security through the SQL constructs of views and grants. When you enable SQL access to Enterprise Database Server databases using the Relational Design Center, you can specify appropriate security using the views and grants feature. The SQL database entities listed in the following table are referred to generically as items. Enterprise Database Server Entity Data set Set or subset Item SQL Entity Table View Column For SQL, the authorization identifier for the database is assumed to be the database name. For more information about SQL authorization identifiers, refer to the SQL Query Processor Programming Guide

91 Using the Relational Design Center Utility View Construct A view is a table that is not physically stored, but instead is derived from the execution of a query. A view is a logical construct created from information contained in one or more tables or previously defined views. The rows, columns, and data values found in a view are derived from rows, columns, and data values in existing tables or previously defined views. The following lists some of the benefits of using views: Simplifies tables for a specific user. Information not pertinent to a specific user is shielded from the user. Limits for security purposes the content of data sets mapped as tables. Restricted information is viewed only by users with rights to the information. When used with SELECT statements, specifies a range of acceptable values. Views are defined through the Relational Design Center using the Views node. A view defined for a database processed through the Relational Design Center behaves exactly like a view that is defined for any relational database. The Views input form in the Relational Design Center enables you to specify a name for the view, the column names for the view, and the SQL SELECT query that defines the data to be returned when the view is accessed. SQL views correspond to Enterprise Database Server remaps. Both the view and the remap enable the database administrator to specify alternative views of the physical database files or tables. One significant advantage of the SQL views over Enterprise Database Server remaps is that a remap always performs a linear search if the remap is defined to eliminate records. In contrast, if the view definition eliminates records because the SQL query has a WHERE condition that leaves out some records from the base table, the query optimizer uses indexes where possible, which enhances performance. Grant Construct A grant defines the actions specific users can perform against a specific table or view. A grant is defined through the Relational Design Center using the Grants node. The Grants input form in the Relational Design Center enables you to specify a name for the grant, the list of allowed verbs, the table or view to which the grant refers, and a list of usercodes that receive the defined access rights. You can define a single grant that refers to all tables and views and define a grant that enables all usercodes to access all views and tables

92 Using the Relational Design Center Utility Working with Servers You can perform the following server-related tasks using the Relational Design Center: Adding a server Removing a server Importing a relational schema Creating an SQL database Adding a Server Perform the following steps to add a server to the tree view: 1. From the tree view, right-click the ClearPath Servers node, and click Add Server. The Add New Server dialog box appears. Note: You can also click Add Server on the Action menu. 2. Type the appropriate credentials for the server you want to add and click Add Server. The server is added to the tree view. 3. Right-click the server and perform one of the following actions: Removing a Server Import a relational schema of a database. Create an SQL database. Perform the following steps to remove a server to the tree view: 1. From the tree view, right-click the server you want to remove, and click Remove Server. The Confirm Server Removal dialog box appears. 2. Click Yes. The server is deleted from the tree view

93 Using the Relational Design Center Utility Importing a Relational Schema The following lists factors you should consider when completing the Import Relational Schema dialog box to import a relational schema: The database name you enter must include the location of the Enterprise Database Server control file. Enter the database name in the format (<usercode>)<database name> ON <pack name>. To import a logical database, enter the database name in the format <logical database name> OF (<usercode>)<database name> ON <pack name>. The database description file name is optional. If you decide not to specify a database description file, the Relational Design Center assumes that the description file is located under the usercode and pack name specified in the Database Name box. If you do not specify a usercode and pack name in the Database Name box, the Relational Design Center assumes that the description file is located under the usercode and pack name of the person attempting to access the database. To enable SQL queries to update the database, select the Read-only option. To authenticate log-in credentials using your ClearPath MCP usercode and password, select the MCP option in the Authentication list and type your log-in credentials. To authenticate log-in credentials using Kerberos credentials, select the Kerberos option in the Authentication list. To encrypt your Kerberos credentials, select the Encryption option in the Encryption list. The usercode can consist of usercode, accesscode, and chargecode combinations as shown in the following syntax. Accesscode and chargecode requirements are defined by your system administrator. <usercode> /<accesscode> /<chargecode> /<accesscode>/<chargecode> The password can consist of a password and an optional accesscode password as shown in the following syntax: <password> /<accesscode password> Perform the following steps to create a relational schema of an Enterprise Database Server database or to import a schema of an SQL database that has already been created. 1. From the tree view, right-click the server that contains the database you want to map, and click Import Relational Schema. The Import Relational Schema dialog box appears. 2. Enter the appropriate information in the text boxes

94 Using the Relational Design Center Utility 3. Click Import. The Relational Design Center attempts to create a relational map of the database. If the create operation is successful, the database is added to the tree view along with its properties in the properties view. The results of the operation appear in the output view. When you exit the Relational Design Center, the structure of the tree view structure is preserved. After you open the database, the Relational Design Center checks the database timestamp to determine if an update mapping is required. If a mapping is required, the mapping is automatically updated. If the Relational Design Center determines that an update mapping is not required, the data items for the database are loaded into the tree view. Creating an SQL Database You can generate a database based on an SQL schema. The SQL Query Processor uses the Enterprise Database Server to manage the data so that the audit, backup, and recovery features of Enterprise Database Server are available. Generation, update, and reorganization are managed through the Relational Design Center. Backup and recovery are managed through the Database Operations Center. Once the database is generated, database access is the same as for an Enterprise Database Server database that was mapped to an SQL model. Perform the following steps to create an SQL database: 1. From the tree view, right-click the server in which you want to create the database, and click Create SQL Database. The Create SQL Database dialog box appears. 2. Type a name in the Database Title box. The database title can be a fully qualified name containing a usercode, database name, and pack family, for example, (USERCODE)DATABASENAME ON PACK. You must provide at least a database name. If you omit the usercode or pack family, they default to the usercode and pack family associated with the usercode used to log into the ClearPath MCP server. Note: Ensure that the database title is unique. If a database with the same name already exists on the ClearPath MCP server under your default pack family, the existing database is overwritten. The Relational Design Center checks for the existence of a database control file under your default pack family. If a control file is not found, the SQL database is created with the given title. If the database control file exists for the given SQL database title, the Relational Design Center returns a warning message. 3. Click Browse. The Open dialog box appears

95 Using the Relational Design Center Utility 4. Navigate to the database description file and select the file. The path and file name appear in the Database Description File Name box. Note: You can also type the location and name of the database description file in the Database Description File Name box. 5. Type the pack family on which the SQL database is to be created in the MCP Pack Family box. 6. Click Create. The Open Database dialog box appears. 7. Type your log-in credentials and click OK. Notes: To authenticate log-in credentials using your ClearPath MCP usercode and password, select the MCP option in the Authentication list and type your log-in credentials. To authenticate log-in credentials using Kerberos credentials, select the Kerberos option in the Authentication list. To encrypt your Kerberos credentials, select the Encryption option in the Encryption list. If the create operation is successful, the database is added to the tree view along with its properties in the properties view. The results of the operation appear in the output view

96 Using the Relational Design Center Utility Working with Databases You can work with the following database types in the Relational Design Center: Enterprise Database Server SQL An Enterprise Database Server database is based upon an Enterprise Database Server schema whereas an SQL database is based upon an SQL schema. You can perform the following database-related tasks using the Relational Design Center: Opening a database Removing a database Refreshing a database if you make a database update Restoring a database Getting SQL schemas Saving the modifications you make to a database schema Loading an SQL schema Applying saved database modifications and continuing to add modifications, or applying all schema modifications Modifying an SQL database Opening a Database To work with a database in the Relational Design Center, it must first be opened. Opening a database enables you to maintain the tables, grants, and views of the database. If an Enterprise Database Server database is upgraded or reorganized, the open database operation automatically creates a new MCP server SQL catalog that is compatible with the Enterprise Database Server database. Perform the following steps to open a database: 1. From the tree view, double-click the server that contains the database with which you want to work. The tree view expands to expose the underlying databases. 2. Double-click the database with which you want to work. The Open Database dialog box appears. 3. Type your log-in credentials and click Open

97 Using the Relational Design Center Utility Notes: To authenticate log-in credentials using your ClearPath MCP usercode and password, select the MCP option in the Authentication list and type your log-in credentials. To authenticate log-in credentials using Kerberos credentials, select the Kerberos option in the Authentication list. To encrypt your Kerberos credentials, select the Encryption option in the Encryption list. 4. Proceed with your work as desired. Removing a Database Perform the following steps to remove a database from the tree view: 1. From the tree view, right-click the database you want to delete, and click Remove SQL Mapping. The Confirm Removal of Database Mapping dialog box appears. 2. Click Yes. The database is removed from the tree view. Note: If you decide you want to place the database back into the tree view, you must import the database schema. Refer to Importing a Relational Schema earlier in this guide for details. Refreshing a Database Use the refresh database operation to cancel all local changes to grants, views, or fields you have made (saved or unsaved) since the last time you applied schema modifications or imported a relational schema. The refresh database operation removes all unapplied schema modifications and resets the current Relational Design Center session state back to the last Apply Schema Modifications. Note: The refresh database operation is available only to an Enterprise Database Server database and only after the database is opened. The refresh database operation is not available to SQL schema-generated databases. Perform the following steps to refresh a database in the tree view: 1. From the tree view, right-click the database you want to refresh, and click Refresh Database. The Refresh Database Status dialog box appears indicating that a refresh operation was performed. 2. Click OK

98 Using the Relational Design Center Utility Restoring a Database The restore database operation removes all applied and unapplied schema modifications, and resets the current Relational Design Center session back to a schema that matches the current Enterprise Database Server database. The MCP server SQL catalog is also restored to a state that matches the current Enterprise Database Server database. Notes: The restore database operation is available only to an Enterprise Database Server database and only after the database is opened. The restore database operation is not available to SQL schema-generated databases. Exercise caution when using the restore database operation as it removes all grants, views, and field changes that were already applied and unapplied. Perform the following steps to restore a database in the tree view: 1. From the tree view, right-click the database you want to restore, and click Restore Database. The Restore Database Status dialog box appears indicating that a restore operation was performed. 2. Click OK. Getting the SQL Schema After opening a database, you can view the SQL schema file through the output view of the Relational Design Center window. From the tree view, right-click the database for which you want to obtain the SQL schema, and click Get SQL Schema. The Relational Design Center attempts to retrieve the schema file. If the schema file is successfully retrieved, the contents of the file appear in the output view. Saving the Schema The Relational Design Center enables you to modify a database schema and save those modifications so that you can apply them at a later time. To save the changes you made to a database schema, right-click the database on which you made changes and click Save Schema. Note: If you make changes to a database and attempt to exit the utility without saving the schema, the Relation Design Center utility prompts you to save or discard the schema modifications

99 Using the Relational Design Center Utility Loading a Schema The Relational Design Center enables you to modify a database schema, save modifications, and load the modifications at a later time. Perform the following steps to load previously saved schema modifications to a database: 1. From the tree view, right-click the database on which you load the schema, and click Load Schema. The Load Schema Status dialog box appears indicating that all schema modifications are loaded for the database. 2. Click OK. Applying Schema Modifications After you have made all the necessary modifications to the database schema, you can apply the changes to the database. Perform the following steps to apply schema changes to a database: 1. Open the database for which you want to apply schema modifications. Note: If any saved schema modifications exists for the database, you must load them by clicking Load Schema from an Action menu. 2. Right-click the database node and click Apply Schema Modifications. The schema modifications are uploaded to the server and applied to the database. Modifying an SQL Database Perform the following steps to modify an SQL database: 1. From the tree view, expand the server containing the database you want to modify. Note: If the database is not yet open, click Open Database to open the database for modification. 2. Right-click the database and click Modify SQL Database. The Modify SQL Database dialog box appears. 3. In the DDL File Name box, click Browse, navigate to the database description file, and select the file. The path and file name appear in the DDL File Name box. Note: You can also type the location and name of the database description file in the Database Description File Name box

100 Using the Relational Design Center Utility 4. Click Modify. The Modify Database Status message box appears indicating that the changes are complete. Note: The modification process closed the database. 5. Click OK. 6. From the tree view, right-click the database and click Open Database. The Open Database dialog box appears. 7. Log in with the appropriate credentials and click OK. A message appears indicating that the database has been opened. 8. Continue with your work

101 Using the Relational Design Center Utility Working with Database Schemas The following tasks can be performed only on an Enterprise Database Server database that has been imported into the Relational Design Center: Modifying data sets Modifying occurring items Modifying variable-format items Modifying indexes (sets and subsets) Modifying data items Assigning access rights to database structures Modifying access rights for database structures Creating and modifying SQL dates Creating and modifying integrity constraints Creating and modifying views Note: The preceding tasks apply only to Enterprise Database Server databases that are mapped to SQL. Modifying Data Sets Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify data sets: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database you want to modify, expand the Tables node, and select the appropriate table. 3. Double-click the value for the Alias Table Name property and type the name used for the SQL table represented by the data set. The alias name can be up to 30 characters long. The alias for the global data set is GLOBALDATA. 4. Select the Ignore check box to make the data set inaccessible to SQL queries. Otherwise, leave the check box cleared

102 Using the Relational Design Center Utility Modifying Occurring Items Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify occurring items: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database you want to modify, and expand the Tables node representing each data set in the database. 3. Expand the Occurring Items node to display each occurring item or group. An occurring item or an occurring group appears as a separate, normalized table to SQL. 4. From the tree view, select the name of the desired occurring item or group. 5. Double-click the value for the Occurring Item Table Name property, and type a name to identify the SQL table that contains the occurring item or occurring group. 6. (Optional) Double-click the value for the Occurrence Index Column Name property, and type a name for the column representing the occurrence index for the occurring item table. If you do not specify a name, the column name is the name of the occurring item or occurring group table with a suffix of _INX. 7. If you want the occurrence index to be a required column and a not null column, select the Occurrence Index Is REQUIRED check box. 8. Select the Ignore check box to make the occurring item or occurring group accessible to SQL queries. Otherwise, leave the check box cleared. Modifying Variable-Format Items A variable-format data set is viewed by SQL as several tables. A separate table appears for each variable-format part. Each of these tables contains the columns of the fixed part and the columns of the appropriate variable-format part. In addition, another table is mapped: the table that represents the records having no variable-format part specified (record type equals 0). Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify the schema for a variable-format item: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database you want to modify, and expand the Tables node representing each data set in the database. 3. Expand the Variable Format Items node to display each variable-format part and its properties

103 Using the Relational Design Center Utility 4. Select the node representing the desired variable-format item. The properties or semantics associated with the variable-format item appears in the properties view. The following schema properties associated with the variable-format item appear in the properties view. 5. Double-click the value for the Alias Table Name property, and type the name used for the SQL table represented by the variable-format part. The alias name can be up to 30 characters long. 6. Select the Ignore check box to make the variable-format item accessible to SQL queries. Otherwise, leave the check box cleared. Modifying Indexes (Sets and Subsets) Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify indexes (set and subsets): 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database you want to modify, and expand the Tables node representing each data set in the database. 3. Expand the Indexes node to display the indices associated with the table. 4. Select the index you want to modify. The following schema properties associated with the index appear in the properties view. 5. Double-click the value for the Alias Index Name property and type the name used for the SQL table represented by the set or subset. The alias name can be up to 30 characters long. 6. Select the Ignore check box to make the index accessible to SQL queries. Otherwise, leave the check box cleared. Modifying Data Items (Columns and Primary Keys) Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify data items: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database you want to modify, and expand the Tables node representing a data set in the database. 3. Expand the Columns node to display the data items associated with the table. 4. Select the data item you want to modify. 5. Double-click the value for the Alias Column Name property or Alias Primary Key Name property, and type the name used for the SQL table represented by the data item. The alias name can be up to 30 characters long

104 Using the Relational Design Center Utility 6. Select the Ignore check box to make the data item accessible to SQL queries. Otherwise, leave the check box cleared. Note: Occurring items and variable-format items are also mapped as tables. They can also contain columns. To access the columns for these tables, expand the node representing the occurring item table or variable-format item table. Assigning Access Rights to Database Structures Grants give specific users access rights to specific database structures. If no grants are defined, all structures are available to all users. Once any grants have been defined, only access that is explicitly given by a grant definition is allowed. Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to assign access rights to database structures: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database for which you want to create the grant. 3. Click the Grants node. An input form appears in the properties view. 4. Type a name for the grant in the Grant Name box. 5. Identify the tables or views on which you want to grant privileges by selecting one of the following in the Grant Privileges On group: Select the All Tables and Views check box to apply the access rights defined by the grant to all tables and views in the database. Select a table or view from the This Table or View list to apply the access rights defined by the grant to the specific table or view in the database. 6. Identify the SQL actions that can be performed on the tables or views by selecting the relevant check boxes in the Grant SQL Actions group. Select This action enables you to initiate a SELECT statement on the table or view defined by the grant. Insert This action enables you to initiate an INSERT statement on the table or view defined by the grant. Update This action enables you to initiate an UPDATE statement on the table or view defined by the grant. Delete This action enables you to initiate a DELETE statement on the table or view defined by the grant

105 Using the Relational Design Center Utility 7. Identify the users to which to grant privileges by selecting one of the following in the Grant Privileges To Users group. Select Public to grant the privileges to all users. Select Specific Usercodes to grant the privileges to specific users. The text box is enabled. Type the usercodes (without parentheses and separated by commas) to which you want to grant privileges. 8. Click Store. The grant is added to the tree view and assumes the grant state of Unapplied Grant. This means that the grant is not yet incorporated into the SQL catalog. 9. Follow the steps outlined in Apply Schema Modifications earlier in this section to incorporate this change into the SQL catalog. After the change is incorporated into the SQL catalog, the grant state is displayed as Applied Grant. Modifying Access Rights for Database Structures Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify assign access rights for database structures: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database that contains the grant you want to modify. 3. Click the Grants node. 4. Select the grant that you want to modify. The grant definition appears in the properties view. 5. Make the necessary changes to the grant definition, and click Store. The grant is updated and assumes one of the following grant states. Unapplied Grant Unapplied Modification to an Applied Grant Unapplied Delete to an Applied Grant The preceding grant states mean that the change is not yet incorporated into the SQL catalog. 6. Follow the steps outlined in Apply Schema Modifications earlier in this section to incorporate this change into the SQL catalog. After the change is incorporated into the SQL catalog, the grant state is displayed as Applied Grant

106 Using the Relational Design Center Utility Creating SQL Dates Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to model a new set of dates for a data set: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the desired data set and select the Dates folder. An input form appears in the properties view. 3. Type a name for the date column in the Date Column Name box. The name is used to reference this column in SQL statements. 4. In the Date Format group, select the format that represents how the data in the Enterprise Database Server data item is actually formatted. 5. Depending on the date format selected, different input fields appear on the input form. The input form contains the Item Name list and the Base Year box if you select one of the following formats: 1-Item MMDDYY 1-Item YYMMDD 1-Item DDMMYY 1-Item DDDYY 1-Item YYYDD Select an item from the Item Name list that corresponds to the date. If the selected date format contains a 2-digit year, the Base Year box is enabled. The Base Year box displays the reference year from which to interpret the 2-digit year. For example, if the base year is 1957, the years from 57 through 99 are interpreted as 1957 to 1999, while the years from 00 through 56 are interpreted as 2000 through The input form contains only the Item Name list if you select one of the following formats: 1-Item MMDDYYYY 1-Item YYYYMMDD 1-Item DDMMYYYY 1-Item DDDYYYY 1-Item YYYYDDD Select an item from the Item Name list that corresponds to the date. The input form contains the Year Item list, Day Item list, and Base Year box if you select the 2-Item Date format. Select an item from the Year Item list that corresponds to the year. Select an item from the Day Item list that corresponds to the day. Specify a base year to use in the Base Year box

107 Using the Relational Design Center Utility The input form contains the Year Item list, Month Item list, Day Item list, and Base Year box if you select the 3-Item Date format. Select an item from the Year Item list that corresponds to the year. Select an item from the Month Item list that corresponds to the month. Select an item from the Day list that corresponds to the day. Specify a base year in the Base Year box or use the default value. 6. Click Store to create an SQL date. The date is added to the tree view immediately and the date is added to the database schema when you apply modifications to the database. Refer to Applying Schema Modifications earlier in this section for details. Modifying SQL Dates Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify an SQL date: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database that contains the date you want to modify. 3. Click the Dates node. The date definition appears in the properties view. 4. Make the necessary changes to the date definition, and click Store. The date is updated. You can later upload your modifications to the database on the ClearPath MCP server. Refer to Applying Schema Modifications earlier in this section. Creating Integrity Constraints Using integrity constraints, you can specify foreign keys in a referencing table that point to certain primary keys or other unique keys in a referenced table. Once the constraints are defined, the SQL Query Processor enforces referential integrity on any updates to the database using SQL interfaces. SQL updates do not leave dangling references to nonexistent records. In a relational referential integrity constraint, one or more foreign keys in the referencing table are checked against one or more primary keys in the referenced table. SQL ensures that the data contained in the foreign key columns of the referencing table are consistent with the data contained in the primary key columns of the referenced table. Note: Native Enterprise Database Server applications are not affected by referential integrity constraints added to an existing Enterprise Database Server database using Relational Design Center. If you add referential constraints to an Enterprise Database Server database through the Relational Design Center, the enforcement only occurs when update, delete, or insert actions are executed through SQL statements. This might result in inconsistent data for databases updated by non-sql applications

108 Using the Relational Design Center Utility Perform the following steps to create an integrity constraint for a table: Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database and expand the data set for which you want to create a constraint. 3. Click the Constraints node. An input form appears in the properties view. 4. Type a name for the constraint in the Referential Integrity Constraint Name box. 5. Select a foreign key for the referencing table from the Foreign Key Item list. If the table does not contain any foreign keys, the Foreign Key Item list is unavailable. 6. Select a table from the Referenced Table list. 7. Select a primary key from the Primary Key Item list. If the table does not contain any primary keys, the Primary Key Item is unavailable. 8. Click Add Key Pair to add the foreign key item and primary key item to the table. If more than one foreign key and primary key pair is required for the constraint, you can add additional key pairs by selecting the items from the appropriate list and then clicking Add Key Pair. If you want to remove a key pair from the constraint, select the appropriate key pair row from the table and click Delete Key Pair. 9. Click Store. The new constraint is added to the tree view immediately and the constraint is added to the database schema when you apply modifications to the database. Refer to Applying Schema Modifications earlier in this section for details. Modifying Integrity Constraints Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify an integrity constraint: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database and expand the data set that contains the constraint you want to modify. 3. Click the Constraints node. 4. Select the constraint you want to modify. The constraint definition appears in the properties view

109 Using the Relational Design Center Utility 5. Make the necessary changes to the constraint definition and click Store. The constraint is updated. You can later upload your modifications to the database on the ClearPath MCP server. Refer to Applying Schema Modifications earlier in this section. Creating SQL Views Views are similar to tables. That is, they contain rows, columns, and data values. The difference between tables and views is that tables are physically stored, whereas views are derived from the information stored in tables. Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to create an SQL view: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database for which you want to create the view. 3. Click the Views node. An input form appears in the properties view. 4. Type a name for the view in the View Name box. 5. Type the columns names (separated by commas) of a selected table in the Enter Column Names box. 6. Type a query statement in the SQL View Query box. 7. Click Store. The view is added to the tree view and assumes the view state of Unapplied View. This means that the view is not yet incorporated into the SQL catalog. 8. Follow the steps outlined in Apply Schema Modifications earlier in this section to incorporate this change into the SQL catalog. After the change is incorporated into the SQL catalog, the view state is displayed as Applied View. Modifying SQL Views Note: This task applies only to an Enterprise Database Server database that is mapped to SQL. Perform the following steps to modify a view: 1. From the tree view, expand the server containing the database you want to modify. 2. Expand the database that contains the view you want to modify. 3. Click the Views node. 4. Select the view you want to modify. The view definition appears in the properties view

110 Using the Relational Design Center Utility 5. Make the necessary changes to the view definition, and click Store. The view is updated and assumes one of the following view states. Unapplied View Unapplied Modification to an Applied View Unapplied Delete to an Applied View The preceding view states mean that the change is not yet incorporated into the SQL catalog. 6. Follow the steps outlined in Apply Schema Modifications earlier in this section to incorporate this change into the SQL catalog. After the change is incorporated into the SQL catalog, the view state is displayed as Applied View

111 Section 5 SQL Query Processor Server Administration The SQL Query Processor server provides a socket-based API to enable non-mcp based applications to access the SQL Query Processor CLI. The SQL Query Processor server uses the NA command protocol supported by Distributed System Services (DSS). This section discusses the following SQL Query Processor server administration topics: Configuring SQL Query Processor server resources Preparing a database to be a resource Controlling the SQL Query Processor server Automating SQL Query Processor server initialization Setting the SQL Query Processor server timeout intervals Obtaining SQL Query Processor server status Viewing log information on the server Viewing trace information on the server Retrieving dump files

112 Configuring SQL Query Processor Server Resources Configuring SQL Query Processor Server Resources What Is a Resource? When an SQL Query Processor user establishes a connection between an application and a data source in the MCP environment, the connection is not made to the data source directly. Between the workstation application and the physical data source is a resource. A resource is a logical identifier that maps a data source identifier to one or more physical databases. When an application using the SQL Query Processor software attaches to a resource, the system automatically routes instructions and data between the application and the physical data source or sources to which the resource is mapped. Whether a resource is mapped to one or several physical data sources is transparent to the application user. Resource Configuration Process You configure resources using the SQL Query Processor configuration control facility, which reads statements from the SQL Query Processor configuration file. These statements define the resources and their location. For more information on this file, see Section 6, SQL Query Processor Configuration Control Facility. For each resource needed, specify the following information in the SQL Query Processor configuration file: Definition of the data sources that are to be accessed Definition of a repository that can be used to locate the data sources (optional) Repository attributes of the database Mode in which the databases are to be accessed (that is, inquiry or update) Coded character set to use when transferring character data between the MCP environment and the workstation (optional)

113 Configuring SQL Query Processor Server Resources Modifying Resource Definitions During Processing The following steps enable you to alter the contents of the SQL Query Processor configuration file in the MCP environment while the system is running without affecting current users: 1. Edit the contents of the SQL Query Processor configuration file and add, change, or delete any resources. 2. Run SYSTEM/SQL/CONFIG to validate the contents of the file. For more information about the SQL Query Processor configuration file, refer to Section 6, SQL Query Processor Configuration Control Facility. Notes: Modifications made to a resource definition while the resource is in use do not take effect until you close, open, and reconnect to the data source. Deleting a resource does not automatically terminate an SQL Query Processor application using the deleted resource. The SQL Query Processor configuration control facility does not notify SQL Query Processor servers or users when resources have been added, changed, or deleted

114 Preparing a Database to Be a Resource Preparing a Database to Be a Resource The SQL Query Processor allows applications to communicate with resources in an MCP environment by using common interface routines and SQL to read data from multiple data sources. Because these applications use SQL, the database in the MCP environment must be prepared to process SQL queries. In addition, database security and configuration concerns must be addressed. The following table describes database preparation tasks to complete before using the SQL Query Processor software. Refer to the related documents identified in the table for more information on performing each task. Task Ensure that your data sources are SQL capable. SQL-capable data sources are Enterprise Database Server databases processed using the SQLVIEW command SQL databases Specify the following Enterprise Database Server software titles in the database schema to ensure that a database opens successfully: DMSUPPORT library Accessroutines Recovery Note: When the SQL Query Processor server opens a database, the MCP environment worker task inherits the user's family default as specified in the system user data file. If a guard file is used to provide security for the Enterprise Database Server database, provide the server task SYSTEM/SQL/WORKER with appropriate access to the physical database. Related Documents Relational Design Center Help (also Section 4 of this guide) SQL Query Processor Programming Guide Enterprise Database Server Getting Started and Installation Guide Security Administration Guide

115 Controlling the SQL Query Processor Server Controlling the SQL Query Processor Server The SQL Query Processor server provides a TCP/IP interface to the SQL Query Processor CLI. You can perform the following SQL Query Processor server tasks in the MCP environment: Start or stop the SQL Query Processor server. Obtain help information. Starting and Stopping the SQL Query Processor Server Use the following system command to start or stop the SQL Query Processor server in the MCP environment: NA DMSQL + QUIT NOW Starting the SQL Query Processor Server Use the NA DMSQL + command to initiate the SQL Query Processor server. The system displays the following message to indicate that the server is active: Initiation of the DSS "DMSQL" is being attempted. In addition, when the SQL Query Processor server is successfully initiated, a message such as the following appears in the system messages. You can view the system messages by using the SMSG (System Messages) command in Menu-Assisted Resource Control (MARC). DMSQL: INITIALIZED: VERSION: Stopping the SQL Query Processor Server Use the NA DMSQL command, the NA DMSQL QUIT NOW command, or the NA DMSQL QUIT command to terminate the SQL Query Processor server. The command that you use depends on the level of termination you want to occur for the SQL Query Processor server. Using the NA DMSQL or NA DMSQL QUIT NOW command causes an abrupt termination of the server regardless of whether there is any server activity. This termination stops all network connections to the SQL Query Processor; however, MCP-based applications accessing the SQL Query Processor continue to operate. The system displays the following message to indicate that the server is stopped: Termination of the DSS "DMSQL" is being attempted

116 Controlling the SQL Query Processor Server Using the NA DMSQL QUIT command causes the SQL Query Processor server to terminate only if no workers are active. If any worker is active, the system displays the following message to indicate that there continues to be server activity: QUIT DMSQL ignored; workers still active. If no workers are active, the system displays the following message to indicate that the SQL Query Processor server is stopped: DMSQL terminated In either case, when the SQL Query Processor server is successfully terminated, a message such as the following appears in the system messages. You can view the system messages by using the SMSG system command in MARC. DMSQL: TERMINATED: VERSION If the confirmation messages do not appear, check the system messages for any related messages. Also check the system waiting entries or system scheduled entries to ensure that no SQL Query Processor-related tasks are waiting or scheduled. Note: The version identifiers in the preceding messages are examples only. To determine version information, consult the system messages produced by the SQL Query Processor server installed on your system. Obtaining Help Information Use the following system command to obtain help information: NA DMSQL HELP + LOG QUIT STATUS TRACE Use the NA DMSQL HELP command to obtain help information for various DMSQL commands. Using the HELP command by itself displays help for all available commands, including those for showing SQL Query Processor server status and obtaining diagnostic information. If you want help information for a specific command, add the command name after the HELP keyword

117 Automating SQL Query Processor Server Initialization Automating SQL Query Processor Server Initialization The SQL Query Processor server is initiated using any one of the three following methods: Initiate the SQL Query Processor server using the ODT command NA DMSQL +. Include the INITIALIZE = TRUE specification when registering the DSS/REG file. Inclusion of this specification causes the SQL Query Processor server to initiate when a request for the SQL Query Processor service is received by the network. Include the RECOVERY = TRUE specification when registering the DSS/REG file. Inclusion of this specification causes the SQL Query Processor server to initiate when the DSS Router is initiated, such as after a halt/load. Creating the *DMSQL/SERVER/CONFIG File During the SQL Query Processor server initialization process, the server must be informed about the type of network connection between the MCP environment and the workstation. You provide this information to the server by creating a *DMSQL/SERVER/CONFIG file to automate server initiation. This network information file must be titled *DMSQL/SERVER/CONFIG, and it must reside on the same pack as the *SYSTEM/DMSQL/SERVER code file. Note: You can alter the location of the *DMSQL/SERVER/CONFIG file by using the WFL MODIFY command to change the family name of the file during installation. The following diagrams illustrate the syntax of the network and network access point (NAP) specifications that must be included in the *DMSQL/SERVER/CONFIG file: <network specification>, /1\ TCPIP <port number> : <TIMEOUT specification> /1\ COMPRESSION ON + OFF <TIMEOUT specification> <BLOCKEDTIMEOUT value> : <DIALOGCHECKINTERVAL value>

118 Automating SQL Query Processor Server Initialization The following table explains the elements of the syntax diagrams. Element TCPIP <port number> <BLOCKEDTIMEOUT value> <DIALOGCHECKINTERVAL value> COMPRESSION ON COMPRESSION OFF Definition Identifies the port number of the SQL Query Processor server if you are using a TCP/IP network. The default port number is Specifies the length of time, in minutes, that the connection between the workstation and the enterprise server stays open after the workstation has stopped responding to inactivity handshaking procedures. This value must be an integer. The BLOCKEDTIMEOUT value defaults to 10 minutes. Specifies the length of time, in minutes, that the enterprise server waits without any response from an attached system before it automatically invokes inactivity handshaking procedures. This value must be an integer. The DIALOGCHECKINTERVAL value defaults to 0, which indicates that the inactivity handshaking procedures are never invoked. Enables the use of the file compression feature. You can also use the + (plus) option in place of the ON option. Disables the use of the file compression feature. You can also use the (minus) option in place of the OFF option

119 Setting the SQL Query Processor Server Timeout Intervals Setting the SQL Query Processor Server Timeout Intervals The timeout interval for the SQL Query Processor server indicates the number of minutes the TCP/IP networking software must wait before closing (disconnecting) an idle TCP/IP dialog. An idle TCP/IP dialog is one where the client is not responding to the inactivity handshaking procedures of the server. As long as the client is responding to the handshaking procedures of the server, the connection cannot be automatically closed. The SQL Query Processor server timeout interval cannot be changed once the network connection is made. The default timeout interval is 10 minutes. To change the timeout value, enter the new timeout interval in minutes when the SQL Query Processor server is initiated. The following example shows a timeout value: TCPIP 1897:10:5 The number 10 indicates closing a connection after 10 minutes of being blocked. The number 5 indicates sending a confirmation every 5 minutes, and if there is no response, declaring the information blocked. This action then triggers the 10-minute wait before the connection closes

120 Obtaining SQL Query Processor Server Status Obtaining SQL Query Processor Server Status The server status report displays on your screen and contains a description of the current state of the server, the network, and the individual workers. Use the following system command to display the status of the SQL Query Processor server: NA DMSQL STATUS SHOW <worker ID> ALL <worker ID>, <mix number> <IP address> (<usercode>) The following table explains the elements of the syntax diagrams. Element STATUS or SHOW STATUS STATUS <worker ID> STATUS ALL or SHOW STATUS ALL Definition Shows global information about the server including the total number of connections. Shows detailed information about a specific worker. The worker can be specified by any of the following identifiers: Mix number IP address for TCP/IP (for example, ) Usercode under which the worker is running Each worker identifier must resolve to one worker. If a usercode with more than one worker is used, an error is reported. Obtains status information for all workers

121 Viewing Server Log Information in the MCP Environment Viewing Server Log Information in the MCP Environment The server log is used to capture significant events in an MCP environment. The server log is designed for continuous use and cannot be disabled. The volume of data captured is relatively small and the frequency of writes is low so that there is minimal impact on performance. Use the following system command to show log information in the MCP environment: NA DMSQL LOG RELEASE The following table explains the elements of the syntax diagram. Element Definition LOG LOG RELEASE Shows the location of the current log file. Closes the current log file and opens a new file. Identifying the Server Log The server log is written as a data file with 90-byte records, each containing one log record consisting of 90 characters of text. The name of the log file is DMSQL/LOG/<mix number>/<unique number>. The <mix number> parameter is the mix number of the server. When the SQL Query Processor server is initiated, the <unique number> parameter begins at 1 and is incremented by 1 in each new log file. The log file is created as a public file under the same usercode and family occupied by the server code file. The location is assigned when the SQL Query Processor server is installed. The system automatically closes the server log when it reaches 10,000 records and starts a new file. This action prevents the log file from becoming too large and enables you to remove older log files periodically. You can begin a new log file at any time by using the LOG RELEASE command

122 Viewing Server Log Information in the MCP Environment Understanding Server Log Contents The header of the server log includes the title, task numbers, session start date and time, server code file title, server version identifier, maximum number of workers supported, the requested maximum number of idle workers maintained, and the identifier for the earliest version of the driver that can be supported. The last line identifies the columns that follow the header. The following provides an example of header information for the server log file: DMSQL log for job 00939/0939 Wednesday, June 4, :58: Server (USER)SYSTEM/DMSQL/SERVER ON UI2. Version maximum Workers supported = 256 Server Internal Release no. = MM/DD HH:MM:SS(MIX#) A trailer provides the date and time at the end of the log session as shown in the following example: End of log Wednesday, June 4, :58: Other lines in the log each begin with a prefix containing the month and day, the time to the nearest second, and the mix number as shown in the following example: 06/04 12:58:06(0939) idle Worker #1 starting Static information, which is not provided in the header, is written to the log as procedures are completed so that the data is accessible. This information appears at various locations in the body of the log. The following is one such example: 06/04 12:58:06(0939) DMSQL_config file name: 06/04 12:58:06(0939) (USER)DMSQL/SERVER/CONFIG ON PACK Dynamic information about significant events is written to the log as the events occur. The following is an example: 06/04 12:58:06(0939) Worker #0 (USER)SYSTEM/SQL/WORKER ON PACK starting 06/04 12:58:06(0939) active Workers = 1, idle Workers = 1, total = 2 All error messages generated by the SQL Query Processor server that signal environmental errors (that is, database errors and warnings or SQL Query Processor server malfunctions) are written to the log as well as being sent to the SQL Query Processor provider for display

123 Viewing Trace Information on the Server Viewing Trace Information on the Server The server provides a trace facility that you can use to capture additional information during a session. This information helps you obtain a better understanding of the changing state of the server during a session. The captured information includes such data as SQL traffic and database calls as well as information that can be used to diagnose problems. Diagnostic Trace The Diagnostic trace provides information for all workers. For each worker, the trace information includes the dialog between the server and the driver as well as the SQL query text, the SQL engine calls, and the program flow trace. This information is used to assist in problem diagnosis at your site. If you encounter software problems, you might be asked to enable this trace to capture the necessary information. This trace might have a high impact on performance. Identifying the Trace File The diagnostic trace file that is created is titled DMSQL/TRACE/<mix number>/<unique number>. The <mix number> part of the title is the mix number of the server for global tracing. When tracing is initiated, the unique number begins at 1 and is incremented by 1 in each new diagnostic trace file. A new trace file is created when a given trace file is released or an overflow occurs on the file. Enabling the Trace Facility Tracing can be enabled collectively with a single trace file for all workers. Tracing to a single collective trace file is referred to as global tracing. While global trace is enabled, tracing is automatically initiated for any new workers that start up. A trace file can be segmented into two or more physical files by a release function. Releasing a trace file closes the current file and opens a new file for the same task. Releasing a trace file allows significant events to be confined to a smaller trace file. The location of a trace file is assigned when the SQL Query Processor server is installed. All information in diagnostic trace files is prefixed with the mix number and timestamp to the nearest second. Global trace files are created as public files

124 Viewing Trace Information on the Server Use the following system commands to enable the trace facility for all the workers: NA DMSQL TRACE ON DEBUG + OFF RELEASE The following table explains the elements of the syntax diagrams. TRACE Element TRACE ON TRACE ON DEBUG TRACE OFF TRACE RELEASE Definition Shows the status of the trace as well as the name and location of the current trace file. Produces a trace in a single global trace file. You can also use the + (plus) option in place of the ON option. Produces trace information designed to assist Unisys personnel in diagnosing problems. Note: This option is only available when running the diagnostic version of the software. Causes the SQL Query Processor server to discontinue tracing and close the global trace file. You can also use the (minus) option in place of the OFF option. Closes the current global trace file and opens a new file. Closing Trace Files Automatically The trace file is closed automatically when it reaches 50,000 records. If an error occurs during the writing of trace records, the trace file is also closed. Once the trace file is closed, a new trace file is initiated. Any error messages are written to the new trace file, followed by what would have been the next record in the closed trace file. The tracing continues in the new trace file. If an error occurs while the new trace file is being created, the tracing is disabled and an error message is returned

125 Retrieving Dump Files Retrieving Dump Files When a serious fault occurs on the server, the system might perform a program dump. A message is displayed on the ODT to indicate the type of fault that occurred and to identify the dump file name. A similar message also is written to the server log and, if diagnostic trace is active, to the trace file. This message includes the stack history. In most cases, the server can continue normal operations after the dump. Identifying the Dump File The dump file is created as a printer backup file on the pack designated for backup files. Use the system command DL (Disk Location) to locate the pack name. The title of the dump file is *DMSQL/DUMP/<mix number>/<date>/<time>. The * (asterisk) is the usercode for a server library dump file. The mix number identifies the server or worker against which the dump occurred. The date and time are the system date and time. Displaying the Dump File To display the dump file, use the BACK command as follows: BACK *DMSQL ON <backup pack name> When the server performs a dump, it is recommended that you submit the dump file along with a User Communication Form (UCF). This dump file aids in problem diagnosis

126 Retrieving Dump Files

127 Section 6 SQL Query Processor Configuration Control Facility This section explains the following topics: Using the SQL Query Processor configuration control facility Understanding the SQL Query Processor configuration file Creating the SQL Query Processor configuration file Using the CCS clause Using the limit clause Sample SQL Query Processor configuration files

128 SQL Query Processor Configuration Control Facility Using the SQL Query Processor Configuration Control Facility The SQL Query Processor configuration control facility enables you to use multiple releases of the SQL Query Processor software on a single enterprise server. A single data file contains information that identifies the packs that hold the different releases of the SQL Query Processor software and also identifies the usercodes assigned to the different releases. Therefore, you can run the latest version of the SQL Query Processor software along with earlier versions of the software. Different databases can use different versions of the software, thus simplifying the process of upgrading to a new release. The SQL Query Processor configuration control facility consists of The SYSTEM/SQL/CONFIG library, which is shared by all users An SQL Query Processor configuration file, which is shared by all users SYSTEM/SQL/INTERFACE, which is a forwarding library for the gateway into the SQL Query Processor environment This shared-by-all forwarding library is used to redirect calls from the user to the library of the appropriate release level. Libraries must be set to point to the latest release you are planning to run. For example, if you want to run multiple versions of the SQL Query Processor software, the system support libraries for DMSQLCONFIG and DMSQLCLI must be set to the ClearPath MCP release 10.1 or later. In addition, the SQL Query Processor configuration file enables you to Select the level of data management software. List resources used by SQL Query Processor. Note: It is recommended that you use the SI program to install your data management software so that the system support libraries are set automatically to point to the latest release. However, if you do not use the SI program to install the database management software, you must use the SL (Support Library) system command to ensure that all system support libraries are established and point to the latest release

129 SQL Query Processor Configuration Control Facility Understanding the SQL Query Processor Configuration File The SQL Query Processor configuration file that you create is read by the SYSTEM/SQL/CONFIG library when the library is initialized. The information in the SQL Query Processor configuration file is used by the system to determine the version of the SQL Query Processor software to which a particular user has access. If you alter the contents of the SQL Query Processor configuration file while the SYSTEM/SQL/CONFIG library is frozen, the system automatically re-reads the file. Users currently running the SQL Query Processor software are not affected by the change in the SQL Query Processor configuration file, but the new specifications are used for any subsequent attempts to link to a library. To determine the name of the current SQL Query Processor configuration file and to verify its contents, run the SYSTEM/SQL/CONFIG program. The system displays the name and location of the SQL Query Processor configuration file and displays a message if there are any errors in the file. Errors in your SQL Query Processor configuration file can indicate that the installation process was not completed correctly

130 SQL Query Processor Configuration Control Facility Creating the SQL Query Processor Configuration File An SQL Query Processor configuration file is a sequential data (SEQDATA) file that you create using CANDE or some other text editor. There is no required naming convention for the file. The following syntax diagram illustrates the information you can enter in the file: /255*\ <release specification> <user specification> <program specification> /1\ <default release specification> <resource specification> The following table explains the elements of the syntax diagram. Element <release specification> <user specification> <program specification> <default release specification> <resource specification> Definition Defines the software to be used for a specified release. You must include at least one release specification in the SQL Query Processor configuration file. Defines the usercodes that have access to the specified release. The release specification that defines the software to which a user has access must precede the associated user specification in the SQL Query Processor configuration file. The user specification also enables you to restrict the number of database operations executed under the specified usercode. Enables you to restrict the number of database operations performed in one SQL query executed by the specified programs. Defines the software to be used by usercodes not specified in the user specification. You can include only one default release specification in the SQL Query Processor configuration file. Defines a logical identifier that maps a SQL Query Processor data source identifier to one or more physical databases

131 SQL Query Processor Configuration Control Facility Release Specification You must include at least one release specification in your SQL Query Processor configuration file. Each release specification identifies the location of some set of SQL Query Processor software that can be accessed by a system user. You can tailor the release specifications to suit individual users or groups of users. You can also build release specifications from other release specifications contained in your SQL Query Processor configuration file. A release specification can be used multiple times for the same release identifier; however, only the last set of specifications is recognized. If the same release identifier is defined multiple times, a warning message appears. The following diagrams illustrate the syntax of a release specification: <release specification> RELEASE <release identifier> = <base release identifier>, ( /1\ PACK = <family name> ) SL <SL name> = <file title> <file title> / /12\ <identifier> ( <usercode> ) * ON <family name> The following table explains the elements of the syntax diagrams. Element <release identifier> Definition Identifies the software to be used for a particular release. The release identifier is a contiguous group of no more than 17 characters. The release identifier cannot contain a space, colon (:), semicolon (;), equal sign (=), comma (,), left parenthesis ( ( ), or right parenthesis ( ) ). Examples of valid release identifiers include PRODRELEASE BETARELEASE MYRELEASE

132 SQL Query Processor Configuration Control Facility Element <base release identifier> PACK = <family name> SL <SL name> <file title> <usercode> <identifier> <family name> Definition Names a release identifier declared earlier in a release specification in the same file. The software named in the earlier release specification becomes associated with the release identifier you are using in this release specification. This ability to associate the information in one release specification with one or more other release specifications enables you to tailor your environment to the needs of individual users as well as to groups of users. Designates the pack location for the software identified in this release specification. If an individual piece of software resides on a pack other than the designated pack, you must use the SL statement to identify the name and location of the file. If you do not include a PACK statement in the release specification, the software is located using standard enterprise server file-search conventions. Identifies the command used to map a function name to a library file. Use the SL statement if a piece of the data management software resides in a location different from the default location identified in the PACK statement, or if the software does not follow the default naming convention. Identifies one of the system library configuration functions. Identifies the name of the file containing the code for the data management software. Identifies the usercode under which the data management code file is contained. The usercode can contain from 1 to 17 alphanumeric characters. The first character must be either a letter or a number. The remainder of the characters can be letters, numbers, underscores (_), or hyphens (-). Specifies a node in the name of the data management code file. The identifier can contain from 1 to 17 alphanumeric characters. The first character must be either a letter or a number. The remainder of the characters can be letters, numbers, underscores (_), or hyphens (-). Identifies the pack on which the data management code file resides. The family name can contain from 1 to 17 alphanumeric characters. Usually it is necessary only to identify the level of software you want to use and the pack on which the software resides. However, in a release specification you can designate different locations for any of the SQL Query Processor configuration specifications. The following table lists each specification and the name of the code file that the specification is associated with by default. Note: The following table lists SQL Query Processor configuration specifications, not SQL Query Processor settings

133 SQL Query Processor Configuration Control Facility SQL Query Processor Configuration Specification DMSQLADMIN DMSQLCOBOLDESC DMSQLDRIVER DMSQLDMSIIMAPPER DMSQLFILESUPPORT DMSQLPARSER DMSQLSCODESUPPORT DMSQLSUPPORT DMSQLCATALOG DMSQLSCODE Default Name * SYSTEM/SQL/ADMIN *SYSTEM/SQL/COBOLDESC *SYSTEM/SQL/DRIVER *SYSTEM/SQL/DMSIIMAPPER *SYSTEM/SQL/FILESUPPORT *SYSTEM/SQL/PARSER *SYSTEM/SQL/SCODESUPPORT *SYSTEM/SQL/SUPPORT *DESCRIPTION/SQLDIR/DMSQL-CATALOG DMSQLSCODE User Specification The user specification defines the usercodes that have access to the specified software release. If you do not include a user specification in the SQL Query Processor configuration file, all users have access to the software designated in the default release specification. You can include one or more user specifications in the SQL Query Processor configuration file. The following diagrams illustrate the syntax for the user specification: <user specification> USER, <user identifier> <release identifier> <limit clause> = <user identifier> <usercode> ( <usercode> ) <limit clause> LIMIT <limit value> = UNLIMITED

134 SQL Query Processor Configuration Control Facility The following table explains the elements of the syntax diagrams. Element <user identifier> <release identifier> <limit clause> <limit value> UNLIMITED Definition Specifies a user who has access to the software described in the release specification. The user identifier can consist of a single usercode or a list of multiple usercodes separated by commas (,). If a usercode is the same as one of the following keywords, the usercode must be encased in parentheses; otherwise, the use of parentheses is optional. The keywords are DMSQL, RELEASE, USER, RESOURCE, and DEFAULT. You can specify a usercode for multiple releases; however, only the last specification in the file is used. If a usercode does occur multiple times, a warning message appears. Names a release identifier used in a release specification. The designated release identifier must appear in a release specification before it can be used in a user specification. Enables the system administrator to impose an upper limit on the number of database operations performed by a single SQL query. Refer to Using the Limit Clause later in this section for limit clause information. Identifies the maximum number of database operations allowed in one SQL query. The limit value must be an integer between 1 and Indicates that no limit is applied to the specified usercodes. UNLIMITED is the default if no limit clause is specified. Program Specification The program specification enables you to restrict the number of database operations performed in one SQL query executed by the specified programs. The main purpose of the program specification is to enable a limit value linked to a usercode to be overridden when a particular application program is executed. If an SQL query is executed and both the program and the usercode have explicit limits on the number of database operations in a query, then the larger limit applies. The following diagrams illustrate the syntax of the program specification: <program specification>, PROGRAM <program name> <limit clause> <limit clause> LIMIT <limit value> = UNLIMITED The following table explains the elements of the syntax diagrams

135 SQL Query Processor Configuration Control Facility Element <program name> <limit clause> <limit value> UNLIMITED Definition Identifies the name of the file containing the code for the data management software. This program name has the same syntax as the <file title> variable within a release specification, except the usercode and family name must be explicitly stated. Enables the system administrator to impose an upper limit on the number of database operations performed by a single SQL query. Refer to Using the Limit Clause later in this section for limit clause information. Identifies the maximum number of database operations allowed in one SQL query. The limit value must be an integer between 1 and Indicates that no limit is applied to the specified usercodes. UNLIMITED is the default if no limit clause is specified

136 SQL Query Processor Configuration Control Facility Default Release Specification The default release specification defines the data management software release to be used for any usercodes not specifically named in the user specification. You can include only one default release specification in your SQL Query Processor configuration file. If a default release specification is not declared, the first release specified in the file becomes the default release specification. The following diagrams illustrate the syntax of the default release specification: <default release specification> DEFAULT <limit clause> RELEASE = <release identifier> <limit clause> LIMIT <limit value> = UNLIMITED The following table explains the elements of the syntax diagrams. Element <limit clause> <limit value> UNLIMITED <release identifier> Definition Enables the system administrator to impose an upper limit on the number of database operations performed by a single SQL query. Refer to Using the Limit Clause later in this section for limit clause information. Identifies the maximum number of database operations allowed in one SQL query. The limit value must be an integer between 1 and Indicates that no limit is applied to the specified usercodes. UNLIMITED is the default if no limit clause is specified. Names the software that is to be used by anyone accessing the data management software from a usercode that is not explicitly mentioned in the SQL Query Processor configuration file. The designated release identifier must appear in a release specification before it can be used in the default release specification

137 SQL Query Processor Configuration Control Facility Resource Specification The resource specification is used by the SQL Query Processor to create a logical connection between a client application and the physical data source. The resource you specify is a logical identifier for the data source. A resource maps a data source identifier to one or more physical databases. When an application using the SQL Query Processor software attaches to a resource, the system automatically routes instructions and data between the client application and the physical data source or sources to which the resource is mapped. Whether a resource is mapped to one or several physical data sources is transparent to the user of the client application. The following diagrams illustrate the syntax for configuring system resources: <resource specification> RESOURCE <resource identifier> = <CCS clause>,, /5*\ <database list> <CCS clause> CCS <coded character set name or library ccsnumber> <database list> <database name> <logical database title> <mode> <logical database title> <logical database name> OF <database name> <database title> <database title> * <database name> ON <family name> <user code> <mode> ( MODE INQUIRY ) UPDATE The following table explains the elements of the syntax diagrams. Element <resource identifier> Definition Identifies the resource. The resource identifier must be 1 to 18 letters, numbers, underscores (_), or hyphens (-). The first character must be a letter or a number, and the last character must not be an underscore or a hyphen. SHIPPING is an example

138 SQL Query Processor Configuration Control Facility Element <CCS clause> <coded character set name or library ccsnumber> <database list> <database name> <database title> <logical database title> <mode> Definition Specifies the coded character set used by the SQL Query Processor server to map data characters between the workstation and the data source. Refer to Using the CCS Clause later in this section for additional information. Specifies the coded character set name or number. For a detailed explanation and listing of coded character sets, refer to the MultiLingual System Administration, Operations, and Programming Guide. Associates databases with the resource identifier. At most, five databases can be associated with one logical resource. Identifies the database name. The database name is an identifier containing from 1 to 17 letters, numbers, or hyphens. The first character must be a letter. The last character cannot be a hyphen. Specifies the name of the database and location of the database control file. (ACCOUNTDB)PAYROLL ON PAYPACK is an example. Specifies the name of the logical database and location of the logical database control file. RESOURCE LDB1 = LDB1 OF (DEV)TESTDB ON PRODUCTION (MODE UPDATE) is an example. Indicates the way in which the specified database is to be accessed. The access mode defaults to INQUIRY if no mode is specified

139 SQL Query Processor Configuration Control Facility Using the CCS Clause The CCS clause specifies the translation to and from Unicode that is needed when database data and identifiers are passed between the MCP-based SQL Query Processor components and the Windows-based Relational Design Center and the Query Design Center. If a CCS clause is omitted, the SQL Query Processor determines the coded character set based on the ccsversion of the database. If a ccsversion is not specified for the database and the CCS clause is omitted, then ASERIESEBCDIC is assumed. A ccsversion is an optional specification in DASDL for a database on which the SQLVIEW command was performed. If a CCS clause and a ccsversion are specified for the database, the CCS value of the ccsversion must match the value of the CCS clause for the resource. If 16-bit data item names, structure names, or data item types are used in DASDL for a database on which the SQLVIEW command was performed, a corresponding CCS clause must be used for the resource specification. For a complete list of supported CCS values, refer to the MultiLingual System Administration, Operations, and Programming Guide. Using the Limit Clause The limit clause enables the system administrator to impose an upper limit on the number of database operations performed by a single SQL query. The limit can be designated by usercode and by program name. The limit applies to any of the following databases: SQL databases Databases or files processed by the Relational Design Center The limit applies to all programs. If no explicit limit clause is specified, the default value of UNLIMITED applies. Setting a Default Release Limit A designated person, such as a system administrator, can set a default release limit for all usercodes. Limits can also be set for specific usercodes and for specific programs. Specific usercode and program limits override the default release limit. If both a usercode and a program limit are applied to a program execution, the larger of the two limits is enforced

140 SQL Query Processor Configuration Control Facility Limit Clause Enforcement If a limit clause is included in the SQL Query Processor configuration file, then each time an SQL query is run, the database operations performed during that query are counted. If the number of operations exceeds the stated limit, an error occurs. A database operation is equivalent to one retrieval of a row in an SQL table, regardless of whether the retrieved entity is selected. For example, consider the following query: FROM PERSON RETRIEVE NAME WHERE AGE = 60 If this query reads 1000 entities and selects 10, then the operation count is Because of the high-performance method of executing a linear search, the check for exceeding the operations limit is performed when a record is selected or at 5-second intervals, whichever occurs first. Depending upon the system load, the operation count can exceed the query limit by a considerable number before the query is stopped. For update queries, the retrievals are counted, not the updates. For example, consider the following query: UPDATE STUDENT (ADVISOR = 1234) WHERE STUDENT_NO > 1106 If this query reads 500 entities and modifies 6, then the operation count is 500. In a nested query, the retrievals at all levels are counted. An example of this query would be as follows: SELECT * FROM CUSTOMER WHERE CUSTOMER.SALESMAN ID IN (SELECT ID FROM SALESME N WHERE REGION = EAST ) If this query reads 10 rows from SALESMEN for each of 60 customers and selects 15 customers, then the operation count is 600. When the Limit Is Set and Tested The query limit for the current program is obtained when the open query driver call is made. If a limit is changed while a program is running, the new value does not take effect until the program is terminated and started up again. When a retrieval or an update operation is executed that causes the limit to be exceeded, the following error message appears: You have exceeded the database operations limit <nnn> requested by your admi nistrator. Effect of Query Limit Error If a query limit error occurs on a retrieval call that is being repeated to obtain all the selected data, then all the data returned to the application by the earlier calls is available

141 SQL Query Processor Configuration Control Facility to the application. If the query limit error occurs on an update statement, no update is performed. The following sample SQL Query Processor configuration file illustrates the uses of the limit clause: RELEASE 521 (PACK = SYS521) SL DMSQLADMIN = (GEORGE)SYSTEM/SQL/ADMIN ON USER1 USER FRED, GEORGE, MARY LIMIT = PROGRAM (FRED)OBJECT/REPORTPROG ON USER1, (MARY)SYSTEM/SQL/CLIPROG ON USER2 LIMIT UNLIMITED DEFAULT LIMIT = 1000 RELEASE = 521 With the preceding SQL Query Processor configuration file, queries are limited to 1000 operations each. However, the following exceptions to this limit are defined: The FRED, GEORGE, and MARY usercodes have a query limit of The programs (FRED)OBJECT/REPORTPROG and (MARY)SYSTEM/SQL/CLIPROG have no limit on the number of operations that each query can perform

142 SQL Query Processor Configuration Control Facility Sample SQL Query Processor Configuration Files The following pages contain three examples of SQL Query Processor configuration files. Note: All release names, pack names, and usercodes are arbitrary. They are used as examples only. When creating your own SQL Query Processor configuration file, use the appropriate names and usercodes. Example 1 This example defines two releases. The SQL Query Processor software for release MYREL1 is on a pack named SYSOLD. The MYREL2 release software is on a pack named TESTPACK. For both releases, the default code file titles are used. Usercode DEBORAH uses the SQL Query Processor software that resides on the pack TESTPACK. All other usercodes use the default release software, which resides on the pack SYSOLD. The SQL Query Processor configuration file in this example enables users to continue to use the MYREL1 release SQL database while some experimentation is carried out using an updated version of the SQL Query Processor software. RELEASE MYREL1 (PACK = SYSOLD) RELEASE MYREL2 (PACK = TESTPACK) USER DEBORAH = MYREL2 DEFAULT RELEASE MYREL

143 SQL Query Processor Configuration Control Facility Example 2 This example defines several releases and assigns various usercodes to specific releases. This SQL Query Processor configuration file defines the MYREL1, MYREL2, and MYREL3 release software as residing on the PACKFORMYREL1, PACKFORMYREL2, and PACKFORMYREL3 packs, respectively. Usercode OSWALD uses MYREL1. Usercodes BETTY and BOB use MYREL2, and usercodes KAREN, JEFF, and TINA use MYREL3. Usercode FRED uses software based on his current family statement. If his family statement is set to PACKFORMYREL1, he uses the MYREL1 software on that pack. If his family statement is set to PACKFORMYREL3, he uses the MYREL3 software. If his family statement includes PACKFORMYREL2, he uses the MYREL2 software. Usercode JOE has a release for his own use, called PRIVATE-FIX. It is based on MYREL2 but has two different files, one of which can be found on PACK under the usercode JOE. The second file is also located on PACK, but it can be found under usercode EUROPE. In addition, the second file uses the coded character set named LatinCyrillicEBC rather than the default coded character set. All other usercodes use the MYREL2 SQL Query Processor software. RELEASE MYREL1 (PACK = PACKFORMYREL1) RELEASE MYREL2 (PACK = PACKFORMYREL2) RELEASE MYREL3 (PACK = PACKFORMYREL3) USER OSWALD = MYREL1 BETTY,BOB = MYREL2 KAREN, JEFF, TINA = MYREL3 RELEASE FAMILY-SQL USER FRED = FAMILY-SQL RELEASE PRIVATE-FIX = MYREL2 SL DMSQLSUPPORT = (JOE)SYSTEM/SQL/SUPPORT ON PACK USER JOE = PRIVATE-FIX DEFAULT RELEASE = MYREL2 VIEWCONNECTION VIEWUPLOAD RESOURCE SHIPPING = (JOE)SHIPPINGDB ON PACK RESOURCE INTL = CCS LatinCyrillicEBC, (EUROPE)INTLDB ON PACK

144 SQL Query Processor Configuration Control Facility Note: The coded character set identifier CCS LatinCyrillicEBC can also be specified by its library ccsnumber, as follows: Example 3 RESOURCE INTL = CCS 29 (EUROPE) INTLDB ON PACK The following example assumes that the following support library function has been created on the system: SL MYSCODE = *SYSTEM/SQL/SCODE ON PACK1 Usercode HARRIET has a release for her own use, called MYREL1TEST. It is based on release MYREL1 but is using a new version of *SYSTEM/SQL/SCODE. RELEASE MYREL1 (PACK = SYSOLD) RELEASE MYREL1TEST (PACK = TESTPACK) SL DMSQLSCODE = MYSCODE USER HARRIET = MYREL1 DEFAULT RELEASE MYREL

145 Section 7 Using the Schema Administrator This section explains the following topics: Ensuring description file and control file accessibility Reviewing the results file of a SQLVIEW command generation Using the Schema Administrator input file Manually enabling SQL access to an Enterprise Database Server database Listing the description

146 Using the Schema Administrator Ensuring Description File and Control File Accessibility Use of the SQL Query Processor Schema Administrator requires that you have the appropriate access to files in the MCP environment. As part of enabling SQL access to databases, the SQL database generation process (using the SQLVIEW command) must be able to read the applicable description file and control file. The generation process also requires the creation of an SQL catalog file under the same usercode as the control file or the data file. The SQL description you generate resides in a description file that is named according to the following format: DESCRIPTION/<database name>/dmsql-catalog This description file is the SQL catalog and is stored under the usercode and family you define for the database control file when you generate the SQL mappings for Enterprise Database Server databases. This SQL catalog inherits the physical security of the control file. Ensuring File Accessibility The easiest way to ensure that the system can locate and read the database control file, and create the SQL catalog file without security problems is to perform all database processing under the usercode of the control file. If you choose to run the SQLVIEW command from a different usercode, explicitly specify the location of both the control file and the database description file when you generate your description file. In addition, ensure the usercode from which you run has the appropriate privileges to read the Enterprise Database Server description file and create the SQL catalog file

147 Using the Schema Administrator Reviewing the Results File of a SQLVIEW Command Generation After generating an SQL description using the SQLVIEW command, a results file containing confirmation messages, error messages, and structure mappings is produced. If you use the Schema Administrator command interface, the default name of the results file is DDLRESULTS/<database name> You can file-equate the results file so that it is created with a name other than the default shown in the preceding example. The results file is located under the usercode and on the primary pack with which the Schema Administrator is initiated. The format of the results file is compatible with the file format of the compiler error messages. This compatibility enables you to use the Editor Utility to view the messages in the context of the CARD file. After examining the errors, you can print them. Then, from the Relational Design Center, reload the semantics you have created, make appropriate changes to the semantics, save the changes, generate the semantics, upload the new semantics, and rerun the Schema Administrator program. Viewing the Schema To view the SQL schema SQL catalog, you can use the Schema Administrator LIST command. The output from the LIST command also contains information about Enterprise Database Server constructs that were not modeled. For information on the Schema Administrator LIST command, refer to Listing the Description later in this section. Note: The LIST command produces certain constructs to provide further information about the SQLVIEW descriptions, but these constructs are not accepted as valid SQL DDL syntax. You should review all attributes on the SQL schema to determine the SQL characteristics enforced by the system. For example, if an entity cannot be fully updated, the Schema Administrator assigns appropriate schema constraints like READONLY so that errors can appear through normal SQL processing

148 Using the Schema Administrator Using the Schema Administrator Input File The Schema Administrator uses a file with the internal name CARD as an input file. The CARD file is optional. If you are not using the Relational Design Center, you can use the CARD file to apply security to the SQL mapping. If you do not supply security specifications in the CARD file, the default security is used. You can also use the CARD file to modify SQL mappings. Note: It is recommended that you use the Relational Design Center to create SQL maps or define security for your SQL descriptions. If you want to define security for the SQL mapping created with the Schema Administrator, you must include DDL access and permission security statements in the CARD file. When you generate a description with the SQLVIEW command, you are assumed to be the owner of the database. You can define accesses and permissions to enable any or all usercodes, accesscodes, and programs to perform specific tasks on specific SQL entities in your database. You can define the accesses and permissions for any items mapped by the SQLVIEW command. If you want to define SQL mappings for the SQL description created with the Schema Administrator, you must include SQL DDL statements in the CARD file. For more information on using SQL DDL statements, refer to the SQL Query Processor Programming Guide

149 Using the Schema Administrator Manually Enabling SQL Access to an Enterprise Database Server Database Perform the following steps to enable SQL access to the Enterprise Database Server database. Note: The following procedure assumes that you are working with a database named MYDB and that any additional semantics are saved in a file called MYDB/GEN. 1. Log on to the ClearPath MCP system under the usercode containing the database files. For a nonusercoded database, log on under a privileged usercode. 2. Verify that you have at least read access to both the Enterprise Database Server control file and the Enterprise Database Server description file (named MYDB/CONTROL and DESCRIPTION/MYDB for the MYDB database). 3. Set your family statement appropriately. 4. Create the SQL mapping by executing the Schema Administrator. For example, if you are using CANDE and the database and the MYDB/GEN files are under your current usercode, enter the following statement: RUN $SYSTEM/SQL/ADMIN ("SQLVIEW DATABASE MYDB"); FILE CARD = MYDB/GEN If you want to allow the Enterprise Database Server database to be updated from SQL queries, add :ACCESSCONTROL = UPDATEOK to the statement, as follows: RUN $SYSTEM/SQL/ADMIN ("SQLVIEW DATABASE MYDB:ACCESSCONTROL = UPDATEOK"); FILE CARD = MYDB/GEN If you want to optimize queries based on table population, specify the STATISTICS element in the ACCESSCONTROL clause. If ACCESSCONTROL is omitted, the database is read only. If the database is a nonusercoded database, explicitly specify the asterisk (*) in the database name. For example, use *MYDB for the name of the database, as follows: RUN $SYSTEM/SQL/ADMIN ("SQLVIEW DATABASE *MYDB"); FILE CARD = MYDB/GEN Assuming that the Schema Administrator detected no errors, the Enterprise Database Server database is now SQL-capable

150 Using the Schema Administrator Generating the SQL Descriptions Use the SQLVIEW command to generate an SQL description using the Schema Administrator command interface. SQLVIEW Command Syntax SQLVIEW DATABASE <database title> LOGICAL DATABASE <logical database title : <access control> <database title> <database name> ( <usercode> ) ON <pack name> * <logical database title> <logical database name> OF <database name> <database title> <access control> ACCESSCONTROL = INQUIRYONLY UPDATEOK,STATISTICS,LOCKEDFILE Explanation Syntax Element SQLVIEW DATABASE or SQLVIEW LOGICAL DATABASE <database title> <logical database title> <access control> <database name> <usercode> Description Designates the Schema Administrator SQLVIEW command. Describes the name and location of the Enterprise Database Server database for which you want an SQL mapping. If you do not specify a usercode and pack name, standard file search rules are applied. Describes the name and location of the Enterprise Database Server logical database for which you want an SQL mapping. If you do not specify a usercode or a pack name, standard file-search rules are applied. Defines the degree of access to the database using the SQL mappings. Specifies the name of the Enterprise Database Server database for which you want an SQL mapping. Indicates the usercode under which the Enterprise Database Server control file is stored

151 Using the Schema Administrator Syntax Element Description * Indicates that the Enterprise Database Server control file is stored without a usercode. <pack name> ACCESSCONTROL INQUIRYONLY UPDATEOK STATISTICS LOCKEDFILE Indicates the pack name on which the Enterprise Database Server control file is stored. Defines the degree of access to the database. ACCESSCONTROL can be defined as either INQUIRYONLY or UPDATEOK. The default is INQUIRYONLY. Allows users to retrieve information from the database but not to modify information in the database. Allows users to retrieve and modify information in the database. Computes population statistics for all structures for use in query optimization. Applies structure lockout while the population is being computed. Examples Using the Command Interface You initiate the Schema Administrator SQLVIEW command by using either a CANDE RUN statement or a WFL job. The following text provides examples of each method. Using a CANDE RUN Statement The following example shows how to run the Schema Administrator using a CANDE RUN statement. The name of the Enterprise Database Server database is ORGDB; it is located on the pack DBPACK. Access control is defined as UPDATEOK. The example also names a CARD file and a DASDL file. The DASDL file is file-equated to the title of the description file. RUN *SYSTEM/SQL/ADMIN ("SQLVIEW DATABASE ORGDB ON DBPACK: ACCESSCONTROL = UPDATEOK"); FILE CARD = SCHEMA/SECURE/ORGDB; FILE DASDL = DESCRIPTION/ORGDB ON DESCPACK; FILE DDLRESULTS = RESULT/DMSVIEW/ORGDB

152 Using the Schema Administrator Using a WFL Job The following example shows how to run the Schema Administrator using a WFL job. In this example, the database ORGDB under the usercode SAMPLE is being viewed. Because the ACCESSCONTROL syntax element is omitted, the default value is INQUIRYONLY; users querying the viewed database have inquiry access only. Users cannot update the database. This example names the file SCHEMA/SECURE/ORGDB as the CARD file. BEGIN JOB SQLVIEW/ORGDB; TASK T; RUN *SYSTEM/SQL/ADMIN ("SQLVIEW DATABASE (SAMPLE)ORGDB") [T]; FILE CARD (TITLE = SCHEMA/SECURE/ORGDB); IF T(VALUE) LSS 0 THEN ABORT "Errors detected"; END JOB Listing the Description Use the Schema Administrator LIST command to list the SQL description. The following describes the syntax for this command. LIST Command Syntax LIST DATABASE <database title> SQL LOGICAL DATABASE <logical database title> : REMOTE PRINTER FILE <file name> <database title> <database name> (<usercode>) ON <pack name> * <logical database title> <logical database name> OF <database name> <database title> Explanation Parameter Description SQL <database title> Causes the SQL schema to be listed. SQL is the default when no parameter is entered. Specifies the name and optionally the location of the database for which the description is to be listed

153 Using the Schema Administrator Parameter <logical database title> REMOTE PRINTER FILE Description Specifies the name and optionally the location of the logical database for which the description is to be listed. Causes output to be sent to a remote file. REMOTE is the default when the Schema Administrator is run from a terminal. Causes output to be printed. PRINTER is the default when the Schema Administrator is run in batch mode. Causes the designated file to be created on disk containing the schema information. Note: Although the output from the LIST command provides the information in the form of SQL schema syntax, this syntax is not guaranteed to be accepted as input to produce a native SQL database

154 Using the Schema Administrator

155 Section 8 Using the DMQUERY Utility What Is the DMQUERY Utility? The DMQUERY utility is a SQL Query Processor command-line diagnostic tool you use to perform administrative operations such as opening and closing databases, and managing transactions. You can also use the SELECT, INSERT, UPDATE, or DELETE statements. SQL Query Processor transactions are started implicitly. If you have modified the database without ending the transaction, you must explicitly commit or roll back the transaction before terminating your DMQUERY utility session. The DMQUERY utility has a DO file capability to process commands and SQL statements saved in a file. You can set the DEST option to cause output to be routed to a printer file or disk file rather than the remote file. You can use the DEFINE command to define an identifier (with optional parameters) to be commands or SQL statements and use that identifier to invoke the command. Using SQL Statements You must open the database using the OPEN command. You can then use any of the following SQL Query Processor statements: SELECT INSERT UPDATE DELETE

156 Using the DMQUERY Utility Using DMQUERY Utility Commands The following conventions apply to your use of DMQUERY utility commands: BYE DMQUERY utility commands are case-insensitive. You terminate a command with a semicolon (;) character. When interacting with the DMQUERY utility, the end of a transmission also acts as a command terminator. You can transmit multiple commands in a single transmission. If the DMQUERY utility encounters a percent sign, it ignores the rest of the transmission. In a DO file, the end of a record does not act as a command terminator. That is, commands are automatically continued across record boundaries. If the DMQUERY utility encounters a percent sign, it ignores the rest of the record. Tokens enclosed in square brackets are optional. The bold portion of a word is the minimum part of the word that must be used. CANCEL CLOSE Ends a DMQUERY session. BYE END QUIT Cancels all updates since a designated savepoint. CANCEL <number> Closes a database. You use the CLOSE command to close the database and the BYE command to end the DMQUERY utility session. CLOSE <database identifier> COMMIT WORK Commits a transaction. You can also use the ENDTRAN command to commit a transaction. COMMIT WORK ENDTRAN

157 Using the DMQUERY Utility DEFINE DIAGNOSE DO OPEN PARSE Creates a query with parameters that are defined at execution. DEFINE <identifier> [(#<parameter 1>[,#<parameter 2>...])] = <SQL statement> In the SQL statement, you refer to a parameter by #<parameter>. Generates a query dump (QDUMP). DIAGNOSE [LAST] Executes commands contained in a script file. DO <file title> Opens a database. OPEN <database identifier> [(<open option name> [ = ] <open option value>[,...])] The parameter <database identifier> is the default database name. Open Options NAME = <database name> LOGICALDB = < logical database name> The parameter <database name> or <logical database name> is the actual database name. Open Option Values USERCODE = <usercode> FAMILYNAME = <family> MODE = INQUIRY UPDATE Parses the corresponding SQL statement. PARSE <SQL statement>

158 Using the DMQUERY Utility QD REPEAT Sends a message to the query driver. QD SCODE [<query number>] DUMP QUERY The QD command generates a dump of the query symbolic or the Scode. The information is stored in a file named QDUMP/<mix number>/<serial number>. Repeats the last SQL statement. You use the SHOW command to display the last SQL statement entered and the REPEAT command to repeat the last SQL statement entered. REPEAT [LAST] ROLLBACK WORK SAVEPOINT SET Aborts a transaction. You can also use the ABORT command to abort a transaction. ROLLBACK WORK ABORT Creates a savepoint. SAVEPOINT <number> Changes the state of a DMQUERY utility option. SET <option setting> [, <option setting>...] <option setting> <Boolean option setting> <numeric option setting> <string option setting> <symbolic option setting> <symbolic value> <Boolean option setting> <Boolean option> [ = ] TRUE FALSE ON OFF

159 Using the DMQUERY Utility <Boolean option> Option Description DUMPONFAULT ECHO QGRAPH TRUNCATE Causes a dump to be taken if the DMQUERY utility faults. The default is ON. Causes the statements in a DO file to be written to the file or device indicated by the DEST option. The default is ON. Writes a query graphic (QGRAPH) file for each subsequent SQL statement. Manages spacing of the output. The default is ON. <numeric option setting> <numeric option> [ = ] <number> <numeric option> Option Description LIMIT PAGELENGTH PAGEWIDTH SPACING Designates the maximum rows to be retrieved for a SELECT statement. The default is zero (unlimited). The default is 24 lines. The default is 80 characters. Designates for the FORMAT TABULAR option the minimum spacing between columns. The default is 20. <string option setting> <string option> [ = ] <string> <string option> TITLE FOOTING

160 Using the DMQUERY Utility SHOW <symbolic option setting> <symbolic option> [ = ] <symbolic value> <symbolic option> Causes the output to be written to a printer, remote file, or a disk file named DEST. DEST = PRINTER REMOTE FILE <symbolic value> Causes the result of a SELECT statement to be written as a table or written one column at a time. The default is TABULAR. FORMAT = TABULAR STRUCTURED Displays the last SQL statement entered or the names of the defines. The default is to display the last SQL statement. You use the SHOW command to display the last SQL statement entered and the REPEAT command to repeat the last SQL statement entered. SHOW [LAST] [DEFINES]

161 Using the DMQUERY Utility Running the DMQUERY Utility Interactively Through CANDE Run the DMQUERY utility interactively by issuing the following statement through the Command and Edit (CANDE) program: RUN $SYSTEM/SQL/DMQUERY The following message appears: Welcome to the DMSQL Diagnostic Facility Please enter command At this point, you can issue any of the DMQUERY utility commands. Refer to Using DMQUERY Utility Commands earlier in this section for more information. Running the DMQUERY Utility in Batch Mode Run the DMQUERY utility in batch mode through CANDE or through a Work Flow Language (WFL) job. Note: Make sure to add SW1=TRUE as part of the WFL RUN statement to direct the DMQUERY utility to run in batch mode. The following lists an example of running the DMQUERY utility in batch mode through CANDE: RUN *SYSTEM/SQL/DMQUERY; FILE FIL = DMSQL/DMQUERY/DB1/SELECT/NEWDMQUERYRESULTS; FILE CARD = DMSQL/DMQUERY/DB1/SELECT/INPUT; The following lists two examples of running the DMQUERY utility in batch mode through a WFL job. Example 1 BEGIN JOB RUN/DMQUERY1; TASK T; RUN *SYSTEM/SQL/DMQUERY [T]; SW1=TRUE; FILE FIL = DMSQL/DMQUERY/DB1/SELECT/NEWDMQUERYRESULTS ON PACK1; FILE CARD = DMSQL/DMQUERY/DB1/SELECT/INPUT ON PACK2; END JOB. Example 2 BEGIN JOB DMSQL/DMQUERY2; RUN *SYSTEM/SQL/DMQUERY ON DISK;SW1=TRUE; FILE CARD(KIND=READER); DATA CARD

162 Using the DMQUERY Utility SET DEST=FILE, QGRAPH TRUE; OPEN DB1(USERCODE=USER1, FAMILYNAME=PACK1, MODE=INQUIRY); SELECT COUNT(*) FROM DS1; CLOSE DB1; BYE? END JOB; The following lists a sample input CARD file for the DMQUERY utility: 100 % Route all output to a file 110 SET DEST=FILE; % Write statement to output as well as return data 140 SET ECHO; % Produce a query graphic for each SQL statement 170 % Limit queries to return at most 5000 records 180 SET QGRAPH=TRUE, LIMIT=5000; % Open database DB1 400 OPEN DB1; % Find record 600 SELECT employee_name from ds1 where employee_nbr=67; % Add record, you can continue a command on the next line 630 INSERT into ds1 (employee_nbr, employee_name, employee_age) 635 VALUES (44, Bob Smith, 33); % Complete update by ending transaction 660 COMMIT WORK; % Close database 970 CLOSE DB1; % End DMQUERY session 990 BYE;

163 Using the DMQUERY Utility DMQUERY Utility Files The following table lists the files that result from running various DMQUERY utility tasks. File Type CARD FIL PRT RMT Description Identifies a disk file that is used as an input script when running the DMQUERY utility in batch mode. Identifies a disk file that is used as the output file containing the results of queries. In batch mode, the file defaults to the name DEST. Identifies the printer file. Identifies the remote file name used when running the DMQUERY utility interactively

164 Using the DMQUERY Utility

165 Appendix A Setting Up Kerberos Authentication in the Windows Environment in the Windows Environment Perform the following steps to set up Kerberos authentication in the Windows environment: 1. Create the following registry key using the Windows Registry Editor to make the session ticket-granting ticket (TGT) key available: HKLM\System\CurrentControlSet\Control\LSA\Kerberos\ AllowTGTSessionKeyDWORD 1 2. Modify the java.security file in the Java Runtime Environment (JRE) lib/security directory to reference the Java Authentication and Authorization Service (JAAS) configuration file named jaas.config, which is in the same directory. For example: login.config.url.1=file:${java.home}/lib/security/jaas.config Note: If login.config.url.1 exists, use the next available number. For example, login.config.url.2=file:${java.home}/lib/security/jaas.config. The JAAS configuration file indicates the Pluggable Authentication Module (PAM) to use. The following lists sample contents, which can be added to an existing jaas.config file: unisys.dmsql.provider { com.sun.security.auth.module.krb5loginmodule required useticketcache=true client=true debug=false usekeytab=true default_tkt_enctypes=des-cbc-md5 default_tgs_enctypes=des-cbc-md5; }; A 1

166 Setting Up Kerberos Authentication in the Windows Environment 3. Create the Kerberos configuration file named krb5.conf in the lib/security directory of the JRE structure. The following lists sample contents of the Kerberos configuration file: [libdefaults] default_realm = FOO.BAR dns_lookup_kdc = true [realms] FOO.BAR = { kdc = kdc.foo.bar admin_server = kdc.foo.bar } [domain_realm] [logging] A

167 Appendix B Troubleshooting This appendix lists limitations and restrictions in your use of the SQL Query Processor, and error messages you might encounter with possible solutions. Case-Sensitive Passwords If a password includes lowercase letters or special characters, it must be placed inside of quotation marks (for example, Jones ), unless the MCP security option CaseSensitivePW is set. If a password is not enclosed in quotation marks and the CaseSensitivePW security option is not set, SQL Query Processor capitalizes the password. When the SQL Query Processor server is initiated, it reads the MCP security option CaseSensitivePW and saves the value in memory. When the option CaseSensitivePW is set, the SQL Query Processor server does not capitalize any entered passwords, and it is not necessary to enclose in quotation marks a password that contains lowercase letters or special characters. However, you can enclose the password in quotation marks. If the MCP security option CaseSensitivePW is changed while the SQL Query Processor server is active, the change is not reflected until after the server is stopped and restarted. 1. To stop the SQL Query Processor server, wait until all server users have finished. Then, enter the following system command: NA DMSQL QUIT NOW 2. To restart the SQL Query Processor server, enter the following system command: NA DMSQL B 1

168 Troubleshooting Error Messages The following text lists error messages you might encounter while accessing the database on the ClearPath MCP server and lists possible corrective actions. The control file for your database cannot be found. Use the Relational Design Center to update your database. No message; you get no response. The server task SYSTEM/SQL/WORKER might be waiting. Perform the following steps to respond to this situation: 1. Log on to CANDE using the usercode with which you were trying to connect. 2. Enter the following command to determine whether the SQL Query Processor system files are installed on the secondary family: FAM* 3. If the secondary family is not in the proper location, change the family statement in the USERDATAFILE. 4. If the secondary family is not an issue, check for waiting entries to try to resolve the problem. 5. Contact the Unisys Support Center if you cannot resolve this problem. Another possible cause for this error condition is that the SYSTEM/SQL/CONFIG file is waiting on a NO FILE condition for the SQL Query Processor configuration file (DMSQL/CONFIG). Run the *SYSTEM/SQL/CONFIG program from CANDE to determine the title of the file for which the worker is looking and to verify the syntax of the statements in the file. java.net.connectexception: Connection refused: connect The specified port number might be incorrect. Execute the following command on the ClearPath MCP server to identify the correct port number: NA DMSQL STATUS java.net.unknownhostexception: eccsxx The specified server name is incorrect. Identify the correct name of the server. Unable to connect to data source The user-specified resource or database name is incorrect. Use the Query Design Center to check the catalog of available resources. B

169 Index A access point for network, 5-7 access rights, 7-2 assigning in Relational Design Center, 4-42 accesscode, Query Design Center, 3-2 accesses SQL, 4-23 adding a server, Relational Design Center, 4-30 ALPHA data items modeled in SQL, 4-24 with ccsversion specifications, modeling, 4-23 Analyze Query window, 3-3, 3-11 commands, 3-13 results pane, 3-12 text pane, 3-11 applying schema modifications, Relational Design Center, 4-37 assigning access rights to database structures, in Relational Design Center, 4-42 assigning library function names, 2-4 associating users with software, 6-7 attribute type, modeled from data item types (table), 4-23 authentication, setting up Kerberos, A-1 automating SQL Query Processor server initialization, 5-7 B BACK command, 5-15 base release identifier, denoting in the SQL Query Processor configuration file, 6-6 base tables, SQL views of, 4-23 batch mode, running DMQUERY utility, 8-7 benefits, SQL Query Processor, 1-4 bit vector physical organization sets mapped in SQL, 4-23 subsets not modeled in SQL, 4-23 BLOCKEDTIMEOUT value, 2-7, 5-8 BYE command, DMQUERY utility, 8-2 C CANCEL command, DMQUERY utility, 8-2 CANDE RUN statement, 7-7 CARD file, 7-4 case-sensitive passwords, limitations, B-1 Catalog window, 3-3, 3-6 CCS clause, 6-11, 6-13 ccsversion specification in SQL, 4-23 changing name and location of configuration file, 2-6 chargecode, Query Design Center, 3-2 ClearPath MCP environment installing SQL Query Processor in the Windows environment, 2-11 ClearPath MCP servers, terminology, 1-1 CLOSE command, DMQUERY utility, 8-2 closing the trace file, 5-14 column attributes, query table pane, 3-20 column properties, Catalog window, 3-8 Command and Edit (CANDE) message control system (MCS) RUN statement, 7-7 Command and Edit (CANDE), running DMQUERY utility, 8-7 command interface LIST command, 7-3 reporting on descriptions, 7-8 results file, 7-3 SQLVIEW command, 7-6 commands Analyze Query window, 3-13 BACK, 5-15 BYE, 8-2 CANCEL, Index 1

170 Index CLOSE, 8-2 COMMIT WORK, 8-2 DEFINE, 8-3 DIAGNOSE, 8-3 DMSQL, 5-5 DMSQL HELP, 5-6 DMSQL SHOW STATUS, 5-10 DO, 8-3 HELP, 5-6 LIST, 7-3, 7-8 LOG, 5-11 MODIFY in WFL, 5-7 OPEN, 8-3 PARSE, 8-3 QD, 8-4 REPEAT, 8-4 ROLLBACK WORK, 8-4 SAVEPOINT, 8-4 SET, 8-4 SHOW, 8-6 SHOW STATUS, 5-10 SQLVIEW, 7-6 TRACE, 5-14 COMMIT WORK command, DMQUERY utility, 8-2 components, SQL Query Processor, 1-4 configuration *DMSQL/SERVER/CONFIG file, creating, 5-7 process for resource, 5-2 SQL Query Processor server, 5-5 starting, 5-5 stopping, 5-5 configuration control facility, SQL Query Processor, 6-2 configuration file (See SQL Query Processor configuration file) configuring distributed systems services (DSS), 2-8 server resources, 5-2 conflicting names, handling, 4-9 connection status, Query Design Center, 3-5 control file, 7-2 controlling SQL Query Processor server, 5-5 conventions for terminology, 1-1 conventions for usercode and password, Query Design Center, 3-2 creating *DMSQL/SERVER/CONFIG file, 5-7 dump file, 5-15 integrity constraints in Relational Design Center, 4-45 savepoint in Query Design Center, 3-17 server configuration file, 2-6 SQL database in Relational Design Center, 4-32 SQL dates in Relational Design Center, 4-44 SQL Query Processor configuration file, 6-4 SQL views in Relational Design Center, 4-47 customizing, Query Design Center, 3-24 D Data and Structure Definition Language (DASDL) example embedded data set in SQL, 4-21 embedded data set mapped in SQL, 4-17 occurring item mapped in SQL, 4-17, 4-19 data item properties, Relational Design Center, 4-4 data items defaults, 4-23 modeled as SQL attribute types, 4-23 occurring, mapped in SQL, 4-15 options, modeled in SQL, 4-24 data set properties, Relational Design Center, 4-4 data sets disjoint, modeled in SQL, 4-10 embedded mapped in SQL, 4-17, 4-19 modeled as SQL tables, 4-14 occurring items example, 4-14 restart, modeled in SQL, 4-25 variable-format deleting table rows, 4-13 example, 4-13 mapping in SQL, 4-10 SQL mapping example, 4-10, 4-11 data sources, 5-2, 5-4 database entities (table), 4-28 database properties, Relational Design Center, 4-4 databases access mode, 5-3, 6-11 Enterprise Database Server, 5-4 list, 6-12 name, 6-12 Index

171 Index resource preparation, 5-4 SQL, 5-4 title, 6-12 date construct, SQL, 4-26 DDLRESULTS file, 7-3 default properties, Query Design Center, 3-24 default release specification, 6-4, 6-10 defaults access, 4-23 data item, 4-23 disjoint data set, 4-10 embedded data set, 4-14 global data, 4-10 group, 4-25 link, 4-25 occurring item, 4-14 physical option, 4-25 restart data set, 4-25 set, 4-23 SQL names, 4-9 subset, 4-23 DEFINE command, DMQUERY utility, 8-3 defining data source, 5-2 release identifiers in the SQL Query Processor configuration file, 6-6 repository, 5-2 resources, 5-2, 5-3 SQL Query Processor configuration file, 6-4 deleting rows from variable-format table, 4-13 description file, 7-2 descriptions generating SQL, 7-6 reviewing results of generating SQL, 7-3 Design Query window, 3-3, 3-20 join pane, 3-20 query table pane, 3-20 results pane, 3-22 text pane, 3-22 designating users in the SQL Query Processor configuration file, 6-7 designing a query, Query Design Center, 3-22 determining connection status, Query Design Center, 3-5 DIAGNOSE command, DMQUERY utility, 8-3 diagnostics gathering dump information, 5-15 gathering information, 5-11, 5-13 trace information, 5-13 DIALOGCHECKINTERVAL value, 2-7, 5-8 disjoint data sets default in SQL, 4-10 modeled as SQL tables, 4-10 displaying the dump file, 5-15 distributed systems services (DSS) configuration, 2-8 DMQUERY utility, 8-1 commands, 8-2 BYE, 8-2 CANCEL, 8-2 CLOSE, 8-2 COMMIT WORK, 8-2 DEFINE, 8-3 DIAGNOSE, 8-3 DO, 8-3 OPEN, 8-3 PARSE, 8-3 QD, 8-4 REPEAT, 8-4 ROLLBACK WORK, 8-4 SAVEPOINT, 8-4 SET, 8-4 SHOW, 8-6 files, 8-9 running in batch mode, 8-7 running through CANDE, 8-7 using SQL statements, 8-1 DMSQL command, 5-5 DMSQL HELP command, 5-6 DMSQL SHOW STATUS command, 5-10 DMSQL/CONFIG file, creating, 2-5 DMSQL/SERVER/CONFIG, server configuration file, 2-6 DO command, DMQUERY utility, 8-3 DSS (distributed systems services) configuration, 2-8 dump file, 5-15 E editing SQL Query Processor configuration file, 5-2, 6-4, 6-11 embedded data sets mapped in SQL, 4-14, 4-17, 4-19, 4-23 modeled as SQL tables, 4-14 embedded subsets, not modeled in SQL, 4-23 embedded table, 4-17 deletions, 4-15 for DASDL duplicates, SQL example of, 4-19 enabling Index 3

172 Index manual commit mode, Query Design Center, 3-15 SQL access, 7-5 trace facility on SQL Query Processor server, 5-13 enabling tracing, Query Design Center, 3-26 Enterprise Database Server base tables, SQL views of, 4-23 data item types, modeled in SQL (table), 4-23 databases, 5-4 updating with SQL queries, 2-22 names used in SQL description, 4-9 restart data set, modeled as SQL table, 4-25 subsets, default modeling, 4-23 Enterprise Database Server data set updating with SQL queries, 2-22 error messages, B-2 F file compression, 5-8 files displaying dump, 5-15 DMQUERY utility, 8-9 input, 7-4 program dump, 5-15 results, 7-3 SQL Query Processor configuration, 5-2, 5-3, 6-11 (See also SQL Query Processor configuration file) type required for the SQL Query Processor configuration file, 6-4 fixed-length strings, from occurring items in global data, 4-15 function names, manually assigning, 2-4 G generating a QDump, Query Design Center, 3-19 generating a QGraph, Query Design Center, 3-18 generating SQL description, 7-6 getting the SQL schema, Relational Design Center, 4-36 global data defaults in SQL, 4-10 global tracing, 5-13 grants, 4-29 purpose, 4-13 group defaults, 4-25 applied to SQL occurring items, 4-25 H handling naming conflicts in SQL, 4-9 hardware requirements, 2-2 HELP command, 5-6 help information, obtaining, 5-6 I icons Catalog window, 3-6 Relational Design Center, 4-3 identifier, base release, 6-6 identifier, resource, 6-11 identifier, worker, 5-10 identifying server log, 5-11 importing a relational schema, Relational Design Center, 4-31 index properties, Relational Design Center, 4-5 initial values in SQL mapping, 4-22 initialization of SQL Query Processor server, 5-7 INITIALVALUE data item option, modeled in SQL, 4-24 input file, 7-4 installation tasks, optional, 2-9 installing the SQL Query Processor MCP environment, 2-3 troubleshooting, 2-16 Windows environment, 2-11 integrity constraints creating in Relational Design Center, 4-45 modifying in Relational Design Center, 4-46 interface Query Design Center, 3-3 Relational Design Center, 4-2 internationalization, 6-11 IP address worker, 5-10 isolation levels, setting in Query Design Center, 3-16 Index

173 Index J join pane, Design Query window, 3-20 K Kerberos authentication, setting up, A-1 keys foreign, 4-26 primary, 4-26 column, 4-14 L limit clause, 6-13 linear search of master table, 4-16 links, defaults in SQL, 4-25 LIST command, 7-8 listing status of the SQL Query Processor server, 2-21 loading the schema, Relational Design Center, 4-37 LOG command, 5-11 logging diagnostic information, 5-11 logical database, 6-11, 7-6, 7-8 title, 6-12, 7-6, 7-9 M maintenance options for occurrence indexes in SQL, 4-16 making the SQL Query Processor configuration file, 6-4 manual commit mode, enabling in Query Design Center, 3-15 manual subsets, not modeled in SQL, 4-23 mapping accesses, 4-23 bit vector physical organization sets, 4-23 DASDL embedded data set, 4-17 DASDL example duplicates, 4-19 embedded data set in SQL, 4-21 occurring items, 4-17 embedded data sets, 4-14, 4-17, 4-19, 4-23 Enterprise Database Server data item types as SQL attribute types (table), 4-23 initial values, 4-22 nonoccurring groups, 4-25 occurrence index, 4-15 occurring groups, 4-25 occurring item, 4-15, 4-17 physical options, 4-25 relational, 4-8 restart data set, 4-25 sets, 4-23 simple data items (table), 4-23 SQL example of variable-format data sets, 4-11 subsets, 4-23 unordered list physical organization sets, 4-23 variable-format data sets, 4-10 master rows deleting, 4-15 row additions and, 4-22 master table, linear search, 4-16 MCP environment hardware requirements, 2-2 installing the SQL Query Processor, 2-3 reinstalling SQL Query Processor, 2-15 removing SQL Query Processor, 2-13 software requirements, 2-2 uninstalling SQL Query Processor, 2-13 menu bar Query Design Center, 3-4 Relational Design Center, 4-7 migrating from an earlier release, 2-12 mix number, worker, 5-10 mode, database access, 5-2, 6-11, 6-12 modeling embedded data sets, 4-14 embedded levels, example, 4-14 embedded tables, 4-14 nonoccurring items, 4-15 occurring items, 4-14 physical set organizations, 4-23 REQUIRED and INITIALVALUE data item options, 4-24 MODIFY, WFL command, 5-7 modifying resource definitions, 5-3 modifying, in Relational Design Center access rights to database structures, 4-43 data items, 4-41 data sets, 4-39 indexes, 4-41 integrity constraints, 4-46 occurring items, 4-40 SQL database, 4-37 SQL dates, Index 5

174 Index N SQL views, 4-47 variable-format items, 4-40 names defaults in SQL, 4-9 handling conflict of, 4-9 SQLVIEW results file, 7-3 naming the SQL Query Processor configuration file, 6-3, 6-4 network access point, 5-7 automatic initialization, 5-7 specification, 5-7 SQL Query Processor, 5-8 nonoccurring groups in SQL mapping, 4-25 nonoccurring items, modeled in SQL, 4-15 O occurrence indexes, mapped in SQL, 4-15 occurring groups in SQL mapping, 4-25 occurring item properties, Relational Design Center, 4-5 occurring items in global data, modeled in SQL, 4-15 in SQL, initial values and, 4-22 mapped in SQL, 4-15, 4-17, 4-19 modeling, 4-14 occurring table, 4-17 SQL example of for DASDL duplicates, 4-19 OPEN command, DMQUERY utility, 8-3 opening a database, Relational Design Center, 4-34 opening a query, Query Design Center, 3-15 opening tables, Query Design Center, 3-9 optimizer, 4-14 SQL query, 4-18 optional installation tasks, 2-9 options for maintaining occurrence indexes in SQL, 4-16 output view, Relational Design Center, 4-6 P PARSE command, DMQUERY utility, 8-3 password conventions, starting Query Design Center, 3-2 physical option defaults, mapped in SQL, 4-25 physical set organizations, modeled in SQL, 4-23 port number, TCP/IP, 5-8 preparing and executing a query, Query Design Center, 3-14 preparing database as resource, 5-4 primary key column, 4-14 primary key properties, Catalog window, 3-8 printer backup file, for program dump, 5-15 program dump, 5-15 program specification, 6-8 properties view Catalog window, 3-7 Relational Design Center, 4-3 Q QD command, DMQUERY utility, 8-4 QDump, generating in Query Design Center, 3-19 QGraph, generating in Query Design Center, 3-18 Query Design Center, 1-4 Analyze Query window, 3-3, 3-11 Catalog window, 3-3, 3-6 creating a savepoint, 3-17 customizing, 3-24 default properties, 3-24 described, 3-1 Design Query window, 3-3, 3-20 designing a query, 3-22 determining connection status, 3-5 enabling manual commit mode, 3-15 enabling tracing, 3-26 generating a QDump, 3-19 generating a QGraph, 3-18 interface, 3-3 menu bar, 3-4 opening a query, 3-15 opening tables in Catalog window, 3-9 preparing and executing a query, 3-14 rolling back to a savepoint, 3-17 saving a query, 3-14 saving query results, 3-15 setting isolation level for transaction, 3-16 setting row limit for queries, 3-17 starting, 3-1 Index

175 Index viewing column results in Catalog window, 3-10 viewing table results in Catalog window, 3-9 query optimizer, 4-18 query table pane, Design Query window, 3-20 query, designing in Query Design Center, 3-22 R referential integrity constraints, SQL, 4-25 refreshing a database, Relational Design Center, 4-35 reinstalling SQL Query Processor in the MCP environment, 2-15 in the Windows environment, 2-15 Relational Design Center, 1-4 adding a server, 4-30 applying schema modifications, 4-37 assigning access rights, 4-42 creating integrity constraints, 4-45 SQL database, 4-32 SQL dates, 4-44 SQL views, 4-47 data item properties, 4-4 data set properties, 4-4 database properties, 4-4 described, 4-1 getting the SQL schema, 4-36 icons, 4-3 importing a relational schema, 4-31 index properties, 4-5 interface, 4-2 loading the schema, 4-37 menu bar, 4-7 modifying access rights to database structures, 4-43 data items, 4-41 data sets, 4-39 indexes, 4-41 integrity constraints, 4-46 occurring items, 4-40 SQL database, 4-37 SQL dates, 4-45 SQL views, 4-47 variable-format items, 4-40 occurring item properties, 4-5 opening a database, 4-34 output view, 4-6 properties view, 4-3 refreshing a database, 4-35 removing a database, 4-35 removing a server, 4-30 restoring a database, 4-36 saving the schema, 4-36 starting, 4-2 tree view, 4-3 user assistance view, 4-6 variable-format item properties, 4-6 working with databases, 4-34 working with schemas, 4-39 working with servers, 4-30 relational mapping, SQL, 4-8 release identifier, denoting in the SQL Query Processor configuration file, 6-5 release level, associating with users, 6-7 release specification, 6-4 default, 6-4 syntax for, 6-5 removing a database, Relational Design Center, 4-35 removing a server, Relational Design Center, 4-30 removing SQL Query Processor from the MCP environment, 2-13 from the Windows environment, 2-15 REPEAT command, DMQUERY utility, 8-4 report server log, 5-11 SQL Query Processor server status, 5-10 reporting on an SQL description, 7-8 repository, 5-2 attributes, 5-2 REQUIRED data item option, modeled in SQL, 4-24 requirements hardware, 2-2 MCP environment software, 2-2 software, 2-2 updating Enterprise Database Server data set with SQL queries, 2-22 updating Enterprise Database Server database with SQL queries, 2-22 Windows environment software, 2-3 resolving naming conflicts, 4-9 resource, 5-2 configuration, 5-2 modifying definitions, 5-3 preparation, 5-4 resource identifier, 6-11 resource properties, Catalog window, Index 7

176 Index resource specification, 6-11 restart data set defaults, 4-25 restoring a database, Relational Design Center, 4-36 results file accessing, 7-3 contents, 7-3 default name with Schema Administrator command interface, 7-3 results pane Analyze Query window, 3-12 Design Query window, 3-22 ROLLBACK WORK command, DMQUERY utility, 8-4 rolling back to a savepoint, Query Design Center, 3-17 row additions in relation to master row, 4-22 row limit, setting in Query Design Center, 3-17 S savepoint creating in Query Design Center, 3-17 rolling back to in Query Design Center, 3-17 SAVEPOINT command, DMQUERY utility, 8-4 saving query results, Query Design Center, 3-15 query, Query Design Center, 3-14 schema, Relational Design Center, 4-36 Schema Administrator command interface, 7-8 generating SQL description, 7-6 LIST command, 7-8 schema, viewing SQL, 7-3 security accesses and permissions, 4-28 SQL grants, 4-29 SQL views, 4-29 views and grants, 4-28 server configuration file DMSQL/SERVER/CONFIG, 2-6 server resources, 5-2 SET command, DMQUERY utility, 8-4 sets, defaults in SQL, 4-23 setting look and feel, Query Design Center, 3-5 row limit, Query Design Center, 3-17 timeout intervals, SQL Query Processor server, 5-9 transaction isolation level, Query Design Center, 3-16 setting up Kerberos authentication on Windows, A-1 SHOW command, DMQUERY utility, 8-6 SHOW STATUS command, 5-10 SL/CONFIG file (See SQL Query Processor configuration file) software associating with users, 6-7 identifying location in the SQL Query Processor configuration file, 6-6 software release denoting in the SQL Query Processor configuration file, 6-5 software requirements, 2-2 specifying users in the SQL Query Processor configuration file, 6-7 SQL (See Structured Query Language) SQL catalog, 7-2 SQL dates creating in Relational Design Center, 4-44 modifying in Relational Design Center, 4-45 SQL queries updating Enterprise Database Server data set with, 2-22 updating Enterprise Database Server database with, 2-22 SQL Query Processor benefits, 1-4 closing trace files, 5-14 components, 1-4 described, 1-3 enabling trace facility, 5-13 hardware requirements, 2-2 installing in MCP environment, 2-3 installing in Windows environment, 2-11 network, 5-8 optional installation tasks, 2-9 overview, 1-1 Query Design Center, 1-4 reinstalling in the Windows environment, 2-15 reinstalling on MCP system, 2-15 Relational Design Center, 1-4 removing from the MCP environment, 2-13 removing from the Windows environment, 2-15 resource specification, 6-11 resources, configuring, 5-2 server automating initialization, 5-7 Index

177 Index closing trace files, 5-14 configuration, 5-5 controlling, 5-5 enabling trace facility, 5-13 log, 5-11 setting timeout intervals, 5-9 starting, 5-5 status, 5-10 stopping, 5-5 task, SYSTEM/DMSQL/WORKER, 5-4 terminating, 5-6 trace information, identifying trace file, 5-13 trace information, viewing, 5-13 troubleshooting, 2-16 server log contents, 5-12 identifying, 5-11 software requirements, 2-2 uninstalling from the MCP environment, 2-13 uninstalling from the Windows environment, 2-15 SQL Query Processor configuration control facility, 6-2 SQL Query Processor configuration file, 5-2, 5-3, 6-2 base release identifier, 6-6 CCS clause, 6-13 changing name and location, 2-6 constructing release identifiers, 6-6 contents of, defining, 6-4 creating, 2-5, 6-4 default release specification, 6-10 determining the name of, 6-3 editing, 5-2, 6-4, 6-11 limit clause, 6-13 program specification, 6-8 release identifier, 6-5 release specification, 6-4 resource specification, 6-11 samples of, 6-16 software location and, 6-6 syntax for, 6-4 user specification, 6-7 SQL schema, getting in Relational Design Center, 4-36 SQL statements, using in DMQUERY utility, 8-1 SQL views creating in Relational Design Center, 4-47 modifying in Relational Design Center, 4-47 SQL-capable data sources, 5-4 SQLColumns command, 3-10 SQLForeignKeys command, 3-10 SQLPrimaryKeys command, 3-10 SQLStatistics command, 3-10 SQLVIEW command, 5-4, 7-6 starting Query Design Center, 3-1 Relational Design Center, 4-2 SQL Query Processor server, 5-5 statistics, retrieving, 3-10 status of SQL Query Processor server, 5-10 stopping the SQL Query Processor server, 5-5 Structured Query Language (SQL) data construct, 4-26 data item defaults, 4-23 databases, 5-4 default modeling of Enterprise Database Server data item types (table), 4-23 default names, 4-9 disjoint data set defaults, 4-10 embedded data set defaults, 4-14 enabling access for, 7-5 example embedded table, 4-17 embedded table for DASDL duplicates, 4-19 mapping of DASDL duplicates, 4-19 mapping of DASDL embedded data sets, 4-17 mapping of DASDL occurring items, 4-17 modeling of variable-format data sets, 4-10, 4-11 occurring items, 4-14 occurring table, 4-17 occurring table for DASDL duplicates, 4-19 variable-format table, 4-13 global data defaults, 4-10 grants, 4-29 group defaults, 4-25 initial values, 4-22 link defaults, 4-25 maintenance options for occurrence indexes, 4-16 modeling ALPHA data items, 4-24 naming conflicts, resolving, 4-9 naming rules, 4-9 occurring item defaults, 4-14 physical option defaults, 4-25 query optimizer, Index 9

178 Index referential integrity constraints, 4-25 restart data set defaults, 4-25 set and access defaults, 4-23 subset defaults, 4-23 tables modeled from disjoint data sets, 4-10 modeled from embedded data sets, 4-14 modeled from occurring items, 4-22 modeling, 4-16 viewing schema, 7-3 views, 4-29 subsets defaults, 4-23 not modeled in SQL, 4-23 SYSTEM/DMSQL/WORKER task, 5-4 SYSTEM/SIM/CONFIG library determining the name of the SQL Query Processor configuration file, 6-3 tree view Catalog window, 3-6 Relational Design Center, 4-3 troubleshooting, B-1 troubleshooting SQL Query Processor server, 2-16 listing server status, 2-21 verifying configuration file contents, 2-19 configuration file location, 2-18 distributed systems services (DSS) information, 2-20 release identifiers, 2-16 SCode compiler system library, 2-17 server code file, 2-19 server provider, 2-20 SL configuration system library, 2-16 SQL driver system library, 2-18 TPC/IP endpoint, 2-21 T table properties, Catalog window, 3-7 tables, modeled in SQL, 4-16 from disjoint data sets, 4-10 from embedded data sets, 4-14 from occurring items, 4-14 TCP/IP distributed systems services (DSS), configuring, 2-8 IP address of worker, 5-10 port number, 5-8 syntax, 2-6 terminating the SQL Query Processor server, 5-6 terminology conventions, 1-1 text pane Analyze Query window, 3-11 Design Query window, 3-22 TIMEOUT specification, 5-7 timeout specification, TCPIP syntax, 2-6 title of the SQL Query Processor configuration file, determining, 6-3 TRACE command, 5-14 trace file closing, 5-14 creating, 5-13 trace information diagnostic, 5-13 enabling, 5-13 viewing, 5-13 U uninstalling SQL Query Processor in the MCP environment, 2-13 in the Windows environment, 2-15 unordered list physical organization sets mapped in SQL, 4-23 subsets, not modeled in SQL, 4-23 updating Enterprise Database Server data sets with SQL queries, 2-22 Enterprise Database Server database, 2-12 Enterprise Database Server databases with SQL queries, 2-22 SQL database definition, 2-12 USAGE KANJI, modeled in SQL, 4-24 user assistance view, Relational Design Center, 4-6 user specification, 6-4, 6-7 usercode, 5-10 usercode conventions, starting Query Design Center, 3-2 V value BLOCKEDTIMEOUT, 5-8 DIALOGCHECKINTERVAL, 5-8 Index

179 Index variable-format data sets mapping in SQL, 4-10 SQL example of mapping, 4-10, 4-11 variable-format item properties, Relational Design Center, 4-6 variable-format table deleting rows, 4-13 example, 4-13 verifying contents of the configuration File, 2-19 distributed systems services (DSS) information, 2-20 existence of SQL Query Processor configuration file, 2-18 release identifiers, 2-16 SCode compiler system library, 2-17 server code file, 2-19 server provider, 2-20 SQL driver system library, 2-18 SQL Query Processor configuration system library, 2-16 TCP/IP endpoint, 2-21 viewing column results in Query Design Center, 3-10 log information, 5-11 results of generating an SQL description, 7-8 table results in Query Design Center, 3-9 views, 4-29 views and grants, 4-28 W WFL job, 7-8 what s new in guide, 1-2 Windows environment hardware requirements, 2-2 installing from ClearPath MCP server, 2-11 installing SQL Query Processor, 2-11 reinstalling SQL Query Processor, 2-15 removing SQL Query Processor, 2-15 setting up Kerberos authentication, A-1 software requirements, 2-3 uninstalling SQL Query Processor, 2-15 Work Flow Language (WFL) job, using, 7-8 MODIFY command, 5-7 worker identifier, 5-10 IP address, 5-10 mix number, 5-10 usercode, 5-10 working with databases, Relational Design Center, 4-34 schemas, Relational Design Center, 4-39 servers, Relational Design Center, Index 11

180 Index Index

181 .

182 2010 Unisys Corporation. All rights reserved. * *