Table of contents

About the authors.................................................................................................................. 2 Introduction ........................................................................................................................... 3 Agenda.................................................................................................................................. 4 Why SQL?............................................................................................................................. 5 Approaches and options ....................................................................................................... 7 Approaches and options (continued) .................................................................................... 8 Modernizing definitions and objects ...................................................................................... 9 Modernizing database objects: Terminology....................................................................... 10 Modernizing database definitions and objects: Tables or physical files.............................. 11 Modernizing database definitions and objects: Indexes or logical files............................... 13 Modernizing database definitions and objects: Views or logical files (continued)............... 15 Modernizing database definitions and objects: DDS-to-SQL conversion tool..................... 16 Modernizing database definitions and objects: DDS-to-SQL conversion tool..................... 17 Modernizing database definitions and objects: SQL object management .......................... 18 Modernizing database definitions and objects: SQL object management .......................... 19 Modernizing database definitions and objects: SQL object management (continued) ....... 20 Modernizing database definitions and objects (continued) ................................................. 21 Modernizing definitions and objects: SQL and nonrelational data ...................................... 22 Modernizing definitions and objects: Moving business logic into DB2 (automatic key generation) .......................................................................................................................... 23 Modernizing definitions and objects: Moving business logic into DB2 (constraints) ........... 24 Modernizing definitions and objects: Moving business logic into DB2 (triggers)................. 25 Modernizing data access .................................................................................................... 26 Modernizing data access: Programming interfaces ............................................................ 27 Modernizing data access: Native I/O to SQL example........................................................ 28 Modernizing data access: Native I/O to SQL example (Joined Logical Files and Views) ... 29 Modernizing data access: Native I/O to SQL example (performance comparison) ............ 30 Modernizing data access: Comparing SQL and native performance.................................. 31 Modernizing data access: Native to SQL considerations.................................................... 32 Modernizing data Access: Using SQL to reuse and repurpose existing code .................... 34 Modernizing data access: Using SQL to reuse and repurpose existing code (UDFs) ........ 35 Modernizing data access: Using SQL to reuse and repurpose existing code (procedures) 36 Modernizing data access: DB2 and new application models (distributed transactions)...... 37 Modernizing data access: DB2 and new application models (Web services) ..................... 38 Modernizing data access: DB2 and new application models (XML and text mining).......... 40 Modernizing data access: Development tools..................................................................... 41 Modernizing data access: Development tools (continued).................................................. 42 Next steps ........................................................................................................................... 43 DB2 Family certifications..................................................................................................... 45 Summary............................................................................................................................. 46 Links.................................................................................................................................... 48 Trademarks and special notices ......................................................................................... 50

Page 1 of 50

About the authors

Mike Cain is a senior technical staff member and the team leader of the DB2 for i5/OS Competency Center in Rochester, Minnesota, USA. Prior to his current position, he worked as a systems engineer and technical consultant. He can be reached at [email protected]. Gene Cobb is a DB2 for i5/OS technology specialist in the IBM ISV Business Strategy and Enablement organization in the System i group. He has worked on IBM midrange systems since 1988, with 10 years in the IBM Client Technology Center (CTC) in Rochester. While in the CTC, he assisted solution providers and IBM clients with application design and development using RPG, DB2 for i5/OS, CallPath/400 and Lotus Domino. His current responsibilities include providing consulting services to System i developers, with special emphasis in application and database modernization.

Page 2 of 50

IBM System i

Application Modernization: DB2 for i5/OS style

Mike Cain and Gene Cobb DB2 for i5/OS Technology Team ISV Business Strategy and Enablement - System i

Introduction
The IBM System i Developers Road Atlas (formerly called the iSeries Developer Roadmap) is one of the key initiatives from IBM in helping System i developers modernize their existing applications and toolsets. The SQL programming language and IBM DB2 for i5/OS are two modern tools that help programmers move toward more responsive, Web-enabled applications. This online course explains the modernization steps on the Road Atlas from an SQL and DB2 for i5/OS point of view.

Page 3 of 50

Agenda
Why modernize with SQL and DB2 for i5/OS? Approaches and options Modernizing database definitions Modernizing data access Next steps

Agenda
This course first discusses why you might want to modernize the DB2 aspects of your application and use SQL. Next, there is a discussion of the possible approaches and methodologies for DB2. Then, this course goes into detail on the two approaches to DB2 modernization: modernization of the database objects and their definitions (for example, moving from data-definition specifications [DDS] to SQL) and modernization of the dataaccess interfaces in application programs (for instance, moving from native I/O to SQL). This course concludes with some possible first steps you can take in modernizing applications from a DB2 and SQL perspective.

Page 4 of 50

Why SQL?
Portability of code and skills Strategic database interface for industry and i5/OS
SQE delivers faster performance (only available to SQL-based interfaces) SQL is required for certain functions and middleware
J2EE architecture based on SQL interfaces Data types: BLOB, CLOB, Datalink and others Auto-incrementing constructs: Sequence and identity column attribute Column-level triggers Encryption and decryption functions Encoded-vector indices others

Enables better positioning of System i as a database server As a programming language, SQL can reduce total lines of code DB2 symmetric multiprocessing (SMP): Parallel database processing

Why SQL?
Why should a System i developer consider using SQL? Obviously, the portability of SQL statements is one thing people latch onto, because that is the industry standard. System i DDS and native I/O interfaces are not supported on other platforms. A portability issue often overlooked is the portability of SQL programming skills. Many enterprises and application development organizations have switched to programming with SQL for this very reason it is easier to find a programmer with SQL skills than a programmer with RPG skills. Just like Java, using SQL to develop applications provides a bigger pool of programmers from which to hire. Almost all of the new solutions use SQL, which is one reason why IBM has made SQL the strategic interface for the System i platform and has put much of its research and development investment into enhancing SQL. The native (that is, non-SQL) interfaces are here to stay, but the functional improvements are primarily for SQL interfaces only. This graphic lists some SQL-only enhancements. In IBM OS/400 Version 5 Release 2, IBM delivered the SQL query engine (SQE). The improved performance offered by this new database engine is only available to SQL interfaces; native I/O interfaces receive no benefit now or in the future. Several functional capabilities also require the use of SQL. The Java 2, Enterprise Edition (J2EE) architecture obviously is based on SQL interfaces to data such as Java Database Connectivity (JDBC). The binary large object (BLOB) and character large object (CLOB) data types can only be used in SQLcreated tables. DB2 for i5/OS supports both SQL and external triggers, but only SQL triggers allow triggers to be defined at a column level. Encoded-vector indexes (EVI) are yet another example of a DB2 object that can only be created with SQL. An advantage of using SQL is that when you start incorporating more modern aspects of the DB2 for i5/OS database, it is easier to convince Microsoft and Java developers in your shop that using the System i platform as a database server is a viable option. Those developers are accustomed to using stored procedures, triggers and automatically generating columns. If those developers know that those capabilities exist

Page 5 of 50

in your DB2 for i5/OS databases, there is a greater likelihood they will write new applications or change existing applications to use your System i model as a data store. As a programming language, SQL can reduce the total lines of code that a developer has to write, because SQL is designed to work on a set of rows (or records) at a time. In comparison, native I/O works with one row at a time. A single SQL request can process multiple rows of data in one request; in the native I/O world, this takes multiple operations. DB2 Symmetric Multiprocessing (SMP) enables a single DB2 request to run in parallel across multiple processors. With SQL, parallel processing is essentially enabled by turning on the DB2 SMP feature. If you want to run parallel processing with the non-SQL interfaces, you basically have to physically change your application. The application has to be broken into partitions so each partition can run concurrently to benefit from a system with multiple processors.

Page 6 of 50

Approaches and options

ODBC, JDBC, PHP, ADO, DRDA, XDA

Network

Host server
Static
Compiled embedded statements

CLI, JDBC
Extended dynamic
Prepare once, then reference

Dynamic
Prepare every time

Native (record I/O)

SQL Optimizer

DB2 for i5/OS

(Data storage and management)

Approaches and options

To understand the approaches to modernization that are based on DB2-coding techniques, you need to know the various SQL interfaces that go into the DB2 for i5/OS database engine. The biggest difference between SQL and the native interface is the interaction with the query optimizer. This emphasizes the point that, to be successful in modernizing your application with SQL, it is necessary to have an in-depth knowledge and understanding of the query optimizer.

