HATS Administration

 

+
Search Tips   |   Advanced Search

 

Overview

After you have published applications to a WAS server, the HATS administration interface can be used to manage connections and perform problem determination.

You can include HATS Administration support files with the set of HATS applications contained within an .ear file deployed to WAS. The deployed .ear file provides a runtime environment, in which the HATS Administration console enables you to manage HATS applications. If you include HATS Administration files in multiple projects, more than one HATS Administration console can be started using different application names; however, each HATS Administration console provides the same views and functions.

Instead of including the HATS Administration support files in each .ear file, you can create an .ear file that contains only HATS Administration. When you deploy this .ear file, you can start HATS Administration and change the management scope to enable you to administer HATS applications from multiple .ear files with one instance of HATS Administration. The deployed HATS Administration project gives you a single point of administration for all HATS applications. When you create a new HATS project, you specify whether to include HATS Administration files in the project. If you create a HATS Administration project, you no longer need to add the administration support files to other projects you create.

To create a HATS Administration project in HATS Studio, follow the path...

File | New | Project | Host Access Transformation Services | HATS Administration Project

You should specify an Enterprise Application project name that uniquely identifies this project as the HATS Administration project. The HATS Administration project only appears in HATS Studio on the Navigator tab. Deploy the .ear file you created to WAS and start it.

If you use the display terminal or any other trace options in HATS Studio, be sure you turn the functions off before assembling your project for deployment to WAS.

 

Security

HATS Administration is bound to WebSphere security. This means that when WAS security is enabled, your system administrators must have proper authentication to perform HATS administrative tasks. The security functions used by HATS in WebSphere are based on the J2EE form-based authentication process. When WAS security is enabled, HATS Administration operations are restricted based on the role defined for a user ID. There are three roles defined for HATS Administration:

HATSAdministrator

This role has full administration capability, able to do all of the following tasks:

• Manage license information
• Select the scope of management
• View active connections, connection pools, connection pool definitions, user lists, and logs
• Terminate active connections
• View log and trace files
• Set log and trace options
• View potentially sensitive data by seeing the display terminal, changing its trace settings, terminate existing connections, and download trace files.

By default, the HATSAdministrator role is mapped to "All Authenticated" users.

HATSOperator

This role is equivalent to the HATSAdministrator role, but cannot access potentially sensitive data. A user with this role cannot enable display terminal tracing, nor download trace files.

HATSMonitor

This role only allows the user to view non-sensitive data, such as active connections, connection pools, user lists, and logs. A user with this role cannot change any settings, such as license management settings, log and trace file options, display terminal settings, nor download trace files.

The mapping of security roles to users or groups of users is performed using the WebSphere administrative console when you install an Enterprise Application. Unless you configure the roles for HATS Administration when you install the .ear file, everyone with a valid user ID and password will have the full capabilities of the HATSAdministrator role, which is the default role for HATS Administration.

HATS Administration can also be started in HATS Studio, using Run on Server. You can also launch the HATS Administration by right-clicking the HATS Project View tab of the HATS Studio, and clicking Open Administration Console. When other applications are running, you can use HATS Administration to terminate connections or open the display terminal and use it for debugging your projects.

Otherwise, those functions will be active when you deploy your application.

 

Start HATS Administration

HATS Administration is Web based. You perform administration tasks using a Web browser, through a user interface provided by the HATS Administration servlet, HATSAdminServlet.

To start HATS Administration, load this URL in your browser...

http://host:port/appname/hatsadmin/admin

...where host is your host name, port is the port number of http transport of the appserver on which the HATS application is running (note: port is not needed if URL requests are directed to a web server configured for WebSphere) and appname is the name of a HATS application that includes administration support.

For example:

http://hostname:10010/hatsadmin/hatsadmin/admin

When you start HATS Administration, it uses the default language of the server. You can, however, change the language by selecting Preferences in the navigation frame, choosing the language you want, and restarting the browser. The new language choice remains in effect for that browser until you select another language in Preferences.

 

HATS Admin Functions

 

Management Scope

