Richard Gambrell <[log in to unmask]> bemoans:

> The question very much in our face here at UTC is where to direct our next
> generation software development and how to evolve the current generation.
> Does it make sense to aim it at qcterm or at html or Java or any of the
> other client/server technologies? Can we afford to do more than one?

This is a problem faced by a lot of businesses.  Whether to bet the business
on the language du jour and risk being orphaned if that language fails, or
to bet the business on the status quo and risk being out-technologed (a new
verb!) by the competition.  This is why COBOL 2000 (or whatever they're
calling the next implementation of COBOL) is so important to us.  With the
proper tweaks, COBOL can be made to be a very robust, leading edge type of
language.  It would also allow us to leverage our existing knowledge and
systems by evolving them, instead of wholesale replacement.

The difficulty with an HTML or browser-based solution (and a lot of the
other C/S solutions) is its statelessness.  Not that statelessness is a new
concept.  IBM's CICS and Unisys's DPS were both stateless screen handlers.
What I love about the HP (and others) is the stateful connections.  That's
what makes QCTerm so nice.  It's a GUI interface, but with a stateful
connection.  This, combined with COBOL enhancements will enable us to jazz
up those old applications and design some very nice and elegant new
solutions.


Jim Phillips                            Manager of Information Systems
E-Mail: [log in to unmask]     Therm-O-Link, Inc.
Phone: (330) 527-2124                   P. O. Box 285
  Fax: (330) 527-2123                   Garrettsville, Ohio  44231