1

Abstract:

Native SQL procedures were introduced with DB2 9 for z/OS, and SQL

Procedure Language (SQL PL) was extended to UDFs with DB2 10. DB2 11

has delivered additional SQL PL-related enhancements. This session will

provide information that attendees can use in the development,

management, and monitoring of native SQL procedures and UDFs. It will

also cover exploitation of native SQL procedures and UDFs to enhance DB2

for z/OS performance, scalability, and security - particularly for client-server

applications.

Robert Catterall

IBM

rfcatter@us.ibm.com

2

For years, COBOL ruled the roost with respect to the coding of DB2 for z/OS

stored procedures. SQL PL, more recently on the scene, will, I think, come

to be the dominant language for DB2 stored procedure development (and

for development of user-defined functions). I believe that DB2 for z/OS

people – systems programmers, DBAs, and application developers – should

have at least some knowledge of SQL PL, and DB2-using organizations

should engage in at least some degree of SQL PL routine development.

I’ll start by providing some information about the history of DB2 for z/OS native

SQL procedures (and UDFs), and some recently delivered enhancements in

this area. Then I’ll talk about the benefits of native SQL procedures and UDFs

with respect to application performance, scalability, and security. After that I’ll

discuss topics related to native SQL procedure and UDF development and

management. I’ll conclude with some thoughts on shifting to SQL PL from

other languages for DB2 stored procedure and UDF development.

3

A brief SQL PL history lesson, and a look at what’s new.

4

It was DB2 for z/OS Version 7 that introduced the ability to write stored

procedure programs using only SQL statements (in other words, the stored

procedure’s source is contained entirely within the associated CREATE

PROCEDURE statement).

The enriched SQL that enabled creation of SQL-only stored procedure source

is called SQL Procedure Language, or SQL PL for short. To the existing SQL

DML (e.g., SELECT, INSERT), DCL (GRANT and REVOKE), and DDL

statements (CREATE, ALTER), SQL PL added what are called control

statements. These statements are about variable declaration, assignment of

values to variables, and logic flow control (via statements such as IF, WHILE,

ITERATE, LOOP, and GOTO).

5

What did organizations like about SQL PL as introduced with DB2 for z/OS

V7? Mostly they liked that the language expanded the pool of people who

could develop DB2 stored procedures – people who didn’t know a

programming language such as COBOL or C or Java could write DB2 stored

procedures using SQL PL.

What did organizations not like about first-generation SQL PL routines? Some

organizations didn’t like the fact that the routines were turned into C language

programs with embedded SQL DML statements as part of preparation for

execution. These programs ran – like other external-to-DB2 stored procedure

programs – in WLM-managed stored procedure address spaces. The concern

in some people’s mind had to do with the CPU consumption of a C language

stored procedure program, which often was a good bit greater than the CPU

cost of executing a COBOL stored procedure program of equivalent

functionality. Certain organizations opted not to use DB2 V7-style SQL

procedures because the negative of added CPU cost (versus COBOL stored

procedures) outweighed the benefit of an expanded pool of people who could

develop DB2 stored procedures.

6

A very important enhancement was introduced with DB2 9 for z/OS running in

new-function mode: native SQL procedures (organizations that migrated to

DB2 10 from DB2 V8 can utilize native SQL procedure functionality in a DB2

10 NFM environment)). Unlike DB2 V7 or V8 SQL procedures (still supported

in DB2 9, 10, and 11 systems, and now called external SQL procedures), DB2

9 (and beyond) native SQL procedures are internal procedures – they run in

the DB2 DBM1 address space, as opposed to a WLM-managed stored

procedure address space. Other differences versus external SQL procedures:

• A native SQL procedure’s sole executable is its DB2 package – there’s

nothing else to it.

• A native SQL procedure executes under the task of the invoking application

process – not under its own TCB in a stored procedure address space.

• A native SQL procedure provides some capabilities not available for external

SQL procedures, such as nested compound SQL statements (very handy for

implementation of multi-statement condition handlers).

• That functionality gap versus external SQL procedures continues to grow.

DB2 11 delivered some important enhancements that are only applicable to

