This chapter provides information that enables you to use message logs and traces to diagnose problems that could occur when users interact with your HATS application. It also outlines some problems that could be encountered, and solutions to those problems.
When a HATS application runs in the WebSphere Application Server, logging and tracing is performed for the application. Logging and tracing is controlled by the settings of the runtime.properties file. The location of this file differs between the machine where you installed HATS Studio and the server machine where your applications run:
You can use any text editor to modify the runtime.properties file. If you modify the file, you must stop and restart the server that is running the application for the changes to take effect.
The runtime.properties file contains the following basic properties:
The value is an integer. There is no default. Specify num_licenses = - 1 if you purchased an unlimited license.
The maximum size of the license usage files is 512 KB. When the file size of the license1.txt file reaches 512 KB, the file is renamed to license2.txt and a new license1.txt file is created. The new license1.txt file contains the most recent license usage information. When the new license1.txt reaches 512 KB and is renamed, the old license2.txt is deleted.
The license usage files contain the following information, arranged in rows, with each row representing one hour of operation. The values are separated by a space ( ).
The base trace file name in runtime.properties is used as a template to generate unique sets of trace files for each application server. The default base name for a trace file is trace.txt, which can be changed.
An index (1, 2, 3, and so forth) is added to this name to distinguish multiple trace files. When trace1.txt reaches maxTraceFileSize, it is closed and renamed to trace2.txt. A new trace1.txt file is opened.
When the maxTraceFiles number is exceeded, the oldest file is deleted.
The location of the trace*.txt files differs between the machine where you installed HATS Studio and the server machine where your applications run:
The value is a decimal integer. The default is 1024 KB.
The base message log file name in runtime.properties is used as a template to generate unique sets of message log files for each application server. The default base name for a log file is messages.txt, which can be changed.
An index (1, 2, 3, and so forth) is added to this name to distinguish multiple message log files. When messages1.txt reaches maxLogFileSize, it is closed and renamed to messages2.txt. A new messages1.txt file is opened.
When the maxLogFiles number is exceeded, the oldest file is deleted.
The location of the messages*.txt files differs between the machine where you installed HATS Studio and the server machine where your applications run:
The value is a decimal integer. The default is 512 KB.
The runtime.properties file contains the following HATS server tracing properties:
The value is an integer from 0-9. The default is 0.
See the description of the tracelevel.* keys for information on values for this setting.
The value is an integer from 0-9. The default is 0.
See the description of the tracelevel.* keys for information on values for this setting.
The value is an integer from 0-9. The default is 0.
See the description of the tracelevel.* keys for information on values for this setting.
The value is an integer from 0-9. The default is 0.
See the description of the tracelevel.* keys for information on values for this setting.
The value is an integer from 0-9. The default is 0.
See the description of the tracelevel.* keys for information on values for this setting.
The values of tracelevel.1 through tracelevel.7 should not be changed unless requested by IBM support. Otherwise, specifying these seven tracelevel.* properties is not necessary.
Tracelevel.8 and tracelevel.9 values can be used to create customized tracing levels.
The default values are:
To customize the trace masks, add together the following (hex) values:
The runtime.properties file contains the following Host On-Demand tracing properties:
The value is an integer from 0-3. The default is 0.
The value is an integer from 0-3. The default is 0.
The value is an integer from 0-3. The default is 0.
The value is an integer from 0-2. The default is 0.
The value is an integer from 0-3. The default is 0.
The value is an integer from 0-3. The default is 0.
The value is an integer from 0-1. The default is 0.
The value is an integer from 0-1. The default is 0.
The value is an integer from 0-1. The default is 0.
This section describes problems that could occur when users interact with your HATS application, and solutions to those problems.
If a user of your HATS application clicks the browser's Back button rather than using the controls on the Web page, the results will be unpredictable. You can disable the Back button by inserting this script into each template used by your HATS application:
<HEAD>
<HTML>
<SCRIPT Language="Javascript">
function goHist(a)
{
history.go(a);//Go forward one.
}
</SCRIPT>
</HEAD>
<body onLoad="goHist(1);">
The tabbed folder widget is not supported on Netscape 4.x, regardless of platform. If you use tabbed folders in your HATS application, tell your users to use Internet Explorer or Netscape 7.
The text alignment on buttons does not appear as left-justified (right-justified for bidirectional applications) in the following browsers: Internet Explorer 5.0, Netscape 6.2.3, and Netscape 7. Therefore, you see inconsistent spacing around button text in these browsers.
When running a HATS application on AIX using Netscape 4.78, characters may appear incorrectly when you highlight the text in the browser. This is a known issue with the IBM HTTP Server, the internal Web server used by WebSphere. Currently there is no way to work around this problem. However, this does not compromise product functionality.
On Netscape 4.7x browsers running on Unix platforms, the caption on the Button widget does not display the space between words.
If a HATS administrator wants to administer a specific clone by using a session ID obtained from a user and pasting this value in the text input field on selectclone.jsp, he may not be directed to the correct clone if using Netscape 6.2.3. To solve this problem, use Internet Explorer or Netscape 7 to perform clone selection.
While most unprotected entry fields on host screens are empty, some host applications may fill entry fields with underscores (_) or occasionally with periods (.). Although emulator screens have control over whether the cursor is in input or overwrite mode, HTML always places the cursor into insert mode. Because of this, users may occasionally need to manually select overwrite mode. Users of Internet Explorer can use the Insert key to change to overwrite mode. In Netscape, the Insert key does not change the mode, so users can use the Delete key to delete text to be replaced, or highlight the text with the mouse before typing the new text.
If you try to start the Run on Server function to preview a HATS project, and the server does not start, the Netscape browser might be unable to start. The Run on Server uses the browser that you have defined in your WebSphere Studio preferences (not the default browser for your machine). If Netscape is your Studio default browser, follow these steps to enable the server to run:
When you preview a project in WebSphere Studio, using the Run on Server function, your cursor may not appear in the input field for every host screen. To solve this problem, you must click twice (instead of once) in the Web browser running on WebSphere Studio to cause the cursor to appear in the input field.
When previewing a transformed screen, a Microsoft Script Debugger screen may pop up after clicking any buttons, links, or input fields.
Follow these steps to disable the screen:
HATS application input can be corrupted in non-English locales and result in incorrect data being used.
HATS applications rely on input data from Servlet and Java Server Page (JSP) API's to retrieve HTML FORM data from the FORM character set and convert it to Unicode. The Servlet's getParameter() methods must decide on the character set of the FORM. HATS applications create JSPs in all locales using the UTF-8 character set; so UTF-8 is the required character set for processing HATS application data.
The specification for FORM provides a charset value in the content-type attribute, but most browsers do not add the charset value to content-type. Also, in WebSphere Application Server 4.0 (WAS), there is no way for the HATS application to dynamically specify the character set used for each form; however, you can assign a character set mapping used by the entire WAS. A customizable properties file provides a locale-to-character set mapping used by WAS. The file is \\WebSphere\AppServer\properties\encoding.properties.
The encoding.properties file determines which character set is used in reading input data. For example:
en=ISO-8859-1 fr=ISO-8859-1 . . . zh=GB2312 zh_TW=Big5
The default ISO-8859 character set works in most cases; however, input data in non-Latin1, double-byte, and bi-directional locales is frequently corrupted.
To establish UTF-8 as the character set, edit the encoding.properties file.
The default font size for HATS applications is 10-point type. For a Thai session, the default font size is too small; it should be 12-point type. For transformations to display well on a Thai session, you should increase the font size by applying one of the supplied stylesheets or modyfing the stylesheet you are using to display the proper font size.
If you are running a HATS application in the Run on Server function of WebSphere Studio, Thai characters may appear incorrectly in the text input widget. You must edit the encoding.properties file located in WebSphere/AppServer/properties/encoding.properties by changing the "th" locale from windows-874 to UTF-8.
The line currently reads:
tr=ISO-8859-9
th=windows-874
vi=windows-1258
The new line should read:
tr=ISO-8859-9
th=UTF-8
vi=windows-1258
If you experience problems opening a host terminal screen in the KOR environment, change the following lines in the file [wsad folder]\jre\lib\font.properties.ko from:
monospaced.0=\uad74\ub9bc,HANGEUL_CHARSET monospaced.1=Courier New monospaced.2=Lucida Sans Typewriter Regular
to
monospaced.0=\uad74\ub9bc\uccb4c,HANGEUL_CHARSET monospaced.1=Courier New,ANSI_CHARSET monospaced.2=\uad74\ub9bc\uccb4,HANGEUL_CHARSET,NEED_CONVERTED
Finally, restart WebSphere Studio.
HATS applications use standard HTML INPUT fields to render unprotected host fields, but HTML does not provide control over the cursor position within these fields. Host screens usually place the cursor at the beginning of an unprotected field, but some do not. HATS renders the unprotected field by placing the cursor at the beginning of the field instead of at the host-indicated cursor position. You may need to click on the correct location within such fields to place the cursor at the desired location.
If you create a HATS studio transformation, make sure it is in the same subfolder level as the template you are using. Transformations are embedded in templates, and if a transformation is in a different subdirectory level than its template, the links will be invalid at runtime.
The following is an example of an incorrect embedding and will fail at runtime:
/proj/webApplication/transformations/sub/login.jsp in /proj/webApplication/templates/Simple1.jsp
This example demonstrates correct embedding:
/proj/webApplication/transformations/sub/login.jsp in /proj/webApplication/templates/other/Simple1.jsp
If it is not possible to put the transformation and template at the same subdirectory level, change the links in the transformation to be relative to the URL root. Double-click on the transformation in the HATS Project View, then click the Source tab. Change each occurrence of SRC="..common/ to SRC="<%= request.getContextPath()%>/common/.
If you deploy a HATS application to run on WebSphere Application Server on the AIX or Solaris platform, make these configuration changes to the server's Java Virtual Machine (JVM) to avoid a memory problem:
exclude com/ibm/hats/common/HostScreen SetString
Restart WebSphere Application Server.
If the end users of your application are receiving an HTTP 404 - File not found when trying to run an application message, WebSphere Application Server could be configured incorrectly.
If your deployed .ear file contains the .war files for multiple applications, the WebSphere Application Server (WAS) administrator must configure the server with Module Visibility set to Application.
[ Top of Page | Previous Page | Next Page ]