IBM Archive

Recently, popular Apple blogger John Gruber has been on a mission to explain why, exactly, tech companies like Apple don’t need any stricter government oversight or be subjected to stricter rules and regulations. He does so by pointing to technology companies that were once dominant, but have since fallen by the wayside a little bit. His most recent example is IBM, once dominant among computer users, but now a very different company, focused on enterprise, servers, and very high-end computing. Gruber’s argument: It wasn’t too long ago — 20, 25 years? — when a leadership story like this at IBM would have been all anyone in tech talked about for weeks to come. They’ve been diminished not because the government broke them up or curbed their behavior through regulations, but simply because they faded away. It is extremely difficult to become dominant in tech, but it’s just as difficult to stay dominant for longer than a short run. Setting aside the fact that having to dig 40 years into the past of the fast-changing technology industry to find an example of a company losing its dominance among general consumers and try to apply that to vastly different tech industry of today is highly questionable, IBM specifically is an exceptionally terrible example to begin with. I don’t think the average OSNews reader needs a history lesson when it comes to IBM, but for the sake of completeness – IBM developed the IBM Personal Computer in the early ’80s, and it became a massive success. Almost overnight, it became the personal computer, and with IBM opting for a relatively open architecture – especially compared to its competitors at the time – it was inevitable that clones would appear. The first few clones that came onto the market, however, ran into a problem. While IBM opted for an open architecture to foster other companies making software and add-in cards and peripherals, what they most certainly did not want was other companies making computers that were 100% compatible with the IBM Personal Computer. In order to make a 100% IBM compatible, you’d need to have IBM’s BIOS – and IBM wasn’t intent on licensing it to anyone. And so, the first clones that entered the market simply copied IBM’s BIOS hook, line, and sinker, or wrote a new BIOS using IBM’s incredibly detailed manual. Both methods were gross violations of IBM’s copyrights, and as such, IBM successfully sued them out of existence. So, if you want to make an IBM Personal Computer compatible computer, but you can’t use IBM’s own BIOS, and you can’t re-implement IBM’s BIOS using IBM’s detailed manual, what are your options? Well, it turns out there was an option, and the company to figure that out was Compaq. Compaq realised they needed to work around IBM’s copyrights, so they set up a “clean room”. Developers who had never seen IBM’s manuals, and who had never seen the BIOS code, studied how software written for the IBM PC worked, and from that, reverse-engineered a very compatible BIOS (about 95%). Since IBM wasn’t going to just hand over control over their platform that easily, they sued Compaq – and managed to find one among the 9000 copyrights IBM owned that Compaq violated (Compaq ended up buying said copyright from IBM). But IBM wasn’t done quite yet. They realised the clone makers were taking away valuable profits from IBM, and after their Compaq lawsuit largely failed to stop clone makers from clean-room reverse-engineering the BIOS, IBM decided to do something incredibly stupid: they developed an entirely new architecture that was entirely incompatible with the IBM PC: MCA, or the Microchannel Architecure, most famously used in IBM’s PS/2. In the short run, IBM sold a lot of MCA-based machines due to the company’s large market share and dominance, but customers weren’t exactly happy. Software written for MCA-based machines would not work on IBM PC machines, and vice versa; existing investment in IBM PC software and hardware became useless, and investing in MCA would mean leaving behind a large, established customer base. The real problem for IBM, however, came in the long run. Nine of the most prominent clone manufacturers realised the danger MCA could pose, and banded together to turn the IBM PC into a standard not controlled by IBM, the Extended Industry Standard Architecture (with IBM’s PC-AT of the IBM PC renamed to ISA), later superseded by Vesa Local Bus and PCI. Making MCA machines and hardware required paying hefty royalties to IBM, while making EISA/VLB/PCI machines was much cheaper, and didn’t tie you down to a single, large controlling competitor. In the end, we all know what happened – MCA lost out big time, and IBM lost control over the market it helped create entirely. The clone makers and their successful struggle to break it free from IBM’s control has arguably contributed more to the massive amounts of innovation, rapid expansion of the market, and popularity and affordability of computers than anything else in computing history. If the dice of history had come up differently, and IBM had managed to retain or regain control over the IBM PC platform, we would have missed out on one of the biggest computing explosions prior to the arrival of the modern smartphone. To circle back to the beginning of this article – using IBM’s fall from dominance in the market for consumer computers as proof that the market will take care of the abusive tech monopolists of today, at best betrays a deep lack of understanding of history, and at worst is an intentional attempt at misdirection to mislead readers. Yes, IBM lost out in the marketplace because its competitors managed to produce better, faster, and cheaper machines – but the sole reason this competition could even unfold in the first place is because IBM inadvertently lost the control it had over the market. And this illustrates exactly why the abusive tech giants of today need to be strictly controlled, regulated, and possibly even broken up. IBM could only dream of

