Page 1 of 50

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 IO to SQL example 28 Modernizing data access Native IO to SQL example (Joined Logical Files and Views) 29 Modernizing data access Native IO 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 2 of 50

About the authors Mike Cain is a senior technical staff member and the team leader of the DB2 for i5OS 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 mcainusibmcom Gene Cobb is a DB2 for i5OS 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 i5OS CallPath400 and Lotusreg Domino His current responsibilities include providing consulting services to System i developers with special emphasis in application and database modernization

Page 3 of 50

IBM System i

Application Modernization DB2 for i5OS style

Mike Cain and Gene CobbDB2 for i5OS Technology Team ISV Business Strategy and Enablement - System i

Introduction The IBMreg System itrade Developersrsquo Road Atlas (formerly called the ldquoiSeries Developer Roadmaprdquo) 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 DB2reg for i5OSreg 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 i5OS point of view

Page 4 of 50

Agenda

bull Why modernize with SQL and DB2 for i5OS

bull Approaches and options

bull Modernizing database definitions

bull Modernizing data access

bull 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 data-access interfaces in application programs (for instance moving from native IO to SQL) This course concludes with some possible first steps you can take in modernizing applications from a DB2 and SQL perspective

Page 5 of 50

Why SQL

bull Portability of code and skillsbull Strategic database interface for industry and i5OS

ndash SQE delivers faster performance (only available to SQL-based interfaces)ndash SQL is required for certain functions and middleware

bull J2EE architecture based on SQL interfacesbull Data types BLOB CLOB Datalink and othersbull Auto-incrementing constructs Sequence and identity column attributebull Column-level triggersbull Encryption and decryption functions bull Encoded-vector indicesbull others

bull Enables better positioning of System i as a database serverbull As a programming language SQL can reduce total lines of codebull 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 IO 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 mdash it is easier to find a programmer with SQL skills than a programmer with RPG skills Just like Javatrade 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 OS400reg 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 IO interfaces receive no benefit now or in the future Several functional capabilities also require the use of SQL The Java 2 Enterprise Editiontrade (J2EEtrade) architecture obviously is based on SQL interfaces to data such as Java Database Connectivity (JDBCtrade) The binary large object (BLOB) and character large object (CLOB) data types can only be used in SQL-created tables DB2 for i5OS 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 i5OS database it is easier to convince Microsoftreg 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 6 of 50

in your DB2 for i5OS 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 IO works with one row at a time A single SQL request can process multiple rows of data in one request in the native IO 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 2 of 50

About the authors Mike Cain is a senior technical staff member and the team leader of the DB2 for i5OS 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 mcainusibmcom Gene Cobb is a DB2 for i5OS 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 i5OS CallPath400 and Lotusreg Domino His current responsibilities include providing consulting services to System i developers with special emphasis in application and database modernization

Page 3 of 50

IBM System i

Application Modernization DB2 for i5OS style

Mike Cain and Gene CobbDB2 for i5OS Technology Team ISV Business Strategy and Enablement - System i

Introduction The IBMreg System itrade Developersrsquo Road Atlas (formerly called the ldquoiSeries Developer Roadmaprdquo) 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 DB2reg for i5OSreg 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 i5OS point of view

Page 4 of 50

Agenda

bull Why modernize with SQL and DB2 for i5OS

bull Approaches and options

bull Modernizing database definitions

bull Modernizing data access

bull 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 data-access interfaces in application programs (for instance moving from native IO to SQL) This course concludes with some possible first steps you can take in modernizing applications from a DB2 and SQL perspective

Page 5 of 50

Why SQL

bull Portability of code and skillsbull Strategic database interface for industry and i5OS

ndash SQE delivers faster performance (only available to SQL-based interfaces)ndash SQL is required for certain functions and middleware

bull J2EE architecture based on SQL interfacesbull Data types BLOB CLOB Datalink and othersbull Auto-incrementing constructs Sequence and identity column attributebull Column-level triggersbull Encryption and decryption functions bull Encoded-vector indicesbull others

bull Enables better positioning of System i as a database serverbull As a programming language SQL can reduce total lines of codebull 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 IO 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 mdash it is easier to find a programmer with SQL skills than a programmer with RPG skills Just like Javatrade 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 OS400reg 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 IO interfaces receive no benefit now or in the future Several functional capabilities also require the use of SQL The Java 2 Enterprise Editiontrade (J2EEtrade) architecture obviously is based on SQL interfaces to data such as Java Database Connectivity (JDBCtrade) The binary large object (BLOB) and character large object (CLOB) data types can only be used in SQL-created tables DB2 for i5OS 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 i5OS database it is easier to convince Microsoftreg 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 6 of 50

in your DB2 for i5OS 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 IO works with one row at a time A single SQL request can process multiple rows of data in one request in the native IO 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 3 of 50

IBM System i

Application Modernization DB2 for i5OS style

Mike Cain and Gene CobbDB2 for i5OS Technology Team ISV Business Strategy and Enablement - System i

Introduction The IBMreg System itrade Developersrsquo Road Atlas (formerly called the ldquoiSeries Developer Roadmaprdquo) 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 DB2reg for i5OSreg 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 i5OS point of view

Page 4 of 50

Agenda

bull Why modernize with SQL and DB2 for i5OS

bull Approaches and options

bull Modernizing database definitions

bull Modernizing data access

bull 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 data-access interfaces in application programs (for instance moving from native IO to SQL) This course concludes with some possible first steps you can take in modernizing applications from a DB2 and SQL perspective

Page 5 of 50

Why SQL

bull Portability of code and skillsbull Strategic database interface for industry and i5OS

ndash SQE delivers faster performance (only available to SQL-based interfaces)ndash SQL is required for certain functions and middleware

bull J2EE architecture based on SQL interfacesbull Data types BLOB CLOB Datalink and othersbull Auto-incrementing constructs Sequence and identity column attributebull Column-level triggersbull Encryption and decryption functions bull Encoded-vector indicesbull others

