COMMAND BUTTONS:
DDE transfer to external application
Roscoe Connection detects which host is active and then attempts to recognise the
current Host Screen. If it identifies the screen it extracts up to twenty fields from the screen
including Order Number, National Number, Customer Name, etc.
This information is then transferred, via Dynamic Data Exchange, to a local
SuperBase 2.0 database called S.A.M.S., being developed locally by one of our staff.
This button will cause S.A.M.S. to become the active application and Drift for Windows
and the Roscoe Connection will become background tasks.
"PARTS"Visual Basic utility
This button activates a the "PARTS" Program I wrote which displays text information
about any given part number. It can be indexed on Supplier and System type.
This Windows utility provides very quick access to information in over 1Meg of text files
"TECH INFORMATION"Visual Basic utility
Clicking on Techs activates the "TECHINFO" Window utility that displays technicians and
their current level of training. It can show either the courses a tech has done or the
techs that are trained on any given system. I wrote this utility to use a CSV version
of a local Excel spreadsheet as its database.
In this way the users have the convienence of using the features of Excel to enter, use display
attributes, enter formulas, and print sections of the spreadsheet while other users can
view the contents using "TECHINFO" without the overhead of using Excel and trying
to navigate through a sheet with over 100 columns.
"PAGER"Visual Basic utility
This button also activates a standalone application. In this case a Windows Paging
program that provides single and group paging and some basic search and sort database
facilities which also allow it to serve as a phone directory and answer important questions
like "who owns DCF193 and why has he blocked me car in!!"
The actual paging is done by a Drift For Windows Pager Robot I have written which
allows priority paging and logging of messages. It use the dial-up P9 interface in to the
Telecom Paging system. Usage of this system is surprisingly high, about 1500 page's
per week!
(ALT-D)Dialog Form
The Despatch button is similar in operation to the Transfer button. If it can identify the
Host Screen it will extract some useful information from it and put it into a user editable
dialog box. This information will include the Order No, National No, Customer Name
and address, contact person and phone number, and problem details. It will also try to
automatically bring the up the Techs name and pager number by searching on a tech no
extracted from the host screen. The user can add whatever information is required to
the job details extracted and the page the tech with this information, through a priority
interface into the Pager Robot.
Dialog Form
This function is not currently in use. It was used previously to provide quick key
access to the last eight host screens. I intend to use it for access to a new program
I am writing the "Service Plus Assistant", which is to large to describe here.
(ALT-K)Dialog Form
Brings up a multi-column list box which contains a variety of strings that are relevant
to the current host. Using the mouse or keyboard these text strings can be sent to the
host as if typed from the keyboard. This facility can cut keyboard load by a large amount
and provide features like semi-auto login, etc.
Dialog Box
The Print button (ALT-P) provides either hotkey or point and click access to printing
a choice of either one or two screens per printer pager.
Dialog form with popup menus
This button is no longer relevant. It was used to provide a host access and pull-down
menu system that was required when were accessing multiple hosts on a single session.
LABELS:
The time label provides a handy reminder of the current LAN time
The value in the percentage label is a warning about the current level of Windows resources.
This is a visual indication of the version of the Roscoe Connection currently in use.
Invoking the Windows Task Manager will also show the date the version was created.
Alt-1Alt-8
The Host Labels on the bottom line e.g. Demon, DemonB, Service+ are used to either
connect or disconnect from Hosts. This is done by either clicking on the label or
using their associated hotkeys (ALT-1 to 8). The label will glow green when their
is a active session for the named host. This can be used to manage session resources.
ALT-PtrScr (on Osborne 101 keyboard)
WHAT FOLLOWS WAS TO BE A MORE FORMAL DOCUMENT DESCRIBING THE 'WHY' AND 'HOW' AND 'HISTORY' OF THE "ROSCOE CONNECTION" IT IS NOT COMPLETE AND REQUIRES REWRITING, ETC
EXECUTIVE SUMMARY The "Roscoe Connection" is a Windows based program that acts as a front-end for Telecoms SOE Communication package Drift for Windows V1.1.0. The "Roscoe Connection" adds additional functionality and user-friendliness to Drift for Windows as well as providing access to a number of other services. It has been developed locally to meet specific needs but also provides a range of general purpose functions that could perhaps be applied else where.
INTRODUCTION The original DOS version of the "Roscoe Connection" took it's name in part from the name of the commercial program it replaced. This was a commercial communication program released by "Softerm" and was locally identified as the "Host Connection". The Windows\Drift version retains the same name to exploit the good-will the original version had attained.
BACKGROUND (DOS Version) At the time of the design of the Sturt St LAN the preferred method of host connection was via DDN lines hooked up to CS410 boxes. The CS410 boxes allowed access into Horizon, Rass, Dcris, Leopard, etc to be broken up into user groups. Up to four different hosts could be accessed on a single session and the native terminal emulation's of the hosts were translated into a VT100 emulation. Each host required the keyboard and function keys to be remapped separately, consequently the chosen software package provided a series of hot keys macro's that ,hopefully, changed the current host session and the keyboard remapping. The LAN based system replaced the use of Dumb terminals each running in the native emulation of the host, this advance was initially seen as a great step backwards !
Inherent Problems (of the Telecom design) The LAN design had a number of major disadvantages including :-
SOLUTION I identified the problems above as requiring a technical solution. I established that is was possible to interface to the Telnet layer used in our communication protocol. Having proven the technical feasibility of the project I developed , on my time, a VT100 emulator, using Borland C++ which I had purchased as some cost. This program had a number of specific features to overcome the problems listed above. It ran in 27 line mode to provide all the required information for the HP based host. It provided pop-up menus for host access and provided a visual display of which work stations were using which sessions, to allow the best use of our limited number of sessions. Some performance fine tuning was required on my program to give it the equivalent performance of the Softerm software, which I suspect was written in assembler, when running on slow PCS (286). The overall performance of the Roscoe Connection did a lot towards encouraging users to migrate from dumb terminals to the use of LAN workstations.
BACKGROUND (DOS Version) INTRODUCTION of WINDOWS With the introduction of Windows it was important to encourage users to exploit it powerful and productive applications to the full. Unfortunately initially it was not possible to run Windows and access the hosts systems concurrently. Changing from a communications session to a windows session and back again, meant logging out of and back into a number of hosts. Which was a lengthy process assuming on leaving Windows you could actually get an available host session. This process was holding back our migration to being a Windows based site. To solve this problem I enhanced the Roscoe Connection to allow it to startup itself and the required TSRs and the load Windows on top of itself. It was then possible to task swap between Windows and the Roscoe Connection using a hot key, without loss of connectivity. This solution resolved the problems outlined.
INTRODUCTION of DRIFT for WINDOWS The production of Drift for Windows V1.0.5 provided us with the opportunity to seamlessly integrate our host connectivity into the Windows environment. But as this time, and up until the introduction to our site of CDN-B in July 1993, there was no alternative to using the CS410 boxes. As Drift for Windows is unable to support multiple keyboard remapping on a single session it then came down to a choice staying with DOS communication programs or writing a version of the Roscoe Connection to interface with Drift for Windows.
DEVELOPMENT LIFE CYCLE (Roscoe Connection for Windows) This document is the only, apart from the source code, formal statement of the design and intellectual processes involved in the development of the product. The actual development occurred through rapid prototyping. The requirements and specification stages were constantly revisited, consequently this document should not considered as a chronological statement of the program development.
REQUIREMENTS
Concept Exploration
The concept of having a Drift front-end was my own and stemmed as a logical
step from the DOS version of the Roscoe Connection.
Business
- (Desirable) Ensure that Drift4W became the communication program of choice allowing the changeover to Windows SOE applications occurred ASAP.
- (Desirable) Ensure that Drift4W remained as similar in operation to previous program as possible to reduce user learning curve and resistance.
- (Desirable) Provide quickest and convenient possible access to Host mainframes.
- (Desirable) Support AS Standards conformity by allowing users to "page" host information out to field techs.
- (Desirable) Support local applications by providing data extraction and exchange facilities.
Functional
- (Essential) Allow Drift for Windows to support multiple hosts on single session.
- (Essential) Appear to integrate into Drift for Windows rather than being a separate application, without obscuring Drift window.
- (Essential) Provide a visual indication of current and active host sessions.
- (Desirable) Provide point and click and hot-key access to sessions and host swapping.
- (Desirable) Provide point and click and local tools and printing utilities.
SPECIFICATION
Program screen behaviour "R.C." has to behave like a child window of Drift. Float above the Drift application window without obscuring. Disappear when Drift and itself are not the active application Resize and move itself when Drift resizes and moves. Adjust to different screen resolutions. Drift interaction
General behavior Minimize its overhead on Windows resources Detect if a copy of the program is already running and defer to that copy Detect when the Drift application closes, even if a Drift control is not attached, and prompt the user to close the Roscoe connection
DESIGN Choice of programming language As Drift for Windows supported Microsoft Visual Basic this was the obvious choice. Experience in programming language In the initial stage I had no experience with Visual Basic and no experience with Drift custom controls. Consequently I had to write some test programs to gain experience with both these products.
Program Structure
The program structure as evolved rather than stemming from an original high
level design. The program code modules are as follows:-