TM1 Server log

[deepakjain2020]

Hi All,

3872 [98] INFO 2014-06-16 14:00:40.569 TM1.Process Process "Process_Name": finished executing normally, elapsed time 1818.91 seconds

Above line is from TM1 server log file.

3872 - Thread ID
[98] - ??
INFO - Message Level
2014-06-16 14:00:40.569 - Date and time
TM1.Process - TM Logger Name
Process "Process_Name": finished executing normally, elapsed time 1818.91 seconds - Message Text

Can someone please let me know what the 98 represents for, having in red color font.

Regards,
Deepak Jain

[Alan Kirk]

Hi All,

3872 [98] INFO 2014-06-16 14:00:40.569 TM1.Process Process "Process_Name": finished executing normally, elapsed time 1818.91 seconds

Above line is from TM1 server log file.

3872 - Thread ID
[98] - ??
INFO - Message Level
2014-06-16 14:00:40.569 - Date and time
TM1.Process - TM Logger Name
Process "Process_Name": finished executing normally, elapsed time 1818.91 seconds - Message Text

Can someone please let me know what the 98 represents for, having in red color font.

I wouldn't worry about it; it doesn't seem to be relevant. It appears to be a hexadecimal ID code representing a client session ID for the current server session, with each new session being incremented by 2. It only appears to be populated for manually triggered processes or chores for that session.

In the log file for my test environment, all of the scheduled chores have nothing between the brackets. I then triggered a chore manually and it appeared as [2]. Then I logged out and logged back in and did another one, and it showed as [4]. Then I logged out and ran another one from a different client ID and it appeared as [6]. Then I opened a session of Architect and ran another one, and it appeared as [8]. Any other chores or single processes that I ran during the same sessions got the same ID code. In the next session [8] was replaced by [a], then next time [a] was replaced by [c], then in the one after that [c] was replaced by [e], then the next one [e] was replaced by [10].

So [98] would represent 4C hex (that is, 98 hex \ 2 ) sessions which represents the 76th client session for that server session based on the tests shown above. Not particularly useful information. The only relevance would be if you wanted to know which processes or chores had been triggered in the one client session.

[BariAbdul]

Amazing Alan,You never cease to suprise us with depth of your knowlege.Thanks a ton.

[deepakjain2020]

When I triggered again 98 was replaced by 2.

Thanks Alan for information

[Alan Kirk]

Amazing Alan,You never cease to suprise us with depth of your knowlege.Thanks a ton.

Thank you, but in fairness that wasn't knowledge, that was just "fluffing around with a test session and seeing what happened".

When I triggered again 98 was replaced by 2.

Most likely you had rebooted the server since the previous run; a data save alone doesn't seem to reset the ID number. (Some of the chores / processes that I ran in my tests did Save Data All.)