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.




see also HostAnalyzer, WebVIew


HostConnector is a service program that provides multiple concurrent Unisys host connections and serves up transaction screens in XML format.  It is installed as part of the WebView product but may also be deployed with your custom web application.

HostConnector exposes an automation interface that allows a calling program (e.g. ASP page or Visual Basic program) to add a new connection, set its properties, and connect to a host.  Thereafter, the calling program can simply wait for host xml messages and post xml responses via the defined automation methods.  There are also a number of lower level automation calls available for manipulating the virtual screen associated with the host session which are modeled on the QTerm automation interface.  It is unlikely you will need to use them but they are there if you find you have to perform very specific screen functions.

The processing of the XML data is a function of the calling program.  You could, for example, use ASP pages to form a browser capable presentation of the data by rendering html to the client and receiving http responses and mapping them back to XML.  Or you could send the XML together with an XSLT definition directly to a browser.  Or you could send XML documents to a remote Web Service in which case you would be less concerned with presentation and more concerned with processing the XML data directly, perhaps as a part of your business logic on an application server.


A very typical deployment is to provide a web service with a host interface. In this example the HostConnector service is installed on your web server and you build up screen definition schemas using the HostAnalyzer utility.  The installation is fairly straightforward:

  • install the HostConnector service by running the setup program
  • use the Windows component services console to specify the users that can connect to the service, typically the Administrators group for control and ASPNET for ASP pages to connect to HostConnector
  • run the HostAnalyzer program to identify your host transaction screens

Now it's over to you to develop your web application.  Assuming a Visual Studio aspx development then you can use your language of choice (e.g. Visual Basic or C#) in the back end code to call the automation methods of HostConnector.

From an ASP page you can create connections to the host, send messages and receive responses in XML format.  These XML exchanges utilize the screen map schemas created in HostAnalyzer to recognize host messages and map the screen fields data into an XML tree.  This has 2 important ramifications:

  • all fields are referenced by name
  • all the screen fields are exchanged with one method call (instead of having to make 10's or 100's of method calls to access fields individually)

Also be aware of the implications of mapping web sessions to host transactions.  In the web server world an ASP page is scheduled when input is received from a web browser; the page processes the input and sends a response back to the browser.  Now this interaction can easily involve accessing host data as easily as it can access a SQL database.  However, the nature of host transactions is that the response to a host transaction can be somewhat less deterministic than that of a database query.

A host transaction typically returns a single response but may return more than one response.  Occasionally the number of responses may be variable, depending on the input and the context.  This is where your web application logic comes into play.  The connection methods GetXMLdata and PutXMLdata are self evident but also consider using the WaitHost method.  The point being made here is that the automation interface to QTerm offers an event interface to alert the automation client as to when messages arrive etc. but the nature of ASP threads means that the event interface is not feasible.

Sample Code

Sample code is provided for a stand alone automation client program and as a sample ASP based web called WebView.