native SQL PL routines (I’ll cover these enhancements momentarily).

7

DB2 10 for z/OS (in new-function mode) expanded the usefulness of native

SQL PL routines to user-defined functions (UDFs). I like to call these routines

“native” SQL UDFs, but the official term is “compiled SQL scalar functions.”

As is true of SQL procedures, “native” SQL UDFs expand the pool of people

who can develop user-defined functions in a DB2 environment. Could UDFs be

written in SQL before DB2 10 NFM? Yes, but they were very limited in

functionality (more on this to come).

8

Prior to DB2 10 (NFM), if you wanted to create a user-defined function that

had some degree of sophistication, including declaration of variables and

assignment of values to same, and logic such as “do loops,” you pretty much

had to go with an external UDF that would be associated with a program

written in COBOL (for example). With DB2 10 NFM (and beyond), that type of

sophistication can be achieved with a compiled SQL scalar function written in

SQL PL. As with a native SQL procedure, the “body” of a “native” SQL UDF is

contained within what’s called a compound statement. Other things that

“native” SQL UDFs have in common with native SQL procedures:

• They run in the DB2 DBM1 address space.

• They run under the task of the invoking application process.

• The one and only executable is the “native” SQL UDF’s package – nothing

about a “native” SQL UDF is external to DB2.

9

The ability to have a SQL PL routine as the body of a “native” SQL UDF is not

the only DB2 10 enhancement related to SQL UDFs. Other goodies:

• The RETURN statement in a compiled SQL scalar UDF (also called a non-

inline SQL scalar UDF) can contain a scalar fullselect. Prior to DB2 10 NFM,

not only could a SQL scalar UDF not contain a scalar fullselect – it couldn’t

even reference a column of a table.

• A table UDF, which returns a set of values, can be written in SQL in a DB2 10

NFM (and beyond) system (previously, a table UDF had to be external, i.e.,

associated with an external-to-DB2 program written in a language such as

COBOL).

Note that DB2 10, in addition to having new CREATE (and ALTER) statements

for compiled SQL scalar UDFs and SQL table UDFs, still supports the pre-DB2

10 type of SQL scalar UDF (now called an inline SQL scalar UDF).

10

I had stated previously that one benefit of native SQL procedures versus

external SQL procedures is the fact that new capabilities are, by and large,

delivered for the former and not for the latter. An example of such a new

capability is the XML support provided for native SQL procedures (and not

external SQL procedures) starting with DB2 10 in new-function mode:

• Input and output parameters for a native SQL procedure can be of the XML

data type (prior to DB2 10 NFM, XML data had to be passed to or received

from a native SQL procedure in character string form). Native SQL procedures

can also declare variables of the XML data type.

• The same holds true for SQL UDFs (whether scalar – inline or compiled – or

table UDFs).

11

DB2 11 provides a couple of very cool native SQL procedure-only

enhancements. One of those is support for array parameters: they can be

passed to or received from a native SQL procedure, or declared as variables in

a native SQL procedure (and the same is true for a compiled SQL scalar

UDF). An important caveat: when array parameters are used for a native SQL

procedure, the procedure has to be called from another SQL PL routine or

from a Java program that connects to DB2 using the IBM Data Server Driver

for JDBC and SQLJ type 4 driver (I underlined that Java bit because Java

client-side programmers have long wanted DB2 stored procedure support for

array parameters).

Note that one first creates an array (it’s a category of user-defined data type)

and then uses it with a native SQL procedure (or UDF). You can create

ordinary arrays, in which a value in the array is identified by its ordinal position

within the array (e.g., element 1, or 12, or 27), and associative arrays, in which

values are ordered by, and can be referenced by, user-provided index values.

The example on the slide shows a CREATE statement for an ordinary array.

DB2 11 also provides several new built-in functions that facilitate working with

arrays.

12

Another new and cool DB2 11 feature that is exclusive to native SQL

procedures is the autonomous transaction. Here’s what this is about: suppose

you want an application transaction to make a data change (e.g., insert a row

into a DB2 table) that will persist even if the transaction itself is subsequently

