A while back, by accident, I noticed that someone had mentioned TPF in a discussion being
carried on in the Usenet group 'comp.arch'. It was originally going under the title of
'Mainframes vs. Unix' and was the usual debate about the rise of the unix box as a
solution for the future and the questions about the role of the mainframe etc.
I decided to toss in my contribution and was immediately inundated by e-mail extolling
the virtues of unix as a high-volume transaction processing solution. The subject of
benchmarks came up and the TPC-A results for TPF. Nowadays, of course, most
self-respecting transaction processing systems have a TPC-C rating (since it is more
'lifelike' as a benchmark) Despite being told to the contrary, every website that I
visited to find information on the latest TPC-C results were measuring transactions in
'tpm' or transactions per minute, and then only scoring up to 30,000 (= 500 transactions
per second).
Check the following league table and you'll see what I mean...
TPC-C League Table
from Ideas International.
While I can readily understand that the unix systems are rapidly improving in their
weakest areas, those of operability, recoverability and spedd, TPF is pressing ahead in
areas where it is weakest, chiefly programmer development environments, connectivity and
the ability to port-in applications from other platforms.
I expect this debate to continue as I am curious to find out just how close the Silicon
Graphics, SUN and DEC's are to mounting a real threat to TPF for the applications most TPF
systems run. I'm hoping that those of you that read this that have any experience with
unix (of any sort) will send in those experiences so we can build a better picture of what
the real story is here.
What do you think ?....
A recent e-mail from an observer in the US:
"I know of a shop where they have a TPF system that processes close to
2 million transactions a day at a cost of less than $.0003 per transaction. The system is
always up, is mirrored in real time, and provides under 3 second response time to over 99%
of those
transactions. The operation of this system is fully automated.
This same shop has a UNIX based system that chokes at a much lower transaction rate, can't
keep mirror databases reliably in synch, and is currently operating at a cost of about
$2000 per transaction. It also requires round the clock babysitters."
Another reader writes:
"There are applications which are best run on Unix, and there are
applications that are not. Pick the correct OS, forget one size fits
all. Unix is a great operating system, but it is a system designed to exploit
hardware inadequacy, i.e.. it's a multitasking operating system. It is also intended to be a well rounded operating system, all things to all people.
It is like a shotgun, frequently hits it's target, but not without a lot of collateral damage. As hardware speeds up Unix speeds up, transaction
rates increase, but it's still multi-tasking.
TPF on the other hand is a much more focused operating system. Tasks begin and end without being forced
out. As long as TPF can maintain it's focus it will always be faster, but as IBM keeps trying to add "Newer Technology" to TPF (Folders and Pockets,
TCPIP) ground may slip. What the TPF community needs to do is examine proposed changes based on the fundamental TPF premise, SPEED. Will the
change slow the running applications down? How much? When questionable changes are implemented by IBM ask that they be removed! Don't just ignore
the APAR, get rid of it, it muddies the water. Let's not make TPF a Unix clone."
