- up to 141 configurable processors
- new 22nm 8-core processor chip@5GHZ
- 110GIPS
- Single Instruction Multiple Data (SIMD) support
- On chip cryptographic and compression coprocessors
- up to 10 TB of memory (configured as 'memory raid', RAIM)
PDF is here: http://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsd03035usen/...
> Single Instruction Multiple Data (SIMD), a vector processing model providing instruction level parallelism, to speed workloads such as analytics and mathematical modeling. For example, COBOL 5.2 and PL/I 4.5 exploit SIMD and improved floating point enhancements to deliver improved performance over and above that provided by the faster processor.
Most people would consider COBOL and PL/I to be laughably out of date languages from the 60s and 70s. But here's a new machine with 10 TB of RAM, and the release notes are quick to point out new features for COBOL and PL/I. Go figure.
Seriously, we have code whose originals can be traced to systems long dead. Yet code is not stagnate, full SQL integration exists for most language, there are many ways to get to the web. That and you would be surprised at the number of companies who use these machines simply for one reason above all, reliability. Our last crash was a site failure and even then we rolled to the DR site instantly.
Well they are. These things are built for a specific audience and it so happens that they are still willing to spend money on this, otherwise it wouldn't be made, especially not by IBM that is otherwise quick to disband business units that don't make heaps of money.
In my research I'm using an even older language: Fortran. Believe it or not, but in a field that is less narrow and specific than you would think[1], there's still no real replacement for (modern) Fortran.
[1] numeric applications that need to get close to the hardware's peak performance, written in a higher level language than C that is usable by non-CS-graduates.
PL/I is not totally out of date! E.g., it has some really sweetheart scope of names rules. The On Conditions are generally nicer than Try-Catch, e.g., if in a code block A and do a Goto out of it to a statement label in a containing code block B (it's fair to call PL/I a block structured language), then the stack of that task (in some ways nicer than just a thread) is rolled (popped as in popping a stack, which is essentially what happens) back to the context of the last time block B was active.
Block B can have a function F that inherits names defined in the blocks that contain B, and block B can call a function G, pass F as an entry variable, and function G can call it's parameter for function F, function F can execute and access all the variables it has access to that function G may not. That can be nice. I used it once when scheduling the fleet for FedEx.
Can have tasks, like threads. Can allocate some storage as, say, controlled. Then when the task ends, that allocated storage is freed. That can be nice -- nice way to stop memory leaks when have to kill a task.
PL/I has structures which replace much of the utility of classes. And the structures, with arrays of structures of arrays of structures of arrays, etc., are much faster than instances of classes because all the addressing is just a fairly nice generalization of simple old array addressing without pointers.
Such a structure can be based which means that can allocate one and get back a pointer to it. So, that is a lot like allocating an instance of a class. B can be part of a structure A, and B can be defined to be like structure C -- so, can get some inheritance.
The flat file I/O is much sweeter than what is in C and was brought over to, say, Visual Basic .NET or C#.
PL/I will convert nearly any data type to nearly any other, e.g., something like a cast in the C family of languages, but the documentation says in very full and fine detail just how each conversion is done.
There's a relatively powerful pre-processor macro language executed by the compiler that can be used to generate a lot of source code -- can be nice.
If they have tried to upgrade PL/I, say, to 64 bit addressing, maybe more on event handling, some collection classes, a sweet DB/2 or RDBMS interface (it always had some DB syntax and semantics in the language), then it could be a nice language even now.
It's been said that the golden age of language design was the 1960s. C was designed after PL/I and was a really big step down so that it could compile on a DEC mini-computer with 8 KB of main memory while PL/I always had at least 64 KB.
On VM/CMS and MVS, PL/I didn't have access to TCP/IP, but C did, so I wrote some C code callable from PL/I that gave PL/I access to TCP/IP. Used it a little! Maybe now TCP/IP is closer to being native to the language.
I was in the group at IBM's Watson lab that did the expert system shell KnowledgeTool that was implemented as a pre-processor to PL/I. One night I stayed up until dawn and coded the logic that made rule subroutines fast, functional, etc. The key was to keep a crucial part of our run time software and the user's rule subroutine on the stack of dynamic descendancy. Gee, I got an award! The hourly rate for that night was actually relatively good!
PL/I doesn't have to be so bad!
This parallel universe is called reality and you live in the matrix.
However, that's ignoring what's made a mainframe fast and expensive for the past several decades. Mainframes still slaughter all comers when it comes to I/O, and this is no different. When you've got up to 320 fibre links available, you're gonna have no problem keeping those processors busy.
Nowadays you don't create a single monolithic system, really expensive too, which is capable of processing all of your transactions, as it says, like 100 cybermondays every day.
Instead, you have a distributed system, with many cheap, geographically distributed servers, each one capable of a much lower number of transactions, but still quite high today... and also you can spin up new servers as needed, or destroy servers as they are no longer needed, so you control your costs when you don't need as much instead of having a very expensive mainframe 90% underutilized 90% of the time.
IBM is full of really smart people some of whom work on really hard problems using the principles of Computer science. The z13 wasn't the result of two recent grads pivoting a Yelp for Rabbits startup and the z13 isn't for companies hoping to do a billion transactions a day. It's for those doing it.
To say that the Google 'many-servers' approach is the only valid one is to overstate the trade-offs.
At a basic level this kind of sytem gives you lots of low latency bandwidth connecting CPUs to each other and CPUs to storage. That is a useful quality to have and not neccessarily easily repoducible using network and internet connections between servers and data centers.
A mainframe is typically partitioned into multiple, smaller systems. This is what IBM calls a Logical Partition (LPAR). This partitioning is done with firmware called PR/SM. This capability has been around since the 3090 (mid to late 80's). Within an LPAR, one typically installs either z/OS or z/VM (there are other systems too, but less commonly used this way). Running in an LPAR is 'bare metal'. Within z/VM, there's typically a mix of guest types, but this is where Linux would typically be configured to run. z/VM has some pretty impressive capabilities and has been around for a LONG time. It's very stable. The biggest things that you would probably dislike about it are: (1) one uses a 3270 emulator to do day-to-day system-level admin work, (2) it only runs (legally) on real mainframe hardware, and (3) much of IBM's jargon is dated and would unfamiliar to people coming from x86.
The modern mainframe hardware and software has an impressive feature set for virtualized networking (networking is all software defined and runs within the box). This means you can set up hundreds or thousands of Linux guests and have them on networks that are all virtualized within z/VM. And of course, z/VM guests can be created and spun-up on demand and stopped on-demand. This has been there for decades.
IBM now has support for OpenStack in z/VM. From what I've perused, it seems to be quite slick. Assuming it all works as advertised, this would make folks coming from x86 feel much more at home.
Many seem to think that distributed systems are so much cheaper. You can't just think of it as the price of the rack server though. You have to include everything in the mix to understand the total cost: hardware, software, networking, people (headcount and consulting), power and cooling, floorspace, and intangibles (such as capabilities). When you do the math, mainframes running Linux under z/VM are often fairly economical (YMMV).
Once you throw off the stereotypes and objectively dig into the modern mainframe, you might be surprised at what you find.
Because the other OSes which run on the hardware are so obscure that non-technies would never have heard of them. I'm morally certain CMS and z/OS (or whatever MVS is called these days) and VM are still in use, but Linux has the penguin and the media coverage. Therefore, it gets the inches.
If you want the best with insane price level, buy into Power/AIX. If you are not really sure, please don't. You need to train administrators (with larger setups) - or prepare to shell in a lot of money, the hardware contains nasty licensing surprises, the hardware is rather expensive, and so on. When you get it running, it's insanely powerful indeed, and the platform itself nearly never screws up (if you tested properly for Monday parts), and the virtualization is insanely good in practice.
Some potential customers have bought Power/AIX, some not. The ones that did are still years after customers, and to my knowledge pretty happy. I believe IBM is actually gaining customers. Slowly, but they are. Those that made the choice knew what they got into, and are not going to change their views.
I was talking to an ibmer a while ago and AIX was mentioned. We agreed the platform had technical merits, and on a pure platform level was superior to x32/x64 but the network effects of commodity hardware had already won the platform game. No one writes software for any other platforms but intel/amd64. AIX lost for the battle, similar to the reasons betamax lost to VHS.
IBM licensed the 286 for the IBM PC/AT. Acorn wanted to use the 286 for the Archimedes, but Intel would not allow licensing. This forced Acorn to create their own processor, resulting in the first RISC based consumer PC.
Perhaps that snowballs into our current tech environment.
Transaction Database --> copy --> analytics db = slow
In-memory transactions with built-in analytics = fast
My bank recently alerted me because I swiped my credit card at one gas station away from home but did not buy gas (the pump was out of gas) and then swiped again at another gas station in a 3mi radius within 30 minutes (obviously since I needed gas).
Their system picked up these two transactions, figured out they were both gas stations, geo-located them to be out of my area, calculated the distance to be close enough to reason it was just one person (and not my wife using her card elsewhere), and triggered an alert because the first transaction was really just a $1 pre-auth with no actual charge.
While none of this is really that complex if you built a fraud-detection system from ground up with these requirements, imagine running this rule on a few hundred million transactions per day. Now add in a thousand more fraud-detection rules, scoring algorithms, and pattern recognition for uncommon usage. Then hook it up to the mobile app to further reduce chances of fraudulent usage by tracking user's location, businesses silently checked-in, and alert preferences. IBM is targeting companies that need this.
So I am wondering why they use TPS as a unit when it can be anything.
One reason for industry standards is that they distribute risk across the whole industry. So if NIST crypto is broken the entire industry goes down together; one company wouldn't have a competitive disadvantage.
Or you know, any kind of transaction because there is no difference.
Fuck I hate marketing.