Page 7 of 50

Approaches and options (continued)

SQL-created objects

SQL programs

Considerations: Multimember and multiformat files

DDS-created objects

Native* programs

*Restrictions: EVIs, LOB columns, UDTs, Datalinks, and others

Approaches and options (continued)

There is not a clear, step-by-step methodology for modernizing an application from a DB2 perspective. The integrated nature of DB2 for i5/OS supports permutations and combinations. This flexibility provides a developer with many options as they move toward the ultimate goal of using SQL for both database definitions and data access. With this integrated database, you can mix and match SQL and native database interfaces. You can start modernizing by creating your database objects with SQL, and the programs using native I/O to access the data can still run. If you want to use a new DB2 function, such as column encryption, and you do not have time to convert the database objects from DDS to SQL, the program can be changed to use SQL to encrypt the data, even though the underlying objects are not defined with SQL. As you can tell, the approach that you take depends on where you want to start and what you want to do. No rigid process has to be followed.

Page 8 of 50

Modernizing definitions and objects

Terminology Moving from DDS to SQL DDL SQL object management Embedding business logic into database definitions

Modernizing definitions and objects

This chart lays out the aspects of modernizing your database objects and definitions with DB2 for i5/OS. There is a more detailed discussion about each of these over the next few charts.

Page 9 of 50

Modernizing database objects

Terminology

SQL
Schema or collection table view index row column log

i5/OS
library physical file logical file keyed logical file record field journal

Modernizing database objects: Terminology

The first thing to comprehend is the terms used by the SQL interface and how they map to i5/OS and DDS terms. The terms on the left side of this table equate to the terms on the right. Traditional System i developers are accustomed to using the terms on the right. Although the terms used might be different, the function provided is the same. However, notice that member is nowhere on the chart; there is no SQL equivalent. Most of these are self-explanatory. An SQL schema is an i5/OS library that contains both a journal and a journal receiver object, each of which is created inside of the library automatically.

Page 10 of 50

Modernizing database definitions and objects

Tables or physical files

SQL tables compared with physical files

Advantages
More data types Constraint definitions can be included in object source Faster reads Longer, more descriptive column names Support for a data-modeling tool DB2 attempts to journal tables automatically

Disadvantages
Slower writes No DDM, but SQL can utilize DRDA connections Multimember files
SQL ALIAS provides the solution: CREATE ALIAS JanSales FOR SALES (JANUARY )

Modernizing database definitions and objects: Tables or physical files

The reality is that both SQL tables and DDS physical files (PFs) create the same internal i5/OS object. However, some rules in the SQL standard cause a few differences in behavior between those two objects. These rules essentially result in SQL tables having faster reads than PFs, but slower writes. Writes are slower because the SQL standard is more stringent in dictating that no dirty data (for example, data that causes decimal data errors in programs) is allowed into the table on inserts and updates. Although the internal i5/OS object for tables and PFs is the same, the cursor that is used to write data into an SQL table has more built-in validity checks than the cursor that writes data into a DDS-created PF. Reads are slightly faster against an SQL table because the cursor that reads SQL tables does not have extra code to clean up the dirty data. Cursors that perform reads against PFs need extra code to clean up dirty data because the writes against the PFs do not prevent dirty data from getting in. This performance difference is usually small, but is noticeable to some users. The "Why SQL?" chart (shown earlier) states that more data types are available with SQL tables. The SQL Create Table statement is also more flexible in allowing for the inclusion of constraints definitions in the table definition (beside the column definitions). DDS has no support for constraints. If you add a constraint to a PF, then there is DDS source to manage for the PF definition and source to manage for the constraint definition. This means that there are two sets of source you need to manage with DDS. In contrast, SQL allows both to be managed on the CREATE TABLE statement. SQL tables also have a functional advantage of not being limited to short, cryptic-like DDS field names. SQL supports column names up to 30 characters in length and table names up to 128 bytes in length. Longer SQL identifiers allow your object names and definitions to be more self-describing from a documentation point of view.

Page 11 of 50

If you want to use data modeling tools, you have a better chance of finding tools that support DB2 for i5/OS if you use SQL to create your database objects instead of DDS. One other behavioral difference is that DB2 automatically tries to journal SQL tables. As mentioned, SQL schemas are created with a journal. DB2 looks for that schema-created journal after every CREATE TABLE request. If a journal is found, DB2 automatically journals the newly-created table to that journal. If you want to use journaling to improve database recovery and availability, this automatic-journaling behavior is simpler. If you do not plan to journal DB2 objects, you need to be aware of this default behavior and modify it accordingly (disable journaling). There are a few things to be aware of when using SQL. Distributed Data Management (DDM) SQL tables do not exist because SQL has a different solution. Instead of having a DDM file (which is an object that redirects a request to a different system), SQL uses a Distributed Relational Database Architecture (DRDA) connection. The SQL Connect statement is used to redirect your database processing to a different system or server. The database request then references the table name on that remote DB2 server directly (as opposed to the indirect access offered by DDM files). As mentioned, SQL does not support multimember files. Table-partition support in i5/OS V5R3 offers similar capabilities, but that support is limited by some performance issues that must be CAREFULLY researched before creating partitioned tables. If you have multimember files, but want to access them from an SQL application, then SQL aliases must be used. An SQL alias is a one-time setup step in which you create an alias for each member in a physical file, as demonstrated at the bottom of this chart. Then, your applications that use SQL can reference this alias name anywhere on an SQL statement that allows table names. An SQL programmer does not have to be concerned that they are accessing the fifth member of a multimember file because they know they are using an alias that allows access to that particular data set.

Page 12 of 50

Modernizing database definitions and objects

Indexes or logical files

SQL indexes compared with keyed logical files Advantages

EVI structure 64KB logical-page size (since OS/400 V4R2)
Improves performance of queries that scan lots of key values in an index (a 64 KB I/O operation brings more keys into memory) Single key lookups in index might or might not be as efficient Larger logical page size can lend itself to more efficient index maintenance Considerations:
Larger index pages can strain memory-starved environments SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of journal receivers Use RCVSIZOPT(*RMVINTENT *MAXOPT2) Journal Receiver threshold must be at least 6.5 GB

Disadvantages
8 KB logical-page size No support for Select/Omit filtering or Join logical files

Modernizing database definitions and objects: Indexes or logical files

Consider SQL indexes as compared with the DDS keyed logical files. Again, for the most part, SQL indexes and keyed logical files both cause the same internal i5/OS object to be built. The main difference is that SQL indexes can choose between a binary-radix tree structure or an advanced bitmapped index structure known as an EVI. Another small difference between these two objects is the logical page size. Since OS/400 V4R2, SQL indexes have been created with a bigger logical-page size than keyed logical files. The reasoning behind this change was that SQL requests tend to do more query processing, which results in SQL indexes frequently being scanned for a range of key values. Because a larger logical-page size allows DB2 to scan more key values on a single I/O request, SQL indexes are created with a logical-page size of 64 KB (instead of the 8 KB logical-page size used in keyed logical files). An index with a larger logical-page size can cause positive and negative performance differences. Single-key lookups might or might not be as efficient because it takes longer to read a 64 KB page than an 8 KB page. However, bringing in a 64 KB page also means that more key values must be resident in memory. Therefore, some of the singlekey lookups might be faster because a previous 64 KB page read brought that key value into memory. In general, IBM has found that the larger logical-page size makes the internal-index maintenance algorithms more efficient. Memory utilization is another item to consider before switching to the larger-page SQL indexes. If your program runs in a memory-strained environment, those bigger 64 KB pages increase the memory load. The larger page size also makes journaling a little more difficult because, when you change key values; the journal component has a 64 KB page to put on the journal instead of an 8 KB page. Some journal configuration

Page 13 of 50

settings are shown in blue in this graphic; they can improve journal performance when dealing with the larger page size. SQL indexes can be opened as keyed logical files for native I/O; this gives you native capabilities after switching from keyed logical files to SQL indexes. The SQL index record description makes all columns available when an index is opened as a logical file. SQL indexes are limited by the fact that they do not have a way to subset the keys (as do DDS-created Select and Omit logical files). This enhancement for SQL indexes is on the list of possible future enhancements for DB2 for i5/OS.

Page 14 of 50

Modernizing database definitions and objects

Views or logical files

SQL Views compared with logical files

