Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The IBM mainframe: How it runs and why it survives

arstechnica.com

Post reply on HN
Print view View original

131–140 of 195 posts

Re: The IBM mainframe: How it runs and why it survives

#131

Post by StillBored »

"Today’s IBM mainframe CPUs are based on a highly evolved version of the POWER architecture that IBM has been developing for over 30 years. "

I've heard a lot of largely clueless people who weren't aware of the differences between the zeries and pseries say something like this, but its generally been entirely false (especially 15-30 years ago which overlaps with some time I myself spent at IBM). Given the rest of the article I wouldn't presume the author is in this category.

So has something changed? or is the implication stretching the truth? I mean I guess you could strip a POWER core down so it only runs s390 microcode/etc, but that likely won't actually yield a performant machine and the process of evolving it would likely fundamentally change the microarch of whatever RISCish core they started with.

I mean they are entirely different Arches, in the past utilizing entirely different microarches. I can see some sharing of a RTL for maybe a vector unit, or cache structure, or a group doing layout, but that doesn't make the zeries processors any more derivative of POWER than Itanium was derivative of x86, etc.

PS: the bit about zos partitions supporting linux seems like a bit of confusion too, earlier its correct about the LPARs being capable of running linux directly, but ZOS isn't providing the lpar functionality, and is generally just another guest alongside linux, ztpf, and various other more esoteric "OSs" that can run natively. There is a unix system services in zos but that isn't a linux kernel/etc.

Re: The IBM mainframe: How it runs and why it survives

#132

Post by sb-alien »

I was involved in an IBM mainframe to RS/6000 migration in the mid 1990s for a major aerospace company. We moved the engineering functionality to a client/server system, including many custom programs and CAD/CAM/CAE.

Like the article mentioned, migration was a Herculean task done over a period of years, with a good chance it wouldn't succeed. I worked many 70 hour weeks, I had to drive to the factory at 2AM some days to monitor jobs because only certain people had remote access. Floating point and text encoding was different between the systems, decades of legacy engineering and manufacturing data and code (having cost hundreds of millions of dollars to produce) had to be translated and verified. There was a rivalry with the mainframe group who wanted it to see it fail, reluctant programmers, engineers, and line workers. On and on and on...we had to apply start-up levels of creativity and ingenuity while working in an MegaAeroCorp bureaucratic atmosphere.

Ultimately, the project was a success, although the system soon moved to PC-based desktops as graphics cards became more powerful. I got a company award from my internal engineering customers. Shortly after the dust settled, I got called into a secretive meeting with my boss and the department head, expecting a promotion and a raise, or at least an "Attaboy!" No, I was reprimanded by an HR rep with a formal note in my records about my attitude ("You risked everything by cowboying!"). I was admonished for having the gall to take a couple of sick days during the ordeal (my coworkers were concerned when they found me passed out at my workstation, my boss warned me after my time-off "If you are sick be sick" and called me a filthy name.) I was put on double secret probation.

Our whole department was eventually outsourced, and I ended my tenure there by being escorted by security to the door and told not to let it hit me in the backside. I guess I should have joined the mainframe group on the business side, in retrospect, they are still around grinding out profit statements. It was a challenge to get rid of a mainframe, maybe more so than eliminating our entire engineering support team.

Re: The IBM mainframe: How it runs and why it survives

#133

Post by lotsoweiners »

sofixa wrote: post #106
Solvency wrote: post #96

Earlier quoted context omitted.

Completely untrue. Listen to everything Cameron Seay has ever said about the subject. Mainframe programmers are wanted more than ever. https://www.youtube.com/watch?v=hxxyORcU3Hs https://blog.share.org/Article/mainframe-visibility-ibm-cham...

Which part is untrue? That there isn't enough personnel or that it's a severely limiting career choice? Because what you're saying confirms the first one, and for the second one, not a lot of people dream of working on legacy stuff in a big organisation, and those are your only choices if you're a mainframe programmer. Say in the US, for mainframe work, there are what, 30 banks? 5 airlines? 20 insurance companies? No…

Lots of government too. I worked at a government agency that ran it’s business off of mainframe. I worked there as a web developer and we had to consume data from the mainframe in our web apps. Very tedious process.

Re: The IBM mainframe: How it runs and why it survives

#134

Post by bombcar »

reacharavindh wrote: post #130
CraigJPerry wrote: post #4

The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…

I think its hardware is what enables such reliable software. Hot plug CPUs, memory modules, and DASDs. All survive the failure scenario gracefully. Good luck trying to do that on a rack of x86 servers. I think as in most engineering things. They do a different trade-off and cater to a different niche while x86 servers are the mass market consumables that most workloads -should- be using. The mainframe CPUs go for the…

