Error running SQLJ.INSTALL_JAR

Paul Reddin

Hi,

(V8.1 FP2)

Trying to run SQLJ.INSTALL_JAR, we get the following error

SQL1131N DARI (Stored Procedure) process has been terminated abnormally.
SQLSTATE=38503

Not sure why this has started failing now (we did upgrade to fp2 fairly
recently, so don't know if there is something that needs rebinding?)

The trouble is, it doesn't log any messages to give us a clue as to
what the internal problem is ?

Can we by-pass this CALL completely by simply manually copying the JAR files into
sqllib/function/jar/INSTANCE

ourselves, or is there something else this Proc. does ?
PS. why is it in schema SQLJ anyway? and why is it not present in SYSCAT.PROCEDURES?

Thanks.

Paul.

Nov 12 '05 #1

Sean McKeough

Ah Paul, so many questions. :-)

Answers inline.

Paul Reddin wrote:

Hi,

(V8.1 FP2)

Trying to run SQLJ.INSTALL_JAR, we get the following error

SQL1131N DARI (Stored Procedure) process has been terminated abnormally.
SQLSTATE=38503

Not sure why this has started failing now (we did upgrade to fp2 fairly
recently, so don't know if there is something that needs rebinding?)

The trouble is, it doesn't log any messages to give us a clue as to
what the internal problem is ? Do you get a trap file in the db2dump directory? If not, can you email
me a server side trace?
Can we by-pass this CALL completely by simply manually copying the JAR files into
sqllib/function/jar/INSTANCE The problem will be that you won't be able to create the procedure using
a jar file in the external name...on the create of a parm style java
stored proc, we acutally validate that the jar entry exists in the
sysjar schemas, and look at the jar for the class that's specified. This
is part of the sqlj part 1 spec (see below).

ourselves, or is there something else this Proc. does ?
PS. why is it in schema SQLJ anyway? and why is it not present in SYSCAT.PROCEDURES? This was done as part of SQLJ part 1 (java standards...see www.sqlj.org
for more info). We can't catalog it because it does funny things to the
sp parameters, such as materializing the first parm (url) into a blob if
the jar file lives on the client system. At some point we want to deploy
a version called db2_install_jar or the like that will take the lob parm
directly, live in the system catalogs, and be compilable etc.

Thanks.

Paul.

Nov 12 '05 #2

Paul Reddin

Some were ponderings rather than questions directly! :-)
- Thanks for all the answers.

- It's great to get immediate feedback on this as it is really
hindering our progress.

We have now solved the problem (to a point).

The issue seems to be that SQLJ.INSTALL_JAR does not work
when we use JDK 1.4.1 (which we need to use for JAVA Regular
Expression support)

So having reset JDK_PATH=/opt/IBMJava2-131, we are able to run
it succesfully!

However, having run successfully, we we now change back to
JDK_PATH=/opt/IBMJava2-141, to be able to run our UDFs, and we get
two dbfmp processes which spin-off running @ 100% CPU and never
come back (query never ends) ???

We know the UDFs work under 1.4.1, as they are runnning fine on
another machine (with JDK_PATH=/opt/IBMJava2-141, which was created
from a backup/restore of the database which is now not working).

So, may be running of INSTALL_JAR with 1.3.1 is not compatible with
actually
running the UDFs with 1.4.1 ??

This is really hurting my head, I thought Java was meant to get away
from all these inter-dependencies, it just seems to be worse! :-(

Thanks again.

Paul.


Sean McKeough <mc******@nospam.ca.ibm.com> wrote in message news:<bo**********@hanover.torolab.ibm.com>...

Ah Paul, so many questions. :-)

Nov 12 '05 #3

Sean McKeough

Paul,

The only thing that we do on install_jar in a db2fmp, is read out this
list of classes for the jar that's being installed. Other than that,
there should be no lingering effect on the system, when the JDK is
changed (unless we somehow got back a bad list of classes with the 1.3
jdk, but I'd find that very surprising)...

Are you _sure_ the JDK is at the same level on both systems (the one
that works, vs this one)? I had seen problems on early jdk levels with
the jvm starting, and to me it sounds like this is what you were seeing
both for the install_jar, and maybe for this hanging problem (hung on a
severe trap?!?)...

BTW, I was able to run install_jar on a windows box, and AIX box with
the IBM 1.4.1 jdks...both the jvm builds were pretty recent. I'm also
aware of a problem with 1.4.1 SUN jvms where poll is being used too
frequently, and the CPU use in idle fmps is high (being investigated by
SUN)...

Paul Reddin wrote:

Some were ponderings rather than questions directly! :-)
- Thanks for all the answers.

- It's great to get immediate feedback on this as it is really
hindering our progress.

We have now solved the problem (to a point).

The issue seems to be that SQLJ.INSTALL_JAR does not work
when we use JDK 1.4.1 (which we need to use for JAVA Regular
Expression support)

So having reset JDK_PATH=/opt/IBMJava2-131, we are able to run
it succesfully!

However, having run successfully, we we now change back to
JDK_PATH=/opt/IBMJava2-141, to be able to run our UDFs, and we get
two dbfmp processes which spin-off running @ 100% CPU and never
come back (query never ends) ???

We know the UDFs work under 1.4.1, as they are runnning fine on
another machine (with JDK_PATH=/opt/IBMJava2-141, which was created
from a backup/restore of the database which is now not working).

So, may be running of INSTALL_JAR with 1.3.1 is not compatible with
actually
running the UDFs with 1.4.1 ??

This is really hurting my head, I thought Java was meant to get away
from all these inter-dependencies, it just seems to be worse! :-(

Thanks again.

Paul.


Sean McKeough <mc******@nospam.ca.ibm.com> wrote in message news:<bo**********@hanover.torolab.ibm.com>...

Ah Paul, so many questions. :-)

Nov 12 '05 #4

Paul Reddin

Sean,

Thanks for the feedback again.

Yesterday, we managed to install the UDFs on yet another Linux Box,
and this worked! i.e install_jar and UDFs both run correctly with
JDK1.4.1

So, out of 4 servers we now have the following:
2 work & 2 don't.

So it is looking like there is a combination of Linux & JVM level that
isn't
working.

Interestingly, the two that work are Single CPU runnning RedHat 7.3,
the two that don't are 2x CPU RedHat AS 2.1.

So, in conclusion, we are investigating the Linux,JVM combinations to
get this working consistently.

Thanks for all your help.

Paul.

Nov 12 '05 #5