HATS Administration maintains a list of the management scopes for the life of the HttpSession. The initial scope of management is selected by default as the HATS enterprise application (.ear) of the HATS application used to access the HATS Administration console. You can change the scope of management to manage other HATS enterprise applications deployed within the same WebSphere cell.

The key to changing management scope is providing the host and port information for HATS Administration to locate installed HATS enterprise applications. The port value specified must be an active WebSphere BOOTSTRAP_ADDRESS port. WebSphere appservers, nodes, and cells each have a BOOTSTRAP_ADDRESS port. Specifying the port value for one of these WebSphere resources enables administration for the HATS enterprise applications deployed to that resource. Specifying a host and port of a WebSphere node enables administration of all HATS enterprise applications installed on that node.

 

Manage licenses

License Management contains the following license panels:

Sets	Specifies how many licenses you have, whether to collect license tracking information, and the template name of the file in which to write tracking information. The default template file name is license.txt.
Usage	Tracks license usage for all appservers in a node. HATS tracks the number of HATS connections to host or database resources and logs a message when the value exceeds the number of licenses purchased.

 

Monitor connections

Connection Management allows you to monitor the following connections:

Host	Connections to 3270, 5250, or VT applications running on a host, such as an iSeries server or other server accessible via Telnet (VT)
Database	Connections to database though the JDBC interface from HATS applications.

Each connection shown in these displays represents a communication link to a back-end data source, such as a 3270 application or a database. The displays enable you to see details about which users are connecting to which data sources, and which connection identifiers they are using. You can also shut down sessions.

 

Monitor connection pools

The Connection Pools panel under the Connection Management heading in the left navigation frame displays information about defined connection pools. A connection pool is not listed until at least one connection is allocated from the pool.

Connection pools are collections of communication links to back-end data sources, such as 3270 applications or databases. When an Integration Object or an application is run on behalf of a client request, it obtains an available connection from a pool, uses it for access to the data source, then returns the connection to the pool. When connection pooling is enabled, the overhead of establishing a connection is absorbed in its first use. Each reuse of this connection benefits from the prior establishment of the connection and can run faster.

 

Monitor pool definitions

The Connection Pool Definitions panel under the Connection Management heading in the left navigation frame displays pool definition information for host and database connections. A pool definition is not listed until at least one connection is allocated from the defined pool.

A pool definition provides information about a collection of data source connections. Some related definitions are associated with a pool definition; for example, connection and macro definitions and user list name. In addition to creating associations between several other definitions, the pool definition provides configuration parameters for all connections in the pool, such as minimum and maximum pool size (in terms of number of active connections) and connection timers.

 

Monitor user lists and user list members

The User Lists panel under the User Management heading in the left navigation frame displays information about user lists.

User lists identify the user IDs and other connection-specific parameters associated with a particular connection pool definition. For systems that allow only a single connection per user ID, the number of user IDs determines the number of connections that can be active in a single pool.

 

Administer problem determination components

HATS Administration enables you to monitor logging and tracing to help you resolve problems. You can view the messages in the log, and change log and trace settings by selecting the links under the Troubleshooting heading in the left navigation frame. A runtime.properties file maintains settings for these problem determination aids.

Log and trace file names

The base log and trace file names in runtime.properties are used as templates to generate unique sets of log and trace files for each appserver. The default base trace file name is trace.txt; the default base log file name is messages.txt. The appserver name is appended to the base file name to generate the template for the log and trace files for an appserver. The appserver name is the same as the fully-qualified name of the appserver, as defined by WebSphere. This name is cell_node_server, where:

• cell is the name of the WebSphere cell.

• node is the name of the WebSphere node.

• server is the name of the WebSphere server.

The appserver running HATS is the concatenation of the underscore (_) character, followed by the appserver name, followed by another underscore (_) character.

Use the trace file as an example, the name becomes trace _cell_node_server_.txt. Finally, an index (1, 2, 3, and so forth) is added to this name to distinguish multiple files. With multiple trace files configured, the trace file names for this appserver are trace_cell_node_server_1.txt, trace_cell_node_server_2.txt, and so forth.

