|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Zoned decimal output |
« View previous topic :: View next topic » |
Author |
Message
|
meekings |
Posted: Tue May 07, 2002 10:55 am Post subject: |
|
|
 Voyager
Joined: 28 Jun 2001 Posts: 86 Location: UK, South West
|
I'm creating a zoned decimal output field destined for MVS from an AIX box. The CWF specifies Extended Decimal, 4 bytes, Signed, Included Trailing, and the Compute node sets CodedCharSetId to 500 to force conversion to EBCDIC on output.
-1234 produces F1F2F3D4, +1234 produces F1F2F3F4. My Cobol's a little rusty, but I seem to remember that B or D in the zone field represents negative, C or F represents positive, but that strictly D should be used for negative, and C for positive, so that +1234 should really come out as F1F2F3C4.
Could anybody clarify for me?
This occurs with both 2.0.2 and 2.1 CSD02. |
|
Back to top |
|
 |
CodeCraft |
Posted: Tue May 07, 2002 12:42 pm Post subject: |
|
|
Disciple
Joined: 05 Sep 2001 Posts: 195
|
The proof in the pudding here is not what you see, but what is accepted by the target host.
If I remember correctly, there's a difference between MVS and AS/400 where the AS/400 doesn't like the 'C' in the sign nybble, even for signed positive numbers.
The 'C' is designated as the 'preferred' positive sign, but in fact there are a whole raft of signs accepted. Since 'F' should be accepted by both AS/400s and MVS as positive for both signed and unsigned, this is what WMQI should output when writing zoned decimal to an EBCDIC CCSID.
This is because WMQI has no way of knowing whether the actual target system would be an AS/400 or MVS system.
The rules should be as follows going to/from an EBCDIC host.
When being received by WMQI:
D accepted as '-' for signed negative.
F,C accepted as '+' for signed postive.
F accepted as '+' for unsigned positive.
When being written by WMQI:
D written as '-' for signed negative.
F written as '+' for signed positive, and unsigned positive.
This is loosely from memory. There were a couple of APARs in 2.0x for this, but the latest CSDs should have this behaviour (if what I remember is correct). 2.1 should also have this behaviour.
The only downside to this is that on a round trip, if you parse and rewrite the data, something arriving as F1C1 would go back as F1F1 (the representation of the sign will change, but the meaning will be the same). |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|