Advantages
More flexibility in terms of selecting and processing data
CASE expressions and Date and Time functions Grouping and more advanced Join processing

Can be used as logical files to enhance native functionality

Disadvantages
Views cannot be keyed or ordered
Does that mean Views have slower performance? NO, assuming that the right set of indexes and statistics are in place for the query optimizer to use. View is used by SQL to transform data; the query optimzer's job is to find the best method to speed up selection or sorting. The fastest method might not be a keyed access method.

Modernizing database definitions and objects: Views or logical files (continued)

SQL Views are equivalent to nonkeyed logical files. SQL Views have a strong advantage in that they offer more processing and data manipulations than a logical file. These features can be performed within the View definition. SQL Views allow you to embed Case expressions and offer a suite of functions for processing and manipulating Date and Time values. The grouping and join processing offered by SQL View is far superior to anything available on a logical-file definition. Because the View has an implementation similar to an SQL View, a native program can open that View as a logical file. Some of the more complex SQL functions cause the View to be classified as a read-only View (meaning native writes are not allowed). Some programmers are concerned because SQL Views cannot be keyed, nor can they have an index created over them. The issue is that this makes SQL Views automatically slower than logical files. The reality is that SQL Views can provide the same thing, but it is done indirectly. The programmer defines an SQL View to perform the data transformations. Instead of the programmer creating an index over the View, it is the query optimizer's job to figure out the fastest way to access the tables referenced in the View definition. The programmer or administrator must ensure that a good set of indexes and statistics are in place for the optimizer to use for the implementation of the View. When it makes sense from a performance perspective (index scans are not always fastest), the query optimizer uses keyed/indexed access whenever the View is referenced; this indirectly provides the same performance characteristics as a keyed logical file.

Page 15 of 50

Modernizing database definitions and objects (continued)

DDS-to-SQL conversion tool

iSeries Navigator Generate SQL Task (QSQGNDDL API)

Useful in converting object definitions from DDS to SQL Supports physical and logical files
Not all DDS features can be converted, tool converts as much as possible and generates warnings for unconvertible options (for example, EDTCDE) Logical files converted to SQL Views SQL Field Reference File support not used

Can convert a single object or a group of objects Output can be edited and saved directly into source-file members

Modernizing database definitions and objects: DDS-to-SQL conversion tool

In some cases, you might decide to convert your existing DDS objects to SQL. If so, there is a tool available to help with this conversion. The Generate SQL task in iSeries Navigator provides a graphical interface to the QSQGNDDL i5/OS API. This tool automates the simple DDS-to-SQL data-type conversion, leaving you time to deal with any DDS features that do not have an SQL equivalent. The tool helps manage your new SQL CREATE TABLE source statement by allowing the output from the tool to be stored in a source physical-file member on your server.

Page 16 of 50

Modernizing database definitions and objects

DDS-to-SQL conversion tool

Modernizing database definitions and objects: DDS-to-SQL conversion tool

Here is an example of the iSeries Navigator interface that assists in your efforts to convert DDS to SQL. Right-click a schema and select the Generate SQL option. The next window displays the list of all database objects in that schema. You have the ability to add more database objects to this list. Simply click the Add button to do this. You have two options for output: Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements). Write the statements to a source physical-file member. You can later use the RUNSQLSTM CL command to execute the statements in the source file member. When you are ready, click the Generate button to create the scripts to the specified output option.

Page 17 of 50

Modernizing database definitions and objects

SQL object management

SQL source-management best practices:

Just like DDS SQL, source can be stored in source physical-file members and referenced with the RUNSQLSTM CL command (instead of CRTPF and CRTLF)
If change management tools are not specific to i5/OS, store SQL scripts in PC or IFS files If SQL source is misplaced, Generate SQL can be used to retrieve the SQL source from System Catalogs (SYSIBM and QSYS2)

SQL Table definitions can use Field Reference File CREATE TABLE customer AS (SELECT id cust_id, lname cust_lastname, fname cust_firstname, city cust_city FROM RefFile) WITH NO DATA

Might need to adjust process for moving from development to production

Best practice is to reexecute the SQL creation script Save and Restore process for SQL databases documented at: ibm.com/developerworks/db2/library/techarticle/0305milligan/0305milligan.html

Modernizing database definitions and objects: SQL object management

One of the more common questions for System i users who are considering switching from DDS to SQL is: How do I manage my SQL source statements? For the majority of traditional programmers, the answer is: The same way. Just store your SQL CREATE statements in a source physical-file member as you do with DDS source. Then, instead of pointing the CRTPF or CRTLF CL command at DDS source, use the RUNSQLSTM CL command to run the SQL statements in the specified source member to create your DB2 objects. One disadvantage that SQL tables had in the past was a lack of support for field reference files. OS/400 V5R2 fixed this issue with the CREATE TABLE LIKE enhancement, as demonstrated in the graphic. In addition to source management, you also need to consider how to move SQL-created objects from a development environment into a production environment. The best approach is to rerun the SQL creation script. If that is not possible, look at the referenced Web resource (shown on this chart and included in the Links section of this course) to understand the best way to use the normal Save and Restore approach with SQLcreated objects.

Page 18 of 50

Modernizing database definitions and objects

SQL object management

SQL Column and Object names have maximum lengths of 30 and 128 (respectively). But, many i5/OS utilities, commands and interfaces only support a 10character length. How does that work?
System automatically generates a short 10 character name
First five characters with unique 5-digit number
CUSTOMER_MASTER >> CUSTO00001

Might be different each time a specific table is created, depending on creation order and what other objects share the same five-character prefix Use i5/OS SQL syntax to specify your own short name
RENAME TABLE (tables and views) and RENAME INDEX FOR COLUMN clause for columns SPECIFIC clause for procedures, functions

Modernizing database definitions and objects: SQL object management

One benefit of using SQL is that it allows you to create database-column (field) and table (file) names that are longer than 10 characters. Of course, not all i5/OS interfaces support these longer names. The FOR COLUMN clause on the CREATE TABLE statement allows you to specify a short name for your long-column names, which can be used on the interfaces that cannot support field names longer than 10 characters. (If a short name is not specified, the system automatically generates one.) However, the CREATE TABLE statement does not allow you to specify a short name for the table name. Again, the system does generate a short name automatically, but the short name is not user-friendly (the system short name for customer_master is CUSTO00001) and is not guaranteed to have the same short name if you re-create the database-table object multiple times. That is where the RENAME TABLE (for tables and Views) and RENAME index statements are valuable.

Page 19 of 50

Modernizing database definitions and objects (continued)

SQL object management

Coexistence example between Short and long names

Specify the short name at creation: CREATE TABLE dbtest/cusmst (customer_name FOR COLUMN cusnam CHAR(20), customer_city FOR COLUMN cuscty CHAR(40)) Specify a long name for existing short name: RENAME TABLE dbtest/cusmst TO customer_master FOR SYSTEM NAME cusmst

If a long name specified on SQL Table definition, you can also add or control the short name after the table is created:
RENAME TABLE dbtest/customer_master TO SYSTEM NAME cusmst

Modernizing database definitions and objects: SQL object management (continued)

Here is an example of how to use the RENAME TABLE statement to assign a long descriptive name to the SQL table after creating it with a short name. This is probably the preferred approach because the short name specified on the CREATE TABLE statement (or generated by DB2 if using a long SQL statement) is used for the recordformat name. In this first example, the record-format name is cusmst. An SQL programmer might reference the table either with cusmst name or the customer_master name. If you have some traditional native I/O programs, then being able to control the format name with SQL minimizes the changes to your native program.

Page 20 of 50

Modernizing database definitions and objects (continued)

SQL object management

RENAME statement also controls the format and file name used by native programs
1. Specify the format name (cmfmt) when creating the table CREATE TABLE dbtest/cmfmt (customer_name FOR COLUMN cusnam CHAR(20), customer_city FOR COLUMN cuscty CHAR(40)) Use RENAME to specify the short file name (cusmst) for the table: RENAME TABLE dbtest/cmfmt TO cusmst Use RENAME to specify the long name for SQL interfaces RENAME TABLE dbtest/cusmst TO customer_master FOR SYSTEM NAME cusmst

2. 3.

i5/OS V5R4 simplifies control of the record-format name with a new SQL keyword
CREATE TABLE dbtest/customer_master (customer_name FOR COLUMN cusnam CHAR(20), customer_city FOR COLUMN cuscty CHAR(40)) RCDFMT cmfmt

