| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Packed decimal conversion issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| vishnurajnr |
 Posted: Sun Oct 24, 2021 8:58 pm Post subject: |
 |
|
Centurion
Joined: 08 Aug 2011
Posts: 134
Location: Trivandrum
|
| bruce2359 wrote: |
Was any of your testing successful? What did the successes have in common?
What did your testing failures have in comm? |
Yes, testing so far seems successful. The mainframe is able to receive the data with the expected values (15 are not getting converted to 25 and vice versa).
Testing failures - I think I explained earlier that some of the field values received at the mainframe shows modified values. This was the failure scenario.
To make it clear - it was all working fine for the input values does not have these 15 or 25 values.
| vishnurajnr wrote: |
The issue is happening for certain inputs containing 15 is getting converted as 25 in the packed decimal format while writing to MQ.
Example1 - value send as 8988250 is converted as 8988150
Example 2 - Value send as 0115924 is converted as 0125924
|
|
|
| Back to top |
|
 |
| rekarm01 |
| Posted: Wed Oct 27, 2021 5:55 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Is this Java, or JMS? If it's JMS, then is it a TextMessage, or a BytesMessage?
| vishnurajnr wrote: |
| I think i found the root cause of the issue. It is the character encoding used which is changing the byte stream. |
No, the root cause is that the Java application assumes that the entire message contains character data, when it's really a mix of character strings and packed decimals (and other stuff?). If MQ were converting the character data, then it would need the MQMD FORMAT to identify which bytes are which. If Java were converting the data outside of MQ, then it would need the same information. The resolution is to find and fix (or eliminate) any improper conversions.
Performing any character conversions on packed decimals is always wrong, because packed decimals are not characters. In the best case, two conversions will cancel each other out (for example, from EBCDIC to ASCII and back again), preserving round-trip integrity, and only temporarily corrupting the packed decimal data, before setting it right again.
EBCDIC ccsids define two different end-of-line characters, NL (X'15') and LF (X'25'), but 7-bit ASCII only defines one of those, LF (X'0A'). Different EBCDIC ccsids may map NL differently (for example, either to 7-bit ASCII LF (X'0A'), or to ISO 8-bit NEL (X'85')), possibly depending on the some external value, such as the MQ ConvEBCDICNewline attribute. So for some ccsids, round-trip conversions may end up mapping an EBCDIC NL (X'15') to an EBCDIC LF (X'25'). And when performing the same conversions on a packed decimal byte that happens to look like an EBCDIC NL, then the same thing would happen.
| vishnurajnr wrote: |
The character encoding used was IBM037 which will convert bytestream 25 as 15. If we use the char encoding as IBM01146 - it will convert bytestream 15 as 25.
Most of the IBM0XX encodings are changing the 25 to 15 (just based on random tests). And most of the IBM1XXX are changing the 15 to 25 (just based on random tests)
Finally, I randomly found IBM1047 is not doing this conversion and choosing this encoding resolves my issues. |
Randomly swapping out one ccsid for another is never a good idea. That might seem to work, at least temporarily, until someone else changes some obscure attribute, or applies the latest fixpack, or discovers that it may have fixed one problem (with the packed data), while introducing a different problem (for example, partially corrupting character strings instead). |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
