IBM STG Lab Services and Training

Embedding SQL the IBM i Way

Dan Cruikshank
Agenda

 Getting Started with Embedded SQL

 Writing Flexible and Reusable SQL

 Dynamic SQL
 RPG Open Access
Getting Started with Embedded SQL

 Is There a Difference?

Host Language SQL

Reasons for Using Embedded SQL in HLL Programs

 Leverage HLL skills with SQL set based processing when

accessing large amounts of data
– Blocked FETCH and INSERT.
 Take advantage of HLL programming constructs not
available to DB2 SQL Procedure Language (PSM)
– Externally described data structures
– SQL can use descriptors but does support blocked FETCH
 Use ILE concepts
– Prototyped Procedures
– Modules
 Rdi Visual Application Diagramming
Rdi Visual Application Diagram (VAD)

You
want
this!!!
Rules for Embedding SQL in HLL programs

 Each SQL statement must begin with EXEC SQL and end
with a semicolon (;)
 The EXEC SQL keywords must be on the same line
– The SQL statement can be on the same line or multiple lines

 Only 1 SQL statement for each EXEC SQL group

 Refer to the Embedded SQL Programming manual for other
language specific restrictions/conventions
– http://www-
01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzajp/rzajpkickof
f.htm
Types of SQL

 Embedded SQL is a general term for SQL in an application

program and can be either Static or Dynamic
– Static SQL validated during compilation
– Dynamic SQL validated during preparation
– Both produce plans that can be shared and reused

 Both Static and Dynamic can be used in the same program

– SQL EXEC SELECT COUNT(*) INTO…
– SQL EXEC EXECUTE IMMEDIATE ‘CREATE ALIAS…’
WRITING FLEXIBLE AND
REUSABLE SQL
Writing Flexible and Reusable SQL

 A reusable SQL procedure is one that can be called from

multiple procedures.
 A flexible SQL procedure is a reusable procedure that:
– Imports varying input parameters
– Produces varying output based on that input
– And does it without program modification
 The following fall within this definition:
– Integrated Language Environment (ILE)
• Modules and Service Programs
– Dynamic SQL with simplified SQL descriptor usage
– Flexible views (use of global variable)
 There are several new SQL and High Level Language (HLL)
enhancements on IBM i that make this possible
VAD for Integrated Language Environment (ILE)

Flexible Service Program

Prototyped procedures are
coded once and reused.

Custom SQL code modules.

No Bound to program module
SQL to create a single program object
Easy to clone

Embedded SQL
referencing cursors
cannot be re-used.
VAD for SQL Modules and Service Programs

 Many SQL statements support host variables

 These statements need only be coded once in a service program
– Parameters can be used to provide variables

Custom SQL
Module

Service Program
SQL and HLL Enhancements

 Many new enhancements have been made in the last

decade that makes coding in SQL more attractive
– SQL Enhancements
• Result Set Consumption by HLL
• Global Variables
• Simplified SQL Descriptor Usage
• Named And Default Parameters For SQL Procedures
• Plus more
– HLL Enhancements
• CL RUNSQL command
• RPG total free format coding
• RPG Open Access
 Keeping up to date
– DB2 for i Web Page
• http://www-03.ibm.com/systems/power/software/i/db2/index.html
– DB2 for i Technology Updates
SQL Enhancement: Result Set Consumption

– New SQL statements allow simplification of result set consumption by host centric
programs using embedded SQL
• ASSOCIATE LOCATORS and ALLOCATE CURSOR
 Allows common stored procedures for both host centric and external
applications
– Result set can be returned to caller (RPG/COBOL) or client (Java, .NET, PHP,
etc.)
 Conceptual use of result set consumption

CALL SQLLE2 () SP1

• CALL SP1 • DECLARE CURSOR

• ASSOCIATE/ALLOCATE cursor • OPEN CURSOR WITH RETURN TO
• FETCH from allocated cursor CALLER
• CLOSE cursor when complete

Data Flow
Result Set
VAD for Result Set Consumption

Cursor names
cannot be
variables

Procedure names
and result set
locators can be
variables. Diagnostics and
error handling
Called procedure
result set can be Service program can contain
consumed by other multiple modules
applications.
Using Host Variables

 Host Variable
