Don't forget to consider the mainframe has a much smaller enironmental
footprint that say 500 COTS.
The cost savings in power comsumption, air conditioning, and floor space
can be huge.

On Thu, May 25, 2017 at 10:21 AM, Willemina Konynenberg <w...@konynenberg.org
> wrote:

> But according to the datasheets, upgrading, say, an H06 to an H13
> "requires planned down time", so if you started small and then want to
> grow, the only feasible (non-down-time) upgrade path is to buy a 2nd
> mainframe, which, as you point out "won't scale painlessly".
>
>
> With a COTS based system, you work with a cluster configuration from the
> start (without requiring additional licenses), and have a rather more
> granular and disruption-free upgrade path.
> And because it is designed from the ground up as a cluster, it is
> designed to be maintainable WHILE WORKING.  Replacing any hardware
> component of the cluster (ECC memory, CPU, I/O board, main board,
> network component, rack, ...) can be done while the system is running.
>
> So there isn't really any *functional* advantage to using a mainframe.
> The question is whether you want to be running a cluster of, say, 2 - 5
> mainframes, or, say, 10 - 500 COTS boxen.  I.e. "what do you want to
> spend your money on".
>
> And no, you should not then have a bunch of sysadmins running around
> manually managing those 500 COTS boxen.  That's supposed to be automated...
>
>
> WFK
>
> On 05/25/17 16:22, John Campbell wrote:
> > As I recall from Appendix A of the "Linux for S/390" redbook, the S/390
> > (and, likely, zSeries) is designed to be maintainable WHILE WORKING.
> >
> > The multi-dimensional ECC memory allows a memory card to be replaced
> WHILE
> > the system is running.  Likewise, power supplies the CPs.
> >
> > I have to agree that the "second" zSeries box won't scale painlessly;
> The
> > work to load balance would NOT be fun (and the second box has its own
> > issues w/r/t the management team, too).
> >
> > I recall, when dealing with the idea of putting an S/390 into a Universal
> > Server Farm in Secaucus, NJ (I had some fun helping define the various
> > networks as this predated the "hyperchannel" within the BFI ("Big Iron")
> as
> > part of this USF integration) when it was killed for non-technical
> reasons.
> >
> > -soup
> >
> > On Thu, May 25, 2017 at 8:41 AM, Philipp Kern <pk...@debian.org> wrote:
> >
> >> On 24.05.2017 00:03, John Campbell wrote:
> >>> Cool...
> >>>
> >>> Though the real key is that the mainframe is designed for something at
> or
> >>> beyond five 9s (99.999%) uptime.
> >>>
> >>> [HUMOR]
> >>> Heard from a Tandem guy:  "Your application, as critical as it is, is
> on
> >> a
> >>> nine 5s (55.5555555%) platform."
> >>> [/HUMOR]
> >>
> >> Mostly you trade complexity in hardware with complexity in software.
> >> Mainframes do not scale limitless either, so you trade being able to
> >> grow your service by adding hardware with doing it within the boundaries
> >> of a sysplex.
> >>
> >> Your first statement is also imprecise. It's designed for five 9s
> >> excluding scheduled downtime. If you use the fact that hardware is
> >> unrealiable (after subtracting your grossly overstated unreliability) to
> >> your advantage, you end up with a system where any component can fail
> >> and it doesn't matter. You win.
> >>
> >> Again, it then comes down to the trade-off question if you're willing to
> >> pay for the smart software and the smart brains to maintain it rather
> >> than paying IBM to provide service for the mainframe.
> >>
> >> Kind regards
> >> Philipp Kern
> >>
> >> ----------------------------------------------------------------------
> >> For LINUX-390 subscribe / signoff / archive access instructions,
> >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390
> or
> >> visit
> >> http://www.marist.edu/htbin/wlvindex?LINUX-390
> >> ----------------------------------------------------------------------
> >> For more information on Linux on System z, visit
> >> http://wiki.linuxvm.org/
> >>
> >
> >
> >
> > --
> > John R. Campbell         Speaker to Machines          souperb at gmail
> dot
> > com
> > MacOS X proved it was easier to make Unix user-friendly than to fix
> Windows
> > "It doesn't matter how well-crafted a system is to eliminate errors;
> > Regardless
> >  of any and all checks and balances in place, all systems will fail
> because,
> >  somewhere, there is meat in the loop." - me
> >
> > ----------------------------------------------------------------------
> > For LINUX-390 subscribe / signoff / archive access instructions,
> > send email to lists...@vm.marist.edu with the message: INFO LINUX-390
> or visit
> > http://www.marist.edu/htbin/wlvindex?LINUX-390
> > ----------------------------------------------------------------------
> > For more information on Linux on System z, visit
> > http://wiki.linuxvm.org/
> >
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to