The Simulated Host, as a standard Windows service, can be started automatically by the system, or through direct action by the operator using the Administrative Tools / Services control applet.

 

Each connection opens a TelNet conversation on port 23; what happens after that depends on the active script or log file currently configured for the Simulated Host.

 

Adds an Icon to System Tray

 

The Simulated Host, while running, displays an icon in the System Tray, which enables the changing of the active script file as well as a convenient method of stopping the service/process.  The Accessing Simulated Host Options section describes how to access Simulated Host options through the tray icon.

 

Can also run as a Process

 

You can also run the Simulated Host as a process, from a command window or directly.  When running as a process, be sure to include the special flag -start or the Simulated Host will incorrectly try to start the service dispatcher and fail to load correctly.

 

Example:   c:\simhost>simhost -start

 

When run as a process, the Simulated Host displays all messages to a standard command window (in text mode).

 

Functions are Based on Script File

 

Once started, the Simulated Host will read a definitions/script file that initially points to a sample installed with the Flynet Viewer, compile it and then wait for new clients or application servers to connect.  There are two types of scripting files.

 

Simulated Host Custom scripts end with the extension .sms or .xml and contain logic, screen maps and event declarations to enable the reproduction of host logic in a rapid manner.  This scripting environment is not intended as a real logic/business rules capable environment, but is intended as a "logic stub" to help simulate error conditions and navigation.  For example, while a real application needs to read a database to display a list, the Simulated Host script can simply display a fixed, hardcoded screen displaying the same list every time.  At this time, Full Scripts only support TN3270 clients, but future Simulated Host versions may add additional emulation protocols.

 

Log Files end with the extension .log and are copied from the standard Flynet Viewer log file created in the Flynet Viewer data\logs folder.  Log files do not contain logic, but replay the exact buffers sent and received by the host during the logging session, so they can reproduce any protocol type supported by Flynet Viewer.

 

The primary advantage of Log Files as input to the Simulated Host is the minimal effort required to capture them, rename them and save them as Simulated Host scripts.  By recording complex application sequences in the Flynet Viewer Administrator's terminal emulator or WorkFlow Screen Recorder, it is easy to produce tests that cover large areas of functionality for an Flynet Viewer application that requires testing.

 

Errors are Written to Event Log

 

As a standard Windows Service, the Simulated Host will write all errors to the event log.

 

Maximum Connections

 

Many concurrent connections can be supported by the Simulated Host, as it uses highly efficient multi-threaded techniques to optimize performance.  By default, 100 connections can be maintained simulaneously, but this number can easily be increased by editing the registry setting HKEY_LOCAL_MACHINE/Software/FlyNet/FlyNet SimHost/MaxSessions.

 

Due to the ability for the Simulated Host to support many concurrent sessions without "melting the PC", it is a good option when performance testing is undertaken.  Otherwise, valuable host resources can be sapped in trying to simulate the load of many users, particularly if the transactions involved are complex.