Modernizing database definitions and objects (continued)

Here is an example of how to use the RENAME TABLE statement to control the record format name and the short file name that native programs must use to access this SQLcreated object. Most native applications require the record-format name to be different from the short file name. Using this sequence of steps minimizes the number of changes that have to be made to native applications after the DB2-object definitions are switched to SQL.

Page 21 of 50

Modernizing definitions and objects

SQL and nonrelational data

User-defined table functions

Allows nonrelational and legacy data to be virtualized as an SQL table SELECT * FROM TABLE(myudtf('Part XYZ')) Both SQL and External Table Functions supported
External UDTFs can be easily written to access multiformat files and stream files Table functions can only be invoked from SQL-based interfaces

Datalinks
URL-based data type provides linkage to related objects in IFS Can establish Referential Integrity relationship between table row and IFS object

LOBs
Allows you to keep nonrelational data along with all the other business data

Modernizing definitions and objects: SQL and nonrelational data

Although SQL was designed originally for relational database objects, it has been enhanced to support nonrelational objects. Examples of some nonrelational objects include image files and i5/OS multiformat files. These are all objects that SQL applications cannot access directly. In OS/400 V5R2, user-defined table functions (UDTFs) were added to make it easier to access nonrelational objects. A UDTF can be written entirely in SQL or implemented as an external UDTF by using one of the highlevel programming languages supported by i5/OS. If you have an existing i5/OS program that knows how to extract data from a nonrelational object (such as an IFS stream file or data queue), the program can be registered as an external UDTF. Then, SQL programmers can access the data in these nonrelational objects by invoking the UDTF as demonstrated in this example. A UDTF can be referenced anywhere on an SQL statement where a table reference is allowed. The DataLink data type provides a method of linking a row in a DB2 table with nonrelational objects in IFS that are associated with that row of data. For example, a row in the orders table might want a Datalink to store the reference to the IFS file that contains an image copy of the order invoice. LOB data types (BLOB and CLOB) allow you to store the nonrelational object content directly into a database row instead of just a virtual link, such as a DataLink column.

Page 22 of 50

Modernizing definitions and objects

Moving business logic into DB2 (automatic key generation)

Identity Column attribute

Attribute that can be added to any numeric columns to have DB2 generate next value Not guaranteed to be unique, primary key or unique index must be defined Only available for SQL tables, but Identity Column value is generated for both SQL and non-SQL interfaces (RPG, COBOL) that are adding new rows CREATE TABLE emp( empno INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 10 , INCREMENT BY 10), name CHAR(30), dept# CHAR(4)) INSERT INTO employee(name,dept) VALUES('MIKE','503A') or INSERT INTO employee VALUES(DEFAULT,'MIKE', '503A')

Sequence object
Separate object that can be shared across multiple tables Generated value to be part of non-numeric keys CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10 INSERT INTO orders(ordnum,custnum) VALUES( NEXT VALUE FOR order_seq, 123 )

Modernizing definitions and objects: Moving business logic into DB2 (automatic key generation)
One of the simplest pieces of business logic that can be embedded into your DB2 object definitions is key generation. Almost all solutions have code that generates a key value for invoice or customer number and then inserts that value into a database table for storage. Why not have DB2 generate that value for you as it inserts the row into the table? That is exactly the functionality that the Identity column attribute and Sequence object (new in i5/OS V5R3) can provide. Let DB2 handle the key generation, locking and serialization of that value, so you can concentrate on real business logic. Support for the sequence object was added because that DB2 object makes it easier to share a generated-key value across multiple tables. Not only can these DB2 capabilities help modernize your database definitions, they also reduce the total lines of application code that have to be written and maintained.

Page 23 of 50

Modernizing definitions and objects

Moving business logic into DB2 (constraints)

Database constraints benefits

Easier code reuse and better modularity Improved data integrity Improved query performance; SQE query optimizer is constraint-aware

Constraint types
Primary and unique key Referential-integrity constraints
Enforce parent and child as well as masterand detail relationships

Check constraints
Ensure that a column is only assigned legal values
CREATE TABLE orders( ordnum INTEGER PRIMARY KEY, ordqty INTEGER CHECK(ordqty>0 AND ordqty<999), ordamt DECIMAL(7,2), part_id CHAR(4), CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID) ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects: Moving business logic into DB2 (constraints)
By moving business rules into your database, you are assured that those requirements are enforced across all transactions and, more importantly, all interfaces. In contrast, business rules implemented in an application are enforced only when that application is used to change your database. Relying on application-enforced business rules opens up serious data-integrity issues when data corrections are made using SQL and Web-based application tools. DB2 constraints again provide a means for moving some of your simpler business logic into the DB2 objects themselves. Primary and unique key constraints prevent duplicate entries from being entered into the database for the same customer or order. Creating a primary key constraint on a table also provides equivalent functions with a uniquelykeyed physical file object. RI constraints allow DB2 to keep the master-detail relationship between related tables always in synchronization. For example, an RI constraint prevents an order from being inserted whenever that order does not reference a valid customer number. Check constraints allow the programmer to ensure that only a certain set of values are allowed into a column. The check constraint example here enforces that the order quantity amount is always greater than zero and less than 1000. As of i5/OS V5R3, the new SQE optimizer also has the ability to analyze the constraint definitions to see if they can be employed to make data retrieval more intelligent and faster. For example, if a query is run to search for all orders with a quantity greater than 1000, the optimizer can return an empty result set without looking at any of the data because it knows that the check-constraint definition prohibited any quantity value greater than 1000.

Page 24 of 50

Modernizing definitions and objects

Moving business logic into DB2 (triggers)

Triggers initiate business policies and processes when new data comes in or existing data is changed
DB2 is responsible for always invoking the trigger program Execution is independent of the user interface Can be used to transform data before it gets into DB2

DB2 for i5/OS trigger support

Before and After: Insert, Update and Delete events (up to 300 triggers) SQL and External(ADDPFTRG) triggers
Column-level and statement-level triggers only available with SQL triggers
CREATE TRIGGER audit_salary AFTER UPDATE ON employee(salary) REFERENCING NEW AS n REFERENCING OLD AS o FOR EACH ROW WHEN (n.salary - o.salary >= 5000) INSERT INTO audit VALUES(n.empno, n.deptno, n.salary,current timestamp)

Modernizing definitions and objects: Moving business logic into DB2 (triggers)
Constraints provide great vehicles for defining simple-file and field-level rules. However, more complex business rules, such as checking inventory levels before accepting an order, might require program code that reads and processes data that spans multiple database tables. More complex processes and policies can be carried out in DB2 for i5/OS with triggers. A trigger is an SQL routine or i5/OS program object that is associated with a database table and set in motion (or triggered) by a change in data. DB2 for i5/OS triggers can be fired with the insertion, update or deletion of a row. When you define a trigger, you define which of these database events causes DB2 for i5/OS to call the trigger logic automatically. A DB2 for i5/OS trigger can easily be used to read data in other files. This helps the application determine whether the order must be accepted or not. The trigger can also initiate a batch job to order additional inventory whenever the trigger logic determines that inventory levels have dropped low enough to require back-order processing. Because triggers are just programs, they can perform nondatabase actions, as well. For example, each time you add a customer to the customer table, a trigger can send the customer information to a data queue. Then, another program can take the data off the queue and fax a welcome letter to the new customer. DB2 for i5/OS allows you to create triggers with or without SQL. For instance, external triggers can also be used.

Page 25 of 50

Modernizing data access

Programming Interfaces Native I/O to SQL comparison Using SQL to reuse and repurpose existing code DB2 and new application models Tools

Modernizing data access

DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5/OS data. The five aspects are: Programming Interfaces Native I/O to SQL comparison Using SQL to reuse and repurpose existing code DB2 and new application models Tools The next few charts review these in more detail.

Page 26 of 50

Modernizing data access

Programming interfaces
Static SQL Embedded static Dynamic SQL Embedded dynamic JDBC, SQLJ Extended-dynamic SQL QSQPRCED IBM Toolbox for Java JDBC and iSeries Access ODBC XDA API set

OLE DB, .NET CLI, ODBC, PHP Net.Data RUNSQLSTM

**DB2 for i5/OS SQL Development Kit required only if using embedded SQL (and STRSQL)

