Tuesday, March 4, 2008

Upgrade from ITM6.1 FP6 to ITM6.2 may break logon through IE TEP

It is great that ITM 6.2 brings about some good new features. However along with the good features are some painful issues that may ruin ones fun with the product at least for some moment. Herein is one pain I and others had to endure after an upgrade from ITM6.1 FP6 to ITM6.2 some few days ago. This document hopes to help one quickly eliminate at least one of the many possible pains that come with the upgrade to ITM 6.2.

Please bare in mind as you read through that the problem may be dependent upon ITM components installed in your ITM6.x environment.


The environment this problem was witnessed on had a TEMS & TEPS running on a Windows 2000 Server(Dual 3.06 GHz Intel Xeon with Hyper-threading and 3808MB ram) with ITM required patches. Internet browser used to logon to TEP was Internet Explorer 6.x running on an XP Professional host.


When you attempt to logon to the TEP through Internet Explorer (IE) you get an back the following error during user validation dialogue:

KFWITM001W Unable to connnect to Tivoli Enterprise Po....

Increased tracing for the Plugin150.trace reported amongst many other things, the errors that read as follows:

(475405aa.0c474f80-(null)AWT-EventQueue-2:Bundle,0,"Bundle.Bundle(String,String,Locale,String)") Resource bundle: id = kjri, baseName = candle.kjr.resources.KjrImageBundle, actual locale used:

(475405b4.10ed7f00-(null)Thread-10:DataBus,0,"DataBus.make()") EXCEPTION: Unable to create DataBus object: org.omg.CORBA.INITIALIZE: Could not initialize (com/borland/sanctuary/c4/EventHandler) unexpected EOF at offset=0 vmcid: 0x0 minor code: 0 completed: No

(475405b4.10ed7f00-(null)Thread-10:QueryModelMgr,0,"QueryModelMgr.QueryModelMgr()") EXCEPTION: InstantiationException --> Unable to instantiate DataBus object

(475405b4.10ed7f00-(null)Thread-10:QueryModelMgr,0,"QueryModelMgr.make()") EXCEPTION: InstantiationException --> Unable to instantiate QueryModelMgr object

(475405b4.10ed7f00-(null)Thread-10:LogonDialog,0,"LogonDialog.processOK()") EXCEPTION: Unable to connect to CandleNet Portal server: java.net.ConnectException

(475405b6.33611380-(null)AWT-EventQueue-2:CNPClientMgr,0,"CNPClientMgr.terminate(CNPAppContext,boolean)") Performing normal exit of TEP Workplace

(475405b6.33611380-(null)AWT-EventQueue-2:UserManager,0,"UserManager.loadPermissionXRef()") Error loading User Permission Cross-Reference tables: KFWITM219E Request failed during creation.

The extracted log messages above are pretty misleading because they kind of make the problem look like a network communication problem!

After sending the applet.html that reside ..\cnb directory on TEPS server to ITM developers, the following was determined to be the root cause.

There were two problems in applet.html that are believed to have led to the original connection symptom.

In applet.html, the set of jar files associated with the TEP applet is listed in the CACHE_ARCHIVE statement. This is a comma-separated list of jar file names. The first problem was that embedded within the list were two commas separated by one or more spaces, but no jar file was listed between them (an empty entry). The java plug-in associated with the browser would consider this construct to be illegal and very likely ignored the rest of the jars listed in the archive statement; the jars that were ignored were never downloaded, but were needed to successfully initialize the TEP client.

Associated with the CACHE_ARCHIVE statement, there is a CACHE_VERSION statement that identifies the version number of the jar file that positionally corresponds to that version number (e.g., the first version number listed in the version statement corresponds to the first jar file listed in the archive statement; the second version number corresponds with the second jar file, and so on). By definition, the number of versions listed in the CACHE_VERSION statement should always match the number of jar files listed in the CACHE_ARCHIVE statement. However, in this case, there was one additional version element in the version statement that did not correspond to any jar files found in the archive statement. This too would be considered invalid by the java plug-in, with undetermined results.


The developers rectified the corrupted applet.html file I had sent them for analysis, and sent back the corrected file to replace the old corrupted one with.

If you are interested in the edited applet.html just "simply" shoot me a message and I'll gladly send it to you. But please note that by requesting for it, you're assuming complete responsibility for whatever may go wrong with your environment due to your usage of it.

During troubleshooting we had increased the trace levels for the TEP running on IE to "ERROR FLOW DETAIL" which brought the TEP to a grounding halt after the fix was applied and we were able to logon successfully. So it is important to reduce to an acceptable minimum (i.e. kjr.trace.params = ERROR) the TEP tracing after troubleshooting is complete (just another best practice). Else the TEP GUI will just remain frozen after successful logon.

I hope the above eases the pain to a resolution should another experience the same problem.

J. Napo Mokoetle
"May the wind always be at your back and the sun upon your face. ..."

No comments: