25
System i – DDL vs DDS In today’s world using SQL / DDL is the obvious path to managing our database objects. This has long been true with the other Database Management Systems and is the future path for the System i. There are major differences in the way DDL objects are treated by the OS resulting in improvements in data integrity and performance. Let’s get a better understanding of why this is the path we should take and how to get there. SQL Terminology What is SQL / DDL ? Overview The History of SQL What are the Advantages of using SQL/DDL ? The Primary Advantages of using DDL instead of DDS Data Integrity – Data Validation Differences Data Integrity – Referential Integrity Performance – Access Path Performance SQL / DDL Language Basics Most common DDL statement examples DB2 Sequence Objects How to build / Execute DDL scripts i Series Navigator using PDM DDS to DDL Conversion i Series Navigator Using API’s within PDM Good Practices Presented by : Chuck Walker The System Solutions Group, llc

System i - DDL vs DDS Presentation

Embed Size (px)

Citation preview

Page 1: System i - DDL vs DDS Presentation

System i – DDL vs DDS

In today’s world using SQL / DDL is the obvious path to managing our database objects. This has longbeen true with the other Database Management Systems and is the future path for the System i. Thereare major differences in the way DDL objects are treated by the OS resulting in improvements in dataintegrity and performance. Let’s get a better understanding of why this is the path we should take andhow to get there.

SQL TerminologyWhat is SQL / DDL ?

OverviewThe History of SQL

What are the Advantages of using SQL/DDL ?The Primary Advantages of using DDL instead of DDSData Integrity – Data Validation DifferencesData Integrity – Referential IntegrityPerformance – Access Path Performance

SQL / DDL Language BasicsMost common DDL statement examplesDB2 Sequence ObjectsHow to build / Execute DDL scriptsi Series Navigatorusing PDM

DDS to DDL Conversioni Series NavigatorUsing API’s within PDM

Good Practices

Presented by : Chuck WalkerThe System Solutions Group, llc

Page 2: System i - DDL vs DDS Presentation

SQL Terminology

Term /Acronym

Description

SQL Structured Query Language

DDL DDL (Data Description Language) is a subset of the SQL Language that containsstatements to create and modify database objects. These statements include those tocreate, modify, and drop table and index definitions, create and modify Views, as wellas to grant and revoke authorities on these objects.

DML DML ( Data Manipulation Language) is a subset of the SQL Language that containsstatements to modify values within our database objects. Most commonly thesestatements are used to Add, Change and Delete data within tables.

DDSDDS (Data Description Specifications) is a Specification Language used to define theattributes of several external file types. These files are the physical, logical, display,printer, and ICF (intersystem communications function) files.

RDBMS Relational Data Base Management System – A general term used to describe today’sdatabase systems such as SQL Server, Oracle, Sybase, DB2, etc.

RLA Record Level Access. Typically used to refer to Reads, Chains, Updates, etc. in aHLL program.

System i SQLLibrary Collection or SchemaPhysical File TableLogical File – Keyed IndexLogical File – Non Keyed ViewRecord RowField Column

Page 3: System i - DDL vs DDS Presentation

What is SQL / DDL ?

Overview:The evolution of the i Series has resulted in a mixture of older and newer technologies. Most notablyare the methods used to create, populate and manipulate databases. The technologies vary widely between theearly days and today.

In the early days of the AS400 DDS (Data Description Specifications) was the most common and efficient way ofcreating and manipulating data through Physical and Logical files and Record Level Access (RLA) in the HLL(High Level Language) programs. Although SQL was available the underlying SQL engine was painfully slow.As a result developers and system administrators where discouraged from using SQL in the development process.This, as well as the fact that most System 36 and System 38 programs already used DDS and RLA processingmethods, the primary development process was DDS. In the early days IBM AS400 training classes in DatabaseDevelopment taught primarily DDS. SQL / DDL, although mentioned, wasn’t the primary focus.

As a result many of the System i applications in use today still use DDS with record level access to the DB2-400files through RPG or COBOL. All other Relational Database Management Systems (RDBMS) use StructuredQuery Language, or SQL, to define their tables, indexes, and views as well as access the data.

