SQL CALL statement (stored procedures)

The SQL CALL statement is not actually specific to distributed relational databases, but a discussion of it is included here because its main value is in distributing application logic and processing.

Result sets can be generated in the stored procedure by opening one or more SQL cursors associated with SQL SELECT statements. In addition, a maximum of one array result set can also be returned. For more information about writing stored procedures that return result sets, see the descriptions of the SET RESULT SETS and CREATE PROCEDURE statements in the SQL reference topic.

The CALL statement provides a capability in a DRDA^® environment much like the Remote Procedure Call (RPC) mechanism does in the Open Software Foundation (OSF) Distributed Computing Environment (DCE). In fact, an SQL CALL to a program on a remote relational database actually is a remote procedure call. This type of RPC has certain advantages; for instance, it does not require the compilation of interface definitions, nor does it require the creation of stub programs.

You might want to use SQL CALL, or stored procedures, as the technique is sometimes called, for the following reasons:

To reduce the number of message flows between the application requester (AR) and application server (AS) to perform a given function. If a set of SQL operations are to be run, it is more efficient for a program at the server to contain the statements and interconnecting logic.
To allow native database operations to be performed at the remote location.
To perform nondatabase operations (for example, sending messages or performing data queue operations) using SQL.
Note: Unlike database operations, these operations are not protected by commitment control by the server.
To access server APIs on a remote server.

A stored procedure and application program can run in the same or different activation groups. It is recommended that the stored procedure be compiled with ACTGRP(*CALLER) specified to achieve consistency between the application program at the AR and the stored procedure at the AS. If the stored procedure is designed to return result sets, then you should not create it to run in a *NEW activation group. If you do, the cursors associated with the result sets might be prematurely closed when the procedure returns to the caller and the activation group is destroyed.

When a stored procedure is called that issues an inquiry message, the message is sent to the QSYSOPR message queue. The stored procedure waits for a response to the inquiry message. To have the stored procedure respond to the inquiry message, use the Add Reply List Entry (ADDRPYLE) command and specify *SYSRPYL on the INQMSGRPY parameter of the Change Job (CHGJOB) command in the stored procedure.

When a stored procedure and an application program run under different commitment definitions, the COMMIT and ROLLBACK statements in the application program only affect its own commitment definition. You must commit the changes in the stored procedure by other means.