NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/database/6505

Internet Message Format | 1992-09-02 | 5.1 KB

Path: sparky!uunet!ogicse!hp-cv!sdd.hp.com!scd.hp.com!cupnews0.cup.hp.com!dhepner
From: [e-mail] (Dan Hepner)
Newsgroups: comp.databases
Subject: Re: TP monitors for SunOs, 3278 drivers.
Message-ID: <[e-mail]>
Date: 2 Sep 92 17:56:09 GMT
Article-I.D.: cup.BtyptM.GMD
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett-Packard
Lines: 91
X-Newsreader: Tin 1.1scd1 PL4

>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.

Ok, but we need to back up one step.  This machine is capable only
of running a single batch job at a time, and we want to do online work.
Making a single batch job service lots of online users was the primary
accomplishment of the original mainframe TP monitors.  Efficiency
came as an optimization, reduced memory consumption reflects the
reality of 25 year old memory systems.

OLTP on Unix "came with" this fundamental problem already solved.  One
or more Unix processes per user works quite well as a means to provide
online access.

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.

This problem is overblown somewhat, as applies to most Unix kernels suitable
to be run on "multi-user" hardware.  Running hundreds of processes seldom
creates much OS inefficiency, and with main memory sizes exceeding 1GB,
keeping significant amounts of state is similarly less of a problem than
when 1MB of main memory was a lot.  We do however start to see inefficiency,
both in the OS and with DBMS software when we start to run thousands of
processes.

So we see that the problem, whatever it might be, to be addressed by a
Unix TP monitor is not the same as that which faced the designers
of mainframe TP monitors 25 years ago.  While it is desirable to reduce
the number of "heavyweight OLTP processes" to well below 1 per online user,
there is little point in shooting to achieve, say, 3; 50 would likely
work as well or better.  Client/server designs address this desire quite
nicely.

However, we do not need a TP monitor to do client/server.  Sockets based
C/S has been doable for more than a decade, and DCE now provides a broad
set of nice standards for doing C/S.  Situations when the client sends a
message to a server, and the server completes the transaction are
well supported using conventional communications.

But what if the transaction needs to access more than one service,
particularly when the services access different databases?  This is
the essence of the problem which Unix TP monitor products solve.
They provide transactional communications, the ability to "flow"
the transaction from the client process to the server process;
whatever is done in the server will need to be atomically committed
with work done by the client as well as that done by other servers.
We need two phase commit coordination, and we need the buy in of the
database products, allowing themselves to be coordinated to achieve
a global atomic commit.  The DBMS product buy in has come as
"XA compliance", and is now nearly universal.

All (3 or 4) of the Unix TP monitors can do that; some use TCP
as their basic communications, some use DCE RPC.  But they all provide
the ability to have work done in multiple processes be coordinated as
a single atomic transaction.  Well underway with all are ways of expanding
the transactional communications to include activity done on mainframes.

Then the different products go their own way, especially in answering
the question "what does a Unix TP monitor monitor?"

>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.

One might expect this concern to be answered with, "you really _like_
those dumb terminals?"  Some would imagine them as the first to
go in any "downsizing operation"; it's fairly straightforward in many
systems to install a user-friendly, Unix based, graphical front end
which then submits ugly transactions to an unchanged back end mainframe.

>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 (?).

Leaving SPARC out of it, if this is really what you want, it may be
worth checking out CICS-AIX, from IBM, on an RS/6000. If anyone can
supply CICS on Unix, it's likely to be IBM.

One might observe however that if the problem which one is setting
out to solve is running 500 happy online users, that the cost differences
between "small Unix machines" and "large Unix machines" as the backend
hardware is not likely to show up as the dominating factor in determining
which to buy.

Dan Hepner
Not a statement of the Hewlett Packard Company.