When running on WAS for z/OS, an appserver can have more than one Servant running, with each Servant generating unique log and trace files. To distinguish these, the server component of the name is prefixed with the Address Space ID (asid) of the Servant (example: trace_cell_node_server<asid>_1.txt).

View Log

Use the View Log panel, you can view the HATS log file, download the entire file, or clear the file. The log file records information about two kinds of events:

Error events

Problems that prevent an operation from completing. Error events usually require that you take some action to correct the problem.

Warning events

Unexpected occurrences that might require action to correct the problem. Warning events are not as serious as error events.

The log file is intended for you to read and use as a reference when troubleshooting problems. Most of the messages that appear in the log are documented in the IBM WebSphere Host Access Transformation Services Troubleshooting. That publication contains suggestions for actions you can take to correct problems, when necessary.

In Windows, you cannot rename or delete the standard output and standard error logs while HATS applications are running. If you want to rename or delete these logs as part of troubleshooting procedures, to reclaim disk space, or to minimize the size of an information bundle file, stop the appserver representing HATS. However, the WebSphere node can remain running.

Set Log Options

Use the Log Settings panel, you can control whether information and warning events are written to the log file, and define the file to which the log events are written. See Log and trace file names for information about how log files are named. If the file already exists, new events are appended to it. Error events are always written to the log file. You can also define how many log files to keep and the maximum size of each log file.

Set Trace Options

Use the Trace Settings panel, you can choose to set one or more of the following types of trace options:

Server Tracing

Enables tracing in HATS runtime for connections, event actions, components, widgets, and runtime utilities. You can specify whether to perform these traces individually or as a group of server traces. HATS Administration sets each of these settings to the maximum trace level. To trace these runtime components at a different level.

Integration Object Tracing

Enables tracing in specific Integration Objects in your project. Use the Class Name specification field to specify which Integration Objects to trace, using one or more patterns. Each pattern can contain one or more wildcard (*) character. For example, IntegrationObject.Callup* specifies that tracing is enabled for all Integration Objects that start with the letters Callup. To trace all Integration Objects, specify IntegrationObject.*. If multiple patterns are specified, they should be delimited with commas. HATS Administration sets the Integration Object setting to the maximum trace level. To trace Integration Objects at a different level, see The runtime.properties file for information about the tracelevel.* settings.

User Macro Tracing

Traces the playing of macros. Because it affects system performance, we recommend that you use this trace only for debugging macros.

Display Terminal

Enables you to view the host terminal screen (green screen) of any connection as it runs in real time on the server. After you enable the display terminal, the terminal settings are shown only for newly created connections. For more information about the Display Terminal, see Use Display Terminal for testing and debugging.

IBM Service Tracing Options

HATS Administration also includes a Display Service Tracing Options check box with which you can turn on traces (if instructed to do so by IBM service). We recommend that you not use these traces unless you are asked to do so by IBM service.

Trace Output

Enables you to control whether trace information is written to the trace file, and define the file to which the log events are written. See Log and trace file names for information about how trace files are named. If the file already exists, new trace information is appended to it. You can also define how many trace files to keep and the maximum size of each trace file.

 

The runtime.properties file

The file...

was_dir/installedApps/ear_name/runtime.properties

...saves the settings of the HATS administrative and runtime options. Changes made in the HATS Administration console are written to this file. You can also edit the runtime.properties file directly to change settings.

When running on WAS for z/OS, the runtime.properties file on x/OS must be edited with an ASCII editor, which can be done by transferring the file to a workstation, editing the file and transferring it back. There is a copy for every active Servant within an appserver (Address Space ID of the Servant). The base runtime.properties file should be changed for changes to persist across appserver restarts.

The runtime.properties file contains the following properties:

num_licenses

Specifies the number of licenses you purchased. HATS tracks the number of HATS connections to host resources and logs a message when the value exceeds the number of licenses purchased.

The value is an integer. There is no default.

licenseTracking

Specifies whether HATS tracks license usage or not. The value is binary. The default is 0.

0

HATS does not track license usage.

1