rolled back (perhaps due to a SQL error encountered by the transaction)? An

autonomous transaction, which is a special form of a native SQL procedure,

will do that for you, because it has a unit of work that is completely

independent of the unit of work associated with the transaction that called the

procedure.

One interesting implication of that independent-unit-of-work thing: a DB2 lock

acquired by the transaction that calls a SQL procedure functioning as an

autonomous transaction will not automatically be “inherited” by the

autonomous transaction, and vice versa; thus, an autonomous transaction

could conceivably deadlock with its invoking transaction.

13

Next I’ll cover some things that I like about native SQL procedures and UDFs

from a performance perspective.

14

There are two main misconceptions that I’ve frequently encountered in the

area of native SQL procedures and zIIP offload:

Misconception 1: native SQL procedures are always zIIP-eligible when

they execute. NOT TRUE. A native SQL procedure is zIIP-eligible only when it

is called by a DRDA requester. Here’s why: a native SQL procedure, unlike an

external stored procedure, runs under the task of its caller (an external stored

procedure always runs under its own task – a TCB – in a WLM-managed

stored procedure address space). When the caller is a DRDA requester, the

task in the z/OS system is an enclave SRB in the DB2 DDF address space,

and that makes the native SQL procedure zIIP-eligible. If a native SQL

procedure is called from (for example) a CICS transaction, it will run under that

transaction’s TCB and will therefore not be zIIP-eligible.

Misconception 2: using native SQL procedures in a DDF application

environment will always increase zIIP offload. NOT TRUE. zIIP offload will

be increased if native SQL procedures replace external stored procedures for

a DDF-connected application. If you just take SQL DML statements issued by

a client-side program and package them in native SQL procedures, zIIP

offload should not be significantly affected because the client-issued SQL DML

statements would themselves be zIIP-eligible (because they would execute

under the DDF enclave SRB associated with the DRDA requester).

15

I’ve mentioned that a native SQL procedure will execute under the task of its

caller, while an external DB2 stored procedure will execute under its own TCB

in a WLM-managed stored procedure address space. Besides affecting zIIP

eligibility (see preceding slide), this characteristic of native SQL procedures

provides another benefit: there is no need to switch the caller’s DB2 thread to

the stored procedure’s task, because the task of a native SQL procedure and

the task of its caller are one in the same. This benefit is seen as well for SQL

UDFs versus external UDFs, and you could really see the associated

performance impact in a situation in which a UDF is invoked MANY times in

the execution of a single SQL statement. Consider a UDF that appears in the

SELECT of a correlated subquery that is driven once for each of the

thousands of rows qualified by an outer SELECT. An organization with which

I’ve worked had exactly that situation. The query in question was running a lot

longer than desired, and monitor data showed a lot of “UDF TCB wait” time.

The UDF happened to be external. When it was converted to a SQL UDF, the

query ran much faster than before. That can happen when thousands of task-

to-task DB2 thread switches are eliminated.

16

DB2 10 provides some performance benefits for SQL PL routines. One is that

a SQL PL routine’s package (and recall that this is the sole executable with

respect to a native SQL procedure or a compiled SQL scalar UDF) is more

CPU-efficient when it is regenerated in a DB2 10 system (more in a moment

on the two ways in which a SQL PL routine’s package can be regenerated).

That improved CPU efficiency is due to factors like a reduced path length for

execution of IF statements (very commonly found in SQL PL routines), and

reduced CPU consumption in the execution of SET statements that reference

built-in functions such as CHAR (SET statements are used in native SQL

procedures to assign values to variables and to output parameters).

If you make a few code changes you can realize still more CPU savings for a

native SQL procedure in a DB2 10 NFM (and beyond) system. Starting with

DB2 10, one SET statement can be used to assign values to multiple variables

and/or parameters of a native SQL procedure. Do that to reduce the number of

SET statement executions, and you’ll get some reduction in CPU consumption

associated with execution of the SQL procedure.

17

A DB2 package is executable code – basically, the compiled form of a

program’s SQL statements. In the case of a native SQL procedure or a

