| Author |
Message
|
| vishnurajnr |
 Posted: Tue Oct 19, 2021 6:26 pm Post subject: Packed decimal conversion issue |
 |
|
Centurion
Joined: 08 Aug 2011
Posts: 134
Location: Trivandrum
|
Hi,
I have a Java service which is sending messages containing packed decimal format to MQ in the mainframe.
MQMD CCSID set as 1146
MQMD Encoding set as 745
MQMD FORMAT set as NONE
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
If I write the message as bytes - I am able to solve the example 2 issue but then the example 1 issue persists.
If I write the message as String, I am able to solve the example 1 issue, but Example 2 issue persists.
I was referring the mqseries and stack overflow posts here - but could not resolve the issue actually
https://stackoverflow.com/questions/32595419/issue-with-mq-ebcdic-data-conversion-25-interpreted-as-line-feed-and-converted
I was trying different encoding/ccsid options, but not getting much success.
Any help or pointers to resolve this is highly appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Oct 19, 2021 7:07 pm Post subject: Re: Packed decimal conversion issue |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| 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
|
The issue is in your programming.
Either you are passing a byte[] field and the byte values for packed decimal are well documented, or you're not.
Anything due to conversion when there should be none is on your shoulders...
So a value of 8988250 should look as x"89 88 25 0C" if memory serves well. This is the same value in any CCSID as it is the hex representation of the byte[] field. Now if you go and translate this into characters, you're going to your own funeral.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Oct 20, 2021 1:54 am Post subject: Re: Packed decimal conversion issue |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| vishnurajnr wrote: |
MQMD CCSID set as 1146
MQMD Encoding set as 745
MQMD FORMAT set as NONE |
Who is doing the conversion? Not MQ, since you have a format of none which means MQ will not do any conversion.
Perhaps you should show us the code that is reading the message. The Stackoverflow question you linked shows that the entity parsing the data was at fault. So we should see your getting/parsing application code. Are you using Java to do data conversion for example? Does Java know how to handle packed decimal?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| vishnurajnr |
| Posted: Wed Oct 20, 2021 4:47 am Post subject: Re: Packed decimal conversion issue |
|
|
Centurion
Joined: 08 Aug 2011
Posts: 134
Location: Trivandrum
|
| hughson wrote: |
Who is doing the conversion? Not MQ, since you have a format of none which means MQ will not do any conversion.
Perhaps you should show us the code that is reading the message. The Stackoverflow question you linked shows that the entity parsing the data was at fault. So we should see your getting/parsing application code. Are you using Java to do data conversion for example? Does Java know how to handle packed decimal?
Cheers,
Morag |
A Java program inside webmethods ESB will get the input data in String/Number and transform the data to the COBOL copybook format which contains the packed decimal and then sent to the mainframe system over MQ
Here the Java service will do the conversion to packed decimal format and the converted message will be PUT to an MQ Queue and the mainframe will consume from there.
We can see via RFHUtil/Cobol parser the structure of the data and values and we could see the15 converting to 25 or vice versa. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Oct 20, 2021 1:24 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
So at which point do you think the change is taking place?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Oct 20, 2021 3:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| Java service will do the conversion to packed decimal format and the converted message will be PUT to an MQ Queue |
Do a hex dump of the message immediately before putting it to MQ. It will probably show that the Java conversion logic is not quite correct.
| Quote: |
| transform the data to the COBOL copybook format which contains the packed decimal and then sent to the mainframe system over MQ |
Another case for not using platform specific data formats in MQ messages. At least the COBOL fields could have been unpacked decimal EBCDIC !
_________________
Glenn |
|
| Back to top |
|
|
| vishnurajnr |
| Posted: Thu Oct 21, 2021 6:47 am Post subject: |
|
|
Centurion
Joined: 08 Aug 2011
Posts: 134
Location: Trivandrum
|
I think i found the root cause of the issue. It is the character encoding used which is changing the byte stream.
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.
Thanks all for the support..  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 21, 2021 8:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What's the CCSID of the source system? What o/s?
What's the CCSID of the target (mainframe) system?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Oct 21, 2021 2:04 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| vishnurajnr wrote: |
I think i found the root cause of the issue. It is the character encoding used which is changing the byte stream.
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.
Thanks all for the support.. |
With your random solution, what exposure do you think you have to other bytes randomly changing to other values? Can you do an exhaustive test of all values?
_________________
Glenn |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Oct 21, 2021 2:10 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
What's the CCSID of the source system? What o/s?
What's the CCSID of the target (mainframe) system? |
Hi Bruce. Given "MQMD FORMAT set as NONE", the MQMD CCCSID and Encoding values are irrelevant. The CCSID and numeric encoding of the target application program is important, and how it treats packed decimal. In this regard, there is probably no difference between the 2 most common app values on z/OS, 37 and 500.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 21, 2021 5:51 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I’m wondering if the Java service app is running on Little Endian or Big Endian hardware. The OP only mentions the target platform z/OS.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| vishnurajnr |
| Posted: Sat Oct 23, 2021 12:56 am Post subject: |
|
|
Centurion
Joined: 08 Aug 2011
Posts: 134
Location: Trivandrum
|
| bruce2359 wrote: |
| I’m wondering if the Java service app is running on Little Endian or Big Endian hardware. The OP only mentions the target platform z/OS. |
The source system is Little Endian here (Linux, version 3.10.0-1160.15.2.el7.x86_64)
| gbaddeley wrote: |
With your random solution, what exposure do you think you have to other bytes randomly changing to other values? Can you do an exhaustive test of all values?
|
Yes, it is another risk here that this encoding can cause another byte conversion. we raised this to uncover such issues during the testing. based on the tests done so far, we don't see any byte conversion issues.
I tested 01 to 99 combination and could not see any issue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 23, 2021 7:11 am Post subject: Re: Packed decimal conversion issue |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| fjb_saper wrote: |
| 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
|
The issue is in your programming.
Either you are passing a byte[] field and the byte values for packed decimal are well documented, or you're not.
Anything due to conversion when there should be none is on your shoulders...
So a value of 8988250 should look as x"89 88 25 0C" if memory serves well. This is the same value in any CCSID as it is the hex representation of the byte[] field. Now if you go and translate this into characters, you're going to your own funeral.... |
Your examples did not result in packed decimal, as FJ observes. The low-order byte will contain the sign value (positive or negative).
You say you tested your code on 01-99. What were the results of each? Please post them here.
http://www.3480-3590-data-conversion.com/article-packed-fields.html offers examples of what packed-decimal fields look like.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| vishnurajnr |
| Posted: Sun Oct 24, 2021 6:34 am Post subject: Re: Packed decimal conversion issue |
|
|
Centurion
Joined: 08 Aug 2011
Posts: 134
Location: Trivandrum
|
| bruce2359 wrote: |
| fjb_saper wrote: |
| 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
|
The issue is in your programming.
Either you are passing a byte[] field and the byte values for packed decimal are well documented, or you're not.
Anything due to conversion when there should be none is on your shoulders...
So a value of 8988250 should look as x"89 88 25 0C" if memory serves well. This is the same value in any CCSID as it is the hex representation of the byte[] field. Now if you go and translate this into characters, you're going to your own funeral.... |
Your examples did not result in packed decimal, as FJ observes. The low-order byte will contain the sign value (positive or negative).
You say you tested your code on 01-99. What were the results of each? Please post them here.
http://www.3480-3590-data-conversion.com/article-packed-fields.html offers examples of what packed-decimal fields look like. |
The COBOL structure contains files in packed decimal and fields in the non-packed decimal structure. So the message is a combination of packed decimal and picture. Example as follows
| Code: |
05 ITEM-CODE PIC S9(7) COMP-3.
05 SAP-SUPPLIER-NO PIC S9(7) COMP-3.
05 HQ-START-DATE PIC X(10).
05 SAP-SUPP-GROSS-PRICE PIC S9(5)V9(4) COMP-3.
05 SAP-CURRENCY-DESC PIC X(7).
05 SAP-QTY-PER-GROSS-PR PIC S9(5) COMP-3.
05 SAP-QUANTITY-DESC PIC X(6).
05 SAP-ORD-TRADE-DISC-1 PIC S9(3)V99 COMP-3.
05 SAP-WHSE-DIR-ORD-TERM PIC X(1).
05 SAP-ORD-TRADE-DISC-2 PIC S9(3)V99 COMP-3.
05 SAP-ORD-TRADE-DISC-3 PIC S9(3)V99 COMP-3.
05 SAP-ORD-TRADE-DISC-4 PIC S9(3)V99 COMP-3.
|
Testing is injecting a different combinations of data to MQ and verifying using RFHUtil.
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 24, 2021 7:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Was any of your testing successful? What did the successes have in common?
What did your testing failures have in comm?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
