Can feeders delete data from the cube!?!?!?

[vladino]

Hello guys,
I know that the basic answer to my question is "NO at all!". But I'm experiencing a bit different behavior right now...

We just have upgraded to the latest PAL version which is 2.0.3. I'm not sure it this might be the reason...

First of all, let me summarize the basics of the model which is quite simple.
We have a cube which consists of time dim, versions, products, segments and measures. I have tested the behavior on a simple example:
There are three measures: BOP, NEW and EOP. The logic behind is easy:
EOP(p) = BOP(p) + NEW(p)
BOP(p) = EOP(p-1)

We have two versions - actuals and plan. There is a version config cube which tells us the "breaking" period between actuals and plan. There is a simple rule (applied as the first rule in the cube) that fills plan version with actuals for period before or equal to the "breaking" period.
The above mentioned logic for EOP applies to the plan version. For actuals we are uploading EOP directly.

So the rule seems like this:
1. [] = N: if version is plan then (if period is before or equal to the version config cube then get actuals else continue) else continue
2. BOP(p) = N: EOP(p-1)
3. EOP(p) = N: if version is plan then BOP(p) + NEW(p) else continue

Feeders:
actuals => plan
EOP(p) => BOP(p+1)
BOP => EOP
NEW => EOP

And here comes "the magic"... After we import EOP for actuals we can see the correct results, ie. EOP is imported in actuals, it's linked to the plan for historical periods and for future period the calculations take place. But after I restart the TM1 instance there is no EOP data in actuals... If I repeat the import process, comment EOP feeders (ie. last two feeders above) and restart the TM1 instance the data for EOP is stil in actuals, then it gets linked to the plan but there are no aggregations for EOP for the plan version (becasue of missing feeders of course).

Am I missing something or is this appropriate behavior???

Thanks in advance for any opinion and/or help!

BR
Vladino

EDIT: We are using these params in the cfg file: MaximumCubeLoadThreads=CPU-1 (we are not using conditional feeders), MTCubeLoad (also with Bookmark files option), MTFeeders (also with Startup option), MTQ=All

[lotsaram]

You have given too much pseudo code and not enough information. However it sounds similar to APAR PI70620 which was a defect where if there was overfeeding where an input cell was fed (i.e. data entry cell with no rule or rule evaluating to STET) then the input data would be deleted on server restart.
Very.bad.bug.

This was fixed in 10.2.2 FP6 IF1014. This was discussed already here

If this same bug has made a comeback in PA 2.03 it would not be good

[vladino]

Hi,
thanks a lot for your reply!

Yes, it sound like the same bug - actually those cells might be overfed.

But I have discovered that if I remove MT* params from the CFG file and leave only MaximumCubeLoadThreads then it works even after restart.

What should I do now? Should I report this as a potential "evolution" of previously corrected bug?