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.
Web Installation (Server Files)
Web-UTS and Web-T27 are ActiveX controls that provides the complete functionality of a Unisys UTS or T27 terminal connected over TCP/IP to a Unisys 2200 or A-Series mainframe. In the examples below they are referred to as Web-XXX. An HTML page on a web server is accessed from a user's desktop to automatically download the ActiveX control and associated components. The first access can involve downloads and naturally takes longer to complete than subsequent accesses.
The centralized access to a web server provides simple management of the profiles and settings required for the end users. In order to perform terminal emulation, the ActiveX control needs to be given configuration settings and terminal names. Remember that an ActiveX control, being a DLL, is very much the servant to the controlling program. Unlike an executable program it is not launched with its own working directory and command line parameters. It must be told what to do. Each web session starts by accessing a profile, which gives the required direction and URL names.
Web Server Installation
Various files are installed on your web server, in a directory accessible from the web root directory. The naming convention is adopted to conform to the names used in the INF file in the primary cabinet file. If this convention is a problem please contact us for a specially tailored .inf file. These files include:
These files are described below, under components. After reading about the content of these files the sequence, or dependency, will probably be self-evident. The web page points to the Profile and the Profile indicates how to load the Settings. and provides the terminal names and the host names. These operational stages are dealt with in more detail below.
This is the web, so you can use your imagination and artistic talents to their full in designing your own web pages! Several sample web pages are provided to guide you on how to incorporate the ActiveX control on a page and set the required parameters for initialization and configuration.
You can use one of the commercial web page formatting/layout programs or code directly in HTML if you are comfortable with that. In any case you must end up with the ActiveX control positioned on your page and the ProfileURL parameter must be set to point to a profile file on your server (more about the profile below).
After the control has been positioned on the web page the HTML code should contain an object definition much like the following:
The web page parameters are as follows:
Typically you will want to either have a specific layout on your web page, mixing the ActiveX control with other text or graphics or you will want to fill the web page with the control. In order to fill the web page with the control you must set the margins to zero and tell the control to use 100% of the available area, as follows:
The profile (as specified in the web page by a PARAM statement) contains the names of files required and, importantly, whether they need be loaded if already present on the target machine. This speeds up operation if files are not required to be re-loaded and also allows the web manager to force downloading of files the next time someone accesses the web server.
A good example is updating common macros or key mapping and ensuring everyone gets updated the next time they log in.
Typically all users can access the same web page and hence the same profile. However, the target end users may be grouped according to access rights, preferences or even nationality and a web page/profile per group may be generated.
The profile is organized as a number of sections, much like the Windows INI files:
The settings file must be downloaded at least once and thereafter may be forced to download (DownloadNewSettings=1), overwriting whatever settings are on the desktop.
If the settings file is to be downloaded then the SettingsURL parameter must be specified. This indicates the URL where the Settings file is to be found (on the web server).
NoDummyTerminal specifes whether or not to allow a dummy terminal called "?" to be created if the user name cannot be found.
UseDownloadCache specifies whether or not to allow downloaded files to be retrieved from the browser cache.
As shown, you can include up to 25 arbitrary files to be copied. The key names must be File1 through File25.
By default the files are downloaded to the system TEMP directory but the Local Directory parameter may be used to specify a target directory on the users desktop. This should be specified if you want to allow users to modify the Settings file on their desktop and to preserve those settings.
This is a server based text file. It is simply copied to the user desktop when required. The content is described in the QTerm Help file. The settings file may be created either by QTerm, by Web-XXX or by the QConfig utility.
This is where you can set up macros, colors, key mapping etc in a common format for all users. As documented in the QTerm help file you can configure a password to protect some or all of the settings from user modification.
Terminal Names and Host Names Files
Terminal names are a very important part of configuring access to a host computer. Typically the terminal name is used as a security factor by the host before allowing access. The Terminal Names and Host Names files were first designed to support the server-based installation of the QTerm emulator and this philosophy applies very well to the web environment.
You could go the extreme of having a web page per user, each of which would point to a profile per user and a settings file per user. This would allow a complete settings file to be prepared per user, including the required, unique terminal names but would be a huge headache to configure and administer. Hence the idea of a common settings file minus the terminal names.
In this case every user downloads the same settings file which does not include the terminal names but does specify how to find the terminal names. This is done in the Path Settings section. The URL of the terminal names file is specified and is augmented by a user name. Hence all users (or group of users) receive the same profile and settings but access their individual terminal names. The user name may be configured in the path settings as one of the following:
The Host Names file is simply a list of host definitions that are copied to the desktop. This allows you to specify the same list of host for access by all users (or a group of users).
Required Modifications to Installed Files
The files installed on your web server are the nucleus of your operation and must therefore be tailored to your environment. The modifications are mainly to do with network addresses. Note that you can specify an IP address (e.g. 188.8.131.52) instead of a domain name (e.g. www.abc.com). The required changes are fairly simple and can be made using Notepad or Word.
The users access your web server via the browser on their desktop, as to any web site. The first time they do this the browser will determine that the embedded object is not present and will download it from the codebase specified in the web page. Actually, more than the ActiveX control is required and these files are packaged as CABinet files that include an INF file, the control and the QTerm font etc.
The control then takes over and accesses the web site to retrieve the profile, the settings and the terminal names file. All this is transparent to the user unless an access problem occurs; in which case an error message will be displayed.
The user's customization of the Settings is governed by the contents of the Profile and the security specifications in the Settings file.
All things considered, the user is unaware of most of the "under the hood operations" and simply accesses a web page that allows access to a mainframe as if he/she were connecting from a regular terminal or terminal emulator.