| Author |
Message
|
| nethaji |
 Posted: Wed Oct 24, 2001 10:43 am Post subject: |
 |
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
HI all,
My application is triggered for a client (say QA) and reads QA1 & QA2. The same application is triggered for another client QB that reads QB1 & QB2. Like this the application is triggered for each client and reads its relevant queues.
I feel that this application can be changed a little so that, it can accept the client name and then work on the particular queues. This reduces the queue creations for each client. In this case the application should have logic to pick up the messages for each specific client. I read some where that I can specify any of the five variables for identifying a particular message
MsgId
CorrelId
GroupId
MsgSeqNumber
Offset
I think out of this, correlation id is the best for this application if each client is ready to send a correlation id in a generic form (like QA1212312, QA123231, …. QA* for client QA). I also read that since correlation id is a character array it won't undergo any data conversion. Will this create a problem? Can I read messages with generic correlation id? Is the whole idea good?
nethaji
[ This Message was edited by: nethaji on 2001-10-24 11:45 ]
[ This Message was edited by: nethaji on 2001-10-24 11:46 ] |
|
| Back to top |
|
 |
| bduncan |
| Posted: Wed Oct 24, 2001 2:13 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
nethaji,
What you are saying is correct. Generally, any application-level context information is placed in the CorrelId field, and you shouldn't run into any conversion problems because this is all handled by the queue manager. However, another field that might make more sense for your particular application is to use the "ReplyToQ". In other words, your sending application can set this field to the name of a queue, and then when your receiving application retrieves the message, it can look at the value of this field and do whatever processing is necessary on that queue. This way the CorrelId field is free to use for other purposes. But either way should work fine...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nethaji |
| Posted: Thu Oct 25, 2001 6:35 am Post subject: |
|
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
HI bduncan,
Thanks for the idea of adding Reply-To-Queue Name. What i am trying to ask is, All the client are going to send the reply back to the same queue (if I use the same reply-to-queue Name for all the clients) then if I need to retrieve the message that are sent by a particular client , I have to use the correllation id only, Right? How about the data conversion of the correllation id. If the client sends message from NT and I receive the data in OS/390 will this work? |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Oct 25, 2001 9:57 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Then in that case CorrelId is probably the best bet. You don't have to worry about conversion... If you send a message from OS390 to NT, for instance, it works a bit like this:
1. The data of the message will be retrieved in EBCDIC form unless the MQGMO_CONVERT option is specified
2. The header of the message (which is where the CorrelId is contained) is retrieved in the format of the receiving platform regardless of what platform sent it. In other words, conversion of the header is handled automatically by the queue manager. So if you set your CorrelId to "TEST123" on OS390, on the NT box (receiving end) you should be able to do an MQGET and specify matching against a CorrelId of "TEST123" and it will retrieve your message.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nethaji |
| Posted: Thu Oct 25, 2001 11:40 am Post subject: |
|
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
|
| Back to top |
|
|
| kamy |
| Posted: Sat Oct 27, 2001 5:09 pm Post subject: |
|
|
Novice
Joined: 26 Oct 2001
Posts: 21
|
Hi,
I was wondering if you coould use temperory dynamic ques to correlate reques/replies?
- kamy |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Oct 29, 2001 4:13 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Kamy,
Yes - you can use temporary dynamic queues for replies. Just have the sending application create a temporary dynamic queue, and then when it sends a request, have it set the ReplyToQ field in the MQMD structure to the name of the temporary dynamic queue it created. Then have it open this queue and wait for a reply based on the CorrelId. Meanwhile, have your receiving application create the reply message and send it to the queue name specified in the ReplyToQ name field.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nethaji |
| Posted: Wed Oct 31, 2001 2:46 pm Post subject: |
|
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
hi kamy & bduncan,
Thanks for the idea. We wanted this application to be Asynchronous, so I think the above is the best solution. May be we can think of creating permanent dynamic queues... but in that case deleting those permanent dynamic queues become more complicated.
I have one more question.
Can we specify a generic correlation id to fetch messages which starts with corellation id. I mean is there something we can specify like ABC* to fetch all the messages which has the correlation id starting with ABC (like ABC231423, ABC34543, ABC223, ABC)
regards
nethaji
|
|
| Back to top |
|
|
| StefanSievert |
| Posted: Wed Oct 31, 2001 4:44 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Hey guys,
I think I have to disagree with the statement that the correlId is a character field which will be converted.
msgId and correlId both are MQBYTE24. If you are sending across similar platforms, you might be golden when using strings in these fields. However, if you send from OS/390 to NT or any other non-EBCDIC platform yuo might be in trouble because MQ treats these fields as binary values, not as string values and as such, will not convert EBCDIC to ASCII.
You could overcome this by populating these fields with hex values that represent ASCII characters/numbers though.
Did I miss the point?
To answer the last question, I don't think that you can select messages with 'generic' msgId/correlId (like 'QA*').
Cheers,
Stefan |
|
| Back to top |
|
|
| kolban |
| Posted: Wed Oct 31, 2001 4:56 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Stefan is 100% correct, the MSGID, CORRELID and GROUPID are binary fields and do NOT get translated to an alternate code page as used in character fields.
Don't forget that you have MSGID and GROUPID in addition to CORRELID. A client could set the MSGID or CORRELID or GROUPID to its own name (padded with NULLs or spaces) and do an MQGET keyed from those attributes. |
|
| Back to top |
|
|
| AlexeiSkate |
| Posted: Fri Jul 12, 2002 7:30 am Post subject: |
|
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
If within your message flow you want to set the CorrId to some value like 'MY CORR ID', is there an easy way to automatcially convert the string of characters to an MQByte24 value (or hex value ) ?
thanks,
Alex |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Jul 12, 2002 7:39 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
It's expected that the CorrelId is a numerical value. If you want to stuff something else in there, I would say use an MD5 of the english phrase...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
