DSXchange

Hi All,
I have a problem with numbers having more then 15 digits.
I have a decimal(20) definition and a number totaling 16 digits or more.
as a test case (for whom ever wants to try this), I built a transformer that generats 1 row with a 14-20 digits long numbers as columns, then passes them thru a transformer (doing nothing) and outputting the row to a sequential file, all numbers with more then 15 digits get their least segnificant digits turned to zeros, depending on the length of the number (i.e: 1234567890123456 turns to 1234567890123450, a 17 digit number would have it's 2 least segnificant digit turned to zeros and so on)

I found the EXACTNUMERIC configuration parameter in the uvconfig file that has the default value of 15 and max value of 57 and set it to 30 + stop DS + uvregen + start DS + recompile job + rerun job but still same behaviour .

Does anyone have any idea on resolving this?
I would like to know if this is only on my platform or do others have the same behaviour.

Thanks in Advance,

This one is tricky. Default precision is 15 but should be able to be modified with the EXACTNUMERIC configuration parameter.

Execute the command smat -t | grep EXACTNUMERIC to determine whether your change was effective.

Try editing the JOBCONTROL.H file (in the DSINCLUDE subdirectory), adding the following line anywhere in the file. Then recompile your job. I don't know whether this will work or not; you may get an error.
Let us know the result. If it works I'll explain why it works. If it doesn't work, remove the line from JOBCONTROL.H.

If it doesn't work, log a support call. As a workaround use the string math functions (SADD, SSUB, SMUL and SDIV) that perform arithmetic operations on strings of any length.

For some reason I found this strangely amusing:

ray.wurlod wrote:If it works I'll explain why it works. If it doesn't work...

... Pay no attention to the man behind the curtain. I've filed away the tip about the 'string math' functions, didn't even know they existed. Thanks Ray. Curious if this works for you Roy.

Thanks Guys,
As it happens were in holydays till the 13th,
so I'll check it then.
DS will not mess around with the number if it has leading zeros (from a DB that still has it as character with a char(20) even when it goes to a decimal(20,0) column to sequential files (that I understand, since DS won't chage the data, unless we tell it to, it really treats the number as a string and leading zeros are gone when it is inserted to a numeric(20,0) column in the DB.)
basically no math is required on those numbers, they were strings, but someone thought it would gain performance to turn them numeric numbers (what a mistake!!! ), now I have to live with that (hopefully not for to long).
I found that there is no problem if I change the metadata to varchar on this column, even ORACEL takes it in with no warnings.

I'll post my findings

Thanks again,

Hi,
smat gave EXACTNUMERIC 30 which means the change was made, but still same behaviour.
adding PRECISION 29 to JOBCONTROL.H file gave compilation error, but PERCISION=29; got compiled, alas same behaviour .

I'll Check with my support.

In case you havnt resolved this problem, what we have found is that numeric data type in PX pre-pends a space for the +- pushing the digits right hence causing your last digit to become a 0.

E.g numeric(15) "123456789012345" passed through trnasformer and output to a sequential file will return " 123456789012340." notice the space and decimal point implicitly added. The field width is now 17 not 15, you need to ensure that definition in your metadata for the sequential file.

Hi,
this issue is with Ascential's engeneering.
hopefully it will be resolved shortly.