| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problem with Receive Exit on v7.0.1.3 for Windows |
View previous topic :: View next topic |
| Author |
Message
|
| Alfredo |
 Posted: Wed Apr 27, 2011 6:53 am Post subject: Problem with Receive Exit on v7.0.1.3 for Windows |
 |
|
Newbie
Joined: 27 Apr 2011
Posts: 2
|
We use Send and Receive Exits to organize some kind of VPN tunnel with national cryptography standards for Server-Server and Client-Server communication. So not only message data, but overall channel data is passed through Send-Receive Exits pair. As per “WebSphere MQ Intercommunication” book recommendations first eight bites of the package is bypassed by Send Exit, as that block is reserved for use by the MCA, then we shift the rest of the data one byte to the right (so the original ninth byte becomes tenth, so on) and set the ninth byte to zero to be the flag, that indicates the package was processed by Send Exit (as per IBM recommendations, seems in original data the ninth byte is always non-zero). After all of that Send Exit emplements some compression and ciphering on data started from tenth byte. Receive Exit checks ninth byte of the package and if it’s zero (so processed by corresponded Send Exit) – makes “undo” operations on the data started from tenth byte and then shifts the result one byte to the left, so we should have at the output of Receive Exit the same package as it was at the entry of Send Exit.
The problem is encountered with our Receive Exit on Receiver and Requester type channels of WebSphere MQ Server v7.0.1.3 on Windows XP SP3 while communicating with WebSphere MQ Server v6 on z/OS. Receive Exit fails with ciphered data consistency check time by time. We made some dumps of the data and found out that 4th bit of 12th byte of the package is set to 1 somehow between Send and Receive exits calls. So as 12th byte is the part of the data, that was processed by Send Exit, if it had 0 at 4th bit of 12th byte after ciphering and then somehow changed to 1 – the consistency check made by Receive Exit is failed of course.
The problem is found only on Receiver and Requester type channels at WebSphere MQ Server v7.0.1.3 and we didn’t try to link it with version of WebSphere MQ Server differ to v6 or other platform then z/OS yet. But with backward way from v7 on WinXP SP3 to v6 on z/OS (Sender channel type on v7 for Win and Receiver channel type on v6 for z/OS) same pair of exit programs works perfectly. Also we tried to replace v7.0.1.3 with older v5.3.1 on Windows and then we also don’t have any problems with any Sender/Receiver/Requester channels. The same Exit program for Windows also perfectly works on Server Connection channels between v7 Client on v7 Server on Windows platform. Server Connection channels between older v5.3.1 WebSphere MQ Client on Windows systems and any WebSphere MQ Server we have (v5.3.1 and v7.0.1.3 for Windows and v6 for z/OS) also don’t reveal problems with our Send and Receive Exits.
So we assumed in version v7 some more bytes then just first eight are used by MCA, including that 12th byte, but found nothing about that in the latest WebSphere MQ documentation, or at least published actual version of Intercommunication book still states only first eight bytes are used by MCA and so restricts only change of that block. Recommendation to shift data started from ninth byte in Send Exit also assumes that the rest of the data won’t be used by MCA till it passed Receive Exit.
We would like to know if someone faced the same problem, or may be other way – have no problems with v7 Server in same situation and so may be that “bit changed” problem is really result of some inner error like “buffer overflow” in our exit we don’t know about.
Thanks for your responses. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Apr 27, 2011 6:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'd check for PTFS for v6 in this area... and try just applying the equivalent of the most recent FP set of PTFs anyway.
Is there a particular reason you are reimplementing MQ channel SSL using exits, rather than the built-in function? |
|
| Back to top |
|
|
| Alfredo |
| Posted: Wed Apr 27, 2011 7:09 am Post subject: |
|
|
Newbie
Joined: 27 Apr 2011
Posts: 2
|
| mqjeff wrote: |
| I'd check for PTFS for v6 in this area... and try just applying the equivalent of the most recent FP set of PTFs anyway. |
I'm not sure the problem is with z/OS side, as the same exit program works perfectly if the other side on Windows station uses v5.3.1 instead of v7.0.1.3
| mqjeff wrote: |
| Is there a particular reason you are reimplementing MQ channel SSL using exits, rather than the built-in function? |
Yes, as I said in introduction - we have to use national cryptography standards and that's nothing about RSA or something like that. Why don't to use good known international algorithms? It's goverment project.... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 27, 2011 7:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I suppose I took an unintentional US meaning for "national". MQ in the US contains strong encryption algorithms that meet US national encryption standards (AES)... but those don't ship elsewhere necessarily and the ones that do don't necessarily meet non-US government standards.
apologies for that.
You won't get very far trying to compare behavior with v5.3... a lot of things have changed and it won't get you very far if you need to open a PMR.
You might try 7.0.1.4 instead of 7.0.1.3... at least to compare against. |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
