Hi all,
We have a parallel job that needs some improvements but is by no means complex. The last transformer in a job is preceeded by lookup stage that drops un-matched records. The transformer writes to dataset with some simple derivations.
The job was running fine in non-prod environments, but started failing on 4 production engine nodes (fifth one dedicated to conductor).
The failure message is "Player 9 terminated unexpectedly" with Player 9 being the transformer.
The stage variables causing this failure are:
svZoneLenId
------
Len(Trim(DecimalToString( To_Xfm.POS_ZONE_ID,"suppress_zero")) )
svZoneId
------
Trim(DecimalToString( To_Xfm.POS_ZONE_ID,"suppress_zero"))
When written as such the Dump Score advises there are 21 datasets.
If however, the order of stage variables is swapped so that svZoneId appears first, the job completes and the Dump Score advises there are 20 datasets instead.
I know these stage variables are not written in the best way but even as they are they should not be causing a failure?
Regards,
Novak
Order of stage variables fails a job
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 1735
- Joined: Thu Mar 01, 2007 5:44 am
- Location: Troy, MI
Since they've already said that they "know these stage variables are not written in the best way" I wasn't going to bother to point that out.
And just for the record, no clue why the order would matter here seeing as how one is not dependent on the other. Seems like something to take to support.
And just for the record, no clue why the order would matter here seeing as how one is not dependent on the other. Seems like something to take to support.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Reordering stage variables in a Transformer will not produce a change in the number of Data Sets in the score. Something else has also been changed in the job design, about which you have chosen not to inform us.
Perhaps you could post the two scores?
Perhaps you could post the two scores?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
This will very likely be due to buffering.
Was trying to avoid changing too much of a job in production but prior to this there were two lookup stages linked one to each other.
In dev and sit, they tell me it was never an issue, but it was never tested with large volumes.
After changing from lookup to join stage the job is behaving better.
Thanks for chiming in.
Novak
Was trying to avoid changing too much of a job in production but prior to this there were two lookup stages linked one to each other.
In dev and sit, they tell me it was never an issue, but it was never tested with large volumes.
After changing from lookup to join stage the job is behaving better.
Thanks for chiming in.
Novak