By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,391 Members | 1,387 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,391 IT Pros & Developers. It's quick & easy.

Problems debugging Java Stored Procedures in V7.2 FP9 (WinXP)

P: n/a
I've spent the last couple of hours trying to figure out how to debug a Java
stored procedure and am just going in circles. The last straw came when I
got "Cannot open input stream for default" when I launched the IBM
Distributed Debugger via
D:\IBMDebug>idebug.exe -qdaemon -quiport=8000,8001

First, a bit of background.

I am running DB2 V7.2 with Fixpack 9 applied on Windows XP Professional (all
critical service applied). I've written a Java stored procedure that is
giving me a CLI0111 error. Unfortunately, the CLIxxxx errors are very vague.
The db2diag.log is a little more helpful:

2004-01-27-17.35.27.804000 Instance:DB2 Node:000
PID:3224(db2dari.exe) TID:4080 Appid:
BSU Java support sqlejNMstp_setBigDecimal Probe:40

Invalid null BigDecimal given.

I only have a couple of lines of code that involve BigDecimals but I've
looked at the code and I can't see anything wrong with it. I thought I'd try
debugging to see if I could nail the problem.

I tried debugging via the Stored Procedure Builder, which is where I wrote
the procedure. After considerable poking around, I was unable to get the
"Build for Debug" menu option to work, even though I had "Build for Debug"
checked in the wizard when I built the stored procedure. This option is also
turned on in the properties for the procedure.

After reading the Help and Google posts on this subject, I read that Java
stored procedures can *not* be debugged in the Stored Procedure Builder. Did
I misread that or is that true?

Anyway, I read that I should get and use the IBM Distributed Debugger so I
downloaded and installed V9.2, which is described as being for DB2 V8.1 in
the hopes that it would still work with DB2 V7.2 FP9.

Unfortunately, when I ran "idebug.exe -qdaemon -quiport=8000,8001" on my
command line, a message in the command window said "Cannot open input stream
for default". A simple dialog that said "Listening to port(s): 8001,8000"
also poppsed up so I took the chance that maybe the error was not
significant. I started the Stored Procedure Builder but I still can't "Build
for debug".

I can't even find the IBM Distributed Debugger under Start/Programs and
there is no icon or help for it anywhere that I can see. All I can find is
the README but it says nothing about this. I suspect some kind of
installation/configuration problem - I'm not great at
installing/configuring! - but I can't figure out how to get past this. I
couldn't find a single post on any newsgroup that mentioned this problem -
and darn few about the IBM Distributed Debugger at all.

I tried db2 force applications all/db2stop/db2start in the hope that this
would fix things up but no luck. The DB2ROUTINE_DEBUG environment variable
is set to ON and DB2_USE_JDK12 is set to YES. The db2dbg table and view are
present and populated. I have SYSADM authority. I am trying to debug a
stored procedure on a standalone machine so it might seem strange to use a
distributed debugger but I really don't need a distributed debugger: I just
need something/anything that I can use to debug a Java stored procedure. I
need to be able to step through my stored procedure and watch the variable
values change.

Can anyone tell me how to get past my problem?

--

Rhino
---
rhino1 AT sympatico DOT ca
"If you want the best seat in the house, you'll have to move the cat."
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I managed to get the "Cannot open input stream for default" message from the
IBM Distributed Debugger to go away - all it took was a simple reboot of
Windows. However, I still can't get the debugger to do anything and, worse
yet, I can't get any of my Java stored procedures to run at all now, let
alone debug!

I'm getting SQL4301N, Reason Code "4".

I've researched this in Google and seen only one thread where Reason Code
"4" occurred - the other Reason Codes seems to happen a lot more - but I
think I've done everything suggested in that thread and still no luck.

Here are the relevant settings from my system:
JDK11_PATH = c:\Program Files\SQLLIB\java\java12\jdk
DIAGLEVEL = 4
JAVA_HEAP_SZ = 4096
KEEPDARI = YES

DB2_USE_JDK12=YES
DB2ROUTINE_DEBUG=ON

