3 ms·

What do you mean by "transactions" in this context? I don't think either COBOL or old IBM mainframes support software transactional memory (STM) as that's a fai

What do you mean by "transactions" in this context? I don't think either COBOL or old IBM mainframes support software transactional memory (STM) as that's a fairly exotic technique that's mostly seen in the context of Haskell and the like, even though it does seem interesting as a model for concurrency.

bin0 7y ago
Not in that sense, in the sense of "how many cart checkouts, wire transfers, other business logic transactions can I perform per unit x time?"
6thaccount2 7y ago
Like user bin0 said below, a mainframe can do 30k to 1.1M transactions like wire transfers in a second. They also have rediculously high up times and much higher security (probably mostly via obscurity). Unfortunately, they're insanely expensive.
- hermitdev 7y ago
  Probably more obscurity than actual security, in my experience. I once knocked off about 10k users off of a dev mainframe LPAR simply by running a SQL query (crashed DB2 and the underlying OS). With someone with more experience than I had, probably could have been exploitable. It was an accident, but it happened. Mainframes weren't nearly as rock solid as their reputation in the 3 years of dealing with them that I had. Mainframes were great at processes that need high IO. I've not dealt with them in close to 20 years, so dont know how current x64 linux or Windows stacks line up. Mainframes are hugely expensive. 20 years ago, entry level for the hardware was around $500k, IIRC. Dont think that even provided storage or software licenses. But, yeah, youve got one largely extremely reliable piece of big iron that can handle nearly all of your needs.
  - 6thaccount2 7y ago
    I assume the focus is on big businesses and banks that can afford those numbers. Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.
- OskarS 7y ago
  I'm a little bit confused by the terminology here. What exactly is a "transaction", in a lower-level sense? What does it consist of? Is it pure CPU processing of one data structure to another? Is it shuffling things around in a (local? remote?) database? Is negotiating a transaction with another mainframe somewhere else over TCP? It matters, because otherwise any kind of performance number is meaningless. If it's just CPU processing, then 1.1 million is not that much. If it's doing some sort of network handshake/transaction with other mainframes, then it's VERY impressive.
  - fork1 7y ago
    You tend to have two types of processing done in a mainframe, batch and online. Transactions usually refer to online work. In the old times, it used to be someone connecting in 3270 and issuing a bunch of "transactions" to bring up screens and perform various operations. Now, it would likely involve a web layer. The server part can be CICS for example, but they are others. Think of them as application servers. Proper batch jobs tend to perform even faster. There is a few reasons to that, one of them is the full integration of the systems (ie: the batch has "shared" memory access to the database, basically it's a big stored procedure).
greglindahl 7y ago
The concept of a transaction predates software transactional memory. It's a database term going back to when databases were invented.

bin0 7y ago

Not in that sense, in the sense of "how many cart checkouts, wire transfers, other business logic transactions can I perform per unit x time?"

6thaccount2 7y ago

Like user bin0 said below, a mainframe can do 30k to 1.1M transactions like wire transfers in a second. They also have rediculously high up times and much higher security (probably mostly via obscurity). Unfortunately, they're insanely expensive.

hermitdev 7y ago
Probably more obscurity than actual security, in my experience. I once knocked off about 10k users off of a dev mainframe LPAR simply by running a SQL query (crashed DB2 and the underlying OS). With someone with more experience than I had, probably could have been exploitable. It was an accident, but it happened. Mainframes weren't nearly as rock solid as their reputation in the 3 years of dealing with them that I had. Mainframes were great at processes that need high IO. I've not dealt with them in close to 20 years, so dont know how current x64 linux or Windows stacks line up. Mainframes are hugely expensive. 20 years ago, entry level for the hardware was around $500k, IIRC. Dont think that even provided storage or software licenses. But, yeah, youve got one largely extremely reliable piece of big iron that can handle nearly all of your needs.
- 6thaccount2 7y ago
  I assume the focus is on big businesses and banks that can afford those numbers. Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.
OskarS 7y ago
I'm a little bit confused by the terminology here. What exactly is a "transaction", in a lower-level sense? What does it consist of? Is it pure CPU processing of one data structure to another? Is it shuffling things around in a (local? remote?) database? Is negotiating a transaction with another mainframe somewhere else over TCP? It matters, because otherwise any kind of performance number is meaningless. If it's just CPU processing, then 1.1 million is not that much. If it's doing some sort of network handshake/transaction with other mainframes, then it's VERY impressive.
- fork1 7y ago
  You tend to have two types of processing done in a mainframe, batch and online. Transactions usually refer to online work. In the old times, it used to be someone connecting in 3270 and issuing a bunch of "transactions" to bring up screens and perform various operations. Now, it would likely involve a web layer. The server part can be CICS for example, but they are others. Think of them as application servers. Proper batch jobs tend to perform even faster. There is a few reasons to that, one of them is the full integration of the systems (ie: the batch has "shared" memory access to the database, basically it's a big stored procedure).

greglindahl 7y ago

The concept of a transaction predates software transactional memory. It's a database term going back to when databases were invented.