UK-based website

The Alternative TPF Homepage
Serving the online TPF community since 1995 : Now receiving >12,000 hits per week

Where To Next ?
Home
TPF Scoop

   TPF Jobs
  Online Store
TPF Talent
TPF Help
TPF Site Search
TPF Net Search
TPF Link Central
What is TPF ?
TPF TravelGuide
TPF vs. Unix
TPF Futures
  Where are they now?
TPF Salary Survey

comp.os.tpf

 

Any browser will do....

Animated GIFs by:

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

 


Updated: 14/05/02