| Author |
Message
|
| zpat |
 Posted: Thu Oct 03, 2019 10:25 pm Post subject: A tale of two WAS servers |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
WAS 7.0.0.43 contains MQ client 7.0.1.14
The channel status of a svrconn channel from this WAS to a QM confirm this version of MQ client in the RVERSION field.
However another WAS server at the same version of WAS connects and the svrconn channel status shows garbage characters in the RVERSION and RPRODUCT fields.
This suggests to me that old, buggy MQ jars are lurking around and have been incorporated into the application release somehow. These are being used for the connection in place of the proper WAS supplied MQ client.
However the support team can't find these other java classes - any clues on what they should look for and how/where to find them?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| abhi_thri |
| Posted: Fri Oct 04, 2019 1:56 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
hi...does RAPPLTAG display anything, usually it displays the application name and if you are lucky the jar file path (at least for jboss).
Also if all WAS processes are running using a WAS app id you could try listing all processes running as that app id on the client server...which should hopefully list out all WAS processes which usually will also have the config file paths used by those processes and then you can search for jar files in those folders.
Also is it not possible to do a global search for all *.jars configured on the client server via some global search or so (eg: 'find' in linux) which should then tell you the path where the MQ jars are deployed. Alternatively i think if it is known that WAS are using xml config files (or *.properties etc) to specify the MQ jars you could run targeted search (ie search for occurrences of '.jar' in *.xml files on the client server) |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Oct 04, 2019 4:22 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
It WAS the best of times, it WAS the worst of times . . .
What platform is WAS running on? For example if it is Linux, you could use lsof to see what open files the WAS process is referencing. If it is Windows, you could use ProcessExplorer. Each platform usually has a tool like this to inspect the open files of a process.
_________________
Working with MQ since 2010.
Last edited by tczielke on Fri Oct 04, 2019 6:22 am; edited 1 time in total |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 04, 2019 5:59 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Linux is the platform.
I don't have direct access to the host, but I can convey these suggestions to those who do - thanks.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 04, 2019 5:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 04, 2019 6:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| tczielke wrote: |
It WAS the best of times, it WAS the worst of times . . .
|
Yes, that is very apt ... 
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Sun Oct 06, 2019 11:47 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
Do both WAS use the same SVRCONN channel?
If not, what's the value of SHARECNV?
_________________
Regards
Hubert |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Oct 07, 2019 11:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
They are attaching to different QMs. But the channel definition is the same and has a sharecnv value of 10.
RAPPLTAG just says "Websphere MQ client for java"
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Oct 08, 2019 12:21 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| zpat wrote: |
They are attaching to different QMs. But the channel definition is the same and has a sharecnv value of 10.
RAPPLTAG just says "Websphere MQ client for java" |
I think this is always the same for MQv7 clients - IMHO this changed in version 8 or so, that the RAPPLTAG does contain some more detailed information about the Java App.
Did you check (and compare) the CLASSPATH parameter? May be there is an additional path with additional (corrupted?) JARs?
Did you compare the JAR files?
To find the JARs they could search with
| Code: |
| find / -name "*com.ibm.mq.*.jar" 2>/dev/null |
_________________
Regards
Hubert |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 11, 2019 11:24 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
This tale has a curious ending.
Turns out the "garbage" characters for RVERSION and RPRODUCT were actually ASCII characters being displayed as EBCDIC on the z/OS QM 7.1, after upgrading to z/OS MQ 9.0 the fields displayed correctly.
Very odd, especially as there is an APAR for something similiar with Omegamon
https://www-01.ibm.com/support/docview.wss?uid=swg1OA56988
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
