TM1 Forum

I have this issue from time to time and have not been able to find a logical explanation or a resolution for it.

Sometimes after a server restart, Dimensions that had subsets attached to them no longer have them. Similarly with cubes, views disappear.
The .sub and .vue files *are* however on the disk and look valid when opening via a text viewer i.e. the MDX contained in the subsets works when testing in the subset editor, files look well formed in terms of control sections and line counts.

None of the missing subsets appear in any user's folder as private either.

}Clients has subsets and registers, }Cubes has subsets and does not register, }Dimensions has subsets and does not register.
The subset on }Cubes is MDX - a TM1SubsetAll, works in the subset editor, ditto for }Dimensions.

Recreating the subsets and saving them writes over the version on disk without issue and the new subsets are then available. Similarly with views.
After a restart, the newly created subset is not shown/registered i.e. no subsets associated with the dimension again.

The TM1Server.log does not show any warnings or errors on these or other dimensions/cubes.

Antivirus is not running on the TM1 Data or Logs folders.

Has anyone had this issue and do you have insight you could share?

TM1 is 10.2.2 FP4 (looking to upgrade at some point but not as a way to solve this issue)

I saw this regularly when I was at King, where they had 10.2.2 FP3.

It was odd and intermittent as you said. I even put it on the dev server and they re-appeared when server started but not in live.
Sometimes, I restart the live server and they come back. But most of the time I have to manually re-create the subsets and views.

Your post just reminded me how annoying it was.
Luckily, I have not experienced this in PA 11.0.7 - so it is worth upgrading IMHO.
Other thing off course is I think 10.2.2 is no longer supported (from end sept 2019)


HTH
Ken

Thanks Ken, unfortunately client is a large corporate and the upgrade is underway but the cycles are long.
Busy enabling some of the TM1 loggers in the tm1s-log.properties file to see if it sheds more light.

After adding a logger for TM1.System.File I picked up the following on two of the dimensions with the subset issue: The errors seem to repeat for man other dimensions, including those where subsets are registered and viewable.

What I am not sure of is why the Dim files have 3 dollar signs after dim rather than the usual 1.
Notice that the renames seem to be from dim to dim$$$ then from dim$ to dim - seems odd.
It is also possible that the first delete is doing something like an "if exists then delete" to avoid a renaming issue.
All speculation at this stage though.

gtonkin wrote: ↑Fri Dec 20, 2019 1:14 pm What I am not sure of is why the Dim files have 3 dollar signs after dim rather than the usual 1.
Notice that the renames seem to be from dim to dim$$$ then from dim$ to dim - seems odd.
It is also possible that the first delete is doing something like an "if exists then delete" to avoid a renaming issue.
All speculation at this stage though.

I have experienced the multiple dollar sign files as well. What happens is the system gets "lost" when saving and the temporary file (the one with the $) never gets renamed. This now becomes your live version of that object. If you make changes again then you'll get a version with $$ and then again you'll get one with $$$. Once an object with the $ becomes the live version of an object there is no getting out of it this spiral. The only solution is to stop the service, delete all the files with a $ in the name and restart. However, doing so has a big caveat. You will lose whatever changes you have made to the dimension/subset/whatever because the changes are only in the latest $ file. You need to save this off somewhere so you can restore it once the service is recycled. If it's a dimension then the answer is to create an .XDI file before you recycle the service. If it's a subset then you'll have to just use the .SUB file to see what changes are necessary and make them again yourself.

tomok wrote: ↑Fri Dec 20, 2019 2:04 pm ...
I have experienced the multiple dollar sign files as well. What happens is the system gets "lost" when saving and the temporary file (the one with the $) never gets renamed. This now becomes your live version of that object. If you make changes again then you'll get a version with $$ and then again you'll get one with $$$. Once an object with the $ becomes the live version of an object there is no getting out of it this spiral. The only solution is to stop the service, delete all the files with a $ in the name and restart. However, doing so has a big caveat. You will lose whatever changes you have made to the dimension/subset/whatever because the changes are only in the latest $ file. You need to save this off somewhere so you can restore it once the service is recycled. If it's a dimension then the answer is to create an .XDI file before you recycle the service. If it's a subset then you'll have to just use the .SUB file to see what changes are necessary and make them again yourself.

Thanks for the reply Tom but my situation is a bit different.

The issue is arising after startup of the server. Whilst shut down and before starting, I have checked and there are no files with dollars after the type(extension). I have also made sure that there is no TM1S just in case there is some kind of recovery from the log.

The messages in the previous post are logged during start up.

If I create a new subset on }Dimensions for example, the .sub file is created correctly on the file system - no dollar files. I can access the subset as expected.

After a restart, the newly created subset and previously existing subsets are no longer accessible.

After a restart, there are now dollar files anywhere under the TM1 Data or Log folders.

I am busy restoring and restarting a server in my Dev environment from last night's backup. The issue looks to have been around for the last 5 days.
It also appears to be limited to *control* dimensions but I need to do a thorough check as it is a fairly large instance with well over 100 dims. Also takes about an hour to start with persistent feeders, so lots of waiting.

