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

logging output

P: n/a
Hi there,

I'm trying to track down the log file into which the following failure
will be written.

---
SQL4302N Procedure or user-defined function
"SRCPROD.PRO_GENERATE_GROUP_EVENTS", specific name
"JDBC_GEN_GROUP_EVENTS"
aborted with an exception "[IBM][CLI Driv".
---

I've checked the db2diag.log on my linux box but the error isn't
written to it - I presume because it occurs before entering the custom
Java SP. Alternatively, is there a way to stop DB2 truncating the
error messages before they become useful?

I've got a windows box at work and linux box at home so logging
locations for both would be helpful, please.

Cheers

Michael

Apr 2 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Kenevel wrote:
Hi there,

I'm trying to track down the log file into which the following failure
will be written.

---
SQL4302N Procedure or user-defined function
"SRCPROD.PRO_GENERATE_GROUP_EVENTS", specific name
"JDBC_GEN_GROUP_EVENTS"
aborted with an exception "[IBM][CLI Driv".
---

I've checked the db2diag.log on my linux box but the error isn't
written to it - I presume because it occurs before entering the custom
Java SP. Alternatively, is there a way to stop DB2 truncating the
error messages before they become useful?

I've got a windows box at work and linux box at home so logging
locations for both would be helpful, please.
The stack traceback is written to the db2diag.log (or better yet, use
the "db2diag" tool). What may have happened is that you set your DBM CFG
parameter DIAGLEVEL to a value where such information is not logged at all.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Apr 2 '07 #2

P: n/a
On 2 Apr, 10:58, Knut Stolze <sto...@de.ibm.comwrote:
>
The stack traceback is written to thedb2diag.log (or better yet, use
the "db2diag" tool). What may have happened is that you set your DBM CFG
parameter DIAGLEVEL to a value where such information is not logged at all.
Hi Knut,

Thanks for your reply. I haven't touched the DIAGLEVEL variable so
when DB2 stopped writing error messages to the db2diag.log I presumed
it was because the error occurred not in the user-space (ie because
I'd written some duff code) but rather because of a system problem (as
it turned out, a NoClassDefFoundError). I reasoned that this latter
type of error was being written elsewhere.

Anyway, my immediate problem has been resolved but I would still be
interested to know why output to the db2diag.log (on linux) stopped as
it did.

Cheers

Michael
Apr 3 '07 #3

P: n/a
Kenevel wrote:
Anyway, my immediate problem has been resolved but I would still be
interested to know why output to the db2diag.log (on linux) stopped as
it did.
Which entries/records do you see in the db2diag.log around the time when the
java stack traceback should have been recorded?

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Apr 3 '07 #4

P: n/a
On 3 Apr, 15:25, Knut Stolze <sto...@de.ibm.comwrote:
>
Which entries/records do you see in thedb2diag.log around the time when the
java stack traceback should have been recorded?
Hi Knut,

I can't say for sure - I'd have to go back through the log and try to
estimate when I was doing the testing. However, I can say that the
DIAGLEVEL value was set to 3, which I've incremented to 4. Even though
I've done that all I now get after a Java error is the following (you
can see the interesting part of the Java stack trace is truncated!!):

2007-04-03-21.22.17.476056+060 I180277G841 LEVEL: Info
PID : 11261 TID : 2988402352 PROC : db2agent
(SRC_PROD)
INSTANCE: michaelg NODE : 000 DB : SRC_PROD
APPHDL : 0-7 APPID: *LOCAL.michaelg.070403192905
AUTHID : MICHAELG
FUNCTION: DB2 UDB, oper system services, sqlofica, probe:10
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -4302 sqlerrml: 70
sqlerrmc: MICHAELG.PRO_GENERATE_GROUP_EVENTS JDBC_GEN_GROUP_EVENTS
[IBM][CLI Dri
sqlerrp : SQLEJEXT
sqlerrd : (1) 0x00000000 (2) 0x00000000 (3) 0x00000000
(4) 0x00000000 (5) 0x00000000 (6) 0x00000000
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:

Apr 3 '07 #5

P: n/a
Kenevel wrote:
On 3 Apr, 15:25, Knut Stolze <sto...@de.ibm.comwrote:
>>
Which entries/records do you see in thedb2diag.log around the time when
the java stack traceback should have been recorded?

Hi Knut,

I can't say for sure - I'd have to go back through the log and try to
estimate when I was doing the testing. However, I can say that the
DIAGLEVEL value was set to 3, which I've incremented to 4. Even though
I've done that all I now get after a Java error is the following (you
can see the interesting part of the Java stack trace is truncated!!):

2007-04-03-21.22.17.476056+060 I180277G841 LEVEL: Info
PID : 11261 TID : 2988402352 PROC : db2agent
(SRC_PROD)
INSTANCE: michaelg NODE : 000 DB : SRC_PROD
APPHDL : 0-7 APPID: *LOCAL.michaelg.070403192905
AUTHID : MICHAELG
FUNCTION: DB2 UDB, oper system services, sqlofica, probe:10
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -4302 sqlerrml: 70
sqlerrmc: MICHAELG.PRO_GENERATE_GROUP_EVENTS JDBC_GEN_GROUP_EVENTS
[IBM][CLI Dri
sqlerrp : SQLEJEXT
sqlerrd : (1) 0x00000000 (2) 0x00000000 (3) 0x00000000
(4) 0x00000000 (5) 0x00000000 (6) 0x00000000
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:
That's all there is? Or do you have other entries before/after that one? I
believe you do; otherwise you wouldn't know that the stack trace is
truncated...

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Apr 5 '07 #6

P: n/a
On 5 Apr, 07:31, Knut Stolze <sto...@de.ibm.comwrote:
>
That's all there is? Or do you have other entries before/after that one? I
believe you do; otherwise you wouldn't know that the stack trace is
truncated...
Of course, you're right: there are loads more entries in the
db2diag.log file, but I didn't see the need to post the whole log to
the group. My point was that the interesting bit of that log-file
entry (the Java stack-trace) was truncated. Anyway, that seems to have
been related to a linux write-permission issue - there were entries in
my username.nfy file saying that it couldn't be opened for writing.
However, other entries were still being added so I guess a process
with the right permissions was still able to access it, while another
one wasn't. Is that the case?

I deleted the db2diag.log file and let DB2 recreate it, and it seems
to be working again. I'll check again when I'm at the Linux box.

Cheers Knut,

Michael

Apr 5 '07 #7

P: n/a
Kenevel wrote:
On 5 Apr, 07:31, Knut Stolze <sto...@de.ibm.comwrote:
>>
That's all there is? Or do you have other entries before/after that one?
I believe you do; otherwise you wouldn't know that the stack trace is
truncated...

Of course, you're right: there are loads more entries in the
db2diag.log file, but I didn't see the need to post the whole log to
the group.
I wasn't asking for the whole log - just for the entries near the time where
you saw the Java error.
My point was that the interesting bit of that log-file
entry (the Java stack-trace) was truncated. Anyway, that seems to have
been related to a linux write-permission issue - there were entries in
my username.nfy file saying that it couldn't be opened for writing.
However, other entries were still being added so I guess a process
with the right permissions was still able to access it, while another
one wasn't. Is that the case?
Unless you have a strange configuration (what's your fenced userid?), you
shouldn't see such problems.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Apr 5 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.