[HN Gopher] On the strange joys of mainframe OSes that have surv...
___________________________________________________________________
On the strange joys of mainframe OSes that have survived into
modern times
Author : todsacerdoti
Score : 102 points
Date : 2022-09-25 07:57 UTC (15 hours ago)
(HTM) web link (liam-on-linux.dreamwidth.org)
(TXT) w3m dump (liam-on-linux.dreamwidth.org)
| rahen wrote:
| > All modern computers are microcomputers
|
| I'm not sure if an IBM i system would really qualify this way,
| it's mini software running on downscaled mainframe hardware.
|
| IBM i is probably the last mini out there, it will feel
| completely alien to someone coming from the microcomputer world
| (say, *nix and Windows, x86 and ARM).
| trasz wrote:
| "Mini" is just a marketing name at this point. The "i" is just
| a POWER machine - a micro - running a weird operating system.
| rahen wrote:
| It's not even marketing since IBM doesn't use this
| terminology.
|
| But i is still quite removed from the micro standards: POWER,
| EBCDIC, COBOL, RPG, 5250 terminals, and the SLIC/TIMI/LPAR
| abstractions.
|
| The typical "micro" app would use x86, UTF-8,
| Java/C++/Rust/Go on top of a general public system like
| Linux.
|
| Well at least both use 8 bits words, it hasn't always been
| the case.
| lproven wrote:
| [Article author here]
|
| It's not really, you know.
|
| IBM i is very interesting: the last mainstream single-level
| store system. This is a concept I've both talked and written
| about in recent years -- examples here on HN:
|
| https://news.ycombinator.com/item?id=26066762
| https://news.ycombinator.com/item?id=32314814
|
| Saying that, I've done very very little work on the system. One
| job ever, really, 20Y ago.
|
| But IBM i is OS/400, yes, a minicomputer OS, yes -- but running
| on IBM P series, i.e. a POWER server, i.e. a modern RS/6000.
| It's a RISC workstation. Not even slightly mainframe-like.
|
| Other minicomputer _OSes_ survive, notably VMS, now on x86-64.
|
| https://www.theregister.com/2022/05/10/openvms_92/ <- Another
| of my stories, just so you know where I stand.
|
| So, yes, mini _OSes_ survive, sure, but not really any mini
| _hardware_. Arguably as minicomputers died out they evolved
| into workstations, and those have now died out, too. 99.99% of
| the workstation market is basically high-end PCs now, if we
| count modern Macs as sort of honourary PCs. (Arm Macs are in
| some ways more like desktop /laptop-shaped iPads, really.)
| phoehne wrote:
| In order to disagree or agree with your statement I would
| need some working definition of mini, micro, and mainframe.
| lproven wrote:
| Mainframes: the first style of computer. Primarily designed
| as a batch-oriented system, meaning that they are not
| directly interactive. Jobs are queued up, run without
| interaction, results stored, and then the next job
| processed. Later models added interactivity as a secondary
| feature, usually like most mainframe I/O handled by
| intelligent peripherals which in effect are networked to
| the main processors. So, the terminal, on its own, shows a
| form and then handles all user input as the user completes
| the form, without communicating with the host at all. Then,
| when the user signals that the form is complete, the entire
| contents, maybe many pages, are sent as a single message to
| the host.
|
| Separate processors in storage, in terminals, in networking
| controllers, in printers, in everything. Typically the
| machine cannot actually drive any output or input directly
| (e.g. mouse movements, or keystrokes, or anything):
| peripherals do that, collect and encode the results, and
| send them over a network. So as someone else commented, a
| mainframe isn't really _a_ computer, it 's a whole cluster
| of closely-coupled computers, many with dedicated
| functionality. Quite possibly all implemented with
| different architectures, instruction sets, programming
| languages, bit widths, everything.
|
| Here's an article I wrote about a decade back about how IBM
| added the new facility of "time sharing" -- i.e. multiple
| users on terminals, all interacting with the host at the
| same time -- by developing the first hypervisor and running
| 1 OS per user in VMs, because the IBM OSes of the time
| simply could not handle concepts like "terminal sessions".
|
| https://www.theregister.com/Print/2011/07/14/brief_history_
| o...
|
| Minicomputer: the 2nd main style of computer. Smaller,
| cheaper, so affordable for a company department to own one,
| while mainframes were and are mostly leased to whole
| corporations. Typically 1 CPU in early ones, implemented as
| a whole card cage full of multiple boards: maybe a few
| boards with registers, one with an adder, etc. The "CPU" is
| a cabinet with thousands of chips in it.
|
| Hallmarks: large size; inherently multitasking, so that
| multiple users can share the machine, accessing it via dumb
| terminals on serial lines. User presses a key, the
| keystroke is sent over the wire, the host displays it.
| Little to no networking. One processor, maybe several disk
| or tape drives, also dumb and controlled by the CPU. No
| display on the host. No keyboard or other user input on the
| host. All interaction is via terminals. But because they
| were multiuser, even the early primitive ones had fairly
| smart OSes which could handle multiple user accounts and so
| on.
|
| Gradually acquired networking and so on, but later.
|
| In some classic designs, like some DEC PDPs, adding new
| hardware actually adds new instructions to the processor's
| instruction set.
|
| Wildly variable and diverse architectures. Word lengths of
| 8 bit, 9 bit, 12 bit, 18 bit, 24 bit, 32 bit, 36 bit and
| others. Manufacturers often had multiple incompatible
| ranges and maybe several different OSes per model range,
| depending on the task wanted, so offering dozens of totally
| different and incompatible OSes across half a dozen models.
|
| Microcomputer: the simplest category. The entire processor
| is implemented on a single silicon chip, a microprocessor.
| Early machines very small and simple, driven by 1 terminal
| with 1 user. No multitasking, no file or other resource
| sharing, no networking, no communications except typically
| 1 terminal and maybe a printer. Instead of 1 computer per
| department, 1 computer per person. Facilities added by
| standardised expansion cards.
|
| This is the era of standardisation and commoditisation. Due
| largely to microcomputers, things like the size of bytes,
| their encoding and so on were fixed. 8 bits to a byte,
| ASCII coding, etc.
|
| Gradually grew larger: 16-bit, then 32-bit, etc. In the
| early '80s gained onboard ROM typically with a BASIC
| interpreter, on-board graphics and later sound. Mid-'80s,
| went to 16-bit with multicolour graphics (256+ colours),
| stereo sound. Lots of incompatible designs, but usually 1
| OS per company, used for everything. All single-user boxes.
|
| These outperformed most minis and minis died out. Some
| minis gained a hi-res graphical display and turned into
| single-user deskside "workstations", keeping their
| multitasking OS, usually a UNIX by this point. Prices
| remained at an order of magnitude more than PCs, and
| processors were proprietary, closely-guarded secrets, and
| sometimes still implemented across multiple discrete chips.
| Gradually these got integrated into single chip devices but
| they usually weren't very performance competitive and got
| displaced by RISC processors, built to run compiled C
| quickly.
|
| In the '90s, generalising wildly, networking became common,
| and 32-bit designs became affordable. Most of the 16-bit
| machines died out and the industry standardised on MS
| Windows and classic MacOS. As internet connections became
| common in the late '90s, multitasking and a GUI were
| expected along with multimedia support.
|
| Apple bought NeXT, abandoned its proprietary OS and
| switched to a UNIX.
|
| Microsoft headhunted DEC's team from the cancelled MICA
| project, merged it with the Portable OS/2 project, and got
| them to finish OS/2 NT, later Windows NT, on the N-Ten CPU,
| the Intel i860, a RISC chip, then on MIPS, and later on
| x86-32 and other CPUs. This was the first credible
| commercial microcomputer OS that could be both a client and
| a server, and ultimately killed off all the proprietary
| dedicated-server OSes, of which the biggest was Novell
| Netware.
|
| That is a vastly overlong answer but it's late and I'm just
| braindumping.
|
| Mainframe: big tightly-clustered bunch of smart devices,
| flying in close formation. Primary role, batch driven
| computing, non-interactive; interactivity bolted on later.
|
| Mini: departmental shared computer with dumb terminals and
| dumb peripherals, interactive and multitasking from the
| start. Most text-only, with interactive command-line
| interfaces -- "shells" -- and multiprogramming or
| multitasking OSes. Few had batch capabilities; no graphics,
| no direct I/O, maybe rare graphical terminals for niche
| uses. Origins of the systems that inspired CP/M, MS-DOS,
| VMS, UNIX, and NT.
|
| Micro: single-chip CPU, single-user machines, often with
| graphics and sound early on. Later gained GUIs, then later
| than that networking, and evolved to be servers as well.
|
| If the machine can control and be controlled by a screen
| and keyboard plugged into the CPU, it's a micro. If its CPU
| family has always been a single chip from the start, it's a
| micro. If it boots into some kind of firmware OS loader,
| it's probably a micro. The lines between micros and UNIX
| workstations are a bit blurred.
|
| I'm not sure this is helping any more. I'll shut up.
| phoehne wrote:
| That helps. I don't necessarily agree, but it's
| definitely interesting!
| __d wrote:
| If you squint a bit, you can view Web-1.0-era UIs as
| being a bit like a 3270: the terminal downloads the
| template, the user fills out the fields, and hits the
| submit button. That creates a HTTP POST, which is kinda
| like a CICS transaction.
|
| This enables the central CPU running the application
| server to ignore all the terminal I/O issues, and just
| deal with a set of transactions implementing the
| application logic. If the load-balancer and HTTP server
| are separate machines, then at a high-level boxes-and-
| lines level, it's not a long way from a mainframe
| application architecture (at the front end, anyway).
|
| But this isn't really accurate, and it's become less
| superficially similar with more recent web trends where
| the REST layer isn't a hard boundary, and pre-rendering
| and so on have muddied the model again.
| __d wrote:
| I think those definitions are somewhat complicated, because
| micro-computer architectures have gradually adopted
| features (perhaps in reduced form) from their mini-computer
| and mainframe counterparts.
|
| So, mainframes have channel controllers, and micro-
| computers don't. But a modern micro-computer Ethernet
| driver might run some software on the NIC. It's not really
| a channel and yet the architectural distinction is blurred.
|
| The distinctions made more sense in the 80's, when the
| lines were clearer.
|
| But I think the point is valid: the micro-computer
| architecture has taken over the industry, and _some_ things
| of value have been lost.
| __d wrote:
| Similarly, the "bus" of a micro-computer started out as a
| pretty simple thing: parallel, 8 bits of data, 16 bits of
| address, with memory-mapped or I/O-mapped fixed-function
| peripherals managed by the (single) CPU. Memory and I/O
| devices on the same bus.
|
| But the modern PCIe "bus" is really more of a packet-
| switched network. Memory is now separate (although, see
| CXL). Devices on that network can talk directly to each
| other, or to the CPU. In some ways, this is closer to a
| mainframe architecture.
| rahen wrote:
| It absolutely is. IBM started to bring mainframe features
| to the PC architecture with its PS2 line. The PS2
| microchannel architecture (MCA), in particular, was
| inspired by the 360 and became itself the inspiration for
| the PCI bus.
| rahen wrote:
| - You lose a screw inside: microcomputer
|
| - You lose a screwdriver inside: minicomputer
|
| - You lose a technician inside: mainframe
|
| When you bring a new addition to your personal collection:
|
| - your wife complains: microcomputer
|
| - Your wife yells at you: minicomputer
|
| - Your wife leaves you: mainframe
| hatsuseno wrote:
| In jest I'll also assume the author could write a similar article
| lamenting what storage tech could have been, but instead everyone
| with data that mattered took the maintenance hit with RAID and
| called it a day.
|
| Commoditization is, to me, just a natural effect of product
| development in a free market, capitalist(-ish) society. It feels
| to me that as long as much of the population is chasing
| financially optimal outcomes this will continue to happen, and
| that may be okay.
| thriftwy wrote:
| I'm pretty sure nothing serious runs in mainframes outside of US
| and maybe EU.
|
| They have all that infrastructure like banks and planes and it
| looks quite modern and resilient.
| __d wrote:
| Japan? NEC, Hitachi, and Fujitsu all used to make mainframes.
|
| Hitachi has merged their line with IBM z-Series, but I think
| it's still for sale? Fujitsu still sells several lines, and NEC
| still sells in Japan.
|
| I suspect their customers are pretty similar though: banks and
| airlines.
| wokkel wrote:
| Unless understand your comment wrong: most older EU banks run
| their core on mainframe. Sure the webapp to see your account is
| running on some websphere/j2ee or nowadays maybe even angular
| server. But that's just a gateway to the real accounting system
| on the mainframe.
| thriftwy wrote:
| What about banks outside US/EU?
| rbanffy wrote:
| Brazilian banks and parts of the government were pretty big
| mainframe clients. I'm most familiar with the IBM ones, but
| Unisys also had quite a footprint with their A series
| (which evolved into the Clearpath Libra family).
| jasode wrote:
| _> I read this wonderful article on mainframe OSes._
|
| As irony, the url link points to an article mentioning the Unisys
| mainframe. Unisys later switched to running on commodity x86
| servers with a Unisys emulation on top:
| https://www.google.com/search?q=unisys+clearpath+shift+xeon
|
| _> , and that you don't need all the fancy scaling
| infrastructure because one modern box [mainframe] can support a
| million concurrent users no problem, and a few such boxes can
| support tens of hundreds of millions of them, all in something in
| the corner of one room, with an uptime of decades and no need for
| any cloud. But it's hard to do it that way, _
|
| The author proposes that "mainframes-are-superior" by vague
| generalizations and no performance data.
|
| As a case study, consider that the Sabre travel reservations was
| the _first IBM mainframe commercial customer_ since 1960. With 6
| decades of experience with IBM 360 and Z upgrades, they 'd know
| more about running mission-critical performance workloads on
| mainframes than just about anyone.
|
| And yet, they've been _migrating off of mainframes_ to AWS +
| Azure + Google cloud :
| https://www.google.com/search?q=sabre+migration+multi-cloud+...
|
| To think of the opposite case from Sabre, let's consider a new YC
| startup today with no legacy IT systems. Thinking from first
| principles (i.e. raw math of cpu & io performance & costs on an
| Excel spreadsheet), what situation makes sense to build the
| solution on an a new IBM z16 mainframe instead of cloud?
|
| If one is an old bank already running an older IBM z14 or z15
| mainframe and wants the next iteration of performance
| improvements, a z16 upgrade is the simplest so probably makes the
| most financial sense. But without a "legacy IT" constraint,
| what's the compelling spreadsheet model for a YC company to
| choose a mainframe?
| neverartful wrote:
| "But without a "legacy IT" constraint, what's the compelling
| spreadsheet model for a YC company to choose a mainframe?"
|
| The most compelling reasons for the mainframe, based on its
| intrinsic values, are 'RAS' (reliability, availability,
| serviceability). However, those virtues come with a very high
| price tag. So far the most part, I cannot imagine any startup
| business choosing one (UNLESS system downtime will kill the
| business).
| derefr wrote:
| Plus, you can squeeze out those same RAS factors from a
| cluster of commodity x86 boxen, at the software level, if
| your devs are willing to learn a little Erlang.
| rbanffy wrote:
| > Unisys later switched to running on commodity x86 servers
|
| It runs the same OS on an emulation layer. Not sure they do it,
| but you can get zero downtime out of multiple x86 boxes with a
| number of interesting tricks while pretending you are on a
| single CPU
| derefr wrote:
| > raw math of cpu & io performance & costs on an Excel
| spreadsheet
|
| But that's not the raw math; the raw math is "total OpEx", and
| OpEx for these large systems is increasingly dominated not by
| the systems themselves, but rather by development-talent
| acquisition costs, and operational-maintenance talent labor
| costs.
|
| Even Sabre's choice wasn't "upgrade to z16 vs. move to IaaS";
| it was "hire people to replace churned devs+ops to write the
| next feature of the system: people with z/OS experience, or
| people with IaaS experience?"
| dangus wrote:
| Also, supporting a lot of concurrent users is easier when the
| capabilities of the services being offered are very basic.
|
| Banks weren't doing things like providing millions of customers
| instant OCR processing of checks in the mainframe days.
| mhh__ wrote:
| Migrating away from mainframes can also be just because of
| talent availability but also lock in.
|
| Where I work we have processes that would make perfect sense
| chucking jobs at a mainframe (if we implement our language on
| it...), but IBM have no competition so it's super risky.
| reaperducer wrote:
| I'd like to see an article about the joys of mainframe operating
| systems that _didn 't_ survive.
|
| I cut my teeth on a PR1MEOS machine at SUNY New Paltz. Great
| system. But there is no modern emulator and almost zero
| information about it on the internet.
| trasz wrote:
| There is a reason why there are no proper benchmark results for
| mainframes available, and why the EULA prohibits publishing them.
| neverartful wrote:
| Back when IBM changed the branding on their hardware lines, it
| was done to help people identify WHY you would pick one
| platform versus another. z (mainframe) =
| "Zero downtime" i (as/400) = "integrated" (e.g., DB2
| and stuff like processing queues is baked into the OS)
| p (rs/6000) = "performance" x (x86) = was sold off to
| Lenovo after a few years
|
| See the "p"? If you need maximum performance, you go with POWER
| and run AIX or Linux.
| 13of40 wrote:
| "minimum viable product"
|
| I've heard a few folks use this term disparagingly lately, and I
| just want to point out that the spirit of an MVP isn't that you
| do the bare minimum required to huck your product to an
| unsuspecting customer. The point of an MVP is that every
| milestone you deliver something that's actually useful and
| functional in some way, end-to-end. The alternative to an MVP is
| a junk mock-up with all of the technical debt swept under the rug
| and the devs whistling and looking the other way when questions
| start coming out.
|
| Also, I loved the article.
| NonNefarious wrote:
| Into "mo?"
|
| Whatever that is.
|
| Buried.
| KolmogorovComp wrote:
| Modern times
| bhauer wrote:
| > _A handful of grumpy old gits know that if you pick the right
| languages, and the right tools, you can build something to
| replace this 2nd level system in the same types of tools as the
| first level system, and that you don't need all the fancy scaling
| infrastructure because one modern box can support a million
| concurrent users no problem, and a few such boxes can support
| tens of hundreds of millions of them, all in something in the
| corner of one room, with an uptime of decades and no need for any
| cloud._
|
| I suppose I am a grumpy old git, then, although I did not think
| of myself that way until recently. In the past decade or two,
| I've seen computer science lose its collective appreciation of
| the staggering potential of hardware. This has steadily resulted
| in software being built with tremendously over-engineered, hyper-
| complicated, cloud-first architectures that barely match the
| throughput of a single box running a high-performance platform
| (and for the record, "high performance" can still be relatively
| ergonomic via Java, C#, Rust, and so on).
|
| The scale of hardware, clock cycles, bits per second of
| bandwidth, etc., being squandered on modern cloud-first highly
| complicated architectures boggles the mind.
|
| I fear there is no strength behind any pendulum swing back to
| architectural simplicity, appreciation of the available capacity
| of hardware and how to use it, and local-first.
| phoehne wrote:
| I think that's changing. You're seeing more companies investing
| more in custom silicon. Like Microsoft, Amazon, and Google all
| make custom silicon to support their cloud efforts. That's
| expected to increase over time. Apple has shown that if you
| don't settle for BOG standard hardware you get better than BOG
| standard performance.
| fock wrote:
| > I fear there is no strength behind any pendulum swing back to
| architectural simplicity, appreciation of the available
| capacity of hardware and how to use it, and local-first.
|
| I'm pretty sure, the ecological devastation we are living will
| raze these things. If we are lucky we can salvage a bit. And
| the whole industry of the last 20years isn't worth saving.
| Eleison23 wrote:
| Cloud services and hyperscale data centers are arguably modern
| mainframe-class systems. If you look at them from the perspective
| of the provider, they have a lot of mainframe type features that
| distinguish them from micros or supercomputers.
|
| In the 70s, VM/CMS dominated the time-sharing landscape, and
| everything old is new again.
| qaq wrote:
| Reliability is nowhere near mainframe
| froh wrote:
| yup. error detection in the CPU (Alu, Decoder, etc) traps
| into the hypervisor which fires up a spare core, transfers
| the registers over to it and calls the technician.
|
| technician calls you to tell you "your machine needs
| maintenance"
|
| and at application level there was a short "mouse hang"
| latency for this hardware failure.
|
| and of course that works cross-site, too, hot moving running
| software across data centres at the hypervisor level, because
| you want one data centre downtown, one at the airport.
|
| but it's not just for finance. some mainframe customers have
| virtualized thousands of "your personal domain and web server
| running php/perl/nodejs" on a single physical machine which
| shares a r/o mounted /usr, in ram, transparently.
|
| customer X needs more ram? click click life assign more ram.
| needs more cpu? activate another core. the Linux
| virtualization Features to support hit cpu and ram swap were
| driven by the mainframe guys from IBM, years ago.
| delusional wrote:
| It sounds very impressive until the entire mainframe wont
| boot up after a simple routine upgrade as happened recently
| at my place of work.
| yourapostasy wrote:
| That's more of a training / staffing issue than a tech
| stack issue. I've seen similar outages at my clients in
| distributed systems. A lot of mainframe staff has been
| outsourced / offshored and those providers suffer
| constant turnover because the money and job prospects in
| distributed systems is generally better.
|
| Mainframe jobs pay well at the very apex of skills, but
| if you're coming up through the ranks in an outsource
| provider you're a cost not profit center. The
| compensation package and work life balance are good if
| you are with a company that keeps everyone in house,
| trains in house, have a deep bench of expertise who
| maintain the systems in an orderly fashion, and have a
| continuous succession plan for staff. Super low drama,
| and they keep the financial lights on in the house by
| processing the bulk of profit-generators' needs. These
| tend to be in places like stodgy COBOL shops the Cool
| Kids would rather gnaw their feet off to avoid, though.
|
| The part many people miss when comparing mainframes and
| distributed is you get all that mainframe magic with the
| application programmers accommodating the architecture
| little if at all. But your system programmers (system
| admins in Linux) have to be top tier.
|
| You can accomplish most if not all of that same magic in
| distributed architectures with parallelizable workloads.
| But your application and devops staff have to be top
| tier.
| delusional wrote:
| > That's more of a training / staffing issue than a tech
| stack issue.
|
| I mean sure, but the same could be said for distributed
| systems. What breeds reliability is qualified personnel
| working on a system that they understand. Slapping an IBM
| logo on the front doesn't make something more reliable,
| and stacking proprietary technology that "transparently"
| moves subsystems between datacenters only increases the
| training burden.
|
| Mainframes became a victim of their own moat. While
| proprietary _._ magic _._ can hold people in, those very
| same technologies also keep new people out.
| qaq wrote:
| It sounds impressive until a whole region or whole cloud
| goes down because of bug in the control plane.
| lmz wrote:
| > some mainframe customers have virtualized thousands of
| "your personal domain and web server running
| php/perl/nodejs" on a single physical machine which shares
| a r/o mounted /usr, in ram, transparently.
|
| For general public use? Can you name one?
| froh wrote:
| yes for general public use
|
| page 15 in this white paper from 2012 is the closest I
| can go in terms of naming. there were more , in
| continental Europe.
|
| https://www.slideshare.net/hcl/effective-web-
| hostingonzlinux...
| Spooky23 wrote:
| IBM was paying them to do it. The problem is you're
| running in a separate set of processors... it's almost
| like a blade chassis at this point. The cost structure
| didn't work as if you're doing anything significant
| you're going to end up licensing more CPU time (yes, you
| need to buy access to the stuff you bought), and it
| cheaper to buy x86 and run Linux OR just rent VMs from
| Amazon.
|
| I had to do a POC of this for an IBM app in 2008-9, as it
| was seen as a way to save on IBM software licensing. I
| killed the notion after spending 6 months getting stuff
| to work (ie the IBM boys and inwere the first idiots to
| try) when i borrowed from surplus PCs awaiting shredding
| and replicated the entire environment on 6 circa 2005
| pentium whatever desktops (which I did during the week
| between Christmas and New Years). My little lab
| outperformed the mainframe by a factor of 5 for the task.
|
| If these solutions were sold commercially, there must
| have been some German compliance requirement that led
| people to do it. Nobody would ever do this without
| getting directly compensated for "choosing" to do so.
| froh wrote:
| what works financially is providing a fleet of simple
| similar independent machines.
|
| think "your personal wordpress instance w/ own email and
| ftp server", centrally maintained, identical baseline but
| individual content.
|
| to this day Linux KVM does not enable multi tenancy. with
| z/VM you can provide that, and you still have the shared
| /usr in physically shared ram in z/vm.
|
| the physical CPUs are also virtualized and shared, each
| "full own wordpress server" only needs slivers of that
| cpu pool.
|
| it was done and it qorkwd. and it was profitable for both
| the hosters and IBM.
| greggsy wrote:
| > some mainframe customers have virtualized thousands of
| "your personal domain and web server running
| php/perl/nodejs"
|
| Are there hosting providers offering this type of service?
| rwmj wrote:
| IBM Cloud offers Z systems:
| https://www.ibm.com/community/z-and-cloud/ I imagine
| they're absurdly expensive like the real hardware.
| retcore wrote:
| Only available for existing Z/OS sites via your
| organization rep.
| froh wrote:
| that was around 2010/2012, eg page 15 here
|
| https://www.slideshare.net/hcl/effective-web-
| hostingonzlinux...
|
| however virtualization on arm and Intel has meanwhile
| matured enough to replace that business model.
| bionsystem wrote:
| What would prevent, in your opinion, to make some changes
| to current commodity hardware architectures (say, x64,
| arm...) to allow for mainframe-like scalability and
| reliability ?
|
| As per the article, how is the jitted/interpreted world of
| languages so bad ?
| bayindirh wrote:
| I'd say cost (of research, implementation and resulting
| product ).
|
| The additional hardware both in silicon and on PCB is
| massive to enable these kinds of reliability numbers. I
| played with some higher end HP servers back in the day,
| which allowed hot-swapping RAM carriers to maximize
| uptime. The construction on mechanical, electrical and
| software was much more sophisticated to enable these
| features. Which made the systems bigger, somewhat noisier
| and harder to maintain in a sense.
|
| When everybody is moving towards more cattle-like
| systems, and the behemoths like HPC doesn't care about
| reliability in the worker nodes (we just re-schedule the
| job, no biggie), that kind of reliability is not wanted
| by the people, in most sectors, and this low demand
| doesn't make the capabilities worthy to pursue.
|
| Also, there are system dynamics which affect operations
| profoundly. Your normal server boots in 5 minutes tops
| from power to "all services are ready to serve". Your run
| off the mill SMP server needs 15 minutes. A mainframe is
| never expected to be shut down, and if it's ever turned
| off, it's at least an hour required to spin that thing
| back up.
|
| We're talking about machines which have small "guns"
| inside to physically sever power lines in an emergency
| (sorry I can't find the story I've read about moving a
| datacenter hence turning of the IBM mainframes, however a
| related reference can be found at [0]).
|
| The JIT/Interpreted languages of the day were really bad.
| Java was heavy, other languages were slow. Today's
| JIT/Interpreted languages are fast enough, because the
| VMs running these have been optimized heavily, and the
| processors allows these VMs to run at much faster speeds
| because of available instructions, available memory and
| system interconnect speed at every level and interface.
| So the evolution of JIT and interpreted languages is a
| matter of chicken and egg. Hardware enabled both faster
| speeds and technology to write better VMs and optimize
| them further.
|
| [0]: http://www.catb.org/jargon/html/B/Big-Red-
| Switch.html
| ianai wrote:
| ECC bring the norm and better error handling all around.
| OSes that better handle memory and uptime. Possibly
| something like a user session being accessible from
| allowed terminals and applications that call for that.
| Think hotel front desk staff or anyone public facing who
| move from desk to desk.
| neverartful wrote:
| There's far more to reliability than ECC. What if a
| processor/CPU goes bad in an x86 server while running?
| You have to take the server down, replace it, and bring
| it back up. IBM mainframes allow for processor
| replacements while it's running. I think it's the same
| with memory. IIRC, in the mainframe world IBM has
| processor and RAM packaged together as a 'book' and it
| may be the book that can be hot swapped. Hopefully
| someone more knowledgable can clarify.
| rbanffy wrote:
| A mainframe reminds me more of a cluster of specialised
| machines networked over ridiculously fast interconnects
| and purpose-specific networks that host those specialised
| machines.
|
| Some functionality of those specialised machines is
| exposed to user programs that can delegate some
| processing to these smart peripherals, offloading things
| like allocating blocks in the filesystem and letting the
| boxes that run your used code focus on running it without
| ever being disturbed with servicing network or disk
| interrupts.
| User23 wrote:
| That ECC isn't entirely standard is shameful.
| froh wrote:
| patents, tongue in cheek...
|
| on a more serious note yagni: for most workloads you
| simply don't need the dependability and Xeon has caught
| up sufficiently for most workloads.
|
| however if your business depends on less than 5 minutes
| of unplanned downtime per year you need stacks designed
| for faul operational subsystems, i.e. subsystems which
| don't just detect faults and halt, but which gracefully
| handle many faults with a short degradation but no
| failure.
|
| and that's not only hard to master it's also plastered
| with IBM patents.
|
| wrt the jit/interpreted world my personal take is that
| silicon vendors are very happy about it. very few
| organisations feel the pain to an extent they innovate
| things like golang... and once they are in the business
| of selling compute power (as cloud service provider),
| there goes their motivation to create a sexy cobol.
| Macha wrote:
| > but it's not just for finance. some mainframe customers
| have virtualized thousands of "your personal domain and web
| server running php/perl/nodejs
|
| To be fair, shared hosting providers did this on x86 server
| machines on a scale of 100s of customers in the 90s, and
| I'm sure a modern revival on 2022 could do 1000s also
| marcus0x62 wrote:
| Sure, but they way we did that back in the 90's was very
| different, and carried a much lower overhead than LPARs
| in the IBM mainframe world or any hypervisor or container
| used today -- shared hosting "virtualization" in the 90's
| was little more than chroot jails, and frequently not
| even that.
| neverartful wrote:
| I think you're confusing LPARS with guests under z/VM. A
| mainframe LPAR is a coarse-grained (relatively speaking)
| partitioning of the system. LPARS are created and managed
| by a Hardware Management Console (HMC), and run on PR/SM
| [0]. No one creates mainframe LPARS to run a VPS. Those
| would simply be a guest under z/VM. Realistically
| speaking, z/VM would be running in an LPAR (less than the
| whole of the mainframe resources) and then within z/VM's
| LPAR, z/VM hypervisor allows all of its guests to run
| concurrently.
|
| [0] https://wiki.alquds.edu/?query=PR/SM
| marcus0x62 wrote:
| >> ... or any hypervisor or container used today ...
|
| > I think you're confusing LPARS with guests under z/VM.
|
| I am not, but thanks.
| rbanffy wrote:
| KVM is also available now in addition to z/VM. The IBM
| cloud "trusted environments" run on it.
| bayindirh wrote:
| We have a 10 machine Proxmox cluster at the office, and
| no. It doesn't lend itself to such capacities.
|
| Maybe we over-provision systems, and can fit that number
| of VMs, but what will be the performance?
|
| You can use a proper SMP machine with 16 sockets, but you
| are already at half mainframe price and journey-wise, and
| you'll be wasting the machine's capabilities.
| bayindirh wrote:
| Just no. They are very large herds of cattle systems, which act
| like as a big pet system, because it tolerates small blows.
|
| A mainframe is a single pet, which can live undisturbed even
| with moderate size blows, and can host a sizable herd of cattle
| systems without even noticing on the load monitor.
| jimkoen wrote:
| Every time I hear someone advocating for mainframes, they always
| praise them and make them appear as something like a computing
| behemoth, that, while expensive outperforms any commoditiy
| hardware at the tasks it's good at, wether it's in performance or
| reliability.
|
| But there's never any real world use case. It's always just "If
| you're running a mainframe, you don't care about money". No
| performance benchmarks, no architecture comparisons. You get
| shown an architecture diagram of a mainframe, next to one of say,
| a cloud system and you get asked "See??", like the conclusion is
| obvious.
|
| > Instead, we got lowest-common-denominator systems. Not what was
| best, merely what was cheapest, easiest, and just barely good
| enough - the "minimum viable product" that an industry of
| shysters and con-men think is a good thing.
|
| How is this _not_ a good thing??
|
| >But mainframes aren't. They cost a lot, and rental and licensing
| costs a lot, and running them costs a lot... everything costs a
| lot. Meaning you don't use them if you care about costs that
| much. You have other reasons. What those are doesn't matter so
| much.
|
| ...which is exactly my point! Yeah it makes sense that there is a
| separate ecosystem for mainframes! Because from the outside and
| these kind of arguments it looks like IBM has been siphoning off
| some great marketing in the 80s and 90s and _really_ ignorant
| managers in charge of purchasing at large banks and the US gov.
|
| On an unrelated note, I kinda made the experience that people
| that like mainframes usually have some weird obsession with high
| level computing architectures. Is there maybe a correlation?
| mhh__ wrote:
| Mainframes are supposed to be good at the type of jobs that you
| can't really do an apples to apples comparison of - they're not
| supposed to be running linear algebra benchmarks, however
| equally a lot of quasi-distributed systems (some cloud infra or
| whatever) performance will completely collapse when you try to
| scale them beyond little benchmarks.
|
| I've read IBMs docs on their processor architectures, I'm sure
| they're fast _enough_ but no more than that.
|
| Wouldn't choose one for infrastructure but would love to have a
| play with a mainframe.
| rbanffy wrote:
| > I've read IBMs docs on their processor architectures, I'm
| sure they're fast enough but no more than that.
|
| I've played with the LinuxONE community cloud for a while and
| one thing that quickly become obvious is how ridiculously
| fast the machines are. Not only the 5+ GHz CPUs but all that
| very smart IO that seems to magically predict what the CPU
| will want, and have it on hand.
|
| And the cache architecture of the z16 CPU is awesome.
| HyperSane wrote:
| IBM actually forbids customers from sharing the performance of
| its z/OS mainframe performance benchmarks, which should tell
| you that they must be terrible for the money.
| neverartful wrote:
| The value proposition (if I may use that terminology) of
| mainframes is not performance -- it's 'RAS' (reliability,
| availability, serviceability). Of course, if you've got a
| huge legacy codebase of COBOL and CICS, it might be more a
| matter of 'keeping the lights on' for the business.
| rbanffy wrote:
| Also, benchmarks would have to be carefully set up. Sure
| you can do more MIPS on a cluster of generic underpowered
| x86 boxes, but what happens if you remove a RAM stick,
| shoot a bullet through an SSD or are hit by an earthquake?
| The numbers alone are hard to compare if the guarantees are
| totally different.
|
| A second thing to count is that it's vastly cheaper to run
| thousands of services out of a small group of very large
| machines than to run the same workload on a large number of
| cheap machines.
| lproven wrote:
| Hi. I wrote the blog post here.
|
| > Every time I hear someone advocating for mainframes, they
| always praise them
|
| [1] I wasn't "advocating" anything. I was talking about how
| they've survived. They _have_ survived. Whether it 's under
| emulation doesn't matter: still being sold, still driving the
| same peripherals from the same software.
|
| Their survival, thus far, is a fact. So the question I was
| trying to address was _why_.
|
| That's not advocacy.
|
| [2] If I were, which I wasn't -- It is pretty hard to advocate
| for anything without praising it. :-)
|
| The points about performance others have answered very well.
|
| > How is this _not_ a good thing??
|
| "You can have good, fast, or cheap. Pick any two."
|
| We have fast and cheap.
|
| The end.
|
| > people that like mainframes usually have some weird obsession
| with high level computing architectures
|
| Um. Define what you mean by "high level architectures" here?
| zppln wrote:
| > No performance benchmarks, no architecture comparisons.
|
| Yeah, I remember dipping my toes into this world when I was
| trying out COBOL a few years ago. IIRC they market these things
| with "transactions per second", which doesn't exactly lend it
| self to direct comparison with other systems...
| retrocryptid wrote:
| What does this have to do with mainframes other than the word
| "mainframe" is in the title and it links to a blog post where
| someone mentions Unisys. BeOS and OS/2 were operating systems
| that predominantly ran on PC class systems.
| abrax3141 wrote:
| Relevant previous discussion:
| https://news.ycombinator.com/item?id=30505219
| magic_hamster wrote:
| This actually got me fairly curious as to what the big difference
| is between mainframes and regular ol' micros. I don't think I
| ever used a proper mainframe, and I honestly wanted to know more.
| The author keeps building up to this massively different,
| otherworldly system, and then just finishes without ever
| answering.
|
| I did feel some contempt towards certain developers (who dare
| call themselves software engineers) and there was definitely an
| "old man yelling at cloud" undercurrent. If only I could learn
| something of merit, that would have been worth it.
|
| So I guess it's up to us plebs to go and see what makes
| mainframes so different. How the "weird" custom architectures
| work. What's it like to work on one and write code for it.
| Tor3 wrote:
| The maybe most distinguishing feature of a "mainframe" is
| intelligent I/O channels, which offloads a lot of what would
| otherwise be CPU work. And those I/O channels is why the PDP-10
| was called a "mainframe" while the rest of the PDP series
| (without I/O channels) were called "minicomputers". There's
| more, but it depends on the system - some can do maintenance on
| parts of the system while still operating.
| HyperSane wrote:
| The x86 world is getting I/O channels in the form of
| "SmartNICs" which are NICs with substantial processing power.
| rbanffy wrote:
| They also have it with disks local and remote. The idea is
| that the CPU is running user code 100% of the time and that
| it doesn't need to wait for anything.
| neverartful wrote:
| With the mainframe all disks are external. This diagram
| [0] does a good job of showing that.
|
| [0] https://en.wikipedia.org/wiki/Count_key_data#/media/F
| ile:IBM...
| trasz wrote:
| In the PC world this has been done couple of times, eg
| https://en.m.wikipedia.org/wiki/I2O from the late 90's.
|
| I think the real reason why it works for mainframes is
| that their operating system is so primitive, so it's easy
| to cross layers - because there are so few of them. z/OS
| is closer to MS-DOS than to Unix in that regard.
| Sebb767 wrote:
| > some can do maintenance on parts of the system while still
| operating.
|
| That's not that rare these days. Basically any server will
| allow hot-plugging hard drives, with some configurations
| network cards and by now a lot of laptops can even hot-plug
| GPUs via Thunderbolt.
| [deleted]
| neverartful wrote:
| Hot-plugging hard drives is a bare minimum. There are many
| other points of failure and a failure of any of the
| following WILL result in downtime while the component is
| replaced: disk controller, CPU, memory, NIC. Having dual
| NICs and dual processors helps, but it's still a far cry
| from 100% availability.
| rbanffy wrote:
| I remember some big iron could do it with processors and
| memory as well. IIRC, you can no longer remove CPUs with
| IBMs, but replacing memory is relatively simple.
| lproven wrote:
| Hi. I wrote the piece. Thanks for taking the time to read it.
|
| I wasn't aiming or trying to give a worked example of the
| differences, though.
|
| That's in the link that inspired the comment. Didn't you look
| at that? It's exactly what you ask, with discussions of
| filesystems, CLI, even C code examples. It would have been
| redundant to try to duplicate that. It's why I recommended it.
| I still do. You should read it, because it sounds like what you
| want to me.
|
| https://arcanesciences.com/os2200/
|
| As for sounding like a grumpy old man -- well:
|
| "I don't mean to sound bitter, cold, or cruel, but I am, so
| that's how it comes out."
|
| -- Bill Hicks
|
| :-D
|
| It's only a comment from Lobste.rs, copied-and-pasted. It might
| grow into something more significant at some time. Might not.
| Can't promise.
| Animats wrote:
| > The author keeps building up to this massively different,
| otherworldly system, and then just finishes without ever
| answering.
|
| Yes, it's a weak article.
|
| So, what do mainframes have that microcomputers don't?
|
| - Much more internal checking.
|
| Everything has parity or ECC. CPUs have internal checking.
| There are interrupts for "CPU made a mistake", and OSs which
| can take corrective action.
|
| - Channels.
|
| Mainframes have channel controllers. These connect to devices
| on one end, and the main CPUs and memory on the other. They
| work in a standardized way, independent of the device. The
| channel controllers control what data goes to and from the
| devices. Sometimes they even control what a program can say to
| a device, so that an application can be given direct device
| access with access restrictions. This would, for example, let a
| database talk to a disk partition without going through the OS,
| but limit it to that partition. The channel controllers
| determine where peripherals put data in memory. Mainframes have
| specific I/O instructions for talking to the channel
| controllers. Drivers in user space have been around since the
| 1960s.
|
| Minicomputers and microcomputers, on the other hand, once had
| peripherals directly connected to the memory bus. Programs
| talked to peripherals by storing and loading values into
| "device registers". There were no specific I/O instructions
| built into the CPU. Some devices accessed memory themselves,
| called "direct memory access", or DMA. They could write
| anywhere in memory, a security and reliability problem.
|
| Microcomputer CPUs haven't worked that way for decades. Not
| since the era of ISA peripherals. _But they still pretend to._
| Programs use store instructions to store into what appears to
| the CPU is a memory block. But that 's really going to what's
| called the "southbridge", which is logic that sends commands to
| devices. Those devices offer an interface which appears like
| memory, but is really piping a command to logic in the device.
| On the memory access side, the program stores into "device
| registers" which tell the "northbridge" to set up data access
| between devices and memory. Sometimes today there's a memory
| management unit between peripherals and main memory, to control
| where they can store.
|
| The end result is something more complicated than a mainframe
| channel, but without the architectural advantages of isolating
| the devices from the CPU. Attempts have been made to fix this.
| Intel has tried various types of I/O controllers. But the
| architecture of Unix/Linux isn't channel-oriented, so it just
| adds a layer of indirection that makes drivers more difficult.
|
| (Then came GPUs, which started as peripheral devices and
| gradually took over, but that's a whole other subject.)
|
| - Virtual machine architecture
|
| The first computer that could virtualize itself was the IBM
| System 360/67, in the 1960s. This worked well enough that all
| the System/370 machines had virtual machine capability. Unlike
| the mess in x86 world, the virtual machine and the real machine
| look very similar. Similar enough that you can load an OS
| intended for raw hardware into a virtual machine. This even
| stacks; you can load another copy of the OS inside a VM of the
| first OS. I've heard of someone layering this 10 deep. The way
| x86 machines do virtualization required adding a special layer
| in hardware underneath the main layer, although, over time,
| it's become more general in x86 land. Arm AArch64 considered
| virtualization from the start, and may be saner.
| neverartful wrote:
| If you want to quickly get a feel for traditional IBM mainframe
| software, you can do that easily enough. Download Hercules
| mainframe emulator [0] and then you can fire up MVS 3.8 [1] or
| VM/370 [2]. Be aware that the community has made significant
| improvements on these old open source software systems.
| [0] http://www.hercules-390.org [1]
| https://www.jaymoseley.com/hercules/installMVS/iPREREQv7.htm
| [2] http://gunkies.org/wiki/Installing_VM/370_on_Hercules
| tristor wrote:
| As someone who's worked deeply on mainframe and minicomputer
| systems and then worked even more deeply in the cloud, there is
| really no point to mainframes anymore unless you are doing a
| realtime application, which in most cases is unnecessary.
|
| The only value proposition I see is realtime redundancies, which
| are physically impossible with geographically distributed
| systems, but par for the course on mainframes. For most non-
| realtime applications, though, you can achieve same or better
| uptime for cheaper and with better flexibility building in the
| cloud.
| badrabbit wrote:
| Whay is a mainframe's redundancy/uptime? > 5 9s?
| Tsiklon wrote:
| A mainframe has 100% uptime. Redundancies are baked in by
| design, hardware maintenance can be performed while the
| system is live
| _-david-_ wrote:
| Can they update firmware without rebooting?
| rbanffy wrote:
| You rarely reboot the whole computer. You can take parts
| of it offline for repairs and the software will route
| around it. There is a PC inside it running Linux whose
| job is managing the various subsystems up from powering
| up the PSU, making sure UPS batteries are charged, that
| cooling is working even before the CPUs are powered up
| and microcode is loaded.
| badrabbit wrote:
| If that is true then that is enough of a selling point.
| Cloud providers with 5 9's have one or two outages a year.
| If you need the uptime for systems that can't have one
| outage in a decade, is there a competing solution?
| __d wrote:
| NonStop?
|
| Originally from Tandem, then bought by .. Compaq? And
| then HP, now HPE.
|
| Not a mainframe, but designed and built for 100% uptime.
| They used to do demos where you could open the cabinet
| and pull out boards at random, and it'd just keep going.
|
| It migrated from custom hardware, to Itanium, to x86-64.
| It's a custom OS, but has a Unix-like layer on top for
| ease of porting stuff.
| captainmuon wrote:
| I don't really share the reverence for mainframes. While they
| have certain cool unique features, like extreme resiliance, that
| doesn't matter very much because all the low-level details can be
| abstracted away. We have learned to build reliable systems on
| "commodity" hardware.
|
| In all the other places where mainframes are different, they are
| not only utterly alien, but I would also argue inferior. Focus on
| 60s languages, weird menu-based OSes, no proper Unicode support
| (judging from plane tickets and payrolls with missing symbols),
| and so on.
|
| That they hold out in "important" areas like banking and
| insurances is especially damning. This is the "allocation" layer
| of our society and is also hopelessly obsolete. The way we
| allocate resources has not caught up with our technological
| development. My personal belief is, one day, when we make the
| step to "capitalism++" - I don't know what it will look like, but
| it will compare to our current society like that compared to
| feudalism - then all that legacy infrastructure will become
| unneccessary.
| tyingq wrote:
| A lot of the holdouts are specifically z/OS mainframes running
| TPF. It's a distinctly different OS than z/OS (what MVS is now
| called). Used by VISA and the Airline industry.
|
| They've both had multiple attempts over the years to replace
| TPF, with varying degrees of success. Amadeus/Altea just barely
| finished getting rid of their mainframes. The other big GDS
| systems are still working on it.
|
| I don't think it was lack of desire or commitment of resources.
| ITA spent quite a lot trying to replace it, with an unusual
| collection of the best/brightest, and was able to replace the
| shopping piece successfully, but stalled on commercial success
| of the booking part.
|
| It's just a hard problem to solve. TPF is incredibly good at
| extremely high transaction rates in a distributed fashion with
| high reliability.
| rahen wrote:
| > We have learned to build reliable systems on "commodity"
| hardware.
|
| It is still cobbled together, and it still doesn't compare with
| what a mainframe can offer in reliability, security, resource
| efficiency and technical debt.
|
| Mainframes are the original computers, if anything the
| microcomputers are more alien. They had virtual machines from
| the early 70s, Z/OS can still run code from the 360 and maybe
| even the 1401, and it still has far fewer vulnerabilities, part
| from obscurity, part from a smaller attack surface compared to
| general public systems like Linux. Nothing wrong with CICS and
| 3270 either, which you seem to call "menu based OS". These are
| extremely resource efficient presentation layers.
|
| Also, i and Z basically are turnkey systems. They require close
| to no sysadmin, you don't have to run after the latest update
| to fix the latest issue. How many vulnerabilities had to be
| patched in the 51 years of existence of the 3270 protocol?
|
| I would trust a mainframe a lot more than a cloud based, or
| worse, anything based on Linux or Kubernetes when it comes to
| reliability and security - in fact, I bet an app running on
| such a solution will be considered obsolete in a mere 15 years
| (if not 10).
|
| I've seen companies running their own internal mainframe
| classes just because there's no suitable alternative to replace
| them.
| neverartful wrote:
| "Also, i and Z basically are turnkey systems. They require
| close to no sysadmin ..."
|
| I think this is true and fitting for i, but not for Z.
| __d wrote:
| The MVS systems I worked with had a small priesthood of
| sysops and sysprogs keeping them ticking. They certainly
| weren't set and forget.
| dangus wrote:
| You might as well say that battle tanks are better than
| Toyota Corollas. I'm sure a battle tank is safer in an
| accident but that doesn't mean it's the best choice for a
| daily driver.
|
| The goal of a business is to produce as many outputs as
| possible with as few inputs as possible.
|
| If mainframes are so much better, why don't you own one? Why
| doesn't your company own one? I see a Z 2828 on eBay for
| $9,995, sounds like a pretty good deal! I know the Raspberry
| Pis that run my self-hosted services only cost me $200, but,
| like you said, you get what you pay for! Where the heck is my
| credit card!?
|
| Mainframes are a dying breed because they aren't a solution
| for 99.9% of businesses (yes, that's right, literally 99.9%
| of businesses have fewer than 500 employees). [1]
|
| By the time a new business has grown large enough to
| potentially benefit from a mainframe architecture, it has
| been using x86/ARM commodity computing for years/decades.
|
| The only way a business would ever choose mainframes would be
| if they were already gigantic businesses before
| microcomputers were invented and their business has a high
| amount of clerical overhead. This is why banks and airlines
| ended up with mainframes.
|
| Having the best, most resilient technology possible isn't the
| end goal of most businesses. The goal of a business is to
| sell things and make money. Computing is essentially a cost
| center where the lowest bidder wins, where the cheapest
| possible solution is always the best one as long as the level
| of risk is acceptable.
|
| [1] https://www.chamberofcommerce.org/small-business-
| statistics/
| rbanffy wrote:
| > By the time a new business has grown large enough to
| potentially benefit from a mainframe architecture, it has
| been using x86/ARM commodity computing for years/decades.
|
| And this is why I say IBM is failing terribly in providing
| a simple onboarding ramp to these platforms. Almost nothing
| will scale as far up as a Z, but almost no company will
| need that and spending the money required by the entry
| level mainframe is a capital expense most companies won't
| consider appealing.
| neverartful wrote:
| In my opinion, the marketing and legal group at IBM (for
| decades) must have this for their mission statement:
| "Let's see how quickly we can sink this business!".
| They're completely inept.
|
| Examples? - Customers: "Can we license z/OS, z/VM, and
| other IBM mainframe software to run on Hercules
| (mainframe emulator) for DR purposes?" IBM: "we'll sue
| your ass out of existence!"
|
| - POWER5 brought some pretty amazing virtualization
| technology allowing for 'micro LPARS' down to 1/10 of a
| CPU [0]. It's gotten even better since then. When and
| where have you ever heard about these capabilities?
| They're part of what used to be called APV (now branded
| as PowerVM) [1].
|
| - At one time you could buy a used RS/6000 off of eBay
| (or from a reseller) and get a legal license (and media)
| for AIX. To do this today with modern Power systems, you
| have to first put the hardware under maintenance
| agreement. Oh, and if the server wasn't already under a
| maintenance agreement ('SWMA') (or there's been a lapse
| since it was under maintenance), you have to pay an
| additional fee ('ALF'). How much are these fees? SWMA
| estimate is $1800 PER YEAR. ALF estimate is $3200 (one
| time, unless you have a lapse in SWMA and need to do ALF
| again). Since Power8, you have to buy a separate HMC
| (nearly $2000) to configure LPARS. Net result is that it
| has become cost prohibitive for individuals to buy a
| second-hand POWER system and run latest AIX or i.
|
| - Want to get IBM's C or C++ compiler for AIX? There are
| 3 pricing options [2] available: $5780 per user, $17500
| per concurrent user, or $88.60 per VPC per month.
| [0] https://en.wikipedia.org/wiki/Micro-Partitioning
| [1] https://en.wikipedia.org/wiki/PowerVM [2]
| https://www.ibm.com/products/open-xl-cpp-aix-compiler-
| power/pricing
| rbanffy wrote:
| It must indeed be very frustrating to work for IBM and
| want to cover different markets and being unable to do
| it.
|
| I see, however, IBM can migrate a lot of those products
| from item sales to cloud subscriptions and, in that case,
| there would be little space for entry level hardware.
| [deleted]
| adwn wrote:
| That was a wild ride - from a reasonable start of "mainframes
| are a sub-optimal compromise" via "important foundations of our
| society rely on obsolete systems" all the way to "we'll replace
| capitalism with something completely different and better, but
| I don't know what".
| 2fast4you wrote:
| They said we'd replace capitalism with another version of
| capitalism, he didn't say it would be better
| adwn wrote:
| It was implied:
|
| >> _it will compare to our current society like that
| compared to feudalism_
|
| Unless you disagree that our current society is better than
| feudalism?
| rbanffy wrote:
| Speak for yourself. My family was faring really well
| under feudalism ;-)
| 2fast4you wrote:
| I think he was saying capitalism is an evolution of
| feudalism
___________________________________________________________________
(page generated 2022-09-25 23:02 UTC)