Decimal type error in transform

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
banactp
Participant
Posts: 52
Joined: Tue Feb 22, 2005 2:55 pm

Decimal type error in transform

Post by banactp »

I'm getting the following error message from a parallel transformer stage:

Code: Select all

APT_DecimalNumber::analyzeAndPrepare:divisor is 0.
followed by:

Code: Select all

Fatal Error: APT_Decimal::asDFloat: invalid representation in the decimal; the leading nybble must be zero with odd precision.
I'm having trouble tracking down the cause, since:

1. There are only two divide operations in the transformer, both associated with decimal-type stage variables. I've added zero-handling logic to them (If divisor=0 then don't divide, else go ahead and divide) and still the error persists. None of the divisor values (originating from a parallel routine) should be zero, anyway. The derivations for the Decimal(24,6) stage variables in question look like:

Code: Select all

DFloatToDecimal( 1.0 / RoutineReturningDouble(String,String), "round_inf" )
2. I've tried assigning both the divisor and the result to double-typed stage variables before doing the DFloatToDecimal conversion. This had no effect.

3. I can't find the APT_DecimalNumber::analyzeAndPrepare method anywhere in the include files. Anyone know where it is and what it does?

4. I'm not really sure which error occurs first, but I would bet that this is a really a type-conversion issue. Even though the "divisor is 0" message appears first in the job log, I would not be suprised if it was in fact arising because of the asDFloat error.

Has anyone encountered these or similar errors before, and if so, what is the cause and cure?
banactp
Participant
Posts: 52
Joined: Tue Feb 22, 2005 2:55 pm

Post by banactp »

For future reference, the errors above were indicative of an attempt to perform a decimal divide-by-zero.

I must admit that there was one more divide operation buried deep in the bowels of my transformer logic. Although the divisor in that case should not have ever been zero, partitioning issues upstream were setting it to zero for some records, hence the errors.

Tim
Post Reply