Problem with running local server (models)

[MathiasBeckers]

Hi,

I'm faced with the following problem and I was wondering if someone encountered the same thing before. I've installed TM1 on an internal server and the client tools on my personal laptop. No problems with connecting, I can access and open models running on the server without any issues.

Next I wanted to run a local server (model), stored on my laptop, using the connection to the TM1 server of course. I've created an empty folder, I changed the options in TM1 to point to the right directory, but when I press start local server nothing happens. Same issue on the server directly through remote desktop. I've searched within the admin server log but I don't seem to get an error or warning.

Does anyone perhaps know what might be the problem or what I can check? I've been able to run local servers at clients and on my virtual machine but not in the current setup, although I don't seem to understand what might be different or causing the issue.

Perhaps some additional info that might be helpful: TM1 (version 10.1) is running on a Windows Server 2003 (64bit) and I'm connecting using a Windows 7 client operating system with Ms Office 2010 and the 32-bit client tools Architect and Perspectives (also version 10.1).

Thanks in advance.

[Harvey]

I haven't used the "Start Local Server" option for a long time.

However, if you have tm1s.exe in your TM1 bin folder, you can start a local server manually by running this file, with the parameter -z and the path to your tm1s.cfg file.

An example would be:

Code: Select all

"C:\Program Files\ibm\cognos\tm1_64\bin64\tm1s.exe" -z "C:\TM1 Servers\MyServer"

The tm1s.cfg file has a number of options in it that are in the documentation, but each of the samples also has a tm1s.cfg you could copy. For instance, there is one at:

Code: Select all

C:\Program Files\ibm\cognos\tm1_64\samples\tm1\PlanSamp

.

Because all of this is a headache, I have written a Windows application called the Flow Server Manager that takes care of everything for you. It's freeware and can be downloaded here.

[MathiasBeckers]

Lazarus,

Thanks you for your reply. The option you suggest, I believe is only possible from the TM1 server or if you have a TM1 admin server installed on your client, right? I'm aware of how to run new models using the tm1s.exe option, installing them as a windows service or as of version 10 using the TM1 configuration program.

However, the idea behind my request is using local server models during a small training we would like to organize. Rather than everyone working on the same model or setting up a number of test models running on the server, we were thinking of using the local server options so everyone has their own sandbox to play with and we can all do the same exercises. So if I can't figure out how to get these local servers to run I'm thinking of just creating a number of training models running on the server directly.

[jim wood]

You seem to be talking at cross purposes about what a "local" server is (i.e. a real local server (single user, running in Perspectives/Architect) vs what Capt. Kirk (Alan) refers to as a "remote server running locally" (a tm1s.exe application or a tm1sd.exe service on the same machine as the TM1 client). (Credit to Alan for the direct lift)

[MathiasBeckers]

Just to make sure I'm following because indeed I think we're talking about two different things here.

What I'm trying to set up is the possibility to run local models on a client using the "Start local server" option in the file menu of Perspectives or Architect, referencing a local folder on the client's local hard drive.

What I didn't know, and understood from your remarks so please correct me if I'm wrong, is that each client also has the tm1s.exe file installed and should therefore be able to run a model using a shortcut to that file, with an additional -z reference. But this would require a tm1s.cfg file present on each laptop. Would be an alternative workaround I hadn't considered yet but still doesn't explain why I can't just use the "Start local server" option, right?

[rmackenzie]

Just to make sure I'm following because indeed I think we're talking about two different things here.

I do think that there is some talk at cross purposes.

...doesn't explain why I can't just use the "Start local server" option, right?

It does sound like a bug. AFAIK it has always been an option to run a local server from a local data folder on your own machine with just a Perspectives install. There was another thread where a similar matter was discussed. It looks like something has occurred, by error or design, in the last few releases. FWIW I just ran a local server on my laptop on 9.5.2 Perspectives with no problem.

However, the idea behind my request is using local server models during a small training we would like to organize. Rather than everyone working on the same model or setting up a number of test models running on the server, we were thinking of using the local server options so everyone has their own sandbox to play with and we can all do the same exercises.

I'm curious about who you are training. If it is users then I think it is preferable to train them on a central (shared) model as
a) users will want to see that their data entry can be seen by other users, or that it can't if you are using sandpits etc
b) this exposes them to a environment that they will experience in production (i.e. not training)
c) you can talk about the difference between public and private objects and make your point directly
d) you can train them directly on a cut of data they understand rather than example models

