The ScreenSurfer Service which provides both the ScreenSurfer Web Gateway and ScreenSurfer Administrator's Port consists of a single executable which is installed as a Windows/NT Service. Following installation, you start the service using the ScreenSurfer Service Control Panel or the Control Panel Services Dialog. The ScreenSurfer service must be started prior to accessing any of its functionality.
To have the service start every time that NT is booted, change its properties in the Services dialog to Automatic startup if you didn't select this option during installation.
When the ScreenSurfer service is started as a service all informational, warning and error messages are logged to the Windows/NT Event Log. To view any messages, from the Start button, choose Programs/Administrative Tools/Event Viewer. ScreenSurfer is an "Application", which is one of three categories selectable from the Event Viewer menu bar.
Should you desire to execute the ScreenSurfer service from a command line in order to view messages as they occur, or for diagnostic purposes, you can do so from the ScreenSurfer\BIN directory. The program name is IELUA.EXE, and to execute from the command line you should use the IELUA START command.
Accessing The ScreenSurfer Console Port from a Web Browser
To access the console port, the easiest way is on the machine that ScreenSurfer is installed on: from the Start Button, select /ScreenSurfer/ScreenSurfer Console. This will display an HTML page with a link customized by the ScreenSurfer installation program based on the Console port you specified during installation.
Version 3.0 provides the ability to access the Console and DevCenter through an SSL Filter. Once you have downloaded the surfprox executable file, found at ScreenSurfer, you can access the web server with the special resource of "/ss_adm/" which will route the request to the Console Port, in a fully secure SSL environment.
If you want to access the Console Port from
any browser at any time, the Console port number will be part of the URL
when using the browser. For example, on the same machine as ScreenSurfer,
assuming a Console Installation port of 81, the URL will be: http://localhost:81
or http://127.0.0.1:81 if DNS is not
active on your machine To access the Console Port from a different
machine, simply include the machine name:Port of the machine ScreenSurfer
is installed on, such as http://surferboy:83 As previously mentioned, when started from the
Services Dialog, ScreenSurfer will log error messages to the Event Viewer.
These messages can be viewed from the Programs/Administrative Tools/EventViewer.
Choose Log/Applications and all messages will be logged with the Source
of "ScreenSurfer".
Possible
ScreenSurfer Startup errors
When initially starting ScreenSurfer, you may see the following:
Starting ScreenSurfer V1.0
Error: During Primary Socket Bind, return code=2740
Description=WSAEADDRINUSE: The specified address is already in use. (See the SO_REUSEADDR socket option under setsockopt.)
Suggestion: Please specify a different port using the Console Settings Page
This type of error occurs if you have a conflict with an already existing port in use from another HTTP server.
Warning: Validating Console User (The Console is currently unprotected you should enter valid IP addresses in registry!)
This is because you currently have no security for remote users to access the ScreenSurfer Console Port on your system. The registry entry, Valid Console Ports, has the wildcard *, specified for anyone to access it. You can instead enter specific IP addresses separated by commas, to restrict remote access, or specify Password-based security by adding Console Users from the Settings page.
Note: Information on where to find the Valid Console Ports registry entry is documented in step 6 of the next section: Getting Started with ScreenSurfer .
If any error should occur that refers to WINRUI32.DLL when using ScreenSurfer, then try the following:
1. Make sure you have WINRUI32.DLL. This file should be located in your SNA\SYSTEM directory.
2. If you have this file, make sure SNA\SYSTEM is in your PATH.
3. If you have two copies
of WINRUI32.DLL (from another terminal emulation product such as
Wall Datas Rumba), make sure SNA\SYSTEM appears
first.
4. Now, you may have to reboot for these changes to take effect.
This section describes how to start the ScreenSurfer.
1. If using SNA Server, make sure the Service in SNA Server is started. (TN3270 users: skip this step)
For SNA Server V2.11:
For SNA Server V3:
2. Start the ScreenSurfer Service
Make sure the ScreenSurfer Service is started either as a service or from the Command Prompt.
Starting from the ScreenSurfer Service Control Panel
Setting Security from the Windows/NT Control Panel Services Dialog
Depending on the configuration of you NT system, you may need to set security for the ScreenSurfer Service to do this:
Starting ScreenSurfer From the Command Prompt:
At times, you may need to view informational, warning and error events as they occur instead of through the Administrative Event Viewer. In this case, you can start ScreenSurfer from a command prompt as follows:
3. Start an Internet browser of your choice and use
http://localhost:<port > as the URL
where <port> is the port number specified during installation.
Note: if DNS is not active on your machine, use http://127.0.0.1<port> as the URL.
4. You should see the ScreenSurfer Console Home Page
5. Choose Change ScreenSurfer Service Settings or Click on the Settings button
Modify the LU name fields to contains valid values unless the values entered during installation were correct
Generally, these fields should contain LU Pool names for SNA RUI or *TN3270:<hostname> for TN3270. Any connections configured during installation should be visible in this page.
Refer to ScreenSurfer Console features accessible from a Web browser for more information.
6. Choose Submit to make the changes to update the Registry entries under:
HKEY_LOCAL_MACHINE
SOFTWARE
iE
ScreenSurfer
Config
If the Registry entries do not appear to change
as expected, then check the security.
In the Registry Editor, highlight Config and select
Security/Permissions
Then, change Type of Access to Full Control.
7. Select the ScreenSurfer Service Control Panel from the Task Bar and Stop, then Start the ScreenSurfer service in order to make any configuration changes active.
8. Now, you are ready to use the ScreenSurfer!
As users access the Web Gateway port, you can view their sessions using the Active button, or the Picture button from the Console Home Page
9. Once a session is started
Use Details to look at the Active Session Screen either by selecting the Picture button and then clicking on an active session, or from the List all Active Sessions/Active or List all Defined Sessions/Defined.
To terminate the ScreenSurfer service do the following:
(If ScreenSurfer was started as a console application from the Command Prompt using the IELUA command, use the mouse to put focus on the command window displaying the ScreenSurfer process and hit Ctrl-C or Ctrl-Break to stop IELUA.EXE)
Go back into SNA Server Admin/Manager. Highlight the Server you want to stop. Then, use the menu item Service/Stop Service (or just Service/Stop for SNA Server V3) to close the connection to all LUs for this Server.
When bringing up the ScreenSurfer Console Home Page, you should see a column of buttons down the left side of the page along with some status information at the top of the right side and some additional links.
For example:
50 Sessions defined, 23 Sessions Active
Service Status: Active
Where the number 50 is the Total Sessions allowed based on your licensing level, and 23 is the number of sessions with a Session Status of Active.
Service Status: which will be either Normal, Shutting Down, or Shut Down.
The buttons on the left equate to some of the text on the right as noted below by a /. For example, choosing Defined produces the same results as choosing List all Defined Sessions
This shows a single-page view of all existing sessions based on session number. If you click on the session number, it will give you detailed status information, and the current screen if the session is Active.
If a session is Active, then it will appear
green or blue in the Picture. Red indicates an error.
If you have more than 100 sessions: Picture Summary Page
If you have more than 100 sessions licensed, you will first see a summary page listing sessions in groups of 100. The colors of each summary line is escalated to the most "critical" status. Thus, if any sessions in a given range have an LU Error, the color will be red, whereas in another group the session will be blue if there are any active user connections but no LU Errors.
You may also display a picture of specific session ranges directly using the "picture" command. For example, to display a picture of sessions 100 through 150 on a ScreenSurfer machine named "portal":
http://portal:81/picture/100..150
This lists the current active ScreenSurfer sessions. Sessions become active following a user clicking on a /surfer/connect link pointing at the ScreenSurfer Web Gateway port. They may also be sessions that have had the Start command performed on them when used in a pool of sessions used to service specific ScreenSurfer transactions.
You may also list specific active sessions directly using the "list" command. For example, to list sessions 1 through 20 on a machine named "portal":
http://portal:81/list/1..20/activeonly
This lists all defined sessions and status information in a ScreenSurfer Defined Session status screen.
From Commands, you can Start or Stop a session. Starting a session makes it connected to a LU and available to be used in a transaction pool. You can use Details to view the Active Session Screen.
To list specific sessions use the "list" command. For example, to list all defined sessions from 50 through 100:
http://portal:81/list/50..100
This feature allows settings to be defined for your environment which
include the LU, LU Pool and TN3270 information. The following properties
and settings are available on this screen:
New for Version 3.0 is the Full Configuration and Tuning button. This allows the user or developer to make changes directly to the Registry, rather than having to open the Registry itself as in previous versions. A complete description is associated with each entry as well as the ability to view the registry settings in full after making any changes.
This is the total number of sessions available for use. It is
governed by your licensing level, and controlled by the access key you
were given when receiving the product.
Number of sessions to restart after a Shutdown has occurred -- Note that the Sessions to AutoStart cannot be greater than the Total Sessions.
This release of the ScreenSurfer Web Gateway includes up to 10 different connection groups which may be defined. This is an arbitrary number which is expected to become fully user-defined in a future release (greater than 10 groups).
For many installations, a single group will
provide all the definition needed, where a single TN3270 port or single
SNA Server LU Pool will provide access for a full application area.
Group LU Name:
The LU Name represents one of three supported
connection types. For each type, the format of the LU name string
is given.
SNA Server Logical Units or LU Pool Names
The syntax for an SNA Server LU or LU Pool name is simply the LU or Pool Name as defined in SNA Server. Thus, for an LU Pool named "IELUPOOL", the Group LU name will be "IELUPOOL".
TN3270 Target Host Names
For TN3270, you preceed the TN3270 host IP address
with the special string "*TN3270:". Thus, for the
host "ORBIS.YALE.EDU" you would enter "*TN3270:ORBIS.YALE.EDU".
Note: Either DNS or numeric IP addresses may be used.
For example, "*TN3270:192.168.12.2"
is a valid entry as is "*TN3270:www.screensurfer.com".
SNA Server Trace Files (Offline Test and error resolution)
For SNA Server trace files (created using trace options described in
the section "Using SNA Server Trace")--you preceed the full path
to the trace file name with "*TRACE:" and then add the
LU Name that is active in the trace file after a dash. For example,
a trace file named "CLIMSG1.TRC" that contains an "LU ACTIVATE"
line activating "DEMOLU1" would be specified as "*TRACE:C:\sna\traces\climsg1-DEMOLU1".
Note: do not include the .trc extension when defining trace file
group entries.
Group Session Range
The session range determines which of your available sessions will be allocated to the group being defined. This is entered as a range, with two dots providing a seperator. For example, if the first group is to be allocated sessions 1 through 10 (inclusive) you would enter "1..10" as the group session range.
The Range cannot exceed the Total Sessions.
For example, you cannot use 1..300 if your Total Sessions is defined as
128.
Enter the period of time (in minutes) that the ScreenSurfer should use in order to consider a user "timed-out". Note that the timeout of users in the ScreenSurfer is "passive" in that a user will lose a connection only when a new user has made a "CONNECT" request and all defined sessions are already connected.
The first session found that has been inactive equal to this amount (in minutes) will be "bounced" and the current connection request will take ownership of the session.
If you wish to activate address-based session security, change this value to "yes". By default, this is installed with a value of "no".
Strict session address security ensures that a user, once connected to a session, can only access that session from the same workstation. This option is compatible with dynamically assigned addresses (DHCP), but is NOT compatible with access through a proxy that uses a "pool" of addresses and where each socket open and close through the proxy can end-up using a different IP address.
Generally, you would not set this value to "yes" for any "Internet" style application, since many large organizations use the kind of proxy server that would give a user problems with a "yes" value.
TCP/IP Port Number for the ScreenSurfer console web server port. By changing this value, you will change which TCP/IP port ScreenSurfer "listens" on for Console HTTP requests. For example, by changing from the default install value of "81" to "83", your URL for accessing the console on a machine named "myserver.yoohoo.drink" would be "http://myserver.yoohoo.drink:83".
The initial setting for the Console Port number is specified during installation.
Selecting this button displays a simple dialog which enables you control Console access by hard-coded console machine IP addresses or by UserID/Password security.
For more information, see ScreenSurfer Console User Security
TCP/IP Port Number for the ScreenSurfer Web Gateway port. By changing this value, you will change which TCP/IP port ScreenSurfer "listens" with for Terminal Emulation HTTP requests. For example, by changing from the default install value of "84" to "80", your URL for accessing the Terminal Emulation on a machine named "myserver.yoohoo.drink" would be "http://myserver.yoohoo.drink" (note that port 80 is the default for HTTP requests, so no ":80" need be appended to your URL).
Name of file to log ScreenSurfer connection information to. The name you provide will provide the base for individual log file names. Since multiple sessions may be logged concurrently, the session ID is appended as an additional extension to the name specified here.
For example, if you enter d:\surfer.log and two users connect on sessions 1 and 2, you should see the following two files in the d:\ root directory:
D:\surfer.log.1
D:\surfer.log.2
Enter the session number you would like to perform logging on. There are two special entries you can use to log all sessions or no sessions:
Log No Sessions: Use the number 0
Log All Sessions: Use the Asterisk (*)
When you check this, on submission of the settings page, the logfile
defined in LogFile Name will be cleared to empty, so that a new
log file can be started.
Note that activating HTTP logging should impact throughput on a busy server by approximately 4-8%, based on testing performed in our labs.
The name you enter should include the full path as well as the starting portion of the name. For example, d:\screensurfer\logs\ht will yield file names looking something like: d:\screensurfer\logs\ht19981028.log. By entering a name, you will activate logging, with the first file name using the current date.
ScreenSurfer caches HTTP log records; to flush the cache, view the console settings page and click on the "submit" button (no changes need be performed).
The log file name can be changed by ScreenSurfer at a frequency you select in the following selection (see following section).
ScreenSurfer log files are formatted in comma separated records (IIS 4 format), with the following data in each row:
Client Address | IP Address of the HTTP client |
Session User | This is also the IP address of the HTTP client, but is initialized when the user first connects to a host session; you can update and read this using the Screen.ActiveUser variable. |
Timestamp | Date and time of the HTTP hit |
Service | Always W3SVC for compatibility with log analysers expecting IIS4 format |
Server Name | The local network name of your server |
Server Address | The TCP/IP DNS name of your server |
Hit duration | How long the hit lasted, in milliseconds |
Bytes IN | Total size of the HTTP request |
Bytes OUT | Total size of the HTTP response |
HTTP RC | The HTTP return/status code |
System RC | Any NT system error code |
HTTP Request | The HTTP command, such as GET or POST |
URL | The URL presented |
Agent | Browser identification |
Referrer | The previous URL visited; user chose a link off this to come to this page. |
Statistics | ScreenSurfer specific: maximum host response time, current response time and a reserved value currently always 0 |
Task ID | The HTTP thread ID that handled the request |
Note that if you select the "Keep" frequency, the log file is never changed, and will continue to grow as a single file. This is generally not recommended, particularly for busy systems, as the log file can grow to be many megabytes quickly.
When you check this, ScreenSurfer enables internal exception handling for all internal "traps" that may occur while executing template code. This can provide the most robust operating environment for a live server, as it will prevent a single user's thread from "taking down" all other ScreenSurfer sessions.
While this setting provides the most robust operational environment, you should keep it "unchecked" during development and testing, as any diagnostic information that can be generated by such utilities as Dr. Watson will not be available as long as this option is checked. Since the goal is to produce as high a mean time to failure for all users, it is best to collect as much information as possible in a non-production environment, to assist ScreenSurfer support in resolving any exceptions that may occur.
Console Settings Submit Button
Once the SUBMIT button is chosen, any changes will be updated in the registry entries under:
HKEY_LOCAL_MACHINE
SOFTWARE
iE
ScreenSurfer
Config
If the Registry entries do not appear to change as expected, then check the security. In the Registry Editor, highlight Config and select Security/Permissions Then, change Type of Access to Full Control.
Note: You must now restart your browser and The ScreenSurfer Service itself for many changes to take effect--note that the status information following the submission of the settings page will inform you whether or not a service restart is required.
ScreenSurfer Console User Security
This page is presented following a click on the Console User Security Button on the main Console Settings page. It provides the ability to activate machine address-based security or userid/password security.
One of the latest features added to Version 3.0 is the ability for an Administrator to control access in ScreenSurfer by creating Console user accounts. The Console users are given specific rights based upon their level of product functionality. A user interface is provided for the Administrator for easy configuration of account rights, such as, recompiling, viewing a user session, and shutting down the server.
From the Administrators Console, select "Settings" then click on the "Update Console Users" button. As the Administrator, you can either click on an existing user to edit their profile and rights or add a new user to the current list. Once you have selected your choice, the window will convert into a user interface. When you have completed making your changes or edits, simply click "add".
Machine address-based security is generally not recommended, but is provided to maintain compatibility with prior versions of the ScreenSurfer base software.
Before activating user-password security for the console, you must disable the installation default for console security, which is "none" (!). To enable console security, edit this field and change the setting from "*" to either an empty string, or the hard-coded four-part TCP/IP address of a valid console machine. If you wish to have hard-coded machine address security for more than one machine, seperate the machine addresses with commas or spaces.
Once you have de-activated "wide-open" security (the installation default), you can start to use user-password security, which is managed with the following fields.
Enter a UserID to be used for Administration of ScreenSurfer. Both developers and administrators need to have Administrator's rights. To update the password of an existing user, enter that user's ID along with the new password.
Enter the new password for the given UserID. The password will not be written to the registry; instead, a unique hash value is generated, which is then used at runtime to compare with the real password.
The DevCenter button provides access for developers to the DevCenter page. The DevCenter page is a Frames-based HTML document currently only supported for Netscape Navigator Version 4 (and higher) and Microsoft Internet Explorer Veresion 4 (and higher). With ScreenSurfer Version 3, use IE 5.5 to fully utilize the Visual Surfer functionality in the DevCenter.
DevCenter provides administration functions for developers, such as re-compiling templates, generating new templates and a variety of related activities.
The Support button provides access to all ScreenSurfer customer support functions, including product technical support, sales assistance as well as accounting information.
Upon clicking this button, a new browser window will be displayed containing the Support Pages, starting with a support roadmap and related links. For all ScreenSurfer customers (and you are a customer from the moment you download the product for a free trial), access to all submitted questions, problems and suggestions is provided through the Support Pages.
Clicking on this button will cause a "sweep" of all sessions, checking which ones have timed-out. If a session has been idle greater than the timeout minutes (specified in the settings page), it will be stopped and made available. You can implement your own logic for timed-out sessions by adding a "TIMEOUT" section to global.stml.
This will not allow any new sessions to be started and will disconnect all existing sessions. Then, shutdown will occur. This is a soft shutdown which will only shutdown sessions that are not connected (eg. Those "In Progress " or "LU_INIT_PENDING").
After this is done, you must do a Stop Shutdown! to be able to restart any sessions that were shutdown. This insures that any problems have been resolved with these sessions before continuing.
This will immediately shutdown all existing sessions. This will shutdown all sessions regardless of their status.
Note that this may take a few minutes to complete depending on the status of your sessions and the number of sessions to be shutdown. After this is performed, you must do a Restart to be able to start any sessions. This guarantees that any system problems have been addressed before any more session access is allowed. The Service Status will change to Shut Down and 0 Sessions Active on the ScreenSurfer Console Home Page.
For example, if you have the following sessions:
ID | SNA LU | Term Status |
1 | DEMOLK1 | Active |
2 | BOZO | In Progress.. |
If you do a Shutdown (normal), then just BOZO will be Stopped.
If you do a Shutdown Now (hard), then both DEMOLK1 and BOZO will be stopped.
These items will appear after a Shutdown is selected.
Restart (Accept Connects)
This menu item will only appear after a Shutdown Now (hard). This will allow Autostart session to be restarted. This will allow sessions that were just shutdown to now be accessible.
Stop Shutdown!
This menu item will appear after a Shutdown (normal). This will allow sessions that were just shutdown to now be accessible.
About ScreenSurfer
This displays the current version of ScreenSurfer that you are using.
ScreenSurfer Release Notes
This displays information about the current version of ScreenSurfer in use. This includes such information as the features currently available and improvement over the previous version.
ScreenSurfer Documentation
The ScreenSurfer Documentation table of contents page is displayed.
The following columns of information are listed on these displays:
ID
This is the Session Identifier. This is the same as the special SessionKey value used to validate all ScreenSurfer Web Gateway URL's for connected users.
LU
This is the name of the SNA LU or the TN3270 connection address.
If the session is Stopped, then this will be the LU, LU Pool or TN3270 address defined in the Session settings. If the session is active, than this will be the active name of the LU assigned from the pool and not a Pool name.
Term Status
Would contain one of the following: Active, Stopped or an error. When an error Can be one of the following:
LU_ERROR
LU_PENDING_INIT
LU_PENDING_HOST
LU_LINK_INACTIVE
LU_LINK_ACTIVATING
LU_PU_INACTIVE
In Progress
If after Reloading/Refreshing these errors still appear when using an SNA connection, please check your services in SNA Server. Make sure they are started and not in error. If they are, you will have to restart the ScreenSurfer Service and SNA Server for success.
Session Status
Should contain one of the following values: Available or Active-SessionKey
Available: The session has no users active
on it, but has been started
Active-SessionKey: The Session has an active user connection, with
the displayed SessionKey
Activity
This is the transaction count or number of writes to the session that have occurred.
Idle Time
This is the amount of time the session has been idle. If the Term Status is Stopped, this value should be ignored. When a session is Active, this field will be color-coated accordingly:
Green - less than a minute (number of seconds)
Yellow - more than a minute, less than an hour (number of minutes)
Red - more than 60 minutes (number of hours)
Errors
For future use. Intended to contain HardErrorCount/SoftErrorCount.
Command
Start/Stop/Details. These commands are used to
either Start a session, Stop a session, or view the details of the session.
When you select Stop for an active session, a confirmation screen
will be displayed giving you the opportunity to cancel the stop request.
If you stop an active session, the user on that session will receive a
session not connected or timeout error on his or her next request to the
ScreenSurfer Web Gateway port.
Status example:
ID | SNA LU | Term Status | Session Status | Activity | Idle Time | Errors | Command |
1 | DEMOLK1 | Active | Available | 0 | 1 minute | 0/0 | Start/Stop/Details |
2 | IELUPOOL | Stopped | Available | 0 | 18 minute | 0/0 | Start/Stop/Details |
If you choose Stop for DEMOLK1, then the SNA LU will change back to the starting LU which is IELUPOOL in this case.
Additional columns on the Details (see the standard list items) screen are:
StartupLU
This is the original LU, LU Pool, or TN3270 name used to start the session
Cursor
This is the current cursor position
Last AID Request
This is the last Attention IDentifier sent to the session.
RUI SID
This is the RUI Session IDentifier. This is the number the SNA RUI interface uses internally to identify the session.
For example, additional fields for DEMOLK1 if
you have already hit Enter to get onto the second screen may be:
Startup LU | Cursor | Last AID Request | RUI SID |
IELUPOOL | 1760 | Enter | 2 |
Due to the wide variety of host communications and application systems, there can be circumstances where certain screens or combinations of screens are incorrectly interpreted by ScreenSurfer. When this happens, Teamstudio support personnel may request that you provide an SNA Server trace of the connection during the execution of the screen sequence that is in error.
The following describes how to start and use SNA server trace facilities for
q SNA Server v2.2
q SNA Server v3
To activate SNA Server version 2.11 trace:
1. Choose Microsoft SNA Server (Common) / SNA Server Trace
2. Locate the SNA Server installation directory (eg. E:\sna) and delete the files sna\traces\climsg*.trc. The SNA Server Admin must be closed and all Services stopped in order to delete these files successfully.
3. In the SNA Server Trace Options dialog box, select ONLY the "3270 Messages" checkbox, and make sure that the "Internal Tracing" scrollbar is at "disabled". The Service Name should be SNA Applications.
4. There should be no active ScreenSurfer users or connections.
5. Select the "APPLY" button in the SNA Server Trace Options Dialog Box.
6. Access the ScreenSurfer Web Gateway port from a browser and "exercise" the screens which are causing problems.
7. Wait one minute (to insure the trace has been flushed to disk).
8. In the sna\traces directory, you should now have new climsg*.trc files.
9. You may also be requested to repeat the above steps using the SNA Server 3270 Applet (after saving the trace files created with ScreenSurfer). This can provide ScreenSurfer support personnel with comparitive data.
Using SNA Server V3 trace
1. Choose Microsoft SNA Server (Common) / Trace
2. Locate the SNA Server installation directory (eg. E:\sna) and delete the files sna\traces\climsg*.atf. The SNA Server Manager must be closed and all Services stopped in order to delete these files successfully.
3. Highlight SNA Applications and Choose the Properties.. button. In Message Trace, check 3270 Messages and hit Apply.
4. There should be no active ScreenSurfer users or connections.
5. Access the ScreenSurfer Web Gateway port from a browser and "exercise" the screens which are causing problems.
6. Wait one minute (to insure the trace has been flushed to disk).
7. In the sna\traces directory, you should now have new climsg*.atf files.
8. Use the View Trace file facility in SNA Server and save the viewed data as climsg.trc ASCII text files for use by ScreenSurfer Support personnel.