ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Packed decimal conversion issue

Post new topic  Reply to topic Goto page 1, 2  Next
 Packed decimal conversion issue « View previous topic :: View next topic » 
Author Message
vishnurajnr
PostPosted: Tue Oct 19, 2021 6:26 pm    Post subject: Packed decimal conversion issue Reply with quote

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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Tue Oct 19, 2021 7:07 pm    Post subject: Re: Packed decimal conversion issue Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Wed Oct 20, 2021 1:54 am    Post subject: Re: Packed decimal conversion issue Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
vishnurajnr
PostPosted: Wed Oct 20, 2021 4:47 am    Post subject: Re: Packed decimal conversion issue Reply with quote

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
View user's profile Send private message Visit poster's website
hughson
PostPosted: Wed Oct 20, 2021 1:24 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
gbaddeley
PostPosted: Wed Oct 20, 2021 3:22 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
vishnurajnr
PostPosted: Thu Oct 21, 2021 6:47 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Thu Oct 21, 2021 8:11 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
gbaddeley
PostPosted: Thu Oct 21, 2021 2:04 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
gbaddeley
PostPosted: Thu Oct 21, 2021 2:10 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
bruce2359
PostPosted: Thu Oct 21, 2021 5:51 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
vishnurajnr
PostPosted: Sat Oct 23, 2021 12:56 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Sat Oct 23, 2021 7:11 am    Post subject: Re: Packed decimal conversion issue Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
vishnurajnr
PostPosted: Sun Oct 24, 2021 6:34 am    Post subject: Re: Packed decimal conversion issue Reply with quote

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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Sun Oct 24, 2021 7:12 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Packed decimal conversion issue
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.