Comment by underplank | Hacker News Reader

Comment by underplank | Hacker News Reader

Parent Full thread

I used to develop software for system-z(2 years ago). As someone else said, if you are already using mainframes, get another one. If you arent, pretty much you can ignore them. Their hardware is of higher quality, but I think their uptime has more to do with the hermetic seal of human process that exists around the installations. You can't get anything changed in production, ever. And thats fine, because banks have been doing the same thing for the last 30 years.

I don't actually think performance wise they have anything on a cluster of x86 servers. But its hard to benchmark things like that accurately.

From a developer point of view, its not a great technology stack to work on. Its old and out dated, and is pretty incompatible with other platforms. EBCDIC is a pain, 3270 terminal is a pain. Having to allocate files manually is a pain. Having actually about 7 different types of files is a pain.

Its really all a pain. Just dont go there.

Also, I found that guys who had been working on mainframes for a really long time have a pretty outdated view of what the "distributed" world has to offer. A lot of the time they dont understand what "web Scale" at the level of google, facebook et al are operating at.

As an additional funny annecdote, the I/O that a lot of people have been talking about is now conventional if high end disk array's AFAIK. But internally the disks are emulated for the OS to look like the disks it was using back in like 1975. Thats how it gets backwards compatibility, just dont change anything.

As a technologist I'm always excited about new stuff, but there's another part of me that thinks it's really neat that some of the world's most important software was written 30 - 50 years ago and still works just fine.

Can you imagine a time 1000 years into the future where software written today might still be in use? How cool would that be?!

Most of that software is still in use because it's very poorly written using a combination of COBOL and assembler and people are afraid to touch it.

Very poorly written and it works, at least.

I'm currently reading a book written in the 1170s, so I can imagine that :)

And I've just finished the Iliad (in translation) which dates from about 800BC describing events of ~1250BC.

It's a bit like the descendants thing that was discussed a few days ago on here - either lots of stuff will survive the next 1000 years (and therefore lots of running code will) or almost nothing will.

There are some technologies out there in the non-mainframe world that have similar properties.

To name the ones I know of - vi, emacs, C, Common Lisp. These have held pretty steady for about 30 years now.

Given I'm sure many people here have anecdotes about little snippets they wrote in a short amount of time that ended up in use for a decades, even though the code was crappy (someone tell me I'm not alone here...) - I'd be willing to bet something, somewhere will still be around a long time from now.. though a thousand years is a bit hard to comprehend in terms of technological change.

If banks still exist they'll still be emulating zOS on their quantum dimension-folded computers...

Cool? I'd think that would be depressing.

>Their hardware is of higher quality, but I think their uptime has more to do with the hermetic seal of human process that exists around the installations. You can't get anything changed in production, ever. And thats fine, because banks have been doing the same thing for the last 30 years.

You hit it. Things break when you change things. The high priesthood that surrounds all mainframes prevents that from happening.

Nowadays, if you have to change stuff, IBM sells you AIX boxes that cost nearly as much as mainframes which sort of integrate with them to support those changes.

Reply on news.ycombinator.com