There has been a lot more detail written to my db2diag.log since I set
DIAGLEVEL to 4 but I don't know what to look for and don't want to put
hundreds of lines on the log in a newsgroup post if I can avoid it.

Can anyone suggest what I need to do to get my Stored Procedures to run
again?

And for the bonus prize, does anyone know what I need to do to make the
debugger actually launch itself after it tells me that it is listening on
ports 8000 and 8001? The Build For Debug option is still greyed out in the
Stored Procedure Builder and I still can't find any documentation on how to
make the debugger do its thing.

Rhino

"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message
news:9L*******************@news20.bellglobal.com.. .
I've spent the last couple of hours trying to figure out how to debug a Java stored procedure and am just going in circles. The last straw came when I
got "Cannot open input stream for default" when I launched the IBM
Distributed Debugger via
D:\IBMDebug>idebug.exe -qdaemon -quiport=8000,8001

First, a bit of background.

I am running DB2 V7.2 with Fixpack 9 applied on Windows XP Professional (all critical service applied). I've written a Java stored procedure that is
giving me a CLI0111 error. Unfortunately, the CLIxxxx errors are very vague. The db2diag.log is a little more helpful:

2004-01-27-17.35.27.804000 Instance:DB2 Node:000
PID:3224(db2dari.exe) TID:4080 Appid:
BSU Java support sqlejNMstp_setBigDecimal Probe:40

Invalid null BigDecimal given.

I only have a couple of lines of code that involve BigDecimals but I've
looked at the code and I can't see anything wrong with it. I thought I'd try debugging to see if I could nail the problem.

I tried debugging via the Stored Procedure Builder, which is where I wrote
the procedure. After considerable poking around, I was unable to get the
"Build for Debug" menu option to work, even though I had "Build for Debug"
checked in the wizard when I built the stored procedure. This option is also turned on in the properties for the procedure.

After reading the Help and Google posts on this subject, I read that Java
stored procedures can *not* be debugged in the Stored Procedure Builder. Did I misread that or is that true?

Anyway, I read that I should get and use the IBM Distributed Debugger so I
downloaded and installed V9.2, which is described as being for DB2 V8.1 in
the hopes that it would still work with DB2 V7.2 FP9.

Unfortunately, when I ran "idebug.exe -qdaemon -quiport=8000,8001" on my
command line, a message in the command window said "Cannot open input stream for default". A simple dialog that said "Listening to port(s): 8001,8000"
also poppsed up so I took the chance that maybe the error was not
significant. I started the Stored Procedure Builder but I still can't "Build for debug".

I can't even find the IBM Distributed Debugger under Start/Programs and
there is no icon or help for it anywhere that I can see. All I can find is
the README but it says nothing about this. I suspect some kind of
installation/configuration problem - I'm not great at
installing/configuring! - but I can't figure out how to get past this. I
couldn't find a single post on any newsgroup that mentioned this problem -
and darn few about the IBM Distributed Debugger at all.

I tried db2 force applications all/db2stop/db2start in the hope that this
would fix things up but no luck. The DB2ROUTINE_DEBUG environment variable
is set to ON and DB2_USE_JDK12 is set to YES. The db2dbg table and view are present and populated. I have SYSADM authority. I am trying to debug a
stored procedure on a standalone machine so it might seem strange to use a
distributed debugger but I really don't need a distributed debugger: I just need something/anything that I can use to debug a Java stored procedure. I
need to be able to step through my stored procedure and watch the variable
values change.

Can anyone tell me how to get past my problem?

--

Rhino
---
rhino1 AT sympatico DOT ca
"If you want the best seat in the house, you'll have to move the cat."

Nov 12 '05 #2

P: n/a
In article <qp********************@news20.bellglobal.com>, Rhino
(rh****@NOSPAM.sympatico.ca) says...
I managed to get the "Cannot open input stream for default" message from the
IBM Distributed Debugger to go away - all it took was a simple reboot of
Windows. However, I still can't get the debugger to do anything and, worse
yet, I can't get any of my Java stored procedures to run at all now, let
alone debug!

I'm getting SQL4301N, Reason Code "4".

I've researched this in Google and seen only one thread where Reason Code
"4" occurred - the other Reason Codes seems to happen a lot more - but I
think I've done everything suggested in that thread and still no luck.