Modernizing data access: Programming interfaces

It is important to understand all of the SQL-based programming interfaces that are available to System i application developers. There are three types of SQL programming interfaces: static SQL, dynamic SQL and extended-dynamic SQL. When moving from traditional System i solutions, the most logical starting point is embedding static SQL requests into RPG and COBOL programs. Embedded-static SQL statements allow you to hardcode SQL statements into your programs. Static SQL tends to be the best performing of the three types of interfaces. Almost all of the dynamic SQL interfaces are API-based interfaces for passing SQL requests into the DB2 for i5/OS database engine. If your ultimate goal is to move to the Java programming language, JDBC is the dynamic SQL interface that is typically used. DB2 for i5/OS also supports SQLJ, but is not as commonly used. Net.Data provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5/OS. The Net.Data SQL interfaces make it easy to display your business data in an HTML page.

Page 27 of 50

Modernizing data access

Native I/O to SQL example
... /F REE exec sql DECLARE sql_jn CURSOR F OR SE LE CT t.yea r,t.m on th ,i.orderdt,c.cou nt r y,c.cu st , p.pa rt ,s.su pplier ,i.qu an tity,i.r even u e F ROM item _fa ct i INNER J OIN pa r t _dim p ON (i.pa rt id =p.pa r tid) INNER J OIN t ime_dim t ON (i.or der dt =t .da tekey) INNER J OIN cu st _dim c ON (i.custid=c.custid) INNER J OIN su pp_dim s ON (i.suppid=s.su ppid) WHE RE yea r =1998 AND m ont h =6; exec sql OP E N sql_jn ; exec sql F E TCH NE XT FROM sql_jn F OR :RowsReq ROWS INTO :r esu lt _set ; if SQLCOD = 0 a n d SQLER5 = 100 an d SQLE R3 > 0; RowsRd = SQLER3; /E ND-F RE E ...

C Sea r ch Key C C ... C Tim es C Sea r ch Key C C Rd C C C C C DATE KE Y C C RowsRd C DATE KE Y C C C C PARTKE Y C C C C CU STKE Y C C C C SU P PKE Y C C C

KList Kfld Kfld Occu r If Set ll Sea r ch Yea r Sea r ch Mon t h

Resu lt _Set TIME _DIML1 %FOU N D DOU RowsReq = Rows RE AD If TIME _DIML1 %E OF ITE MFACTL1 %FOU ND RowsReq =

Lea ve E n dif Set ll If DOU

RE ADE ITE MFACTL1 If %E OF Lea ve E n dif CH AIN PART_DIML1 If N ot %FOU N D It er E n dif CH AIN CU ST_DIML1 If N ot %FOU N D It er E n dif CH AIN SU PP_DIML1 If N ot %FOU N D It er E n dif ...

Modernizing data access: Native I/O to SQL example

This example is a side-by-side comparison of the native I/O program and its SQL equivalent, which is the simplest form of SQL (embedded SQL). Each program searches through five tables to return data for the specified time period of the sixth month in the year 1998. Notice how SQL performs the join in one request. In contrast, the native program performs Read operations against each table individually and has to specify a logical file to use. Although you can write SQL code so that it uses a separate cursor for each table to mirror the native code more directly, this type of SQL conversion is not recommended because of the performance problems it causes. The real value of SQL is its support for processing a set of data on a single request, instead of subdividing a single request into multiple parts. You will also notice how easy SQL makes it to read only a subset of the columns from the five tables. The native I/O example retrieves all of the fields. In order for the native I/O program to retrieve a subset of fields from each table, a new logical file must be created for each table.

Page 28 of 50

Modernizing data access

Native I/O to SQL example (Joined LFs and Views)
.. C Sea r ch Key C C Sea r ch Mon th ... C C C C C C C C C C C Sea r ch Key KList Kfld Kfld

Sea r ch Yea r

/F REE exec sql DE CLARE sql_jn CURSOR F OR SE LECT * FROM J oin View WHE RE yea r =1998 AND mont h =6; exec sql OPE N sql_jn ; exec sql FE TCH NE XT F ROM sql_jn F OR :RowsReq ROWS INTO :resu lt _set ; If SQLCOD = 0 a n d SQLER5 = 100 an d SQLER3 > 0; RowsRd = SQLER3; E ndif; /E ND-F RE E

Set ll If DO Occu r RE AD If Lea ve E n dif E va l E NDDO E n dif

Times

NTVJ OIN002 %F OUND RowsReq Times Resu lt _Set NTVJ OIN002 %E OF

RowsRd = RowsRd + 1

Modernizing data access: Native I/O to SQL example (Joined Logical Files and Views)
A programmer who is accustomed to using the native I/O system might argue that the previous native I/O solution can be simplified by creating a Join logical file. That is true and is shown in this example. However, SQL can do the same thing by hiding the complex Join logic inside an SQL View. In this SQL example, the Join query from the previous page has been moved into an SQL View named sql_jn. SQL Views have an advantage over Join logical files because the join order is not fixed and more complex join types are available. The query optimizer has an opportunity to analyze the join request and modify the join order that is coded in the SQL View if a different join order performs better. With Join logical files, the burden is on the programmer to code the join order correctly and, in time, double-check that the coded join order is still optimal.

Page 29 of 50

Modernizing data access

Native I/O to SQL example (performance comparison)
25 20 Time (sec) 15 10 5 0 Number of Rows

1 100 Note: Tests run on Model 720 w/1600 CPW and 2 GB Memory - your performance1000 may vary results Native File Join Native JoinLF Native JoinLF w SQL - No IOA SQL IOA SQL SQE IOA 0.002512 0.002304 0.002400 0.145160 0.251168 0.013536 0.260248 0.362128 2.144288 0.489136 0.267208 0.019320 2.219504 2.544608 2.125032 3.166704 0.417800 0.250160

10000 23.228176 21.366480 19.311464 20.452984 1.898800 1.576536

Modernizing data access: Native I/O to SQL example (performance comparison)

One of the biggest reasons System i programmers decide not to use SQL is that they believe native I/O data access is a better performing interface. This chart compares the performance of the SQL and native I/O programming examples that were just reviewed. In general, when processing sets of data, SQL performance is equivalent to, or better than, native access. Native I/O performs better than SQL when retrieving a small number of rows, but SQL performs better with a large set of result sets. When an index is created so that SQL can use index-only access (IOA), SQL performance for retrieving a small number of rows drops dramatically. IOA is another one of those features that is only available to SQL interfaces. Normally when performing a key lookup, the DB2 engine has to issue two I/O operations: one to retrieve the key out of the index (LF) and another to retrieve the associated row out of the table (PF). This double I/O processing is always done when a native program is positioning to a row through a keyed logical file. With SQL interfaces, if the index keys contain all of the column data that is returned by the SQL query, then the query optimizer is smart enough to extract only that column data out of the index with a single I/O operation; it does NOT perform the second I/O operation against the underlying table. In this example, all executions of SQL perform block fetches.

Page 30 of 50

Modernizing data access

Comparing SQL and native performance

RPG
Arrival sequence Keyed access Keyed access (memory-constrained) Pseudo-random Keyed access Direct-key access 202 000 131 000 8000 3950 5100

SQL
173 000 117 000 12 000 3440 4100

rows per minute

Published by NEWS/400 in March 2000, measured on OS/400 V4R4

Modernizing data access: Comparing SQL and native performance

Here is a performance test that was done by a System i trade-press magazine. It must be noted that this performance test compared highly optimized RPG code (featuring overrides) against SQL requests. Even in this specialized test, SQL performance was comparable especially when one considers that this test was run several releases ago and DB2 enhances SQL performance each release. The point is that you can have a high-performing SQL application on the System i platform. Thousands of System i installations have been successfully using SQL in their OLTP applications for data access for several years. Some clients have also harnessed the processing power of SQL to convert native workloads that previously ran in one hour; these SQL workloads now run in minutes. Of course, performance depends on the application. Before deciding to convert an application from native I/O processing to SQL, some upfront performance analysis needs to be done. It is probably better to start using SQL for a new application or a new function in an existing application.

Page 31 of 50

Modernizing data access

Native to SQL considerations ORDER BY clause is the only way to guarantee sequencing of results with SQL Without the clause, ordering occurs by chance Support for free-format embedded SQL (added in i5/OS V5R4) SQL precompilers do not support all the latest features; still missing from RPG precompiler in i5/OS V5R4:
Support for properly scoping a local variable in a subprocedure as a host variable in an SQL statement (multipass) Support for qualified names with more than one level of qualification

