STORED PROCEDURES FOR DB2 USING C AND JAVA

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Pa » Sun, 18 Nov 2001 08:18:37



Over the past week I had very little success with Stored Procedues.
Initially I was given C files to be installed as stored procedures.
To install C stored procedures this is what I did...

Server OS: AIX
DB2 Ver 7.1
Client OS: NT

1) prep the .sqc file to get .bnd and .c file (done from client CLP)
2) bind the .bnd file to the database (done from client CLP)
3) compiled .c file with all the option as specified in the sample
program (done on server)
4) copied the shared library to the sqllib/function directory (on
server)
5) registered the procedure by issuing a CREATE PROCEDURE command (on
server)

Create procedure looked like this:

CREATE PROCEDURE  OI_QUESTIONS (OUT RETURN_CODE INTEGER, OUT
RETURN_MESSAGE VARCHAR(256),
 IN UNIT_IDs VARCHAR(51), IN TAB_ID INTEGER, IN NID VARCHAR(256))
DYNAMIC RESULT SETS 1
LANGUAGE C
PARAMETER STYLE GENERAL
NO DBINFO
FENCED
READS SQL DATA
PROGRAM TYPE MAIN

When I try to run the Stored Procedure by a client application using
JDBC, I am getting the following exception

[IBM][CLI Driver][DB2/6000] SQL10010N  The specified library, "gq",
was loaded, but the function "main" could not be executed.

So I tried to build the same stored procedure using SPB on NT client.
I was able to build and install the stored procedure on the server.
In fact I can even run the stored procedure within the SPB environment
without any problem.

SQL statement generated by SPB looks like this:

CREATE PROCEDURE DB2INST1.J_QUESTIONS ( IN WHICHQUERY int, OUT SQLCODE
int, OUT SQLMESSAGE varchar(4000), IN UNIT_ID varchar(51), IN TAB_ID
int, IN NID varchar(256) ) EXTERNAL NAME
'"DB2INST1".QUEST_ID:com.myfunc.db2.QUESTIONS.quest' SPECIFIC
DB2INST1.QUEST_SPNAME RESULT SETS 1 LANGUAGE JAVA PARAMETER STYLE JAVA
NOT DETERMINISTIC FENCED NO DBINFO NULL CALL READS SQL DATA

However when I use client app using JDBC, I get the following error:
[IBM][CLI Driver][DB2/6000] SQL10013N  The specified library
"/home/db2inst1/sqllib/function/QUESTIONS" could not be loaded.

I am not sure what is it that I am doing wrong..  Can somebody help!!!

Thanks
Pat

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Dirk » Sun, 18 Nov 2001 10:07:36



Quote:> When I try to run the Stored Procedure by a client application using
> JDBC, I am getting the following exception

> [IBM][CLI Driver][DB2/6000] SQL10010N  The specified library, "gq",
> was loaded, but the function "main" could not be executed.

Not sure what the reason for this is. Did you build gq as a shared library
or executable? "PROGRAM TYPE MAIN" should mean that it's build as an
executable. Can you run it? Does it have dependencies on other libraries?

Quote:> So I tried to build the same stored procedure using SPB on NT client.
> I was able to build and install the stored procedure on the server.
> In fact I can even run the stored procedure within the SPB environment
> without any problem.

> SQL statement generated by SPB looks like this:

> CREATE PROCEDURE DB2INST1.J_QUESTIONS ( IN WHICHQUERY int, OUT SQLCODE
> int, OUT SQLMESSAGE varchar(4000), IN UNIT_ID varchar(51), IN TAB_ID
> int, IN NID varchar(256) ) EXTERNAL NAME
> '"DB2INST1".QUEST_ID:com.myfunc.db2.QUESTIONS.quest' SPECIFIC
> DB2INST1.QUEST_SPNAME RESULT SETS 1 LANGUAGE JAVA PARAMETER STYLE JAVA
> NOT DETERMINISTIC FENCED NO DBINFO NULL CALL READS SQL DATA

> However when I use client app using JDBC, I get the following error:
> [IBM][CLI Driver][DB2/6000] SQL10013N  The specified library
> "/home/db2inst1/sqllib/function/QUESTIONS" could not be loaded.

