TM1 Forum

Hi everybody,
I recently added a new element to a dimension that appears in three different look up cubes.The new element appeared in the look up cubes as desired.I then added new values into the new element in only one of the look up cubes.
After saving and closing,i noticed that a new }Hold_Username_Cubename was automatically created by TM1.
Will this in anyway affect the one look up cube that values where added to?Presently,the cube in question is showing what is expected for it to show,after the changes that has been made(addition of the new element to one of its dimension and the values added to the cube is showing up).
Just concerned about the new }Hold_Username_Cubename cube that was autogenerated by the system.Would love any pointers as to how to remove or delete this }Hold cube if it will not in anyway affect or disturb the system.
Thanks and all positive and encouraging advice will be Greatly Appreciated.

{Admin Note: Split from a previous, unrelated thread. (See Request for Assistance Guideline #5)}

segunfunwaoluwa wrote:After saving and closing,i noticed that a new }Hold_Username_Cubename was automatically created by TM1. Will this in anyway affect the one look up cube that values where added to?

No, it's an artifact that's sometimes created due to simultaneous writes.

segunfunwaoluwa wrote:Just concerned about the new }Hold_Username_Cubename cube that was autogenerated by the system.Would love any pointers as to how to remove or delete this }Hold cube if it will not in anyway affect or disturb the system.

Ignore it. It will be gone after your next server restart. If it really bothers you, you could restart now, but it'll probably come back again relatively soon (next time there are simultaneous writes to the cube), so if I were you I'd just ignore it.

Matt

mattgoff wrote:

segunfunwaoluwa wrote:After saving and closing,i noticed that a new }Hold_Username_Cubename was automatically created by TM1. Will this in anyway affect the one look up cube that values where added to?

No, it's an artifact that's sometimes created due to simultaneous writes.

Hmm... are you sure about that? }Hold cubes are generated when users apply holds to leaves or consolidations during data spreads. See the following links for more information:
}Hold
Hold Consolidate and Hold Release in TI
Excluding Consolidations from Data Spreading
Applying Leaf Holds

I'd not heard that these cubes were also used for write contention management and I guess that's theoretically possible, but wouldn't you agree that it is quite a risky strategy to use the same control cube for two totally different system functions?

segunfunwaoluwa wrote:I then added new values into the new element in only one of the look up cubes.
After saving and closing,i noticed that a new }Hold_Username_Cubename was automatically created by TM1.

Perhaps you applied a hold whilst you were updating the cube values?

segunfunwaoluwa wrote:Just concerned about the new }Hold_Username_Cubename cube that was autogenerated by the system.Would love any pointers as to how to remove or delete this }Hold cube if it will not in anyway affect or disturb the system.

If you accidentally applied the holds and don't want them, it won't hurt a great deal to delete this cube. Or, perhaps you can just release the holds? As a rule, however, you should leave these cubes well alone as they may be being used by users who are trying to perform important spreading operations in the system.

rmackenzie wrote:

mattgoff wrote:

segunfunwaoluwa wrote:After saving and closing,i noticed that a new }Hold_Username_Cubename was automatically created by TM1. Will this in anyway affect the one look up cube that values where added to?

No, it's an artifact that's sometimes created due to simultaneous writes.

Hmm... are you sure about that? }Hold cubes are generated when users apply holds to leaves or consolidations during data spreads. See the following links for more information:
}Hold
Hold Consolidate and Hold Release in TI
Excluding Consolidations from Data Spreading
Applying Leaf Holds

I'd not heard that these cubes were also used for write contention management and I guess that's theoretically possible, but wouldn't you agree that it is quite a risky strategy to use the same control cube for two totally different system functions?

I've never used reservation holds in TM1, yet I periodically have }Hold cubes with my username. These cubes consistently appear after a longish scheduled chore updates my GL cube with balance data from Oracle. So, while I haven't explicitly verified this via experimentation, it certainly seems to be the case on my system.

I'm not sure why it would be risky as the }Hold* control cubes contain username information. I presume each process locks portions of each cube when it runs and TM1 automatically creates a reservation when a user attempts a concurrent write (further presumed to do this in order to detect if original data changes before the reservation is made available for that specific write). Since the }Hold cube has user data, there isn't the risk of the wrong lock getting released, if that's what you mean by "risky." Chores run under their own username (as seen in tm1top).

Yes, lots of presumptions, but that's the TM1 docs for you and all empirically true on my model.

Matt

Matt,

I think you're onto something there. I have seen a few models now where }Hold* cubes crop up for users who almost ceirtanly do not use data holds. I have been wondering what these cubes might be used for, but couldn't really figure it out. Simultaneous writes, data spreading and user-defined consolidations with private subsets were all on my list of suspects.

mattgoff wrote:I've never used reservation holds in TM1, yet I periodically have }Hold cubes with my username.

qml wrote:I have seen a few models now where }Hold* cubes crop up for users who almost ceirtanly do not use data holds.

Yes, me too. I have seen this on occasion, and wondered why people were using holds and on further investigation found that no one recalled using that functionality... so I guess there is a bit of a mystery.

By the way, the documented function for the }Hold cubes is to help control how the results are calculated during top-down spreading. When you say 'reservation holds' are you referring to this? The two concepts are different. Spreading, with holding, is widely used in real-world, real-(big)-dollar environments to perform top-down planning. E.g. take last years actuals for fish revenue and apply to this years budget, then add a 10% uplift except for the cod products - i.e. 'hold' cod (someone jump in with a better example please!). Users can easily apply these holds through Excel, cube-viewer, TM1 Web. The holds can persist during planning cycles within a business and can be applied and removed at will, by users. The holds are string flags in special control cubes created in the background.

mattgoff wrote:I'm not sure why it would be risky as the }Hold* control cubes contain username information.

So what is "risky" is that IBM deploy, support and document functionality that is used all around the world in business critical situations... but secretly, they use these cubes to somehow implement controls in the locking model. The username being present in the cube name is no protection because when you run a chore it runs under your user name but when the scheduler runs a chore it gets its own thread. Perhaps they add and remove a measure on the fly to do this; but what if the server crashed during the load - what would happen to the cube data that some user was using for a data spread hold...? Somehow, I don't buy it... but I can't say for certain that it isn't true. Perhaps you could turn on audit logging in your environment and then run your chore, if it does create a }Hold cube and add a measure, then perhaps this would be logged and you could let us know?

mattgoff wrote:Yes, lots of presumptions, but that's the TM1 docs for you and all empirically true on my model.

I think you are confusing correlation with causation and that's a dangerous game to play.