compiled SQL scalar UDF, the ONLY statements in the program are SQL

statements, so the SQL PL routine’s package is the run-time form of the

routine. There are two ways to regenerate this run-time form of a native SQL

procedure or compiled SQL scalar UDF:

• REBIND PACKAGE will regenerate the part of the SQL PL routine’s package

pertaining to non-control statements (e.g., data manipulation statements such

as SELECT).

• ALTER PROCEDURE (or ALTER FUNCTION) with the REGENERATE

option will regenerate ALL of a SQL PL routine’s package – the control section

and the non-control section.

Because IF and SET are control statements, getting the benefit of the

improved CPU efficiency with which these statements are executed in a DB2

10 (and beyond) system (see preceding slide) requires an ALTER

PROCEDURE (or FUNCTION) with REGENERATE – a rebind of the SQL PL

routine’s package will not regenerate the compiled form of control statements

in the routine. ALTER PROCEDURE (or FUNCTION) with REGENERATE is

also required if you want most of the control section of a SQL PL routine’s

package to be stored above the 2 GB bar in the DB2 DBM1 address space

when the routine is executed.

18

Given that ALTER PROCEDURE (or FUNCTION) with REGENERATE reworks

all sections of a SQL PL routine’s package, you might think, “Hey, I ought to

always go with that versus REBIND PACKAGE for a SQL PL routine.” Not so

fast, pardner. Think about SQL DML statement access path changes that can

occur as a result of an ALTER with REGENERATE or a REBIND. Those

changes (especially when you’re talking about taking advantage of optimizer

enhancements provided with a new release of DB2) are often positive from a

performance perspective, but sometimes they aren’t. In the case of REBIND, if

access path-related performance regression is a concern, you can tell DB2 to

reuse current access paths (if possible) for SQL DML statements in a SQL PL

routine via the APREUSE option – something you can’t specify for an ALTER

with REGENERATE; furthermore, plan management functionality, which

enables quick restoration of a previous instance of a package (and its access

paths) via REBIND SWITCH, does not apply to ALTER with REGENERATE.

This being so, you probably want to go with REBIND PACKAGE when there is

not a desire to rework the control section of a SQL PL routine’s package (e.g.,

when you want a query in the routine to use a newly created index). If you

want to do a REGENERATE, try a REBIND PACKAGE first, and check to see

if access paths changed. If they didn’t (or if they did and with positive

performance results), do an ALTER with REGENERATE – chances are that

access paths will be as they were for the just-done REBIND.

19

On this and the next slide, I describe actions that can be taken to improve

performance for both native SQL procedures and external stored procedures.

RELEASE(DEALLOCATE) can be a good package bind choice for stored

procedures that are frequently executed, especially when these stored

procedures have relatively low in-DB2 CPU time. When callers are DRDA

requesters, packages bound with RELEASE(DEALLOCATE) cause DBATs

(database access threads – the kind associated with DDF transactions) to

become high-performance DBATs. Related CPU savings can be 10% or more

(referring to the reduction in in-DB2 CPU time that can be so achieved).

RELEASE(DEALLOCATE), combined with persistent threads (i.e., threads that

persist through commits, such as high-performance DBATs), can, in a pre-DB2

11 environment, interfere with the successful completion of some bind, rebind,

DDL, and utility operations (especially an online REORG executed to

materialize a pending DDL operation). DB2 10 provides relief in this area for

DDF transactions via the command -MODIFY DDF PKGREL(COMMIT). DB2

11 provides general relief for this contention situation.

The DB2 10-introduced RETURN TO CLIENT cursor declaration can save

CPU when the result set of a cursor declared in a “nested” stored procedure is

to be retrieved by the program that initiated the set of nested procedure calls.

20

Any program that can issue a SQL statement can call a DB2 for z/OS stored

procedure, but the real “sweet spot” for stored procedure utilization is with

DDF-connected applications. For one thing, stored procedures can reduce the

network “chattiness” of transactions that involve issuance of multiple SQL DML

statements. Stored procedures also provide a means of utilizing static SQL for

