Written:
> 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.
>
Other have stated (excuse the pun) views on the pro's/con's of a stateless
environment. IMHO, the combination of both state and stateless design,
within a single application, increases an organizations responsiveness and
adaptiveness to the latest techno-de-jour. Every application should strive
to provide a layer of the code which is stateless, yet atomic, and usable
from either the layer of application code requiring state, OR from a
completely external IP based layer (such as the Web).

Every application should provide an access layer, call it an API, which
expresses a set of atomic functions, call them methods, write them in COBOL.
This API, which can be used local or remote (w/different middleware
products), should be the basis for the State Centric processing model AND a
Stateless one (like the WWW).

The implementation of many older State management environments has committed
the underlying application logic to a non-atomic and thus a less "open"
form, code developed in this model often is locked in, and thus the adoption
of the newer generation of software becomes more difficult and the number of
choices diminishes.

Jon van den Berg
Premier Software Technologies
http:/www.premiersoft.com