– Single field commonly used to:
• specify a value in the predicate of a search condition
• replace a literal value in an expression
• Provide a target to receive a value from an INTO clause
 Host Structure
– A group of host variables commonly used to:
• Specify values for VALUES clause (INSERT), SET clause (UPDATE)
• Provide a target to receive multiple values from a FETCH or SELECT
INTO
 Host Structure Array
– A multiple occurrence data structure or array
• Commonly used for blocked FETCH and INSERT statements
• Currently not supported in SQL PL
 SQL Descriptor
– A flexible Host Structure
SQL Enhancements: Global Variables

 SQL Global variables can be used for inter-application communication

– Similar to HLL Import/Export
 Instantiated in session (job) on first reference
– Each session has it’s own global variables and values
 Example of creating a global variable
– CREATE VARIABLE PROC_NAME VARCHAR(300) DEFAULT NULL;
 Conceptual use of global variable

CALL SQLLE1 () SQLLE2 SP1

• SET PROC_NAME = • SET vSQL = CONCAT(‘CALL’, • DECLARE CURSOR

‘SP1’ PROC_NAME) • OPEN CURSOR WITH
• CALL SQLLE2 (); • PREPARE CALL_PROC FROM RETURN TO CALLER
vSQL
• EXECUTE CALL_PROC

Result
Set
VAD for Global Variables

Reusable
Application service imports
exports global global variable
variable.

Reusable service
GetGV may not be program module
required in most SQL contains setters and
Statements as GV can getters.
be referenced directly.
DYNAMIC SQL
Advantages of Dynamic SQL

 Offers a high degree of application flexibility

 You can create/build SQL statement based on parameters
received from:
– Interactive user interface
– List selection techniques
– Application control file
– RPG Open Access
Dynamic SQL Concepts
 Statement is defined and executed at program run time
– PREPARE then DECLARE dynamic cursor for SELECT
– PREPARE then EXECUTE for INSERT,UPDATE, DELETE
– EXECUTE IMMEDIATE for DDL statements (ALIAS, CREATE
INDEX, etc)

 Two types of dynamic SELECT statements

– Fixed list – result columns are predictable and can be pre-
defined
– Varying list – result columns can vary, SQLDA required to
define host variables

 Parameter Markers
– A placeholder (?) for substitution variables used in dynamic
SQL statements
SQL Descriptor Areas
What are they? Where could they be used?
 An SQL descriptor area is used to  Column lists
contain information about a  Data for VALUES on INSERT or
dynamic SQL statement UPDATE
 A set of variables are used to  Data for WHERE clauses
communicate this information  Example
between SQL and your program sqlString = ‘DELETE FROM T1
– Think externally described data WHERE EMPNO = ?’;
structure with a variable file name
EXEC SQL PREPARE S1 USING SQL
 The meaning of the information in
DESCRIPTOR :sqlDescriptor
the descriptor area depends on the
FROM :sqlString;
type of statement
– SELECT or non-SELECT EXEC SQL SET SQL DESCRIPTOR
(UPDATE, INSERT, etc.) :sqlDescriptor DATA = :vEmpno;
EXECUTE S1 USING
:sqlDescriptor;
Simplified SQL Descriptor Usage

 New SQL statements available for passing and receiving variable

information from the database
– ALLOCATE/DEALLOCATE DESCRIPTOR GLOBAL ‘INPUTPARMS’
– SET/GET DESCRIPTOR GLOBAL
 Global Descriptor similar in concept to Global Variable
 Simplified alternative method to using SQLDA
 Conceptual use of global SQL descriptors

Job/Thread Init SP1 SP2

•EXEC SQL •EXEC SQL SET •EXEC SQL GET DESCRIPTOR GLOBAL
ALLOCATE DESCRIPTOR GLOBAL ‘INPUTPARMS’ COUNT
DESCRIPTOR ‘INPUTPARMS’ COUNT •EXEC SQL PREPARE S1
GLOBAL •EXEC SQL SET •EXEC SQL DECLARE C1 FROM S1
‘INPUTPARMS’ DESCRIPTOR GLOBAL •IF count > 0
•EXEC SQL CALL SP1 ‘INPUTPARMS’ VALUE 1
() •EXEC SQL OPEN C1 USING DESCRIPTOR
•EXEC SQL CALL SP2 () GLOBAL ‘INPUTPARMS’
•Else
Job or •EXEC SQL OPEN CI
Thread •Endif
Input Descriptor

 The SQL DESCRIBE INPUT statement is used to populate an INPUT