Do prepare
"call DB2INST1.J_QUESTIONS (?,?, ?, ?, ?, ?) "
and make sure you set all input and register all output parameters. SPB uses
JDBC too. So it's unlikely that this is a bug.

You can look at some examples in sqllib\samples\java

Dirk

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by PATHANJALI MALA » Sun, 18 Nov 2001 23:26:52






> > When I try to run the Stored Procedure by a client application using
> > JDBC, I am getting the following exception

> > [IBM][CLI Driver][DB2/6000] SQL10010N  The specified library, "gq",
> > was loaded, but the function "main" could not be executed.

> Not sure what the reason for this is. Did you build gq as a shared library
> or executable? "PROGRAM TYPE MAIN" should mean that it's build as an
> executable. Can you run it? Does it have dependencies on other libraries?

I have built it as a shared library.  But I am using a main function type
arguments in the function.  I thought the difference between a PROGRAM TYPE
MAIN and PROGRAM TYPE SUB is how the arguemnts are passed.  I thought in SUB
type the argument list would like func(VARCHAR, INT, VARCHAR, LONG) etc.
whereas in type MAIN it would take arguments like (int , char**).  I tried
to look in the DB2 manuals for a clear explanation on this but I couldn't
really find anything that says that if PROGRAM TYPE MAIN is used then the
library has to be executable.

Quote:> > So I tried to build the same stored procedure using SPB on NT client.
> > I was able to build and install the stored procedure on the server.
> > In fact I can even run the stored procedure within the SPB environment
> > without any problem.

> > SQL statement generated by SPB looks like this:

> > CREATE PROCEDURE DB2INST1.J_QUESTIONS ( IN WHICHQUERY int, OUT SQLCODE
> > int, OUT SQLMESSAGE varchar(4000), IN UNIT_ID varchar(51), IN TAB_ID
> > int, IN NID varchar(256) ) EXTERNAL NAME
> > '"DB2INST1".QUEST_ID:com.myfunc.db2.QUESTIONS.quest' SPECIFIC
> > DB2INST1.QUEST_SPNAME RESULT SETS 1 LANGUAGE JAVA PARAMETER STYLE JAVA
> > NOT DETERMINISTIC FENCED NO DBINFO NULL CALL READS SQL DATA

> > However when I use client app using JDBC, I get the following error:
> > [IBM][CLI Driver][DB2/6000] SQL10013N  The specified library
> > "/home/db2inst1/sqllib/function/QUESTIONS" could not be loaded.

> Do prepare
> "call DB2INST1.J_QUESTIONS (?,?, ?, ?, ?, ?) "
> and make sure you set all input and register all output parameters. SPB
uses
> JDBC too. So it's unlikely that this is a bug.

OK Thats good.  I have to try this one.

Quote:

> You can look at some examples in sqllib\samples\java

> Dirk

Thank you very much for Dirk and anyone who shares their wisdom...
Pat
 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Knut Stol » Mon, 19 Nov 2001 08:08:38







> > > When I try to run the Stored Procedure by a client application using
> > > JDBC, I am getting the following exception

> > > [IBM][CLI Driver][DB2/6000] SQL10010N  The specified library, "gq",
> > > was loaded, but the function "main" could not be executed.

> > Not sure what the reason for this is. Did you build gq as a shared library
> > or executable? "PROGRAM TYPE MAIN" should mean that it's build as an
> > executable. Can you run it? Does it have dependencies on other libraries?

>  I have built it as a shared library.  But I am using a main function type
>  arguments in the function.  I thought the difference between a PROGRAM TYPE
>  MAIN and PROGRAM TYPE SUB is how the arguemnts are passed.  I thought in SUB
>  type the argument list would like func(VARCHAR, INT, VARCHAR, LONG) etc.
>  whereas in type MAIN it would take arguments like (int , char**).  I tried
>  to look in the DB2 manuals for a clear explanation on this but I couldn't
>  really find anything that says that if PROGRAM TYPE MAIN is used then the
>  library has to be executable.

From the SQL Reference, "CREATE PROCEDURE" statement:

