TM1 Forum

For those looking to get something more out of MDX, please have a look at the article I just posted on the IBM Community

It also contains links to my other articles on using MDX views.

This worked for me, thanks!
This MDX has also removed all overfeeding in my model and cleaned my aura!

Hoping this was part of the April fool as well?

Also, in V12, the }Stats cubes are deprecated

Unfortunately not, but with the announcement of V12 for on-premise, I do wonder what we were told would not be available, will now be available again as we would not be running containerized, would have access to the filesystem etc.
SaveDataAll, AsciiOutput, possibly logging remains?

Some further questions for the next AMA...

They were pretty clear when asked that v12 on premise would not re-introduce any of the functionality that v12 containerised was removing.

The loss of the Stats cubes has not really been publicised, it's a pretty big deal isn't? How are we supposed to tell we have got our designs right, if dim order needs tuning and perform general oversight of system health.

Has a replacement been hinted at?

Steve Rowe wrote: ↑Mon Apr 08, 2024 12:20 pm They were pretty clear when asked that v12 on premise would not re-introduce any of the functionality that v12 containerised was removing...

I hear you but cannot fathom right now how we would not need to save cubes back to the filesystem to commit changes to disk in a non-containerised environment.

Hi Steve,

https://www.ibm.com/docs/en/planning-an ... -analytics

Please scroll to the last part of the document.

Thanks Wim, that's an interesting read, most of the items are pretty obscure.

A few items stand out though
TI Functions.
Interesting that the ASCIIOutput function is not listed, the one thing that has been known for a long while to not be possible. Same for ExecuteCommand.
AssignClientPassword - I'm assuming because (I assume) mode 1 is not supported?
CreateHierarchyByAttribute - Whilst often not practical in the long term, it is great for quick and dirty hierarchy builds.
SwapAliasWithPrincipalName - Actually a genuine problem for some planning applications where the planning team will use temporary SKU names in advance of the SKU becoming real and getting a proper name, at which point an alias swap is performed.

The loss of the Stats cubes is going to really problematic though, at the moment the only place that you can use PAE you are billed for on a RAM basis, yet you can't tell how big your cubes are anywhere?

I think that AsciiOutput is still there, but then towards folders relative to the model_upload folder.

Steve Rowe wrote: ↑Mon Apr 08, 2024 5:03 pm Thanks Wim, that's an interesting read, most of the items are pretty obscure.

A few items stand out though
TI Functions.
Interesting that the ASCIIOutput function is not listed, the one thing that has been known for a long while to not be possible. Same for ExecuteCommand.
AssignClientPassword - I'm assuming because (I assume) mode 1 is not supported?
CreateHierarchyByAttribute - Whilst often not practical in the long term, it is great for quick and dirty hierarchy builds.
SwapAliasWithPrincipalName - Actually a genuine problem for some planning applications where the planning team will use temporary SKU names in advance of the SKU becoming real and getting a proper name, at which point an alias swap is performed.

The loss of the Stats cubes is going to really problematic though, at the moment the only place that you can use PAE you are billed for on a RAM basis, yet you can't tell how big your cubes are anywhere?

AsciiOutput - is still very much there. v12 gives us a "files" root directory which is the cd from the perspective of AsciiOutput or file datasource for any TI processes.
SwapAliasWithPrincipalName - is a bit of a pain but I can well understand that with horizontal scaling this simply does not fly, since any processes happen purely on the leader, the followers just read logs and replicate changes.
CreateHierarchyByAttribute - is not a loss. This was simply put nothing but demoware and as useless as the proverbal udders on a bull for anything serious. Replace it with a call to bedrock process that can do much more anyway.

Stats cubes not there is a significant issue. }StatsByCube is invaluable for figuring out which cubes should be optimized for dimension order, where there is potential overfeeding, etc. But the loss of }StatsByRule is perhaps an even greater issue as if rule optimization is required, this is an essential resource (and the information isn't available anywhere else.)

The loss of the Properties control cubes is also very significant, as there is now no way to read or write these properties internally within the model. Yes properties can be read and set externally via Rest API requests but this_is_just_not_the_same! If TI functions were introduced to do the equivalent job then I would have no issue at all with this, but as it is it is a severe defecit. (e.g. read the current assigned DimensionsortOrder, set/read names for named levels, set/read the default member, etc, etc.)

lotsaram wrote: ↑Tue Apr 09, 2024 8:08 am

Steve Rowe wrote: ↑Mon Apr 08, 2024 5:03 pm ...
The loss of the Properties control cubes is also very significant...

Wondering how VMT/VMM is handled and sort order on elements/components.