TM1 10.2.1.1 cfg parameter issue

[TrevorGoss]

I have recently created a chore which I call in the cfg of each of my services in TM1. This is done by a parameter named "StartUpChores".

In the CFG file, the parameter looks like this: StartupChores=FindServiceAndServerName
where FindServiceAndServerName is the name of the chore.

An extract of our cfg file:

Code: Select all

#GroupsCreationLimit= 20000
GroupsCreationLimit= 100
AllowSeparateNandCRules=T
ParallelInteraction=T
PersistentFeeders=T
ForceReevaluationOfFeedersForFedCellsOnDataChange=F
DisableSandboxing=F
# Multi Threaded Queries MTQ = x Where X = No Of Cores
#MTQ=4
StartupChores=FindServiceAndServerName
# this is the default
AuditLogMaxQueryMemory= 100MB
AuditLogUpdateInterval=60

A very strange thing has happend in our pre production server. When we start up a server, we run a batch to see if it is running, along with the PID number, and what comes up is a server, but with the name 'StartupChores=FindService' (or sometimes without the first character of the name). It seems as if the name of the parameter, along with the chore name, is used for the name of the Server we start.

We edit the parameter so it says: 'Test StartupChores=FindServiceAndServerName' and the same thing happens, a server, upon starting is called that name. It even happens if we comment out that line in the config file!

This only happens in our pre production server, we have the same parameter in our other servers, and this does not happen.

Because the server with the StartupChores=FindServiceAndServerName is an actual server, it (because of our maintenance) restarts every night. We can not turn this off, because it has no actual location, it just piggy backs off somthing else and lives as his own service. This service acts as a real service, which takes up real memory, bounces, etc. Even though, we never set it up, nor does live in our TM1 listing.

We have tried replacing the CFG file and the same thing occurs. We tried restarting our server remotely and it does no good. I have gone through the dump file, but it just takes me to the log,data, and rawstore directory paths of the server we wanted to start up. The dump file also shows a config file, with the data of the orignial server we wanted to start up.

My question is, has anyone ever come up with somthing like this before? Is anyone aware of any problems that arise with the cfg parameter StartUpChores? I have use this parameter many times, and it has been fine. This is very strange behaviour and any information would be most appreciated.

Thank you.

[declanr]

Trevor,

Is the attachment just a section of your config file? I notice you didn't specify ServerName... I've had issues previously with the ordering of ServerName and LDAPServerName as it seems to hone on to the "ServerName" substring as opposed to the whole text. I'd try flipping the order of ServerName above and below your chore to see if it makes a difference. I have a feeling that I recall the cfg file seemingly being read from bottom to top and needing to place ServerName AFTER other references that included servername.

Or try changing your chore name to not include servername.

[tomok]

Trevor,

Is the attachment just a section of your config file? I notice you didn't specify ServerName... I've had issues previously with the ordering of ServerName and LDAPServerName as it seems to hone on to the "ServerName" substring as opposed to the whole text. I'd try flipping the order of ServerName above and below your chore to see if it makes a difference. I have a feeling that I recall the cfg file seemingly being read from bottom to top and needing to place ServerName AFTER other references that included servername.

Or try changing your chore name to not include servername.

It's never a good idea to have a parameter value be equal to the name of another parameter, in any software package, much less something as touchy as TM1.

[declanr]

Trevor,

Is the attachment just a section of your config file? I notice you didn't specify ServerName... I've had issues previously with the ordering of ServerName and LDAPServerName as it seems to hone on to the "ServerName" substring as opposed to the whole text. I'd try flipping the order of ServerName above and below your chore to see if it makes a difference. I have a feeling that I recall the cfg file seemingly being read from bottom to top and needing to place ServerName AFTER other references that included servername.

Or try changing your chore name to not include servername.

It's never a good idea to have a parameter value be equal to the name of another parameter, in any software package, much less something as touchy as TM1.

True, it was actually LDAPVerifyCertServerName I meant... so 2 built in TM1 cfg parameters.

When I first upgraded by customer from 9.5.2 to 10.2 they had this in their existing configs without issue but when I used the existing config file in the new version it went nuts, until the order was changed (which was eventually done as a last ditch guess)... can't remember what the actual problem was though, think the service just wouldn't start.

[rmackenzie]

s anyone aware of any problems that arise with the cfg parameter StartUpChores?

Not that sounds related to your issue, but I had problems with this parameter on 10.2.2 trying to set security permissions including creating clients, groups and assigning clients to groups. It was quite flaky and my guess was it is something to do with the order objects get registered during start-up.

[TrevorGoss]

Hey guys, thanks for your responses.

The issue has now been resolved.

declanr, the cfg file code was just a snapshot of a part of the cfg file, not the entire file.

tomok, I changed the chore name to equal "FindServiceDetails" so the name no longer included "ServerName" which is also a parameter.

It seems as if the chore name was being used as an argument passed to the parameter of ServerName, this could be because the cfg file is read backwards, allthough it does not make sense to me why TM1 would read the cfg file backwards, it does make sense to me because the fake servers that were being created never said "ServerName" but they were being called the string before "ServerName".

All of our services on this server have had the parameter re named along with the chore. It all works fine now, the final test is to see if the fake servers will come back up upon restart tomorrow, they sould not, as I also moved the original server which was the source of all the fake servers to a different drive.

This is all quite strange because the same parameter with the same chore name is also on a different server, and this has not happend, but I think it is best not to have a chore named after another parameter.

Thanks for your help Guys.