| Author |
Message
|
| drano |
 Posted: Mon Oct 28, 2002 1:38 am Post subject: IMPORTANt!! UNSOLICITED and BAGGREGATE |
 |
|
Novice
Joined: 02 May 2002
Posts: 15
Location: Serv'N Data
|
Sometimes I have record in BAGGREGATE with UNSOLICITED='N'.
These records come with error in fan-out of AggregateControl.
But these records are never removed.
How don't generate these records ? How solve my problem ?  |
|
| Back to top |
|
 |
| devans |
| Posted: Tue Oct 29, 2002 4:18 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
A record will be stored in BAGGREGATE for every request message you send out. They are designed to be removed when the replies have come back and the aggregated reply message has been processed.
If you have orphaned records in the table, then its probably because you tested your message flow when it was incomplete, and you had the logic to insert the records, but not the logic to remove them. As this is only a development system, you can go and wipe those records out by hand
db2 connect to WMQIBKDB
db2 DELETE FROM BAGGREGATE
If you think your flow is complete, you've cleared out the table, but you're still seeing orphaned records, then I'd suggest that your flow is NOT complete and needs further work. |
|
| Back to top |
|
|
| drano |
| Posted: Tue Oct 29, 2002 7:57 am Post subject: It is an normal error |
|
|
Novice
Joined: 02 May 2002
Posts: 15
Location: Serv'N Data
|
OK, I understood your comments. But sometimes I may have an error in fan-out of AggregateControl, because someone doesn't enter a good MQ name. Humans may make a fault !
And, I think that it is not professional to remove all records in baggregate in production environment. I imagined that WMQI was a serious tool.
Do you know if IBM wants to modify aggregate node to avoid this bug ?
Thank you for your answer |
|
| Back to top |
|
|
| devans |
| Posted: Wed Oct 30, 2002 12:57 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
What you are describing is not a bug, it is a problem with your flow design. Your fan-out flow should be transactional. If you subsequently have an error in your fan-out flow, then an exception will be thrown, the transaction will be rolled back, and the records will not be inserted into BAGGREGATE.
I never suggested that you manually remove BAGGREGATE records in a production environment. Your flow should be able to cope with error conditions. The default which is to roll back is perfectly adequate as a starting point. Just make sure everything happens within a transaction. Set "Transaction Mode=Yes" on your MQInput nodes and MQOutput nodes. |
|
| Back to top |
|
|
| drano |
| Posted: Wed Oct 30, 2002 1:47 am Post subject: Transaction mode |
|
|
Novice
Joined: 02 May 2002
Posts: 15
Location: Serv'N Data
|
Yes, I have "TransactionMode=Yes".
In fact, Aggregate node, in my environment, is very unstable. I don't understand why ? I installed CSD03, but problems remain... |
|
| Back to top |
|
|
| devans |
| Posted: Wed Oct 30, 2002 6:52 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
| I suggest that you try and isolate your problem and contact your IBM Support Centre. I've personally seen dozens of solutions sucessfully using Aggregate nodes. This forum isn't really the best place to solve this kind of complex environmental problem. |
|
| Back to top |
|
|
|
|
