Using Stage Variables in PX vs. Server

[mfavero]

I am having trouble with the values of Stage variables being retained from one row to the next. In Server this always worked, but in PX the variables all seem to be reset to zero or null as each row is processed.

example 2 varables:

VarSave integer(10) initial value 0
Var1 integer(10) initial value 0

In stage variables:
1st VarSave set to Var1
2nd Var1 set to input.column1

2 rows input:

column1
1
2

output
input.column1
VarSave
Var1

results:
1
0
1

nothing wrong with first row

second row results:
2
0
2

VarSave should have retained the 1 from the first row but did not.
I was looking for:

2
1
2

[ShaneMuir]

The only thing I can think of is that each row is being processed separately in parallel. Therefore each row will read the initial value as 0 at the same time. I would be interested to see what your outputs were when you used more rows, as I would expect to see the VarSave value to start counting up when there are multiple rows processing on the node.

The only way to ensure that all rows are passed through the variables would be to run the transformer in sequential mode rather than parallel.

[ray.wurlod]

Was this run on a two-node configuration file, with one row being processed on each?

[ShaneMuir]

Was this run on a two-node configuration file, with one row being processed on each?

That is what I was trying to allude to - but couldn't put it as succinctly

[vkhandel]

The transformer should be executed in the sequential mode, to achieve the desired output.

[vmcburney]

You can still use stage variables. For a counter just use some of the PX specific macros that give you the number of threads and thread number. For remembering values just match the partitioning to the key fields, think of it as a multiple instance job, partition by the right field and you can still compare values between rows in a way that makes sense.

[mfavero]

thanks - the problem was indeed that each of the two rows was being processed by a different partition (8 node cfg)

The job only processes 2 rows, so I simply changed it to run in sequential mode.