| Author |
Message
|
| sunny_30 |
 Posted: Tue Jan 25, 2011 12:32 pm Post subject: MQ v7 property control attribute |
 |
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Hi all
In prod, we have a C-program deployable running stable that processes rfh2 messages to/from v6 queues with data inserted into rfh2.mcd folder
after migrating from mq v6 to v7 in dev, we started noticing communication problems due to rfh2 not being recognized by the program. This was fixed after all xmitqs, sender channels, local-Qs, sys-model queue-s' PROPCTL attribute was changed from COMPAT to ALL
there are other jms apps that seem to work fine to process rfh2.jms data with no-change required on the queues & also with change to ALL
Im trying to understand why PROPCTL attribute was not set to ALL by default by IBM in v7
we are thinking to change all mq object definitions to PROPCTL(ALL) across the domain for all Qmgrs. Is there a problem with jms apps if we go that path to have all PROPCTL attributes set to ALL instead of default COMPAT?
thanks |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Tue Jan 25, 2011 10:30 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
from the mq migration manual
| Quote: |
Receiving RFH2 Headers in WebSphere MQ classes for Java
In WebSphere MQ Version 6.0, using all defaults, a got MQMessage includes the RFH2 header (if present) and the message payload (for example, Hello World). If, for example, the message was sent from JMS, this RFH2 would be the standard RFH2 that is generated for a JMS Message. It is possible, though, for the RFH2 to have been generated by other means.
In WebSphere MQ Version 7.0, using all defaults, a got MQMessage does not include the RFH2 header (if present) for folders of the RFH2 that are recognised as being from JMS. If a JMS message is got it consists solely of the message payload. The RFH2 is represented in the message properties of the WebSphere MQ classes for Java message.
To preserve the WebSphere MQ Version 6.0 behavior of propagating the RFH2 to the caller, the queue attribute PROPCTL must be changed from COMPAT to FORCE. |
_________________
Regards, Butcher |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Wed Jan 26, 2011 9:52 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Thanks
My question was-
Why PROPCTL attribute in MQ v7 was not set to FORCE or ALL by default ?
why let the old running applications with v6 fail post upgrade & not compatible with later versions?
any strong reason or problems that may arise if I make a global change for all mq objects to carry value PROPCTL(ALL) ? |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jan 26, 2011 1:22 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sunny_30 wrote: |
| ...Why PROPCTL attribute in MQ v7 was not set to FORCE or ALL by default ?... |
Because COMPAT is what it says on the tin - more likely to work than not, hence COMPAT(ability). You were just unlucky and got bitten.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Wed Jan 26, 2011 2:17 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| Quote: |
| more likely to work than not ... |
| Quote: |
| You were just unlucky and got bitten. |
since when MQ upgrades have become a game of luck ?
I would say- why take a chance ?
Im aware what COMPAT means ..
Again, to elaborate , my question was if PROPCTL(ALL) was set to default in MQv7, wouldnt that favor everybody not just the lucky ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 26, 2011 2:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Doesn't the migration documentation cover this? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 26, 2011 3:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| since when MQ upgrades have become a game of luck ? |
When you fail to do the prerequisite research.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Wed Jan 26, 2011 5:18 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| Quote: |
| Doesn't the migration documentation cover this? |
NO
The migration document has only one section "Receiving RFH2 Headers in WebSphere MQ classes for Java" explaining the rfh2 header behavior in both v6 & v7, impact of queue attribute PROPCTL values.
Its highlighted in Mr.Butcher's post also above.
The program that failed in our DEV environment is not Java, its written in C
| Quote: |
| When you fail to do the prerequisite research. |
I agree 100%, it does become a game of luck if not prepared.
Coming back to this topic, I did do the research in the mqv7 migration doc. Didnt find any material related. Obviously, post-upgrade it failed in dev, later did more research at other places such as infocenter, fixed it.
In this situation, i feel the game itself may have to be blamed instead of player's lack of preparation
I started this post not to fix the problem. its already fixed. but mainly to get a better understanding of below things primarily & save any future potential problems:-
1) isnt PROPCTL(ALL) inclusive of both COMPAT + FORCE options ?
In other words, Im assuming there should be no risks running JMS apps also using ALL attribute
2) if its inclusive, why isnt this a default option in mqv7? that would have saved post migration problems similar to what i faced
3) if not inclusive, i wont be doing a global change for this attribute to ALL. Instead have java apps run using COMPAT mode, C-mq-api programs running under FORCE mode
4) any extra advantage of running Java apps using default COMPAT mode compared to using ALL
Note- My environment is mix of Java & C-apps
Only C-based apps had problem after upgrade to MQv7. Got fixed when PROPCTL is changed to FORCE and also ALL
The JMS apps also seem to run fine recognizing RFH2 using ALL attribute when i tested
Im trying to get that information/ confirmation here. Thanks in advance |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jan 26, 2011 8:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
When you specify C applications I suspect you are not talking about XMS.
Maybe XMS behaves slightly differently as you would use a level 7 XMS library?.
Also you might want to retool your application to deal either with the RFH or the V7 properties...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Jan 26, 2011 11:13 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i am currently running broker 6.1 with mq v6 on z/OS, and i am about to migrate MQ to V7.0.1.... from migration document and broker documentation i found out that because of the pub/sub stuff i want to leave with the broker have to run the v7.0.1 queuemanager in compat mode.
There is no single word about that PROPCTL parameter in this context except that single paragraph in the migration document, which is also not very clear to me.
And i have some java applications ("stand alone" java in batch) and another application using java computing nodes in the broker.
Makes me a bit scary. I think i'll open a PMR and ask.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Jan 27, 2011 1:23 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
While I don't remember the specifics, we ran into an issue where in MQ V6 z/OS the RFH2 header came through, even though it didn't strictly adhere to the rules (we had characters that were not really allowed).
When we upgraded to V7 on z/OS, bang! It stripped the RFH2 header. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 27, 2011 3:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Mr Butcher wrote: |
| There is no single word about that PROPCTL parameter in this context except that single paragraph in the migration document, which is also not very clear to me. |
Lucky for you I looked it up this morning and it is still quite fresh in my mind.
This parameter is valid only for server/sender and cluster sdr/rcvr channels.
It directs how V7 properties are transformed into V6 properties (RFH2) when the qmgr at the other end of the channel is @ V6
Read up on it in the channel parameters in the V7 infocenter. It will (hopefully) be quite clear then.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 28, 2011 4:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jan 28, 2011 4:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
OK, having gone through my notes from the Pub/Sub course I attended last week, the following is my understanding:
COMPAT - all message properties prefixed with mcd, jms, usr, or mqext will be delivered in the MQRFH2 header, and all other properties discarded.
ALL - all message properties are included in one or more MQRFH2 headers.
FORCE - message properties are always returned in the MQRFH2 header regardless of whether a message handle was specified - properties will not be accessible by message handle.
NONE - all message properties are removed.
Don't know if that makes it any clearer?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 28, 2011 2:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And if you have a QM with a bunch of MQ 6 and MQ 7 clients attached and the QM has to be upgrade from MQ 6 to MQ 7 and you don't want any of the applications that use RFH2 headers to have to change or to notice anything different, what does the attribute have to be? All I am guessing? And if yes, I'm with sunny-30, why in the world would that not be the default in a migration?
I get forcing "better" things on the app when upgrading, but I always thought reverse compatibility always took precedence and thought that's what all the defaults would reflect.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
