| Author |
Message
|
| martinrydman |
 Posted: Tue Jun 14, 2005 9:59 am Post subject: Trailing sign in CWF External Decimal field |
 |
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi,
Im sending EBCDIC data to a OS390 system. All is well, except for some numeric fields, defiend as S9(9) (for instance).
Our counterpart on the OS390 expects a x'C0' for positive numbers and x'D0' for negative numbers as the last byte of the field. The only standard setting I've found that does something similar is the Trailing Separate Sign Orientation, but it inserts the more logical '+' or '-' as the last byte.
Any clues as how to handle this?
/Martin |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jun 14, 2005 10:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think this is a packed decimal thingy. You'll have to either hand code it with ESQL, or use CWF to model the data.
Then I believe there is an option in the CWF handling for packed decimals that lets you specify this. If my faulty memory is correct.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Jun 14, 2005 11:10 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I think this is a packed decimal thingy |
Nope. It's signed, external decimal.
I'm fairly sure this can be handled in CWF. Try importing a test COBOL copybook with one of these fields to see what it generates.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| martinrydman |
| Posted: Tue Jun 14, 2005 12:29 pm Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi, and thanks.
Eddie is right, it's not a packed field. Those, by the way, work a charm. Also, I did import a copy-book, and it got the COMP-3 (packed) fileds right with no further action. It's the unpacked fields that causes this. There are two options for trailing sign:
| Quote: |
Included Trailing. This sets a bit in the last byte on if the number is negative. No setting is made if the number is positive. Using this option, the number +22 would be x'3232' and the number -22 would be x'3272'.
Separate Trailing. This sets the last byte of the element to '+' if the number is positive and to '-' if the number is negative. For this option, the length must include the sign byte.
|
None of these do the trick, unfortunately. So, any further imput?
/Martin |
|
| Back to top |
|
|
| schofier |
| Posted: Wed Jun 15, 2005 2:24 am Post subject: |
|
|
Novice
Joined: 10 Dec 2003
Posts: 14
Location: IBM Hursley
|
Ensure that your element is defined as :
a) Signed
b) Sign Orientation = Trailing or Leading (depending on whether you want the sign nibble at the start or end of your field)
c) Ensure that your output message codepage is an EBCDIC codepage
You should then get 'C' for positive numbers and 'D' for negative numbers |
|
| Back to top |
|
|
| martinrydman |
| Posted: Wed Jun 15, 2005 9:54 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi,
I've done all you suggest and, yes, the C and D appears on the *packed* fields but note the unpacked
/Martin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 15, 2005 10:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| martinrydman |
| Posted: Wed Jun 15, 2005 10:47 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
|
| Back to top |
|
|
| schofier |
| Posted: Thu Jun 16, 2005 12:30 am Post subject: |
|
|
Novice
Joined: 10 Dec 2003
Posts: 14
Location: IBM Hursley
|
Hi Martin,
I think I need a bit of clarification here. Can you explain what the difference is between your 'packed' fields and your 'unpacked' fields.
I think that sign 'included' is equivalent to your 'packed' fields.
Reading your first post am I correct in saying that in the 'unpacked' case you expect a separate byte set to 0xC0 for positve and 0xD0 for negative ?
(Note that in the sign 'separate' case the only supported 'characters' for the sign are (as you have observed) '+' and '-' (i.e. U+002B and U+002D))
Thanks
Richard |
|
| Back to top |
|
|
| martinrydman |
| Posted: Thu Jun 16, 2005 3:22 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi,
The unpacked case has Physcal Type set to extended decimal, whereas the packed variety has Packed decimal. And, yes, my counterpart needs a separate byte, just like in your post
For now, I have a dirty solution by decreasing the actual length of the filed by one, inserting a 1 char field right after the decimal field, and manually insert { or }, but I'd hate to keep it if CWF supports this in a proper way.
/Martin |
|
| Back to top |
|
|
| schofier |
| Posted: Thu Jun 16, 2005 7:19 am Post subject: |
|
|
Novice
Joined: 10 Dec 2003
Posts: 14
Location: IBM Hursley
|
Martin,
In a signed external decimal field where the sign orientation is set to 'leading' or 'trailing' (rather than 'Leading Separate' or 'Trailing Separate') then (on an EBCDIC platform) the sign is represented by setting the first half of the first or last byte to be 0xC or 0xD appropriately. (i.e. the signs are packed even for external decimals)
So for example +1234 would be F1F2F3C4 or C1F2F3F4
and -1234 would be F1F2F3D4 or D1F2F3F4
I personally have never come across an extended decimal representation where a whole byte is used to represent the sign (i.e. the first nibble represents the sign and the second nibble is unused (i.e. set to zero.)) Certainly, there is no direct support within CWF for such a representation (apart from the separate sign representation which is limited to U+002B and U+002D as mentioned previously)
Hope this helps
Richard |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Jun 16, 2005 7:26 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| separate byte set to 0xC0 for positve and 0xD0 for negative |
I've never seen that either. It's not the way a PIC S9 field is supposed to work.
| Quote: |
| manually insert { or } |
Why. Just keep that field as part of the "number" and multiply by 10, so the last byte is always C0 or D0.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| martinrydman |
| Posted: Thu Jun 16, 2005 10:32 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Why? Well, I guess it's just my lack of understandig of what's really going on on the mainframe (not my area of expertise...). I'm not exactly sure how multiplying by ten will yield C0 and D0, but I'm sure when I try it out I'll understand it.
I feel I need to sit down with my counterpart and try the different settings again. It may be that I'm missing something obvious here, and reiterating all my attempts may show I've overlooked something.
Anyway, for no we produce curly brackets, and my counterpart is happy...
Thanks all for your input!
/Martin |
|
| Back to top |
|
|
|
|
