Tm1s.cfg my own parameters

[artur_r]

Hi all,

Is there any issues with adding parameters in tm1s.cfg which don't exist?
E.g. we need parameter to determine if current model is production or non-production (lets call it ProductionServer=0)
The idea is: at model startup chore executes, process reads tm1s.cfg and puts this parameter into cube "System_Paramaters"

I have investigated this idea on test server (with full restart) and everything seems fine.

[Alan Kirk]

Is there any issues with adding parameters in tm1s.cfg which don't exist?
E.g. we need parameter to determine if current model is production or non-production (lets call it ProductionServer=0)
The idea is: at model startup chore executes, process reads tm1s.cfg and puts this parameter into cube "System_Paramaters"

I have investigated this idea on test server (with full restart) and everything seems fine.

I don't think there will be a problem doing that, but... why take the risk? Why not have a non-system identifier file somewhere in the path which contains your config file; a plain text file that contains the name of your instance, and have the startup chore read that instead?

You would need to be careful not to overwrite that file when copying from Prod to Dev of course... but that's also true of your config file.

Alternatively if you do as I do and use different port numbers for your production and dev servers (even though they run on different boxes) you could read your config file, look up the port number and determine the instance from a standard mapping cube which exists on all servers. That way you again aren't stinking up your config files with non-existent settings.

[artur_r]

Thanks Alan,

I like the idea of using different ranges of ports for production/non-production models and will try to implement it

[tomok]

Hi all,

Is there any issues with adding parameters in tm1s.cfg which don't exist?
E.g. we need parameter to determine if current model is production or non-production (lets call it ProductionServer=0)
The idea is: at model startup chore executes, process reads tm1s.cfg and puts this parameter into cube "System_Paramaters"

I have investigated this idea on test server (with full restart) and everything seems fine.

So, I assume you are using the same name for your TM1 servers whether they are prod or non-prod? If not, then why not just read the tm1.cfg file and read the server name to determine if it is prod or non-prod. BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

[artur_r]

Hi all,

Is there any issues with adding parameters in tm1s.cfg which don't exist?
E.g. we need parameter to determine if current model is production or non-production (lets call it ProductionServer=0)
The idea is: at model startup chore executes, process reads tm1s.cfg and puts this parameter into cube "System_Paramaters"

I have investigated this idea on test server (with full restart) and everything seems fine.

So, I assume you are using the same name for your TM1 servers whether they are prod or non-prod? If not, then why not just read the tm1.cfg file and read the server name to determine if it is prod or non-prod. BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

We have different names for each tm1 server, also (though very rarely) we can have multiple production servers at the same time for different purposes ( e.g. on one production server users are closing current month, on another previous month)
In this case we should handle some cube and update it with new production tm1 server name everytime when it appears.
As we have large distributed team someone can forget to do this, therefore I was looking for solution which helps me to skip this step

[tomok]

We have different names for each tm1 server, also (though very rarely) we can have multiple production servers at the same time for different purposes ( e.g. on one production server users are closing current month, on another previous month)
In this case we should handle some cube and update it with new production tm1 server name everytime when it appears.
As we have large distributed team someone can forget to do this, therefore I was looking for solution which helps me to skip this step

If each server is name differently then why not read the value for ServerName in the tm1s.cfg file instead of creating your own value? Here is the code I use in the Data tab of a process where I do that:

Code: Select all

sParam = SUBST(V1, 1, 10);
IF(sParam @= 'ServerName');
  sServer =SUBST(V1, 12, LONG(V1) - 11);
  CELLPUTS(sServer, 'Global Variables', 'Value', 'SERVER');
ENDIF;

The tm1s.cfg file is the data source for this process and I am writing the name of the server to a cube called Global Variables.

[gtonkin]

...Here is the code I use in the Data tab of a process where I do that...

Start up chore to run and update?

[tomok]

...Here is the code I use in the Data tab of a process where I do that...

Start up chore to run and update?

Yes, that is one of the processes I run at server startup.

[Alan Kirk]

BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

My mileage varies greatly indeed. If I'm having users testing reports in a dev environment (especially complex reports which draw from multiple servers), websheets on TM1 web etc, etc, I want them using EXACTLY the same documents that they are or will be using in production. Faffing around changing server names is not just more work, it's the embodiment of the expression "something is going to get missed".

[Wim Gielis]

BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

My mileage varies greatly indeed. If I'm having users testing reports in a dev environment (especially complex reports which draw from multiple servers), websheets on TM1 web etc, etc, I want them using EXACTLY the same documents that they are or will be using in production. Faffing around changing server names is not just more work, it's the embodiment of the expression "something is going to get missed".

For me as well. Prod and non-prod with the same name on different boxes.

[Alan Kirk]

BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

My mileage varies greatly indeed. If I'm having users testing reports in a dev environment (especially complex reports which draw from multiple servers), websheets on TM1 web etc, etc, I want them using EXACTLY the same documents that they are or will be using in production. Faffing around changing server names is not just more work, it's the embodiment of the expression "something is going to get missed".

For me as well. Prod and non-prod with the same name on different boxes.

