From: simon@castle.ed.ac.uk (Simon Brown)
Newsgroups: comp.databases
Subject: TP monitors for SunOs, 3278 drivers.
Date: 2 Sep 92 14:01:37 GMT
Organization: Meiko Scientific

I'm posting this article on behalf of a friend who doesn't have access to the
net. 

Subject: TP monitors for SunOs, 3278 drivers.

Dear Netters,

TP monitors are a popular discussion topic these days. However, I confess 
to having experienced real difficulty in piecing together a coherent 
understanding of what I may be able to use one for. 

I hope that what follows serves to start a discussion, as well as to give me
some pointers towards useful products. I am sure it is incorrect in many 
respects, which is partly why I am posting it.

The problem seems to me to be that there once was a term "TP monitor" which 
meant something quite specific. It came from the days when Big Computing
in the DP world was all about handling very large numbers of small, simple
users on machines with relatively small numbers of MIPS, and relatively
small memories. An installation would only have one of these machines,
and it would be very big, and very expensive.

To handle this large number of users two things are critical: to minimise
the cost of context switches between users, and to minimise the amount a state
that needs to be held per user in fast memory. TP monitors (EG CICS) achieve
this by being much less extravagent with their use of heavy processes than Unix
applications would typically be. Instead, they have a few (?) great big
processes which work on behalf of a large number of users, holding for each
user the bare minmal amount of state information required. A typical Unix 
setup would, by contrast, have at least one heavyweight process per user (maybe two, if using a 2-task RDBMS setup).

Some "TP monitor" products now exist for the SunOS platform (in which I am 
interested). However, they differ from my expectations in some subtle and
confusing ways. Firstly, they seem to consist of a package of functionality
which starts with what I understand to be a TP monitor, but extends to cover
many other areas. The only way in which I can usefully catagorise this extra 
stuff is as "things which got left out of RDBMSs and O/Ss, but which
database system designers might find useful". It includes things like network
load balancing, database distribution and so on. 

The other difference is that (in my naive understanding), a Unix TP monitor
is really no more than a sophisticated RPC system. It expects there
to be clients, probably out over the network somewhere, which run as proper
grown-up programs, talking to the RPC-server (AKA TP monitor) via something
sophisticated and expensive like TCP/IP. This is fine, provided your
system architecture allows it. However, it does you much less good 
if your front-end is an enormous network of dumb terminals, or even semi-dumb
terminals like IBM 3278s. What you want then is CICS, under Unix. Not a CICS
migration tool, or a compatability interface, but something which lets you
service a sensible number (500 ?) of OLTP users on a small machine like a 
SPARCstation 10 (?). Something which concentrates on servicing terminal
(or 3278) i/o with jealously husbanded CPU cycles, and holds not one 
byte more data than is really needed.

Does anyone out there have any suggestions (products) ? or corrections ?
I would be quite interested in information on 3278 terminal driving h/w
and s/w for SunOs too. Over to you.

------------------------------------------------------------------------------
Simon Brown             / /     email: simon@ed.ac.uk, or simon@meiko.co.uk 
Meiko Ltd. (Edinburgh) / /
------------------------------------------------------------------------------
Newsgroups: comp.databases