Consider the impact of the SQL isolation level and journaling on native applications Critical performance success factors
Sound indexing and statistics strategy Reusable Open Data Paths (ODPs)
Prepare once, execute many Connection pooling Keep connections and jobs active as long as possible

Blocked Fetches and Inserts

Modernizing data access: Native to SQL considerations

There are a few issues to consider when using SQL instead of native I/O for data access. With SQL, the only way to guarantee the sequencing of results is to specify an ORDER BY clause. Many native applications depend on data being returned in arrival sequence without specifying any key or ordering. SQL is not designed to work that way. Even if an SQL statement returns data in the order you want without an ORDER BY clause, that ordering might change without warning the next time that statement runs, because no ORDER BY clause was specified. Some programmers who use the latest RPG features have found that the RPG SQL precompiler does not support all the latest features. Some of the key restrictions that exist as of i5/OS V5R4 are listed in the graphic. Notice that support of embedded SQL in free-format RPG is provided in i5/OS V5R4. Previously, you had to end free-format mode before adding the embedded SQL statements. If you start using SQL and run with an isolation level (that is, commitment-control level) other than *NONE/NC, consider the impact of row-level locking on the rest of the application and on native applications that access the same tables. Certain technologies, such as IBM WebSphere and Enterprise JavaBeans (EJB) require an isolation level higher than *NONE in order to run. Just as with any programming language, SQL has its performance-related strengths and weaknesses. An RPG programmer learns those over time with the RPG language, and programmers using SQL for the first time have to realize it might take some time to learn the best-performing techniques.

Page 32 of 50

One key requirement is to have a sound indexing strategy to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements. The white paper entitled Indexing and statistics strategies for DB2 for iSeries Version 3 provides more details. (See the Links section of this course for the URL.) Minimizing the number of Open Data Paths (ODPs) that are created is the next biggest factor for an indexing strategy that ensures a high-performing SQL application. For more details on ODPs, see the online course, DB2 for i5/OS: SQL Performance Basics. (The Links section of this course provides the URL.) Blocking of Fetches and Inserts are usually important to good SQL performance because it allows you to retrieve a block of rows from the table and then process those rows individually in your application program without having to go through all the DB2 engine layers for each row.

Page 33 of 50

Modernizing data access

Using SQL to reuse and repurpose existing code

OPNQRYF (SQL)
Retain set at a time processing but provide data using SQL

Stored procedures, functions and triggers provide vehicle for improving and changing the solutions architecture
Better modularity as the result of allowing code reuse by multiple interfaces and applications Better partitioning of logic (separation of presentation and database logic) Easy transition to multitier architectures because many interfaces exist for remote invocations

DB2 for i5/OS support provides maximum flexibility by supporting both SQL and external types
External support allows reuse of existing i5/OS application code and skills SQL Procedural Language (PSM) enables better portability of logic (and programming skills) to and from other platforms Data security can be enhanced and maintained with i5/OS Adopted Authority

Modernizing data Access: Using SQL to reuse and repurpose existing code
One way to modernize huge, monolithic programs is to improve the structure with subroutines and modules that perform specific business tasks. Stored procedures, UDFs (user-defined functions) and triggers are DB2 features that can actually help the modularity of your application code. All of these DB2 features make it easy for common business rules and processing tasks to be shared across a wide variety of interfaces and applications. The reason for this is that almost every programming language has an available SQL interface. Procedures, functions and triggers provide a great way of making your existing applications available to a new application model that uses a Web interface. Just because you are providing a Web-browser interface does not mean that all of the business logic has to be rewritten in Java. Instead, write the presentation layer in Java and then issue a simple JDBC statement to invoke the existing code from a stored procedure. DB2 for i5/OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5/OS high-level programming language. New programmers might use SQL, but a team of RPG or COBOL programmers do not have to throw out their existing trigger and stored procedure skills. Many System i programmers also prefer procedures, functions and triggers because these functions map to program objects. This means that i5/OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications.

Page 34 of 50

Modernizing data access

Using SQL to reuse and repurpose existing code (UDFs)

UDFs allow the database to invoke user-written functions during the processing of an SQL statement
Allows you to customize SQL to meet your business requirements Example: CREATE FUNCTION Euro(EuroAmt DECIMAL(11,2)) RETURNS DECIMAL(11,2) LANGUAGE SQL BEGIN DECLARE rate DECIMAL(9,5); SELECT conversion_rate INTO rate FROM ratetable WHERE ...; RETURN rate*EuroAmt; END SELECT item_name, Euro(item_price) FROM parts...

Modernizing data access: Using SQL to reuse and repurpose existing code (UDFs)
DB2 for i5/OS includes a set of built-in scalar functions (such as ABSVAL and SUBSTRING) to provide a basic suite of functions for mathematical and character processing. However, these functions do not always have the capabilities necessary for programmers to implement complex business calculations or processes such as the calculation of shipping costs, room yield or credit risk. The DB2 support for user-defined functions (UDFs) makes it easy to create and develop your own functions and have the ability to use these user-created functions just as you would the SQL built-in functions. This example shows a simple SQL function to convert a currency amount into its equivalent Euro currency value. As mentioned earlier, the System i platform supports both external and SQL UDFs. This support offers great flexibility. A Java programmer can code a JDBC request that invokes a UDF that internally uses a 10-year-old RPG program for the business calculation. To the Java programmer, the UDF call is the same as invoking a built-in SQL function, such as ABSVAL or SUBSTRING.

Page 35 of 50

Modernizing data access

Using SQL to reuse and repurpose existing code (procedures)

Stored procedures are similar to UDFs, but are invoked with an SQL Call statement
More than just a remote program call
Supported by the majority of the application development tools and languages Result sets can improve performance by minimizing network trips

Procedures are most effective when performing multiple operations on a single procedure call Considerations for external procedures
Might have to make slight modifications to existing code to match stored-procedure parameter conventions or develop wrapper procedures Need to design process for installing and upgrading stored procedures

Considerations for SQL Procedures

Generated C code with embedded SQL not as fast as user-written code Minimize the number of nested calls to other SQL procedures

No support for blocked fetches and inserts

Modernizing data access: Using SQL to reuse and repurpose existing code (procedures)
As with UDFs, stored procedures are created with SQL or an external high-level language; but, the invocation of the two procedural objects differs. UDFs are effective when you want to call the function for each row or a subset of rows in a particular table. Stored procedures are called independently of any DB2 table or row. They are the SQL version of a remote program call. Stored procedures are called only when a particular business task needs to be performed. Stored procedures are a good way to modularize, or partition, a related set of database operations, possibly even an entire transaction. For example, the database changes that are necessary when transferring inventory from one warehouse location to another can be implemented as a stored procedure. Well-defined modular stored procedures can be shared across business transactions to improve code reusability. Stored procedures also provide performance savings in a multitier environment by letting you perform multiple database operations on a single server request from the client. DB2 external procedures make it easy to reuse existing programs as stored procedures. You might only need to adjust how DB2 passes input and output parameters based on the parameter style that is specified on the CREATE PROCEDURE statement. DB2 implements SQL stored procedures by generating a C program with embedded SQL. Because generated code is never as efficient as user-written code, you might consider using external stored procedures in situations where performance is extremely critical. That being said, many System i users are successfully using the SQL procedural language. This language is especially successful in porting triggers and procedures from Oracle and Microsoft SQL Server to DB2 for i5/OS. Stored-procedure calls done with an SQL CALL statement are always implemented as unbound calls. Thus, to get the best performance, the number of stored-procedure calls needs to be minimized by forcing the procedure to perform multiple tasks on a single call.

Page 36 of 50

Modernizing data access

DB2 and new application models (distributed transactions)

DB2 for i5/OS supports XA transactions

i5/OS Transaction Manager was substantially enhanced in i5/OS V5R2 for distributed transaction modes, including support for JTA. i5/OS XA support is designed for SQL interfaces. Native code can participate in XA transactions if they are wrappered as external stored procedures or UDFs.