a DDF application (static SQL generally delivers optimal CPU efficiency in a

DB2 system), while allowing client-side programmers to use their database

access interface of choice; so, client-side programmers can invoke DB2 stored

procedures, which issue static SQL statements, by way of JDBC or ODBC

calls (JDBC and ODBC calls are processed as dynamic SQL on the DB2

server side of the application).

Packaging “table-touching” SQL in DB2 stored procedures can also benefit

performance by loosening the coupling between client-side programs and a

data server (versus the situation in which “table-touching” SQL is issued from

client-side programs). When data access is accomplished via stored

procedures, the DB2 DBA team can make database design changes that are

aimed at improving application performance, and only affected stored

procedures will have to be modified accordingly – client-side changes will not

be required, because programs at that end of the application will continue to

call stored procedures as before.

21

Next, information about some stored procedure characteristics that can

enhance an application’s scalability and security.

22

Most of what I’ll be talking about in this section of the presentation applies to

both external and native SQL procedures. That said, keep in mind two key

advantages of native SQL procedures over external stored procedures: 1)

native SQL procedures can be written by people who aren’t COBOL or C or

Java programmers, and 2) in a DDF application environment, native SQL

procedures greatly increase zIIP offload versus external stored procedures.

23

I’ve already mentioned, briefly, the beneficial impact that stored procedures

can have for network-attached DB2 applications, by reducing the “chattiness”

factor – if a DDF transaction is to drive issuance of, say, 10 SQL DML

statements, packaging those 10 SQL DML statements in a stored procedure

that is called by the transaction can lower SQL-related network transmissions

by an order of magnitude.

24

Have you ever thought of WebSphere MQ as being part of a scalability

solution for a DB2-accessing client-server application? Perhaps you should.

Think about it – if database changes are always accomplished in a

synchronous fashion with respect to end-users hitting ”submit” on browser-

presented screens, your organization will have to provide server-side

processing capacity with workload peaks in mind. If, on the other hand, you

put a queue between end users and the back-end database, processing peaks

can be smoothed out: when a surge of work comes in, the queue depth just

increases temporarily. When application traffic subsides, queue depth is

worked back down.

The DB2 MQListener, provided with DB2 for z/OS, can be used to facilitate

implementation of queue-based application interaction with DB2: data

submitted by a user is placed on a queue in the form of a message, and the

arrival of the message on the queue causes the MQListener to automatically

invoke the DB2 stored procedure associated with the queue (the data in the

message is the input to the DB2 stored procedure).

The queue-based approach also improves application resiliency: if the back-

end database (or just a particular table therein) becomes temporarily

unavailable for some reason, transactions don’t fail. Instead, input messages

build up on a queue, and they are processed as soon as the database (or the

target table) is again available.

25

Stored procedures typically issue static SQL statements, and static SQL, in

addition to being (as previously noted) an application performance booster,

can also enhance security for DDF-attached programs (and, these static SQL

statements packaged in DB2 stored procedures can be dynamically invoked

by client programs). If SQL DML statements are issued from client-side

programs by way of an interface (e.g., ODBC or JDBC) that drives execution

of dynamic SQL statements at the DB2 server, successful execution of these

statements will require the DB2 authorization ID of the application process to

have requisite table access privileges (i.e., SELECT, INSERT, UPDATE,

DELETE). On the other hand, if the “table-touching” SQL statements are

packaged in DB2 stored procedures (which can be invoked via calls issued

through interfaces such as ODBC and JDBC), the authorization ID of the

calling application process will require only the EXECUTE privilege on the

stored procedures that are called.

Want to tighten data security further? Grant the DB2 privileges needed by the

application to a DB2 role versus an ID, and create a DB2 trusted context that

limits the use of the role’s privileges to an application that connects to DB2

using a particular ID and which runs on a particular application server (or

servers), identified by IP address.

26

If someone wants to hack into your DB2 database, he (or she) will have an

easier time of it if he knows the names of tables and columns in the database.

When “table-touching” SQL statements are issued from client-side programs,

developers of those programs know the names of tables and columns, some

of which might contain highly sensitive information. When the “table-touching”

