| Author |
Message
|
| sumit |
 Posted: Fri Dec 27, 2013 1:03 am Post subject: FP3 and FP2 compatibility on WMB8 |
 |
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Hi All,
Environment
OS- Linux
MB - v8 with FP3 (WMB8.0.0.3)
Story till now,
1. A flow built on Toolkit (and broker) version 8.0.0.2 has mainflow and subflow
2. Record and replay monitoring is enabled at both mainflow and subflow level.
3. Bar file created and deployed. The flow is working fine, all monitoring events getting recorded... happy scenario.
4. Installed FP3 on the broker and now the current broker version is 8.0.0.3
5. 2 person (personA and personB), personA still using Toolkit 8.0.0.2 and personB ungrades the toolkit to 8.0.0.3.
6. personA takes the original bar file (as created in pt3) on his 8.0.0.2 toolkit and deploys the flow on a different broker instance running on 8.0.0.3 (linux)
7. Flow is running fine (as expected!). But the monitoring events generated by subflow are now going to BACKOUT queue. Monitoring events from mainflow are still going to DB properly.
8. personB takes the bar in his toolkit (8.0.0.3), rebuilds and deploys on the same broker as done by personA in step6.
9. All monitoring events (MF and SF) are once again going to DB.
Questions are-
1. I know it is good to have the bar rebuild on FP3 toolkit, but is it a must have req?
2. Shouldn't the broker running on FP3 be able to accomodate the functionality developed, built and executed on FP2 as is?
_________________
Regards
Sumit |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Dec 27, 2013 1:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What is the effective level of the broker?
Have you done -f all ? 
_________________
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 |
|
|
| sumit |
| Posted: Fri Dec 27, 2013 2:58 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| zpat wrote: |
| What is the effective level of the broker? |
Is this what you are asking?
| Quote: |
[wmbadmin@ltmyomsmb001 ~]$ mqsireportbroker BRUX0001
BIP8927I: Broker Name 'BRUX0001'
Last mqsistart path = '/opt/ibm/mqsi/8.0.0.3'
mqsiprofile install path = '/opt/ibm/mqsi/8.0.0.3'
Work path = '/var/mqsi'
Broker UUID = '06d54b2a-cce9-11e2-9c36-0a6103100000'
Process id = '19716'
Queue Manager = 'QMUX0001'
User lil path = ''
User exit path = ''
Active user exits = ''
LDAP principal = ''
LDAP credentials = ''
ICU converter path = ''
Trusted (fastpath) Queue Manager application = 'false'
Configuration change timeout = '300' seconds
Internal configuration timeout = '60' seconds
Statistics major interval = '60' minutes
Operation mode = 'advanced'
Fixpack capability level = '' (effective level '8.0.0.1')
Broker registry format = 'v8.0'
Administration security = 'active'
Multi-instance Broker = 'false'
Shared Work Path = 'none'
Start as WebSphere MQ Service = 'undefined'
HTTP listener port = '7080'
Cache manager policy = 'disabled'
Cache manager port range = '2800-2819'
|
Does it mean our effective version is 8.0.0.1? And effectively we are not using FP2/FP3 features? Ah.. never checked this.. 
What I checked was-
| Quote: |
[wmbadmin@ltmyomsmb001 ~]$ mqsiservice -v
BIPmsgs en_US
Console CCSID=1208, ICU CCSID=1208
Default codepage=UTF-8, in ascii=UTF-8
JAVA console codepage name=UTF-8
BIP8996I: Version: 8003
BIP8997I: Product: WebSphere Message Broker
BIP8998I: CMVC Level: S800-FP03
BIP8999I: Build Type: Production, 64 bit, amd64_linux_2
BIP8071I: Successful command completion.
|
| zpat wrote: |
| Have you done -f all ? |
No. I thought FP takes effect the moment it is installed. Does it not? 
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Simbu |
| Posted: Fri Dec 27, 2013 3:35 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| Hi, you should not judge the version of the broker effective level based on the output of "mqsiservice -v" because it gives only broker environment details but not the broker details. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 27, 2013 5:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sumit wrote: |
| zpat wrote: |
| Have you done -f all ? |
No. I thought FP takes effect the moment it is installed. Does it not? |
You will get the fixes included in a new Fix Pack as soon as the Broker is restarted after installing the Fix Pack. But if you want the new features as well, you need to run the mqsichangebroker command with the -f flag.
http://www-01.ibm.com/support/docview.wss?uid=swg21376622
http://pic.dhe.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/an28145_.htm
You can either specifiy the exact Fix Pack you want to enable features at and have to run that command each time you apply a Fix Pack if you want to enable new features each time, or you can run it once specifying 'all', and that way you get all the new functionality of every new Fix Pack as you apply the new Fix Pack.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Dec 27, 2013 5:50 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Thanks all for the information. I must admit, I was unaware about these. I read about these commands in infocenter only after zpat's comments.
We'll take necessary actions now.
However, that doesn't explain the behaviour what we noticed (as mentioned in point 7, 8 and 9 of my original post)
| Quote: |
7. Flow is running fine (as expected!). But the monitoring events generated by subflow are now going to BACKOUT queue. Monitoring events from mainflow are still going to DB properly.
8. personB takes the bar in his toolkit (8.0.0.3), rebuilds and deploys on the same broker as done by personA in step6.
9. All monitoring events (MF and SF) are once again going to DB. |
If the broker is actually running on FP1 (8.0.0.1), shouldn't the flow deployed by 8.0.0.2 toolkit have worked as it was?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Dec 27, 2013 6:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I generally do (mqsichangebroker) "-f all" ..... 
Seems like a good idea, but it's surprising how many people IBM have managed to catch out with this requirement (especially developers who have their own broker).
_________________
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 |
|
|
| sumit |
| Posted: Fri Dec 27, 2013 11:26 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| zpat wrote: |
| I generally do (mqsichangebroker) "-f all" ..... |
We'll also start it as a practice.
Though, there are more incidents which in a way present some erratic behaviour.
For eg., while on FP2 (we never executed mqsichangebroker command on FP2 or FP3), we raised some PMR with IBM for some of the bugs we encountered with record and replay framework. IBM gave interim fixes and those worked. IBM also informed then, that these interim fixes will be part of FP3. So, after FP3 release, we installed it and yes.. the bugs were gone.
Doesn't it mean that after installing FP and restarting the broker, the fix works?
Has someone experienced similar behaviour?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Dec 27, 2013 11:52 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
As has been said, Bug Fixes are automaticall enabled after the application of a fix Pack.
Changes in functionality not related to bug fixes are only enabled to the level specified by the mqsichangebroker -f option.
so yes applying the FP fixes the bugs are you experienced.
_________________
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 |
|
|
| sumit |
| Posted: Fri Dec 27, 2013 10:54 pm Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| PeterPotkay wrote: |
| You will get the fixes included in a new Fix Pack as soon as the Broker is restarted after installing the Fix Pack. But if you want the new features as well, you need to run the mqsichangebroker command with the -f flag. |
| smdavies99 wrote: |
As has been said, Bug Fixes are automaticall enabled after the application of a fix Pack.
Changes in functionality not related to bug fixes are only enabled to the level specified by the mqsichangebroker -f option. |
My bad.. I should have read what PeterPotkay had said earlier.
Thanks All. I will execute mqsichangebroker -f and see how it goes.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Jan 03, 2014 5:19 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
The problem looks a little more complicated. We have already exectuted -f all and don't see any improvement.
If I deploy bar A, both MF and SF triggers events which then go to DB. If I deploy bar B in the same EG, SF's events from bar A start going into backout queue.
And it is because eventSourceAddress and nodeLabel field populated as part of monitoring event are getting some extra characters.
Raised a PMR with IBM.
_________________
Regards
Sumit |
|
| Back to top |
|
|
|
|
