Compiling stored UDFs

Gregor Kovaè

Hi!

I have a UDFs defined in a C source file. I also have a Microsoft Visual
Studio 2005.
Can someone please tell me how to compile this C source with Microsoft's
compiler into a DLL? I'd prefer the command line options :)

Best regards,
Kovi
--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 6 '06 #1

Serge Rielau

Gregor Kova� wrote:

Hi!

I have a UDFs defined in a C source file. I also have a Microsoft Visual
Studio 2005.
Can someone please tell me how to compile this C source with Microsoft's
compiler into a DLL? I'd prefer the command line options :)

Best regards,
Kovi

Gregor,

cd to sqllib\samples\c
There is a DOS script called bldrtn
Usage is described in the header comments.
When you have it done once it's pretty trivial.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Apr 6 '06 #2

Gregor Kovaè

Serge Rielau wrote:

Gregor Kovaè wrote:

Hi!

I have a UDFs defined in a C source file. I also have a Microsoft Visual
Studio 2005.
Can someone please tell me how to compile this C source with Microsoft's
compiler into a DLL? I'd prefer the command line options :)

Best regards,
Kovi

Gregor,

cd to sqllib\samples\c
There is a DOS script called bldrtn
Usage is described in the header comments.
When you have it done once it's pretty trivial.

Cheers
Serge

I've got the put_line sources and I want to compile it for a 64-bit DB2
v8.2.
I did compile it with bldrtn, but when I copy it to FUNCTION directory, bind
it to DB2, use it in a procedure I get:
SQL0444N Routine "EMGSYS.PUT_LINE" (specific name "SQL060406131448304")
is
implemented with code in library or path "\put_line", function
"put_line2"
which cannot be accessed. Reason code: "4". SQLSTATE=42724

Regards,
Kovi
--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 7 '06 #3

Knut Stolze

Gregor Kova� wrote:

I've got the put_line sources and I want to compile it for a 64-bit DB2
v8.2.
I did compile it with bldrtn, but when I copy it to FUNCTION directory,
The bldrtn script already copies the necessary files to sqllib/function/
directory (at least on Unix and Linux systems).
bind it to DB2, use it in a procedure I get:
SQL0444N Routine "EMGSYS.PUT_LINE" (specific name "SQL060406131448304")
is
implemented with code in library or path "\put_line", function
"put_line2"
which cannot be accessed. Reason code: "4". SQLSTATE=42724

What does your CREATE FUNCTION statement look like?

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

Apr 7 '06 #4

Gregor Kovaè

Knut Stolze wrote:

Gregor Kovaè wrote:

I've got the put_line sources and I want to compile it for a 64-bit DB2
v8.2.
I did compile it with bldrtn, but when I copy it to FUNCTION directory,

The bldrtn script already copies the necessary files to sqllib/function/
directory (at least on Unix and Linux systems).

bind it to DB2, use it in a procedure I get:
SQL0444N Routine "EMGSYS.PUT_LINE" (specific name "SQL060406131448304")
is
implemented with code in library or path "\put_line", function
"put_line2"
which cannot be accessed. Reason code: "4". SQLSTATE=42724

What does your CREATE FUNCTION statement look like?

The put_line.dll is in sqllib/function directory.
And the create function is like this:
CREATE FUNCTION PUT_LINE(SMALLINT, VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line';

CREATE FUNCTION PUT_LINE(INTEGER, VARCHAR(4000))
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT,VARCHAR(4000));

CREATE FUNCTION PUT_LINE(SMALLINT)
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line1';

CREATE FUNCTION PUT_LINE(INTEGER)
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT);

