|
View previous topic :: View next topic
|
| Author |
Message |
rashmirgowda
New User
Joined: 18 Jun 2008
Posts: 25
Location: india
|
|
|
|
Hi,
I am new to MQ. I have a requirement to use MQ connect and Disconnect. we need QMGRNAME for MQCONN.
I found two Qmanagename in copybook.
1. Object QManager Name and 2. Resolved QManager Name
Anybody please help me why we are using two Queue Manage name. Out of these which one i have to use.
Thanks,
Rashmi |
|
| Back to top |
|
 |
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
First, why is this being asked in the CICS forum? The MQSeries forum would be the proper place to ask.
The Resolved Queue Manager names refers to the ultmate QMgr as determined by the local QMgr. Naturally, you don't use this for thr MQCONN.
This information is readily available in the MQSeries Application Programming Reference manual.
Garry. |
|
| Back to top |
|
|
csudhir
New User
Joined: 15 Jun 2016
Posts: 2
Location: Hyderabad
|
|
|
|
Business environments are constantly changing. Applications that were written 20 years ago need to exchange data with applications written last week. The core data can be held in a database on a mainframe, but a user of a browser requires a front-end web application server to interact with that database. Messaging is an effective way to connect these systems. It hides many of the details of communication from the application developer and gives a simple interface.
Many mechanisms for communicating between applications require that both applications are available at the same time. Messaging uses an asynchronous model, which means that an application that generates messages does not have to execute at the same time as an application that consumes those messages.
Asynchrony is used in various ways. It can queue large volumes of work, and that work is then submitted once a day by a batch process. Or, work can be submitted immediately and then processed as soon as the receiving application finishes dealing with a previous request. Asynchronous processing does not imply long response times. Many applications were built and successfully execute by using messaging for real-time interactive operations.
Business transactions normally happen exactly once. Middleware needs to ensure all the systems that are involved in that transaction do their job, exactly once. There must be no loss or duplication.
Data is transferred between applications in messages. A message is a container that consists of three parts: WebSphere MQ Message Descriptor (MQMD): Identifies the message and contains additional control information. Message data: Contains the application data. The structure of the data is defined by the application programs that use it, and WebSphere MQ is largely unconcerned with its format or content. The nodes, within a WebSphere MQ message queuing infrastructure, are called queue managers. The queue manager is responsible for accepting and delivering messages.
Placing a WebSphere MQ infrastructure between the two applications allows this communication to become asynchronous. One application places information for the partner in a message on a queue, and the partner application processes this information when it is available to do so. If required, it can then send a reply message back to the originator. The applications do not need to be concerned with communication failures or recovery. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
any reason to tailgate to a FIVE YEARS OLD TOPIC ? 
topic locked to prevent further stupidity |
|
| Back to top |
|
|
|
|