Edit: Copy of server in Dev environment started up but same issue }Cubes and }Dimensions are missing subsets.
May try removing all user defined cubes and dimensions to leave a skeleton system in place and start that up.

Created an instance with only the control dims, cubes and related folders.
Same issue - no subsets on }Cubes and }Dimensions even though the folder is in place with .sub files
Checked permissions - user that starts the service has full control on the instance adn all the way down through folders to files. New subsets create happily.

Created a blank TM1Data and put back only my TM1S.cfg, }Cubes and }Dimensions and the folder with the subs i.e. }Cubes}subs.
Started the instance. All additional files were created as expected. }Cubes and }Dimensions were rebuilt to contain only the valid elements i.e. what was created by default by starting TM1.

No }Cube subsets available. Created and saved a new one, appeared on filesystem. Restarted instance, no subsets available.

Deleted }Cubes.dim and }Dimensions.dim and restarted instance, created subset, shutdown, restarted, no subsets.
Theoretically this is a new instance and still no subsets. Sanity waning.

Created a totally new instance with only my TM1S.cfg and repeated tests, still no subsets after restarting.

Created a totally new instance with only a trimmed down TM1S.cfg and repeated tests, still no subsets after restarting.
TM1S has only name, folders, admin host, port numbers, UseSSL=F, IntegratedSecurityMode=1

Think it is time for a swim and a beer (or two)

Further testing revealed the following:
Creating a public subset on }Clients works as expected when restarting - }Cubes, }Dimensions do not show the subset, not even the plus sign to expand the dimension to show subsets.

Creating a new dimension called Test with a few elements and saving a public subset works as expected after restarting.

Creating private subsets on }Cubes and }Dimensions seem to be retained after a restart but the public subsets in }Cubes}Subs and }Dimensions}subs respectively are still not available.

I created a test process, chore and then public subsets on all dims starting with } and restarted.
}Chores, }Cubes, }Dimensions and }Processes seem to lose their public subsets all others retain them.

Crazy - going to step away for tonight.

If anyone has any further ideas, would appreciate some insight.

Hi George,

I don't think this is new. This is just the way it is or always has been. Or as IBM woudl have it, it's a "feature" not a "bug". It's becasue the }Dimensions and }Cubes dimensions are recreated on every server restart and elements inserted from a sweep of the .dim and .cub objects in the data directory.

We normally just get around this by having a startup chore (re)create any subsets we need in these dimensions.

lotsaram wrote: ↑Fri Dec 20, 2019 6:04 pm Hi George,

I don't think this is new. This is just the way it is or always has been. Or as IBM woudl have it, it's a "feature" not a "bug". It's becasue the }Dimensions and }Cubes dimensions are recreated on every server restart and elements inserted from a sweep of the .dim and .cub objects in the data directory.

We normally just get around this by having a startup chore (re)create any subsets we need in these dimensions.

This definitely makes sense but still strange that the order in which things happen does not have the subsets reattached at the end.
The subset in the }Dimensions dimension is MDX and would have expected it to miraculously just work but alas.

What I do not know is when this subset was introduced by one of my colleagues as he is away and unreachable - it could in hindsight be something new that he added and only failed recently due to the restart.

Thanks for the feedback Lotsa - going to add the subset creates to our startup chore and get on with my weekend.

Agree with lotsaram, just the way it is and handled it the same way. Have a TI that reads the sub files at start up and recreates them.

However, now I use copies of those dimensions instead.

PavoGa wrote: ↑Mon Dec 23, 2019 8:53 am Agree with lotsaram, just the way it is and handled it the same way. Have a TI that reads the sub files at start up and recreates them.

However, now I use copies of those dimensions instead.

Still makes no sense that Private Subsets work as intended. For now it is what it is, workarounds already implemented and deployed.

gtonkin wrote: ↑Mon Dec 23, 2019 10:20 am Still makes no sense that Private Subsets work as intended. For now it is what it is, workarounds already implemented and deployed.

No actually it makes perfect sense! Private subsets and views aren't loaded when the server loads but when the user logs in. The implicit DimensionDestroy and rebuild from file system objects also destroys any public subsets. But by the time the server is available for users to authenticate to all the dimensions and elements exist, hence no issue with private subsets on these dimensions.

lotsaram wrote: ↑Mon Dec 23, 2019 1:29 pm

gtonkin wrote: ↑Mon Dec 23, 2019 10:20 am Still makes no sense that Private Subsets work as intended. For now it is what it is, workarounds already implemented and deployed.

No actually it makes perfect sense! Private subsets and views aren't loaded when the server loads but when the user logs in. The implicit DimensionDestroy and rebuild from file system objects also destroys any public subsets. But by the time the server is available for users to authenticate to all the dimensions and elements exist, hence no issue with private subsets on these dimensions.

Yes, it follows from the sequence of events as described but makes no sense from what *I* would expect i.e. Rebuild the dimensions, register subsets and update based on MDX. If a subset is invalid for any reason after rebuild, it should still be there but without members (empty). Keeping in mind that when the public subsets are "destroyed", they are not actually removed from the file system but persist.

May be that my expectations need to be realigned to reality.