DSXchange

Hi,
Has anyone had issues importing copyvbooks with negative definitions?
05 VRUPB1-TOT-XFER-OUT-AMT PIC -9(9).99.
and
05 VRUPB1-TOT-XFER-OUT-AMT PIC S9(9).99.

both fail on importing the table definition. with the following:
ERROR 1 (line 28): 'PIC' PICTURE character string format is invalid.

Thanks - - John

Do your examples actually have two 'dots' in each of them? I'm assuming the trailing one is the issue if those are accurate.

The trailing or last period is standard for delimiting the cobol field definition as shown here from a piece of a copybook that was successfully imported.

05 VRUPI-NUM-XCHNG PIC 9(2).
05 VRUPI-NUM-ALC-CHNG PIC 9(2).
05 VRUPI-GIA-YTD-RMNG PIC 9(9)V99.

OK... been quite some time since I've had any hands-on time with COBOL, for whatever reason that just looked wrong to me. Guess not.

However, I do think there was some recent discussions that the importer doesn't like the "-" syntax but the "S" one should be fine. Let me see if I can find that...

Here's the other conversation, not sure how much help it will be however.

viewtopic.php?t=151383

S9(9).99 is not valid COBOL. It needs to be S9(9)V99 - as the examples that imported successfully show. Have "them" provide a correct copybook.

No, that's perfectly valid. The former shows that the field has an explicit decimal point while the latter is for an implied one. Perhaps DataStage doesn't like it but it is perfectly valid.

Thanks for all your comments. After playing around a bit it seems like all negatives "-" should be replaced with an S and all decimals for negatives replaced with a V.


PIC -9(9).9(02) should be
PIC S9(9)V9(02)


PIC 9(9).9(02) works fine since there is no sign.

Thanks - - John

I've never been able to get "." to work with signed decimal numbers (those beginning with "S") which I've mainly used. That's why I thought that only "V" is valid.

The difference between explicit decimal -- 9(x).9(x) -- and implied decimal -- 9(x)V9(x) -- is in the physical storage of the field on the original record. An explicit decimal takes a byte of storage. Any numeric with a virtual decimal looks the same in storage regardless of the location of the virtual decimal.

The easy workaround for non-binary numerics -- no "COMP" clause of any type on the PIC statement -- is to read them as alphanumeric with positions provided for the decimal and the sign. You must then parse/convert them back to decimal in a transformer stage after input.

For example: PIC -9(9).9(02) can be read as PIC X(13), edited for the leading sign, and either parsed using the decimal as the delimiter or converted directly to decimal.

In COBOL terminology, and non-binary numeric is labelled "DISPLAY". That DataStage cannot handle it is ridiculous from my personal POV, but there it is.