TM1 Forum

Is there a function that would return the TM1 versions used?

bjones wrote:Is there a function that would return the TM1 versions used?

Mmm, wouldn't that be nice. Grown up programs actually have that on both the client side (any program in Office, right down to patch and build) and the server side (SQL Server) if applicable.

There's a classic API function called TM1SystemVersionGet which will return the API version. It tells you nothing about the server version and it's possible (if unlikely) that the API libraries being used are not the same version as Client/Architect so you can't rely on it for that either.

I'm not sure about Muddler and Infight but I'd be surprised.

At present the only method I know of is to go digging in the mud and determine the versioning numbers shown when you right click on the various installation files and check the Details tab. (tm1sd.exe on the server side and tm1p.dll on the client side are usually fairly representative.) Even then you'll probably need to check with Support to determine what SR / HF etc the thing relates to.

Yeah, i was able to find the version from tm1sd.exe and a link on IBM that explains what every numbers means (versions, fix patches...) but just wanted to make sure that i wasn't missing something obvious. I guess at this point i'll just hard code it since the version doesn't change that often
Thanks for your reply

Assuming you're on windows you can use the wmic command to retrieve the version number
If you set this up in the prolog of a process that's using a text file as a data source with one header row, you will process a file that looks like :

Version
10.1.00100.24600

From previous contact with IBM support it is possible to workout what the version numbers are telling you, here's what they sent to us:

Breaking this one down:
10.1.00100.24600

"10.1.0" = TM1 10.1.0

"00100" = FP1

"24600" = Build number, useful for us/dev.

The important numbers are the middle ones (00100).

The first is part of the major release (aka 10.1.10000 = TM1 10.1.1)

The next 2 numbers are for the FP.

The last 2 numbers are for the IF (aka Hotfix).


To provide more info:

10.1.00100.24600 = TM1 10.1.0 FP1

10.1.10000.26473 = TM1 10.1.1 Base Release

10.1.10100.31864 = TM1 10.1.1 FP1 (For 10.1.1 FP2 this would be 10.1.10200.xxxxx)

10.1.10104.34644 = TM1 10.1.1 FP1 IF4

There is some official documentation on finding and understanding the version strings - http://www-01.ibm.com/support/docview.w ... wg21457063.

Looks like it needs some updating though. The terminology has changed over time, but I believe this numbering has been pretty consistent since 9.5 server

Are you looking for just TM1 server version, or do you want clients too? Are you just looking for the version strings to be exposed in the UIs somewhere or do you actually want to dynamically retrieve (and use) them? If so, what's the use case?

failurehappening wrote:Assuming you're on windows you can use the wmic command to retrieve the version number

That's very clever. More fiddly than we should ever need to bother with, but in the absence of something more straightforward it's an inspired piece of coding.

BrianL wrote:There is some official documentation on finding and understanding the version strings - http://www-01.ibm.com/support/docview.w ... wg21457063.

Looks like it needs some updating though. The terminology has changed over time, but I believe this numbering has been pretty consistent since 9.5 server

Yes, the terminology was why I was a touch reluctant to trust that fully without confirmation from Support, with "Maintenance Releases" clearly being left over from the old Applix days. But I agree that you're right, looking over various version installs it does seem to be more or less the same pattern as was established there.

BrianL wrote:Are you looking for just TM1 server version, or do you want clients too? Are you just looking for the version strings to be exposed in the UIs somewhere or do you actually want to dynamically retrieve (and use) them? If so, what's the use case?

On the client side I'd think that the main user case is that every software company and its dog puts an About -> Version entry in its client software for an obvious reason; "what version are you on?" is the number 2 support question after "what program are you using?". If you have 150 users using a piece of client software and you find that some of them are having problems that should have been sorted in a patch, you don't want to have to go to their workstations and start digging through their hard drives when the (faster, quicker, cleaner) option is to ask them to just go to the Help menu and select About.

Unfortunately IBM tends to take the view that this should be unnecessary because everyone deploys the latest version the instant it becomes available. This theory does not necessarily coincide well with real life practice, and it's not uncommon for multiple client versions to still be hanging around on different machines across the business. Being able to quickly and easily identify exactly which version (including FP, HF etc) that a user is on is of pretty significant value in a real life deployment.

If it can be automated so that it can be grabbed via code (say via a worksheet function) so much the better, as it would be possible to then simply have users open a workbook which will "phone home" the relevant information making life far easier for the administrators.

If it's in a 50 buck screen grab program like Snagit, I think it's not unreasonable for it to be in a program which costs as much as TM1 does. On the server side, let's consider how a few other pieces of software (again costing far less than TM1) handle it:

Microsoft Powershell SQL Server TM1 Leaving aside that this is not a good look, if you want the specifics of why a function returning the version number from the server would be a seriously good idea I refer you to this post by Lotsaram, which expresses it as well as I've seen it expressed.

I agree. It's stupid that you can't retrieve the version string from the various UIs.

Alan Kirk wrote:Leaving aside that this is not a good look, if you want the specifics of why a function returning the version number from the server would be a seriously good idea I refer you to this post by Lotsaram, which expresses it as well as I've seen it expressed.

Code branching as Lotsaram describes would be valuable, but wouldn't that require far more than just a new TI function to return the version?

If a TI script contains a call to a function that's not defined the entire TI will be marked incomplete regardless of whether that code path can be hit. This will prevent the TI from executing anyway.

Best you could probably do with version number retrieval is separate TIscriptv95, TIscriptv101, etc... and have a 'dispatcher' style TI that calls the appropriate TI, but that hardly cuts down on the headaches.

Thanks for your help guys