Live data from Hacker News

Hello World on z/OS

medium.com

101–110 of 123 posts

Re: Hello World on z/OS

#101
post #31

> IBM uses special and completely unintuitive names for basic concepts…. because OF COURSE THEY DO. As I recall, it's called "Bluespeak", and that sort of thing is pretty common actually. I was educated in networking at a Cisco netacad, so I use Cisco terminology that is apparently not universal. Programming languages do this too for some reason: Sum type, tagged union, discriminated union, variant...

The point that M. Bellotti came close to, but missed, is that "of course they do" is because every field has jargon . The error here is in thinking that one set of jargon is intuitive and normal whilst another set of jargon is "special and completely unintuitive". The simple truth is that there are many people to whom jargon such as "WIMP", "ISOs", "flat UI", "IIFE", "DOM", "pull request", and "UX" is equally as opaq…

IIRC, as the story goes the folks who designed IBM's SNA (Systems Network Architecture) went out of their way in order to come up with a whole new set of technical jargon for that. I don't remember why, though.

BTW, I've been around long enough to have had conversations like the following:

Them: "I want to run Lotus 1-2-3." (This was the near-universal spreadsheet standard before Microsoft Excel came along.)

Me: "OK, then first we're going to have to get you a PC."

Them: "What's a PC?"

Then I would have to explain that this was a "Personal Computer". And not just any personal computer, either, but rather an "IBM" PC, in order to distinguish it from an Apple or Commodore or TRS-80 or TI-99/4A or Atari or whatever. And they might respond that they didn't even know that IBM made personal computers. (Which they don't any longer, of course.)

Re: Hello World on z/OS

#102
post #63

Just a shameless plug: there is very little information in the form of Stack Overflow-like things and getting started with mainframes is, as this article shows, pretty hard. I made this SE proposal that's in commitment stage (where people commit to support the community). If you know about mainframes and are willing to be part of it, you should commit too. https://area51.stackexchange.com/proposals/118484/mainframes.…

The hard part for mainframes is that unlike Linux and the BSDs, you can't acquire a bunch of 4 year old Core i5 systems for $80 each (or sometimes free) and install a bunch of different OS varieties on them to test stuff in your home office or the bedroom of a bored teenager (example: centos hosting KVM VMs, debian + xen, freebsd on bare metal, etc).

Don't forget that probably the only reason you can do a lot of that is because AT&T screwed up so badly legally back in the day, and lost many of their rights to Unix in the process. And if SCO had been successful in reasserting their rights to it not that long ago, you still might not be able to do it.

IBM, on the other hand, has always competently (and sometimes quite viciously) protected their products legally. They also have a massive patent portfolio, or at least they used to.

Re: Hello World on z/OS

#103
post #67
post #21

Earlier quoted context omitted.

One of my older coworkers told me that IBM used to have a travelling mainframe demo in the back of a truck. As part of this demo, they would start a big computation, and then reach into the mainframe and start pulling out RAM and entire CPUs straight from the sockets, while the thing kept right on computing.

The current "funfact" is that the on/off button on a Z-series machine is only designed to be used twice.

IPLing a Z-Series machine is some serious dark magick.

Re: Hello World on z/OS

#104

Earlier quoted context omitted.

The hard part for mainframes is that unlike Linux and the BSDs, you can't acquire a bunch of 4 year old Core i5 systems for $80 each (or sometimes free) and install a bunch of different OS varieties on them to test stuff in your home office or the bedroom of a bored teenager (example: centos hosting KVM VMs, debian + xen, freebsd on bare metal, etc).

Don't forget that probably the only reason you can do a lot of that is because AT&T screwed up so badly legally back in the day, and lost many of their rights to Unix in the process. And if SCO had been successful in reasserting their rights to it not that long ago, you still might not be able to do it. IBM, on the other hand, has always competently (and sometimes quite viciously) protected their products legally. Th…

> IBM, on the other hand, has always competently (and sometimes quite viciously) protected their products legally.

Viciously, perhaps.

Competently...well, the Wintel PC market—long ago “The IBM-compatible PC market” might be an indicator that they can fall down hard on that.

Re: Hello World on z/OS

#105

The mainframe infrastructure is both the core feature and showstopper bug of the platform. On the plus side, it has empowered countless core business applications to scale years, even decades, beyond their original development lifecycle. On the negative side, it has created a stagnant cult of mainframe “priests” who oversee a platform that most businesses would rather get rid of, if they could only figure out how. My…

If you listen to the folks over at Terminal Talk (http://terminaltalk.net), they routinely question the wisdom of all those server folks having to build out and maintain infrastructure that just comes built-in to the mainframe. And from what I gather a lot of those server folks (or at least their bosses) may be starting to question that now, too.

As for Facebook and Google and Netflix and so on, you have to remember that for all their claims of reliability and such, their stuff really only needs to be "good enough". But good enough generally just doesn't cut it when dealing with things like financials and such.

BTW, I have a colleague who works for a massive corporation - one that is still recovering from a ransomware attack which has so far cost them at least $300 million. They have thousands of servers, and she says that it has now become IT's full-time job just to keep those updated and patched. (There's apparently little or no time these days for silly little things like development and testing and code loads and such.) I didn't ask her if they are still planning to replace their few remaining mainframes (I'm guessing they're in no big hurry now), but she did tell me that upper management currently thinks that "The Cloud" may yet be their road to salvation.