SQL statements are packaged in DB2 stored procedures, client-side

programmers do not require knowledge of database table and column names.

Yes, stored procedure developers will know this information, but it’s likely that

the number of people writing DB2 stored procedures will be smaller than the

number of people writing client-side programs; thus, use of stored procedures

can reduce the number of people who require knowledge of table and column

names in the database, and that can reduce the risk of unauthorized data

access attempts.

27

Now, some information about native SQL procedure and SQL UDF

development and management.

28

IBM Data Studio, a free and downloadable software product, is a great tool for

developing, debugging, and deploying SQL PL routines. It’s Eclipse-based with

a GUI, and it runs under Windows or Linux. The stored procedure debug view

of Data Studio has a lot of features that facilitate testing a SQL PL routine for

errors.

In addition to useful SQL PL routine debugging capabilities, Data Studio can

be a much better choice than SPUFI for executing certain SQL statements

interactively. In particular, I’ve had much more success in executing queries

that access XML data and queries that access LOB data, and issuing stored

procedure calls, from Data Studio versus SPUFI. With regard to XML data,

Data Studio’s formatting of retrieved XML data is a nice bonus.

29

Lots of organizations use various tools to manage source code for applications

developed in-house. These tools are great when the programming language

used is something like Java or C# or COBOL. But what if the source code is

SQL PL, as it is when you’re talking about DB2 native SQL procedures and

SQL UDFs? It seems to me that a number of the popular source code

management tools on the market do not yet offer support for SQL PL. What

are your options?

Some folks are going with a “roll your own” approach to SQL PL source code

management. To help out with such an approach, IBM provided some sample

REXX routines via the fix for APAR PM29226. Use of these routines is

illustrated via DB2 sample job DSNTEJ67. The routines provide a number of

services that can facilitate management of source code for SQL PL routines,

including:

• Extraction of the source for a SQL PL routine from the DB2 catalog (the

retrieved source can be placed in a file or in a long string – you’d go with the

option that best suits your needs).

• Invocation of the SQL PL precompiler to generate a listing for a routine.

• Modification of various elements of a SQL PL routine (schema, version ID,

etc.).

• Deployment of a SQL PL roitine.

30

Here’s another option for managing SQL PL source code: use the open-source

Apache Subversion software versioning and revision control system with Data

Studio.

How does that work? Well, as I mentioned previously, Data Studio is an

Eclipse-based tool. Subversion (or SVN, for short) integrates with Eclipse.

SQL PL routines developed using Data Studio are resources in Eclipse-speak,

and these resources can be managed by a plug-in that provides the “Team”

component for an Eclipse framework. Subversion is such a plug-in.

31

Before your organization plunges into native SQL procedure development, you

should understand how deployment of such procedures differs versus external

stored procedures. The deployment difference is mainly due to the fact that a

native SQL procedure’s package is its sole executable – there is not the

external-to-DB2 load module that you have with an external stored procedure.

To get a native SQL procedure moved from a test system to a production

system, you can execute a BIND PACKAGE command for the procedure’s

package, with the DEPLOY option specified. What this does: it regenerates the

non-control section of the native SQL procedure’s package, including

optimization (access path selection) for the SQL DML statements in the

routine. This is what you want for those SQL DML statements, because

catalog statistics and other factors are probably different in the production

environment versus test. The control section of the package can be left alone

because the logic of the native SQL procedure is set.

ALTER PROCEDURE (or FUNCTION) with the ACTIVATE VERSION clause is

also something new when you get into the world of native SQL procedures and

UDFs – it allows you to (for example) move a new version of a native SQL

procedure (or compiled SQL scalar UDF) into production and have only a few

people test it out before making it the active version of the routine on the

system (testers can invoke the new routine before it’s active for general use

via the CURRENT ROUTINE VERSION special register).

32

So, how do you make changes to a native SQL procedure? One approach is

drop and re-create, and I’ve seen that approach used, particularly when an

organization is first getting into native SQL procedure development and

deployment. When native SQL procedure usage by a company ramps up, and

situations involving nested stored procedure calls (in which a native SQL

procedure calls another stored procedure) become more common, the drop-