Modernizing data access: DB2 and new application models (distributed transactions)
Many new application models incorporate the design point of having multiple connections (or jobs) working on a single transaction to improve the scalability and flexibility of the application. The XA transaction interface is the most commonly-used industry-standard interface in these types of solutions. The i5/OS operating system provides support for the XA standard and the Java equivalent, the Java Transaction API (JTA). Although the i5/OS support is designed for the SQL interfaces, existing native programs can participate in a distributed transaction if they are registered and called as external stored procedure or external functions.

Page 37 of 50

Modernizing data access

DB2 and new application models (Web services)

DB2 Web services (WORF)

Easily create simple XML-based Web services that access DB2
Part of Websphere Express

Create Document Access Definition eXtension (DADX) documents by using a simple text editor and deploy them in Websphere with minimal knowledge of XML or SQL Used through Websphere and SOAP
SQL Select, Update, Insert, Delete and other procedures XML extenders can also be used

Read more at: ibm.com/servers/enable/site/education/abstracts/db2web_abs.html

<?xml version="1.0"?> <DADX xmlns="http://schemas.ibm.com/db2/dxx/dadx" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Accesses city instead of zip code database </documentation> <operation name="findCityByZipCode"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Finds the city for a zip code </documentation> <query> <SQL_query>SELECT CITY FROM DEMO.CITY_TAB WHERE ZIPCODE = :zipcode</SQL_query> <parameter name="zipcode" type="xsd:string"/> </query> </operation> </DADX>

Modernizing data access: DB2 and new application models (Web services)
Web services are becoming an established technology that provides a model for offering business or application services over the Internet as well as within an organization. The value of specific DB2 Web services is that they let a developer provide direct access to business data without any high-level language programming. DB2 Web services are a good choice when the Web service is data centric meaning that the invoking application looks for a set of data or needs to insert a new row of data. DB2 Web services can support these types of data-centric requirements by essentially coding an SQL statement in an XML document (assuming that the application runs on top of the WebSphere Application Server). The white paper DB2 UDB for iSeries and Web Services has the details on how the WebSphere Web services Object Runtime Framework (WORF) component handles the interfacing tasks with the Web service invoker and also performs the XML formatting of the results that are sent back to the invoker. This streamlined approach lets the developer concentrate on the SQL request (rather than worrying about coding the Javaapplication to establish a database connection and to package and deploy the Java code). DB2 Web services let the developer retrieve and change data on the System i platform, as well as invoke stored procedures.

Page 38 of 50

The example shown here is a simple DB2 Web service that accepts a zip code as an input parameter and returns a list of the city names with that specified zip code. You can learn more about using DB2 Web services by visiting the Web site listed on this chart (and provided in the Links section of this course).

Page 39 of 50

Modernizing data access

DB2 and new application models (XML and text mining) DB2 Extenders provide low-level plumbing to allow you to concentrate on the business logic DB2 and XML integration with DB2 XML Extender
Allows an XML document to be stored and retrieved from a column Enables XML document to be generated dynamically from existing DB2 data Provides ability to decompose an XML document and generate new database rows

Text mining with DB2 Text Extender

High-speed, sophisticated searches for any character columns
Fuzzy searches Search on tenses of word Customize search to words in same sentence or paragraph

Can also search text documents stored in IFS

Reference: ibm.com/servers/enable/site/education/ibo/record.html?db2udbext

Modernizing data access: DB2 and new application models (XML and text mining)
These days, the ability to support XML is a requirement that almost all solutions are addressing. XML is the standard format when sharing data with partners or providing data to other companies. Many times, the data in that XML document needs to come from a DB2 database or must be stored in a DB2 database. That is where XML extenders come into play. They allow you to store XML data along with your business data in DB2 for i5/OS. By incorporating XML information and metainformation directly in the database, you can more efficiently obtain the XML results that other applications need. With the content of your structured XML documents in a DB2 database, you can combine structured XML information with traditional relational data. With the help of XML extenders, the XML documents can be stored entirely in a database column, or you can set up mapping so that XML documents can be decomposed into existing columns or generated from data in existing columns. If you choose to store the entire XML document in a DB2 column, then developers and users will want to search the contents of that large text column containing the XML document. That is where Text extenders come into play. They enable searches against character columns to be done very quickly. In addition, the text extenders provide advanced search capabilities against any character column, such as the ability to find matches (on the tenses of the search word) and searches (requiring the keywords to be in the same sentence or paragraph). Check out the online course DB2 UDB Extenders for iSeries - V5R2 Update for more details on the DB2 XML and text extenders. (See the Links section of this course for the URL.)

Page 40 of 50

Modernizing data access

Development tools

WebSphere Development Studio Client for iSeries

DB2 Web service support XML Extender aids SQL statement wizard

RSE and Code/400 coexist with SQL PDM has basic SQL prompting support Visual Studio .NET plugins DB2 Information Integrator for non-DB2 data access

Reference: ibm.com/servers/enable/site/education/ibo/record.html?hetdata

DB2 Development Center

Stored procedures User-defined functions

IBM DB2 Query Management Facility (QMF) Distributed Edition

Supports Microsoft Windows and browser clients

Modernizing data access: Development tools

As you modernize your business logic with SQL and DB2 database definitions, you need also to look at modernizing your development tools. WebSphere Development Studio Client and Remote System Explorer (RSE) provide a modern interface for System i application development and debugging. In addition, WebSphere Development Studio Client has several wizards to help developers get started with the DB2 Web-service and extenders technologies. For Visual Studio .NET development, you might want to look at the DB2 .NET plugins that are available to make it easier to access DB2 objects. DB2 Development Center provides a development environment to help programmers create and maintain SQL stored procedures and UDFs. Finally, DB2 Information Integrator can be viewed as a development tool that makes it possible to access databases other than DB2 (such as Oracle) for applications running on the System i platform. If part of your solution involves providing precanned reports, the DB2 QMF product must also be examined closely. System i developers need to think of this product as a graphical version of a query tool (such as Query/400) or Query Manager. In fact, the product has conversion utilities to convert existing Query or Query Manager reports into the equivalent QMF report. Not only is this a more modern interface for business reports, the tool also provides conversion utilities to modernize existing reports instead of recreating them from scratch.

Page 41 of 50

Modernizing data access (continued)

Development tools

IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugging (ibm.com/servers/enable/site/education/abstracts/sqldebug_abs.html) iSeries Navigator
Editors for procedure, functions, triggers SQL statement wizard for Insert, Select, Update, Delete Downloadable tutorials at: ibm.com/servers/enable/site/education/ibo/view.html?oc#db2

Visual Explain Database Monitor (STRDBMON CL command) PRTSQLINF DB2 SMP: licensed feature (i5/OS Option 26)

Modernizing data access: Development tools (continued)

This chart lists some tools that are helpful to use after your newly modernized solution is up and running. The IBM Toolbox for Java includes a graphical debugger that is a good tool to use when debugging stored procedures, functions and tools. In i5/OS V5R3 and later releases, iSeries Navigator makes it very easy to bring up the graphical debugger for debugging stored procedures. This graphical administrative interface also has statement wizards to provide programmers with a step-by-step process for coding an SQL Select, Insert, Update or Delete task this is especially useful for programmers of native systems who are still learning SQL syntax. Several self-study tutorials can be downloaded to learn about the DB2 interfaces that are available in iSeries Navigator. (See the Links section of this course for the URL.) Visual Explain and the SQL Performance monitors are also part of iSeries Navigator and are good tools for analyzing and tuning the performance of an SQL-based application. The PRTSQLINF CL command is the i5/OS version of the Explain utility that is available on other DB2 platforms. DB2 SMP is a tool that can also be used to boost the performance of SQL applications. By activating DB2 SMP, the query optimizer tries to speed the performance of SQL SELECT operations by enabling a single operation to run across multiple processors concurrently.

Page 42 of 50

Next steps
Education
Modernizing iSeries Application Data Access Redbook
www.redbooks.ibm.com/abstracts/sg246393.html?Open

Case study: Modernizing a DB2 for iSeries Application white paper

ibm.com/servers/enable/site/education/abstracts/9e5a_abs.html

DB2 for iSeries Performance Workshop

ibm.com/servers/eserver/iseries/service/igs/db2performance.html ibm.com/servers/enable/site/education/ibo/view.html?oc#db2

Indexing and Statistics Strategy white paper

