QTerm 7.0

The 7.0 version of QTerm brings a new look and easily accessible function panels which can be permanently displayed (pinned) or can be automatically hidden and only displayed when moused over. Mutiple frame windows are also supported with one or more terminal windows in each frame. This allows you to easily take advantage of multiple monitors.

If you are interested in trying out the new version please click here to download the software

Click New to close.





The AccessServer provides a secure relay for host access. Client workstations running terminal emulation connect to the AccessServer which in turn connects them to host applications over TCP/IP connections. This relay allows the AccessServer to implement security, client verification and extra functionality transparent to both the client and the host, which is especially important when opening up enterprise host access from the internet.

Sample AccessServer configuration

The AccessServer can also  be deployed in non-Unisys networks in order to provide internet sharing and end-to-end security; for example as shown above in connecting tn3270 terminal emulators to an IBM mainframe.

A graphical management interface is provided for easy to use configuration and status monitoring. A wealth of statistics is maintained per connection.


The AccessServer is a Win32 service and runs on a 32bit Windows platform.  The minimum requirements are:

  • AccessServer runs on Windows NT4(sp4)/2000 /XP with IE5 and up 

When using QTerm or Web-UTS/Web-T27 as client software, the required client platform is: 

  • QTerm 4.2 runs on Windows 95a/98/NT4(sp4)/2000/XP with IE5 and up, with or without security

Requirements Notes:

  • QTerm 4.0 and 4.1 do not include support for secure connections, which is provided under QTerm 4.2/5.0.
  • Netscape uses the common Windows internet DLLs that are actually updated by upgrading Windows or by installing a current version of IE; which is why the requirements are based on Windows Platform and Internet Explorer versions.

Feature Descriptions

Concurrency Control

By configuring a concurrency limit you can limit the number of client workstations connected to a host over a given listening port. For example you may have 1000 users but only require a license for 500 concurrent connections, knowing that you don't have a requirement for any more users to be connected at a time.

Access Control

For each listening port you can set up a profile of clients that are allowed to connect. This is done by configuring a number of IP addresses, and optionally subnet masks, to limit the number of connections to a known set of clients.

Target Host & Connection Balancing

Each listening port accepts connections and opens up corresponding connections to a target host. Even on a PassThru port you can configure a set of hosts if your host applications support connection load balancing. This where you may have multiple network connection points to the same host or multiple hosts connected to the same backend database. In this manner it is desirable to balance the connections over the available hosts or access points.

Terminal Pooling (2200 port )

On a 2200 type port you can configure the AccessServer to perform terminal pooling. This means that a pool of terminal names is configured and available entries are used when making the connection to a host. This feature allows any terminal name to connect to the AccessServer and then have it pick a terminal name that is known to the host. The terminal names in the pool are therefore re-used as required. This can be advantageous if host resources are insufficient to support PID entries for all terminals capable of connecting.

Dynamic Host Selection (2200 port )

On a 2200 listening port you can configure a list of target hosts. The actual target host is determined from the TP0 connection packet, at connection time. This allows a user on a client workstation to configure a single IP address (the AccessServer) and open to one of a selection of configured hosts.

In order to use this facility you can configure the host addresses and names in your desktop emulator or use a default host (with QTerm, see below).  All hosts must be configured to connect to a TP0 host with an IP address of the AccessServer on the port you configure for AccessServer listening (typically 102).  The Host Application name for each host must match a configured host name on the AccessServer.  When a connection is made to the AccessServer the host name is used to look up the list of destination hosts configured  on the AccessServer.

This approach simplifies network management in that all desktops are configured to connect via a single destination ( the AccessServer) and the actual host applications may be easily moved without requiring any desktop reconfiguration.

$$OPEN destHost
The QTerm emulator supports a default host capability whereby you can enter a $$OPEN destHost message and a connect packet is sent to the configured default destination with a Host Application name of destHost.  In this manner you only need configure the default host in order to connect to any 2200 host configured on the AccessServer.

Uniscope Datastream (INT1data port )

If you are implementing your own host access software but do not want to get involved with the INT1 protocol then the INT1data port is what you need.  This port type offers a tcp connection to your software for exchange of a simple message based datastream.  All the host tcp connection and INT1 protocol handling is done by the AccessServer.


For more details, including the messaging port interface, please download the   AccessServer Help. Depending on your Windows version you may need to right click on the help file after downloading, display the properties and click the "Unblock" button.