×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Check via the verbose command which JVM you are using. It may be that
the default JVM is still pointing to an earlier version, and therefore
using /lib jars from the earlier version.
Regards
John Herbert
------------------------------
message: 5
date: Tue, 3 Feb 2009 09:49:53 +0000
from: NGay@xxxxxxxxxxxxx
subject: Does the iSeries somehow cache JAR files?
Hi all,
I don't ask for help too often but this one really has me stumped.
We've
just upgraded from WebSphere MQ 5.3 to 7.0 (immediately after from i5/OS
V5R3 to V6R1, so its possible that's related but I don't believe so).
Java programs attempting to read from our MQ queues no longer work,
returning a reason code 2139 which the help text for mentions the *wrong
version* of a certain data structure. However what has me really
puzzled
is that fact that the code is able to throw an MQException at all,
because
in 7.0 the com.ibm.mq.MQException class has moved from the
com.ibm.mq.jar
file (which IS in the classpath) to com.ibm.mq.jmqi.jar (which ISN'T in
the
classpath).
And so I started experimenting a bit - creating a tiny test class which
creates + outputs a MQException - sure enough if I omit
/QIBM/ProdData/mqm/java/lib/com.ibm.mq.jar from the classpath it cannot
find MQException, but if I include that JAR in the classpath it is able
to
find the class. Yet if I copy that JAR off the iSeries, rename it to a
zip
and examine it, I can prove for certain that the class is NOT inside
that
JAR.
My only conclusion is that its somehow still using the old MQ 5.3 JAR -
that seems consistent with the 2139 error code - if its using old code
then
a "wrong version" error makes perfect sense.
I've tried deleting the JAR and copying on the same JAR from a Windows
MQ
7.0 installation. I've tried forcing a CRTJVAPGM on it. I've even
forced
the created/modified by date on the JAR to today's date, in case this
would
make something realise there's a newer version of the JAR. But all come
up
with the same result.
Does anyone have any suggestions? Am I being stupid and missing
something
obvious here? Thanks all!
Nigel Gay,
Computer Patent Annuities.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.