ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere MQ Java / JMS » MQ v7 Java apps and JMS messages (MQRFH2)

Post new topic  Reply to topic
 MQ v7 Java apps and JMS messages (MQRFH2) « View previous topic :: View next topic » 
Author Message
RogerLacroix
PostPosted: Thu Feb 23, 2012 4:07 pm    Post subject: MQ v7 Java apps and JMS messages (MQRFH2) Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 2757
Location: London, ON Canada

All,

If you have Java (non-J2EE) applications handling MQRFH2 messages running on WMQ v5.* or WMQ v6.0 queue managers and are about to upgrade your queue managers to WMQ v7.* then you might want to read this:
http://www.capitalware.biz/rl_blog/?p=1168

It will save you countless hours of head banging.

And yes, I'm ranting again but who else is going to point out stupidity?

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Fri Feb 24, 2012 1:58 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 12831

I would much rather write MQSETMP than the many many many lines of code needed to produce an RFH header from scratch.

RFH2 headers are messy and complicated.

There's been a fair amount of discussion in the past in this forum about PROPCTL and the differences between it's various settings and how it affects JMS applications.

Why is it that every time I suggest, as a consultant, that an app team make a useful and minor change, they start running around in circles and complaining that it would mean they have to do the dreaded full regression testing and that will take forever.

But then when they understand that a major version release of their supporting infrastructure has taken place, they say "If the app starts, it must be fine!".

Oh, right. It's an MQ Problem.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Fri Feb 24, 2012 9:15 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 2757
Location: London, ON Canada

Huh!

I said "hey, the house is on fire" and you said "wow, look at the pretty sunset".

The issue is not about "what could be" or "what will be", it is about what has already been done.

mqjeff wrote:
I would much rather write MQSETMP than the many many many lines of code needed to produce an RFH header from scratch.

RFH2 headers are messy and complicated.

I have created hundreds of Java (non-J2EE) applications for financial services companies over the last 10-12 years that dealt with MQRFH2 messages because "the sending application could not be changed". All, every single one, will break when those companies upgrade their queue managers to WMQ v7.*. Hence, given the number of companies using MQ, potentially, there are at least a million Java (non-J2EE) applications that have to deal with MQRFH2 messages out there in the "real world". All of these applications will break the moment the queue manager is upgraded to WMQ v7.*.

mqjeff wrote:
There's been a fair amount of discussion in the past in this forum about PROPCTL and the differences between it's various settings and how it affects JMS applications.

The issue is not about JMS applications, it is about how the default behavior has been change for Java (non-J2EE) applications that handle MQRFH2 messages.

mqjeff wrote:
Oh, right. It's an MQ Problem.

In this case, it IS an MQ issue.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Fri Feb 24, 2012 9:39 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 12831

Having watched you burn bridges, Roger, I don't think I need a tutorial from you on the difference between houses and sunsets.

There is, in general, no solid good reason for a Java application to use an MQRFH2 header. Unless it is a Java application that is talking to a JMS application somewhere else. In which case, it should really be using JMS instead of plain java. It's a significantly smaller coding effort!

So that means it is a design decision to write Java code to populate or interrogate an MQRFH2. If the only reason that the design decision was made was to allow the application to communicate with JMS applications, then the app *needs to be recoded for v7 anyway*. The JMS applications aren't going to produce MQRFH2 headers, because they can use message properties instead.

It's absolutely an application lifecycle issue. The application is moving to a new version of the base product that it needs to use. It needs to be examined and modified as needed to ensure that it doesn't fail. That's part and parcel of application maintenance.

Anyone who has waited until roughly eight months before the end of support for MQ v6 before moving to MQ v7 is not even remotely near the bleeding edge. They are entirely at the trailing edge.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Fri Feb 24, 2012 10:16 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 2757
Location: London, ON Canada

mqjeff wrote:
Having watched you burn bridges, Roger, I don't think I need a tutorial from you on the difference between houses and sunsets.

I would have never expected a comment like that from you, but hey, you learn something new everyday. I do not lie for people, I do not sugar-coat stuff for people, I tell it like it is and if someone has made a stupid decision, I say was it was a stupid decision. Honesty and integrity are far more important than kissing someone's @ss.

Since 1994, I have donated, freely, a good part of my life to make MQ a success in the industry. If there are some petty people at IBM who have decided that they want to get even with me then that is there problem and it only serves to hurt the end-customer and not me.

mqjeff wrote:
There is, in general, no solid good reason for a Java application to use an MQRFH2 header. Unless it is a Java application that is talking to a JMS application somewhere else. In which case, it should really be using JMS instead of plain java. It's a significantly smaller coding effort!

