Mainframe, MVS and zOS Discussion

Hi,

How does the High Availability in mainframes is achieved?

We know that everyone says that mainframes are highly available and very stable but let's assume the system goes down - is there a concept of running a "passive system" in mainframe in prod, in parallel to the "active" one?

Hello.

The kind of redundancy that you're looking at would best be implemented through Parallel Sysplex rather than having an idle mainframe sitting around doing nothing. If you have a mainframe, then it has costs in the form of hardware maintenance, software maintenance, software licensing and power consumption (both by the machine itself and the air conditioning). Rather than having the machine sitting around doing nothing, connecting it into a Parallel Sysplex would allow it to accept work rather than idling meaning you'd get more benefit from the hardware for the money that you're paying for it.

The basic concept is that your workload gets distributed across the two (or upto 32!) systems depending upon where the resources are available to run it. So, for instance, say I have two machines, A and B. Submit a job and it could run on either machine depending on what the current workload is. If I shut JES2 down on machine A, any jobs that are queued get started on machine B because it's initiators are still running; the sysplex adapts. In the event that one of the machines fails, then the other will keep going. Yes, the remaining machine will detect that the other one has gone, but it will be able to carry on running the workload that was previously distributed across the two machines. You can even exploit this in the application of service by cycling each machine in the sysplex in sequence resulting in zero downtime.

Another thing you can do is Geographically Dispersed Parallel Sysplex (GDPS). In this scenario, your hardware is not all at one site; the machines could be miles apart. Each system is wired into the sysplex as before (but at distance) and you also have your disks connected and mirroring. This deals with the situation where your systems have to keep running come man-made or natural disaster as your processing power and data are duplicated across distant sites thus increasing the resilliance of the sysplex.

That reliability is designed in to both the hardware and software from the ground up.   First of all, it's very unusual for a mainframe LPAR to just "go down".   Everything about the hardware and software is designed to be resilient, self-recovering, and protect itself against "bad" actors.    For example, in the 50+ year history of the mainframe there has been exactly ONE instance of a mainframe being "hacked" that exploited some vulnerability and did not involve some form of social engineering to gain an 'insider's" access credentials, and that vulnerability in the platform was immediately closed by IBM. 

There are many shops all around the world that only re-IPL  (i.e. "reboot") an LPAR every few MONTHS, and then only on a scheduled basis for the purpose of installing maintenance to the hardware or software.    It's also common for shops to design their entire complex for recovery.  For instance in a parallel sysplex environment  (multiple LPARS connected via coupling facility) the online and batch workloads are configured such that they can be executed on any of the LPAR's in the 'plex.    This allows true 24/7/365 availability for the entire business.  "Maintenance windows" are scheduled to occur during periods of low system demand which allows workload on an LPAR that is being taken down for maintenance to be shifted to other LPAR's in the 'plex. 

We've gotten to the point now where every "update" from companies like Microsoft is a nail-biter because it's commonplace for a 'fix' to break more things than it corrects.  It's painfully obvious that testing is not sufficient and also that the teams responsible for the different system components are NOT talking with each other to identify and resolve cross-product dependencies, and there is no feedback mechanism for customers to report problems that works very well.

Not the case in the mainframe world.   Even the mechanism for installing maintenance (SMP/E) tracks dependencies between components, pre-requisite and co-requisite fixes, and has an integral mechanism to import and update information about fixes in which defects have been discovered subsequent to release (HOLDDATA) that is updated by IBM on a daily basis and can be imported into SMP/E.   At this point IBM may be the only company in the world that still subjects everything to rigorous internal unit and integration testing prior to release.  Plus IBM provides a standard web mechanism for customers to report problems, search for known problems and resolutions, and work with support/developer teams to correct problems.  Customers can tag reports with different severity levels according to impact which get used to prioritize response, and incident reports that customers open are actually bi-directional(!) - when you open a problem, support teams actually respond, peranally, on the ticket (!) and provide periodic updates on progress (!).   "Severity 1" issues, the most impactful, can get worked by advanced support 24/7 continuously until there is a resolution.   Try getting THAT from any other vendor.