| Author |
Message
|
| abetaev |
 Posted: Tue May 29, 2012 2:43 am Post subject: Parsing error: strange signed decimal format from backend |
 |
|
Novice
Joined: 10 May 2012
Posts: 12
|
Hello,
I've met a problem when parsing decimals from backend.
There is decimal format which is defined in COBOL in the following way:
| Code: |
| 04 MONEY-AMOUNT S9(3)V99 SIGN TRAILING. |
This format assumes the ASCII decimal string with sign which embedded into the last character:
0x3132333435 equal to 123.45
0x3132333475 equal to -123.45
But backend's format is a little bit different from standard:
0x31323334B5 comes from backend for -123.45 instead of 0x3132333475.
The difference is in two bits:
0xB5=0b10110101
0x75=0b01110101
Parser throws an exception and nothing helps (except changing message set and parsing such decimals manually).
Does anybody know how to configure message set or broker in order to work with such format?
--
Thanks and regards,
Alexander |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue May 29, 2012 3:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
First rule: If the input message is different between a working case, and a non-working case, then it's the input message that's wrong in the non-working case.
Second rule: make sure, and I mean absolutely sure that it is only those two bits that are different.
If, say, the CCSID on the two messages is also different, then the problem isn't that the two bits are wrong. |
|
| Back to top |
|
|
| abetaev |
| Posted: Tue May 29, 2012 4:22 am Post subject: |
|
|
Novice
Joined: 10 May 2012
Posts: 12
|
Hi mqjeff,
Thanks for the answer!
I really don't know if CCSID which is sent by backend is correct. This is because backend seem to be working incorrectly with encoding: we also have big-endian/little-endian conversion problems because backend system replies with 576 encoding while it should provide 785.
The problem with encoding can be solved using intermediate service which corrects it (and it's the only way I was able to fix that issue). But I am not sure that format of decimal numbers could be affected by such things.
I've looked through http://www.simotime.com/nbrtyp01.htm and toolkit's Information Center regarding signed decimals. Both are saying the same: 0x70 should be used in last digit (for sign trailing of course) instead of 0x30 to mark decimal as negative. But we receive 0xB0. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 29, 2012 4:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| abetaev wrote: |
Hi mqjeff,
Thanks for the answer!
I really don't know if CCSID which is sent by backend is correct. This is because backend seem to be working incorrectly with encoding: we also have big-endian/little-endian conversion problems because backend system replies with 576 encoding while it should provide 785.
The problem with encoding can be solved using intermediate service which corrects it (and it's the only way I was able to fix that issue). But I am not sure that format of decimal numbers could be affected by such things.
I've looked through http://www.simotime.com/nbrtyp01.htm and toolkit's Information Center regarding signed decimals. Both are saying the same: 0x70 should be used in last digit (for sign trailing of course) instead of 0x30 to mark decimal as negative. But we receive 0xB0. |
Right, so it's the encoding that's causing this problem.
If they can't mark the message with the correct encoding, then they are not sending the message correctly, and there's nothing you can do to ensure that you process it correctly. |
|
| Back to top |
|
|
| abetaev |
| Posted: Tue May 29, 2012 5:07 am Post subject: |
|
|
Novice
Joined: 10 May 2012
Posts: 12
|
mqjeff,
But I'm sure that their encoding will not change. Do you know where I can find correct encoding/CCSID for such decimal format? I could not find such on the web. I've already tried all combinations which were available in RFHUtil.
Thanks! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue May 29, 2012 5:23 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| abetaev wrote: |
mqjeff,
But I'm sure that their encoding will not change. Do you know where I can find correct encoding/CCSID for such decimal format? I could not find such on the web. I've already tried all combinations which were available in RFHUtil.
Thanks! |
Why can't you get the encoding changed? If they are sending it wrong then there really is little you can do about it.
The old principle of
Garbage In Garbage Out
may well apply.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| abetaev |
| Posted: Tue May 29, 2012 6:30 am Post subject: |
|
|
Novice
Joined: 10 May 2012
Posts: 12
|
Hi smdavies99,
Thanks for joining discussion.
I tried to change the encoding. But it affects integers and packed decimals only. Here is problem with decimal which is sent in ASCII string.
I think it may be fixed with an appropriate CCSID, but not sure. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 29, 2012 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abetaev wrote: |
| I think it may be fixed with an appropriate CCSID, but not sure. |
I'm less certain; that's an unusual sign encoding. What OS / platform is that backend running on? What flavour of COBOL?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 29, 2012 6:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abetaev wrote: |
| But I'm sure that their encoding will not change. |
How can you be so sure? What consumes their record currently? If it's another external system find out what that external system is using.
If that record is currently only consumed by another COBOL application running on the same backend platform (i.e. internally within the backend), welcome them to the outside world & have them put the clause SEPARATE on the definition.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abetaev |
| Posted: Tue May 29, 2012 6:53 am Post subject: |
|
|
Novice
Joined: 10 May 2012
Posts: 12
|
Hi Vitor,
Thanks for joining the thread.
There're no external systems connected to that service.
What do you mean with "put SEPARATE clause"? (I suggest it is another decimal format with separate sign.)
The only thing I know for now is that service is running on some kind of HP NonStop system. I will learn more about backend system. |
|
| Back to top |
|
|
| abetaev |
| Posted: Tue May 29, 2012 7:10 am Post subject: |
|
|
Novice
Joined: 10 May 2012
Posts: 12
|
System details:
| Code: |
HPNS NS1008
TACL (T9205H01 - 10MAY2011), Operating System H06, Release H06.23.00
Compaq COBOL85 for NonStop Himalaya Systems
COBOL85 - T9257H01 - (15 MAR 09)
Copyright 1985 Compaq Computer Corporation |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 29, 2012 7:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abetaev wrote: |
| There're no external systems connected to that service. |
So the only thing currently consuming that rather odd format is another application which uses the same odd format. They need to accept that the outside world has turned up.
| abetaev wrote: |
| What do you mean with "put SEPARATE clause"? (I suggest it is another decimal format with separate sign.) |
I mean make it SIGN TRAILING SEPARATE which does what you suggest it does. It's a very simplistic change that doesn't impact their logic, only the amount of storage they use (increases the size of the number 1 byte).
| abetaev wrote: |
| The only thing I know for now is that service is running on some kind of HP NonStop system. I will learn more about backend system. |
Could be some kind of ancient VMS COBOL.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed May 30, 2012 6:13 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
It's an unusual overpunch style, used by Tandem NonStop. After some searching I found somebody else with the same problem: http://www.digipedia.pl/usenet/thread/1882/3237/
Best option is to model it as a BLOB ( xs:hexBinary ). If the number is required by the flow, some custom parsing logic will be required because the MRM parser does not support this style of overpunched decimal. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed May 30, 2012 6:26 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
Could be some kind of ancient VMS COBOL. |
The VMS Cobol Compiler was always as close to the ANSII Cobol Standard as possible.
As has been indicated that this is data coming from the monstrosity called Tandem/Compq/HP Non-Stop. nothing was ever to standard there (apart from Tandem's own Standards that is)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| abetaev |
| Posted: Thu May 31, 2012 2:19 am Post subject: |
|
|
Novice
Joined: 10 May 2012
Posts: 12
|
kimbert,
thanks for that link!
Guys,
Thanks again for your answers. I think this issue can be marked as resolved now. |
|
| Back to top |
|
|
|
|