Over time IBM has greatly improved the SQL Query Engine and it is now more efficient than using DDSdescribed files. In recent years the only improvements and enhancements to the database architecture for i SeriesDB2 are being made to the SQL described database objects and the SQL Query Engine.

In years gone by IBM typically addressed performance issues in the AS400 / system i with the primary approachof throwing more hardware at the problem. Over the years great improvements were made in disk access speed,processor speed, etc. Space, both on disk and memory, is not only much more efficient but is now relativelycheap compared to what it used to cost. The focus of IBM now to remedy performance issues is the softwaremethods used.

Because of this many companies that use the i Series are using SQL DDL to define their database objects andembedded SQL DML to manipulate their data in RPG and COBOL programs for all new applications andconverting their old applications to do the same. So, the question may before long not be IF you should make thattransition, but WHEN.

Is there a way that these applications can take advantage of SQL database enhancements without a totalrewrite? Yes. The IBM Redbook "Modernizing iSeries Application Data Access - a Roadmap Cornerstone"addresses this and the conversion process. We will also look at some of the conversion methods later in thispresentation.

The History of SQLIn 1970, Dr. E.F. Codd, an employee of IBM, presented a relational model for databases. Hisideas were the groundwork for all modern Relational Database Management Systems(RDBMS). The Structured English Query Language (SEQUEL) was developed in 1974 byD.D. Chamberlin, an employee at IBM’s lab in San Jose (California) and renamed StructuredQuery Language (SQL) three years later. The first commercial database with relationalcapabilities was introduced with IBMs System/38, the predecessor of the AS/400 and iSeries.The language SQL is not proprietary. This, and the fact that both the American NationalStandards Institute (ANSI) and the International Standards Organization (ISO) formed SQLStandards committees in 1986 and 1987, were major reasons for SQL to become a widelyaccepted standard that is implemented in almost all RDBMSs.So far three standards have been published by the ANSI-SQL group. SQL1 (1989), SQL2 (1992), andSQL3 (1999).

From IBM Redbook – Modernizing IBM @ Server iseries Data Access – A Roadmap Cornerstone

Page 4: System i - DDL vs DDS Presentation

The Advantages of Using DDL instead of DDS :