x86 just made it so the whole computer could drop out of the “cluster” which greatly simplifies the hardware design but the result is NOT a “virtual mainframe” as the software becomes exponentially more complicated if you want “all power”.

Re: The IBM mainframe: How it runs and why it survives

#135

Post by denton-scratch »

Back in the early 80s, I visited the Police National Computer Unit at Hendon in North London. The computer room was the size of a football pitch. Most of the floor was covered with washing-machine-sized disk-pack drives, along with quite a lot of dedicated IO processors (also washing-machine-sized). The walls were lined with storage for offline disk-packs. This system was a triple Burroughs B7800.

What distinguished mainframes from minicomputers back then wasn't their awesome processing power, or their resilience; it was their huge IO capacity. They could handle hundreds of storage devices, and hundreds of thousands of terminals. At least, that's how I was told it; I never worked on mainframes.

Nowadays a single connection to the internet can connect you to a similar number of "terminals", and storage is also accessed over a network. So the advantages touted by the author are quite different from what they used to be; IO nowadays isn't the issue it was back then.

Re: The IBM mainframe: How it runs and why it survives

#136

Post by myth2018 »

It may be my mileage.. But I frequently hear about the shortage of mainframe professionals and, some years ago, I seriously considered getting into it. However, after some attempts to find training on topics I typically see in job postings (CICS, JCL etc), I gave up after finding no courses also providing access to a mainframe "account" for practicing. Maybe I didn't search it properly. I've been advised to try an entry-level position in a company hiring juniors, since they usually provide the training during the first months. But, after over 20 years as an engineer, that felt bigger a step back than what I was willing to take.

I still feel interested though. I'm aware of the current state of chaos on mainframe development, but honestly, I don't think that the current web/mobile situation is much better and, besides, I personally hate them really bad.

Re: The IBM mainframe: How it runs and why it survives

#137

Post by jjtheblunt »

hinkley wrote: post #85
CraigJPerry wrote: post #4

The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…

Most of this Cloud technology we like to go all atwitter about is a retread or a redesign of software that's been on mainframes for thirty years. The old farts must laugh themselves silly looking at us acting like we discovered a large white object orbiting the earth.

SUN used to say The Network is the Computer...that always reminds me of what is called "cloud" the last 10+ years.

Re: The IBM mainframe: How it runs and why it survives

#138

Post by dreamcompiler »

Early in my career I worked on IBM mainframes and wrote JCL for them.

Let's say someone knocked on my door tomorrow and said "We're looking for someone with any experience at all with JCL on IBM mainframes. We'll pay a million dollars a year for a 10-year guaranteed contract. Are you that guy?"

I would say "Nope. Sorry. I'm a plumber. I don't know nuthin' about computers."

(And then they would say "Ha! GOTCHA! How'd you know we were talking about computers? Now take your million-dollar check and watch your head as you get into this nice black helicopter.")

Re: The IBM mainframe: How it runs and why it survives

#139

Post by electroly »

gumby wrote: post #110
CraigJPerry wrote: post #4

The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…

> Going back to the hardware that everyone likes to focus on, it's less radically different from normal servers today than it was historically. The mainframe today is a 19 inch rack like any other. The Main Frame of yore was ... one of the 19 inch racks the computer was made out of (the main one, typically with the ALU and registers in it). And those racks were used because that was how phone systems were built (phon…

The granddaddy of mainframes, System/360, was never in 19" racks. IBM first introduced the use of 19" racks in their midrange lines. What we currently call IBM z didn't adopt standard racks until the 21st century.

Re: The IBM mainframe: How it runs and why it survives

#140

Post by rvba »

hermitdev wrote: post #68
ibiza wrote: post #32

Earlier quoted context omitted.

Migrating a suite of programs written w/ COBOL, CICS, DB2 from z/OS to Linux is fairly straightforward. MicroFocus COBOL compiles IBM COBOL, DB2 runs on Linux or you can swap out another RDBMS. The CICS part requires a simple runtime easily implemented in C plus a new scanner to replace the calls in your programs. I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs runni…

> DB2 runs on Linux The DBA's I interned with would yell at you for this claim. They'd say UDB runs on Linux, but DB2 only runs on z/OS. I worked with both DB2 & UDB during my internship 2 decades ago, and while largely compatible with core SQL functionality, that changed quickly after you got off the "normal" path. UDB was released at a much faster cadence, and if you developed to the latest features of UDB, you'd o…

What company had 10k developers on a mainframe?
Post reply on HN