HATS tracks license usage for all appservers in a node. HATS tracks the number of HATS connections to host or database resources and logs a message when the value exceeds the number of licenses purchased. The license usage information is written to a file named licensex.txt in the log directory of the HATS installation directory on the server, where the x is either 1 or 2.

The maximum size of the license usage files is 512 KB. When the file size of the license1.txt file reaches 512 KB or if the HATS Server is restarted, 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 ( ).

1. Date

2. Time

3. The highest license count since the server was started

4. The highest license count in the last hour (the maximum of the last 60 entries)

5. The license count for each minute (1-60)

licenseFile

The name used as a template to generate names for the license files for license usage information. The default value for this property is license.txt.

adminPortNum

The adminPortNum is the default value used by the HATS Administration console when the management scope is to be changed. The port value must be an active WebSphere BOOTSTRAP_ADDRESS port. The default is 2809, which is the default BOOTSTRAP_ADDRESS port of server1 for a WebSphere base installation, or of the nodeagent server when you federate an appserver node into a deployment manager cell.

logFile

The name used as a template to generate names for each set of application server files to which log messages are written. The default base name for a log file is messages.txt.

maxLogFiles

The maximum number of message files. The default is 2.

The base log file name in runtime.properties is used as a template to generate unique sets of message log files for each appserver. The default base name for a log file can be changed in runtime.properties. The appserver running HATS is the concatenation of: the underscore (_) character, followed by the name of the HATS Server instance, followed by another underscore (_) character.

The HATS Server instance ID (for example _SSS_) is then appended to the base file name to generate the template for the log files for an appserver. For the log file, this becomes messages _SSS_.txt. Finally, an index (1, 2, 3, and so forth) is added to this name to distinguish multiple files. So, for example, if the HATS Server instance ID is cell_node_server, the log file for the appserver is named messages_cell_node_server_.txt. With multiple log files configured, the log file names for this application server are messages_cell_node_server_1.txt, messages_cell_node_server_2.txt, and so forth.

When messages_cell_node_server_1.txt reaches maxLogFileSize, it is closed and renamed to messages_cell_node_server_2.txt. A new messages_cell_node_server_1.txt is opened.

When messages_cell_node_server_1.txt reaches maxLogFileSize again, previous log files are renamed--for example, messages_cell_node_server_2.txt is renamed to messages_cell_node_server_3.txt. Then messages_cell_node_server_1.txt is renamed to messages_cell_node_server_2.txt, and a new messages_cell_node_server_1.txt file is opened.

When the maxLogFiles number is exceeded, the oldest file is deleted.

When running on WAS for z/OS, the server portion of the log file name also includes the Address Space ID of the Servant which is writing to the log (example: messages_cell_node_server<asid>_1.txt). See Log and trace file names for details.

maxLogFileSize

Specifies the maximum size, in kilobytes, that a message log file reaches before an additional log file is opened.

The value is an integer. The default is 512 KB.

traceFile

The name used as a template to generate file names to which HATS trace messages are written. The default base name for a trace file is trace.txt.

maxTraceFiles

The maximum number of trace information files. The default is 5.

The base trace file name in server.properties is used as a template to generate unique sets of trace files for each appserver. The default base name for a trace file can be changed in runtime.properties. The appserver running HATS is the concatenation of: the underscore (_) character, followed by the name of the HATS Server instance, followed by another underscore (_) character.

The HATS Server instance ID (for example _SSS_) is then appended to the base file name to generate the template for the trace files for an appserver, which becomes trace _SSS_.txt. Finally, an index (1, 2, 3, and so forth) is added to this name to distinguish multiple trace files. So, for example, if the HATS Server instance ID is cell_node_server, the trace file for the appserver is named trace_cell_node_server_.txt. With multiple trace files configured, the trace file names for this appserver are trace_cell_node_server_1.txt, trace_cell_node_server_2.txt, and so forth.

When trace_cell_node_server_1.txt reaches maxTraceFileSize, it is closed and renamed to trace_cell_node_server_2.txt. A new trace_cell_node_server_1.txt is opened.

When trace_cell_node_server_1.txt reaches maxTraceFileSize again, previous trace files are renamed--for example, trace_cell_node_server_2.txt is renamed to trace_cell_node_server_3.txt. Then trace_cell_node_server_1.txt is renamed to trace_cell_node_server_2.txt, and a new trace_cell_node_server_1.txt file is opened.

When the maxTraceFiles number is exceeded, the oldest file is deleted.

When running on WAS for z/OS, the server portion of the trace file name also includes the Address Space ID of the Servant which is writing to the log (example: trace_cell_node_server<asid>_1.txt). See Log and trace file names for details.

maxTraceFileSize

Specifies the maximum size, in kilobytes, that a trace file reaches before an additional trace file is opened.

The value is an integer. The default is 1024 KB.

ioPatternKey

One or more patterns specifying the Integration Objects to be traced. See the description of trace.INTEGRATIONOBJECT below.

Each pattern can contain one or more wildcard (*) character. For example, IntegrationObject.Callup* specifies that tracing is enabled for all Integration Objects that start with the letters Callup. To trace all Integration Objects, specify IntegrationObject.*

If multiple patterns are specified, they should be delimited with commas.

trace.RUNTIME

Specifies the level of tracing for the main runtime and for all settings under RUNTIME.* that do not specify a trace level.

The value is an integer from 0-9. The default is 0, which means that no runtime tracing is performed.

See the description of the tracelevel.* keys for information on values for this setting.

trace.RUNTIME.ACTION

Specifies the level of tracing for the event actions. This setting overrides the trace.RUNTIME setting.

The value is an integer from 0-9. The default is 0, which means that no event action tracing is performed.

See the description of the tracelevel.* keys for information on values for this setting.

trace.RUNTIME.COMPONENT

Specifies the level of tracing for HATS components. This setting overrides the trace.RUNTIME setting.

The value is an integer from 0-9. The default is 0, which means that no component tracing is performed.

See the description of the tracelevel.* keys for information on values for this setting.

trace.RUNTIME.WIDGET

Specifies the level of tracing for HATS widgets. This setting overrides the trace.RUNTIME setting.

The value is an integer from 0-9. The default is 0, which means that no widget tracing is performed.

See the description of the tracelevel.* keys for information on values for this setting.

trace.INTEGRATIONOBJECT

Specifies the level of tracing for Integration Objects. You can specify a value of 0-9. The default is 0, which means that no Integration Object tracing is performed.

The value is an integer from 0-9. The default is 0, which means that no runtime utility tracing is performed.

See the description of the tracelevel.* keys for information on values for this setting.

trace.UTIL

Specifies the level of tracing for HATS runtime utilities.

The value is an integer from 0-9. The default is 0, which means that no runtime utility tracing is performed.

See the description of the tracelevel.* keys for information on values for this setting.

tracelevel.x

Each of the tracelevel keys specifies as its value a hexadecimal digit string. This string is a mask which is applied to the tracing feature for components which use that trace level. Each bit of the digit string controls one type of tracing for HATS.

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:

tracelevel.1

0000000000020000

tracelevel.2

000000000000020f

tracelevel.3

000000000004023f (minimum)

tracelevel.4

0000000000041a3f

tracelevel.5

00000000000c1bbf (normal)

tracelevel.6

00000000000c1bbf

tracelevel.7

00000000001c1bbf (maximum)

tracelevel.8

00000000001c1bbf

tracelevel.9

00000000001c1bbf

To customize the trace masks, add together the following (hex) values:

x000001

Informational messages

x000002

Warning messages

x000004

Error messages

x000008

Critical error messages

x000010

API traces

x000020

Callback API traces

x000080

Method entry

x000100

Method exit

x000200

Exceptions

x000400

Miscellaneous traces

x000800

Object creation

x001000

Object disposal

x020000

Reserved

x040000

Miscellaneous data - level 1

x080000

Miscellaneous data - level 2

x100000

Miscellaneous data - level 3

trace.HOD.DISPLAYTERMINAL

Specifies whether Host On-Demand displays a terminal window for each connection.

0

Host On-Demand does not display a terminal window for each connection.

1

Host On-Demand displays a terminal window for each connection.

The value is binary. The default is 0.

If trace.HOD.DISPLAYTERMINAL is 1, when HATS creates a host connection (for example, in response to a request from an application), it automatically creates a host terminal display. If this property is set to 0, this does not occur; however, whether or not the host terminal display is created automatically during host connection creation, a HATS administrator can use HATS Administration to turn host terminal displays on or off for individual host connections.

trace.HOD.PS

Specifies the level of tracing for the Host On-Demand presentation space.

The value is an integer in the range 0 to 3, where:

0

No tracing is performed.

1

Minimum level of tracing is performed.

2

Normal tracing is performed.

3

Maximum level of tracing is performed.

The default is 0.

trace.HOD.SESSION

Specifies the level of tracing for Host On-Demand sessions.

The value is an integer in the range 0 to 3, where

0

No tracing is performed.

1

Minimum level of tracing is performed.

2

Normal tracing is performed.

3

Maximum level of tracing is performed.

The default is 0.

trace.HOD.TRANSPORT

Specifies the level of tracing for the Host On-Demand transport.

The value is an integer in the range 0 to 3, where

0

No tracing is performed.

1

Minimum level of tracing is performed.

2

Normal tracing is performed.

3

Maximum level of tracing is performed.

The default is 0.

trace.HOD.MACRO

Specifies the level of tracing for Host On-Demand macros.

The value is an integer in the range 0 to 2, where

0

Host On-Demand macro tracing is not enabled.

1

Host On-Demand event tracing is enabled.

2

Host On-Demand support tracing is enabled.

The default is 0.

trace.HOD.USERMACRO

Specifies the level of tracing for trace actions in Host On-Demand user macros.

The value is an integer in the range 0 to 3, where

0

No tracing is performed.

1

Minimum level of tracing is performed.

2

Normal tracing is performed.

3

Maximum level of tracing is performed.

The default is 0.

trace.HOD.DS

Specifies the level of tracing for the Host On-Demand data stream tracing.

The value is an integer in the range 0 to 3, where

0

No tracing is performed.

1

Minimum level of tracing is performed.

2

Normal tracing is performed.

3

Maximum level of tracing is performed.

The default is 0.

trace.HOD.PSEVENT

Specifies the level of tracing for the Host On-Demand PS events.

0

Host On-Demand PS event tracing is not enabled.

1

Host On-Demand PS event tracing is enabled.

The value is binary. The default is 0.

trace.HOD.OIAEVENT

Specifies the level of tracing for the Host On-Demand OIA events.

0

Host On-Demand OIA event tracing is not enabled.

1

Host On-Demand OIA event tracing is enabled.

The value is binary. The default is 0.

trace.HOD.COMMEVENT

Specifies the level of tracing for the Host On-Demand COMM events.

0

Host On-Demand COMM event tracing is not enabled.

1

Host On-Demand COMM event tracing is enabled.

The value is binary. The default is 0.

 

Display Terminal functions

When debugging applications on a test system, you can control whether terminal screens are created on the Server display. Display screens are created only for connections established while this option is turned on. They are not created for existing connections or for connections that are idle. However, the Host Connections panel in HATS Administration console includes a Toggle Display Status button that turns Display Terminal on and off for selected connections.

Turning on the Display Terminal option can seriously affect performance or overload the server. Do not use this on servers with many connections. Display Terminal is intended for use in debugging during application development on a test system; it is not intended for use on a heavily loaded production server.

You can turn Display Terminal on for any new host connections by selecting the Enable Display Terminal box on the Trace Settings panel under the Troubleshooting heading in the left navigation frame; however, you can use Toggle Display Terminal on the Host Connections panel to turn Display Terminal on and off at any time, regardless of whether you have selected the Enable Display Terminal box on the Trace Settings panel.

Notes:

1. To use Display Terminal on OS/400, Remote Abstract Windowing Toolkit (RAWT) must be enabled.

2. If you are using WAS on Windows 2000, enable the WebSphere Administration Server service to interact with the desktop.

 

Configure the Display Terminal function for iSeries

To display and use the Display Terminal check box, some additional configuration is required on the iSeries WAS and on your choice of a secondary network system that is capable of supporting Java Abstract Windowing Toolkit (AWT) JDK classes. This configuration is necessary because the iSeries server does not support graphical display devices as direct connect devices; it does support them as client and server roles. Java has a graphical solution for this called Remote AWT. In this case, another remote system such as Windows, acting as an AWT server, handles the graphical display of the terminal screen and interaction of Java code running in the primary environment. The following explains how to set up Remote AWT:

1. Verify that the iSeries system and the remote system are running the same level of Java.

2. Configure your remote system to run the Java JDK Remote AWT server/listener. The Remote AWT daemon needs to be running on the remote system. Copy the files required to start the Remote AWT daemon from the iSeries system.

   • Create a directory on the remote system for the RAWT daemon code.

   • Copy the RAWTGui.jar and RAWTAHost.jar files from the iSeries system. The files are located at /qibm/proddata/java400/jdk13.

   • Start the RAWT daemon on the remote system. Issue the following command:

     java -jar path to RAWT files/RAWTGui.jar

   A small application window appears in the upper right hand corner of the remote system. It must be running to handle the traffic from the iSeries system.

3. To enable the Display Terminal check box, a directory and a file need to be created on the iSeries system. Issue the following commands:

   mkdir '/home/qejbsvr'
   edtf '/home/qejbsvr/SystemDefault.properties'

4. Determine the fully qualified network address of the remote system.

5. Configure your iSeries WAS to send all AWT requests and functions to the remote server/listener.

   os400.class.path.rawt=1
   RmtAwtServer=network address of remote system

6. When setup and configuration is complete, use OS/400 commands to stop and start WAS by issuing the following commands:

   endsbs sbs(qejbas5) option(*cntrld)
   strsbs sbsd(qejbas5/qejbas5)

7. Start HATS Administration.

8. Select the Enable Display Terminal check box in HATS Administration located under Troubleshooting > Trace Settings, and submit the change.

9. Stop and restart the iSeries WAS to enable Display Terminal support. Whenever the Enable Display Terminal check box is changed, restart the server to ensure that the new setting is read.

Disabling Remote AWT

When you have finished using the Display Terminal, disable it to avoid performance degradation.

Do not disable Remote AWT without first clearing the Display Terminal check box and submitting changes in HATS Administration. If you do not follow this sequence, no Java Remote AWT support is not available for HATS Administration to detect, and the Display Terminal is no longer available. The correct sequence is to clear the Display Terminal check box and submit changes, then disable Remote AWT support in WAS.

You can disable RAWT on the iSeries system using either of the following two procedures:

1. From the iSeries console:

   1. Issue the following command:

      wrklnk '/home/qejbsvr/SystemDefault.properties'

   2. Enter a 4 next to the name of the file (option 4 removes the file).

   3. Stop and restart WAS, using the following commands:

      endsbs sbs(qejbas5) option(*cntrld)
      strsbs sbsd(qejbas5/qejbas5)

2. In the Qshell environment:

   1. Rename the qejbsvr directory.

   2. Issue the following command:

      mv /home/qejbsvr/home/qejbsvr.bak

   3. Stop and restart WAS, using the following commands:

      endsbs sbs(qejbas5) option(*cntrld)
      strsbs sbsd(qejbas5/qejbas5)

 

Configure the Display Terminal function for zSeries(R)

With Java 1.3.1 installed on your zSeries system, you can display and use the Display Terminal check box. However, some additional configuration is required on the zSeries WAS and on your choice of a secondary network system (such as an AIX system). This configuration is necessary because the zSeries server does not support graphical display devices as direct connect devices. On a zSeries system, you can export the Display Terminal and graphics to an Xserver running on the remote system. The Xserver handles the graphical display of the terminal screen exported from the primary environment. The graphical display is also needed to view components and widgets in HATS Studio, such as visual tables and graphs.

To export the graphics to an Xserver, open the WebSphere administration console and select Manage WebSphere Variables. Add a new variable DISPLAY and supply the address of the Xserver.

On the Xserver, grant permission to the host to export the graphics (such as xhost +mvs03).

 

Home