| Author |
Message
|
| ydsk |
 Posted: Tue Mar 20, 2007 6:24 am Post subject: MQCC /RC returned when IMS region / txn goes down |
 |
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Hi,
My scenario is:
C++ client on Windows <----->MQ on AIX<------>MQ/IMSbridge/IMS on mainframe.
When my C++ client does a PUT followed by a GET ( request/response) how do I know if and when the IMS region / txn in the back-end goes down ?
Is there a MQCC / RC pair that tells me when the IMS region/txn goes down in the above scenario ?
Any suggestions / ideas ?
Please post.
thank you.
ydsk. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 20, 2007 6:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
You will get a 2033 from your GET if the IMS region is down.
You will also get a 2033 from your GET if the channels to IMS are down. Or if the IMS programs did something wrong, and failed to send a reply. Or any of another hundred different reasons why the reply message wasn't received in time.
You do not want to design an MQ application to be tightly coupled across systems like you are asking about.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 20, 2007 6:47 am Post subject: Re: MQCC /RC returned when IMS region / txn goes down |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ydsk wrote: |
Any suggestions / ideas ?
|
Use the asyncronous nature of MQ to ensure that both sides can cope if the other system is down? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Mar 20, 2007 6:58 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| You could PUT disable the IMS bridge queue remote definitions (on the AIX box) if IMS is going down and PUT enable them when IMS is back, but you would have to work out hows and whens etc. |
|
| Back to top |
|
|
| ydsk |
| Posted: Tue Mar 20, 2007 6:59 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
There is an existing middleware used in place of MQ as of today and that middleware is checking for error code 4273 ( i guess it's coming back from IMS, not sure ) immediately after a GET.
We are replacing the existing middleware with MQ and so we need to retain the existing logic.
So, I am trying to find the best way of doing the same.
thank you.
ydsk. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 20, 2007 7:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess your choice is to continue to hobble along with the tightly coupled logic produced by the original middleware, or take advantage of the loose coupling that MQ provides. I'm betting that the original middleware made synchronous calls.
Any response code from IMS might be in the reply message. I don't know what the IMS bridge does if the IMS region is down.
Another possibility is to use report messages. If you do not get a COA or COD within a certain period of time you can decide that IMS is down.
Or you could just code your C++ client application to talk to IMS over 3270 (telnet), if the client insists on keeping everything tightly coupled.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Mar 20, 2007 7:21 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
SLightly wavering off topic here but......
<soapbox>
In my experience this subject is one of the hardest concepts to get across to 'traditional' programmers. There seems to be an inherent mistrust of 'other' applications to the point where it really hampers good application design. I understand that synchronous is sometimes the best fit for the business but in that case why even try to use an asynchronous methodology to achive your ends? If I had a dollar for everytime I have heard 'but we need to know that the other end worked' I could probably comfortably retire by now.
Of course it is never as simple as that, there is always the probability of the target application being as old as the hills and not too clever at error handling, but if it is that business critical then surely it is important enough to modify to behave itself correctly?
Now I am not saying that MQ shouldn't be used for synchronous type processing, but what I am saying is that the business has to make the decision based on what is or is not possible with the technology.
</soapbox> |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 20, 2007 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Pulling this slightly back towards topic, please see this thread:
http://www.mqseries.net/phpBB2/viewtopic.php?t=35234
This contains a discussion of why you don't need to know if the other end has received a message, and the problems of deciding you do.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ydsk |
| Posted: Tue Mar 27, 2007 10:02 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
When the IMS transaction goes down I get a message in the Reply2Q on AIX that looks like : '.....DFS065 ......'.
I don't get a MQ 2033 reasonCode ..... please note this.
So, there is an IMS response message ( sent by the IMS bridge I guess) indicating a failure on the IMS side. I am thinking there could be other possible DFSxxx messages for different failures on the IMS side.
Thanks.
ydsk. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Mar 28, 2007 12:12 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| A DFS065 is issued if the database is stopped. The bridge is picking this fact up and passing it along to you. What you do with this information is a business decision. |
|
| Back to top |
|
|
|
|