Here are the relevant settings from my system:
JDK11_PATH = c:\Program Files\SQLLIB\java\java12\jdk
DIAGLEVEL = 4
JAVA_HEAP_SZ = 4096
KEEPDARI = YES

DB2_USE_JDK12=YES
DB2ROUTINE_DEBUG=ON

There has been a lot more detail written to my db2diag.log since I set
DIAGLEVEL to 4 but I don't know what to look for and don't want to put
hundreds of lines on the log in a newsgroup post if I can avoid it.

Can anyone suggest what I need to do to get my Stored Procedures to run
again?

And for the bonus prize, does anyone know what I need to do to make the
debugger actually launch itself after it tells me that it is listening on
ports 8000 and 8001? The Build For Debug option is still greyed out in the
Stored Procedure Builder and I still can't find any documentation on how to
make the debugger do its thing.

Rhino


Well, I never worked with the debugger but reading your post I would
check if a local firewall could be blocking the ports (maybe the XP
built-in firewall?)
Another problem could be the space in the JDK11_PATH variable but
that's just a guess.

Hope this helps.
Nov 12 '05 #3

P: n/a
Thanks Gert but I'm pretty sure that the blank in the JDK path name is not
the problem. I changed the JDK path to that setting days ago and it didn't
seem to hurt anything.

I'm going to investigate the XP firewall now to see if it might be the
problem. Perhaps it is blocking port 8000 or 8001 for some reason.

I've just stumbled on some additional clues in this mystery. I tried running
each of my stored procs in the Stored Procedure Builder. None of them
worked: all failed on SQL4301 Reason Code 4. I tried building a new one and
running it and it worked! I tried rebuilding one of my old ones and suddenly
it worked too! In fact, each of my old ones will work if I rebuild it first.
However, it will only run *once*: if I rebuild it, the first run after that
works fine but the second run produces SQL4301 Reason Code 4. That means I
have to rebuild it before each and every run.

I'm not sure what that is saying about the underlying problem but maybe
someone there with more insight into the inner workings of stored procedures
might have an idea.

It also gets me out of the ditch somewhat; at least I can run my stored
procedures now. But that is just a workaround. I really want my stored
procedures to work without having to rebuild them each time.

Any ideas anyone?

Rhino

"Gert van der Kooij" <ge**@invalid.nl> wrote in message
news:MP************************@news.xs4all.nl...
In article <qp********************@news20.bellglobal.com>, Rhino
(rh****@NOSPAM.sympatico.ca) says...
I managed to get the "Cannot open input stream for default" message from the IBM Distributed Debugger to go away - all it took was a simple reboot of
Windows. However, I still can't get the debugger to do anything and, worse yet, I can't get any of my Java stored procedures to run at all now, let
alone debug!

I'm getting SQL4301N, Reason Code "4".

I've researched this in Google and seen only one thread where Reason Code "4" occurred - the other Reason Codes seems to happen a lot more - but I
think I've done everything suggested in that thread and still no luck.

Here are the relevant settings from my system:
JDK11_PATH = c:\Program Files\SQLLIB\java\java12\jdk
DIAGLEVEL = 4
JAVA_HEAP_SZ = 4096
KEEPDARI = YES

DB2_USE_JDK12=YES
DB2ROUTINE_DEBUG=ON

There has been a lot more detail written to my db2diag.log since I set
DIAGLEVEL to 4 but I don't know what to look for and don't want to put
hundreds of lines on the log in a newsgroup post if I can avoid it.

Can anyone suggest what I need to do to get my Stored Procedures to run
again?

And for the bonus prize, does anyone know what I need to do to make the
debugger actually launch itself after it tells me that it is listening on ports 8000 and 8001? The Build For Debug option is still greyed out in the Stored Procedure Builder and I still can't find any documentation on how to make the debugger do its thing.

Rhino


Well, I never worked with the debugger but reading your post I would
check if a local firewall could be blocking the ports (maybe the XP
built-in firewall?)
Another problem could be the space in the JDK11_PATH variable but
that's just a guess.

Hope this helps.

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.