Description
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.
Requirements
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.
Details
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. |