There are a variety of reasons to use SQL Data Definition Language (DDL) rather than Data DefinitionSpecifications (DDS) to define your iSeries physical and Logical files (or tables, indexes, and views, asthey're known in SQL terminology). Many SQL functions aren't available in DDS (e.g., views withsummary values), and SQL is both IBM's and the industry's standard database language. But there'sanother important reason - Performance. For many situations, access is faster for files defined with SQLDDL than with DDS.

The primary advantages of using DDL instead of DDS for your database object creation and SQL foryour database access methods are :

Industry Standard Compliance : SQL / DDL is the most widely used standard across Relational Data Base ManagementSystems for creating database objects.Data integrity: Because data validation is done when data is added as opposed to when data is read it helps to insure thereliability of data in your databases. Also, business rules may be applied to further validate data.Performance: IBM is investing money on improving database access through SQL. No enhancements to the underlyingarchitecture are being targeted for DDS created objects or Record Level Access methodology.Functionality: Some new functions require SQL.System Openness: Using modern technologies to maintain and access your database provides you with more and betteroptions to access your database using third-party tools.

In this presentation we will look at the performance differences in the two approaches and the actualprogramming differences in managing and accessing your physical and logical files.

As programmers we see more and more skill requirements in the marketplace for programmers withembedded SQL experience as well as programming without F Specs. This is where it all starts.

Page 5: System i - DDL vs DDS Presentation

Data Integrity – Data Validation Differences

A DDS Physical File is created from a source member of type PF with a CRTPF command.A DDL Table is created from a SQL script with a Create Table SQL Statement.

With a DDS created Physical File data is validated when a Read occurs. We have all run into thesituation where our application programs get data decimal errors from trying to read a record that hasgarbage, or non-numeric data in a numeric field. This is possible because the Write doesn’t do the datavalidation. Therefore garbage data can end up in the file if our programs that do the write don’t havedata validation in them.

With a DDL created Table data validation occurs when a record is Written instead of when a Readoccurs. This prevents garbage data from being inserted into the file. Therefore data decimal errors areavoided and the integrity of our numeric and date fields is insured.

Let’s consider the impact that these two methods have on the I/O operations. Obviously the datavalidation requires some additional overhead. In the typical life cycle of a File / Table record the recordis written once, updated occasionally, and read many times by different programs. With a DDL definedtable the data validation overhead occurs only once during the Write or Insert operation. With a DDSdefined Physical File the data validation overhead occurs each time an application program reads therecord. Obviously the DDL table will have better performance just for this reason.

Write

Passed

ReadFailed

Read

Passed

WriteFailed

DDSPF

DataValidation Application

Program

Eception Error

DDLTable

DataValidation

ApplicationProgram

Exception Error

Page 6: System i - DDL vs DDS Presentation

Data Integrity – Referential Integrity

Referential integrity is a fundamental principle of database theory and arises from the notion that adatabase should not only store data, but should also actively seek to ensure its quality. Referentialintegrity is a database constraint that ensures that references between data are indeed valid and intact.Referential integrity is usually enforced by the combination of a primary key and a foreign key.It ensures that every foreign key matches a primary key.

For example, customer numbers in a customer file are the primary keys, and customer numbers in theorder file are the foreign keys. If an Order record is created the customer column in the order file mustexist in the customer file. If a customer record is deleted, the order records must also be deleted;otherwise they are left without a primary reference. If the RDBMS does not test for this, it must beprogrammed into the applications. In a nutshell Referential Integrity enforces relationships betweendifferent tables.

Below is a graphic showing the logical relationships between four different tables.

Referential Integrity constraints are used regularly in other RDBMS systems such as Oracle and SQLServer. But I rarely see them used in the System i DB2 system. Referential Integrity constraints are notexclusive to DML database management either.

We have the ability to use constraints with DDS files. A constraint is defined for DDS Physical Fileswith the Add Physical File Constraint (ADDPFCST) command. You can also use the CHGPFCST,RMVPFCST, WRKPFCST, EDTCPCST and DSPCPCST commands. Although these contstraints areavailable for DDS files it is extremely rare to see them in use. Most System i programmers don’t evemrealize they are available. It may very well be worth considering these types of data integrity checks inour design as we convert our physical files to DDL tables.

Although Referential Integrity is a good way to ensure the quality of your systems data it’s not an easything to implement within a system that has existed for years without it. In spite of data validationwithin application programs any system with much age on it will have plenty of orphan records. So it islikely to take a significant amount of data cleanup before Referential Integrity constraints can beimplemented.

Item MasterItem NumberItem DescriptionVendor IDItem CategoryItem CostItem PriceStatus CodeReorder Level

Order DetailOrder NumberLine NumberItem NumberQty OrderedUnit PriceExtended PriceLine Status Code

Order HeaderOrder NumberCustomer NumberPO NumberOrder DateShip DateOrder Amount

Customer MasterCustomer NumberCustomer NameStatus CodeCredit LimitStreet AddressCityStateZip Code

Page 7: System i - DDL vs DDS Presentation

Data Integrity – Business Rules Enforcement

In today’s world of RDBMS systems one of the primary functions is data integrity. Using ReferentialIntegrity constraints is only one aspect of that. The other is the use of Stored Procedures. StoredProcedures are part of the RDBMS. Whenever possible Stored Procedures should be used to Insert.Update, or Delete records.

If all of your application programs use the same stored procedures for these functions then the obviousplace to enforce business rules restrictions is in the stored procedure.If your applications are structured in this manner then there is only one place to make changes to yourbusiness rules logic when needed.

The reason a Stored Procedure should be used is that it can be called from any platform (Web, Windows,etc) as well as a static call from an RPG program.

Order Entry –Manual Input –Telephone Sales

Incoming Order -Web applicationorder.

Incoming Order -EDI Order

Stored Procedure

Order validation / post.

OrderHeaderTable

OrderDetailTable

Page 8: System i - DDL vs DDS Presentation

Performance – Access Path Performance

Modernizing Database Access - The Madness Behind the Methodsby Dan Cruikshank is an article that talks extensively about database engineering as well as theperformance differences between the access paths used for DDL tables and DDS Physical and Logicalfiles.

Since V4R2 an access path created via SQL/DDL has a logical page size of 64K. A DDS keyed logicalfile will create, on average, an 8K access path up to a maximum size of 32K.

In this article It shows a comparison of running a SELECT COUNT(*) SQL statement over identicalfiles, one keyed Logical file and one SQL Index. Because of the access path differences the SQL Indexis processed more than 3 times faster than the Logical file.

He also compares using SQL defined Indexes and DDS defined Logicals to going the speed limit in theHOV lane as opposed to sitting in rush hour traffic in the slow lanes because of the access path size andthe access path sharing that is done with SQL defined indexes.

Those organizations that have a large number of keyed logical files may see improvedperformance as a result of recreating the logical files after comparable SQL indexes have beencreated. This is due to the possibility that some logical files may have been created out of order(e.g. access path K1, K2 being created after access path K1 was created). Creating the accesspaths in order by most key columns first may result in fewer access paths. In addition, the firstapplication to read in an index page will benefit other applications that need to reference the sameindex page. This is because of the access path sharing with DDL defined indexes.

Page 9: System i - DDL vs DDS Presentation

SQL / DDL Language Basics

Most common DDL statement examples

Data definition language (DDL) describes the portion of SQL that creates, alters, and deletes databaseobjects as well as sets authorities for these objects. These database objects include schemas, tables,views, sequences, catalogs, indexes, and aliases.For a complete list of the DB2 DDL statements available see the IBM info center web sitehttp://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Fsqlp%2Frbafysqltech.htmWe’ll take a brief look at some of the most common DDL commands.

SQL / DDL Statement DescriptionCreate Table A table can be visualized as a two-dimensional arrangement of data that

consists of rows and columns. To create a table, use the CREATETABLE statement.

Alter Table You change the definition of a table by adding a column, changing anexisting column definition, such as its length or default value, droppingan existing column, adding a constraint, or removing a constraint.To change a table definition, use the SQL ALTER TABLE statement.

Create Index The DDL statement that defines an index on a DB2 table. It also createsan index specification (metadata that indicates to the optimizer that a datasource table has an index)

Create View The CREATE VIEW statement defines a view on one or more tables orviews.

Create Table examples :

CREATE TABLE INVENTORY(PARTNO SMALLINT NOT NULL,DESCR VARCHAR(24),QONHAND INT,PRIMARY KEY(PARTNO))

CREATE TABLE ORDERS(ORDERNO SMALLINT NOT NULLGENERATED ALWAYS AS IDENTITY(START WITH 500INCREMENT BY 1CYCLE),CUSTNO VARCHAR(10),ORDER_DATE DATE)

Page 10: System i - DDL vs DDS Presentation

ALTER Table Examples :

Constraints can be added to a new table or an existing table. You can add a unique or primary key,a referential constraint, or a check constraint, using the ADD constraint clause on the CREATE TABLEor the ALTER TABLE statements. For example, add a primary key to a new table or to an existing table.The following example illustrates adding a primary key to an existing table using the ALTER TABLEstatement.

ALTER TABLE ORDERSADD PRIMARY KEY (ORDERNO)

You can remove a constraint using the same ALTER TABLE statement:

ALTER TABLE ORDERSDROP PRIMARY KEY (ORDERNO)

Creating Indexes :

You can create any number of indexes. However, because the indexes are maintained by the system, alarge number of Indexes can adversely affect performance just as a large number of Logicals can do.

CREATE INDEX ORDIDX1ON ORDERS(CUSTNO ASC, ORDER_DATE ASC)

Creating Views :

Once you have created the view, you can use it in SQL statements just like a table name. You can also change thedata in the base table. Typically I will use a View instead of an Index when I want to join tables and / or when I

only want records with particular values included, just like a select Logical. The following SELECT statementdisplays the contents of EMP_MANAGERS: SELECT * FROM EMP_MANAGERS

CREATE VIEW EMP_MANAGERS ASSELECT LASTNAME, WORKDEPTFROM EMPLOYEEWHERE JOB = ’MANAGER’

Page 11: System i - DDL vs DDS Presentation

DB2 Sequence Objects

A sequence is an object that generates a sequence of numeric values according to the specification withwhich the sequence was created. Sequences, unlike identity columns or row ID columns, are not associatedwith tables. Applications refer to a sequence object to get its current or next value.

In most RDBMS systems database administrators and programmers are encouraged to make their firstcolumn in any new table a Record ID column that is numeric. The RDBMS may have a data type of AutoNumber which assigns the next number automatically whenever a record is added. The Record ID columnmay then defined as the Primary Key. So whenever the sort on that table is by the Primary Key then it is inarrival sequence. This key value may also be stored in other related tables as a reference.

MS SQL Server as well as MS Access are just a couple of examples for database systems that provide AutoIncrement data types to accomplish this. ORACLE and DB2 use a ROWID data type which is also autoincremented. So, the Sequence object is not typically used for this purpose. A field data type is alreadyavailable.

Historically as System i programmers we have used Data Areas to keep track of the last value for an ordernumber used, P. O. number used, etc. Within our program we take the last value, increment it by 1, updatethe data area value , and use the new number in our functions to write new records. Some applications mayuse configuration or control type physical files to accomplish the same thing. A Sequence object will do thiswithout all of the code.

You create a sequence object with the CREATE SEQUENCE statement, alter it with the ALTERSEQUENCE statement, and drop it with the DROP SEQUENCE statement. You grant access to a sequencewith the GRANT (privilege) ON SEQUENCE statement, and revoke access to the sequence with theREVOKE (privilege) ON SEQUENCE statement.The values that DB2 generates for a sequence depend on how the sequence is created. The START WITHoption determines the first value that DB2 generates. The values advance by the INCREMENT BY value inascending or descending order.

CREATE SEQUENCE ORDER_SEQ AS INTEGERSTART WITH 1INCREMENT BY 1NO MAXVALUENO CYCLE;

The MINVALUE and MAXVALUE options determine the minimum and maximum values that DB2generates. The CYCLE or NO CYCLE option determines whether DB2 wraps values when it has generatedall values between the START WITH value and MAXVALUE if the values are ascending, or between theSTART WITH value and MINVALUE if the values are descending. If the length of your order number is7,0 then your MAXVALUE should be 999,999. If you just want the number to start at 1 again the CYCLEvalue should be set to CYCLE instead of NO CYCLE.

You can then use the same sequence number as a key value for an ORDERS table indexes.

INSERT INTO ORDERS (ORDERNO, CUSTNO)VALUES (NEXT VALUE FOR ORDER_SEQ, 12345);

The NEXT VALUE expression in the INSERT statement generates a sequence number value for thesequence object ORDER_SEQ. The number 12345 is the Customer number value.So, when using a Sequence object for an order number instead of a data area all that needs to be done in aSQL Insert statement is a NEXT VALUE clause referring to the Sequence Object in the Values clause of theInsert statement.

Page 12: System i - DDL vs DDS Presentation

How to build / Execute DDL scripts

First we will look at using i Series Navigator to accomplish these tasks.

Start a Navigator session.Expand the Databases listing in the left panel and then the Schemas listing by clicking on the plus signon the left side of the listing. Library names will be displayed in the left panel as well as the right panel.Remember, a Schemas is a collection of objects and is the equivalent of what we know as a Library.

.

Notice the task list at the bottom that gives you quick access to the most common tasks withinnavigator.

Page 13: System i - DDL vs DDS Presentation

Expand the Library you’re interested in and you will see a list of the different database objects.

Right click on the object type you want to create and choose New in the pop-up menu.

System Name

Page 14: System i - DDL vs DDS Presentation

The following screen appears when selecting a New Table.

This image shows the Table Tab.

Notice the different tabs for columns, key constraints, foreign key constraints, etc.

System Name

Page 15: System i - DDL vs DDS Presentation

This image shows the Columns Tab.

Notice the Show SQL button in the bottom left corner. The SQL statement is built for you. Ifyou click on Show SQL button it will show you the SQL script generated.

Systen Name

Page 16: System i - DDL vs DDS Presentation

This image is the screen displayed when the option to Add a new column is selected.

So, you simply use this tool to step through each tab and fill in the blanks.

System Name

Page 17: System i - DDL vs DDS Presentation

This is the screen displayed when the option to add a new Index is selected.

System Name

Page 18: System i - DDL vs DDS Presentation

You may also use PDM to create a SQL script. Simply create a member in a source file withtype SQL.

Page 19: System i - DDL vs DDS Presentation

Key in your SQL script just as you would in any other type of source member. Notice thedouble hyphens are used to identify comment lines.

Execute the RUNSQLSTM command to execute the script and create your table, index, etc.

DDS to DDL Conversion

Page 20: System i - DDL vs DDS Presentation

DDS to DDL Conversion

The ProcessThe primary reasons and incentives to move your legacy DDS database to a SQL DDL defined databaseis to optimize performance and to minimize the impact of change on the business.

The files that are used the most will obviously benefit our applications when they are converted.To identify those files we can simply run a DSPFD command with a Output(*Outfile) parameter againstthe files likely to be considered. From this file you can run queries to summarize the statistical countsfor writes, updates, reads, etc. What files should be converted for the best bang for the buck shouldbecome obvious.

When we know what files we want to convert then we have 2 methods of converting them to SQL /DDL. First let’s look at the GUI method using Navigator.

i Series Navigator

In i Series Navigator drill down through Databases / Schemas.

Right click on the physical file name in the right panel. Choose the Generate SQL option.

Page 21: System i - DDL vs DDS Presentation

Then this screen appears.The SQL generated may be put into a source file by choosing the Write to file option.

The same may be done for Views but not Indexes.

We need to create SQL indexes to take advantage of the 64K access path. Since i Series Navigator doesn’t do itfor us we need to find another way. For those Logical files that do not show up in the View list the easiestprocess is just to create a SQL script or statement as a SQL member type in a source file.

Page 22: System i - DDL vs DDS Presentation

Using API’s within PDM

The second method to generating SQL script for conversion is to simply use green screen / PDM.IBM has provided an API that may be called from RPG program or CL programs that will generate SQLstatements to source members. This API can be used to generate SQL to create DDL objects fromexisting DDS objects. The API object is QSQGNDD. A couple of good articles describing the use ofthis command as well as source code that can be used to turn it into an easy to use utility arehttp://www.ibmsystemsmag.com/ibmi/developer/general/Generating-DDL-Source-Using-a-CL-Command/

andhttp://www.itjungle.com/mgo/mgo060502-story01.html .

Page 23: System i - DDL vs DDS Presentation

Good Practices

How does using DML (Data Manipulation Language) accelerate the developmentprocess and minimize the impact on the business?

When using RLA (Record Level Access) with native RPG setll, read, reade, and chain operation codesone of the primary problems with adding new fields to a physical file or lengthening an existing field isthat we then have to recompile and deploy all programs that use the file or we get level check errors.Unless, of course, we use the Level Check *No option when creating our new physical file. But there isa certain level of risk in using the Level Check *No option.

If we are using SQL / DML within our programs and we are field level specific in our programs then weonly have to recompile the programs that need to use the new fields. The others will still function asdesigned without recompiling. If you are lengthening a field you would only need to recompile theprograms that use that specific field.

This can significantly reduce the amount of time development and deployment takes and thereforereduce the impact on the business. This is, of course, if we use good practices in writing our code.

Good Practices :I often see programs written using embedded SQL that use an external physical file to define a datastructure within the program and then use a Select * SQL statement to populate the data structure.Example :D salesHeader e ds extname(SHSLSH)

exec sqlselect * into :SalesHeader from shslsh

where shinv = :shinv;

Avoid using this method. The only time I would suggest using this method is within a program that isgoing to copy the complete record structure into a different table. As a general rule Select * shouldnever be used otherwise.

First, by using this method one of the main advantages of using DML within our application programshas been nullified. When this method is used we have to recompile this program whenever we make afile change because it is dependent on the physical file structure to build the data structure. If it isn’trecompiled we will likely get some data mapping errors.

Secondly, it is very rare that an application program really needs all of the fields in a file. Many fileshave more than a hundred fields / columns. Most of our application programs need only a few of thesefields. So by pulling in the entire record instead of just the fields we need hurts performance andlengthens the development process when we need to make file changes.

It takes a little more code initially to list the fields you need in the data structure within your programand to list the fields needed in the select statement but it is well worth the extra time. Then we onlyneed to recompile the program if the program needs to use a new column added or is already using acolumn where the length has changed.

Page 24: System i - DDL vs DDS Presentation

On The CD

Type Name DescriptionPDF System i - DDL vs

DDS PresentationA copy of this presentation in PDF format.

PDF Moving from DDS toSQL

IBM Publication – This publication goes into the details behindData Modeling as well as the conversion steps needed to convert toSQL data tables.

PDF Modernizing DatabaseAccess – The MadnessBehind the Methods

By Dan CruikshankThis article provides a high level overview of the madness behindthe methods known as the Stage 1 DDS to DDL reengineeringstrategy.

PDF Modernizing IBM eserver iSeriesApplication DataAccess – A RoadmapCornerstone

IBM Redbook – This Redbook not only goes into great detail ondata modeling, design, and the conversion to SQL tables, but alsodiscusses data access through embedded SQL, creating I/O modulesfor accessing data, and moving business rules to the database.

PDF DB2 for i5 OS - SQLReference V5R4

An IBM published SQL Reference for iseries SQL. V5 R4

PDF Advanced_Databasefunctions andadministration on DB2UDB_for iSeries

This IBM Redbook covers some of the more advanced functions ofdatabase administration such as Referential Integrity and otherconstraints, data import and export, and commitment control. Italso goes into detail on the IBM tools available for these tasks.

PDF DB2 UDB SQLProgramming – V5R3

This IBM publication covers in detail the iSeries serverimplementation of the Structured Query Language (SQL) usingDB2 UDB for iSeries and the DB2 UDB Query Manager and SQLDevelopment Kit Version 5 licensed program.

PDF System i DatabaseProgramming - V5R4

This Publication covers all aspects of database programmingincluding Triggers, UDFs, and Referential Integrity.

Page 25: System i - DDL vs DDS Presentation

Helpful Links

Link Descriptionhttp://www.iprodeveloper.com/article/databasesql/performance-comparison-of-dds-defined-files-and-sql-defined-files-254

Performance Comparison of DDS-Defined Files and SQL-Defined FilesAuthor: Dan Cruikshank

http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performance_DDS_SQL.pdf

PDF link. Modernizing Database Access Author: DanCruikshank

http://www-03.ibm.com/systems/i/software/db2/ IBM DB2 for i. This site has links to resources and relateddownloads easily accessible.

http://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/servers/enable/site/education/ibp/29a2/index.html

Application Modernization: DB2 for i style. This site also hasuseful downloadable PDFs for the SQL programming languageon system i.

http://www.redbooks.ibm.com/abstracts/sg246393.html Modernizing IBM eServer iSeries Application Data Access - ARoadmap Cornerstone. An IBM Redbook site.

http://comments.gmane.org/gmane.comp.hardware.ibm.midrange/167160 Midrange.com – A technical discussion of DDS vs DDL Timecolumns.

http://comments.gmane.org/gmane.comp.hardware.ibm.midrange/152855 Midrange.com – A technical discussion on convering DDS toDDL.

http://www.mcpressonline.com/forum/showthread.php?17871-VARLEN-in-DDS-vs.-VARCHAR-in-DDL

mcpressonline.com - A tread discussing VARLEN in DDS vs.VARCHAR in DDL

http://editorial.mcpressonline.com/web/mcpdf.nsf/wdocs/5075/$FILE/5075_EXP.pdf

A PDF link – Using IBM I tools in Navigator ton convert toDDL.

http://www.iprodeveloper.com/forums/aft/95831 Article - How do you convert and store your converted DDS toDDL source?Author - Wyatt Repavich