New TM1 server configuration parameters in TM1 10.2.2.3

[moby91]

A new version of the manual IBM Cognos TM1 Installation and Configuration Guide has been published.

http://www-01.ibm.com/support/knowledge ... RXT_10.2.2
TM1 Installation and Configuration Guide 10.2.2.3
Introduction


Comparing the new version, 10.2.2.3, against the previous latest version, 10.2.2.1, there are numerous new TM1 server configuration parameters, and some old ones are gone.

http://www-01.ibm.com/support/knowledge ... le_N1503FE
TM1 Installation and Configuration Guide 10.2.2.1
The Tm1s.cfg Server Configuration File >
Parameters in the Tm1s.cfg File

http://www-01.ibm.com/support/knowledge ... le_N1503FE
TM1 Installation and Configuration Guide 10.2.2.3
The tm1s.cfg Server Configuration File >
Parameters in the tm1s.cfg File


New parameters:

AdminSvrSSLCertAuthority
AdminSvrSSLCertID
AdminSvrSSLCertRevList
AdminSvrSSLExportKeyID
ApplyMaximumViewSizeToEntireTransaction
AutomaticallyAddCubeDependencies
CacheFriendlyMalloc
CertificateVersion
ClientExportSSLSvrCert
ClientExportSSLSvrKeyID
CognosMDX.AggregateByAncestorRef
CognosMDX.CellCacheEnable
CognosMDX.PrefilterWithPXJ
CognosMDX.SimpleCellsUseOPTSDK
CognosMDX.UseProviderCrossJoinThreshold
DHFile-512
DHFile-1024
DHFile-2048
ExportAdminSvrSSLCert
ExportSvrSSLCert
HTTPPortNumber
HTTPSessionTimeoutMinutes
JavaClassPath
JavaJVMArgs
LDAPHost
LDAPPort
LDAPSearchBase
LDAPSearchField
LDAPSkipSSLCertVerification
LDAPSkipSSLCRLVerification
LDAPVerifyCertServerName
LDAPVerifyServerSSLCert
LDAPWellKnownUserName
MTQ.OperationProgressCheckSkipLoopSize
MTQ.SingleCellConsolidation
ODBCLibraryPath
OracleErrorForceRowStatus
PerfMonIsActive
ServerCAMURIRetryAttempts
SSLCertAuthority
SSLCertificate
SSLCertificateID
SSLCertRevocationFile
SSLPrivateKeyPwdFile
SSLPwdKeyFile
SvrSSLExportKeyID
TM1ConnectorforSAP
UseNewConnectorforSAP
UserDefinedCalculations
ZeroWeightOptimization


Gone parameters:

GroupsCreationLimit
MaxUndoHoldLineCount
SpreadingPrecision (Consolidated Holds)
SAPLogFilePath
SAPLoggingEnabled

[lotsaram]

If GroupsCreationLimit is no longer a valid parameter as of 10.2.2 FP3 that is quite BIG news!

This would indicate that there is no longer a limit on the number of security groups which can be created in a server session, which in turn would indicate a not insignificant change in how memory is allocated to TM1's security model...

[Duncan P]

It is quite possible that a number of these have been around for a while but that this is the release in which they are first documented. I certainly recognise ZeroWeightOptimization and CognosMDX.UseProviderCrossJoinThreshold from before.

[Alan Kirk]

If GroupsCreationLimit is no longer a valid parameter as of 10.2.2 FP3 that is quite BIG news!

This would indicate that there is no longer a limit on the number of security groups which can be created in a server session, which in turn would indicate a not insignificant change in how memory is allocated to TM1's security model...

Not necessarily, at least not the "significant" part. Remember that it was always an "on paper" limit anyway because as per the caveat in the documentation (which agreed with my own experience when setting up a new model):

The GroupsCreationLimit value is not enforced when you create groups with the AddGroup function in TurboIntegrator.

Accordingly the parameter provided a hard, iron clad restriction... unless you really, really want to break it, in which case just waltz on through the door.

That being the case the devs may have thought "what's the point of allocating some extra memory to allow for a certain level of group creation if that level is only theoretical anyway? May as well just allocate the amount needed and up it as groups are created." That would basically match what had already been happening when TI was used to create the groups.

More to the point, in most well designed systems the limit was irrelevant as you won't be adding humungous numbers of new groups in a session (or, in most sessions, any groups at all), unless that session is setting up a new model. And sometimes not even then. So what's the point of factoring in extra memory for new security groups (that may never be created at all)? It's just a few extra calculations that yield no practical value.

I think this was just a bit of housekeeping. It'll only make a practical difference if an admin was dumb enough to jack the value up to some ridiculously stratospheric figure, enough to cause the server to run out of memory when the calc was done.

[lotsaram]

My experience has been different in that yes true that using TI AddGroup would add an element to the }Groups dimension and the process would complete without error but with a caveat that once the groups creation limit was exceeded then any security settings applied to such a group were not applied. i.e. the new group was created but it remained outside the "security model" until the next server restart. A particularly annoying and hard to diagnose "silent failure". Give me an explicit error message any day.

Maybe this changed and got corrected in later versions. I'd be glad if it did but would never have noticed as I have always had GroupsCreationLimit set to a sensibly high number to never come across hitting it.