| Author |
Message
|
| jcv |
 Posted: Wed Nov 05, 2008 8:58 am Post subject: backward compatibility issue |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hello,
I have received this:
-------------------------------------------------------------------------------
2008. 11. 05 14:56:18
AMQ9510: Messages cannot be retrieved from a queue.
EXPLANATION:
The attempt to get messages from queue 'SYSTEM.CLUSTER.COMMAND.QUEUE' on queue
manager 'qmgr' failed with reason code 3003.
ACTION:
If the reason code indicates a conversion problem, for example
MQRC_SOURCE_CCSID_ERROR, remove the message(s) from the queue. Otherwise,
ensure that the required queue is available and operational.
-------------------------------------------------------------------------------
2008. 11. 05 14:56:19
AMQ9409: Repository manager ended abnormally.
EXPLANATION:
The repository manager ended abnormally.
ACTION:
Look at previous error messages for the repository manager in the error files
to determine the cause of the failure.
-------------------------------------------------------------------------------
2008. 11. 05 14:56:18
AMQ7925: Message version 3 is not supported.
EXPLANATION:
Message data conversion cannot convert a message because the Version field of
the message contains an incorrect value.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier, and to save the generated output files. Do not discard these files
until the problem has been resolved. Use the file containing the Message
Descriptor of the message to determine the source of the message and to see how
data that is not valid became included in the message.
Is there cluster repository managers compatibility between v5 and v6? I see MQCFH_VERSION_1,2,3 messages coming from v6 to v5 SYSTEM.CLUSTER.COMMAND.QUEUE being not consumed there. Is there an alternative way in old versions to propagate cluster changes without MQCFH_VERSION_3 messages? The problem here is v5 amqrrmfa blocking or crashing under certain conditions (not fixed and not upgraded to v6 or 7). |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Nov 05, 2008 9:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
It's considered best practice in a mixed v5 / v6 cluster to have the full repository queue managers at v6. I'm not sure if it's actually written in any IBM docs anywhere, but I think it's the recommended way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Nov 05, 2008 9:36 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I have fulfilled that requirement. I don't know if that's important too, but changes which were propagating to v5 PR were done at v7 PR. It was about adding new qmgrs v7 to cluster and defining some queues there advertised to cluster. Those were not processed properly and I couldn't recuperate amqrrmfa without deleting them first. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 05, 2008 9:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Is there an IBMer in the house??? 
It sounds like there is a "feature" somewhere in the v7 code which is preventing the changes propogating properly. Have you ensured all the CCSIDs are compatable on all the platforms? I'd be amazed if that was indeed the problem, but it's worth checking.
I mention in closing that v5 is out of support and this is likely to be the basis of any response from IBM. But you know you need to upgrade anyway I'm sure.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 05, 2008 9:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| jcv |
| Posted: Wed Nov 05, 2008 10:40 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
CCSIDs are (fortunately?) not a problem here. It clearly states reason code 3003. I know v5 is not supported, hopefuly it doesn't mean not compatible for clustering with v7, or whatever the problem here is. I would never stick to obsolete version if I wasn't forced.
In this document, prepared a long time ago for v6, it says among other things that all the partial repositories can be upgraded before the full repositories. I have FR's at v6, only one PR at v5, several at v7 and the majority at v6. Do you think this should work or not? This is test environment, didn't put any v7 in prod yet. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 05, 2008 3:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| Do you think this should work or not? |
I would have said it should work, but I'm not astonished to discover it doesn't Because v5 is out of support, it's reasonable to assume IBM didn't bother to test v7 against as they would have tested v6.
If you're being forced to retain v5, someone has made a decision to retain v5 which included weighing the risk of continuing to use software once it was out of support against the time it would take to perform the upgrade.
Tell them their gamble didn't pay off.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Nov 07, 2008 2:46 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| That would be more like "out of function" than just "out of support". Assuming that we are interpreting the reason code well, it must have been design decision. Something like the decision that v5 client must be able to communicate to v7 server through the intact API, which is good decision. That's why I seriously doubt that we came to right conclusion. |
|
| Back to top |
|
|
|
|
