| Author |
Message
|
| deb |
 Posted: Tue Sep 18, 2007 3:22 am Post subject: Message PUT Date/Time |
 |
|
Novice
Joined: 18 Jul 2007
Posts: 18
Location: Germany
|
Hello,
I need a solution/suggestion for the below senerio.
Queue Managers:
QM1 in Host H1
QM2 in Host H2
QM1 configurations
Remote queue - RQ1 for local queue LQ1 of queue manager QM2 in Host H2
Transmission queue - TQ1
Sender Channel - SCH1
QM2 configurations
Local queue - LQ1
Receiver channel - SCH1
If i upload a message in RQ1 at 18.09.2007 01:00:00 PM while the sender channel SCH1 is not running, the message remains in the transmission queue.
The local queue LQ1 of queue manager QM2 wont receive the message until the sender channel SCH1 of QM1 is not started. Let say i have started the channel SCH1 or QM1 at 18.09.2007 02:00:00 PM and hence the message is transmitted to LQ1 on QM2 at that time.
Now the question is how can i find the actual time (i.e. 18.09.2007 02:00:00 PM ) when the local queue LQ1 has received the message as the message PUT date/time attributes has the time as 18.09.2007 01:00:00 in the local queue LQ1 for this message.
Any suggestions or help would be greatly appreciated.
Regards
Deb |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Tue Sep 18, 2007 3:45 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
In that particular case the put time will be close to the time the channel started, a field called CHSTATI in the DIS CHS output.
Write an API exit which logs the put time from the RCVR MCA.
Set the local queue to trigger EVERY, read the msgs from the queue and write to another local queue. Keep a log of the MsgId and the time.
Write a MSG exit on the RCVR channel which logs the put time when each msg is read from the channel and written to its dest queue.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| jsware |
| Posted: Tue Sep 18, 2007 3:59 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I've not tried this, so the put date/time may not be what you want - test it first.
If you can specify one of the MQRO_COA flags when you put the message, then when it arrives at its final destination, the qmgr should generate a COA report message (to the ReplyToQ/Qmgr)
The put date/time of this COA message would indicate when the message arrived.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| deb |
| Posted: Tue Sep 18, 2007 4:00 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
Location: Germany
|
Thanks for your reply!!
But this seems like a long workaround, it there anything/anywhere in MQSERIES objects/logs/attributes etc. where this information is already available.
"When did the local queue received the message which was loaded to the remote queue???" |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 18, 2007 4:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In v6, if the queue has only one message on it, the message age will tell you when that message was put.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| deb |
| Posted: Tue Sep 18, 2007 4:55 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
Location: Germany
|
|
| Back to top |
|
|
| deb |
| Posted: Tue Sep 18, 2007 5:00 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
Location: Germany
|
Hello
| Quote: |
If you can specify one of the MQRO_COA flags when you put the message, then when it arrives at its final destination, the qmgr should generate a COA report message (to the ReplyToQ/Qmgr)
|
The problem is i wont be having any control in the PUT (sender side) and i need to retrive the information i require only in the receiving end.
Any suggestion!! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 18, 2007 5:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Upgrade to v6. No matter what else you do. Do it today! Now!
Put a process between the local queue and your receiving process, that reads from the local queue, logs a message, and then puts the message to a second queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| deb |
| Posted: Tue Sep 18, 2007 5:20 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
Location: Germany
|
| Quote: |
| Upgrade to v6. No matter what else you do. Do it today! Now! |
Not possible, for some reason.
What can be done in V5.3 for the same? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 18, 2007 5:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If I tell you that nothing can be done until you upgrade to v6... would that suddenly make it possible to upgrade?
You have all the answers you need, already, in this thread. Even if you don't upgrade, which absolutely positively has to be done.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| deb |
| Posted: Tue Sep 18, 2007 5:46 am Post subject: |
|
|
Novice
Joined: 18 Jul 2007
Posts: 18
Location: Germany
|
| Quote: |
Write an API exit which logs the put time from the RCVR MCA.
|
So is that the only option i am left with??? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 18, 2007 3:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
Put a process between the local queue and your receiving process, that reads from the local queue, logs a message, and then puts the message to a second queue. |
As Jeff said this should work too.
To reemphasize => Upgrade to V 6.0.2.2 NOW!
5.3 goes out of support on the 23rd
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 18, 2007 5:27 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| jefflowrey wrote: |
Put a process between the local queue and your receiving process, that reads from the local queue, logs a message, and then puts the message to a second queue. |
As Jeff said this should work too. |
Well, NigelG suggested it first.
With a few other perfectly valid, but incredibly tedious and difficult options.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