How do you boot a computer from punch cards when the computer has no operating system and no ROM? To make things worse, this computer requires special metadata called “word marks” that can’t be represented on a card. In this blog post, I describe the interesting hardware and software techniques used in the vintage IBM 1401 computer to load software from a deck of punch cards. (Among other things, half of each card contains loader code that runs as each card is read.) I go through some IBM 1401 machine code in detail, which illustrates the strangeness of the 1401’s architecture and instruction set compared to a modern machine. I simply cannot imagine what wizardry these newfangled computers must’ve felt like to the people of the ’50s, when computers first started to truly cement themselves in the public consciousness. Even though they’ve been around for twice as long, I find a world without cars far, far easier to imagine and grasp than a world without computers.

For a lot of organizations that buy servers and create systems out of them, the overall throughput of each single machine is the most important performance metric they care about. But for a lot of IBM i shops and indeed even System z mainframe shops, the performance of a single core is the most important metric because most IBM i customers do not have very many cores at all. Some have only one, others have two, three, or four, and most do not have more than that although there are some very large Power Systems running IBM i. But that is on the order of thousands of customers against a base of 120,000 unique customers. We are, therefore, particularly interested in how the performance of the future Power10 processors will stack up against the prior generations of Power processors at the single core level. It is hard to figure this out with any precision, but in its presentation in August at the Hot Chips conference, Big Blue gave us some clues that help us make a pretty good estimate of where the Power10 socket performance will be and we can work backwards from there to get a sense of where the Power10 cores could end up in terms of the Commercial Performance Workload (CPW) benchmark ratings that IBM uses to gauge the relative performance of IBM i systems. ARM, RISC-V, POWERx – there’s definitely renewed interest in non-x86 architectures, and that makes me very, very happy.

The vast majority of PC users today have no memory of what PC keyboards looked like before the standard 101/102-key layout arrived, even though various OEMs do their best to mangle the standard layout in order to minimize usability, especially on laptops. OEM-specific modifications aside, the basic layout of the main block of alphanumeric keys has not changed in over 30 years, since 1986. However, up until that point the PC keyboard layout and the keyboard hardware changed quite a bit, and looking at the 1981-1986 IBM Technical References is key to understanding a) why the standard keyboard scan codes are so complex, and b) why there are so many seemingly odd vendor-specific modifications of the standard layout. With our modern operating systems and crazy fast processors, it’s easy to forget that the PC as a platform is almost 40 years old, and many of the PC standards we don’t even think of as standards have roots that date back that far – and the keyboard is no exception.

It has been a long time coming, and it might have been better if this had been done a decade ago. But with a big injection of open source spirit from its acquisition of Red Hat, IBM is finally taking the next step and open sourcing the instruction set architecture of its Power family of processors. Opening up architectures that have fallen out of favour seems to be all the rage these days. Good news, of course, but a tad late.

The IBM System/360 was a groundbreaking family of mainframe computers announced on April 7, 1964. Designing the System/360 was an extremely risky “bet-the-company” project for IBM, costing over $5 billion. Although the project ran into severe problems, especially with the software, it was a huge success, one of the top three business accomplishments of all time. System/360 set the direction of the computer industry for decades and popularized features such as the byte, 32-bit words, microcode, and standardized interfaces. The S/360 architecture was so successful that it is still supported by IBM’s latest z/Architecture mainframes, 55 years later. Although the S/360 models shared a common architecture, internally they were completely different to support the wide range of cost and performance levels. Low-end models used simple hardware and an 8-bit datapath while advanced models used features such as wide datapaths, fast semiconductor registers, out-of-order instruction execution, and caches. These differences were reflected in the distinctive front panels of these computers, covered with lights and switches. This article describes the various S/360 models and how to identify them from the front panels. I’ll start with the Model 30, a popular low-end system, and then go through the remaining models in order. Conveniently IBM assigned model numbers rationally, with the size and performance increasing with the model number, from the stripped-down but popular Model 20 to the high-performance Model 195. This is an incredibly detailed article on this – relatively speaking – arcane topic, filled with beautiful photography. A delight to read.