There are lots of reasons. The primary reason 8-10 years ago, was a company saying we do not have J2EE developers and we purchased a product that generates MQRFH2 messages. Hence, they wanted a non-J2EE application to interact with the purchased product. And to this day, the application is still running.

mqjeff wrote:
It's absolutely an application lifecycle issue. The application is moving to a new version of the base product that it needs to use. It needs to be examined and modified as needed to ensure that it doesn't fail. That's part and parcel of application maintenance.

IBM could have added the feature but made it optional for Java (non-J2EE) applications. i.e. Java (non-J2EE) applications receive the messages with the format MQRFH2 as it was in WMQ v5.3 and WMQ v6.0.

mqjeff wrote:
Anyone who has waited until roughly eight months before the end of support for MQ v6 before moving to MQ v7 is not even remotely near the bleeding edge. They are entirely at the trailing edge.

Who said anything about bleeding edge??? I know there are thousands and thousands of companies out there that will only upgrade at the last minute because WMQ v6 is going out of support. That is the way most people work.

Just look at Christmas shopping, most of it is done in the last week before the 25th.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Sat Feb 25, 2012 5:10 pm    Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 15698
Location: LI,NY

Roger, I do think you are barking up the wrong tree.
Just include in the upgrade process the setting of propctl for the different queues / or even at qmgr level...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
RogerLacroix
PostPosted: Sun Feb 26, 2012 11:04 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 2757
Location: London, ON Canada

Hi Fjb,
fjb_saper wrote:
Roger, I do think you are barking up the wrong tree.

Well, I can't complain to Oracle or HP, as it is not their product. You can't blame the programmers who use MQ, as they are just the users of it. Only IBM is to blame.

When I finished University, my first 2 jobs were for extremely companies that had "active" developers and I just assumed that's the way it was in the real world. Then I took a job with Candle and became a traveling consultant preaching MQ. I visited a huge number of companies and boy that was an eye opener.

Most companies do not have “active” IT department. Software is just a commodity. Period. Programmers or consultants are brought in to do a project then they are gone. Business managers (non-IT) do not care what technology is used under the hood. A job needs to be done, someone was hired to do it and they are gone when the project is done and the project is running as expect. It is a commodity or a black box. Just because the project needed to receive MQRFH2 messages is of no concern (to management) except to the programmer. The programmer could have even documented that the project used received MQRFH2 messages but who is going to remember any of this when it was done in 2004!!!

Changing the default behavior of a Java (non-J2EE) application that receives MQRFH2 messages and putting the problem on a customer’s support team is not right.

Here’s a perfect example: Let’s say you have a cool new smartphne and you have it loaded with lots of stuff. Maybe you have collected hundreds of email addresses and phone numbers of people over your life time and have inputted the information into your nice shining smartphone.

Now version 7 comes out for your smartphone and the smartphone company says it has lots of cool new features including a brand new address book. You think great. You download and install it. Everything works great except all of your contact information is gone. You say what the #%&@. You call the support people of the smartphone company and you tell they what happened and they responses ‘Yes, that is correct’. You complain over and over and they response but it is a new address book in version 7. Finally, they say you have 2 options:

1) input your contact information again or
2) hire a person to convert your backup of your address book to the new format

What would you say? I don’t know anyone who wouldn’t be totally pissed off with the smartphone company. How many people have backups of their contact information (address book) on their PC or anywhere else?? Most people would be freaking out.

The same is true in this situation regarding MQ. I would be willing to bet that 80% of companies will not be able to find a backup of source code that was written back in 2004.

Before you respond, please take a moment and seriously put yourself in the shoes of the smartphone analogy I gave above.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Sun Feb 26, 2012 8:18 pm    Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 15698
Location: LI,NY

I'd be happy to, only the smart phone analogy does not apply here.
If the smart phone company had told you that you needed to switch 2 settings in the new address book and then import the old one and everything would be O.K. would you still be ranting?

And by the way this was described in the documentation. I try and read all the new stuff and changes, but understand if you missed this one (propctrl). I don't always get them all either.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Mon Feb 27, 2012 11:01 am    Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 6762
Location: Hartford CT

Why didn't IBM make the default value "FORCE" for PROPCTL after upgrading a Queue Manager to version 7?

At first glance that seems it would have avoided the whole problem for existing apps. Was it an oversight or bug in the upgrade process, or a concious decision to "help" push apps to the new way of using Message Properties?


In the runmqsc manual for Queue Properties
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaj.doc/sc11240_.htm

There is this text for describing the difference between FORCE and COMPAT.
Quote:

