DB2 Version 9.7 for Linux, UNIX, and Windows

PUT_ROUTINE_SAR procedure

The PUT_ROUTINE_SAR procedure passes the necessary file to create an SQL routine at the server and then defines the routine.

Authorization

DBADM

Read syntax diagramSkip visual syntax diagram
>>-PUT_ROUTINE_SAR---------------------------------------------->

>--(--sarblob--+------------------------------------+--)-------><
               '-,--new-owner--,--use-register-flag-'      

The schema is SYSFUN.

sarblob
An input argument of type BLOB(3M) that contains the routine SAR file contents.
new-owner
An input argument of type VARCHAR(128) that contains an authorization-name used for authorization checking of the routine. The new-owner must have the necessary privileges for the routine to be defined. If new-owner is not specified, the authorization-name of the original routine definer is used.
use-register-flag
An input argument of type INTEGER that indicates whether or not the CURRENT SCHEMA and CURRENT PATH special registers are used to define the routine. If the special registers are not used, the settings for the default schema and SQL path are the settings used when the routine was originally defined. Possible values for use-register-flag:
0
Do not use the special registers of the current environment
1
Use the CURRENT SCHEMA and CURRENT PATH special registers.
If the value is 1, CURRENT SCHEMA is used for unqualified object names in the routine definition (including the name of the routine) and CURRENT PATH is used to resolve unqualified routines and data types in the routine definition. If the use-registers-flag is not specified, the behavior is the same as if a value of 0 was specified.

The identification information contained in sarblob is checked to confirm that the inputs are appropriate for the environment, otherwise an error is raised (SQLSTATE 55046). The PUT_ROUTINE_SAR procedure then uses the contents of the sarblob to define the routine at the server.

The contents of the sarblob argument are extracted into the separate files that make up the SQL archive file. The shared library and bind files are written to files in a temporary directory. The environment is set so that the routine definition statement processing is aware that compiling and linking are not required, and that the location of the shared library and bind files is available. The contents of the DDL file are then used to dynamically execute the routine definition statement.

No more than one procedure can be concurrently installed under a given schema.

Processing of this statement might result in the same errors as executing the routine definition statement using other interfaces. During routine definition processing, the presence of the shared library and bind files is noted and the precompile, compile and link steps are skipped. The bind file is used during bind processing and the contents of both files are copied to the usual directory for an SQL routine.

If a GET ROUTINE or a PUT ROUTINE operation (or their corresponding procedure) fails to execute successfully, it will always return an error (SQLSTATE 38000), along with diagnostic text providing information about the cause of the failure. For example, if the procedure name provided to GET ROUTINE does not identify an SQL procedure, diagnostic "-204, 42704" text will be returned, where "-204" and "42704" are the SQLCODE and SQLSTATE that identify the cause of the problem. The SQLCODE and SQLSTATE in this example indicate that the procedure name provided in the GET ROUTINE command is undefined.