| Author |
Message
|
| belchman |
 Posted: Wed Jun 22, 2011 9:32 am Post subject: Old MQ Java Jars againt MQv7 server |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
I know, but you are preaching to the choir but I hope you will assist me here anyway.
We have a boatload of remote (all internal to internal MQ servers) MQ client apps that are java clients that wrapped and compiled MQ java lib members way back in 1997.
Snippet from one of the decompiled classes:
private static final String sccsid = "@(#) lib/wmq/java/com/ibm/mq/MQGetMessageOptions.java, java, p000, p000-L980818 98/07/07 14:35:33";
So I presume that is v5.2 or 5.3 java code 
Now when I try to upgrade MQ server from v6.* to v7.*, they get an MQRC 2186 at runtime. The class I decompiled was "public class MQGetMessageOptions" for obvious reasons.
Do any of you folks have any suggestions for me to get past this barrier:
Some of my thoughts:
1) If they insist on using those old jars, make them have/fund a local queue manager that is v6.* so they still work
2) Make them change their code so that it uses the java libs on the host instead of those they deploy
3) Aid and abet their malfeasance by helping them compile some more modern classes
I started here in 2005 and this stuff was here when I arrived. It is in prod and is everywhere. Now that it is in prod, it is hard to eliminate.
I would really appreciate any guidance you folks may have to offer here.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jun 22, 2011 9:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So these java apps are packaged in jar files with MQ Jars?
Or are the MQ Jars external?
In theory, you should be able to simply keep using the old MQ jar files with this code, and it should just "work", in that in theory a v5.2 client is supposed to be able to connect to a v7 qmgr (backwards compatible).
But if you need to change these apps to use MQ v7 features, you need to start from scratch. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 22, 2011 9:40 am Post subject: Re: Old MQ Java Jars againt MQv7 server |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| belchman wrote: |
1) If they insist on using those old jars, make them have/fund a local queue manager that is v6.* so they still work
2) Make them change their code so that it uses the java libs on the host instead of those they deploy
3) Aid and abet their malfeasance by helping them compile some more modern classes |
Obviously option 1 is more of a holding action & you'll become more and more exposed as v6.* goes further and further out of support.
Option 3, which I take to mean wrapping the code with more modern jars, is likewise a holding action. But with a much longer time before problems are likely to be experienced. So viable depending on your career plans and how long to plan/expect to be at that site.
(Ohio? Large site in Columbus?)
Option 2, as has been discussed many times in here, is the best way to go but requires a sea change in how the apps work. You may encounter developer resistance as the little dears seem to be afraid of files not under their control. A common occurance and the reason for the many debates in here regarding jar files & their use.
My personal view, other opinions may be equally valid.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| belchman |
| Posted: Wed Jun 22, 2011 9:49 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Jeff,
I am unsure how to answer your question.
They have a set of libraries that they deploy as part of their app as 'ibm_mq.jar' that has a bunch of classes in it from (I assume) the stone age. I decompiled one of them to get the 1998 date. I assume the others are the same.
I am unsure of which of these are special classes they wrote that call IBM provided classes that they just moved into the jar and deployed.
They have an app that is running on the same host that is using the content within the jar.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 22, 2011 9:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| belchman wrote: |
| I am unsure of which of these are special classes they wrote that call IBM provided classes that they just moved into the jar and deployed. |
IMHO there's too much black magic in this set up, where they have jar files written in the old days by the ancestors that provide the sacred WMQ functionality.
(Face it, if you have to decompile the thing to get a date out it's insufficiently documented)
If you don't know how this is working, and they can't explain how they work it, rip it out and use the jar files you supply as WMQ admin via the install.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| belchman |
| Posted: Wed Jun 22, 2011 9:57 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Vitor,
I prefer option 2 myself.
I just do not know how much effort is required by the applications to get their stuff changed to use the IBM code in the MQ client that is installed on the host.
On this particular host, I assume we have n+1 copies of say MQGetMessageOptions.class where n = the number of MQ consuming applications. The 1 in the equation is the unused file in the /opt/mqm/java/lib(64) directories as put there via a legitimate MQ client install.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 22, 2011 11:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| belchman wrote: |
| I just do not know how much effort is required by the applications to get their stuff changed to use the IBM code in the MQ client that is installed on the host. |
And is that more or less effort than replacing the old jars with the new jars as per option 3?
It's a question only the developers can answer.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jun 22, 2011 11:20 am Post subject: Re: Old MQ Java Jars againt MQv7 server |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| belchman wrote: |
98/07/07 14:35:33
So I presume that is v5.2 or 5.3 java code |
That datestamp pre-dates MQSeries V5.1.
| Quote: |
| 2) Make them change their code so that it uses the java libs on the host instead of those they deploy |
That would be the "official" best option. More admin effort required to deploy the app, but then you get permanently out of this particular problem. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Jun 23, 2011 4:15 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Thanks for all of you input everyone. I will let you know how this is resolved.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 23, 2011 4:43 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
This sounds like the apps were compiled with the MQ jar files from the old MA88 Support Pack. Back then that was the official way to do MQ Clients and Java .
I agree with mvic, that is way old, pre 5.1. Having said that, they should work against an MQ 7 QM.
The long term plan should be to install MQ 7 client on the machines and have them reference those jar files. Installing the full MQ client just to get a couple of jar files will make the Java purists howl. MA88, just the jars and nothing but the jars ma'am, was ideal in this sense.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| belchman |
| Posted: Mon Jun 27, 2011 5:21 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
It appears that there were no application specific changes in the 'ibm_mq.jar' file that was deployed with the application. We modified a copy of /opt/mqm/java/lib/com.ibm.mq.jar (we did not change this one) by renaming it to 'ibm_mq.jar' and the application seems to be working OK.
They will be doing more testing on this.
Meanwhile, I will see if there is a way to have it that all WebLogic apps on this host use /opt/mqm/java/lib - or- /opt/mqm/java/lib64 to eliminate the performance of the 'create ibm_mq.jar' step.
More to follow
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Fri Jul 01, 2011 3:26 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
I am going this route on this:
Create a symbolic link as
ln -s /opt/mqm/java/lib/com.ibm.mq.jar ./mqjava in the application's directory and add mqjava to the application's classpath
Regards,
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jul 01, 2011 3:52 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| belchman wrote: |
| ln -s /opt/mqm/java/lib/com.ibm.mq.jar ./mqjava |
Why ./ rather than a fully qualified path? |
|
| Back to top |
|
|
| belchman |
| Posted: Fri Jul 01, 2011 4:00 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Because in my case, at this time, until I know better, I am creating the mqjava symbolic in each application's install directory. That way I can control the speed at which I cut them over.
The command for creating the link was executed in this one particular application's install directory
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
|
|
