ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQ Client

Post new topic  Reply to topic
 MQ Client « View previous topic :: View next topic » 
Author Message
garryp
PostPosted: Thu Mar 02, 2006 11:28 am    Post subject: MQ Client Reply with quote

Newbie

Joined: 02 Mar 2006
Posts: 3

Newbie Q before I spin my wheels a lot.

My platform is a local MQ Client on Windoz.

Target is a proprietary program running MQ Server on a remote HP Unix.

This remote server uses configurable Remote Queue definitions to push messages.

It also uses non-configurable receiver Queues to "pull" messages (preconfiguration information is known).

Question: Can I write a VB program that can both receive the "pushed" messages and send "pulled" messages to the Unix box? i.e. avoid using a local full-up MQ Server at the local end?

Thanks for replies. Suggestions to point my nose in the right direction would also be appreciated.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Thu Mar 02, 2006 11:39 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

There is no notion of "pull" or "push" in MQ. Messages do not have directions.

The two notions are "put" and "get".

An application can put messages to any kind of queue.

An application can only ever get messages from a queue that is a qlocal on the queue manager it is connected to.

So your client application can only get from queues that are qlocals on the remote MQ Server queue manager.

Your client application can put to any queue that is known to that queue manager.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
garryp
PostPosted: Thu Mar 02, 2006 11:58 am    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2006
Posts: 3

Tanks.

put/get: Yes, I know, but I lapsed into the terminology used by the software vendor.

If I understand correctly, the put operation can be used easily, but the remote QM definition (on the 'remote' computer) will have to point to a MQ Server, from which my app will retrieve from a local queue.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Thu Mar 02, 2006 12:26 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

How many queue managers are currently involved? Just the one?
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
garryp
PostPosted: Thu Mar 02, 2006 5:47 pm    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2006
Posts: 3

jefflowrey wrote:
How many queue managers are currently involved? Just the one?


There can be any number, and on multiple servers, on different IP's, different locations. Each server can have multiple remote Q defs for puts, and multiple Q for gets. I do not have the flexibility to change the set-up on the target servers, other than config params. (i.e. I cannot decide to not use remote QM for their put.)

The software I am contemplatimg would be a bridge between ftp and mq.

So it looks like ftp <-> VB6 custom bridge <-> Windoz local MQ server <-> HP itanium remote MQ servers, with possible complex inter-routing on each end.

This is actually a test scenario, load and reliability testing of the Unix systems.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Fri Mar 03, 2006 4:40 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Okay.

Well, again. The basic rule is that your app can only get from qlocals on the queue it is connected to.

So the minimum setup your app needs is
  • a single queue local for receiving messages
  • the MQ network to be set up such that any app that needs to send files by FTP can find your input queue
  • The MQ network to be set up such that your app can find the input queue of any application that needs to receive files by FTP

What you will do is execute gets against a qlocal on some queue manager, and puts to qremotes, name-resolved queues, or qclusters (however the mq admins choose to configure their network).

I'm going to get on my high horse a moment here. File Transfer over MQ is a problem that is usually a lot more complicated than it first seems. Here's an example. In your case, some application puts a file on your queue. How do you know what FTP site it needs to be sent to? Now, a week later, that FTP site has changed. How does your application learn this? When an error occurs accessing an FTP site, what happens? Who needs to know that an error occurred?

File transfer processes in the enterprise need to be highly visible to lots of people, and managed by a small set of people.

You are much better off buying a product to do this than rolling your own. One such product that I personally find very good is MetaStorm's PM4Data.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MQ Client
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.