Cobol Zoned-Decimal Negative Numbers ...

system · February 26, 2008, 7:38pm

I have a Cobol copybook that defines a field as PIC S9(8)V99.

For all “positive” numbers, I am receiving valid results through my mappings.

For negative numbers ending in “0” (zero), I am getting valid results through my mappings.

My issue is, for any negative number where the “pennies” column is 1 - 9 I get invalid results.

My understanding of Zoned-Decimal is that the last byte will contain “A” through “I” for digits 1 - 9 positive and “J” through “R” for digits 1 - 9 negative. Positive zero = “{” and negative zero = “}”

I am receiving a value of ‘000000291Q’ which should resolve to -29.18, but instead it is resolving to -29.11. I have verified this back to the file source, and I have used Designer Data-Profiling to verify this from the source itself before passing it through a Dataflow.

So … Can someone please assist me in this?

I do not want to change the copybook to VARCHAR(10) and then write a custom transform to manage the type conversion to numeric based on a decode of the last byte, but I will if I have to. Argh!!!

Thanks …

Jeff in Chicago …

(Note: I cross posted this in Data Quality & Admin forums as well to see if I could get a reply quickly)

jwilgus (BOB member since 2008-01-17)

system · February 27, 2008, 6:53am

Hi Werner,

This seems to be a bug. Or, rather, unsupported compiler (I wonder what compiler was used by Jeff).

Here’s the info from https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.dfdl-wg/docman.root.current/doc5442;jsessionid=75824D7B2D70652A6F7507CE5659C7D8 :

"What characters are used to represent overpunched positive and negative digits, varies by character set and Cobol compiler and system. By far the most common convention is the EBCDIC one described here used on IBM mainframe systems.

In EBCDIC character sets, overpunched characters ‘}JKLMNOPQR’ represent a negative sign and digits 0 to 9. The characters ‘{ABCDEFGHI’ represent a positive sign and digits 0 to 9.

In ASCII character sets, there are several conventions:

EBCDIC converted style: The overpunched character is the ASCII equivalent of the EBCDIC above. In other words, characters ‘}JKLMNOPQR’ still represent negative sign and digits 0 to 9 even though when looking at the bytes in hex this makes no sense whatsoever because the “}” character has ASCII code 0x7B.

MicroFocus and Microsoft Cobol Style: ASCII characters ‘pqrstuvwxy’ represent negative sign and digits 0 to 9. ASCII characters ‘0123456789’ represent a positive sign and the corresponding digit. (Sign nibble for ‘+’ is 0x3, which is the high nibble of these character codes unmodified.)

CA Realia Compiler Style: ASCII characters ‘pqrstuvwxy’ represent negative sign and digits 0 to 9. ASCII characters from code 0x20 to 0x29 are used for positive sign and the corresponding decimal digit. These characters include the space (‘ &#8216 for zero, characters ‘!”#$%&’ for 1 through 6, the single quote character “’” for 7, and the parenthesis ‘()’ for 8 and 9."

I was able to develop an algorithm to determine the sign in a generic manner: I am checking the high (upper) nibble and, if it is greater than 4, I make it a negative number. This works for all compiler styles above.

Then, to get the over-punched digit value, I simply extract the low nibble value. It works for EBCDIC (IBM MainFrame) and MicroFocus (Also used by Microsoft and Fujitsu) compiler styles from the list above, which are the most common compiler types on the market and allows me to avoid hard-coding specific character strings.

So, here’s the problem: the second part (getting the digit value) does not work for negative values in EBCDIC converted style (ASCII) and for CA Realia Compiler Style. If Jeff wants to get it fixed, this should be a feature request.

Werner Daehn (BOB member since 2004-12-17)

system · February 27, 2008, 2:02pm

wdaehn,

Thanks for your reply. Well then, this certainly seems to be a bug, because the “rule” is being applied inconsistently in the transcoding. I’ve verified via screenprints from both the mainframe and the data received that a value such as 000000291Q is coverting as expected using codepage ibm-37_p100-1995. So, we do not have the situation where a EBCDIC “J” is being converted to an ASCII “q” for example. We are receiving and reading a “Q” as the zoned over-punch byte.

It is hard for me to believe that we are the first DI users to encounter the inability to handle negative zoned-decimal numbers through DI. What have others done that have encountered this issue?

The word document you referenced in your posting indicated the existence or the need for a property “overpunchedASCIISignStyle” to set which version of transcoding to use when the user knows what “style” they are receiving for the zoned decimal.

Does this parameter exist? What are my options? Are you suggesting then that I code around the issue for now until such time as BOBJ can provide a fix?

Please advise ASAP so that I know how to respond. This is a very serious issue as it is causing all adjusted claim amounts to either be off by 7 cents and/or to have unpredictable results.

Thanks again for you response, and I’ll await your reply.

Jeff

jwilgus (BOB member since 2008-01-17)

system · February 27, 2008, 4:32pm

Very good post, Jeff.

I have been doing a lot this type conversion, fortunately have not encountered the problem you have yet. But I am very interested in knowing the results.

Billy_qing (BOB member since 2007-11-16)

system · February 27, 2008, 6:15pm

Thanks Billy_qing …

I’m sorry that I have to be the first one to encounter this issue.

I’m thinking of having the mainframe change the format from PIC S9(8)V99 … zoned-decimal … to PIC S9(8)V99 COMP-3 … packed decimal to see if DI would interpret the data correctly?

In the meantime, that does not help me for the 10s of millions of historical claims that have already been loaded!

I’ve opened a case with BOBJ.

More to follow … I hope with good news!

Thanks again,

Jeff

jwilgus (BOB member since 2008-01-17)

system · September 29, 2010, 6:15pm

I am currently using Data services v12.2.2.0 and am having the exact issue described above. Has a solution to this been implemented or is there a work around?

jdferron (BOB member since 2010-09-29)

system · October 5, 2010, 9:02am

Good question.

Can you call up support and ask them to find the Support case that relates to this post?

Werner Daehn (BOB member since 2004-12-17)

system · October 5, 2010, 4:28pm

There was no record of a previous support ticket on this issue so I opened a new one.

They have confirmed that it is a bug and are currently looking into the cause. I will try to remember to post any results…although it may be a while.

Also, I did find that if the first zoned decimal field in the flat file is a positive number all of the records that follow will be translated correctly. Very odd I know but that seems to be the case.

jdferron (BOB member since 2010-09-29)

system · October 6, 2010, 5:17pm

If you would post the case number or better the ADAPT number, that would help for later reference.

Werner Daehn (BOB member since 2004-12-17)