Changing port numbers without restarting TM1 service?

[stex2727]

In my test environment I managed to duplicate the port numbers in tm1s.cfg with another TM1 server and obviously cannot access the server. Normally it's just a doh moment and change the setting and restart the service, but in this case the server takes an hour to load and thats a lot of doh's. I was wondering if there is a way to change the port number without restarting the service?

I'm sure there's other settings as well that should be able to be changed and not require a server restart.

Steve

[Alan Kirk]

In my test environment I managed to duplicate the port numbers in tm1s.cfg with another TM1 server and obviously cannot access the server. Normally it's just a doh moment and change the setting and restart the service, but in this case the server takes an hour to load and thats a lot of doh's. I was wondering if there is a way to change the port number without restarting the service?

I'm sure there's other settings as well that should be able to be changed and not require a server restart.

There are dynamic parameters, but the manual tells you which ones they are. This is not one of them. Page 50 of the 9.5.1 Operations Guide:

PortNumber
Sets the server port number used to distinguish between multiple servers running on the same
computer. When multiple TM1® servers are installed on a single computer, each server must use a
unique port number.
Parameter type:
● Optional
● Static
If you change this parameter value, restart the TM1 server to apply the new value.

(My emphasis.)

[blackhawk]

In my test environment I managed to duplicate the port numbers in tm1s.cfg with another TM1 server and obviously cannot access the server. Normally it's just a doh moment and change the setting and restart the service, but in this case the server takes an hour to load and thats a lot of doh's. I was wondering if there is a way to change the port number without restarting the service?

Alan stated where you should go to find out what is dynamic and what is static, but here is a tip for you as well:

If you want to try out a few settings (for ones that do require a restart) but don't want to wait:

• Create a folder in the cubes data directory called 'Disabled Rules'
• Move all the .RUX files in it
• Start the server
• Check out the impact of the setting
• If it worked the way you anticipated, then move all the .RUX files back
• Delete the folder
• Restart the server for real

Without the .RUX files, your server should start pretty quickly. If the cubes are very large, and it still takes a long time to load, then just start a "Test #2" instance with some of the bigger cubes removed, just so you can validate the changed setting. Once you get the options set the way you want, update your production/dev instance and restart.

[stex2727]

Thanks for that Alan,

I've normally just restarted the service every time I've changed a parameter. Nice to know there are parameters that don't require a restart of the service but unfortunately not this one.

Steve

[stex2727]

In my test environment I managed to duplicate the port numbers in tm1s.cfg with another TM1 server and obviously cannot access the server. Normally it's just a doh moment and change the setting and restart the service, but in this case the server takes an hour to load and thats a lot of doh's. I was wondering if there is a way to change the port number without restarting the service?

Alan stated where you should go to find out what is dynamic and what is static, but here is a tip for you as well:

If you want to try out a few settings (for ones that do require a restart) but don't want to wait:

• Create a folder in the cubes data directory called 'Disabled Rules'
• Move all the .RUX files in it
• Start the server
• Check out the impact of the setting
• If it worked the way you anticipated, then move all the .RUX files back
• Delete the folder
• Restart the server for real

Without the .RUX files, your server should start pretty quickly. If the cubes are very large, and it still takes a long time to load, then just start a "Test #2" instance with some of the bigger cubes removed, just so you can validate the changed setting. Once you get the options set the way you want, update your production/dev instance and restart.

Nice tip, thanks

Steve

[Martin Ryan]

Another idea, if you're on the requisite version (9.5.1 I think) you can also use persistent feeders to speed up your start time.

Hope the Hutt's treating you well.

Martin

[stex2727]

Ta for that, will look into persistent feeders once things settle down a bit. Hutt's not so bad,but there's only so long they could keep me out of the city, I'm now working 3 days a week at post house looking at some of your handiwork

Steve