Page 1 of 1
ISM won't open - fresh 9.1 installation
Posted: Wed Sep 11, 2013 2:19 pm
by wwilliamson
When I try to open the Information Server Manager (ISM) the splash screen appears and disappears but the application never opens.
An error log file is created each time I try to open ISM. I wasn't sure if it was preferred to paste the contents inline or if it's better to attach the whole file afterward, but below is the relevant portion of a stack trace from the bottom of the file.
Code: Select all
!ENTRY org.eclipse.osgi 4 0 2013-09-11 15:36:38.482
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: Application "com.ibm.istools.manager.ui.application" could not be found in the registry. The applications available are: com.ibm.istools.rcp.application, ...
at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:248)
...
I ran a number of ISA Lite collectors and came up with no obvious issues.
Does ISM usually work out of the box or is there some extra config I've got to do?
I didn't see anything particular on this forum or IBM DeveloperWorks, and the documentation has precious little information about ISM; the installation guide doesn't even appear to mention it.
I put my actual config info in the Additional info section because there isn't an option for 9.1 in the release dropdown.
Posted: Wed Sep 11, 2013 4:33 pm
by ray.wurlod
Check your install log carefully. Look for any errors or warnings, especially for any marked as SEVERE.
SEVERE Eclipse log messages in the installation log.
Posted: Thu Sep 12, 2013 8:47 am
by wwilliamson
Thanks for the tip; that definitely moved me in the right direction. The installation log contained only two "SEVERE" messages; both contain an Eclipse stack trace and indicate that the installer was attempting to connect to the metadata repo using the DataStage server name instead of the db server name. Here's a sample.
Code: Select all
2013-07-26T14:06:56.482, INFO: URL = jdbc:ibm:sqlserver://OurDsServer.OurDevDomain.local:1433;DatabaseName=xmeta
2013-07-26T14:07:08.831, SEVERE: com.ibm.is.install.check.PreInstalledDatabaseChecker
java.sql.SQLNonTransientConnectionException: [IBM][SQLServer JDBC Driver]Error establishing socket to host and port: OurDsServer.OurDevDomain.local:1433. Reason: Connection refused: connect
at com.ibm.isf.jdbc.sqlserverbase.dda4.b(Unknown Source)
...
at com.ibm.is.install.atlasinstaller.ui.View$1.widgetSelected(View.java:98)
at org.eclipse.swt.events.SelectionEvent.dispatchToObserver(SelectionEvent.java:176)
...
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:116)
at java.lang.Thread.run(Thread.java:736)
2013-07-26T14:07:08.831, INFO: FAILED: CDIPR2079I: Ensure that user xmeta can connect to the database xmeta on host OurDsServer.OurDevDomain.local at port number 1433 and has create table, create view, create index, and create trigger rights. Resolution: Ensure that user xmeta can connect to database xmeta on host OurDsServer.OurDevDomain.local at port number 1433 and has create table, create view, create index, and create trigger rights.
Is this kind of installation corruption automatically PMR material or is there a known remedy for this kind of thing?
Posted: Thu Sep 12, 2013 4:17 pm
by ray.wurlod
Check the xmeta user to see whether it has a large number of failed logins and, if so, reset the failed login count to zero. Then check that you're using the correct xmeta password.
Other than that, a PMR will get you excellent and professional assistance.
Issue is now moot
Posted: Tue Oct 01, 2013 2:50 pm
by wwilliamson
The server where this problem was occurring has now been decommissioned so this issue is no longer relevant. I know that under normal circumstances I would mark an answer, but since the issue more or less vanished with the server, what should I do?
Posted: Tue Oct 01, 2013 3:10 pm
by chulett
Note the facts as you just did and then... move on.
If you want to officially close the topic, mark it as a Workaround. We'll consider the decommissioning of the server as your workaround.
