| Author |
Message
|
| volume4 |
 Posted: Wed Feb 28, 2007 3:05 am Post subject: |
 |
|
Newbie
Joined: 21 Feb 2007
Posts: 9
Location: South Africa
|
iS MQMD available to Websphere MQ 5.3?
According to the docs it states:
Availability: All WebSphere MQ V6.0 systems, plus WebSphere MQ clients connected to these systems.
Thanks! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Feb 28, 2007 3:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The Java API for WebSphere MQ that comes with MQ v5.3 does allow you to manipulate the MQMD.
You should not be using that version of the API, however, particularly for new development. MQ v5.3 goes out of support in September, and there are many bug fixes and optimizations in v6.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| volume4 |
| Posted: Wed Feb 28, 2007 3:43 am Post subject: |
|
|
Newbie
Joined: 21 Feb 2007
Posts: 9
Location: South Africa
|
So, would I need to write an exit to manipulate the MQMD or do I set MQMD.MQFB_COD or something similar as a GET message option?
Thanks |
|
| Back to top |
|
|
| volume4 |
| Posted: Wed Feb 28, 2007 4:17 am Post subject: |
|
|
Newbie
Joined: 21 Feb 2007
Posts: 9
Location: South Africa
|
Would the below do the trick?
gmo.options = MQC.MQGMO_MSG_UNDER_CURSOR | MQC.MQMD_VERSION_2 | MQC.MQFB_COD;
myQueue.get(myMessage, gmo);
Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 28, 2007 4:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Have you considered reading the v5.3 version of the Using Java manual?
Have you decided to completely ignore the fact that you should be migrating to v6 as soon as possible, and should be doing absolutely no new development on it?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| volume4 |
| Posted: Wed Feb 28, 2007 4:33 am Post subject: |
|
|
Newbie
Joined: 21 Feb 2007
Posts: 9
Location: South Africa
|
I am reading the PDF and it seems to suggest that the MQMD is edited by setting these options on as part of the get message options. Am I wrong here?
As far as upgrading to 6, this is completely out of my hands. |
|
| Back to top |
|
|
| volume4 |
| Posted: Wed Feb 28, 2007 4:50 am Post subject: |
|
|
Newbie
Joined: 21 Feb 2007
Posts: 9
Location: South Africa
|
Would this do the trick?
MQMessage myMessage = new MQMessage();
myMessage.feedback = MQC.MQFB_COD;
Thanks! |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 28, 2007 5:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| jefflowrey wrote: |
Have you considered reading the v5.3 version of the Using Java manual?
Have you decided to completely ignore the fact that you should be migrating to v6 as soon as possible, and should be doing absolutely no new development on it? |
That's not a realistic point of view in large commercial installations.
We are planning the migration now and expect the entire project to take a year in elapsed time as the various interested parties find the time and resource to test their applications.
Installations are often "back level" because the cost and risk of upgrades outweigh the advantages (or "if it isn't broke, don't fix it). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 28, 2007 5:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A large commercial institution should realistically have started the migration already - having been well and fully aware of the EOS date for MQ v5.3 for several months now.
Any migration effort needs to realistically include a cutoff point where new development is not performed on the old versions of software.
The risk of not upgrading is that an outage will occur that is a) caused by something already fixed in the newer release and thus *preventable*, b) unable to be fixed except by upgrading, and so the cost of the upgrade has now risen to include the cost of the outage. Or vice versa, the cost of the outage has now risen to include the cost of the upgrade!
Upgrading is cheaper than downtime!
This is a very REAL risk. And the cost of performing any kind of an upgrade should already be factored into the cost of running an IT infrastructure. Maintenance is the largest part of any project both in cost and time, and needs to be managed and paid for as an ongoing effort.
Evaluate and apply fixes every 6 months, and start migration to new versions as soon as possible.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 28, 2007 6:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
That's the theory. Just doesn't happen like that. Ask the guy still running OS/2!
"Old" software is generally more stable than "New" software which can make doing the "right thing" a constant cycle of patching. Business priorities often tend to preclude this approach. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 28, 2007 6:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's unrealistic to predicate business priorites on an unchanging business climate, and thus to allow an IT infrastructure to fail to reflect that.
The recent change in the DST laws in the US (and Australia?) is the perfect example of this. Factors completely outside the realm of *both* business AND IT have forced changes to software to ensure that the business logic produces the correct results.
The guy running OS/2 is going to be completely out of luck for this change - all of the date calculations performed on that infrastructure are going to be off by an hour or more for several weeks every year if that infrastructure is running in an affected area.
A constant cycle of patching is required to deal with a constant cycle of business change - and business does face constant change.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 28, 2007 7:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Limited budget + urgent business change vs routine maintenance.
We actually outsource our infrastructure to IBM Global Services and they are contractually obliged to maintain it. However we often go two years without maintenance on queue managers.
Their view is that as along as it remains in support that's enough. Even then they rely on the client to push for new versions in time to meet support withdrawal dates. That's the real world, even when IBM themselves are doing the maintenance, because if they are busy applying CSDs they can't be doing other work for the client.
As long as business people call the budget shots, it will be like that - you can't just lecture people and keep saying "it should, it should..."! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 28, 2007 7:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I can keep lecturing people and saying "it should! it should!".
It may not be effective. But I'm entirely capable of it, I assure you... 
Especially when I've just come from a customer site where the damage of not doing applying routine maintenance was fairly substantial, and ongoing.
It does nothing to help volume4 with the questions about report options and MQMDs. But most of the question seems to be "is the manual correct?", and I guess it usually is.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