bull Enables better positioning of System i as a database serverbull As a programming language SQL can reduce total lines of codebull 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 IO 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 mdash it is easier to find a programmer with SQL skills than a programmer with RPG skills Just like Javatrade 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 OS400reg 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 IO interfaces receive no benefit now or in the future Several functional capabilities also require the use of SQL The Java 2 Enterprise Editiontrade (J2EEtrade) architecture obviously is based on SQL interfaces to data such as Java Database Connectivity (JDBCtrade) The binary large object (BLOB) and character large object (CLOB) data types can only be used in SQL-created tables DB2 for i5OS 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 i5OS database it is easier to convince Microsoftreg 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 6 of 50

in your DB2 for i5OS 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 IO works with one row at a time A single SQL request can process multiple rows of data in one request in the native IO 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 4 of 50

Agenda

bull Why modernize with SQL and DB2 for i5OS

bull Approaches and options

bull Modernizing database definitions

bull Modernizing data access

bull 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 data-access interfaces in application programs (for instance moving from native IO to SQL) This course concludes with some possible first steps you can take in modernizing applications from a DB2 and SQL perspective

Page 5 of 50

Why SQL

bull Portability of code and skillsbull Strategic database interface for industry and i5OS

ndash SQE delivers faster performance (only available to SQL-based interfaces)ndash SQL is required for certain functions and middleware

bull J2EE architecture based on SQL interfacesbull Data types BLOB CLOB Datalink and othersbull Auto-incrementing constructs Sequence and identity column attributebull Column-level triggersbull Encryption and decryption functions bull Encoded-vector indicesbull others

bull Enables better positioning of System i as a database serverbull As a programming language SQL can reduce total lines of codebull 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 IO 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 mdash it is easier to find a programmer with SQL skills than a programmer with RPG skills Just like Javatrade 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 OS400reg 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 IO interfaces receive no benefit now or in the future Several functional capabilities also require the use of SQL The Java 2 Enterprise Editiontrade (J2EEtrade) architecture obviously is based on SQL interfaces to data such as Java Database Connectivity (JDBCtrade) The binary large object (BLOB) and character large object (CLOB) data types can only be used in SQL-created tables DB2 for i5OS 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 i5OS database it is easier to convince Microsoftreg 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 6 of 50

in your DB2 for i5OS 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 IO works with one row at a time A single SQL request can process multiple rows of data in one request in the native IO 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 5 of 50

Why SQL

bull Portability of code and skillsbull Strategic database interface for industry and i5OS

ndash SQE delivers faster performance (only available to SQL-based interfaces)ndash SQL is required for certain functions and middleware

bull J2EE architecture based on SQL interfacesbull Data types BLOB CLOB Datalink and othersbull Auto-incrementing constructs Sequence and identity column attributebull Column-level triggersbull Encryption and decryption functions bull Encoded-vector indicesbull others

bull Enables better positioning of System i as a database serverbull As a programming language SQL can reduce total lines of codebull 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 IO 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 mdash it is easier to find a programmer with SQL skills than a programmer with RPG skills Just like Javatrade 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 OS400reg 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 IO interfaces receive no benefit now or in the future Several functional capabilities also require the use of SQL The Java 2 Enterprise Editiontrade (J2EEtrade) architecture obviously is based on SQL interfaces to data such as Java Database Connectivity (JDBCtrade) The binary large object (BLOB) and character large object (CLOB) data types can only be used in SQL-created tables DB2 for i5OS 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 i5OS database it is easier to convince Microsoftreg 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 6 of 50

in your DB2 for i5OS 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 IO works with one row at a time A single SQL request can process multiple rows of data in one request in the native IO 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 6 of 50

in your DB2 for i5OS 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 IO works with one row at a time A single SQL request can process multiple rows of data in one request in the native IO 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 7 of 50

Approaches and optionsODBC JDBC PHP ADO DRDA XDA

Host server

Static Dynamic Extended dynamic

Compiled embedded statements

Prepare every time

Prepare once then reference

Optimizer

DB2 for i5OS

Native(record

IO)

SQL

Network

(Data storage and management)

CLI JDBC

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 i5OS 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 8 of 50

RestrictionsEVIs LOB columnsUDTs Datalinks and others

DDS-createdobjects

SQL-createdobjects

Nativeprograms

SQLprograms

ConsiderationsMultimember and multiformat files

Approaches and options (continued)

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 i5OS 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 IO 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 9 of 50

Modernizing definitions and objects

bull Terminology

bull Moving from DDS to SQL DDL

bull SQL object management

bull 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 i5OS There is a more detailed discussion about each of these over the next few charts

Page 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 10 of 50

Modernizing database objects

i5OSSQL

Terminology

log

column

row

index

view

table

Schema or collection

journal

field

record

keyed logical file

logical file

physical file

library

Modernizing database objects Terminology The first thing to comprehend is the terms used by the SQL interface and how they map to i5OS 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 ldquomemberrdquo is nowhere on the chart there is no SQL equivalent Most of these are self-explanatory An SQL schema is an i5OS library that contains both a journal and a journal receiver object each of which is created inside of the library automatically

Page 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 11 of 50

Tables or physical filesModernizing database definitions and objects

bull SQL tables compared with physical filesndash Advantages

bull More data typesbull Constraint definitions can be included in object sourcebull Faster readsbull Longer more descriptive column namesbull Support for a data-modeling toolbull DB2 attempts to journal tables automatically

ndash Disadvantagesbull Slower writesbull No DDM but SQL can utilize DRDA connectionsbull Multimember files

ndash SQL ALIAS provides the solutionCREATE 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 i5OS 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 i5OS 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 12 of 50

If you want to use data modeling tools you have a better chance of finding tools that support DB2 for i5OS 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 i5OS 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 13 of 50