descriptor prior to using an SQL EXECUTE statement

Process •

• UPDATE…SET
• PREPARE Statement-name FROM
(edlevel ) = (?)
:sqlString
• SELECT…WHERE
• SET SQL DESCRIPTOR GLOBAL
:inputParms COUNT :columns
workdept = ?
• DESCRIBE INPUT USING SQL
• CALL proc (?,?,?)
DESCRIPTOR GLOBAL :inputParms
Statements • SET SQL DESCRIPTOR GLOBAL
:inputParms VALUE N DATA =
:hostvar
• EXECUTE Statement-name USING
SQL DESCRIPTOR GLOBAL
:inputParms Descriptors
VAD Dynamic SQL Application Overview

Setters/ Getters Cursors/ Result Sets

Application Custom SQL Diagnostics

module and Error
handling

Dynamic SQL
VAD Dynamic SQL – Setters and Getters
1. *INZSR is used to allocate the global
descriptor and set the name in a global
variable
2. The SQL string is set as part of the
transaction process
INSERT INTO t1 (c1,c2) VALUES(?,?)
3. SQL string and descriptor name (4) are
imported by service program
VAD Dynamic SQL Global Descriptors and Variables

4. Transaction is Add, 5. Prepare the imported SQL

Change or Delete string
6. Execute the string using the
global descriptor values

1. *INZSR
2. Number of
parameter markers
3. SET DATA and
INDICATOR for each
parameter
Named And Default Parameters For SQL Procedures
 Extend procedures without breaking existing callers
 Simplify calling requirements by adding default values
– Parameters may be omitted or specified in any order
– Default can be expressions or global variables
 Examples of using named and default parameters
– CALL SQLLE1 (‘D21’); CALL SQLLE1 (PARM2 => 16);
 Conceptual usage:
CALL SQLLE1 SQLLE2 SP1
(PARM2 =>16);

• IN PARM_COUNT INTEGER • SET vSQL = • GET DESCRIPTOR

• IN PARM1 DEFAULT NULL CONCAT(‘CALL’, GLOBAL count
• ALLOCATE DESCRIPTOR PROC_NAME) • PREPARE S1
GLOBAL • PREPARE • DECLARE C1 FROM S1
• SET DESCRIPTOR CALL_PROC FROM • IF count > 0
PARM_COUNT vSQL
• OPEN C1 USING
• If parm_count > 0 • EXECUTE descriptor
CALL_PROC
• SET DESCRIPTOR VALUE(1) • Elsse
DATA(PARM1) • OPEN CI
• End if • Endif
• SET PROC_NAME = ‘SP1’
• CALL SQLLE2 ()

Result
Set
RPG OPEN ACCESS
Open Access Structure

 An Open Access application has three parts:

1. An RPG program that uses normal RPG coding to define an Open
Access file and use I/O operations against the file.
2. A handler procedure or program that is called by Open Access to
handle the I/O operations for the file.
3. The data access service program that the handler is using or
communicating with.
 Open Access is the linkage between parts 1 and 2.
 Open Access is part of the RPG compiler
– Runtime PTFs:
• V6R1: SI45906
• V7R1: SI45905
– Compiler PTFs:
• V6R1: SI45904
• V7R1 TGTRLS(*CURRENT): SI45903
• V7R1 TGTRLS(*PRV): SI45902
RPG HANDLER Keyword
New file level keyword HANDLER
no additional syntax related to using an Open Access file.
1 Line
FFILE1 IF E DISK
of code per
F handler('HANDLERPGM')
FFILE2 IF E DISK
file
F handler('HANDLERSVP(Handle_OPNQRYF)')

Handler can be program or service program

/Free
Setll(e) FILE1;
READE(e) FILE1;
CHAIN(e) FILE2; RPG IO operations
Update FILE1; coded as usual
/End-Free
The HANDLER Program

