TM1 Forum

Hello,

We've encountered an issue and are experiencing some strange behavior with how Tm1 looks to be resolving directories on the server. Let me provide some details:

This particular situation appears to arise when we perform a SaveDataAll while having a large amount of users in the system/trying to log in. Our instance has several large cubes with daily data and is heavily ruled so performing a SaveDataAll takes 20 - 30 minutes.

When this situation arises there are a couple of strange things that start to occur:

- We have a load process that creates a log file in the directory above the database directory (i.e. '..\FileName.log'). Once we get into this state, the process still creates the file however it's placed in a seemingly random location. Often, the file is placed in the directory for our namespace that contains all the sub directories for the users' private views and subsets. However, sometimes it places the log file into one of the individual user directories. I realize it probably be a better idea to use an explicit directory (D:\MyDirectory\Filename.log vs...\File). However, I have left this because it helps me identify when this issue occurs. I can live with misplaced log files, the item below is a bit more critical).

- We have a handful of processes that leverage batch files to perform a variety of functions (e.g. emailing, calculating cells concurrently, etc.). Once this particular scenario arises, any action that leverages a batch file does not perform. All calls made to execute a batch file is made explicit path (e.g. D:\DatabasDirectory\MyBtach.bat). What I assume is occurring is that much like our logs getting placed into the wrong directory, when we call the batch file it's looking somewhere it's not supposed to and just failing. Unfortunately, being a production server I cannot get onto the server or do some simple debugging to see what Tm1 is doing.

This behavior is not consistent every time we run a SaveDataAll. But as I mentioned high usage attempts during this seems to be the only symptom I can discern. After rebooting the server, all is fixed. The logs are written to the correct directory and all processes using batch files work as expected.

Any thoughts? Has anyone ever seen anything like this before?

Thanks,
Brad

I've seen the same behaviour on base 10.1.1.

Annoyingly only on our Production environment, the Dev and Test environments never move away from the data directory as the default file location.

I didn't have enough access to the server it was happening on, or the time, to try and work out why it was doing it. I just picked up the data directory from a system cube and specified the full path name every time. Which I probably should have been doing all along.

bradohare wrote:We have a load process that creates a log file in the directory above the database directory (i.e. '..\FileName.log')

This isn't a TM1 thing, although I guess behaviour may change from version to version. It's a Windows thing in that usage of .. isn't always going to be relative to the database directory - it is relative to the current directory attached to the TM1 process.

This can jump around between the root of database directory, any of the sub-folders and the logging directory. Perhaps it can also be in other locations too. I've tried to manipulate/ control it by creating subsets/ writing text files/ running TIs with text data sources etc and it doesn't appear possible to influence the TM1 current directory through TI calls. Therefore, the recommendation is simply not to use relative paths. I don't know where the idea that it was OK came from in the first place - I recall seeing some example of this in 'Planning sample' so maybe that's where it came from.

bradohare wrote:We have a handful of processes that leverage batch files to perform a variety of functions (e.g. emailing, calculating cells concurrently, etc.). Once this particular scenario arises, any action that leverages a batch file does not perform

I would be looking at the scripts themselves to see if they contain relative paths - did you check that?

bradohare wrote:This behavior is not consistent every time we run a SaveDataAll. But as I mentioned high usage attempts during this seems to be the only symptom I can discern. After rebooting the server, all is fixed. The logs are written to the correct directory and all processes using batch files work as expected.

Yep, it's not clear what sets/ changes the current directory. It sounds reasonable that if lots of things are happening like saving data, people logging in/ out, people creating/ destroying subsets, etc; then TM1 will be jumping all over the place trying to get stuff done.

bradohare wrote:Any thoughts?

If, for some reason, you need to keep on using relative paths (not recommended) then you could play around with trying to set the current directory directly from within the batch scripts using this technique.