friedkiwi/ibm-information-center
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0332907f0f
ibm-information-center/dist/eclipse/plugins/i5OS.ic.db2_5.4.0.1/rbafzmstcallsta.htm

479 lines
28 KiB
HTML
Raw Blame History

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="dc.language" scheme="rfc1766" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<meta name="dc.date" scheme="iso8601" content="2005-09-19" />
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow"/>
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="keywords" content="CALL, SQL statements, CALL statement, procedures,
external, calling, in CALL statement, procedure-name, variable, constant,
NULL clause, special register, in INSERT statement, DLVALUE function,
ALTER TABLE statement, cast-function, INTO keyword, SQL-descriptor-name,
USING DESCRIPTOR clause, descriptor-name" />
<title>CALL</title>
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
<link rel="stylesheet" type="text/css" href="ic.css" />
</head>
<body>
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
<a name="callsta"></a>
<h2 id="callsta"><a href="rbafzmst02.htm#ToC_793">CALL</a></h2><a id="idx1492" name="idx1492"></a><a id="idx1493" name="idx1493"></a><a id="idx1494" name="idx1494"></a>
<p>The CALL statement calls a procedure.</p>
<a name="wq1125"></a>
<h3 id="wq1125"><a href="rbafzmst02.htm#ToC_794">Invocation</a></h3>
<p>This statement can be embedded in an application program or issued interactively.
It is an executable statement that can be dynamically prepared.</p>
<a name="wq1126"></a>
<h3 id="wq1126"><a href="rbafzmst02.htm#ToC_795">Authorization</a></h3>
<p>The privileges held by the authorization ID of the statement must include
at least one of the following: </p>
<ul>
<li>If the procedure is an SQL procedure:
<ul>
<li>The EXECUTE privilege on the procedure, and</li>
<li>The system authority *EXECUTE on the library containing the SQL procedure</li></ul></li>
<li>If the procedure is a Java&trade; external procedure:
<ul>
<li>Read authority (*R) to the integrated file system file that contains the Java class.</li>
<li>Read and execute authority (*RX) to all directories that must be accessed
in order to find the integrated file system file.</li></ul></li>
<li>If the procedure is a REXX external procedure:
<ul>
<li>The system authorities *OBJOPR, *READ, and *EXECUTE on the source file
associated with the procedure,</li>
<li>The system authority *EXECUTE on the library containing the source file,
and</li>
<li>The system authority *USE to the CL command,</li></ul></li>
<li>If the procedure is an external procedure, but not a REXX or Java external
procedure:
<ul>
<li>The system authority *EXECUTE on the program or service program associated
with the procedure, and</li>
<li>The system authority *EXECUTE on the library containing the program or
service program associated with the procedure</li></ul></li>
<li>Administrative authority</li></ul>
<p>For information on the system authorities corresponding to SQL privileges,
see <a href="rbafzmstgntprc.htm#eqtabler">Corresponding System Authorities When Checking Privileges to a Function or Procedure</a>.</p>
<a name="wq1127"></a>
<h3 id="wq1127"><a href="rbafzmst02.htm#ToC_796">Syntax</a></h3>
<a href="rbafzmstcallsta.htm#synscall"><img src="c.gif" alt="Click to skip syntax diagram" /></a>
<pre class="cgraphic"><span><img src="c.gif" alt="Read syntax diagram" longdesc="rbafzmstsyn260.htm"
border="0" /></span><a href="#skipsyn-259"><img src="c.gif" alt="Skip visual syntax diagram"
border="0" /></a>>>-CALL--+-<span class="italic">procedure-name</span>-+------------------------------------->
'-<span><span class="italic">variable</span></span>-------'
>--+----------------------------------------------------------+->&lt;
+-(--+------------------------------------------------+--)-+
| | .-,------------------------------------------. | |
| | V | | |
| '---+-<span><span class="italic">variable</span></span>-------------------------------+-+-' |
| +-<span class="italic">constant</span>-------------------------------+ |
| +-NULL-----------------------------------+ |
| +-<span class="italic">special-register</span>-----------------------+ |
| +-DLVALUE--(--<span class="italic">arguments</span>--)---------------+ |
| '-<span class="italic">cast-function-name</span>--(--+-<span><span class="italic">variable</span></span>-+--)-' |
| '-<span class="italic">constant</span>-' |
+-<span class="italic">SQL-descriptors</span>------------------------------------------+
'-USING DESCRIPTOR--<span class="italic">descriptor-name</span>------------------------'
SQL-descriptors:
|--+------------------------------------------------------------+-->
| .-SQL-. .-LOCAL--. |
'-INTO--+-----+--DESCRIPTOR--+--------+--<span class="italic">SQL-descriptor-name</span>-'
'-GLOBAL-'
>--+------------------------------------------------------------------+--|
| (1) |
| .-SQL------. .-LOCAL--. |
'-USING--+----------+--DESCRIPTOR--+--------+--<span class="italic">SQL-descriptor-name</span>-'
'-GLOBAL-'
</pre>
<a name="skipsyn-259" id="skipsyn-259"></a>
<a name="wq1128"></a>
<div class="notelisttitle" id="wq1128">Notes:</div>
<ol type="1">
<li>If an SQL descriptor is specified in the USING clause and the INTO
clause is not specified, USING DESCRIPTOR is not allowed and USING SQL DESCRIPTOR
must be specified.</li>
</ol>
<a name="synscall"></a>
<h3 id="synscall"><a href="rbafzmst02.htm#ToC_797">Description</a></h3>
<dl class="parml">
<dt class="bold"><var class="pv">procedure-name</var> or <var class="pv">variable</var> </dt><a id="idx1495" name="idx1495"></a><a id="idx1496" name="idx1496"></a>
<dd>Identifies the procedure to call by the specified <var class="pv">procedure-name</var> or the procedure name contained in the <var class="pv">variable</var>.
The identified procedure must exist at the current server.
<p>If a <var class="pv">variable</var> is specified: </p>
<ul>
<li>It must be a character-string variable or UTF-16 or UCS-2 graphic-string.</li>
<li>It must not include an indicator variable.</li>
<li>The procedure name that is contained within the variable must be left-justified
and must be padded on the right with blanks if its length is less than that
of the variable.</li>
<li>The name of the procedure must be in uppercase unless it is a delimited
name.</li></ul>
<p>If the procedure name is unqualified, it is implicitly qualified
based on the path and number of parameters. For more information see&nbsp; <a href="rbafzmstch2nam.htm#qualun">Qualification of unqualified object names</a>.</p>
<p>If the procedure-name identifies a procedure that was
defined by a DECLARE PROCEDURE statement, and the current server is a DB2 UDB for iSeries server,
then: </p>
<ul>
<li>The DECLARE PROCEDURE statement determines the name of the external program,
language, and calling convention.</li>
<li>The attributes of the parameters of the procedure are defined by the DECLARE
PROCEDURE statement.</li></ul><p class="indatacontent"> Otherwise: </p>
<ul>
<li>The current server determines the name of the external program, language,
and calling convention.</li></ul><p class="indatacontent"> </p>
<ul>
<li>If the current server is DB2 UDB for iSeries:
<ul>
<li>The external program name is assumed to be the same as the external procedure
name.</li>
<li>If the program attribute information associated with the program identifies
a recognizable language, then that language is used. Otherwise, the language
is assumed to be C.</li>
<li>The calling convention is assumed to be GENERAL.</li></ul></li></ul>
<ul>
<li>The application requester assumes all parameters that are variables or
parameter markers are INOUT. All parameters that are not variables are assumed
to be IN.</li>
<li>The actual attributes of the parameters are determined by the current
server.
<p>If the current server is a DB2 UDB for iSeries, the attributes of the parameters
will be the same as the attributes of the arguments specified on the CALL
statement. <sup class="fn"><a id="wq1130" name="wq1130" href="rbafzmstcallsta.htm#wq1131">59</a></sup></p></li></ul>
</dd>
<dt class="bold"><var class="pv">variable</var> <span class="base">or</span> <var class="pv">constant</var> <span class="base">or</span> NULL <span class="base">or</span> <var class="pv">special-register</var> </dt><a id="idx1497" name="idx1497"></a><a id="idx1498" name="idx1498"></a><a id="idx1499" name="idx1499"></a><a id="idx1500" name="idx1500"></a>
<dd>Identifies a list of values to be passed as parameters to the procedure.
The <tt class="xph">n</tt>th value corresponds to the <tt class="xph">n</tt>th parameter in the
procedure.
<p>Each parameter defined (using a CREATE PROCEDURE or DECLARE
PROCEDURE statement) as OUT or INOUT must be specified as a variable.</p>
<p>The number of arguments specified must be the same as the number of parameters
of a procedure defined at the current server with the specified <span class="italic">procedure-name</span>.</p>
<p>The application requester assumes all parameters
that are variables are INOUT parameters except for Java, where it is assumed all parameters
that are variables are IN unless the mode is explicitly specified in the
variable reference. All parameters that are not variables are assumed to be
input parameters. The actual attributes of the parameters are determined by
the current server.</p>
<p>For an explanation of <span class="italic">constant</span> and <span class="italic">variable</span>, see <a href="rbafzmstch2cons.htm#ch2cons">Constants</a> and <a href="rbafzmstch2refvar.htm#ch2host">References to host variables</a>. For a description of <span class="italic">special-register</span>, see <a href="rbafzmstspecreg.htm#specreg">Special registers</a>. NULL specifies the null value.</p>
</dd>
<dt class="bold">DLVALUE(<var class="pv">arguments</var>)</dt><a id="idx1501" name="idx1501"></a>
<dd>Specifies the value for the parameter is the value resulting from a
DLVALUE scalar function. A DLVALUE scalar function can only be specified for
a DataLink parameter. The DLVALUE function requires a link value on insert
(scheme, server, and path/file). The first argument of DLVALUE must be a constant,
variable, or a typed parameter marker (CAST(? AS data-type)). The second and
third arguments of DLVALUE must be constants or <span class="italic">variables</span>.
</dd>
<dt class="bold"><span class="bold"><var class="pv">cast-function-name</var></span> </dt><a id="idx1502" name="idx1502"></a>
<dd>This form of an argument can only be used with parameters defined as
a distinct type, BLOB, CLOB, DBCLOB, DATE, TIME or TIMESTAMP data types. The
following table describes the allowed uses of these <var class="pv">cast-functions</var>.
<a name="wq1132"></a>
<table id="wq1132" width="100%" summary="" border="1" frame="border" rules="none">
<thead valign="bottom">
<tr>
<th id="wq1133" width="47%" align="left" valign="top">Parameter Type</th>
<th id="wq1134" width="52%" align="left" valign="top">Cast Function Name</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top" headers="wq1133">Distinct type N based on a BLOB, CLOB, or
DBCLOB</td>
<td align="left" valign="top" headers="wq1134">BLOB, CLOB, or DBCLOB *</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq1133">Distinct type N based on a DATE, TIME, or
TIMESTAMP</td>
<td align="left" valign="top" headers="wq1134">DATE, TIME, or TIMESTAMP *</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq1133">BLOB, CLOB, or DBCLOB</td>
<td align="left" valign="top" headers="wq1134">BLOB, CLOB, or DBCLOB *</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq1133">DATE, TIME, or TIMESTAMP</td>
<td align="left" valign="top" headers="wq1134">DATE, TIME, or TIMESTAMP *</td>
</tr>
<tr>
<td colspan="2" align="left" valign="top" headers="wq1133 wq1134">
<a name="wq1135"></a>
<div class="notetitle" id="wq1135">Notes:</div>
<div class="notebody">
<p>* The name of the function must
match the name of the data type (or the source type of the distinct type)
with an implicit or explicit schema name of QSYS2.</p></div></td>
</tr>
</tbody>
</table>
<dl class="parml">
<dt class="bold"><var class="pv">constant</var> </dt><a id="idx1503" name="idx1503"></a>
<dd>Specifies a constant as the argument. The constant must conform to the
rules of a constant for the source type of the distinct type or for the data
type if not a distinct type. For BLOB, CLOB, DBCLOB, DATE, TIME, and TIMESTAMP
functions, the constant must be a string constant.
</dd>
<dt class="bold"><var class="pv">variable</var> </dt><a id="idx1504" name="idx1504"></a>
<dd>Specifies a variable as the argument. The variable must conform to the
rules of a constant for the source type of the distinct type or for the data
type if not a distinct type.
</dd>
</dl>
</dd>
<dt class="bold"><var class="pv">SQL-descriptors</var></dt>
<dd>If SQL descriptors are specified on CALL, a procedure that has IN and
INOUT parameters requires an SQL descriptor to be specified in the USING clause;
and a procedure that has OUT or INOUT parameters requires an SQL descriptor
to be specified in the INTO clause. If all the parameters of the procedure
are INOUT parameters, the same descriptor can be used for both clauses. For
more information, see <a href="rbafzmstcallsta.htm#multiple_sqld">Multiple SQL descriptors on CALL</a>.
<dl class="parml">
<dt class="bold">INTO<a id="idx1505" name="idx1505"></a></dt>
<dd>Identifies an SQL descriptor which contains valid descriptions
of the output variables to be used with the CALL statement. Before the CALL
statement is executed, a descriptor must be allocated using the ALLOCATE DESCRIPTOR
statement. The COUNT field in the descriptor header must be set to reflect
the number of OUT and INOUT parameters for the procedure. The item information,
including TYPE, and where applicable, DATETIME_INTERVAL_CODE, LENGTH, DB2_CCSID,
PRECISION, and SCALE, must be set for the variables that are used when processing
the statement.
<dl class="parml">
<dt class="bold">LOCAL</dt>
<dd>Specifies the scope of the name of the descriptor to be local to program
invocation. The information is returned from the descriptor known in this
local scope.
</dd>
<dt class="bold">GLOBAL</dt>
<dd>Specifies the scope of the name of the descriptor to be global to the
SQL session. The information is returned from the descriptor known to any
program that executes using the same database connection.
</dd>
<dt class="bold"><var class="pv">SQL-descriptor-name</var></dt>
<dd>Names the SQL descriptor. The name must identify a descriptor that already
exists with the specified scope. <a id="idx1506" name="idx1506"></a>
</dd>
</dl>
</dd>
<dt class="bold">USING</dt>
<dd>Identifies an SQL descriptor which contains valid descriptions
of the input variables to be used with the CALL statement. Before the CALL
statement is executed, a descriptor must be allocated using the ALLOCATE DESCRIPTOR
statement. The COUNT field in the descriptor header must be set to reflect
the number of IN and INOUT parameters for the procedure. The item information,
including TYPE, and where applicable, DATETIME_INTERVAL_CODE, LENGTH, DB2_CCSID,
PRECISION, and SCALE, must be set for the variables that are used when processing
the statement. The DATA item and when nulls are used, the INDICATOR item,
must be set for the input variables.
<dl class="parml">
<dt class="bold">LOCAL</dt>
<dd>Specifies the scope of the name of the descriptor to be local to program
invocation.
</dd>
<dt class="bold">GLOBAL</dt>
<dd>Specifies the scope of the name of the descriptor to be global to the
SQL session.
</dd>
<dt class="bold"><var class="pv">SQL-descriptor-name</var></dt>
<dd>Names the SQL descriptor. The name must identify a descriptor that already
exists with the specified scope. <a id="idx1507" name="idx1507"></a>
</dd>
</dl>
</dd>
</dl>
</dd>
<dt class="bold">USING DESCRIPTOR <var class="pv">descriptor-name</var> </dt><a id="idx1508" name="idx1508"></a><a id="idx1509" name="idx1509"></a><a id="idx1510" name="idx1510"></a>
<dd>Identifies an SQLDA that must contain a valid description of variables.
<p>Before the CALL statement is processed, you must set the following fields
in the SQLDA. (The rules for REXX are different. For more information, see
the <a href="../rzajp/rzajpkickoff.htm">Embedded SQL Programming</a> book.) </p>
<ul>
<li>SQLN to indicate the number of SQLVAR occurrences provided in the SQLDA</li>
<li>SQLDABC to indicate the number of bytes of storage allocated for the SQLDA</li>
<li>SQLD to indicate the number of variables used in the SQLDA when processing
the statement</li>
<li>SQLVAR occurrences to indicate the attributes of the variables.</li></ul><p class="indatacontent"> The SQLDA must have enough storage to contain all SQLVAR occurrences.
Therefore, the value in SQLDABC must be greater than or equal to 16 + SQLN*(80),
where 80 is the length of an SQLVAR occurrence. If LOBs or distinct types
are specified, there must be two SQLVAR entries for each parameter marker
and SQLN must be set to two times the number of parameter markers.</p>
<p>SQLD must be set to a value greater than or equal to zero and less than or
equal to SQLN. It must be the same as the number of parameters in the CALL
statement. The <span class="italic">n</span>th variable described by the SQLDA
corresponds to the <span class="italic">n</span>th parameter marker in the prepared
statement. (For a description of an SQLDA, see <a href="rbafzmstsqldda.htm#sqldda">Appendix D. SQLDA (SQL descriptor area)</a>.)</p>
<p>Note that RPG/400&reg; does not provide the function for setting pointers. Because
the SQLDA uses pointers to locate the appropriate variables, you have to set
these pointers outside your RPG/400 application.</p>
</dd>
</dl>
<a name="wq1136"></a>
<h3 id="wq1136"><a href="rbafzmst02.htm#ToC_798">Notes</a></h3>
<p><span class="bold">Parameter assignments:</span> When the CALL statement is
executed, the value of each of its parameters is assigned (using storage
assignment rules) to the corresponding parameter of the procedure. Control
is passed to the procedure according to the calling conventions of the host
language. When execution of the procedure is complete, the value of each
parameter of the procedure is assigned (using retrieval assignment rules)
to the corresponding parameter of the CALL statement defined as OUT or INOUT.
For details on the assignment rules, see <a href="rbafzmstch2bas.htm#ch2bas">Assignments and comparisons</a>.</p>
<p><span class="bold">Cursors and prepared statements in procedures:</span> All
cursors opened in the called procedure that are not result set cursors are
closed and all statements prepared in the called procedure are destroyed when
the procedure ends.</p>
<a name="callrs"></a>
<p id="callrs"><span class="bold">Result sets from procedures:</span> Result sets are only returned when a procedure
is directly called or a nested RETURN TO CLIENT procedure is indirectly called
from one of the following interfaces:</p>
<ul>
<li>ODBC,</li>
<li>JDBC,</li>
<li>OLE DB,</li>
<li>.NET,</li>
<li>SQL Call Level Interface, or</li>
<li>iSeries Access Family Optimized SQL API.</li></ul>
<p>There are three ways to return result sets from a procedure: </p>
<ul>
<li>If a SET RESULT SETS statement is executed in the procedure, the SET RESULT
SETS statement identifies the result sets. The result sets are returned in
the order specified on the SET RESULT SETS statement.</li>
<li>If a SET RESULT SETS statement is not executed in the procedure,
<ul>
<li>If no cursors have specified a WITH RETURN clause, each cursor that the
procedure opens and leaves open when it returns identifies a result set. The
result sets are returned in the order in which the cursors are opened.</li>
<li>If any cursors have specified a WITH RETURN clause, each cursor that is
defined with the WITH RETURN clause that the procedure opens and leaves open
when it returns identifies a result set. The result sets are returned in the
order in which the cursors are opened.</li></ul></li></ul><p class="indatacontent">When a result set is returned using an open cursor, the rows are returned
starting with the current cursor position.</p>
<p><span class="bold">Locks in procedures:</span> All locks that have been acquired
in the called procedure are retained until the end of the unit of work.</p>
<p><span class="bold">Errors from procedures:</span> A procedure can return errors
(or warnings) using the SQLSTATE like other SQL statements. Applications should
be aware of the possible SQLSTATEs that can be expected when invoking a procedure.
The possible SQLSTATEs depend on how the procedure is coded. Procedures may
also return SQLSTATEs such as those that begin with '38' or '39' if the database
manager encounters problems executing the procedure. Applications should therefore
be prepared to handle any error SQLSTATE that may result from issuing a CALL
statement.</p>
<p><span class="bold">Nesting CALL statements:</span> A program that is executing
as a procedure, a user-defined function, or a trigger can issue a CALL statement.
When a procedure, user-defined function, or trigger calls a procedure, user-defined
function, or trigger, the call is considered to be nested. There is no limit
on how many levels procedures and functions can be nested, but triggers can
only be nested up to 200 levels deep.</p>
<p>If a procedure returns any query result sets, the result sets are returned
to the caller of the procedure. If the SQL CALL statement is nested, the result
sets are visible only to the program that is at the previous nesting level.
For example, if a client program calls procedure PROCA, which in turn calls
procedure PROCB. Only PROCA can access any result sets that PROCB returns;
the client program has no access to the query result sets.</p>
<p>When an SQL or an external procedure is called, an attribute is set for
SQL data-access that was defined when the procedure was created. The possible
values for the attribute are:</p>
<pre class="xmp"> NONE
CONTAINS
READS
MODIFIES</pre><p class="indatacontent">If a second procedure is invoked within the execution of
the current procedure, an error is issued if:</p>
<ul>
<li>The invoked procedure possibly contains SQL and the invoking procedure
does not allow SQL</li>
<li>The invoked procedure reads SQL data and the invoking procedure does not
allow reading SQL data</li>
<li>The invoked procedure modifies SQL data and the invoking procedure does
not allow modifying SQL data</li></ul>
<p><span class="bold">REXX procedures:</span> If the external procedure to be
called is a REXX procedure, then the procedure must be declared using the
CREATE PROCEDURE or DECLARE PROCEDURE statement.</p>
<p>Variables cannot be used in the CALL statement within a REXX procedure.
Instead, the CALL must be the object of a PREPARE and EXECUTE using parameter
markers.</p>
<a name="multiple_sqld"></a>
<p id="multiple_sqld"><span class="bold">Multiple SQL descriptors on CALL:</span> If SQL descriptors are
specified on CALL and a procedure has IN or INOUT parameters and OUT or INOUT
parameters, two descriptors must be specified. The number of variables that
must be allocated in the SQL descriptors depends on how the SQL descriptor
attributes are set and the number of each type of parameter.</p>
<ul>
<li>If the input SQL descriptor attributes were set using DESCRIBE INPUT and
the output SQL descriptor attributes were set using DESCRIBE (OUTPUT), the
SQL descriptors will have attributes that match the actual procedure definition
at the current server prior to calling the procedure. In this case, the output
SQL descriptor will contain one variable for each OUT and INOUT parameter.
Likewise, the input SQL descriptor will contain one variable for each IN and
INOUT parameter.
<p>This is the recommended technique for specifying multiple
SQL descriptors on a CALL statement.</p></li>
<li>Otherwise, the actual procedure definition at the current server is unknown
prior to calling the procedure, so each parameter is assumed to be INOUT at
the time the procedure is called. This means that both SQL descriptors must
be specified, and since each parameter is assumed to be INOUT, they must have
the same number of variables and the TYPE, DATETIME_INTERVAL_CODE, LENGTH,
DB2_CCSID, PRECISION, and SCALE of each variable in the output SQL descriptor
must be exactly the same as the corresponding variable in the input SQL descriptor.
Otherwise, an error is returned.</li></ul>
<p>If multiple SQL descriptors are specified, the DATA or INDICATOR items
associated with any INOUT parameters in the input SQL descriptor may also
be modified when the procedure is called. Thus, a SET DESCRIPTOR may be necessary
to reset the DATA and INDICATOR items for such an input SQL descriptor prior
to its use in another SQL statement.</p>
<a name="wq1137"></a>
<h3 id="wq1137"><a href="rbafzmst02.htm#ToC_799">Examples</a></h3>
<p><span class="italic">Example 1:</span> Call procedure PGM1 and pass two parameters. </p>
<pre class="xmp"> <span class="bold">CALL</span> PGM1 (:hv1,:hv2)</pre>
<p><span class="italic">Example 2:</span> In C, invoke a procedure called SALARY_PROCED
using the SQLDA named INOUT_SQLDA. </p>
<pre class="xmp"> struct sqlda *INOUT_SQLDA;
/* Setup code for SQLDA variables goes here */
<span class="bold">CALL</span> SALARY_PROC <span class="bold">USING DESCRIPTOR</span> :*INOUT_SQLDA<span class="bold">;</span></pre>
<p><span class="italic">Example 3:</span> A Java procedure is defined in the database
using the following statement: </p>
<pre class="xmp"> <span class="bold">CREATE PROCEDURE</span> PARTS_ON_HAND <span class="bold">(IN</span> PARTNUM <span class="bold">INTEGER,</span>
<span class="bold">OUT</span> COST <span class="bold">DECIMAL(</span>7,2<span class="bold">),</span>
<span class="bold">OUT</span> QUANTITY <span class="bold">INTEGER)</span>
<span class="bold">LANGUAGE JAVA PARAMETER STYLE JAVA</span>
<span class="bold">EXTERNAL NAME</span> 'parts!onhand'<span class="bold">;</span></pre><p class="indatacontent"> A Java application calls this procedure <span>on the connection
context 'ctx'</span> using the following code fragment: </p>
<pre class="xmp">...
int variable1;
BigDecimal variable2;
Integer variable3;
...
#sql [ctx] {<span class="bold">CALL</span> PARTS_ON_HAND(:IN variable1, :OUT variable2, :OUT variable3)};
...</pre><p class="indatacontent"> This application code fragment will invoke the Java method
<span class="italic">onhand</span> in class <span class="italic">parts</span> since
the <var class="pv">procedure-name</var> specified on the CALL statement is found in the
database and has the external name 'parts!onhand'.<a id="idx1511" name="idx1511"></a><a id="idx1512" name="idx1512"></a></p>
<hr /><div class="fnnum"><a id="wq1131" name="wq1131" href="rbafzmstcallsta.htm#wq1130">59</a>.</div>
<div class="fntext">Note that in the case of decimal constants, leading zeroes
are significant when determining the attributes of the argument. Normally,
leading zeroes are not significant.</div>
<br />
<hr /><br />
[ <a href="#Top_Of_Page">Top of Page</a> | <a href="rbafzmstbegdcl.htm">Previous Page</a> | <a href="rbafzmstclosst.htm">Next Page</a> | <a href="rbafzmst02.htm#wq1">Contents</a> |
<a href="rbafzmstindex.htm#index">Index</a> ]
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink