In my last article I have investigated whether there are 30 billion COBOL transactions per day and I have concluded that this claim is baseless. So now I want to discuss how many transactions there actually are per day.
Since there aren’t any reliable, recent numbers, I will have to talk about the numbers from the late 1990s.
Inhalt
What is the capacity of a mainframe?
IBM has sold 30 million CICS terminals and 50,000 mainframes. I think we can rely on these numbers, because IBM can have taken them from their sales figures easily. Since the terminals don’t do the processing, they are irrelevant for this question.
Today, only 10,000 mainframes are still in use, but to the best of my knowledge, there were still 30,000 mainframes in use in the late 1990s. For 30 billion transactions per day, this would mean that each mainframe had to handle about 1,000,000 transactions per day. This sounds like a cosmetic number that the marketing department would choose – but is it plausible?
I don’t want to make misleading claims, so I want to emphasize that „transaction“ is not a unit of measure. Depending on what a transaction does, it takes more or less time. Creating a new customer-record takes longer than modifying an existing one for example – so if you only edited customer records all day long, your mainframe would be able to handle more transactions per day than if you only created new customer records all day long.
Billions per second?
IBMs marketing department keeps claiming that mainframes were able to handle billions of transactions per second, but if mainframes could handle „only“ one billion transactions per second, then one mainframe alone would be able to handle all the transactions in the world, while running at only 0.035% utilization. Why would you even build a second mainframe? Let alone 49,999 more mainframes? This is complete nonsense!
Artificial Transactions
Of course you can construct artificial „transactions“ that only write a single byte to a hard drive. Such „transactions“ could run at the speed of the hard drive they work on. That would be billions per second on m.2 hard drives, so this might be how they came up with that claim…
But we are talking about real world transactions here.
Queue length isn’t throughput
Several case studies of the time mention that mainframes could handle peaks of over 1000 transactions in 1 second. I guess some marketing people mistook this for the speed at which mainframes can process transactions, because you also often read that mainframes could handle thousands of transactions per second.
No – this is just the size of the queue – mainframes can take a short burst of a thousand transactions, store them and process them later, when the burst has stopped. If the burst doesn’t stop, the queue overflows and the mainframe rejects more incoming transactions.
New Jersey and IBMs case studies of the time
The mainframe in New Jerseys department of Labor started failing when they hit 220 thousand transactions per week, so 31.5 thousand transactions per day were already to much for it.
IBMs own case studies of the time talked about 30 to 60 thousand transactions per day. Some case studies talk about more transactions than that – but these case studies are about scenarios with multiple mainframes that run at 30 to 60 thousand transactions per day each.
Conclusion
So I think 30,000 mainframes times 60,000 transactions per day makes a generous estimate of 1.8 billion transactions, that all the mainframes of the time together were physically able to handle per day, if all mainframes ran at full capacity at all times.
Of course, machines normally don’t run at full capacity. The mainframe in New Jerseys department of labor normally processes about 3,000 transactions per day. That is just how many claims they get per day (outside of the Corona crisis). So if we take that as a benchmark (for lack of more numbers), we arrive at about 90 million transactions per day.
So I believe that there were somewhere between 90 million and 1.8 billion transactions per day in the late 1990s.
And I, for one, have come to the conclusion that you shouldn’t believe a single number that anybody tells you about COBOL. These are not scientific facts, they are marketing fiction.