| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQTrigger V/s Java |
« View previous topic :: View next topic » |
| Author |
Message
|
| narki |
 Posted: Mon Mar 24, 2008 5:43 pm Post subject: MQTrigger V/s Java |
 |
|
Acolyte
Joined: 19 Dec 2005
Posts: 67
|
There is requirement to FTP file from message broker on unix to mainframe in append mode. I was planning to use the FileOutput node, but the problem, with the file output node is that it overwire the existing file. Here are two alernative :
1. Use File Out put node to write to local file system. And use MQTrigger to invoke the script which will FTP the file in append mode.
2. Second option is to call java program from the ESQL which will FTP the file in app mode.
I am for 1st solutins whcih looks to me straigt forward, but are another group which is arguing for second option. Only strong argument which I can find about optionII is error handling. If something goes wrong while FTPing in messageflow, exception will be thrown in broker and which will be handled by the eror handling routine.
Right now I am not able to find any soluting regarding monitoring the MQTrigger and way to correct the the problem which can occures.
What are the problem which can occurs whicle using MQ trigger. Whether mQ trigger is good option or not. Advice in this regard is highly appriciated. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 25, 2008 1:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The correct option is to do this outside of broker entirely, with a standalone program that will read the message on the queue, and ftp the file in append mode.
Well, really, the correct option is to change the mainframe program to read from a queue rather than a file that has to be FTPd.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 25, 2008 2:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| Well, really, the correct option is to change the mainframe program to read from a queue rather than a file that has to be FTPd. |
   
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| narki |
| Posted: Tue Mar 25, 2008 4:51 am Post subject: |
|
|
Acolyte
Joined: 19 Dec 2005
Posts: 67
|
| Jeff, thanks for reply. Changing is mainframe program is not an option for us. Is there any way to alert the operations in case the MQTrigger failed or program failed to FTP. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 25, 2008 4:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| narki wrote: |
| Jeff, thanks for reply. Changing is mainframe program is not an option for us. Is there any way to alert the operations in case the MQTrigger failed or program failed to FTP. |
Add a new mainframe program that does this!
You are going to vastly simplify your operational situation if you do not use FTP for anything other than external file transfers. FTP is troublesome, unreliable, and hard to code for successfully.
Use MQ for all internal traffic, configure your MQ monitoring system to generate necessary alerts.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 25, 2008 5:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| narki wrote: |
| Changing is mainframe program is not an option for us. |
Why? It's the lower cost option (long term) than trying to shoehorn a badly fitting solution into your architecture, if you factor in the costs of fixing all the failed file transfers over the years.
| narki wrote: |
| Is there any way to alert the operations in case the MQTrigger failed or program failed to FTP. |
Depends - what have you got monitoring the Unix box & can it communicate with the mainframe operators.
Consider also using a commerical ftp-over-MQ solution to move the file (such as but not limited to) PM4Data. It's more reliable than native ftp (though this should not be taken as an endorsement, other such products are available, no liability is accepted for loss or damage resulting from taking this advice & you should move from files to messages anyway).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