and-re-create method of affecting stored procedure changes can become

problematic. Why? Because an attempt to drop a stored procedure that is

called by a native SQL procedure will fail (the SYSPACKDEP catalog table

records these dependencies). To drop that called stored procedure, you’d first

have to drop the native SQL procedure that calls it. What if several native SQL

procedures call the stored procedure you want to drop and re-create? What if

a native SQL procedure that calls the stored procedure that you want to drop

and re-create is itself called by a native SQL procedure? You can see how

your one planned stored procedure drop and re-create could turn into quite a

few drop and re-create actions.

The moral of this story: when you need to make a change to an existing stored

procedure, use ALTER PROCEDURE to accomplish the change. Go with drop

and re-create if ALTER PROCEDURE, for some reason, won’t do what you

need done.

33

Last section! I’ll close with some thoughts on making the shift to SQL PL as a

development language for native SQL procedures and compiled SQL scalar

UDFs.

34

As you’ve probably gathered, I’m very big on native SQL procedures; however,

even as a big fan of native SQL procedures I’m not going to tell you to take all

your external stored procedures (if you have any) and change them en masse

to native SQL procedures. For one thing, that change requires complete

rewrite if an existing external stored procedure is written in a language other

than SQL PL (like COBOL). Even if you have external SQL procedures that

were written in SQL PL, converting those to native SQL procedures can

involve more than a mere drop and re-create (I included on the slide the URL

of an IBM “technote” that contains very useful information on converting

external SQL procedures to native SQL procedures). On top of that, an

external stored procedure written in, say, COBOL, might access non-DB2 data

(such a stored procedure might access VSAM data, either directly or by way of

a CICS transaction invoked by the stored procedure), and it wouldn’t make

much sense to try to get a native SQL procedure into that picture.

So, what should you do if you have existing SQL procedures and you want to

convert some of those to native SQL procedures? Go first for the “low-hanging

fruit:” external procedures that are relatively simple (reduces conversion

effort), that access DB2 data, that are frequently executed, and that are called

primarily by DRDA requesters. Converting those to native SQL procedures

should give you a nice return on your conversion effort, particularly in terms of

increased zIIP offload.

35

So, your organization is ready to develop and deploy native SQL procedures

and UDFs. Question: who’s going to write those SQL PL routines? Will it DB2

DB2 for z/OS DBAs? They know SQL, but their numbers can be fairly small,

even at a site with a big DB2 for z/OS workload. Plus, they are typically pretty

busy with managing and administering the DB2 environment. How about

application developers? Often you’ll find lots of those folks in an organization’s

IT department. Problem there is that these people may have a bit of a learning

curve with respect to mastering SQL PL. And there are plenty of CREATE and

ALTER PROCEDURE (and FUNCTION) statement options and keywords that

application developers could find to be less than straightforward.

What if the task of writing SQL PL routines were to be assigned to people who

are not DBAs (in the traditional sense) and not application developers (in the

traditional sense), but who have a role that combines aspects of DBA and

application development work? On to the next slide…

36

I’ll close with some information about an approach to SQL PL routine

development that I encountered at a DB2 for z/OS site. It’s an approach that I

like a lot. The organization in question decided to create a new position that

they labeled, “procedural DBA.” The idea was to form a new team that would

be database-centric in terms of their focus, but with an emphasis on

development and management of DB2 routines (stored procedures and user-

defined functions). The new positions were advertised internally, and a mix of

people applied – some who had worked as traditional DBAs and wanted to be

more involved with application development, and some who’d worked as

traditional application programmers and wanted to work more closely the

enterprise data server. All of the newly minted “procedural DBAs” that I met

during a visit seemed to be pretty excited about their assignment. For them,

the new role presented a fresh and challenging (in a good way) area of work.

A team of SQL PL people, whatever you might call them, could work effectively

in support of both DB2 for z/OS and DB2 for LUW systems, because SQL PL

on the two platforms is virtually identical. That kind of cross-platform DB2 work

would deliver yet more value to an organization. Something to think about.

37

38

Thanks for attending the session!