MQSeries.net :: View topic

IanAlderson · Posted: Fri Jun 20, 2014 5:09 am Post subject:

Letting the MQOutput node set the codepage/encoding is sound advice. But I think the problem here for the OP is that he is using a readUTF api which expects a 2 byte length field to precede the data (i.e. not a codepage conversion issue). It's not clear what else he is doing in the compute node but if he is altering the message body in some way, then as far as I can tell he would need to recalculate the byte length for it to be useable for a readUTF call by the client - and I don't believe an MQOutput node will re-add an updated length field for you in the message body. I'd be happy to be corrected if that is the case.

The link I posted shows a workaround from the KC for ESQL to add that field, but it's not pretty. There may well be a better way to construct his flow depending upon what he is trying to achieve.

As suggested earlier, perhaps the simplest solution is for the client app to not use readUTF at all but one of the alternative readString* methods instead. ReadUTF and writeUTF are really more for how java deals with data conversions internally rather than the traditional approach of letting MQ convert to UTF8 for you based on the CCSID/encoding.