Do you see a point where a shift away from COBOL happens on a larger scale? In my field (nuclear), FORTRAN is still standard, but other languages are creeping in and making dents outside of...
Do you see a point where a shift away from COBOL happens on a larger scale? In my field (nuclear), FORTRAN is still standard, but other languages are creeping in and making dents outside of research and academia. Less people are learning FORTRAN which makes using it a potentially losing battle over time.
How often do you usually see companies upgrading mainframe hardware or getting new mainframes to replace operating ones? Rephrased, how long are mainframes usually designed to last?
One of the benefits (from what I gather) of having dedicated mainframes is that they are just handling a specific company's data/operations with redundancies for that data/operations. Does a company trying to move to a cloud environment complicate managing those resources since they may be shared across multiple companies and would it really be beneficial?
And I guess last question just for fun since it is IBM even though it's still early, are there already forays into how quantum computing may change how mainframe-type operations would have to occur?
Sorry if some of these questions seems misplaced, this is just something I have zero experience with. Thanks for your time!
So, bearing in mind I'm a "firmware" developer (what I work on, while it technically meets the definition of the firmware, because there's so much complexity, means that often what I'm doing is...
Exemplary
So, bearing in mind I'm a "firmware" developer (what I work on, while it technically meets the definition of the firmware, because there's so much complexity, means that often what I'm doing is just normal web development at the top layer, and communicating user inputs to lower levels of firmware via Java or C). There are literally thousands of people who work on System Z and my view is limited, but I'll share what I've heard from the actual smart people. Disclaimer that you should take everything I say with a grain of salt, my opinions are mine and not IBM's.
do you see a point where a shift away from COBOL happens on a larger scale? In my field (nuclear), FORTRAN is still standard, but other languages are creeping in and making dents outside of research and academia. Less people are learning FORTRAN which makes using it a potentially losing battle over time.
So, from what I understand of what I read internally (bearing in mind IBM has its own internal propaganda), typically what runs on Z in COBOL is "mission critical" high reliability software -- the type that would need to be replicated bug-for-bug in order to be migrated successfully. The head of "mainframe modernization" here talked about how often those efforts fail... I recall he spoke a bit about how he works with those clients, but I don't remember much of the details, since it's outside my wheelhouse. I vaguely remember him talking about IBM working to get a better developer environment for COBOL, including tools like VS Code, and the chicken-and-egg problem involved (ex: we tried several years ago to get a StackExchange for mainframes, but couldn't get the people, which means that it's harder to ask mainframe questions, so harder to learn, so fewer people have knowledge...)
How often do you usually see companies upgrading mainframe hardware or getting new mainframes to replace operating ones? Rephrased, how long are mainframes usually designed to last?
Again, disclaimer on limited viewpoint, internal propaganda. So I can definitely say the hardware is built with a crazy amount of resilience, just from what I've seen of the design, and the thoughtfulness around redundancy and testing for contingencies like earthquakes. I know there are some clients who seem to update every machine generation every few years. We got a presentation on the massive scaled environment of one such client (sorry, can't share details, trying to avoid breaking my NDA). I know that once a user does a power-on reset of a System Z (basically, power on, load firmware, create partitions) it's possible and even likely that they will not do so again for literal years. Vaguely, I've heard anecdotes of decades old systems that are still running, like the IRS's, but I don't know how normal that is or isn't.
One of the benefits (from what I gather) of having dedicated mainframes is that they are just handling a specific company's data/operations with redundancies for that data/operations. Does a company trying to move to a cloud environment complicate managing those resources since they may be shared across multiple companies and would it really be beneficial?
I'm not quite sure what you're asking here, it's definitely a security benefit when you are on your own dedicated hardware in your own locked down data center, though we do plan internally for the "Coke and Pepsi" scenario where a managed infrastructure provider might lease individual LPARs on one system to clients and making sure that data can't leak back and forth, even in the SE. There's definitely a level of trust a company needs to have when using cloud computing or really any shared computing resources.
And I guess last question just for fun since it is IBM even though it's still early, are there already forays into how quantum computing may change how mainframe-type operations would have to occur?
Absolutely! One of the big "line items" for last release was developing and implementing quantum safe cryptographic algorithms, and I know that IBM Research and IBM Systems (well, now IBM Infrastructure) are working closely together to prepare for and in the future, integrate quantum computing. How we quantum-proofed IBM z16
I'm sorry I couldn't give thorough answer to many of these, I really am just a peon, but I hope this was helpful?
Thank you for the response! It was definitely helpful and I understand that designing, building, and maintaining these types of systems requires an incredible amount of people with a lot of...
Thank you for the response! It was definitely helpful and I understand that designing, building, and maintaining these types of systems requires an incredible amount of people with a lot of knowledge in various topics. And thank you for the article on quantum-proofing, interesting read and the videos were a good watch. I'm curious to how quantum-computing may also change things beyond cryptography.
Sorry for the lack of clarity for my third question, but you touched on some of the points I was trying to get at. More directly, I was trying to ask, "If a company does want to move away from a dedicated/centralized mainframe that they solely use, what kinds of issues would arise?"
You touched briefly on the Coke/Pepsi example which is what I was thinking about. I was curious on what drawbacks and benefits you saw for a large company in using or not using mainframes.
Same disclaimer that a lot of my knowledge comes from internal sources, so of course they're going to say Z is always the best ever. I guess what that comes down to, is what are the flaws of what...
"If a company does want to move away from a dedicated/centralized mainframe that they solely use, what kinds of issues would arise?"
Same disclaimer that a lot of my knowledge comes from internal sources, so of course they're going to say Z is always the best ever.
I guess what that comes down to, is what are the flaws of what they move to relative to a mainframe? That's typical cloud provider managed commodity x86. It's more prone to downtime (still pretty good, but set up right, Z is the best you can get for resilience), there's less facilities and possibly no support for running your backbone code from 1972. I've seen claims internally that mainframes are more energy efficient, and are cheaper to run than paying for cloud services in the long term.
In exchange you get the benefits of x86, which (assuming good engineering, which can be hard) infinite scaling -- Z can scale quite well, but eventually you will need someone to install new hardware, easier geographic distribution of load/backups, less up front cost.
Another consideration for a migration is that you'll also run into some strangeness if you're licensing any software that's priced per-core. System Z cores are much bulkier than a comparable x86 commodity server core, so you'll pay less in licensing fees in that case with Z than x86
how quantum-computing may also change things beyond cryptography.
This is definitely not my area of expertise, but this article looks good?
I was surprised by this: "I/O is handled by two PCI Express 4.0 controllers." I wonder if the operating system still uses the SIO (start I/O) and related privileged instructions.
I was surprised by this: "I/O is handled by two PCI Express 4.0 controllers." I wonder if the operating system still uses the SIO (start I/O) and related privileged instructions.
I work with a few mainframes and yeah, we use these terminal emulators nowadays. They're pretty cool! The IBM Reflection one is my favorite, but BlueZone isn't too awful in certain settings.
I work with a few mainframes and yeah, we use these terminal emulators nowadays. They're pretty cool! The IBM Reflection one is my favorite, but BlueZone isn't too awful in certain settings.
I'm an IBMer, I work on System Z (mainframes) and I've actually met one of the people quoted in this article. Neat!
Anyone have any questions?
Sorry if some of these questions seems misplaced, this is just something I have zero experience with. Thanks for your time!
So, bearing in mind I'm a "firmware" developer (what I work on, while it technically meets the definition of the firmware, because there's so much complexity, means that often what I'm doing is just normal web development at the top layer, and communicating user inputs to lower levels of firmware via Java or C). There are literally thousands of people who work on System Z and my view is limited, but I'll share what I've heard from the actual smart people. Disclaimer that you should take everything I say with a grain of salt, my opinions are mine and not IBM's.
So, from what I understand of what I read internally (bearing in mind IBM has its own internal propaganda), typically what runs on Z in COBOL is "mission critical" high reliability software -- the type that would need to be replicated bug-for-bug in order to be migrated successfully. The head of "mainframe modernization" here talked about how often those efforts fail... I recall he spoke a bit about how he works with those clients, but I don't remember much of the details, since it's outside my wheelhouse. I vaguely remember him talking about IBM working to get a better developer environment for COBOL, including tools like VS Code, and the chicken-and-egg problem involved (ex: we tried several years ago to get a StackExchange for mainframes, but couldn't get the people, which means that it's harder to ask mainframe questions, so harder to learn, so fewer people have knowledge...)
Again, disclaimer on limited viewpoint, internal propaganda. So I can definitely say the hardware is built with a crazy amount of resilience, just from what I've seen of the design, and the thoughtfulness around redundancy and testing for contingencies like earthquakes. I know there are some clients who seem to update every machine generation every few years. We got a presentation on the massive scaled environment of one such client (sorry, can't share details, trying to avoid breaking my NDA). I know that once a user does a power-on reset of a System Z (basically, power on, load firmware, create partitions) it's possible and even likely that they will not do so again for literal years. Vaguely, I've heard anecdotes of decades old systems that are still running, like the IRS's, but I don't know how normal that is or isn't.
I'm not quite sure what you're asking here, it's definitely a security benefit when you are on your own dedicated hardware in your own locked down data center, though we do plan internally for the "Coke and Pepsi" scenario where a managed infrastructure provider might lease individual LPARs on one system to clients and making sure that data can't leak back and forth, even in the SE. There's definitely a level of trust a company needs to have when using cloud computing or really any shared computing resources.
Absolutely! One of the big "line items" for last release was developing and implementing quantum safe cryptographic algorithms, and I know that IBM Research and IBM Systems (well, now IBM Infrastructure) are working closely together to prepare for and in the future, integrate quantum computing. How we quantum-proofed IBM z16
I'm sorry I couldn't give thorough answer to many of these, I really am just a peon, but I hope this was helpful?
Thank you for the response! It was definitely helpful and I understand that designing, building, and maintaining these types of systems requires an incredible amount of people with a lot of knowledge in various topics. And thank you for the article on quantum-proofing, interesting read and the videos were a good watch. I'm curious to how quantum-computing may also change things beyond cryptography.
Sorry for the lack of clarity for my third question, but you touched on some of the points I was trying to get at. More directly, I was trying to ask, "If a company does want to move away from a dedicated/centralized mainframe that they solely use, what kinds of issues would arise?"
You touched briefly on the Coke/Pepsi example which is what I was thinking about. I was curious on what drawbacks and benefits you saw for a large company in using or not using mainframes.
Same disclaimer that a lot of my knowledge comes from internal sources, so of course they're going to say Z is always the best ever.
I guess what that comes down to, is what are the flaws of what they move to relative to a mainframe? That's typical cloud provider managed commodity x86. It's more prone to downtime (still pretty good, but set up right, Z is the best you can get for resilience), there's less facilities and possibly no support for running your backbone code from 1972. I've seen claims internally that mainframes are more energy efficient, and are cheaper to run than paying for cloud services in the long term.
In exchange you get the benefits of x86, which (assuming good engineering, which can be hard) infinite scaling -- Z can scale quite well, but eventually you will need someone to install new hardware, easier geographic distribution of load/backups, less up front cost.
Another consideration for a migration is that you'll also run into some strangeness if you're licensing any software that's priced per-core. System Z cores are much bulkier than a comparable x86 commodity server core, so you'll pay less in licensing fees in that case with Z than x86
This is definitely not my area of expertise, but this article looks good?
I was surprised by this: "I/O is handled by two PCI Express 4.0 controllers." I wonder if the operating system still uses the SIO (start I/O) and related privileged instructions.
I work with a few mainframes and yeah, we use these terminal emulators nowadays. They're pretty cool! The IBM Reflection one is my favorite, but BlueZone isn't too awful in certain settings.
I agree! All the weird commands and programming. I kind of stumbled into this world years ago, very glad I did.