/COPY QOAR/QRPGLESRC,QRNOPENACC
Data structure template provided
DCL-PR Handle_Main ;
rpgIO LIKEDS(QrnOpenAccess_T);
in QOAR.
userArea LIKEDS(userArea_t)
OPTIONS(*NOPASS) ; Data structure passed by IBM I
END-PR ;) to handler program

DCL-PR Prepare_Then_Execute_CALL IND;

DCL-PR Call_Stored_Procedure IND;
DCL-PR Allocate_Cursor ;
DCL-PR Associate_Result_Set_Locator IND
DCL-PR Fetch_From_Allocated_Cursor IND;
Determine SQL function based
DCL-PR Return_Row_From_Host_Array IND; on I/O operation
DCL-PR Close_SQL_Cursor END-PR ;
So What's Stopping You?

 Simply change the HLL read operation to an SQL blocked FETCH

 Nobody wants to touch the program.
 Why???
 Now what? Handlers to
the rescue!

Rdi Visual Application

Diagram 24k line RPG
Module Using
OPNQRYF
Handler’s to the Rescue

• RUNSQL
CL • SET PROCEDURE NAME global variable SET
Pgm • CALL HLL_PROGRAM Global
Variables
HLL • HANDLER keyword assigned to file
Pgm

• OPEN Operation
GET
Hand-
• GET PROCEDURE NAME from global variable Global
• First IO Operation
ler
• CALL SQL Stored Procedure
Variables
• ASSOCIATE/ALLOCATE cursor

SQL • DECLARE CURSOR DB2 for i Table

Stored • OPEN CURSOR WITH RETURN TO CALLER
Proc

• FETCH result set from allocated cursor into host array

Hand- • CLOSE cursor when complete
ler • Return Row from host array to HLL Program Result Set

HLL • Read rows until complete

Pgm
HLL Enhancements: CL RUNSQL command

 RUNSQL CL Command allows executing SQL strings without

requiring a source file
– SQL string is limited to 5000 bytes
– SQL string cannot be used with SELECT statements
– CL program must be ILE to use advanced SQL (e.g. global variables)
 Example of RUNSQL in CL Program
– RUNSQL SQL('SET SCHEMA USER') ;
 Conceptual use of RUNSQL
CALL CLPLE1 () SQLLE2 SP1

• RUNSQL SQL('SET • SET vSQL = CONCAT(‘CALL’, • DECLARE CURSOR

PROC_NAME = PROC_NAME) • OPEN CURSOR WITH
'‘PROC1''') • PREPARE CALL_PROC FROM RETURN TO CALLER
• CALL SQLLE2 (); vSQL
• EXECUTE CALL_PROC

Result
Set
 HLL Enhancements: Open Access

 Open Access provides a unique opportunity for RPG programmers to access SQL
procedures with minimal change to existing programs
– Not available for COBOL
 Opens up RPG‘s file I/O capabilities allowing programmers to code their own
programs (in any host language) to handle RPG operations
 I/O handlers can be used to:
– Transform traditional record at a time I/O operations to SQL set based
operations
– Take advantage of SQL enhancements
 Conceptual use of Open Access

CALL CLPLE () RPGLE HANDLER/SQLLE SP1

•RUNSQL(SET •HANDLER •Provides bridge between RPG and •DECLARE
PROC_NAME = (SQLLE) SQL CURSOR
&PROCNAME) •1 Line of code •SET vSQL = CONCAT(‘CALL’, •OPEN CURSOR
•CALL RPGLE1 change PROC_NAME) WITH RETURN TO
•PREPARE CALL_PROC FROM CALLER
vSQL
•EXECUTE CALL_PROC
•ASSOCIATE/ALLOCATE Cursor
•FETCH/CLOSE

Data Flow Result

Set
RPG Visual Diagram for a Procedure-based Handler
FDDSFILE1 UF E K DISK
F handler(‘PRCHANDLER')

It all starts with

The addition of
one line of code!
Summary

 Now is the time to move to SQL

 New enhancements in SQL development has made Data
Centric Programming very attractive
 RPG Open Access combined with result set consumption
have simplified the process of bridging to SQL
– Only 1 line of code needs to be added to existing RPG program
– COBOL programmers can use these same techniques but will have
to change more lines of code
 Modern development tools and methods have dramatically
improved ease of creating and maintaining SQL
– IBM Data Studio
– Rational Developer for i