| Author |
Message
|
| mqjim |
 Posted: Tue Sep 20, 2005 1:37 pm Post subject: Asked provide PROOF what MQ Received is what it Delivered |
 |
|
Novice
Joined: 01 Jul 2004
Posts: 22
Location: TEXAS
|
Was in a discussion that involved tracking a flow from start to end. MQ at one point was passed a message from an application and the message was sent up to another platform where the message was received.
The question being asked is how do you know that the message placed on MQ is the same message that was delivered. This is a question by someone outside MQ that needs to be able to say message ABC was given to MQ. Message ABC was delivered at this time to here.
I am not aware that MQ has this type of logging. It has the active logs for persistent messages. Although finding something in them is not too easy and I do not know that I could say the message was delivered to here....
Has someone gone through this path and what was you response to this question of providing proof???
many thanks for the HELP. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Sep 20, 2005 1:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Look in the manuals and search on this site for MQMD Report options COA and COD.
-Peter
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 20, 2005 3:54 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Oooh! Oooh! Call on me, Mr Kotter! Oooh! Oooh!!
In v6, there are new facilities for end-to-end tracing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| markt |
| Posted: Tue Sep 20, 2005 11:22 pm Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| It all depends on what you mean by "proof". For the strongest possible indicator you might need something like TAMBI with cryptographic mechanisms that sign the message at PUT and check it at GET, perhaps combined with reporting options (like COA/COD) to return a copy of the message to the sender. |
|
| Back to top |
|
|
| mqjim |
| Posted: Wed Sep 21, 2005 5:29 am Post subject: Asked provide PROOF what MQ Received is what it Delivered |
|
|
Novice
Joined: 01 Jul 2004
Posts: 22
Location: TEXAS
|
I tend to agree that using something that will sign the message when place on MQ would provide this type of proof. I do not see that COA and COD would provide any proof that the message is the same as was given MQ. It would provide deliverly conformation only.
What I am looking for is something that I can say witout any doubt this message received is the message you sent. Sounds like some signing product would provide this.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 21, 2005 5:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The difficulty most people run into with this kind of thing is having to convince their mq partners to install software on the partner qms.
But MQ guarantees that messages will only be transformed (ccsid/encoding conversion) in certain ways along the road from PUT to GET - and only if you explicitly ask for that transformation to occur.
In general with communications between different business entities, you can only provide proof up to point-of-handover/demarcation. So you could install a channel exit that would log the messages going out from your qm to the other side. Then you could say "When this message left our QM, it was exactly so. If it didn't load on your end, I'm not responsible".
If you're dealing with internal recipients, rather than external recipients, then disabling the receiver app temporarily and using something like amqsbcg to dump the messages from the receiver's input queue is usually sufficient to identify who needs to adjust their code.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| scottm |
| Posted: Wed Sep 21, 2005 8:50 am Post subject: |
|
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
Because MQ is a message transportation mechanism, I think of it in terms of a network infrastructure.
With that in mind, telling them that the message is the same because MQ guarantees it, is similar to telling them that when you copy a file from one network drive to the other it will be the same. And do they ask the network people to provide PROOF that the files never change?
Hopefully, you can just send some messages over the MQ infrastructure and show that the messages you placed on one queue are the same as what arrived on the other queue, and they will accept that as your proof and leave it at that. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Sep 21, 2005 9:47 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Is this question driven by a "development" issue where party A says it sent X and party B claims to have received Y
or is this a "production" issue where you constantly want proof MQ did what it is supposed to do?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| mq_developer |
| Posted: Wed Sep 21, 2005 11:16 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
| Quote: |
| What I am looking for is something that I can say witout any doubt this message received is the message you sent |
Look at this ..
http://www-306.ibm.com/software/integration/wmq/securityedition/features
* Attach digital signatures to individual messages so you can verify if they have been tampered with and identify and trace messages to their point of origin
Ofcourse you can make use of the above feature & product as a value addition in terms of "message integrity" service , but not for "proving" that MQ didnt change anything in the message. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Sep 21, 2005 3:28 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
I agree with scottm on this one - the question is simply irrelevant; this issue keeps resurfacing on almost every site I consult, usually by low level managers or others who have no knowledge of MQ. When you write to a DB you don't go around checking the data do you? When writing to a local file, net file (scottm), send a TCP packet or whatever - you don't check it, there's just no need; The computer world wouldn't go very far if the two-face-commit algorithm wasn't foolproof.
I highly recommend that instead of trying to find smart technological solutions to stupid (nonexistant) problems, use the art of speech and persuasion to teach the masses what software design is all about, and that parity checks should not be done in the application level. |
|
| Back to top |
|
|
| sjensen |
| Posted: Thu Sep 22, 2005 1:25 am Post subject: |
|
|
Centurion
Joined: 18 Dec 2003
Posts: 134
Location: London
|
| well if the message represent million of dollars it is of some importance that the message can not be tampered with |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Sep 22, 2005 3:15 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| sjensen wrote: |
| well if the message represent million of dollars it is of some importance that the message can not be tampered with |
You statement is true, but I utterly disagree with the approach, which i've encountered many times. Contrary to common opinion, there is no exponential formula that balances re-checks to data importance; that is, if data is highly valuable, it *does not* mean that I shall re-check it 3 times to make sure it's ok.
Design concepts remain the same no matter how critical a system is, the only difference is the money invested in deepening design plans, buying monitoring and recovery products, and implementing "correct" design concepts. A silly test system will have a simple PC with nothing on it, a big Stock Exchange transaction system will have a RAID, a weekly image, a remote copy to another site every day, a monitoring product, and full SSL security setup; it will not have a SELECT after every INSERT to make sure the data is ok, or any MQ parallel.
My point is, each function belongs in a different level; parity checks belong on the communication level - i.e use SSL on your channels. If you suspect someone is getting between you and MQ, tampering with the data just after you MQPUT (highly, highly unlikely) you can encrypt your message via some security API and decrypt it on the other end; But a much better solution would be to simply harden the server with local security policies and normal OS and WMQ permissions. |
|
| Back to top |
|
|
| Cliff |
| Posted: Fri Sep 23, 2005 4:55 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Whilst I don't in any way disagree with the wisdom espoused here, if the requirement is essentially one of audit and/or non-repudiation, proving unequivocally what went into and out of a queue manager, then you could do worse than use linear logs, and a tool like Cressida's Request which can query the logs in a considerably more convenient manner than dmpmqlog. I assume persistent messages, of course!
Just my £0.02 ....
Cheers -
Cliff |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sat Sep 24, 2005 12:28 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
You could sign the message using a PKI algorithm, this gives the receiver the ability to check the message for tampering.
(It requires like TAMPI, that you keep your private certificate secret.)
A simpler solution is a CRC function, that can also detect tampering... aslong as you keep the alogorithm safe.....
I played a lot with SWIFT on international message (payment instructions) transfers and the key points here was: Non-repudiation, no tampering, encryption etc.
Is the data you'll send internal or external ?
If it's internal, you should be able just to use security (RACF, OAM) to keep Mrs. BlackHat out... And keep your messages safe.
The final question is: what amount of $$$$$$ are you allowed to spend ??
I'm shure that the various vendors can help you.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