ibm.com/servers/enable/site/education/ibo/record.html?indxng Database modernization roadmaps Modernizing DB2 definitions and usage www.developer.ibm.com/vic/hardware/myportal/develop/roadmap?roadMapId=appiniti Modernizing data access with SQL www.developer.ibm.com/vic/hardware/myportal/develop/roadmap?roadMapId=appinitj Maximizing SQL performance www.developer.ibm.com/vic/hardware/myportal/develop/roadmap?roadMapId=appinith

Identify first project

Write a new function or program component using SQL Rewrite existing components by using SQL (for example, reporting function) Port SQL-based program to DB2 for i5/OS
Porting guides and conversion tools at: ibm.com/servers/enable/site/db2/porting.html

Get help
eServer Custom Technology Center: www.ibm.com/ctc System i IBM Global Services team: [email protected]

Next steps
SQL is no different than any other programming language; you need education and experience to learn how to design a high-performing application. IBM highly recommends that you take advantage of the education available at the various Web sites listed on this chart. This education is important because the SQL performance tuning methods and tools are drastically different than performance considerations for native I/O processing. Depending only on trial-and-error experiences to build your experience level with SQL performance tuning takes too long. Education is needed first and then hands-on experience with SQL performance tuning is needed to solidify these new skills. The referenced iSeries SQL Performance Workshop provides both lecture and lab to give you opportunities in both areas. Portions of the SQL Performance Workshop lab materials are available online. (You can also see the Links section of this course for the URL.) As with any new venture, it is recommended that you start small and then build on that small success. It is not recommended that your first project be the rewrite of an entire native program to SQL. Instead, look for a new project that requires the creation of a new program or module that can use SQL in just the new code you are writing. Similarly, you might look at an existing component or routine in your application that can be rewritten using SQL. The reporting function for an existing application might be a good candidate.

Page 43 of 50

Some System i programmers have been forced into using SQL when they port an application that was written by PC programmers for another database (such as Microsoft SQL Server). Many times, the driving reason for porting the solution to the System i platform is to resolve scalability issues that are inherent with on the other platform and database. A conversion of an application from another database product requires the use of SQL to complete the conversion in a timely manner. IBM eServer Custom Technology Center and the IBM eServer iSeries Global Services Team are available to help with SQL modernization and performance tuning. Some solution providers might also qualify for assistance from the DB2 team in the IBM ISV Business Strategy and Enablement organization.

Page 44 of 50

DB2 for i5/OS Family certifications

Certified Database Associate: DB2 for i5/OS Family (Test 700)
Web site: ibm.com/certify/certs/dbdaudv81.shtml Education resources: ibm.com/certify/tests/edu700.shtml Online tutorial: www7b.boulder.ibm.com/dmdd/library/tutorials/db2cert/db2cert_V8_tut.html

Certified Application Developer: DB2 for i5/OS Family (Test 703)

Web site: ibm.com/certify/certs/dbapudv81.shtml Education resources: ibm.com/certify/tests/edu703.shtml

Sample tests: certify.torolab.ibm.com/ice Exams are refreshed and updated for DB2 for i5/OS

DB2 Family certifications

Here is a listing of the DB2 Family Certifications. You can become a Certified Database Associate or a Certified Application Developer. Check the Links section of this course for URLs to this information.

Page 45 of 50

Summary
SQL is everywhere DB2 for i5/OS supports both native and SQL-based interfaces. DDS objects can be converted to SQL through the use of the i5/OS QSQGNDDL API. SQL on the System i platform supports relational and nonrelational data objects. SQL supports moving business logic into the the DB2 engine.
Better modularization and isolation of data and business logic

SQL and DB2 for i5/OS support Java, XML and Web services. There are many development tools for SQL and DB2 for i5/OS.

Summary
SQL offers many advantages for System i developers as they move toward modernizing their existing RPG and C-based applications. One significant reason is that SQL is ubiquitous it is widely available, as are the programming skills needed to use this standards-based database interface. SQL can reduce the total lines of code, and it supports parallel database processing, which can yield better throughput for I/Ointensive applications. DB2 for i5/OS supports a number of native and SQL-based interface types into the data, each of which can be mixed and matched with other interfaces. The approach that you take depends on where you start and what you need to accomplish it is not an inflexible process. The SQL interface options include: static SQL, dynamic SQL and extended-dynamic SQL The QSQGNDDL i5/OS API is a tool that helps you convert existing DDS objects into SQL. You can conveniently access this tool from iSeries Navigator so that you can do these conversions through a graphical interface, which makes your job even easier. The decision to move to SQL as a database interface is easier because, since OS/400 V5R2, SQL on the System i platform now supports nonrelational objects (as well as its long-supported relational objects). This support was added through user-defined table functions (UDTFs). SQL also makes it easier to move business logic into the DB2 engine. A prime example of this is its ability to support automatic key generation. Developers no longer have to include this logic in code that should be more focused on core business tasks. Even some data tasks that are related to business logic can be handled by SQL and DB2 (for example, referential-integrity constraints and triggers). In addition to providing more efficient and better-performing database-access code, SQL also supports your need to reuse and repurpose existing code as you move to restructure your huge, monolithic programs. Stored procedures, UDFs (user-defined functions) and triggers are DB2 features that can actually help the modularity of your application code. SQL and DB2 for i5/OS also support new Java-based application development for todays Web-driven environments. This support is provided through the XA standard and

Page 46 of 50

its Java equivalent, the Java Transaction API (JTA). Web services, XML, and text mining are also easily achievable with SQL. Finally, there is a wealth of development tools to assist you in working with SQL and your existing code (see the Links section of this course).

Page 47 of 50

Links
White papers and articles: Indexing and statistics strategies for DB2 UDB for iSeries - Version 3.0 ibm.com/servers/enable/site/education/abstracts/indxng_abs.html DB2 UDB for iSeries and Web Services ibm.com/servers/enable/site/education/abstracts/db2web_abs.html DB2 Information Integrator for non-DB2 data access ibm.com/servers/enable/site/education/ibo/record.html?hetdata

Online courses: DB2 UDB for iSeries: SQL Performance Basics ibm.com/servers/enable/site/education/abstracts/db2sql_abs.html DB2 UDB Extenders for iSeries - V5R2 Update ibm.com/servers/enable/site/education/ibo/record.html?db2udbext IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibm.com/servers/enable/site/education/abstracts/sqldebug_abs.html iSeries Navigator DB2 interfaces (several online courses) ibm.com/servers/enable/site/education/ibo/view.html?oc#db2 Other courses ibm.com/eserver/iseries/db2/db2educ_m.htm

IBM Redbooks: ibm.com/redbooks Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503) DB2 UDB for AS/400 Object Relational Support (SG24-5409) Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249) Workshops: DB2 for i5/OS SQL Performance ibm.com/servers/eserver/iseries/service/igs/db2performance.html Other DB2 workshops ibm.com/servers/enable/site/education/ibo/view.html?oc#db2

Page 48 of 50

DB2 for i5/OS Family certifications: Certified Database Associate - DB2 for i5/OS Family (Test 700) ibm.com/certify/certs/dbdaudv81.shtml Study resources ibm.com/certify/tests/edu700.shtml Tutorials www7b.boulder.ibm.com/dmdd/library/tutorials/db2cert/db2cert_V8_tut.html Certified Application Developer - DB2 for i5/OS Family (Test 703) ibm.com/certify/certs/dbapudv81.shtml Study resources ibm.com/certify/tests/edu703.shtml Sample tests certify.torolab.ibm.com/ice Other helpful Web sites: IBM eServer Custom Technology Center ibm.com/ctc DB2 for i5/OS home page ibm.com/eserver/iseries/db2 DB2 online manuals ibm.com/eserver/iseries/db2/books.htm DB2 porting help ibm.com/servers/enable/site/db2/porting.html Book: SQL/400 Developer's Guide by Paul Conte and Mike Cravitz http://as400network.com/str/books/Uniquebook2.cfm?NextBook=183

Newsgroups: USENET newsgroup comp.sys.ibm.as400.misc, comp.databases.ibm-db2 iSeries Network (NEWS/400 Magazine) SQL and DB2 Forum www.iseriesnetwork.com/Forums/main.cfm?CFApp=59

Page 49 of 50

Trademarks and special notices

Copyright. IBM Corporation 1994-2006. All rights reserved. References in this document to IBM products or services do not imply that IBM intends to make them available in every country. DB2, i5/OS, IBM, the IBM logo, OS/400, Redbooks, System i and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction. Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

Page 50 of 50