Default action of TI Process

[deepakjain2020]

Hi All,

When we extract a data from a cube into a file, TI ignores consolidated elements and Zero values by default?

Regards,
Deepak Jain

[jim wood]

TI like all other software, does what you tell it do. If you're unsure about this you need to become more familiar with TI.

[Wim Gielis]

Hi All,

When we extract a data from a cube into a file, TI ignores consolidated elements and Zero values by default?

Regards,
Deepak Jain

True story.

[deepakjain2020]

TI like all other software, does what you tell it do. If you're unsure about this you need to become more familiar with TI.

Hi Jim,

Yes you are right, that all softwares will work as we tell it to do.
Anyways apart from that, my concern was to get the confirmation from all of my friends regarding default action of TI when we are taking the following scenario

Datasource: Cognos TM1 Cube
We will declare the respective variables and in data section we are using ASCIIOUTPUT.

The file which we are going to have will exclude Consolidated values and as well as ZERO values by default, is that true?

Regards,
Deepak Jain

[rmackenzie]

The file which we are going to have will exclude Consolidated values and as well as ZERO values by default, is that true?

The following commands are set to 1 by default whenever a ViewCreate statement is executed.

• ViewExtractSkipCalcsSet
• ViewExtractSkipRuleValuesSet
• ViewExtractSkipZeroesSet

If you want to include consolidated elements you would specifically set them to 0. E.g. to include zero values, you would code:

Code: Select all

ViewExtractSkipZeroesSet ( sCubeName, sViewName, 0);

For cubes that contain data for reporting, planning, analytics etc; they are usually sparse. As most of the time, no-one is interested in the zero values, the views created default to '1' for this setting. If you are concerned that it is too ambiguous, then you simply code all the settings when creating a view:

Code: Select all

ViewCreate ( sCubeName, sViewName );
ViewExtractSkipCalcsSet ( sCubeName, sViewName, 1);
ViewExtractSkipRuleValuesSet ( sCubeName, sViewName, 1);
ViewExtractSkipZeroesSet ( sCubeName, sViewName, 1);

Because they are default, you don't have to do this. But it does make the code more transparent and easier for others to follow the process.

[gibson]

The file which we are going to have will exclude Consolidated values and as well as ZERO values by default, is that true?

The following commands are set to 1 by default whenever a ViewCreate statement is executed.

• ViewExtractSkipCalcsSet
• ViewExtractSkipRuleValuesSet
• ViewExtractSkipZeroesSet

Bumping an old thread here ... Are these defaults mentioned anywhere in IBM's documentation? I've been searching and haven't found anything.

[deepakjain2020]

Hi Gibson,

You can find those in reference guide, which give info on how set value for functions.

Regards,
Deepak Jain

[gibson]

Hi Gibson,

You can find those in reference guide, which give info on how set value for functions.

Regards,
Deepak Jain

Thanks Deepak. Yeah, I saw the commands in the reference guide but I was looking for where in the documentation it states these are defaulted to on after a view create statement (I don't think it's documented). I believe everyone on the forum that says this is true and it's easily testable, as a newbie it's just aggravating IBM didn't include this in their literature.

[jim wood]

If memory serves they all default to false, so unless you specify otherwise it will include everything. Which makes sense, why would it exclude anything without you telling it to do so,

Jim.

[gibson]

If memory serves they all default to false, so unless you specify otherwise it will include everything. Which makes sense, why would it exclude anything without you telling it to do so,

Jim.

The file which we are going to have will exclude Consolidated values and as well as ZERO values by default, is that true?

The following commands are set to 1 by default whenever a ViewCreate statement is executed.

• ViewExtractSkipCalcsSet
• ViewExtractSkipRuleValuesSet
• ViewExtractSkipZeroesSet

If you want to include consolidated elements you would specifically set them to 0. E.g. to include zero values, you would code:

Code: Select all

ViewExtractSkipZeroesSet ( sCubeName, sViewName, 0);