PROGRAM TYPE
      [...]

      MAIN
        The stored procedure expects the parameters to be passed as an
        argument counter, and a vector of arguments (argc, argv). The name
        of the stored procedure to be invoked must also be "main". Stored
        procedures of this type must still be built in the same fashion as a
        shared library as opposed to a stand-alone executable.

I think that's crystal clear.  You must indeed use a shared library and not
an executable.

But let's continue in the description:

      The default for PROGRAM TYPE is SUB. PROGRAM TYPE MAIN is
      only valid for LANGUAGE C or COBOL and PARAMETER STYLE
      GENERAL, GENERAL WITH NULLS or DB2SQL.

Are you, by any chance, using Java?  If yes, then you cannot use program
style MAIN.

Quote:> > > So I tried to build the same stored procedure using SPB on NT client.
> > > I was able to build and install the stored procedure on the server.
> > > In fact I can even run the stored procedure within the SPB environment
> > > without any problem.

> > > SQL statement generated by SPB looks like this:

> > > CREATE PROCEDURE DB2INST1.J_QUESTIONS ( IN WHICHQUERY int, OUT SQLCODE
> > > int, OUT SQLMESSAGE varchar(4000), IN UNIT_ID varchar(51), IN TAB_ID
> > > int, IN NID varchar(256) ) EXTERNAL NAME
> > > '"DB2INST1".QUEST_ID:com.myfunc.db2.QUESTIONS.quest' SPECIFIC
> > > DB2INST1.QUEST_SPNAME RESULT SETS 1 LANGUAGE JAVA PARAMETER STYLE JAVA
> > > NOT DETERMINISTIC FENCED NO DBINFO NULL CALL READS SQL DATA

This is a LANGUAGE JAVA procedure.  How does this relate to the problem
above?

--
Knut Stolze
DB2 UDB Spatial Extender
IBM Silicon Valley Lab

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Dirk » Tue, 20 Nov 2001 07:26:39








> > > > When I try to run the Stored Procedure by a client application using
> > > > JDBC, I am getting the following exception

> > > > [IBM][CLI Driver][DB2/6000] SQL10010N  The specified library, "gq",
> > > > was loaded, but the function "main" could not be executed.

> > > Not sure what the reason for this is. Did you build gq as a shared
library
> > > or executable? "PROGRAM TYPE MAIN" should mean that it's build as an
> > > executable. Can you run it? Does it have dependencies on other
libraries?

> >  I have built it as a shared library.  But I am using a main function
type
> >  arguments in the function.  I thought the difference between a PROGRAM
TYPE
> >  MAIN and PROGRAM TYPE SUB is how the arguemnts are passed.  I thought
in SUB
> >  type the argument list would like func(VARCHAR, INT, VARCHAR, LONG)
etc.
> >  whereas in type MAIN it would take arguments like (int , char**).  I
tried
> >  to look in the DB2 manuals for a clear explanation on this but I
couldn't
> >  really find anything that says that if PROGRAM TYPE MAIN is used then
the
> >  library has to be executable.

> From the SQL Reference, "CREATE PROCEDURE" statement:

> PROGRAM TYPE
>       [...]

>       MAIN
>         The stored procedure expects the parameters to be passed as an
>         argument counter, and a vector of arguments (argc, argv). The name
>         of the stored procedure to be invoked must also be "main". Stored
>         procedures of this type must still be built in the same fashion as
a
>         shared library as opposed to a stand-alone executable.

> I think that's crystal clear.  You must indeed use a shared library and
not
> an executable.

Good! Then the next question is if the customer exported the "main" symbol
and used all the right compiler switches and libraries. Look at the "DB2
Application Buiding Guide" under the section "Building AIX Applications -
IBM C - DB2 CLI Stored Procedures". Remove the CLI specific stuff if you
don't use it.

Dirk

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Pa » Wed, 21 Nov 2001 01:05:45








> > > > When I try to run the Stored Procedure by a client application using
> > > > JDBC, I am getting the following exception

> > > > [IBM][CLI Driver][DB2/6000] SQL10010N  The specified library, "gq",
> > > > was loaded, but the function "main" could not be executed.

> > > Not sure what the reason for this is. Did you build gq as a shared library
> > > or executable? "PROGRAM TYPE MAIN" should mean that it's build as an
> > > executable. Can you run it? Does it have dependencies on other libraries?

> >  I have built it as a shared library.  But I am using a main function type
> >  arguments in the function.  I thought the difference between a PROGRAM TYPE
> >  MAIN and PROGRAM TYPE SUB is how the arguemnts are passed.  I thought in SUB
> >  type the argument list would like func(VARCHAR, INT, VARCHAR, LONG) etc.
> >  whereas in type MAIN it would take arguments like (int , char**).  I tried
> >  to look in the DB2 manuals for a clear explanation on this but I couldn't
> >  really find anything that says that if PROGRAM TYPE MAIN is used then the
> >  library has to be executable.

> From the SQL Reference, "CREATE PROCEDURE" statement:

> PROGRAM TYPE
>       [...]

>       MAIN
>         The stored procedure expects the parameters to be passed as an
>         argument counter, and a vector of arguments (argc, argv). The name
>         of the stored procedure to be invoked must also be "main". Stored
>         procedures of this type must still be built in the same fashion as a
>         shared library as opposed to a stand-alone executable.

> I think that's crystal clear.  You must indeed use a shared library and not
> an executable.

> But let's continue in the description:

>       The default for PROGRAM TYPE is SUB. PROGRAM TYPE MAIN is
>       only valid for LANGUAGE C or COBOL and PARAMETER STYLE
>       GENERAL, GENERAL WITH NULLS or DB2SQL.

> Are you, by any chance, using Java?  If yes, then you cannot use program
> style MAIN.

> > > > So I tried to build the same stored procedure using SPB on NT client.
> > > > I was able to build and install the stored procedure on the server.
> > > > In fact I can even run the stored procedure within the SPB environment
> > > > without any problem.

> > > > SQL statement generated by SPB looks like this:

> > > > CREATE PROCEDURE DB2INST1.J_QUESTIONS ( IN WHICHQUERY int, OUT SQLCODE
> > > > int, OUT SQLMESSAGE varchar(4000), IN UNIT_ID varchar(51), IN TAB_ID
> > > > int, IN NID varchar(256) ) EXTERNAL NAME
> > > > '"DB2INST1".QUEST_ID:com.myfunc.db2.QUESTIONS.quest' SPECIFIC
> > > > DB2INST1.QUEST_SPNAME RESULT SETS 1 LANGUAGE JAVA PARAMETER STYLE JAVA
> > > > NOT DETERMINISTIC FENCED NO DBINFO NULL CALL READS SQL DATA

> This is a LANGUAGE JAVA procedure.  How does this relate to the problem
> above?

Hhh! Well, I am trying to sail in tow boats.  I have initially tried
to build the stored procedure in C.  After repeated failed attempts I
decided to give a try to Java.  Right now I couldn't get any of the
two to work.  I want atleast one of them to work.

For the C language stored procedure, I am building the target as a
shared library and not executable.  I am even explicitly export the
main function.  And also specified to use main function in the library
in EXTERNAL clause.

The java one is really funny.  I have used SBP to build java stored
procedure.  I can run it from SBP but I cannot run it from a Java
client using JDBC. As pointed out by Dirk I have tried using fully
qualified name for the stored procedure which
<schema_name>.<procedure_name>  even that didn't help I am still
getting the message that

[IBM][CLI Driver][DB2/6000] SQL10013N  The specified library
"/home/db2inst1/sqllib/function/DB2INST1.JQUESTIONS" could not be
loaded.

I was just wondering if there are any other resources other than
manuals that IBM has something like a knowledge base.  Because manuals
sure doesn't seem to help me on this one.

Thanks again for your help..

Pat

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Dirk » Wed, 21 Nov 2001 04:26:54



> For the C language stored procedure, I am building the target as a
> shared library and not executable.  I am even explicitly export the
> main function.  And also specified to use main function in the library
> in EXTERNAL clause.

I almost ran out of ideas. Have you tried setting the diaglevel to 4 and see
if there's something helpful in db2diag.log?

Quote:> The java one is really funny.  I have used SBP to build java stored
> procedure.  I can run it from SBP but I cannot run it from a Java
> client using JDBC. As pointed out by Dirk I have tried using fully
> qualified name for the stored procedure which
> <schema_name>.<procedure_name>  even that didn't help I am still
> getting the message that

> [IBM][CLI Driver][DB2/6000] SQL10013N  The specified library
> "/home/db2inst1/sqllib/function/DB2INST1.JQUESTIONS" could not be
> loaded.

> I was just wondering if there are any other resources other than
> manuals that IBM has something like a knowledge base.  Because manuals
> sure doesn't seem to help me on this one.

The manuals are very precise about that. You only have to find where to
look! In the SQL Reference under "CALL" we explain how dispatch is done for
catalogued SPs:

"A matching procedure is determined using the steps that follow.
  1.. Find the procedures from the catalog (SYSCAT.PROCEDURES) where the
PROCNAME matches the procedure-name specified and the PROCSCHEMA is a schema
name in the SQL path (CURRENT PATH special register). If the schema name is
explicitly specified, the SQL path is ignored and only procedures with the
specified schema name are considered.
  2.. Next, eliminate any of these procedures that do not have the same
number of parameters as the number of arguments specified in the CALL
statement.
  3.. Chose the remaining procedure that is earliest in the SQL path.
  4.. If there are no remaining procedures after step 2, an error is
returned (SQLSTATE 42884). "
You have to make sure that DB2 looks in the right schema (e.g. explicitly
calling it with "CALL SPSCHEMA.SPNAME" or by setting the SQL PATH). The SP
has to have the right number of parameters (output parameters do count).

If you don't figure it out on your own, please post the DDL again and the
JDBC code.

Dirk

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by PATHANJALI MALA » Wed, 21 Nov 2001 12:45:05





> > For the C language stored procedure, I am building the target as a
> > shared library and not executable.  I am even explicitly export the
> > main function.  And also specified to use main function in the library
> > in EXTERNAL clause.

> I almost ran out of ideas. Have you tried setting the diaglevel to 4 and
see
> if there's something helpful in db2diag.log?

> > The java one is really funny.  I have used SBP to build java stored
> > procedure.  I can run it from SBP but I cannot run it from a Java
> > client using JDBC. As pointed out by Dirk I have tried using fully
> > qualified name for the stored procedure which
> > <schema_name>.<procedure_name>  even that didn't help I am still
> > getting the message that

> > [IBM][CLI Driver][DB2/6000] SQL10013N  The specified library
> > "/home/db2inst1/sqllib/function/DB2INST1.JQUESTIONS" could not be
> > loaded.

> > I was just wondering if there are any other resources other than
> > manuals that IBM has something like a knowledge base.  Because manuals
> > sure doesn't seem to help me on this one.

> The manuals are very precise about that. You only have to find where to
> look! In the SQL Reference under "CALL" we explain how dispatch is done
for
> catalogued SPs:

> "A matching procedure is determined using the steps that follow.
>   1.. Find the procedures from the catalog (SYSCAT.PROCEDURES) where the
> PROCNAME matches the procedure-name specified and the PROCSCHEMA is a
schema
> name in the SQL path (CURRENT PATH special register). If the schema name
is
> explicitly specified, the SQL path is ignored and only procedures with the
> specified schema name are considered.
>   2.. Next, eliminate any of these procedures that do not have the same
> number of parameters as the number of arguments specified in the CALL
> statement.
>   3.. Chose the remaining procedure that is earliest in the SQL path.
>   4.. If there are no remaining procedures after step 2, an error is
> returned (SQLSTATE 42884). "
> You have to make sure that DB2 looks in the right schema (e.g. explicitly
> calling it with "CALL SPSCHEMA.SPNAME" or by setting the SQL PATH). The SP
> has to have the right number of parameters (output parameters do count).

> If you don't figure it out on your own, please post the DDL again and the
> JDBC code.

> Dirk