COMPAT
If the message contains a property with a prefix of mcd., jms., usr., or mqext., all message properties are delivered to the application in an MQRFH2 header. Otherwise all properties of the message, except those contained in the message descriptor (or extension), are discarded and are no longer accessible to the application.
This is the default value; it allows applications which expect JMS related properties to be in an MQRFH2 header in the message data to continue to work unmodified. If a message handle is supplied then the behavior is to return the properties in the message handle.
FORCE
Properties are always returned in the message data in an MQRFH2 header regardless of whether the application specifies a message handle.
A valid message handle supplied in the MsgHandle field of the MQGMO structure on the MQGET call is ignored. Properties of the message are not accessible via the message handle.


The italics is mine. I consider myself at least as MQ savy as the average MQ'er. I'm confused. The italics are saying we should be seeing an RFH2 header - IF no message handle is supplied. I'm going to guess that means the MQ Client app needs to be using MQ 7 Client, which will have the Message Handle and thus suppress the RFH2 header if the q property is FORCE? But if the MQ Client is pre MQ 7, then there will be no Message Handle, and therefore you get the RFH2 header whether the Q property is FORCE or COMPAT?

Upgrading the QM to MQ 7 therefore is not the only thing that needs to happen to make things break, its the MQ Client that also needs to go to 7?


_________________
Peter Potkay
Amazing MQSeries secrets found here: Click Me
And Here
Back to top
View user's profile Send private message Visit poster's website
RogerLacroix
PostPosted: Mon Feb 27, 2012 11:10 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 2757
Location: London, ON Canada

fjb_saper wrote:
I'd be happy to, only the smart phone analogy does not apply here.
If the smart phone company had told you that you needed to switch 2 settings in the new address book and then import the old one and everything would be O.K. would you still be ranting?

"¡Ay, caramba!" You really don't get it. That is a simplistic view of the problem/solution. The funny part is that I have already received several emails this morning from people saying "OMG, they were about to be burnt by this".

For large to enterprise size companies, here is the standard scenario that will happen: (1) Upgrade to WMQ v7 and (2) Hours / days / weeks later an application blows up. Most queue managers for these companies have 500 to 1000 queues, so lets say only 5 queues (applications) will be affect by this.

Here is a standard support track:

- MQAdmin will waste at least 4 hours on the problem
- The application support person will waste at least 4 hours on the problem
- The programmer will waste at least 8 hours on the problem
- The manager will waste at least 1 hour on the problem
- Going to the resolution / deployment meeting 1 hour

So, lets add it up: 5 * (4 + 4 + 8 + 1 + 1) = 90 hours (at least) on this issue per company. Since, I have spent my whole IT career dealing with large and enterprise financial and retail companies, what I describe IS the real world.

That is the REAL cost per company (large & enterprise) of the decision by IBM to change the default behavior of Java (non-J2EE) applications receiving MQRFH2.

fjb_saper wrote:
And by the way this was described in the documentation.

Now that is BS. Nowhere in the WMQ Migration Guide for v7 does it describe anything about default behavior for MQRFH2 or MQHRF2 or GMO options changing.

fjb_saper wrote:
I try and read all the new stuff and changes, but understand if you missed this one (propctrl). I don't always get them all either.

Read the manuals, I read and constantly reread the manuals. I have all WMQ v7.0.1 manuals (PDFs) loaded on my iPad. I read the manuals so often that my wife says to to me "Now what are reading?" and when I say an MQ manual, she says "that again"!!

I couldn't create 14 MQ commercial products and 7 open source MQ projects unless I was reading the manuals. Sheeh! MQ Auditor is the most complex MQ program I have ever written. It touches every single MQ API call and every single API structure. Complex doesn't begin to describe it.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter


Last edited by RogerLacroix on Mon Feb 27, 2012 11:22 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
RogerLacroix
PostPosted: Mon Feb 27, 2012 11:17 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 2757
Location: London, ON Canada

PeterPotkay wrote:
Why didn't IBM make the default value "FORCE" for PROPCTL after upgrading a Queue Manager to version 7?

Exactly my point.

PeterPotkay wrote:
At first glance that seems it would have avoided the whole problem for existing apps. Was it an oversight or bug in the upgrade process, or a concious decision to "help" push apps to the new way of using Message Properties?

I don't know but it is was a bad idea.

PeterPotkay wrote:
Upgrading the QM to MQ 7 therefore is not the only thing that needs to happen to make things break, its the MQ Client that also needs to go to 7?

True but also true for Java applications running in bindings mode (on the same server as the queue manager). Given that I have gone to hundreds of companies telling them to follow IBM's standard of NOT embedding MQ JAR files with the application things will break when they upgrade the WMQ Client and also break for those running in bindings mode when the WMQ Server is upgraded.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere MQ Java / JMS » MQ v7 Java apps and JMS messages (MQRFH2)
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.