For cubes that contain data for reporting, planning, analytics etc; they are usually sparse. As most of the time, no-one is interested in the zero values, the views created default to '1' for this setting. If you are concerned that it is too ambiguous, then you simply code all the settings when creating a view:

Code: Select all

ViewCreate ( sCubeName, sViewName );
ViewExtractSkipCalcsSet ( sCubeName, sViewName, 1);
ViewExtractSkipRuleValuesSet ( sCubeName, sViewName, 1);
ViewExtractSkipZeroesSet ( sCubeName, sViewName, 1);

Because they are default, you don't have to do this. But it does make the code more transparent and easier for others to follow the process.

Jim, rmachenzie is saying the opposite. Can you confirm which is true?

[Wim Gielis]

By default, the parameter value is 1: skip the cells (zeroes, consolidations, rules-calculated cells).
You have to specify 0 to force the view to not skip those cells.

[Alan Kirk]

In answer to the actual question, which is whether the default values of the skip variables are documented, that would be no.

However it's pretty easy to test empirically. This line of code was executed in isolation:

Code: Select all

ViewCreate('RevenueAndStats','zTestView');

This results in creation of a .vue file. In .vue files, the following codes apply (extracts from my own documentation, not IBM's):

381,x
When exporting as text, whether or not to skip rule calculated values. (0=No, 1 = Yes.)

361,x
When the view is exported as text, this determines whether consolidations are skipped in the export. (0 = no, 1 = yes.)

362,x
This is zero suppression for views created through the export text dialog or the TI ViewCreate function. 0 = off, 1 = on. See also 372.

So what do we see in the .vue file? (Extracts, not in this order:)

381,0
361,1
362,1

So in a raw view created with the ViewCreate function, rules values are not skipped, consolidations are skipped, zero suppression is on.

[jim wood]

Interesting. I didn't seem that coming. So the morale of the story is, always specify them and you'll be ok.

[Alan Kirk]

Interesting. I didn't seem that coming. So the morale of the story is, always specify them and you'll be ok.

Quite so. Here's another one that I didn't see coming either. It's been a while since I wrote the documentation that I referred to above and I thought that it might be timely to just do some double checks to make sure that it was still current.

So imagine my surprise when I added a ViewExtractSkipZeroesSet function to the code and set the value to 0 (include zeroes), and the .vue file still showed a 362 code of 1. So then I created two views, one by itself, and one with ViewExtractSkipZeroesSet set to 0.

Code: Select all

SC_CUBE = 'RevenueAndStats';
SC_VIEW1 = 'zTestViewWithoutZeores';
SC_VIEW2 = 'zTestViewWithZeores';

If ( ViewExists ( SC_CUBE, SC_VIEW1) = 1 );
    ViewDestroy ( SC_CUBE, SC_VIEW1);
EndIf;

If ( ViewExists ( SC_CUBE, SC_VIEW2) = 1 );
    ViewDestroy ( SC_CUBE, SC_VIEW2);
EndIf;

ViewCreate(SC_CUBE,SC_VIEW1);

ViewCreate(SC_CUBE,SC_VIEW2);
ViewExtractSkipZeroesSet ( SC_CUBE, SC_VIEW2, 0);

Then I loaded the two .vue files up in WinMerge to check them side by side.

The only, only line that was different between the two files was the name line, code 390.

So I opened them up in the Export As Text Data view and sure enough, View1 had skip zeroes checked, but View2 did not. But the files have the same codes. But the results are different. But the files have the same codes. But the... Stop. Think. Why would this be so?

Logical conclusion; the ViewExtractSkipZeroesSet function had updated the View object in memory, but did not update the .vue file at the same time.

And so I did a data save and... sure enough, at that point the .vue file was changed. The moral of that story... sometimes the metadata definition files don't get updated in real time. Most of the time it makes no difference, but if anyone loses the changes to a view (or, presumably, subset) unexpectedly that may be the cause.

[tomok]

In any programming environment if you need to create an object to complete a task and that object has properties and you need those properties to have a specific value then you should always set them when the object is created. Relying on default values, while a attractive, is not best practice. I have base code I use for TIs that has the ViewCreate function together with all the property set statement following that. I don't like relying on defaults, even though I know what they are. It also jogs my memory as to what the view is doing when a look back at the code at a later date.

[gibson]

Thanks for the replies! Good to know for sure.

[paulsimon]

Hi

From memory I think Jim is right - the default used to be no skips unless you specified them. It seems that in more recent versions IBM changed the defaults say skip. Anyway the best practice is to always specify all three and that way you won't be caught out by any further changes.

Regards

Paul Simon

[Alan Kirk]

From memory I think Jim is right - the default used to be no skips unless you specified them. It seems that in more recent versions IBM changed the defaults say skip.

It would have to have been a very, very long time ago. Those notes of mine date back to 8.2.12 (updated for 9.0, 9.5 and now 10.2.2) and it was the same pattern back then. For as long as I can remember the Export as Text dialog (which uses the same .vue parameters as the ViewCreate function) skipped consolidations and zeroes, since both were most commonly used as a data source and neither of those would be needed (or wanted) in most data sources.

Anyway the best practice is to always specify all three and that way you won't be caught out by any further changes.

Agreed.

[paulsimon]

Hi Alan

Yes it probably was a very long time ago. When Jim and I first worked together it was on version 6. Version 7 was just coming in. I don't think TI even arrived until 7.1 or something like that. Having said that I have always specified all the skip parameters so I wouldn't have really noticed if anything changed. The anomaly around Skip Rule Calcs being false while the other two are true, might be because there was originally only Skip Zeroes and Consols, and Skip Rule Calc Values was added later. On the other hand may be someone decided that the default should be false.

Anyway I will continue to always specify all three.

Regards

Paul Simon

[Alan Kirk]

Yes it probably was a very long time ago. When Jim and I first worked together it was on version 6. Version 7 was just coming in. I don't think TI even arrived until 7.1 or something like that.

I'm pretty sure you're right. Back on version 6 we were still using map sheets. I recall that TI became available after we (a different "we" to now) did an upgrade to the legendary 7.1.4 version, but I can't recall if it was around before that. Back in those days TI was licenced separately (or at least down here it was) so not all v7 users would have had it, even if it was available then.

Having said that I have always specified all the skip parameters so I wouldn't have really noticed if anything changed. The anomaly around Skip Rule Calcs being false while the other two are true, might be because there was originally only Skip Zeroes and Consols, and Skip Rule Calc Values was added later.

It was, hence the code number in the .vue file being somewhat removed from the other two. And of course it also explains why the TI function for skipping consolidations has a slightly misleading name; ViewExtractSkipCalcsSet. There wasn't the ability to skip rule based calculations at the time so most likely the writer of that function didn't consider that the name could be ambiguous.

The ability to skip rules I think came in in 8.0, though it may have been earlier than that or as late as 8.1.0, but no later. The release notes show that there was a bug that was fixed in 8.1.1. Prior to that selecting "Skip Rule Calculated Values" in the dialog would actually set the "Skip Consolidated Values" parameter in the view. (So clearly it's not only the end users who were a bit confused by the naming conventions.)

On the other hand may be someone decided that the default should be false.

I think so; to me the defaults have always made sense. As I said either export as text or ViewCreate will typically be used as data sources, whether to feed another TM1 cube (or to copy a version) or to feed an external database. You won't typically want zeroes for that (if you're copying to another cube, ViewZeroOut is far more efficient), you won't typically want all of the consolidations (since those will reject if you try to load them anyway)... but assuming that you're making an archive copy (say) you will want the rules calculated amounts since there's no point in keeping live calculations for static data. Or, alternatively, if you're feeding to an external database there's no point in having the ETL or target database recalculate those values.

So while there's an inconsistency, I've always thought that it's a very logically defensible inconsistency on Iboglix's part.

Anyway I will continue to always specify all three.

Definitely the safest way; never assume.