Yes, that's an important qualification. Also, to avoid confusion I only have the dev servers up when I'm actually dev-ing, and just in case there is still any confusion there is a server that runs perpetually on the Dev machine. It's a server which has no cubes, no users, no anything... except the name 00YouAreOnTheDevServer. If anyone still gets confused about where they are then, they're beyond my help.

[PavoGa]

BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

My mileage varies greatly indeed. If I'm having users testing reports in a dev environment (especially complex reports which draw from multiple servers), websheets on TM1 web etc, etc, I want them using EXACTLY the same documents that they are or will be using in production. Faffing around changing server names is not just more work, it's the embodiment of the expression "something is going to get missed".

We have the same instance name across servers. Our DEV server does have additional instances.

[tomok]

BTW, I don't like the idea of having prod and non-prod services sharing the same name. YMMV.

My mileage varies greatly indeed. If I'm having users testing reports in a dev environment (especially complex reports which draw from multiple servers), websheets on TM1 web etc, etc, I want them using EXACTLY the same documents that they are or will be using in production. Faffing around changing server names is not just more work, it's the embodiment of the expression "something is going to get missed".

We have the same instance name across servers. Our DEV server does have additional instances.

When you have on-premise TM1 you have a lot of luxuries those of us in the IBM Cloud do not. We have two cloud instances, one for production and one for non-production. On that non-production I have to have a DEV service and a UAT service (for SOX purposes). Since you can't have two TM1 services with the same name up at the same time on one server that blows up any idea of having all my TM1 services with the same name.

[Alan Kirk]

My mileage varies greatly indeed. If I'm having users testing reports in a dev environment (especially complex reports which draw from multiple servers), websheets on TM1 web etc, etc, I want them using EXACTLY the same documents that they are or will be using in production. Faffing around changing server names is not just more work, it's the embodiment of the expression "something is going to get missed".

We have the same instance name across servers. Our DEV server does have additional instances.

When you have on-premise TM1 you have a lot of luxuries those of us in the IBM Cloud do not.

{Facepalm, sigh...} As if there weren't enough reasons for avoiding the cloud (more precisely IBM's implementation of the cloud) like the plague...

Imagine this situation with running DEV / UAT instances of an SQL Server instance in Azure, AWS, etc, where a new instance means (a) Making a copy of the disk image, (b) Creating a new server instance, (c) Firing her up and (d) Pointing to the new instance for testing. Still, this is the company that regards this "improvement" in PAW 2.0.62 as being a Big! Leap! Forward!

Planning Analytics on Cloud customers can now delete TM1 databases by using Planning Analytics Workspace Administration. You no longer need to submit a support ticket to have a TM1 database deleted for you.

The self-service delete action removes the database from the user interface. However, the database directory and its contents are retained on the data tier. You can later decide whether they should be deleted, moved, copied, or kept on the data tier.

You must use the Planning Analytics Workspace new interface, which is also referred to as New Experience, to delete the database. This functionality is not available in the Planning Analytics Workspace Classic Experience.

The comparable action in AWS:

1. Go to the dashboard.
2. Delete the instance.
3. Click [Yes] to confirm.

Since you delete instances separately from their data storage, whether you retain the database folder is in your hands.

Not to wish to state the bleeding obvious, but this is the sort of thing that should have been under user control from day one whereas the Cloud offering has been running for ... {rhetorically} HOW many years now? And they've only just NOW gotten around to this? Much like the restriction on how many instances you have in cloud, to me this speaks to (yet another) complete failure on IBM's part to understand real world usage of the product.

Raise a support ticket with the necessary human costs just to delete a database. For frick's sake... It's no wonder that IBM can't turn a profit on this sort of thing.

We have two cloud instances, one for production and one for non-production. On that non-production I have to have a DEV service and a UAT service (for SOX purposes).

That is indeed one advantage that we have in the Land Down Under; we don't have to give the time of day to that oversized load of legalistic blather which is the walking definition of "being seen to do something" while in fact achieving nothing. Well, nothing except the prodigious generation of red tape, anyway.

SEC. 406. CODE OF ETHICS FOR SENIOR FINANCIAL OFFICERS.(a) CODE OF ETHICS DISCLOSURE.—The Commission shall issue rules to require each issuer, together with periodic reports required pursuant to section 13(a) or 15(d) of the Securities Exchange Act of 1934, to disclose whether or not, and if not, the reason there for,such issuer has adopted a code of ethics for senior financial officers, applicable to its principal financial officer and comptroller or principal accounting officer, or persons performing similar functions.

Yeeeeah, that'll fix it.
"Our Code Of Ettics (sic) for La Cosa Nostra: We're legitimate businessmen who run a legitimate business. We don't know nothing about any organised racketeering or stock market manipulation."

And having this extra piece of time consuming paperwork that nobody reads (aside from the person who wrote it) as their waste bin liner has modified many a person's behaviour no end.

Since you can't have two TM1 services with the same name up at the same time on one server that blows up any idea of having all my TM1 services with the same name.

You're welcome to Cloud. As I said, I really don't need more reasons to avoid it, but thanks for this one.