What I didn't know, and understood from your remarks so please correct me if I'm wrong, is that each client also has the tm1s.exe file installed and should therefore be able to run a model using a shortcut to that file, with an additional -z reference. But this would require a tm1s.cfg file present on each laptop.

Yes this is a workaround. However, it is either tedious for one to configure if there are many users, or troublesome when the less technical uses need help configuring it themselves. Just having the option of running the local server, against a data directory you can e-mail around, is definitely preferable.

[MathiasBeckers]

It does sound like a bug. AFAIK it has always been an option to run a local server from a local data folder on your own machine with just a Perspectives install. There was another thread where a similar matter was discussed. It looks like something has occurred, by error or design, in the last few releases. FWIW I just ran a local server on my laptop on 9.5.2 Perspectives with no problem.

Thanks for the reference to the other thread, indeed similar to mine and it seems like they are also encountering this on a 10.1 setup. All the more reason to suspect it to be a bug as I also had no problems running local server on a 9.5.x setup. I'm going to look for release notes and see if they have any reference to this issue there. Might also be worth to upgrade to 10.1.1

I'm curious about who you are training. If it is users then I think it is preferable to train them on a central (shared) model as
a) users will want to see that their data entry can be seen by other users, or that it can't if you are using sandpits etc
b) this exposes them to a environment that they will experience in production (i.e. not training)
c) you can talk about the difference between public and private objects and make your point directly
d) you can train them directly on a cut of data they understand rather than example models

I fully agree and if we were creating an end-users training I would indeed use a central model where everyone is connected to so they see and understand that data input is visible to others, that there are differences between public and private views, ... on a model that is very close in setup and in data to what they would get in a production environment. However, this training we're setting up now is intended to train fellow colleagues also on how to create dimensions, cubes, ... That's why I was thinking of using local server models so everyone can jointly create the same, but separate model.

Yes this is a workaround. However, it is either tedious for one to configure if there are many users, or troublesome when the less technical uses need help configuring it themselves. Just having the option of running the local server, against a data directory you can e-mail around, is definitely preferable.

Exactly, this is something i want to avoid. The idea is to give them a folder that contains some of the dimensions and cubes as a starting point and that during the training they complete it by adding dimensions, cubes and rules. Just giving them a small zip and telling them to extract it somewhere, referencing this location in their TM1 options and then starting up their local server seemed like the easiest way to do that.

[MathiasBeckers]

Perhaps a useful addition after checking with IBM Helpdesk:

Starting a local server means starting the TM1 local server that is installed with TM1 Client, without connecting to any TM1 Admin host.
That means that the "Data directory" field, that you see in the TM1 Architect options, is always pointing to the local machine running Architect.

Moreover, this feature was designed in 32-bits and only works with TM1 Client 32-bits.
Since version 10.1, the TM1 Client is provided in the TM1 64-bits installation files but, in this 64-bits version, there is no "tm1s.exe" 32-bits in the /bin directory whereas this is what is required when starting the TM1 local server through Architect.
There was a bug created about this, but Development does not intent to fix it since this feature will soon disappear and since there are other ways to start a server.

Here are the options that you have :

Option 1 - Install the TM1 Client from the TM1 32-bits installation files.
Option 2 - Start the server by creating a shortcut running this command-line :
"C:\Program Files\ibm\cognos\tm1_64\bin64\tm1s.exe" -z "C:\Program Files\ibm\cognos\tm1_64\samples\tm1\PData"

