TM1 Forum

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

stex2727 wrote: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:

TM1 Operations Guide wrote: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.)

stex2727 wrote: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.

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

blackhawk wrote:

stex2727 wrote: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

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

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