I figured out the problem with Java SP.  I should have mentioned the strange
things that I noticed when I used SPB.  Well, the SPB has automatically put
in an argument of type integer (IN), which is later used in a switch
statement.  I did not understand why it was doing so and I was not able to
delete it from the argument list (I was using SPB wizard).  Surprisingly
when I was running the procedure from SPB it did not ask me for a value for
the integer argument.  I guess it automatically filled in a value of 0 for
that.  Anyway, when I removed the integer type argument by editing the code
and rebuilt the procedure, it started working from the Java client app using
JDBC.  Thank you very much for all your help guys..

Now coming to the C procedure, I think I made a little bit of improvement on
that front as well.  Well, I think the problem there is that the compiler is
automatically building an executable eventhough I thought it was building a
shared library as I was using exactly the same compiler options and switches
that were mentioned in the samples.  I am not aware of any tool or any other
utility which can inspect the binary file and tell me if it is a library or
an executable.  I guess the problem might incompatabilities between
different versions of compilers and OSs.  We have a total of three AIX
machines.  Only one of them has DB2.  It doesn't have a C compiler on it.
So, I had compile the C files on a different AIX machine and ftp the
binaries to the machine it has DB2 on.  To make matters even worse, for some
strange reason I am not able to run prep on AIX machine.  However, I am able
to run the prep command from DB2 connect on my desktop using the same user
and same priviliges.  That would be my next task to figure out why it is
happening.  Anyway, I tried to compile the files on a different machine and
using VACPP compiler.  Earlier, I was using a AIX machine with IBM C
compiler.  After the new compilation and rebuilding process, I am not
getting an exception on calling execute method of CallableStatement.
However, I am getting an SQLCODE of -4903.  I wasn't able to figure out what
exactly that code means.  I have to do some more digging into the manuals to
find that out.

I really appreciate your help, and thank you very very much... (being a
newbie to AIX world and databases world, these newgroups are definitely a
big rescue..)

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Dirk » Thu, 22 Nov 2001 03:02:38



Quote:> I figured out the problem with Java SP.
[...]
>  Thank you very much for all your help guys..

Good! You're welcome!

Quote:> Now coming to the C procedure, I think I made a little bit of improvement
on
> that front as well.  Well, I think the problem there is that the compiler
is
> automatically building an executable eventhough I thought it was building
a
> shared library as I was using exactly the same compiler options and
switches
> that were mentioned in the samples.  I am not aware of any tool or any
other
> utility which can inspect the binary file and tell me if it is a library
or
> an executable.

try :
$ file /home/wollsch/bin/unzip
/home/wollsch/bin/unzip:        executable (RISC System/6000) or object
module not stripped
$ file /usr/ccs/lib/libc.a
/usr/ccs/lib/libc.a:    archive (big format)

The AIX compilers versions aren't that different. This script from the "app
building guide" should do what you need:
#! /bin/ksh
# bldclisp script file -- AIX
# Builds a CLI stored procedure in IBM C.
# Usage: bldclisp <prog_name> [ <entry_point> ]

# Set DB2PATH to where DB2 will be accessed.
# The default is the standard instance path.
DB2PATH=$HOME/sqllib

# To compile 64 bit programs, uncomment the following line.
# BUILD_64BIT=true

if [ "$BUILD_64BIT" != "" ]
then
  CFLAGS_64=-q64
else
  CFLAGS_64=
fi

# Compile the error-checking utility.
xlc $CFLAGS_64 -I$DB2PATH/include -c utilcli.c

# Compile the program.
xlc $CFLAGS_64 -I$DB2PATH/include -c $1.c

# Link the program.
xlc $CFLAGS_64 -o $1 $1.o utilcli.o -L$DB2PATH/lib \
  -ldb2 -lm -H512 -T512 -bE:$1.exp -e $2

# Copy the shared library to the sqllib/function subdirectory.
# Note: the user must have write permission to this directory.
rm -f $DB2PATH/function/$1
cp $1 $DB2PATH/function

 
 
 

STORED PROCEDURES FOR DB2 USING C AND JAVA

Post by Pa » Wed, 28 Nov 2001 05:01:17


I finally managed to get C stored procedures to work with JDBC.  The
trick is not to use "main" as the function name.  I changed the
function name to main_example and everything started working.

