This section gives AIX-specific information for building DB2 applications on various supported compilers. It includes:
Because of the way AIX loads stored procedures and resolves library references within them, there are requirements on how COBOL should be installed. These requirements become a factor when a COBOL program loads a shared library (stored procedure) at run time.
When a stored procedure is loaded, the chain of libraries it refers to must also be loaded. When AIX searches for a library only indirectly referenced by your program, it must use the path compiled into the library that referenced it when it was built by the language provider (IBM COBOL or Micro Focus COBOL). This path may very well not be the same path in which the compiler was installed. If the library in the chain cannot be found, the stored procedure load will fail, and you will receive SQLCODE -10013.
To ensure this does not happen, install the compiler wherever you want, then create symbolic links of all language libraries from the install directory into /usr/lib (a directory that is almost always searched when a library needs to be loaded). You could link the libraries into sqllib/function (the stored procedure directory), but this only works for one database instance; /usr/lib works for everyone on the machine. It is strongly recommended that you do not copy the libraries in; this especially applies to Micro Focus COBOL when multiple copies of the libraries exist.
A sample symbolic link of Micro Focus COBOL is provided below (assuming it is installed in /usr/lpp/cobdir):
[1]> su root
[2]> cd /usr/lib
[1]> ln -sf /usr/lpp/cobdir/coblib/*.a .
Stored procedures are programs that access the database and return information to your client application. User-Defined Functions (UDFs) are your own scalar or table functions. Stored procedures and UDFs are compiled on the server, and stored and executed in shared libraries on the server. These shared libraries are created when you compile the stored procedures and UDFs.
Each shared library has an entry point, which is called from the server to access procedures in the shared library. The IBM C compiler on AIX allows you to specify any exported function name in the library as the default entry point. This is the function that is called if only the library name is specified in a stored procedure call or CREATE FUNCTION statement. This can be done with the -e option in the link step. For example:
-e funcname
makes funcname the default entry point. For information on how this relates to the CREATE FUNCTION statement, see "UDFs and the CREATE FUNCTION Statement".
On other UNIX platforms, no such mechanism exists, so the default entry point is assumed by DB2 to be the same name as the library itself.
AIX requires you to provide an export file which specifies which global functions in the library are callable from outside it. This file must include the names of all stored procedures and/or user-defined functions in the library. Other UNIX platforms simply export all global functions in the library. This is an example of an AIX export file:
#! outsrv export file outsrv |
The export file outsrv.exp lists the stored procedure outsrv. The linker uses outsrv.exp to create the shared library outsrv that contains the stored procedure of the same name.
| Note: | After the shared library is built, it is typically copied into a directory from which DB2 will access it. When attempting to replace either a stored procedure or a user-defined function shared library, you should either run /usr/sbin/slibclean to flush the AIX shared library cache, or remove the library from the target directory and then copy the library from the source directory to the target directory. Otherwise, the copy operation may fail because AIX keeps a cache of referenced libraries and does not allow the library to be overwritten. |
The AIX compiler documentation has additional information on export files.
The Application Development Guide describes how to code your stored procedure. The SQL Reference describes how to invoke your stored procedure at the location of a database using the CALL statement. This section tells you how to compile and link your stored procedure in line with the information you provide in the CALL statement.
When you compile and link your program, you can identify functions in two ways:
For example, you can specify the following in the link step:
-e modify
This indicates that the default entry point for the linked library is the function modify.
If you are linking a library mystored in a directory /u/mydir/procs, and you want to use the default entry point modify as specified above, code your CALL statement as follows:
CALL '/u/mydir/procs/mystored'
The library mystored is loaded into memory, and the function modify is picked up by DB2 as the default entry point, and is executed.
Generally speaking, you would use this link option when you have more than one stored procedure in your library, and you want to access additional functions as stored procedures.
To continue the example from above, suppose that the library mystored contains three stored procedures: modify as above, remove, and add. You identify modify as the default entry point, as above, and indicate in the link step that remove and add are additional entry points by including them in an export file.
In the link step, you specify:
-bE:mystored.exp
which identifies the export file mystored.exp.
The export file would be a list of the stored procedure functions, with the default entry point listed first:
modify remove add |
Finally, your two CALL statements for the stored procedures, which invoke the remove and add functions, are coded as follows:
CALL '/u/mydir/procs/mystored!remove'
and
CALL '/u/mydir/procs/mystored!add'
The Application Development Guide describes how to code your UDF. The SQL Reference describes how to register your UDF with DB2 using the CREATE FUNCTION statement. This section explains the relation between compiling and linking your UDF and the information you provide in the EXTERNAL NAME clause of the CREATE FUNCTION statement.
When you compile and link your program, you can identify functions in two ways:
For example, you can specify the following in the link step:
-e modify
This indicates that the default entry point for the linked library is the function modify.
If you are linking a library myudfs in a directory /u/mydir/procs, and you want to use the default entry point modify as specified above, include the following in your CREATE FUNCTION statement:
EXTERNAL NAME '/u/mydir/procs/myudfs'
DB2 picks up the default entry point of the library myudfs, which is the function modify.
Generally speaking, you would use this link option when you have more than one UDF in your library, and you want to access additional functions as UDFs.
To continue the example from above, suppose that the library myudfs contains three UDFs: modify as above, remove, and add. You identify modify as the default entry point, as above, and indicate in the link step that remove and add are additional entry points by including them in an export file.
In the link step, you specify:
-bE:myudfs.exp
which identifies the export file myudfs.exp.
The export file looks like this:
* additional entry points for myudfs #! remove add |
Finally, your two CREATE FUNCTION statements for the UDFs, which are implemented by the remove and add functions, would contain these EXTERNAL NAME clauses:
EXTERNAL NAME '/u/mydir/procs/myudfs!remove'
and
EXTERNAL NAME '/u/mydir/procs/myudfs!add'