Buying an IBM Mainframe
blog.mainframe.dev
blog.mainframe.dev
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.
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.
Thanks again!
It's unbelievable how thoroughly Europeans recycle their old computers. I can't find anything.
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 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.
Very much recommended for anyone who is curious.
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.
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.
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 :-)
Oh please go on for hours; I'd love to hear more. Any format (blog or just semi-structured brain dumps in comment threads) will feed thoughts :-)
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.
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 :-)
Have fun with this beast.
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 ....
Thanks for reading!
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 :-)
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.
Mainframe billing is really complicated.
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.
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 :-)
https://developer.ibm.com/mainframe/2018/01/19/reasons-host-...
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 :-)
There's a contest open to students, but anyone can sign up to use these resources.
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.
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.
https://www.rs-online.com/designspark/my-raspberry-pi-thinks...
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.
Bit of an understatement, MVS 3.8j was released in 1981.
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.
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.
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 was a great read though and I'd probably buy one as well if I had the money, time, and space. They seem like underrated machines.
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.
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.
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.
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 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 :-)
Are they simply like a big computer?
That OS is… something: https://medium.com/@bellmar/hello-world-on-z-os-a0ef31c1e87f
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.
What kind of problems do you hope to solve? Are there anything in particular you will use it for?
Finally he can run a personal Minecraft server.