I am guessing that as soon as the compiler sees a "main" function it
automatically builds an executable file instead of a library.  And
because DB2 can only work with shared libraries, it doesn't know what
to do when it finds an executable.  I could not figure out any option
in C compiler to force a library built.  I understand that in newer
versions of the compiler one can use -qmkshrobj (or something similar)
option to build a shared library.  May be it will be a useful tip for
the knowledge base.

Thanks for your help.

Pat




> > I figured out the problem with Java SP.
>  [...]
> >  Thank you very much for all your help guys..

> Good! You're welcome!

> > Now coming to the C procedure, I think I made a little bit of improvement
>  on
> > that front as well.  Well, I think the problem there is that the compiler
>  is
> > automatically building an executable eventhough I thought it was building
>  a
> > shared library as I was using exactly the same compiler options and
>  switches
> > that were mentioned in the samples.  I am not aware of any tool or any
>  other
> > utility which can inspect the binary file and tell me if it is a library
>  or
> > an executable.

> try :
> $ file /home/wollsch/bin/unzip
> /home/wollsch/bin/unzip:        executable (RISC System/6000) or object
> module not stripped
> $ file /usr/ccs/lib/libc.a
> /usr/ccs/lib/libc.a:    archive (big format)

> The AIX compilers versions aren't that different. This script from the "app
> building guide" should do what you need:
> #! /bin/ksh
> # bldclisp script file -- AIX
> # Builds a CLI stored procedure in IBM C.
> # Usage: bldclisp <prog_name> [ <entry_point> ]

> # Set DB2PATH to where DB2 will be accessed.
> # The default is the standard instance path.
> DB2PATH=$HOME/sqllib

> # To compile 64 bit programs, uncomment the following line.
> # BUILD_64BIT=true

> if [ "$BUILD_64BIT" != "" ]
> then
>   CFLAGS_64=-q64
> else
>   CFLAGS_64=
> fi

> # Compile the error-checking utility.
> xlc $CFLAGS_64 -I$DB2PATH/include -c utilcli.c

> # Compile the program.
> xlc $CFLAGS_64 -I$DB2PATH/include -c $1.c

> # Link the program.
> xlc $CFLAGS_64 -o $1 $1.o utilcli.o -L$DB2PATH/lib \
>   -ldb2 -lm -H512 -T512 -bE:$1.exp -e $2

> # Copy the shared library to the sqllib/function subdirectory.
> # Note: the user must have write permission to this directory.
> rm -f $DB2PATH/function/$1
> cp $1 $DB2PATH/function

 
 
 

1. Calling a Java Stored Procedure from another Java Stored Stored Procedure

Hi,
I'm using the stored procedure builder of DB2 UDB v6.1 on NT to create a
Java Stored Procedure to call another Java Stored Procedure. Both of
them belong to the same project in stored procedure builder.
The sp that calls another sp has the code as follows:
// Calling another java sp -- ErrorHandler
ErrorHandler err = new ErrorHandler();
err.execute("Test #1", 100, "Testing #1");
When I want to build the sp which calls another sp from within, it gave
me an error as follows:
C:\IBMVJava\ide\tools\com-ibm-db2-tools-dev-spb-ivj\spb\bld953747549650\
com\intertrac\datamart\sp\SelectBillShipAddr.java:18: Class
com.intertrac.datamart.sp.ErrorHandler not found in type declaration.
ErrorHandler err = new ErrorHandler();
Does anyone have any clue of how this can be properly done ? Please let
me know.
Thanks,
ra

Sent via Deja.com http://www.deja.com/
Before you buy.

2. Client-Server (was: Database question)

3. Stored procedures problem using DB2 Stored Procedure Builder

4. Urgent! How to link VB to Access interface which is protected by password??

5. Gettting SQL0751N trying to call java stored procedure from a java stored procedure

6. Navigating in Preview Mode

7. SQLJ Java Stored Procedures with DB2 6 on OS/390

8. DB2 Java Stored procedures

9. DB2 Java stored procedures privileges

10. accessing db2 stored procedure from java

11. DB2 java stored procedure

12. Interpreted Java Stored Procedures with DB2 on OS/390