Indexes or logical filesModernizing database definitions and objects

SQL indexes compared with keyed logical filesbull Advantages

ndash EVI structurendash 64KB logical-page size (since OS400 V4R2)

bull Improves performance of queries that scan lots of key values in an index (a 64 KB IO operation brings more keys into memory)

bull Single key lookups in index might or might not be as efficientbull Larger logical page size can lend itself to more efficient index maintenancebull Considerations

ndash Larger index pages can strain memory-starved environmentsndash SQL indexes that are journaled explicitly or implicitly (SMAPP) increase the size of

journal receiversraquo Use RCVSIZOPT(RMVINTENT MAXOPT2)raquo Journal Receiver threshold must be at least 65 GB

ndash Disadvantagesbull 8 KB logical-page sizebull No support for SelectOmit 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 i5OS 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 OS400 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 IO 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 single-key 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 14 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 IO 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 i5OS

Page 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 15 of 50

Views or logical filesModernizing database definitions and objects

bull SQL Views compared with logical filesndash Advantages

bull More flexibility in terms of selecting and processing datandash CASE expressions and Date and Time functionsndash Grouping and more advanced Join processing

bull Can be used as logical files to enhance native functionalityndash Disadvantages

bull Views cannot be keyed or orderedndash Does that mean Views have slower performance

raquo NO assuming that the right set of indexes and statistics are in place for the query optimizer to use

raquo View is used by SQL to transform data the query optimzers job is to find the best method to speed up selection or sorting

raquo 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 optimizers 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 keyedindexed access whenever the View is referenced this indirectly provides the same performance characteristics as a keyed logical file

Page 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 16 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects (continued)

bull iSeries Navigator Generate SQL Task (QSQGNDDL API)ndash Useful in converting object definitions from DDS to SQL

ndash Supports physical and logical filesbull Not all DDS features can be converted tool converts as much as possible and

generates warnings for unconvertible options (for example EDTCDE)bull Logical files converted to SQL Viewsbull SQL Field Reference File support not used

ndash Can convert a single object or a group of objects

ndash 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 i5OS 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 17 of 50

DDS-to-SQL conversion toolModernizing database definitions and objects

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

bull Generate the DDL statements directly into a new Run SQL scripts window (where you can immediately execute those statements)

bull 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 18 of 50

SQL object managementModernizing database definitions and objects

bull SQL source-management best practicesndash 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)bull If change management tools are not specific to i5OS store SQL scripts in PC or IFS

filesbull If SQL source is misplaced Generate SQL can be used to retrieve the SQL source

from System Catalogs (SYSIBM and QSYS2)ndash 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

bull Might need to adjust process for moving from development to productionndash Best practice is to reexecute the SQL creation scriptndash Save and Restore process for SQL databases documented at

ibmcomdeveloperworksdb2librarytecharticle0305milligan0305milliganhtml

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 OS400 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 SQL-created objects

Page 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 19 of 50

SQL object managementModernizing database definitions and objects

bull SQL Column and Object names have maximum lengths of 30 and 128 (respectively)

bull But many i5OS utilities commands and interfaces only support a 10-character length How does that workndash System automatically generates a short 10 character name

bull First five characters with unique 5-digit numberCUSTOMER_MASTER gtgt CUSTO00001

bull Might be different each time a specific table is created depending on creation order and what other objects share the same five-character prefix

bull Use i5OS SQL syntax to specify your own short namendash RENAME TABLE (tables and views) and RENAME INDEXndash FOR COLUMN clause for columnsndash 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 i5OS 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 20 of 50

SQL object management

Modernizing database definitions and objects (continued)

bull Coexistence example between Short and long namesndash Specify the short name at creation

