| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Best Practices for Error Handling |
« View previous topic :: View next topic » |
| Author |
Message
|
| rshephard59 |
 Posted: Mon Feb 24, 2003 1:43 pm Post subject: Best Practices for Error Handling |
 |
|
Novice
Joined: 09 Jan 2003
Posts: 10
|
We just recently deployed our EAI infrastructure using MQSeries and MQ Integrator. We are now starting to write interfaces to meet our business requirements so we don't have a lot of experience to draw upon yet.
I'm curious to know what types of best practices some of you experienced developers have collected for handling errors in the MQ environment. Specifically, for MQ-enabled CICS applications, what are the best methods for ensuring no data loss in the event that MQ itself crashes during a connect or a PUT operation?
On the topic of MQ crashes, how stable has MQSeries for OS/390 been in your opinions? How often have you not been able to actually connect to MQ or PUT a message due to an MQ failure?
I appreciate any feedback you can give us.
Thanks,
Russ |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Tue Feb 25, 2003 3:22 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Hi,
I've only faced once, and it was even my own fault acording to the vendor (I didn't read the electronic updated manual, which was released after my install). 
On Z/OS it's VERY stable, but it depends on you overall SLA. It depends on that the box and other sub-sys are running. There was some child-deceases with clustering, but they are long gone. It's good, two of my customers receives/update stock information using a WebSphere MQ connection....
Well about application design, It's important to handle errors in your program, and make a decision when to use PERSISTENT or NON_PERSISTENT messages using MQxMO_SYNCPOINT or MQxMO_NO_SYNCPOINT. When using MQxMO_SYNCPOINT and a error occurs, CICS can take care of the situation and reestablish a known state (last commit/syncpoint).
If the messages is important, they should be PERSISTENT, so they can survive a QMGR shutdown, just in case of a planned outtake 
You have to take a look on some of these situations: What if a reply is delayed ? It's a asynchronous world.
I hope it give you an impression on WebSphere MQ on Z/OS and CICS.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| rshephard59 |
| Posted: Wed Feb 26, 2003 6:51 am Post subject: |
|
|
Novice
Joined: 09 Jan 2003
Posts: 10
|
Thanks for the advice. It was very helpful.
Russ |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
