David, forgive me for being slow.. but can you expand? The RFH2 follows the 428 bytes... and has EBCDIC newlines in it? convert(yes) on the MVS sender channel does not cause the RFH2 to be converted? Your sender msgexit passes this on, and before it gets to your receiver msgexit the newlines only have been converted into ASCII ones?
Are the EBCDIC newlines in the RFH2 'fixed fields' or in the data section? (in theory EBCDIC is not supported in the data section is it? just Unicode or UTF-8). Not sure of all the points that MQ uses this info... but is either end using this option in their qmgr config? ConvEBCDICNewline=NL_TO_LF|TABLE|ISO Certainly sounds like it's happening at an odd time though. Regards Darren. ----- Original Message ----- From: "David C. Partridge" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 06, 2003 4:21 PM Subject: Re: Strange behaviour on channels with message exit > Problem is now understood. > > The buffer passed to the sending message exit included an RFH starting at > offset decimal 428, which was also the value in MQCXP.HeaderLength. Our > message exit encrypted everything at and beyond offset 428. > > The data passed to the receiving message exit, was *almost* the same as that > which left the sending message exit, except that any x'15' characters were > converted to x'25'. The value of MQCXP.HeaderLength at the receiving > message exit was also 428. We of course (because we HMAC the data) > detected this and dropped the channel. > > Looks like the channel code is "dinking" with data beyond MQCXP.HeaderLength > when it attempts to convert MQ header data to local representation before > calling the message exit (naughty, naughty). > > We're asking our customer to open a PMR against MQ and get the change team > to talk to us. > > PS If Mike Horan is lurking, this should warn him that there's a probable > APAR coming his way. > > Cheers > Dave > -----Original Message----- > From: David C. Partridge [mailto:[EMAIL PROTECTED] > Sent: 04 August 2003 15:26 > To: MQSeries List > Subject: Strange behaviour on channels with message exit > > > A customer is reporting a problem where a cryptographic check-sum failure is > being reported by our channel message exit. > > Analysis of the traces shows that x'15' characters in the data leaving the > 390 are being converted to x'25' characters on receipt on the AIX system. > > Interestingly x'15' is EBCDIC new line, while x'25 is the ANSI new line > character. > > These appear to the only characters that are getting hit. > > The only thing I can think of that could possibly cause this is some code > trying to do new-line conversion, but surely a sender channel with > CONVERT(YES) would do its work before any message exits are called rather > than after. > > Has anyone got any rational explanation for what is happening here? > > Regards, > David C. Partridge > Security and MQ Products Manager > Primeur Group > Tel: +44 (0)1926 511058 > Mobile: +44 (0)7713 880197 > > 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
