Mainframes are fast because each given "run time" (aka VM) has a fixed set of resources (aka Capabilities). Unlike the PC world, the default access is NO to any other files, etc.
We in the PC world keep reinventing our terms, the Mainframe folks just keep using the ones settled on decades ago.
You can run a VAX 11/780 in an Emulator, the same is true of many older Mainframes.
There's nothing magic about them, they're just optimized for throughput, in a very specific context.
The CS course I did in the 1980s had us use a Burroughs mainframe for the first year (complete with MCP) - I think this was a cunning ploy to make us really appreciate Unix when we got to use for the remaining three years....
I'm not sure "started" is the right word. To the degree it's "war", seems like the minor escalations have been regular ever since the VAX was released.
I bumped into some of this in the hobby world. I rescued a 1999 Multiprise 3000 from becoming scrap metal. It has no hard drives and it would be extraordinarily expensive to try to populate even the minimum. It could, though, be used using the IDE port on the PICMG-1.0 PC card, though. I got OS/2 up and running and sought help for the rest. One guy had tons of utilities he got from someone else, but plainly refused to even run a single ftp command. Another was helping, but wouldn't upload more than the bare minimum for each tiny step and quit right when it was time for the stuff needed to talk to the mainframe portion. Most other responses to inquiries, when anyone replied, was to cut IBM a check. It was a frustrating and fruitless effort.
I think that kind of stance is partly intentional on IBM's part. Right now it's practically impossible to develop viruses/ransomware/etc. for any mainframe product, so mainframe owners get security equivalent to commodity air gapped servers, even when it's connected to the internet.
Though behind firewalls of course.
Allowing hobbyists real software/firmware access will inevitably incentivize the creation of attacks since so much valuable financial data flows over mainframes, which everyone knows about.
Mainframes are locked into an antiquated IBM business model: charging by the CPU usage. This incentivizes writing code in Assembly, and prevented me from writing code in Java. They sell a “Java co processor” which is just an unmetered CPU for running JVM.
It’s an insular world in large part because of the pricing model that IBM/SAS doesn’t want to give up. No amount of claimed benefits can make adopting the mainframe a sane decision.
(I have very limited experience in Mainframe systems to take my comment with a grain of salt)
The problem as I see it is IBM wants to have its cake and eat it too. Typically a Mainframe is leased and then setup onsite. Under this model, it would seem that you would get unlimited use out of it because you’re paying for the power, and it’s literally on site. However by charging per CPU usage, even though you’re using it on site, you still treat it as a “cloud” appliance in terms of pricing
If I spin up something in AWS for example, it’s metered yes but that comes to be at the benefit of not having the machine on site and therefore not having to worry about it’s power, upkeep, etc.
It would be like a car company selling you a car and then charging you to drive it per mile.
Well isn't that because most IBM customers don't actually pay upfront for their mainframes, but instead effectively lease them? Car companies DO charge you per mile to drive a leased car beyond the standard allotment.
The difference here is that 'the cloud' like you mention is generalised across an industry of various companies. There may be some pain points moving between vendors but it can be done. Good luck trying to move off that mainframe.
> No amount of claimed benefits can make adopting the mainframe a sane decision.
I feel like engineering teams in payment and finance tech would like a word about this.
There are always extreme use cases that demand unconventional techniques. The stability of global financial networks is a fairly tough constraint to argue with.
Are there free resources for truly learning how to use and manage a mainframe? I would love to add "mainframe" to my resume, but I just don't have the understanding of where to start with it.
Let's say I were to get an emulator running, or somehow install a mainframe in my basement. Then what? What could an average person like myself do on a mainframe that would be useful and benefit me in terms of the job market?
I can download a Linux ISO and run anything I want to on a distributed system (x86 or ARM PC.) That type of tinkering is how I got my start/interest in technology to begin with. But it's not as though I'm about to process financial transactions in my basement for fun. How do you get started "tinkering" with mainframes?
There are open-source projects that attempt to do emulation of some of the larger mainframe systems (S/370, ESA/390, z) like [0] but you have a number of things working against you in that. You are more than likely not to find any newer version of, say, z/OS to run. Couple that with the fact that most mainframe programs deployed at FIs like core banking are so heavily customized commercial packages to fit an individual institution's needs, Hogan and similar [1], that they might as well be bespoke, internally developed systems. You may be able to get away with learning the basics of CICS [2] but it would be a struggle, not near as easy as fetching a linux distro ISO.
That said, I personally think that the Z architecture is completely bonkers and I would love the opportunity, like you, to learn it more in depth. My info above comes second-hand from what I've been able to piece together in my own searches.
This is a pretty reasonable synopsis. Read my other comment in this thread for related info.
"Z architecture" isn't all that different from the Linux for MVS integration, so it's not all that bonkers. Trying to understand mainframes in terms of Unix/Linux is totally bonkers, though.
I can't say for today, but back in the 90's I spent some time in California (I'm from Toronto) on a mainframe course. The reason was that I had to basically rent time on a mainframe in order to do any of the exercises, and understandably nobody was willing to open a terminal to their mainframe across the Internet "for educational purposes only".
I then worked a bit with IBM (in Poughkeepsie, NY) getting Linux on MVS working securely before it was released as a product, and I haven't touched a mainframe since. </background>
The Unix world and mainframe world are so different that you couldn't really just throw an emulator on a Linux box and be able to get anywhere professionally with it. Even the lingo is not compatible. There is next to nothing from the Unix world that you could apply to mainframes. You will have insurmountable gaps in your knowledge without full immersion. Talk to a mainframer about buffer overflows, and you'll realize right away that you are on completely different planets.
AFAIK there are still no full MVS emulators for Linux because of the sheer mountain of "stuff" that would need to go into it. You can certainly learn the scripting languages with emulators, though. So there is that. But your lingo and even understanding of how things connect would still suffer greatly if you think of the concepts from a Unix/Linux point of view. They are not compatible.
Having said all that, because there is Linux on MVS, in theory you should be able to use it as a familiar terminal. But then your only access is through getmvs which still keeps you much too distant from the iron to call it mainframe experience. And it is unlikely anyone's going to open up a terminal to the Internet, as it was for me back then, too. There is way too high a financial risk involved.
Things may have changed since then, but mainframes really don't change very much even across decades. I think getting Linux running in a VM was probably shocking to the entire mainframe world when it was first released. Banks gobbled it up though, so it was quite a smart move.
I believe cloud computing has totally taken over and removed any benefit there was in that particular area now, though.
My expectation is that you'd still need to rent mainframe time slices, and go full immersion if you want to get "Mainframe" on your resume. Otherwise you might have to lower your bar a little, and stick to some of the batch processing languages instead.
z/PDT and zD&T will run current z/OS under emulation on Linux. The ADCD for use with those products includes almost all the IBM software you'd come across in a mainframe environment:
A friend of mine recently left a mainframe assembler programming job. They didn't want to get stuck as a mainframe assembler programmer. They were part the first batch of new hires the company had made in over 10 years for the role. The company didn't pay like they wanted to keep their talent though. And, to top it off, a high level execs criticized growth in that product: "it's in the wrong bucket!".
31 comments
[ 3.4 ms ] story [ 68.3 ms ] threadWe in the PC world keep reinventing our terms, the Mainframe folks just keep using the ones settled on decades ago.
You can run a VAX 11/780 in an Emulator, the same is true of many older Mainframes.
There's nothing magic about them, they're just optimized for throughput, in a very specific context.
The VAX 9000 range tried to become mainframes, and the effort to make them bankrupted DEC.
But there are non-IBM mainframes. They do run under emulation on x86, but they are still real. Unisys Clearpath, for instance.
I started out on VAXen before I learned DOS or Xenix, and frankly, I preferred it.
File versioning was wonderful and with that as a basis, we'd never have needed the vile baroque mess that is Git.
https://en.wikipedia.org/wiki/CANDE
Allowing hobbyists real software/firmware access will inevitably incentivize the creation of attacks since so much valuable financial data flows over mainframes, which everyone knows about.
It’s an insular world in large part because of the pricing model that IBM/SAS doesn’t want to give up. No amount of claimed benefits can make adopting the mainframe a sane decision.
As opposed to more modern platforms, like the cloud!
The problem as I see it is IBM wants to have its cake and eat it too. Typically a Mainframe is leased and then setup onsite. Under this model, it would seem that you would get unlimited use out of it because you’re paying for the power, and it’s literally on site. However by charging per CPU usage, even though you’re using it on site, you still treat it as a “cloud” appliance in terms of pricing
If I spin up something in AWS for example, it’s metered yes but that comes to be at the benefit of not having the machine on site and therefore not having to worry about it’s power, upkeep, etc.
It would be like a car company selling you a car and then charging you to drive it per mile.
I think your comparing apples to oranges here.
Go and Rust can compile for Linux on s390x (64-bit zArch). Support for the proprietary zOS platform might be more of a challenge.
https://www.ibm.com/products/open-enterprise-sdk-go-zos
I feel like engineering teams in payment and finance tech would like a word about this.
There are always extreme use cases that demand unconventional techniques. The stability of global financial networks is a fairly tough constraint to argue with.
Let's say I were to get an emulator running, or somehow install a mainframe in my basement. Then what? What could an average person like myself do on a mainframe that would be useful and benefit me in terms of the job market?
I can download a Linux ISO and run anything I want to on a distributed system (x86 or ARM PC.) That type of tinkering is how I got my start/interest in technology to begin with. But it's not as though I'm about to process financial transactions in my basement for fun. How do you get started "tinkering" with mainframes?
That said, I personally think that the Z architecture is completely bonkers and I would love the opportunity, like you, to learn it more in depth. My info above comes second-hand from what I've been able to piece together in my own searches.
[0] http://www.hercules-390.eu/ [1] https://www.luxoft.com/banking/core-banking/ [2] https://en.wikipedia.org/wiki/CICS , https://www.redbooks.ibm.com/abstracts/sg247952.html?Open
"Z architecture" isn't all that different from the Linux for MVS integration, so it's not all that bonkers. Trying to understand mainframes in terms of Unix/Linux is totally bonkers, though.
I then worked a bit with IBM (in Poughkeepsie, NY) getting Linux on MVS working securely before it was released as a product, and I haven't touched a mainframe since. </background>
The Unix world and mainframe world are so different that you couldn't really just throw an emulator on a Linux box and be able to get anywhere professionally with it. Even the lingo is not compatible. There is next to nothing from the Unix world that you could apply to mainframes. You will have insurmountable gaps in your knowledge without full immersion. Talk to a mainframer about buffer overflows, and you'll realize right away that you are on completely different planets.
AFAIK there are still no full MVS emulators for Linux because of the sheer mountain of "stuff" that would need to go into it. You can certainly learn the scripting languages with emulators, though. So there is that. But your lingo and even understanding of how things connect would still suffer greatly if you think of the concepts from a Unix/Linux point of view. They are not compatible.
Having said all that, because there is Linux on MVS, in theory you should be able to use it as a familiar terminal. But then your only access is through getmvs which still keeps you much too distant from the iron to call it mainframe experience. And it is unlikely anyone's going to open up a terminal to the Internet, as it was for me back then, too. There is way too high a financial risk involved.
Things may have changed since then, but mainframes really don't change very much even across decades. I think getting Linux running in a VM was probably shocking to the entire mainframe world when it was first released. Banks gobbled it up though, so it was quite a smart move.
I believe cloud computing has totally taken over and removed any benefit there was in that particular area now, though.
My expectation is that you'd still need to rent mainframe time slices, and go full immersion if you want to get "Mainframe" on your resume. Otherwise you might have to lower your bar a little, and stick to some of the batch processing languages instead.
http://dtsc.dfw.ibm.com/adcd/adcd.shtml
https://www.youtube.com/watch?v=tI5jk-1OI-g
https://ibm.github.io/zdt-learners-edition-about/
https://ibmzxplore.influitive.com/users/sign_in
Also a bunch of free courses here:
https://learn.ibm.com/
(free registration required)
(EDIT) If you're in the US and meet the requirements (take free courses) you might also be interested in this for (I believe) $120/year:
https://ibm.github.io/zdt-learners-edition-about/
Email in profile if you want to know more.
Heck, at this point, what developer who hadn't worked on mainframes before would decide to go into mainframe development?