| Author |
Message
|
| Calvino |
 Posted: Tue Oct 18, 2005 4:41 am Post subject: ASCII to EBCDIC signed field translation of zeros |
 |
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
Hi
We have come across an odd problem in one of our v5 message flows - wondered if anyone else has seen similar??
We are using WBIMB v5 CSD6 on AIX. We have a message coming in from our ecommerce platform which contains a signed field. We want to translate this to EBCDIC for our mainframe systems.
The field is defined to the MRM-CWF and imported via a Cobol copybook which has it defined as "FieldA PIC S9(6)V9(2)". This definition is exactly the same on the output message to the mainframe.
What we have found is that non-zero positive and negative values are translated correctly, e.g. ASCII '0000001q' translates to '0000001J'
However . . . .
ASCII '00000000' is passed through as-is. We would expect this to be transalated to '000000{'. Even odder is that a 'negative zero' behaves the same way ie: '0000000p' translates to '00000000' NOT to '0000000}'.
I've tried various combinations of things to get this working - e.g. setting up the 'Sign EBCDIC custom' tickbox on the output message; generating v5.0 ESQL (we had been generating V2.1) but nothing seems to work.
Is anyone aware of any change in behaviour between v2.1 and v5 or has anyone seen similar?
Thanks for any help!
Corrine
[/i] |
|
| Back to top |
|
 |
| EddieA |
| Posted: Tue Oct 18, 2005 8:54 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Why should this matter. Are your receiving applications doing something different with +0 and -0.
Actually, the question really should be why is the sending application sending +0 and -0. 0 is 0, it is not signed.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Calvino |
| Posted: Tue Oct 18, 2005 11:28 pm Post subject: |
|
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
Hi Eddie
The value is not always zero and can be negative - but you're right in that if it IS zero then it doesn't matter whether it's positive or negative.
The problem is with the way that an overpunch sign zero is represented in EBCDIC in general I think. Our legacy mainframe app in this particular case has a test to say something like "IF FieldA =0 then do X". This test is failing which is how we noticed the problem.
I would expect the following scenario:
FieldA in ASCII PIC S9(3) = (+) "100" ie x'313030'
FieldA in EBCDIC PIC S9(3) = (+) "10{" ie x'F1F0C0'
What we actually get in EBCDIC is "100" ie x'F1F0F0'
ie Hex positive zero in a signed field is x'C0' but we always get x'F0' instead. Surely this is wrong???
Cheers |
|
| Back to top |
|
|
| schofier |
| Posted: Wed Oct 19, 2005 2:47 am Post subject: |
|
|
Novice
Joined: 10 Dec 2003
Posts: 14
Location: IBM Hursley
|
xC0 is the preferred sign for positive zero on some machines (e.g. OS/390 - z/OS). However the preferred sign can vary depending upon the actual hardware architecture.
In general, A, C, E and F are all valid signs for a positive number. (this can usually be controlled via compiler options)
There is a known requirement to provide user control over the preferred sign (in a manner similar to the current support for packed decimals). However, at the moment the broker will (as you have discovered) generate xF0 on output. (Note that it will accept xC0 on parse)
As an aside, the 'Sign EBCDIC Custom' support is only applicable in an ASCII environment. This is determined by the value of the CCSID property. |
|
| Back to top |
|
|
| Calvino |
| Posted: Wed Oct 19, 2005 6:39 am Post subject: |
|
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
| Thanks schofier. Not exactly what I wanted to hear though ... lookslike we have to code a workaround until the requirement comes through |
|
| Back to top |
|
|
| schofier |
| Posted: Wed Oct 19, 2005 7:33 am Post subject: |
|
|
Novice
Joined: 10 Dec 2003
Posts: 14
Location: IBM Hursley
|
Just to clarify :
Although its a known requirement, this doesn't necessarily mean it will get implemented. It has to compete with all the other known requirements ! 
If you feel strongly about this, then your best bet is to contact IBM via the official support channels. |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Oct 19, 2005 7:52 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| The value is not always zero and can be negative |
But your original question was only about zero values.
| Quote: |
| IF FieldA =0 then do X |
Should work, for COBOL, if FieldA contains x'F0' or x'C0'. Or it used to in my COBOL days. If it doesn't, or if it's a different language, and doesn't, I'd raise it with the Compiler folks, as that's an obvious bug.
Also, COBOL treats "unsigned" values as positive.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Calvino |
| Posted: Thu Oct 20, 2005 12:17 am Post subject: |
|
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
Thanks Guys
The code is COBOL but due to a combination of circumstances we have only just discovered this bug shortly before implementation and the mainframe folks don't want to change their code or compiler options at this stage - so it's down to us to code around it .... 
You've given me a lot of useful info though and once we can get the implementation out of the way I'll definitely investigate this further and see if we can come up with a more elegant solution ... (failing which we'll raise a requirement with IBM!)
If I do find anything else out I'll post it here though.
Thanks again for your help
Corrine |
|
| Back to top |
|
|
|
|