CREATE FUNCTION PUT_LINE(VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line2';

CREATE FUNCTION PUT_LINE(VARCHAR(4000),VARCHAR(1),VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
SCRATCHPAD
FINAL CALL
EXTERNAL NAME 'put_line!put_line3';

If I recreate the functions with FENCED option then the 32-bit version of
the DLL works, but this is not exactly what I want, since I can bring the
DB2 engine to crash with this version.

Best regards,
Kovi
--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 10 '06 #5

Serge Rielau

Gregor Kovaè wrote:

Knut Stolze wrote:

Gregor Kovaè wrote:

I've got the put_line sources and I want to compile it for a 64-bit DB2
v8.2.
I did compile it with bldrtn, but when I copy it to FUNCTION directory,

The bldrtn script already copies the necessary files to sqllib/function/
directory (at least on Unix and Linux systems).

bind it to DB2, use it in a procedure I get:
SQL0444N Routine "EMGSYS.PUT_LINE" (specific name "SQL060406131448304")
is
implemented with code in library or path "\put_line", function
"put_line2"
which cannot be accessed. Reason code: "4". SQLSTATE=42724

What does your CREATE FUNCTION statement look like?

The put_line.dll is in sqllib/function directory.
And the create function is like this:
CREATE FUNCTION PUT_LINE(SMALLINT, VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line';

CREATE FUNCTION PUT_LINE(INTEGER, VARCHAR(4000))
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT,VARCHAR(4000));

CREATE FUNCTION PUT_LINE(SMALLINT)
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line1';

CREATE FUNCTION PUT_LINE(INTEGER)
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT);

CREATE FUNCTION PUT_LINE(VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line2';

CREATE FUNCTION PUT_LINE(VARCHAR(4000),VARCHAR(1),VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
SCRATCHPAD
FINAL CALL
EXTERNAL NAME 'put_line!put_line3';

If I recreate the functions with FENCED option then the 32-bit version of
the DLL works, but this is not exactly what I want, since I can bring the
DB2 engine to crash with this version.

Just a hunch: Copy the DLL to sqllib\function\unfenced.
What does: echo %DB2PATH% say?
It should point to your sqllib.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Apr 10 '06 #6

Gregor Kovaè

Serge Rielau wrote:

Gregor Kovaè wrote:

Knut Stolze wrote:

Gregor Kovaè wrote:

I've got the put_line sources and I want to compile it for a 64-bit DB2
v8.2.
I did compile it with bldrtn, but when I copy it to FUNCTION directory,
The bldrtn script already copies the necessary files to sqllib/function/
directory (at least on Unix and Linux systems).

bind it to DB2, use it in a procedure I get:
SQL0444N Routine "EMGSYS.PUT_LINE" (specific name
"SQL060406131448304") is
implemented with code in library or path "\put_line", function
"put_line2"
which cannot be accessed. Reason code: "4". SQLSTATE=42724
What does your CREATE FUNCTION statement look like?

The put_line.dll is in sqllib/function directory.
And the create function is like this:
CREATE FUNCTION PUT_LINE(SMALLINT, VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line';

CREATE FUNCTION PUT_LINE(INTEGER, VARCHAR(4000))
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT,VARCHAR(4000));

CREATE FUNCTION PUT_LINE(SMALLINT)
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line1';

CREATE FUNCTION PUT_LINE(INTEGER)
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT);

CREATE FUNCTION PUT_LINE(VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line2';

CREATE FUNCTION PUT_LINE(VARCHAR(4000),VARCHAR(1),VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
SCRATCHPAD
FINAL CALL
EXTERNAL NAME 'put_line!put_line3';

If I recreate the functions with FENCED option then the 32-bit version of
the DLL works, but this is not exactly what I want, since I can bring the
DB2 engine to crash with this version.

Just a hunch: Copy the DLL to sqllib\function\unfenced.
What does: echo %DB2PATH% say?
It should point to your sqllib.

Cheers
Serge

%DB2PATH% = C:\Program Files\IBM\SQLLIB
Copying the DLL into the sqllib\function\unfenced directory returned the
same error. As I said I think that the DLL is not properly compiled.

Best regards,
Kovi

--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 10 '06 #7

Knut Stolze

Gregor Kova� wrote:

Knut Stolze wrote:

Gregor Kova� wrote:

I've got the put_line sources and I want to compile it for a 64-bit DB2
v8.2.
I did compile it with bldrtn, but when I copy it to FUNCTION directory,

The bldrtn script already copies the necessary files to sqllib/function/
directory (at least on Unix and Linux systems).

bind it to DB2, use it in a procedure I get:
SQL0444N Routine "EMGSYS.PUT_LINE" (specific name "SQL060406131448304")
is
implemented with code in library or path "\put_line", function
"put_line2"
which cannot be accessed. Reason code: "4". SQLSTATE=42724

What does your CREATE FUNCTION statement look like?

The put_line.dll is in sqllib/function directory.
And the create function is like this:
CREATE FUNCTION PUT_LINE(SMALLINT, VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line';

CREATE FUNCTION PUT_LINE(INTEGER, VARCHAR(4000))
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT,VARCHAR(4000));

CREATE FUNCTION PUT_LINE(SMALLINT)
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line1';

CREATE FUNCTION PUT_LINE(INTEGER)
RETURNS VARCHAR(1)
SOURCE PUT_LINE(SMALLINT);

CREATE FUNCTION PUT_LINE(VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
EXTERNAL NAME 'put_line!put_line2';

CREATE FUNCTION PUT_LINE(VARCHAR(4000),VARCHAR(1),VARCHAR(4000))
RETURNS VARCHAR(1)
NOT FENCED
RETURNS NULL ON NULL INPUT
NO SQL
DBINFO
EXTERNAL ACTION
LANGUAGE C
PARAMETER STYLE DB2SQL
SCRATCHPAD
FINAL CALL
EXTERNAL NAME 'put_line!put_line3';

If I recreate the functions with FENCED option then the 32-bit version of
the DLL works, but this is not exactly what I want, since I can bring the
DB2 engine to crash with this version.

This I don't understand. If the functions are not properly debugged yet,
you should definitively run them as FENCED. This is a safer thing to do
than NOT FENCED (trusted) functions.

I would now check the following:
(1) My guess would be now that some compiler switch that causes 64-bit code
to be produced doesn't quite work or is not set. On AIX, you would set
"-q64" for the xlC compiler.
How did you build the 32-bit library?
(2) that the db2 instance owner has the necessary privileges to read and
load the DLL.
(3) set the diaglevel to 4, try to call the function on the command line.
Then have a look at the output of "db2diag" to see which messages were
written by DB2. Thus should allow you to narrow down whether the lib
was not found (along with the directories being searched) or if it could
not be loaded.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

Apr 10 '06 #8

Gregor Kovaè

Please see the comments inline.

Knut Stolze wrote:

This I don't understand. If the functions are not properly debugged yet,
you should definitively run them as FENCED. This is a safer thing to do
than NOT FENCED (trusted) functions.

I would now check the following:
(1) My guess would be now that some compiler switch that causes 64-bit
code
to be produced doesn't quite work or is not set. On AIX, you would
set "-q64" for the xlC compiler.
How did you build the 32-bit library?
In using Microsoft Visual Studio 2005. It has three different compilers.
32-bit native compiler, 32-bit compiler that can also produre 64-bit code,
and a 64-bit native compiler. I'm using compiler that runs on 32-bit system
and prodeuces 64-bit code. I'm sure of this.
The 32-bit library already came compiled.
(2) that the db2 instance owner has the necessary privileges to read and
load the DLL.
I'm on Windows logged in as Admninistrator. I've always worked like this and
had no problems before.
(3) set the diaglevel to 4, try to call the function on the command line.
Then have a look at the output of "db2diag" to see which messages were
written by DB2. Thus should allow you to narrow down whether the lib
was not found (along with the directories being searched) or if it
could not be loaded.

After setting diaglevel to 4 I get:

2006-04-10-13.52.52.703000+120 I961F1031 LEVEL: Error
PID : 2128 TID : 3388 PROC : db2bp.exe
INSTANCE: DB2 NODE : 000
APPID : *LOCAL.DB2.060410115224
FUNCTION: DB2 UDB, oper system services, sqlofica, probe:10
DATA #1 : Hexdump, 136 bytes
0x000000000012FB70 : 5351 4C43 4120 2020 8800 0000 44FE FFFF
SQLCA ....D...
0x000000000012FB80 : 3800 454D 4753 5953 2E50 5554 5F4C 494E
8.EMGSYS.PUT_LIN
0x000000000012FB90 : 45FF 5351 4C30 3630 3431 3031 3335 3132
E.SQL06041013512
0x000000000012FBA0 : 3438 3034 FF5C 7075 745F 6C69 6E65 FF70 4804
\put_line.p
0x000000000012FBB0 : 7574 5F6C 696E 6532 FF34 2020 2020 2020 ut_line2.4
0x000000000012FBC0 : 2020 2020 2020 2020 5351 4C45 524C 4942
SQLERLIB
0x000000000012FBD0 : FFFF FFFF 0000 0000 0000 0000 0000
0000 ................
0x000000000012FBE0 : 0000 0000 0000 0000 2020 2020 2020 2020 ........
0x000000000012FBF0 : 2020 2034 3237 3234 42724

I cannot make a lot out of this. The functions are now NOT FENCED as I want
them to be.

Best regards,
Kovi
--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 10 '06 #9

Knut Stolze

Gregor Kova� wrote:

Please see the comments inline.

Knut Stolze wrote:

I would now check the following:
(1) My guess would be now that some compiler switch that causes 64-bit
code
to be produced doesn't quite work or is not set. On AIX, you would
set "-q64" for the xlC compiler.
How did you build the 32-bit library?

In using Microsoft Visual Studio 2005. It has three different compilers.
32-bit native compiler, 32-bit compiler that can also produre 64-bit code,
and a 64-bit native compiler. I'm using compiler that runs on 32-bit
system and prodeuces 64-bit code. I'm sure of this.
The 32-bit library already came compiled.

Ah, so it could still be a compile problem after all. I thought you
compiled it yourself.

(2) that the db2 instance owner has the necessary privileges to read and
load the DLL.

I'm on Windows logged in as Admninistrator. I've always worked like this
and had no problems before.

It doesn't hurt to check the privileges nevertheless.

(3) set the diaglevel to 4, try to call the function on the command line.
Then have a look at the output of "db2diag" to see which messages
were
written by DB2. Thus should allow you to narrow down whether the lib
was not found (along with the directories being searched) or if it
could not be loaded.

After setting diaglevel to 4 I get:

2006-04-10-13.52.52.703000+120 I961F1031 LEVEL: Error
PID : 2128 TID : 3388 PROC : db2bp.exe
INSTANCE: DB2 NODE : 000
APPID : *LOCAL.DB2.060410115224
FUNCTION: DB2 UDB, oper system services, sqlofica, probe:10
DATA #1 : Hexdump, 136 bytes
0x000000000012FB70 : 5351 4C43 4120 2020 8800 0000 44FE FFFF
SQLCA ....D...
0x000000000012FB80 : 3800 454D 4753 5953 2E50 5554 5F4C 494E
8.EMGSYS.PUT_LIN
0x000000000012FB90 : 45FF 5351 4C30 3630 3431 3031 3335 3132
E.SQL06041013512
0x000000000012FBA0 : 3438 3034 FF5C 7075 745F 6C69 6E65 FF70 4804
\put_line.p
0x000000000012FBB0 : 7574 5F6C 696E 6532 FF34 2020 2020 2020 ut_line2.4
0x000000000012FBC0 : 2020 2020 2020 2020 5351 4C45 524C 4942
SQLERLIB
0x000000000012FBD0 : FFFF FFFF 0000 0000 0000 0000 0000
0000 ................
0x000000000012FBE0 : 0000 0000 0000 0000 2020 2020 2020 2020 ........
0x000000000012FBF0 : 2020 2034 3237 3234 42724

I cannot make a lot out of this. The functions are now NOT FENCED as I
want them to be.

Not very helpful, indeed. Take a trace and have a look at it:

$ db2trc on
$ db2 "values <fct>"
$ db2trc dump trc
$ db2trc fmt trc fmt

Have a look at the "fmt" file, search for function "sqloLoadModule". I just
tried it with a non-existing file and there I see "SQLO_FNEX" (file not
exists).

--
Knut Stolze
DB2 Information Integration Development
BM Germany

Apr 10 '06 #10

Udo

You can use the command line program "dumpbin" (part of visiual studio)
to examine the functions in a shared library (windows ddl).

use:

dumpbin /exports <your .dll here>

Regards,
Udo

--
Speedgain for DB2 - The DB2 Monitor
http://www.itgain.de/en/index.html

Apr 10 '06 #11

Gregor Kovaè

Udo wrote:

You can use the command line program "dumpbin" (part of visiual studio)
to examine the functions in a shared library (windows ddl).

use:

dumpbin /exports <your .dll here>

Regards,
Udo

--
Speedgain for DB2 - The DB2 Monitor
http://www.itgain.de/en/index.html

This gives me:
Dump of file PUT_LINE.dll

File Type: DLL

Section contains the following exports for put_line.dll

00000000 characteristics
44352FAC time date stamp Thu Apr 06 17:11:40 2006
0.00 version
1 ordinal base
2 number of functions
2 number of names

ordinal hint RVA name

1 0 0000100A put_line1 = @ILT+
(?put_line1@@YAXPEAFPEAD00QEAD222@Z)

2 1 0000100F put_line2 = @ILT+1
(?put_line2@@YAXPEAD0PEAF1QEAD222@Z
)

Summary

1000 .data
1000 .idata
1000 .pdata
2000 .rdata
1000 .reloc
1000 .rsrc
4000 .text
I hope this means functions put_line1 and put_line2 are exported?

Best regards,
Kovi
--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 10 '06 #12

Udo

And that's the reason...

Yes the functions are exported. But the exported names are "mangled"

See:

http://en.wikipedia.org/wiki/Name_mangling

You have to use the "export C" declaration while using a "c++"
compiler.

Regards,
Udo

--
Speedgain for DB2 - The DB2 Monitor
http://www.itgain.de/en/index.html

Apr 10 '06 #13

Liu Liu

Here is the standand way of doing it:

#ifdef __cplusplus
extern "C" {
#endif

SQL_API_RC SQL_API_FN myproc(....)
{
....
}
#ifdef __cplusplus
}
#endif

The extern C would protect your function name from being mangled by
C++. Also, SQL_API_FN is very important on windows.

Apr 10 '06 #14

Liu Liu

Also, on windows, make sure your sqllib\function is on your system
PATH. An improperly exported symbol should get -444 reason code 6
rather than reason code 4. Reason code 4 usually means DB2 can not find
your library at all.

Apr 10 '06 #15

Gregor Kovaè

Liu Liu wrote:

Here is the standand way of doing it:

#ifdef __cplusplus
extern "C" {
#endif

SQL_API_RC SQL_API_FN myproc(....)
{
...
}
#ifdef __cplusplus
}
#endif

The extern C would protect your function name from being mangled by
C++. Also, SQL_API_FN is very important on windows.

I have done this. I have also specified the put_line.def file that says what
functions are exported. I verified that the sqllib/function is in PATH. I
have SQL_API_FN specified on exported functions, I copied the DLL to
sqllib/functions, but I still get the same error.

--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 10 '06 #16

Udo

>From your previous post:

Dump of file PUT_LINE.dll From your ddl EXTERNAL NAME 'put_line!put_line2';
I think for the windows platform (if you name it ".dll") your
sql-source has to be:
EXTERNAL NAME 'put_line.dll!put_line2';

regards,
Udo

--
Speedgain for DB2 - The DB2 Monitor
http://www.itgain.de/en/index.html

Apr 10 '06 #17

Gregor Kovaè

Udo wrote:

From your previous post:

Dump of file PUT_LINE.dll

From your ddl

EXTERNAL NAME 'put_line!put_line2';

I think for the windows platform (if you name it ".dll") your
sql-source has to be:

EXTERNAL NAME 'put_line.dll!put_line2';

regards,
Udo

--
Speedgain for DB2 - The DB2 Monitor
http://www.itgain.de/en/index.html

It doesn't matter.
--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
| Gregor Kovac | Gr**********@mikropis.si |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

Apr 10 '06 #18