CREATE TABLE dbtestcusmst(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

ndash Specify a long name for existing short name

RENAME TABLE dbtestcusmst TO customer_masterFOR SYSTEM NAME cusmst

bull 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 dbtestcustomer_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 record-format 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 IO programs then being able to control the format name with SQL minimizes the changes to your native program

Page 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 21 of 50

SQL object managementModernizing database definitions and objects (continued)

bull RENAME statement also controls the format and file name used by native programs1 Specify the format name (cmfmt) when creating the table

CREATE TABLE dbtestcmfmt(customer_name FOR COLUMN cusnam CHAR(20) customer_city FOR COLUMN cuscty CHAR(40))

2 Use RENAME to specify the short file name (cusmst) for the tableRENAME TABLE dbtestcmfmt TO cusmst

3 Use RENAME to specify the long name for SQL interfacesRENAME TABLE dbtestcusmst TO customer_master

FOR SYSTEM NAME cusmst

bull i5OS V5R4 simplifies control of the record-format name with a new SQL keyword

CREATE TABLE dbtestcustomer_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 SQL-created 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 22 of 50

SQL and nonrelational dataModernizing definitions and objects

bull User-defined table functionsndash Allows nonrelational and legacy data to be virtualized as an SQL table

SELECT FROM TABLE(myudtf(Part XYZ))

ndash Both SQL and External Table Functions supportedbull External UDTFs can be easily written to access multiformat files and stream files bull Table functions can only be invoked from SQL-based interfaces

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

object

bull LOBsndash 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 i5OS multiformat files These are all objects that SQL applications cannot access directly In OS400 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 high-level programming languages supported by i5OS If you have an existing i5OS 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 23 of 50

Moving business logic into DB2 (automatic key generation)Modernizing definitions and objects

bull Identity Column attributendash Attribute that can be added to any numeric columns to have DB2 generate next valuendash Not guaranteed to be unique primary key or unique index must be definedndash 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(namedept) VALUES(MIKE503A) orhellipINSERT INTO employee VALUES(DEFAULTMIKE 503A)

bull Sequence object ndash Separate object that can be shared across multiple tablesndash Generated value to be part of non-numeric keys

CREATE SEQUENCE order_seq START WITH 10 INCREMENT BY 10

INSERT INTO orders(ordnumcustnum) 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 i5OS 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 24 of 50

Moving business logic into DB2 (constraints)

CREATE TABLE orders( ordnum INTEGER PRIMARY KEYordqty INTEGER CHECK(ordqtygt0 AND ordqtylt999)ordamt DECIMAL(72)part_id CHAR(4)CONSTRAINT ordpart FOREIGN KEY(part_id) REFERENCES parts(PartID)

ON DELETE RESTRICT ON UPDATE RESTRICT )

Modernizing definitions and objects

bull Database constraints benefitsndash Easier code reuse and better modularityndash Improved data integrityndash Improved query performance SQE query optimizer is constraint-aware

bull Constraint typesndash Primary and unique key ndash Referential-integrity constraints

bull Enforce parent and child as well as masterand detail relationshipsndash Check constraints

bull Ensure that a column is only assigned legal values

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 uniquely-keyed 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 i5OS 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 25 of 50

Moving business logic into DB2 (triggers)

CREATE TRIGGER audit_salaryAFTER UPDATE ON employee(salary)REFERENCING NEW AS nREFERENCING OLD AS oFOR EACH ROW WHEN (nsalary - osalary gt= 5000)

INSERT INTO audit VALUES(nempno ndeptno nsalarycurrent timestamp)

Modernizing definitions and objects

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

bull DB2 for i5OS trigger support ndash Before and After Insert Update and Delete events (up to 300 triggers)ndash SQL and External(ADDPFTRG) triggers

bull Column-level and statement-level triggers only available with SQL triggers

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 i5OS with triggers A trigger is an SQL routine or i5OS program object that is associated with a database table and set in motion (or triggered) by a change in data DB2 for i5OS 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 i5OS to call the trigger logic automatically A DB2 for i5OS 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 i5OS allows you to create triggers with or without SQL For instance external triggers can also be used

Page 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 26 of 50

Modernizing data accessbull Programming Interfaces

bull Native IO to SQL comparison

bull Using SQL to reuse and repurpose existing code

bull DB2 and new application models

bull Tools

Modernizing data access DB2 application modernization uses the latest DB2 and SQL technologies for the processing and extracting of DB2 for i5OS data The five aspects are

bull Programming Interfaces bull Native IO to SQL comparison bull Using SQL to reuse and repurpose existing code bull DB2 and new application models bull Tools

The next few charts review these in more detail

Page 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 27 of 50

Modernizing data accessProgramming interfaces

DB2 for i5OS SQL Development Kit required only if using embedded SQL (and STRSQL)

RUNSQLSTM

NetData

CLI ODBC PHP

XDA API setOLE DB NET

IBM Toolbox for Java JDBC and iSeries Access

ODBC

JDBC SQLJ

QSQPRCEDEmbedded dynamicEmbedded static

Extended-dynamicSQL

Dynamic SQLStatic SQL

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 i5OS 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 i5OS also supports SQLJ but is not as commonly used NetData provides an SQL interface for those writing CGI-Bin programs to provide a browser interface into DB2 for i5OS The NetData SQL interfaces make it easy to display your business data in an HTML page

Page 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 28 of 50

Modernizing data access C SearchKey KListC Kfld SearchYearC Kfld SearchMonth C Times Occur Resu lt_SetC SearchKey Set ll TIME_DIML1 C If FOUND C DOU RowsReq = Rows Rd C READ TIME_DIML1 C If EOF C Leave C EndifC DATEKEY Set ll ITEMFACTL1 C If FOUND C DOU RowsReq = RowsRdC DATEKEY READE ITEMFACTL1 C If EOF C Leave C EndifC PARTKEY CHAIN PART_DIML1 C If Not FOUND C IterC EndifC CUSTKE Y CHAIN CUST_DIML1 C If Not FOUND C IterC EndifC SUP PKEY CHAIN SUPP_DIML1 C If Not FOUND C IterC Endif

FREE

exec sqlDECLARE sql_jn CURSOR FOR SE LE CT t yeart mon th iorderdt ccou nt ryccust

ppart s su pplier iqu an tityireven u eFROM item_fact i INNER J OIN par t _dim p ON (ipart id =ppar t id) INNER J OIN t ime_dim t ON (iorderdt =t da tekey) INNER J OIN cust _dim c ON (icustid=ccustid) INNER J OIN supp_dim s ON (isuppid=ssu ppid) WHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jnFOR RowsReq ROWS INTO resu lt _set

if SQLCOD = 0 and SQLER5 = 100 an d SQLE R3 gt 0

RowsRd = SQLER3 hellipE ND-FRE E

Native IO to SQL example

Modernizing data access Native IO to SQL example This example is a side-by-side comparison of the native IO 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 IO example retrieves all of the fields In order for the native IO program to retrieve a subset of fields from each table a new logical file must be created for each table

Page 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 29 of 50

Modernizing data access

FREE exec sql

DE CLARE sql_jn CURSOR FOR SE LECT FROM J oin ViewWHE RE year=1998 AND mont h =6

exec sqlOPE N sql_jn

exec sqlFE TCH NE XT FROM sql_jn FOR RowsReq ROWS INTO resu lt _set

If SQLCOD = 0 an d SQLER5 = 100 an d SQLER3 gt 0

RowsRd = SQLER3 E ndif

E ND-FRE E

C Search Key KListC Kfld Search YearC KfldSearch Mon th

C Search Key Set ll NTVJ OIN002 C If FOUND C DO RowsReq Times C Times Occu r Resu lt _SetC RE AD NTVJ OIN002 C If E OF C Leave C E n dif

C E val RowsRd = RowsRd + 1C E NDDO

C E n dif

Native IO to SQL example (Joined LFs and Views)

Modernizing data access Native IO to SQL example (Joined Logical Files and Views) A programmer who is accustomed to using the native IO system might argue that the previous native IO 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 30 of 50

Native IO to SQL example (performance comparison)Modernizing data access

Note Tests run on Model 720 w1600 CPW and 2 GB Memory - your performance results may vary

Number of Rows0

5

10

15

20

25Ti

me

(sec

)

Native File JoinNative JoinLFNative JoinLF wSQL - No IOASQL IOASQL SQE IOA

1 100 1000 100000002512 0260248 2219504 232281760002304 0362128 2544608 213664800002400 2144288 2125032 193114640145160 0489136 3166704 204529840251168 0267208 0417800 18988000013536 0019320 0250160 1576536

Modernizing data access Native IO to SQL example (performance comparison) One of the biggest reasons System i programmers decide not to use SQL is that they believe native IO data access is a better performing interface This chart compares the performance of the SQL and native IO programming examples that were just reviewed In general when processing sets of data SQL performance is equivalent to or better than native access Native IO 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 IO 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 IO 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 IO operation it does NOT perform the second IO operation against the underlying table In this example all executions of SQL perform block fetches

Page 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 31 of 50

Comparing SQL and native performanceModernizing data access

RPG SQLArrival sequence 202 000 173 000

Keyed access 131 000 117 000

Keyed access(memory-constrained) 8000 12 000

Pseudo-randomKeyed access 3950 3440

Direct-key access 5100 4100

rows perminute

Published by NEWS400 in March 2000 measured on OS400 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 mdash 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 IO 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 32 of 50

Native to SQL considerations Modernizing data access

bull ORDER BY clause is the only way to guarantee sequencing of results with SQLbull Without the clause ordering occurs by chance bull Support for free-format embedded SQL (added in i5OS V5R4)bull SQL precompilers do not support all the latest features still missing from RPG

precompiler in i5OS V5R4ndash Support for properly scoping a local variable in a subprocedure as a host variable in an SQL

statement (multipass)ndash Support for qualified names with more than one level of qualification

bull Consider the impact of the SQL isolation level and journaling on native applications bull Critical performance success factors

ndash Sound indexing and statistics strategy ndash Reusable Open Data Paths (ODPs)

bull Prepare once execute manybull Connection poolingbull Keep connections and jobs active as long as possible

ndash Blocked Fetches and Inserts

Modernizing data access Native to SQL considerations There are a few issues to consider when using SQL instead of native IO 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 i5OS V5R4 are listed in the graphic Notice that support of embedded SQL in free-format RPG is provided in i5OS 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 NONENC 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 WebSpherereg and Enterprise JavaBeanstrade (EJBtrade) 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 33 of 50

One key requirement is to have a sound indexing strategy mdash to put indexes in place for the query optimizer to use for your most critical or frequently-run SQL statements The white paper entitled ldquoIndexing and statistics strategies for DB2 for iSeries ndash Version 3rdquo 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 ldquoDB2 for i5OS SQL Performance Basicsrdquo (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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 34 of 50

Using SQL to reuse and repurpose existing codeModernizing data access

bull OPNQRYF (SQL)ndash Retain ldquoset at a time processingrdquo but provide data using SQL

bull Stored procedures functions and triggers provide vehicle for improving and changing the solutionrsquos architecturendash Better modularity as the result of allowing code reuse by multiple interfaces

and applicationsndash Better partitioning of logic (separation of presentation and database logic)ndash Easy transition to multitier architectures because many interfaces exist for

remote invocationsbull DB2 for i5OS support provides maximum flexibility by supporting both

SQL and external typesndash External support allows reuse of existing i5OS application code and skillsndash SQL Procedural Language (PSM) enables better portability of logic (and

programming skills) to and from other platformsndash Data security can be enhanced and maintained with i5OS 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 i5OS provides maximum flexibility in this area by allowing these DB2 objects to be created either entirely in SQL or with any i5OS 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 i5OS adopted authority can be used to limit the security exposure when making business functions available to new interfaces and applications

Page 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 35 of 50

Using SQL to reuse and repurpose existing code (UDFs)Modernizing data access

bull UDFs allow the database to invoke user-written functions during the processing of an SQL statementndash Allows you to customize SQL to meet your business requirementsndash Example

CREATE FUNCTION Euro(EuroAmt DECIMAL(112)) RETURNS DECIMAL(112) LANGUAGE SQLBEGIN

DECLARE rate DECIMAL(95)

SELECT conversion_rate INTO rate FROM ratetable WHERE RETURN rateEuroAmt

END

SELECT item_name Euro(item_price) FROM parts

Modernizing data access Using SQL to reuse and repurpose existing code (UDFs) DB2 for i5OS 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 36 of 50

Using SQL to reuse and repurpose existing code (procedures)Modernizing data access

bull Stored procedures are similar to UDFs but are invoked with an SQL Call statement ndash More than just a remote program call

bull Supported by the majority of the application development tools and languagesbull Result sets can improve performance by minimizing network trips

ndash Procedures are most effective when performing multiple operations on a single procedure call

ndash Considerations for external proceduresbull Might have to make slight modifications to existing code to match stored-procedure

parameter conventions or develop wrapper proceduresbull Need to design process for installing and upgrading stored procedures

ndash Considerations for SQL Proceduresbull Generated C code with embedded SQL not as fast as user-written codebull Minimize the number of nested calls to other SQL proceduresbull 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 i5OS 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 37 of 50

DB2 and new application models (distributed transactions)Modernizing data access

bull DB2 for i5OS supports XA transactionsndash i5OS Transaction Manager was substantially enhanced in i5OS V5R2 for

distributed transaction modes including support for JTA

ndash i5OS XA support is designed for SQL interfaces

ndash 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 i5OS operating system provides support for the XA standard and the Java equivalent the Java Transaction API (JTA) Although the i5OS 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 38 of 50

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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

DB2 and new application models (Web services)

ltxml version=10gtltDADX xmlns=httpschemasibmcomdb2dxxdadx

xmlnsxsd=httpwwww3org2001XMLSchemagtltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtAccesses city instead of zip code database

ltdocumentationgtltoperation name=findCityByZipCodegt

ltdocumentation xmlns=httpschemasxmlsoaporgwsdlgtFinds the city for a zip code ltdocumentationgt

ltquerygtltSQL_querygtSELECT CITY FROM DEMOCITY_TAB WHERE ZIPCODE = zipcodeltSQL_querygtltparameter name=zipcode type=xsdstringgt

ltquerygtltoperationgt

ltDADXgt

Modernizing data access

bull DB2 Web services (WORF)ndash Easily create simple XML-based Web services that access DB2

bull Part of Websphere Expressndash 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

ndash Used through Websphere and SOAPbull SQL Select Update Insert Delete and other proceduresbull XML extenders can also be used

ndash Read more at ibmcomserversenablesiteeducationabstractsdb2web_abshtml

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 mdash 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 ldquoDB2 UDB for iSeries and Web Servicesrdquo 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 Java-application 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 39 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 40 of 50

DB2 and new application models (XML and text mining)Modernizing data access

bull DB2 Extenders provide low-level plumbing to allow you to concentrate on the business logic

bull DB2 and XML integration with DB2 XML Extenderndash Allows an XML document to be stored and retrieved from a columnndash Enables XML document to be generated dynamically from existing DB2 datandash Provides ability to decompose an XML document and generate new database rows

bull Text mining with DB2 Text Extenderndash High-speed sophisticated searches for any character columns

bull Fuzzy searchesbull Search on tenses of word bull Customize search to words in same sentence or paragraph

ndash Can also search text documents stored in IFS

bull Reference ibmcomserversenablesiteeducationiborecordhtmldb2udbext

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 i5OS By incorporating XML information and meta-information 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 ldquoDB2 UDB Extenders for iSeries - V5R2 Updaterdquo for more details on the DB2 XML and text extenders (See the Links section of this course for the URL)

Page 41 of 50

Development toolsModernizing data access

bull WebSphere Development Studio Client for iSeriesndash DB2 Web service supportndash XML Extender aidsndash SQL statement wizard

bull RSE and Code400 coexist with SQLbull PDM has basic SQL prompting supportbull Visual Studio NET pluginsbull DB2 Information Integrator for non-DB2 data accessbull Reference ibmcomserversenablesiteeducationiborecordhtmlhetdatabull DB2 Development Center

ndash Stored procedures ndash User-defined functions

bull IBM DB2 Query Management Facility (QMF) Distributed Editionndash 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 Query400) 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 42 of 50

Development toolsModernizing data access (continued)

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugging(ibmcomserversenablesiteeducationabstractssqldebug_abshtml)

bull iSeries Navigatorndash Editors for procedure functions triggersndash SQL statement wizard for Insert Select Update Deletendash Downloadable tutorials at

ibmcomserversenablesiteeducationiboviewhtmlocdb2bull Visual Explainbull Database Monitor (STRDBMON CL command)bull PRTSQLINF bull DB2 SMP licensed feature (i5OS 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 i5OS 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 mdash 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 i5OS 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 43 of 50

Next stepsbull Education

ndash Modernizing iSeries Application Data Access Redbookwwwredbooksibmcomabstractssg246393htmlOpen

ndash Case study Modernizing a DB2 for iSeries Application white paperibmcomserversenablesiteeducationabstracts9e5a_abshtml

ndash DB2 for iSeries Performance Workshop bull ibmcomserverseserveriseriesserviceigsdb2performancehtmlbull ibmcomserversenablesiteeducationiboviewhtmlocdb2

ndash ldquoIndexing and Statistics Strategyrdquo white paperibmcomserversenablesiteeducationiborecordhtmlindxng

ndash Database modernization roadmapsbull Modernizing DB2 definitions and usage

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitibull Modernizing data access with SQL

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitjbull Maximizing SQL performance

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinithbull Identify first project

ndash Write a new function or program component using SQLndash Rewrite existing components by using SQL (for example reporting function)ndash Port SQL-based program to DB2 for i5OS

bull Porting guides and conversion tools at ibmcomserversenablesitedb2portinghtml

bull Get helpndash eServer Custom Technology Center wwwibmcomctcndash System i IBM Global Services team heithoffusibmcom

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 IO 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 44 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 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 40 of 50

DB2 and new application models (XML and text mining)Modernizing data access

bull DB2 Extenders provide low-level plumbing to allow you to concentrate on the business logic

bull DB2 and XML integration with DB2 XML Extenderndash Allows an XML document to be stored and retrieved from a columnndash Enables XML document to be generated dynamically from existing DB2 datandash Provides ability to decompose an XML document and generate new database rows

bull Text mining with DB2 Text Extenderndash High-speed sophisticated searches for any character columns

bull Fuzzy searchesbull Search on tenses of word bull Customize search to words in same sentence or paragraph

ndash Can also search text documents stored in IFS

bull Reference ibmcomserversenablesiteeducationiborecordhtmldb2udbext

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 i5OS By incorporating XML information and meta-information 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 ldquoDB2 UDB Extenders for iSeries - V5R2 Updaterdquo for more details on the DB2 XML and text extenders (See the Links section of this course for the URL)

Page 41 of 50

Development toolsModernizing data access

bull WebSphere Development Studio Client for iSeriesndash DB2 Web service supportndash XML Extender aidsndash SQL statement wizard

bull RSE and Code400 coexist with SQLbull PDM has basic SQL prompting supportbull Visual Studio NET pluginsbull DB2 Information Integrator for non-DB2 data accessbull Reference ibmcomserversenablesiteeducationiborecordhtmlhetdatabull DB2 Development Center

ndash Stored procedures ndash User-defined functions

bull IBM DB2 Query Management Facility (QMF) Distributed Editionndash 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 Query400) 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 42 of 50

Development toolsModernizing data access (continued)

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugging(ibmcomserversenablesiteeducationabstractssqldebug_abshtml)

bull iSeries Navigatorndash Editors for procedure functions triggersndash SQL statement wizard for Insert Select Update Deletendash Downloadable tutorials at

ibmcomserversenablesiteeducationiboviewhtmlocdb2bull Visual Explainbull Database Monitor (STRDBMON CL command)bull PRTSQLINF bull DB2 SMP licensed feature (i5OS 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 i5OS 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 mdash 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 i5OS 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 43 of 50

Next stepsbull Education

ndash Modernizing iSeries Application Data Access Redbookwwwredbooksibmcomabstractssg246393htmlOpen

ndash Case study Modernizing a DB2 for iSeries Application white paperibmcomserversenablesiteeducationabstracts9e5a_abshtml

ndash DB2 for iSeries Performance Workshop bull ibmcomserverseserveriseriesserviceigsdb2performancehtmlbull ibmcomserversenablesiteeducationiboviewhtmlocdb2

ndash ldquoIndexing and Statistics Strategyrdquo white paperibmcomserversenablesiteeducationiborecordhtmlindxng

ndash Database modernization roadmapsbull Modernizing DB2 definitions and usage

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitibull Modernizing data access with SQL

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitjbull Maximizing SQL performance

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinithbull Identify first project

ndash Write a new function or program component using SQLndash Rewrite existing components by using SQL (for example reporting function)ndash Port SQL-based program to DB2 for i5OS

bull Porting guides and conversion tools at ibmcomserversenablesitedb2portinghtml

bull Get helpndash eServer Custom Technology Center wwwibmcomctcndash System i IBM Global Services team heithoffusibmcom

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 IO 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 44 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 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 41 of 50

Development toolsModernizing data access

bull WebSphere Development Studio Client for iSeriesndash DB2 Web service supportndash XML Extender aidsndash SQL statement wizard

bull RSE and Code400 coexist with SQLbull PDM has basic SQL prompting supportbull Visual Studio NET pluginsbull DB2 Information Integrator for non-DB2 data accessbull Reference ibmcomserversenablesiteeducationiborecordhtmlhetdatabull DB2 Development Center

ndash Stored procedures ndash User-defined functions

bull IBM DB2 Query Management Facility (QMF) Distributed Editionndash 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 Query400) 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 42 of 50

Development toolsModernizing data access (continued)

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugging(ibmcomserversenablesiteeducationabstractssqldebug_abshtml)

bull iSeries Navigatorndash Editors for procedure functions triggersndash SQL statement wizard for Insert Select Update Deletendash Downloadable tutorials at

ibmcomserversenablesiteeducationiboviewhtmlocdb2bull Visual Explainbull Database Monitor (STRDBMON CL command)bull PRTSQLINF bull DB2 SMP licensed feature (i5OS 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 i5OS 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 mdash 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 i5OS 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 43 of 50

Next stepsbull Education

ndash Modernizing iSeries Application Data Access Redbookwwwredbooksibmcomabstractssg246393htmlOpen

ndash Case study Modernizing a DB2 for iSeries Application white paperibmcomserversenablesiteeducationabstracts9e5a_abshtml

ndash DB2 for iSeries Performance Workshop bull ibmcomserverseserveriseriesserviceigsdb2performancehtmlbull ibmcomserversenablesiteeducationiboviewhtmlocdb2

ndash ldquoIndexing and Statistics Strategyrdquo white paperibmcomserversenablesiteeducationiborecordhtmlindxng

ndash Database modernization roadmapsbull Modernizing DB2 definitions and usage

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitibull Modernizing data access with SQL

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitjbull Maximizing SQL performance

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinithbull Identify first project

ndash Write a new function or program component using SQLndash Rewrite existing components by using SQL (for example reporting function)ndash Port SQL-based program to DB2 for i5OS

bull Porting guides and conversion tools at ibmcomserversenablesitedb2portinghtml

bull Get helpndash eServer Custom Technology Center wwwibmcomctcndash System i IBM Global Services team heithoffusibmcom

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 IO 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 44 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 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 42 of 50

Development toolsModernizing data access (continued)

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugging(ibmcomserversenablesiteeducationabstractssqldebug_abshtml)

bull iSeries Navigatorndash Editors for procedure functions triggersndash SQL statement wizard for Insert Select Update Deletendash Downloadable tutorials at

ibmcomserversenablesiteeducationiboviewhtmlocdb2bull Visual Explainbull Database Monitor (STRDBMON CL command)bull PRTSQLINF bull DB2 SMP licensed feature (i5OS 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 i5OS 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 mdash 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 i5OS 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 43 of 50

Next stepsbull Education

ndash Modernizing iSeries Application Data Access Redbookwwwredbooksibmcomabstractssg246393htmlOpen

ndash Case study Modernizing a DB2 for iSeries Application white paperibmcomserversenablesiteeducationabstracts9e5a_abshtml

ndash DB2 for iSeries Performance Workshop bull ibmcomserverseserveriseriesserviceigsdb2performancehtmlbull ibmcomserversenablesiteeducationiboviewhtmlocdb2

ndash ldquoIndexing and Statistics Strategyrdquo white paperibmcomserversenablesiteeducationiborecordhtmlindxng

ndash Database modernization roadmapsbull Modernizing DB2 definitions and usage

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitibull Modernizing data access with SQL

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitjbull Maximizing SQL performance

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinithbull Identify first project

ndash Write a new function or program component using SQLndash Rewrite existing components by using SQL (for example reporting function)ndash Port SQL-based program to DB2 for i5OS

bull Porting guides and conversion tools at ibmcomserversenablesitedb2portinghtml

bull Get helpndash eServer Custom Technology Center wwwibmcomctcndash System i IBM Global Services team heithoffusibmcom

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 IO 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 44 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 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 43 of 50

Next stepsbull Education

ndash Modernizing iSeries Application Data Access Redbookwwwredbooksibmcomabstractssg246393htmlOpen

ndash Case study Modernizing a DB2 for iSeries Application white paperibmcomserversenablesiteeducationabstracts9e5a_abshtml

ndash DB2 for iSeries Performance Workshop bull ibmcomserverseserveriseriesserviceigsdb2performancehtmlbull ibmcomserversenablesiteeducationiboviewhtmlocdb2

ndash ldquoIndexing and Statistics Strategyrdquo white paperibmcomserversenablesiteeducationiborecordhtmlindxng

ndash Database modernization roadmapsbull Modernizing DB2 definitions and usage

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitibull Modernizing data access with SQL

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinitjbull Maximizing SQL performance

wwwdeveloperibmcomvichardwaremyportaldeveloproadmaproadMapId=appinithbull Identify first project

ndash Write a new function or program component using SQLndash Rewrite existing components by using SQL (for example reporting function)ndash Port SQL-based program to DB2 for i5OS

bull Porting guides and conversion tools at ibmcomserversenablesitedb2portinghtml

bull Get helpndash eServer Custom Technology Center wwwibmcomctcndash System i IBM Global Services team heithoffusibmcom

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 IO 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 44 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 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 44 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 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 45 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate DB2 for i5OS Family (Test 700)ndash Web site ibmcomcertifycertsdbdaudv81shtmlndash Education resources ibmcomcertifytestsedu700shtmlndash Online tutorial

www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtmlbull Certified Application Developer DB2 for i5OS Family (Test 703)

ndash Web site ibmcomcertifycertsdbapudv81shtmlndash Education resources ibmcomcertifytestsedu703shtml

bull Sample tests certifytorolabibmcomice bull Exams are refreshed and updated for DB2 for i5OS

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 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 46 of 50

Summarybull SQL is everywherebull DB2 for i5OS supports both native and SQL-based interfacesbull DDS objects can be converted to SQL through the use of the i5OS QSQGNDDL API bull SQL on the System i platform supports relational and nonrelational data objectsbull SQL supports moving business logic into the the DB2 engine

ndash Better modularization and isolation of data and business logicbull SQL and DB2 for i5OS support Java XML and Web servicesbull There are many development tools for SQL and DB2 for i5OS

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 mdash 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 IO-intensive applications DB2 for i5OS 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 mdash it is not an inflexible process The SQL interface options include static SQL dynamic SQL and extended-dynamic SQL The QSQGNDDL i5OS 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 OS400 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 i5OS also support new Java-based application development for todayrsquos Web-driven environments This support is provided through the XA standard and

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 47 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 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 48 of 50

Links White papers and articles

bull Indexing and statistics strategies for DB2 UDB for iSeries - Version 30 ibmcomserversenablesiteeducationabstractsindxng_abshtml

bull DB2 UDB for iSeries and Web Services ibmcomserversenablesiteeducationabstractsdb2web_abshtml

bull DB2 Information Integrator for non-DB2 data access ibmcomserversenablesiteeducationiborecordhtmlhetdata

Online courses

bull DB2 UDB for iSeries SQL Performance Basics ibmcomserversenablesiteeducationabstractsdb2sql_abshtml

bull DB2 UDB Extenders for iSeries - V5R2 Update ibmcomserversenablesiteeducationiborecordhtmldb2udbext

bull IBM Toolbox for Java graphical debugger for ILE and SQL source-level debugger ibmcomserversenablesiteeducationabstractssqldebug_abshtml

bull iSeries Navigator DB2 interfaces (several online courses) ibmcomserversenablesiteeducationiboviewhtmlocdb2

bull Other courses ibmcomeserveriseriesdb2db2educ_mhtm

IBM Redbookstrade

bull ibmcomredbooks

Stored Procedures and Triggers on DB2 UDB for iSeries (SG24-6503)

DB2 UDB for AS400 Object Relational Support (SG24-5409)

Advanced Functions and Administration on DB2 UDB for iSeries (SG24-4249)

Workshops

bull DB2 for i5OS SQL Performance ibmcomserverseserveriseriesserviceigsdb2performancehtml

bull Other DB2 workshops ibmcomserversenablesiteeducationiboviewhtmlocdb2

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 49 of 50

DB2 for i5OS Family certifications

bull Certified Database Associate - DB2 for i5OS Family (Test 700) ibmcomcertifycertsdbdaudv81shtml

Study resources ibmcomcertifytestsedu700shtml

Tutorials www7bboulderibmcomdmddlibrarytutorialsdb2certdb2cert_V8_tuthtml

bull Certified Application Developer - DB2 for i5OS Family (Test 703) ibmcomcertifycertsdbapudv81shtml

Study resources ibmcomcertifytestsedu703shtml

Sample tests certifytorolabibmcomice

Other helpful Web sites

bull IBM eServer Custom Technology Center ibmcomctc

bull DB2 for i5OS home page ibmcomeserveriseriesdb2

bull DB2 online manuals ibmcomeserveriseriesdb2bookshtm

bull DB2 porting help ibmcomserversenablesitedb2portinghtml

bull Book SQL400 Developers Guide by Paul Conte and Mike Cravitz httpas400networkcomstrbooksUniquebook2cfmNextBook=183

Newsgroups

bull USENET newsgroup compsysibmas400misc compdatabasesibm-db2

bull iSeries Network (NEWS400 Magazine) SQL and DB2 Forum wwwiseriesnetworkcomForumsmaincfmCFApp=59

Page 50 of 50

Trademarks and special notices copy 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 i5OS IBM the IBM logo OS400 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 IBMs 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