COM.ibm.db2os390.sqlj.jdbc.DB2SQLJDriver is for applications running on an OS390 or zOS system
You'll have to use COM.ibm.db2.jdbc.net.DB2Driver - this is a type 3 driver for use with applets. If you are writing a Java application you'll have to use the type 2 driver - COM.ibm.db2.jdbc.app.DB2Driver.
And, yes, you'll have to catalog the os390 system as a DCS database.
Thanks for your reply.According to your point problem in the bind step , But while binding time it's completed successfully and also calling the procedure from DB2DC running fine. but it did not shown SQL query output.
I could not under stand why it's refere SYSSTAT package my actual package TEST01.
in bind statement BIND PLAN(TEST01) PKLIST(TEST01.*,DSNJDBC.*)
EXTERNAL NAME 'DB2ADM.TEST01_JAR:TEST01.Test01.GetTest01'
if my bind step processes wrong means What could be correct step..?
When a connection is made from a remote system DB2 uses plan DISTSERV - that's why it appears as part of the message tokens. A plan named TEST01 has nothing to do with this situation.
If you break out the message tokens you'll see that they contain a fully qualified package name and reason code 02. If you read the zOS messages and codes (because that's where the error is occuring) you'll see that it means "The DBRM name 'dbrm-name' did not match an entry in the member list or the package list." In this situation the plan pklist is immaterial - the code has issued
SET PACKAGESET = 'TEST01'
and so collid TEST01 is being used.
What you need to look for is the command
BIND PACKAGE(TEST01) MEMBER(SYSSTAT) ...
(or BIND PACKAGE(TEST01) COPY(collid.SYSSTAT) )
DB2 is complaining because this hasn't been done successfully. SYSSTAT is probably some system package.
I am wondering if you are calling a host based Java stored procedure, in whose definition you specified
In this situation TEST01 is a collection id, not a plan name. In my brief experience with zOS Java SPs I found that I needed to bind copy everything from collection DSNJDBC into the "other" collection if I did this.