[tomok]

I'm really surprised that the whole "Local Server" concept has lasted as long as it has. It's really a throwback to the day when you could purchase Perspectives as a stand-alone product and run TM1 on your desktop without needing a server. They probably just left it in the Perspectives out of laziness, not wanting to expend resources taking it out of the code. I suspect, given that the 32-bit libraries are no longer installed with the 64-bit client install package, they'll remove it from Perspectives. It's not that big of a deal since you can run the tm1s.exe locally and achieve the same thing. The sad day will be when running tm1s.exe locally is no longer an option.

[Mike Cowie]

Hi All:

Sorry to jump in a little late to the party, but I thought I'd share some of what we'd found out about the local server option (Start Local Server from Perspectives/Architect Server Explorer) in 10.1.x. IBM's suggestion that you just run the 32-bit client install doesn't actually work, by itself, in my experience - there's a little more to it.

The local server option isn't totally dead in 10.1.x. Whether it was meant to be or will be, eventually, I can't say for sure as I don't work for IBM - I recently heard it was not going away, which seems to be the opposite of what the help desk said to Mathias below. Anyway, as of 10.1.x the issue we've found is that key files needed to run a local server were omitted from the install; I don't think earlier versions had this problem. Adding those missing files back in makes the "Start Local Server" menu option work again, allowing you to fire up the same old local server instance. Again, whether that was by design or by accident, who knows, but the menu option is clearly still there in 10.1.x.

So, the only way you can get the option to work again in 10.1.x that we've found is to:

• Install the TM1 Architect and/or Perspectives components from the full 32-bit installation package and include the TM1 Server components in the "TM1 Application Tier" selected in the installation
• Install the TM1 Architect and/or Perspectives components from the 32-bit client-only or 64-bit (yes, you can install the 32-bit client components from the 64-bit TM1 installer now) installation package. Copy the 32-bit files that are omitted from an installation done using the previous method.

The latter option I would say is probably safer from a licensing compliance perspective.

The 32-bit files that are omitted are at least the following:

• tm1s.exe
• tm1admsrv.exe

In one instance we also had to copy over additional, missing, 32-bit items the 2 files above depend on:

Files:

• CCLCFGAPI.dll
• CCLCore.dll
• CCLCryptoShared.dll
• CCLIDOM.dll
• IBJStreamsDLL.dll
• icucogdt40.dll
• icuin40.dll
• icuuc40.dll
• xerces-c_2_7.dll
• zlib1.dll

Folder & folder contents:

• icucogdt40l

Any of the missing files above must be the 32-bit versions and must be copied to the 32-bit bin folder that houses the Architect exe (TM1A.EXE) or the Perspectives add-in (TM1P.XLA). That folder is pretty obvious if you've used a 32-bit installation package, but in the 64-bit install it is here, by default:
C:\Program Files\ibm\cognos\tm1_64\bin\

I'm not saying this is a great workaround, especially if you have applied fix packs, but it is a workaround nonetheless. Be advised that I still think you need the right user license to run a local server from Perspectives or Architect - I'm sure Modelers are covered, but I doubt someone with an Explorer license is permitted to run a local server and can't remember if a Contributor is allowed to run a local server.

Hope that helps! We've also reported the issue and it's been acknowledged as Mathias noted below - hopefully this installation issue will be resolved in a future release if the feature is going to continue to exist.

Regards,
Mike

[tomok]

All I can say about this is WOW! This isn't a bug, this is major functionality not working. Where was the regression testing on IBM's part before they released this? I guess they were too busy building a smarter planet to actually test their software. I never use the Local Server option so I didn't realize this problem exists in 10.1. I can't believe they haven't issued a fix yet. I would be mortified if I was in charge of the quality control team in charge of building the install packages.