Re: Hello World on z/OS

#106

The mainframe infrastructure is both the core feature and showstopper bug of the platform. On the plus side, it has empowered countless core business applications to scale years, even decades, beyond their original development lifecycle. On the negative side, it has created a stagnant cult of mainframe “priests” who oversee a platform that most businesses would rather get rid of, if they could only figure out how. My…

I think that, within the context of that story, both directors are missing the deeper issue: A company's technology decisions aren't just about the final state, they're also about getting the project bootstrapped, and all the other technology decisions between that point and the final state. So it's not just that Facebook had already done it their way, it's that, along the way, they never had any realistic alternativ…

> There's simply never going to be any point at which it makes sense for me to scrap everything I have so far and do a complete rewrite for a different platform.

Yet people still often claim that it makes sense to go to all the time and trouble and expense of moving off of reliable legacy platforms onto other platforms which aren't naturally anywhere near as reliable. Imagine that!

Re: Hello World on z/OS

#107
post #21

The mainframe infrastructure is both the core feature and showstopper bug of the platform. On the plus side, it has empowered countless core business applications to scale years, even decades, beyond their original development lifecycle. On the negative side, it has created a stagnant cult of mainframe “priests” who oversee a platform that most businesses would rather get rid of, if they could only figure out how. My…

One of my older coworkers told me that IBM used to have a travelling mainframe demo in the back of a truck. As part of this demo, they would start a big computation, and then reach into the mainframe and start pulling out RAM and entire CPUs straight from the sockets, while the thing kept right on computing.

And there are stories of IBM hardware surviving fires and floods and coming back to life after not much more than a minor cleanup and a reboot. I once personally dealt with an IBM system that got hit by lightning. It crashed and took its own sweet time coming back up but it did come back up, with no special intervention, having only lost a few RS-232 comm cards to the lightning.

Meanwhile, these days you have folks running "start of the art" systems which may just roll over and die for no discernible reason. These may not easily come back up, either, if at all. That's why they have to have so many of them!

Re: Hello World on z/OS

#108
post #47

Earlier quoted context omitted.

spark clusters still have a spof as far as I understand the architecture.

Two of them, I believe - the master for the cluster as a whole, and, for any individual job, its driver. I wasn't really meaning to say that a Spark cluster is as robust as a mainframe (though maybe someone's figured out some tricks), more that I could totally see some sales folks conducting the same demo using something like Spark.

If you're using Spark's built-in scheduler then the cluster manager is a SPOF. Hadoop docs say you can get active/standy ResourceManager, not that I've tried it. Spark can also use k8s and nomad to schedule executors, and those have HA modes as well. I assume Mesos does HA.

You're still boned if the driver dies. I am pretty sure that the driver keeps some important state in RAM so if the node hosting it goes down you have to restart from the beginning, even if the cluster manager restarts the driver.

Re: Hello World on z/OS

#109
post #67
post #21

Earlier quoted context omitted.

One of my older coworkers told me that IBM used to have a travelling mainframe demo in the back of a truck. As part of this demo, they would start a big computation, and then reach into the mainframe and start pulling out RAM and entire CPUs straight from the sockets, while the thing kept right on computing.

The current "funfact" is that the on/off button on a Z-series machine is only designed to be used twice.

Reminds me of an IBM technical bulletin I found, somehow, about 10 years ago. It advised that if you were moving from this z9 hardware configuration to that one, you would have 30 minutes of downtime. Implying that other changes required no downtime, which I inferred wasn't stated because it wasn't insanely awesome to mainframe guys, adding CPUs and RAM to a running system was just how things worked.

I was in college at the time and looked at job postings for mainframe programmers because I wanted to work on that. Never found one that required less than 5-10 years experience, not then and not when I've checked every couple years after that. Too bad; I quite liked the idea of working in an ecosystem that starts from "let's make this work every single time" instead of "let's make this work well enough to keep customer complaints to a dull roar".

Re: Hello World on z/OS

#110
post #88

The mainframe infrastructure is both the core feature and showstopper bug of the platform. On the plus side, it has empowered countless core business applications to scale years, even decades, beyond their original development lifecycle. On the negative side, it has created a stagnant cult of mainframe “priests” who oversee a platform that most businesses would rather get rid of, if they could only figure out how. My…

The sales job Amazon et al did in convincing the world resilience was the job of app developers, not the system vendor, was quite impressive. And while it's true that commodity folks could stand to learn from mainframe folks - serverless looks quite a lot like a forty years on re-invention of CICS if you squint a bit - your story reminds me how profoundly true the opposite is, as well. I've been part of a team that r…

Given what is currently known today (there may be more bombshells yet to come) about x86 system- and chip-level vulnerabilities, both unintentional and intentional, I'm not sure that any sane CxO would allow their data to come anywhere near the platform if they were starting all over today again from scratch. Not that I would necessarily trust any other vendor either (especially not Microsoft), but still ...

Always remember (and don't ever forget) that the only reason most of us have even heard of Intel and Microsoft is because of their relationship to IBM back in the day. They weren't chosen, nor did they ascend to great heights, based the quality of their products. Rather IBM chose them mostly for the sake of its own convenience, and then they leveraged that relationship to the hilt.

Post reply on HN