Kicks-Out

What you can Expect to Experience Converting to Client/Server

When you first decide to do a Kicks-Out conversion, our consultants will examine your existing application to determine whether any unusual aspects of the way you use Telon will require adjustments to our product. Also if you have any preferences as to how your GUI screens should look, adjustments to the conversion software will automate adherence to these standards.

If you have a COBOL CICS/DB2 application running over an SNA network, and most of your users already have PCs and access your application using terminal emulation software, your initial situation will look something like that below. For our conversion to work successfully, you could equally well have a IMS/DC/DB PLI application running over a TCP/IP network using hardware 3270s, but its easier to discuss Kicks-Out if we stick to a single example. (It may seem odd to have DB2 stored procedures accessing an IMS database, but there's no problem.)

Typical Before Scenario

Once we have agreed on the details of how you want your GUI screens to look, we will convert a sample of your programs to allow you to verify these options. For example if you have decided to convert Telon VALUES clauses into drop-down list boxes, your users will have a chance to check out what this will mean to them. If they would prefer to continue typing the value in directly, we can make the adjustment at this point.

From each Telon program, we create four programs:

A DB2 stored procedure which contains the input logic from the Telon program
A COBOL dynamically-called subroutine to perform the output logic
A Java or Visual Basic 'thin-client' program to call the stored procedure
A CICS front end which calls the stored procedure as a static subroutine (This may be useful to test the other new programs, since some testing tools do not yet support stored procedures - also if your main concern was to escape from Telon, you may be content to use these front ends in production, but having the business logic in the form of stored procedures gives you a good option if later reasons to access these functions from GUI emerge).

We support Visual Basic back through version 4, so that you can use Windows 3.1 on an old 386 machine if you wish. (The client programs are not date-sensitive, so you can avoid the Y2K problems indefinitely by booting the 386 with a false date.)

Assuming you choose Visual Basic, and keep your database on the mainframe, once our staff has finished the conversion your situation will look like this:

Typical Immediately-After Scenario DB Remains On The Mainframe

Notice that in a way, little has changed - your users are using the same PCs over the same network to access the same business logic and the same database. No retraining is therefore required, since a Kicks-Out conversion is done on the basis that 'the same keystrokes will yield the same result as before'. Use of the mouse, special page keys, etc. is coded as an alternative.

What has changed radically is your ability to enhance the application.

Instead of having to tell your users that the enhancements they want are impossible on the mainframe, you can fulfil them.
Instead of explaining again to your local temporary staffing agency what Telon is, and paying to fly contractors in, you can use the large local pools of COBOL and Visual Basic talent. There is no code left behind which needs any unusual skills to maintain.
Because Visual Basic is inherently web-enabled, so is your application.

Another important point needs careful definition: many organizations have reengineered and downsized since the applications were originally built. Since each application was originally designed for a single department, abolishing departments and creating new ones often leaves each department responsible for working with several applications, often very inefficiently. Rewriting the business logic from scratch is a very expensive and risky solution. Once each application has gone through a Kicks-Out conversion, the business logic is segregated into the mainframe code, which the user never sees directly. It is a relatively simple matter to write new front ends for each department, still using the old stored procedures. In other words, the Kicks-Out conversion has given you a giant step towards an object-oriented environment.

Once the conversion is complete, and in production, you can exploit it in various ways. One of the simplest is to move the database to a cheaper hardware platform, now that you are not constrained by the need for CICS. A year or two after the conversion is complete, your environment might look more like this:

Typical Later Scenario DB Has Moved

Home Page Back to text Product Demonstration
Would screen-scraping work just as well? Office Locations and Contact information