Hi,
Many people have suggested that part (or all) of the data should be included. So, I figure I would go for 100 bytes but make it configurable.
In this situation, I don't think the CRC32 will fly. The application groups do not currently have this function, hence, this would cause extra work for they to support it. This client has way, way too many platforms with applications running on: Solaris, OS/400, Windows NT/2000 & OS/390. The division that I work has queue managers on Solaris & WinNT/2000. So, I would rather say, MQGET CorrelID timestamp was 'xxxx', etc...
Regards, Roger Lacroix
At 08:22 PM 4/29/2004, you wrote:
Hello Roger,
As I wrote earlier this week, users mostly care about their data, not our CorrelIDs etc. and so I would log CRC32 or some other hash of data (Date, Time, queue name and MsgID would be useful to preserve, of course). In particular, one problem will be to convince users to log MsgIDs, and another will be that even if you manage to do that, they will still be able to mess up (like not cleaning them before MQPUT and so not having them unique).
Also, be prepared to give your users a standalone utility to get CRC32 of their data on their side, (or to instruct them , if on Unix, how to run cksum with their data as an argument) -- because they won't probably be willing to change their applications to log CRC32 from there (although if they did that would be most convenient for you to reconciliate their logs with your logs).
Of course, checksums only work where no conversions is done..
Hope this will help, Pavel
Roger Lacroix <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ> cc: Sent by: MQSeries Subject: Message Tracking List <[EMAIL PROTECTED] C.AT>
04/28/2004 11:48 PM Please respond to MQSeries List
All,
I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?!
The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!!
So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID
>From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged??
I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID & GroupID for matches.
Any comments - thoughts about this.
Regards, Roger Lacroix
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
--
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
