It's a lot cheaper in to do this in the US and with a long term view, my total outlay was under $3000 for a z800, z114, ds6800 all in with transportation. I also temporarily had two DS8870s but resold them because they were worth a lot more than I paid and I will pick up another for cheaper over the course of this year. Both of my frames have HMCs, the z114 was even IBM banded and "MSQ" maintenance service qualified which means they'd come and set it back up for some not-too-outrageous monthly fee if it were in production use.
The z800/z890 are probably optimal for hobby use even though they are old because they have modest power requirements and are relatively light and not too wide like the z114 which is absolutely massive.
Actually a P/390 (MCA or PCI card), or Multiprise 3000 (deskside hybrid CMOS/PC server thing) would be even easier but those are very very old 31-bit systems at this point. (I also have a R/390 setup and can comment on that if desired)
Now that said, this requires A LOT of dedication to get right. You need to understand at minimum shipping/transport issues, as well as electrical requirements and installation (or be willing to consult someone that can advise you on phase and conversion if necessary).
After that, you definitely need an HMC (a PC used to do things like load the OS) or at least a recovery disk and a lot of patience to set that up in emulation or on other hardware.
And then, you need a FICON (or older ESCON) capable array. Connor Krukosky goes into detail about what it's like without that, and you are extremely limited (basically Linux) in what you can do without FICON. A ds6800 is the easiest way to do that because it is a small rackmount unit, but they are also in demand for that reason. DS8ks are quite cheap all things considered, but serious iron like the frame itself.
And then finally you need some OS media which is also non-trivial to get (although there is or was some "out there" on file sharing).
I am willing to help anyone interested in this kind of thing for fun and preservation of incredible technology and history.
Hi kev! Thanks for your comments, you are 100% right.
Yes, living in the states make this hobby waaay easier. The surplus auctions help as well, having various goverments with various languages going in Europe does not make it as easy :-).
Was $3000 your outlay for the system + the DS6800? Or just the shipping? That is a great find in that case!
I just want to correct a small thing: You need SEs (the frame mounted laptops), you do not actually need an HMC as far as I know. Do you have any information that tells another story? If so I will update the article.
BTW, any other European retro-computing enthusiasts that see this, feel free to exchange your thoughts on how to find the machines that escaped the relentless push towards green tech.
IIRC $2k for the z114, $1 for the z800 and a few hundred for a one way moving truck rental I moved it myself, and maybe a few hundred for the ds6800 which I got lucky when it was FICON enabled the auction did not specify. There are three off-label mainframe support companies in the US that broker machines and parts for companies trying to bleed out their machines due to some transition plan or whatever. I've made acquaintance with one of them so I got the z114 for a great price because it wasn't suitable for any of their common customers and they were able to move it quickly from decom to me.
For the HMC I recall reading this in a manual or hearing it from a mainframe professional but I can't quickly cite it. It may be for some things that a home user doesn't necessarily need, like remote access. Can you access the z/OS System Console from the SEs, that is the only critical thing I can think of.
If you want to dabble with mainframe. Another option is the IBM zPDT. It is an emulator that runs on AIX or Linux. It does require a physical USB hardware key. It is kind of pricy about $5K from IBM, but there might be discounts. I believe that also get the z/OS and z/VM software and licenses also.
Yes that entitles you to a lot of software, so it is a good deal for professional use.
If you are just curious on the software side at home, Hercules is an amazing project.
For students IBM does a "Master the Mainframe" contest where you can get remote access to an environment and see what it is like as a user and developer.
And "Master the Mainframe" is even open to non-students (look for "Learning System"). Comes with material and tasks to work through to get acquainted with the mainframe.
I think its a great career niche to be fluent in everything Mainframe, they are still used in critical places and will be for the foreseeable future and they are largely overlooked as a opportunity.
So if you want to work in this niche, having your own Mainframe will greatly speed up learning the system.
It probably also looks awesome when you market yourself.
So all in all, 25k USD for kickstarting a potentially very profitable career sounds like a bargain ....
If you just want to learn the software, you can set up Hercules mainframe emulator for free. Finding an image of z/OS is left as an exercise to the reader, but won't take you long.
Hi, author here. Spot on! It is pretty common to see mainframe courses for $10k each - so given how much I hope to learn I kind of justify the cost just on that. Now, I do not expect to change to work on mainframes full time, but maybe it can grow into a side gig? Who knows! I do enjoy the process anyhow so it feels like a win-win :-).
I'm not even sure if there are still use cases where companies use main frames for newly developed systems. Even core banking systems can be build without using a main frame.
Can't you get to that uptime with a well-configured cluster? I tried to find more information but couldn't find any other reasons why mainframes would still be the best option for a newly designed system?
Getting a cluster to guarantee that something happens excatly once is very hard, but doing things exactly once is an extremely useful property in banking. Using a single earthquake-proof computer with redundant everything, including hot-swappable RAM and CPU gives you similar reliability while making it much easier to achieve many desirable properties. Even if you can do the same in a cluster, spending more on hardware to reduce software complexity is worth it when bugs might cost you millions or billions of dollars.
Also, with Mainframe, you’re not only using a different machine but also a different “everything”. You need specialized storage, you need to use an “exotic” programming language, you need people who know JCL, RACF, DB2 etc., for a lot of “middleware” (CD pipeline, access management, version control) you have limited vendors to choose from so you’ll pay a lot for that too. So if you are also running something else (Linux servers etc.) you basically need double the staff and licensing costs...
That is not really 100% true. You can certainly run z/OS if you want, and that incurs those costs you mentioned - but that is true if you want to run Windows as well for example.
However, the biggest thing to remember is that you can and should run Linux on these things as well. Linux on z, or zLinux as it for some reason is called, is just Linux on the redundant and fault tolerant mainframe hardware. Anyone with Linux experience could manage it really, and you would get a pretty damn good platform to build a high availability service on.
Good old days when I transit from XA to ESA, from dos/vse to movs, from racf administrator to dB admin, Ibm start to ship 3390-3, ispf, Rexx to generate jcl, patching and debug 370 assembler ...
Still holding a Hp dos pocket whilst working on all these.
ThOse were the days. Different very much from using a mac to run leela zero using egpu :-)
Author here, I might write a blog article about that because it is really quite interesting.
The TL;DR is that some might want to rather run 1 or 2 systems (mainframe) instead of 100 physical machines (conventional distributed cattle system).
Now, IBM does make it quite expensive but the mainframe has some pretty cool features like pay-for-what-you-use (which you of course get with the cloud, but not so much if you also want your data in-house).
Anyway, it is a fun beer topic if nothing else :-)
Well...you sort of “pay for what you use”. I believe the extremely simplified version is you pay for the peak CPU usage (excluding specialty processors like ZIIP) in a moving 4 hour average window.
Context:
I work for a large organization that used to run several physical Z13 mainframes, all of them containing several sysplexes. If we had issues, an IBM consultant would fly in within the day. We were definitely not IBM’s biggest customer but we were not insignificant for them either.
We had a lot of mainframe support staff (so not people programming for mainframe but people maintaining storage, DB2, z/OS upgrades etc.) and I think even for them, the IBM bill was more or less: we see a large number, no idea why it’s this amount, but we cannot prove it is not right, so I guess we’ll just pay it.
From an EU perspective, most interbank communication for SEPA is through XML following PACS or CAMT xsd’s (so there’s a PACS format to transfer money, a CAMT format to inquire on the status of a payment etc.) sent via an intermediary clearing house. Used to be huge XML batches, but now moving to small XML messages.
Internationally also “MT” messages are used, which is also a file with specified format.
So it doesn’t really matter what stack you run, as long as it can create files and send them out :-)
I can't verify 100%, but I think Orange Bank (subsidiary of the telco provider) is entirely built on the cloud. I believe they built all their systems ground-up 2 years ago, but I could be wrong. When they acquired Groupama Banque, I think they basically started over on the systems.
I doubt there’s a legit use-case for a mainframe even in business environments. All the “reliability” it gives you can be re-implemented on commodity hardware and still come out ahead compared to the costs of buying & maintaining a mainframe.
I wonder how much cheaper it is to implement software for one, huge machine that „just works”, vs the usual way of implementing for a network of distributed machines. Distributed programming is NOT easy, and, even if the hard parts are supposedly implemented by various protocols/frameworks, these solutions constrain the way you can program and also have a ton of „interesting” failure states - just take a look at logs of say Hadoop cluster that’s been running for a while - even though the cluster is supposedly running fine (or is it?), you’ll find various kinds of exceptions related to the distributed model (socket timeouts and whatnot). Not to mention trying to thoroughly understand various eventual consistency models.
On th plus side, we’ve basically moved complexity from hardware to software (it was pioneered by Google, a software company, so no wonder) which increases salaries of software people, at the expense of hardware people. So yay for us I guess.
Author here, I agree 100%. It is just a different way of building software, which is why I find these things so interesting. It challenges my worldview and thus I want to learn more about its upsides and downsides.
CICS and IMS definitely made it easy to create scalable software decades ago. It is not that different from the frameworks we have invented to make distributed systems viable that you mention, which I find insanely cool.
One of the cool things of running e.g. Ceph is that it exposes a familiar API (POSIX filesystem) which makes things easy to integrate with. The mainframe is like that but for hardware. VMware has similar things to some degree where your VM can be kept alive across hardware failure, but not really on the same level.
Anyway, I will stop here but I could go on for hours :-)
"I doubt there’s a legit use-case for a mainframe even in business environments"
You're incorrect. The most common one is to run legacy software, and not just banks. Insurance, retail, utilities, financial, manufacturing, etc. Some companies have been around before x86 hit the scene and already had significant investments in their in-house computing infrastructure.
Oh? Even when your environment uses z/OS, z/VM, CICS, DB2, and a whole slew of other IBM and 3rd party products? Do you know that all mainframe software is fully supported when run on a mainframe substitute? I have no idea whether it is or isn't.
Correct, it will run at https://datacenterlight.ch using 100% renewable energy. It the least I can do to offset the ~3 kW everything (z114 + dasd + everything else) will consume.
There is recurring costs as well, something like $400/mo in power usage bills, and another $400 in internet and space rental fees per month. The folks over at the datacenter have been very happy to have me so there might be some discounts in there as well, but I am not sure. My goal was to keep the recurring cost as low as I can, and compared to what hosting a beast like this in a conventional datacenter would cost I'd like to think it's a pretty good deal.
Given that it generates like 10k BTU/hr or something like that the drain on the datacenter is non-trivial, so I a running cost was to be expected.
As somebody who started out in the 80s with Apple II and C64 stuff the year before going to college, I always laughed at the old “Star Trek’ episode where the new computer has to tap into the main engine for power. After seeing your new bit of kit, that doesn’t sound so far fetched :-)
I have my own "home server room" with a POWER6, but it's just a couple U in an extended tower. I can't imagine connecting this kind of a beast to household power, let alone getting it in the door. It takes a special kind of skill to maintain big iron like this and definitely the appropriate environment to house it.
My interest in doing this (my wife would kill me anyway) kind of evaporated when in almost every paragraph he hit on licensing issues you might have. What a headache for someone who just wants to tinker on the hardware and maybe buy a few parts off ebay for the full experience. I have no doubt software updates, documentation, and everything is locked behind some portal that requires you to have a stupidly expensive support contract to access.
Shout out to HP (fka Dec) with their support for hobby use of VMS. I have a couple of VAXen (just desktop microvax, no need to get excited) that I had running 15 years ago using the hobby license, which it seems still exists : https://www.hpe.com/h41268/live/index_e.aspx?qid=24548
It definitely still exists - I used my old DECUS membership number to get a new set of license PAKs (and a link to download the install media and software kits) last week.
My second thought about this was "no wonder IBM is largely dead outside of stodgy corporate IT. Nobody can actually learn to use it without dropping $100,000+ on equipment."
Back when I was at IBM one of the hats I wore was AS/400 administrator and programmer.
I miss working with it and would like to buy one for my home lab, but the licensing is a killer. I find used ones on the market, but they usually don't include the license keys or media, and without a support contract can't get them.
I really wish IBM had a hobbyist program. I wouldn't expect it be free, but I wouldn't mind paying a small yearly fee.
The irony is that IBM had one of the first Open Source communities: SHARE, dating back to 1955, shared software up to and including a whole OS, SOS (SHARE Operating System), well before Unix or home computers even existed.
It’s worse than that. Most of these environments are in the stodgiest corner of those companies. I worked with one a long time ago as a consultant where we struggled with an authentication related issue.
The response from the service owners was that they weren’t going to switch to a new, unproven methodology. In this case the “new” thing was around since like 1989 (this happened circa 2003). They still use whatever they were using today.
As a new hire, you’re screwed. Anyone getting into mainframes is insane.
Once you have the basic emulator setup working, check out the Turnkey system below. It's MVS 3.8 so not current Z/OS. If you google around for z/os ADCD, you might find an actual Z/OS CD to try next.
You'd be amazed at how little the underlying ecosystem has changed over the decades. Because it basically keeps compatibility forever, software that was written in the 60's can still run on modern machines. Because of this, learning using 80's software in the mainframe world is not too bad. For example, I keep a book on MVS on my desk from the 80's for reference, and most of the time it suffices for what I need to consult.
Indeed the last official MVS freely available is 24 bit, but then you have stuff like MVS380, which supports 31 bit and has 64 bit support in the works.
80% of what a beginner to IBM big iron would learn at first can be done on MVS 3.8.
It's more like the difference between SysV and Linux, or Windows NT and modern Windows. Major differences and lots of features in the newer stuff, but for first principles it'll do.
Like I said, if you want modern(ish) Z/OS, ADCD is your best bet.
My current side project idea: build a modern programming language with a nice syntax that compiles (transpiles?) to mainframe COBOL, mostly to get mainframe programmers to stop writing code in SHOUTING ALL CAPS.
As I understand it, the field is going in the other direction, namely JVM/CLR COBOL. This means that companies can migrate their COBOL codebases to “commodity hardware”, save on mainframe costs, and then progressively refactor into Java/.NET replacing bits of COBOL piecemeal.
The main company I’ve heard of doing this is MicroFocus, they have all the dev tooling for it for the major IDEs, compilers, etc.
One of the main things that complicates the problem, again as I understand it, is that there is no official COBOL spec. There are several versions from several vendors, but compilers have to account for mainframe hardware bugs, so there are many different targets that have to be supported. Most companies want a different, specific, set of compiler features.
Hmm. I'm interested in making a compile-to-COBOL language only because that way a company could incrementally migrate an old COBOL codebase to the new language. In other words, the new code (which compiles to COBOL) and the old code (written in COBOL) would be fully interoperable, sharing the same data types, calling conventions, etc.
Yeah, and this makes sense, but there are multiple problems with COBOL on mainframes – the COBOL, and the mainframes.
COBOL and mainframes have quite a different programming and system administration model to what we expect with servers. Lots of concepts are quite different, built up from a world of mainframes and terminals, tapes, batch processing, etc. Concepts like users, operating systems, files, networking, parallelism, programs, databases, are all quite different, and all of these differences cause companies problems in training users, and creating nice new software that works in ways people expect now.
Creating a, for example, JavaScript to COBOL compiler is probably not fully possible. You may be able to transliterate it, but you would essentially be writing a COBOL program in JavaScript syntax – not using Node libraries and writing React components. This reduces many of the benefits.
The alternate approach is that you take your COBOL and compile it to work in the JVM. You get a JAR out that you can run on your regular servers that are already running your other JVM software. There is probably a significant runtime built into that by the compiler that translates some mainframe concepts into modern concepts, but that's fine because you haven't had to rework your COBOL. Then, you can progressively pull out modules, rewrite in Java, and reference those from the old COBOL code. You don't need lots of training in mainframe concepts, you don't need to spend millions of dollars a year on your mainframe, and you can write new code in Java.
The US Department of Defence have taken this approach one step further, and are actually writing a compiler from COBOL to Java. It's not fully automated, but with not too many developer-hours, they can turn significant chunks of COBOL into reasonably good quality Java, over the course of several stages.
Your idea is a good one, and worth experimenting with maybe, but I think the best approach for the migration away from COBOL for large businesses (and only large businesses use it) is the other way around.
It's a $900/year subscription if you go the legit route, and not "approved" to use with Hercules. You're supposed to pay ~$4k for zPDT to be fully legit. Thus, most hobbyist use is pirated torrents of ADCD on Hercules.
Everyone in that scene knows that it's not enforceable. Gene Amdahl literally started his own company making plug and software compatible mainframes, and IBM got hit with antitrust rulings trying to shut him down with lawyers.
The law of Conservation of Energy says all that input electrical energy going into the system has to be accounted for in the form of some other energy.
Now the only thing moving will be the fans and the hard disks, which means only a very little of that input energy will be converted to kinetic energy.
The system will not be storing energy, meaning none of the input energy is being converted to potential energy.
Now some energy will be lost in the form of noise and light emitted from the leds and monitors etc.
So that only leaves the radiated energy (i.e. the heat) produced by the system.
I would think that heat component would make up the largest portion of that energy pie.
Even the kinetic energy (fan motors, HDD motors) eventually becomes heat. E.g., the moving air from fans dissipates its energy in turbulence in the room's air, and in a closed system (airtight room), the resistance to airflow (resulting in heat) must equal the pressure differential created by the fans, unless the air builds up unbounded speed. Likewise, torque to keep the HDD platters spinning will be exactly equal to frictional losses once the disks are spun up, so all power into the spindle motors becomes heat.
Even noise that leaves the system either becomes heat as the pressure waves dissipate through the atmosphere, or else do work on eardrums (mechanical energy) which eventually becomes heat as the inner ear resists the motion of the ear bones :-)
Actually it's 100% efficient in terms of converting electricity into heat. Anything that consumes electricity is near 100% efficient at generating heat. If you tried really hard you could build a very efficient laser and send heat outside the room, so not 100% would end up in the room. Even then the majority of heat will be dissipated in the room.
Right, but it was being compared to a space heater, not a heat pump.
Not to mention heat pumps require somewhere to pump to/from, you can't just put one in your basement, plug it into the wall, and heat up the basement. Also heat pumps work best with mild differences, like say 40F inside and 60F inside if you want to heat.
Heat pumps reduce to space heater efficiency if it's sub-zero Fahrenheit outside I believe.
Sub Zero F is seriously cold! But for most climates there is some advantage. 40F is pretty cold. Take somewhere not particularly hot like London - most of the year it will be warmer than that.
Although in the UK most people use gas to heat their homes, because its cheaper. I worked out once that gas and heat pumps cost the same in the end for the amount of energy. Although what I love about heat pumps is how quick they get a place warm compared to radiators.
Granted heat pumps need installation, or you can probably run a tube out the window with one of those adapters.
It's a silly hypothetical discussion, because for the price of this mainframe you could get a heat pump and a set of solar panels and a battery storage, and have some money left over for some Hawaiian shirts to wear once you've heated the place up.
For financial efficiency (environment be damned) a set of crypto miners would be better than either the mainframe or the heat pump.
Is it inefficient? Some of the energy will be converted to light, but all the rest should be converted to heat? If you need constant heating and use electricity for heating, wouldn't a mainframe be as efficient as any other heating?
It would. Unless you could replace the electric heating with a heatpump though - then you would get more heat out of each kW you put in.
But replacing an old-fashioned electric wall heater with a 1700 W mainframe would be totally equivalent. So no, a 1700 W computer isn't more 'inefficient' than a wall heater of the same wattage. The light is neglible and it too ends up as heat anyway.
Heh, exactly. Even the light will quickly be turned into heat once it hits something. Sure some might escape through a window, but that's going to be vanishingly small amount of the total energy.
From what I've heard, redundancy and scalability in a single machine (like, you can hot-swap CPUs on a running machine and have lots of redundant RAM, etc.) and being able to run an OS with backwards compatibility all the way to the fscking 1960s or whatever.
I cringed when he said he bought a DS6800. When I worked at IBM we had about 20 of them and they were shit. Always broke and getting into weird states. No way I'd run one with a support contract.
My understanding is a team ported the ESS "Shark" code from AIX to the little Linux 2.x embedded controllers. It looked like Adaptec OEM hardware when I tore mine apart. I can see how that would go poorly versus the proper cabinet sized arrays. They are definitely good enough for home use but I agree not what you want any production workload on. I heard from a 3rd party support company there is some part that is prone to failure but I cannot recall what it was.
Yeah I found the root linux password online. There was more than once I had to SSH in and fix the SLIP connection between the controllers when they went into a brain split.
If I recall correctly they were running SuSE Linux with Websphere App for management and DB2 storing all of the configuration information.
I hadn't heard they traced their linage back to the shark. That surprises me a bit because we had several of those and they were very reliable. Though thinking about it that makes sense.
Hopefully the later software fixed the reliability problems. I got rid of all of ours in about 2010 or so. Replaced them DS5000 on the Open Systems side (which had their own set of problems), and DS8000s on the Mainframe side. The DS8000 was pretty rock solid.
The z800/z890 are probably optimal for hobby use even though they are old because they have modest power requirements and are relatively light and not too wide like the z114 which is absolutely massive.
Actually a P/390 (MCA or PCI card), or Multiprise 3000 (deskside hybrid CMOS/PC server thing) would be even easier but those are very very old 31-bit systems at this point. (I also have a R/390 setup and can comment on that if desired)
Now that said, this requires A LOT of dedication to get right. You need to understand at minimum shipping/transport issues, as well as electrical requirements and installation (or be willing to consult someone that can advise you on phase and conversion if necessary).
After that, you definitely need an HMC (a PC used to do things like load the OS) or at least a recovery disk and a lot of patience to set that up in emulation or on other hardware.
And then, you need a FICON (or older ESCON) capable array. Connor Krukosky goes into detail about what it's like without that, and you are extremely limited (basically Linux) in what you can do without FICON. A ds6800 is the easiest way to do that because it is a small rackmount unit, but they are also in demand for that reason. DS8ks are quite cheap all things considered, but serious iron like the frame itself.
And then finally you need some OS media which is also non-trivial to get (although there is or was some "out there" on file sharing).
I am willing to help anyone interested in this kind of thing for fun and preservation of incredible technology and history.