| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Fixpack breaking implemented applications |
« View previous topic :: View next topic » |
| Author |
Message
|
| pottas |
 Posted: Wed Nov 04, 2015 12:33 am Post subject: MQ Fixpack breaking implemented applications |
 |
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Hi guys,
I am running the following IIB configuration:
IIB Runtime:
Version: 9001
Product: IBM Integration Bus
CMVC Level: S900-FP01
Build Type: Production, 64 bit, rios_aix_4
We have message flow implemented with the following pattern:
SoapInput Node --> SoapExtract --> Compute --> MQInput Node
So we implemented MQ Fixpack Version: 7.5.0.5, but then our above flows resulted in throwing errors. After investigation, we discovered that we need to explicitly set the MQMD header in the esql source before putting the message to the queue:
| Code: |
| CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD' |
This 'fixed' our errors. Problem is, before the fixpack upgrade, this was working fine. So, the question is, did the fixpack introduce an error to our deployed applications, or did it simply expose an issue we had in our source all along, and we need to correct it? I believe a fixpack shouldn't 'break' something that used to work, and it certainly seems to be the case here.
So our dilemma is, we cannot upgrade to this fixpack before we don't 'fix' the issues as explained above.
Can someone please assist here? |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Nov 04, 2015 12:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5850
Location: UK
|
Why not use a MQHeader node?
What do your messages look like on the output queue (before the fix) - is the MQMD valid?
Always make sure the MQMD.Format field is set properly (usually to MQSTR) and set the required MQMD persistence, CCSID etc.
It's possible the newer MQ is enforcing a proper header, and your code has been wrong all along.
_________________
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 |
|
|
| pottas |
| Posted: Wed Nov 04, 2015 1:03 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Thanks zpat,
Yes, we could use an MQMDHeader Node, we could add the string mentioned to all flows in question, and I am pretty sure we do have some other options as well. And I do accept that it might have been caused by some bad practices all along.
The problem is, something that used to parse and run in the environment is now broken, and it is caused by a fixpack upgrade. What I cannot accept and didn't expect is that a fixpack breaks something that used to work.
So we have no choice than to work through all source to 'fix' all broken applications, which is a monster task, considering our environment runs in excesss of 2000 flows. |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Nov 04, 2015 1:24 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1638
|
The MQOutput node does auto-generate an MQMD if one is not present in the message tree so if the only thing you are doing in your "fix" is to create the MQMD header parser then I'm surprised that this seems to be required as it should not be necessary - and the fact it was working before the update shows this as well. Therefore, a PMR will probably be needed to get to the bottom of this before you go change 2000 flows, but what exactly are the errors you see?
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| timber |
| Posted: Wed Nov 04, 2015 1:26 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1282
|
| Quote: |
| I believe a fixpack shouldn't 'break' something that used to work, and it certainly seems to be the case here. |
It does sound like a change in the default behaviour of the product - something that IBM usually tries very hard to avoid. I think a PMR is justified, if you can prove that this is caused by the MQ fix pack.
I would start by verifying that the message tree being given to the MQOutput node is identical before and after the fix pack is applied. That will rule out any change in IIB behaviour.
IBM service will almost certainly ask you to take an MQ trace of the two scenarios - so you may want to do that proactively. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Nov 04, 2015 1:50 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I have to wonder if this is a case of bad/sloppy code working by default because of 'features' or 'bugs' in one or more of the products.
Then things stop working when said feature is rectified.
Properly setting the MQMD is IMHO best practice. All my flows do it in ESQL because we want to set some features that are under control of the flow configuration. You can't do that in the MQHeader node.
Thankfully, a common PROCEDURE does it all for us.
We have migrated most of our sites from MQ6/Broker V6.1.0.3 or MQ7/Broker 7.0.0.4 to MQ 8.0.0.3/IIB9.0.0.3 without encountering any of these sort of problems. I guess we were lucky.
YMMV though
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| pottas |
| Posted: Wed Nov 04, 2015 2:19 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Thanks for all the replies, we will do as advised, get the traces done, log a PMR.
smdavies99,
Thanks also for your response, I do agree with you, it most probably is sloppy code causing it, but how do you get someone that left the organisation to fix his/her mess in this case when a fixpack exposes the issue well after he or she have moved on?
So, I am one of the guys left to try and resolve this, I am on the spot trying to get things in working order again.
I still question why would a sloppy programmer not go ahead implementing this if nothing in the parsing/build or in runtime restricts him to go ahead and implement this kind of code, just for a fixpack to expose it way later. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 04, 2015 2:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5850
Location: UK
|
The default MQMD value of none for MQMD.Format is probably the single most annoying default in the history of MQ.
So many problems are caused by this (e.g. data conversion). Always set it (to MQSTR or MQHRF2 in 99.99% of cases).
Does your problem happen with IIB 9.0.0.4 because you might as well try that before opening a PMR?
_________________
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
