| Re: IBM S/360 - 370 [message #396143 is a reply to message #396131] |
Thu, 25 June 2020 03:27   |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 25 Jun 2020 01:43:22 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
> It's not just the speed, it's the whole design that has enough
> redundancy to recover from nearly any possible failure. A Z system has
> hot spare CPUs that can take over for a failing one in the middle of
> an instruction. They similarly have multiple paths to I/O devices so
> if one fails, it can recover on the fly.
Of course a modern approach to reliable applications is to build
everything as a Docker swarm and let application level redundancy and
eventually consistent distributed storage keep things up. Devices fail,
systems fail, networks fail, whole countries fail and the applications keep
running - at least that's the idea.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: IBM S/360 - 370 [message #396146 is a reply to message #396131] |
Thu, 25 June 2020 04:42 |
Niklas Karlsson
Messages: 265
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>
> It's not just the speed, it's the whole design that has enough
> redundancy to recover from nearly any possible failure. A Z system has
> hot spare CPUs that can take over for a failing one in the middle of
> an instruction. They similarly have multiple paths to I/O devices so
> if one fails, it can recover on the fly.
Quite right. I believe it's said that you can swap an IBM mainframe out
entirely, piece by piece, without getting any interruption in service.
Niklas
--
Later I was talking to my bosses boss and this module came up. I remarked that
the module seemed to be written by someone with a disturbed mind. My bosses
boss was surprised. He knew the guy. He also knew that the original author was
currently in a mental institution. -- Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396147 is a reply to message #396146] |
Thu, 25 June 2020 05:50 |
|
|
Originally posted by: David Wade
On 25/06/2020 09:42, Niklas Karlsson wrote:
> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>
>> It's not just the speed, it's the whole design that has enough
>> redundancy to recover from nearly any possible failure. A Z system has
>> hot spare CPUs that can take over for a failing one in the middle of
>> an instruction. They similarly have multiple paths to I/O devices so
>> if one fails, it can recover on the fly.
>
> Quite right. I believe it's said that you can swap an IBM mainframe out
> entirely, piece by piece, without getting any interruption in service.
>
> Niklas
>
I don't believe this is true. It is possible with a VMWare ESXI cluster
and I have done it.
Dave
|
|
|
|
| Re: IBM S/360 - 370 [message #396148 is a reply to message #396147] |
Thu, 25 June 2020 05:53 |
|
|
Originally posted by: Bob Eager
On Thu, 25 Jun 2020 10:50:15 +0100, David Wade wrote:
> On 25/06/2020 09:42, Niklas Karlsson wrote:
>> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>>
>>> It's not just the speed, it's the whole design that has enough
>>> redundancy to recover from nearly any possible failure. A Z system has
>>> hot spare CPUs that can take over for a failing one in the middle of
>>> an instruction. They similarly have multiple paths to I/O devices so
>>> if one fails, it can recover on the fly.
>>
>> Quite right. I believe it's said that you can swap an IBM mainframe out
>> entirely, piece by piece, without getting any interruption in service.
>>
>> Niklas
>>
> I don't believe this is true. It is possible with a VMWare ESXI cluster
> and I have done it.
And indeed a VAXcluster.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: IBM S/360 - 370 [message #396159 is a reply to message #396148] |
Thu, 25 June 2020 11:05 |
scott
Messages: 4239
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Bob Eager <news0073@eager.cx> writes:
> On Thu, 25 Jun 2020 10:50:15 +0100, David Wade wrote:
>
>> On 25/06/2020 09:42, Niklas Karlsson wrote:
>>> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>>>
>>>> It's not just the speed, it's the whole design that has enough
>>>> redundancy to recover from nearly any possible failure. A Z system has
>>>> hot spare CPUs that can take over for a failing one in the middle of
>>>> an instruction. They similarly have multiple paths to I/O devices so
>>>> if one fails, it can recover on the fly.
>>>
>>> Quite right. I believe it's said that you can swap an IBM mainframe out
>>> entirely, piece by piece, without getting any interruption in service.
>>>
>>> Niklas
>>>
>> I don't believe this is true. It is possible with a VMWare ESXI cluster
>> and I have done it.
>
> And indeed a VAXcluster.
And Tandem, and Stratus.
|
|
|
|
| Re: IBM S/360 - 370 [message #396164 is a reply to message #396143] |
Thu, 25 June 2020 16:02 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <20200625082733.a0d21ca85223ea3f2d698fdc@eircom.net>,
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> Of course a modern approach to reliable applications is to build
> everything as a Docker swarm and let application level redundancy and
> eventually consistent distributed storage keep things up. Devices fail,
> systems fail, networks fail, whole countries fail and the applications keep
> running - at least that's the idea.
I would prefer that my bank not have an eventually consistent idea of
what my account balances are.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 [message #396170 is a reply to message #396164] |
Thu, 25 June 2020 18:54 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> In article <20200625082733.a0d21ca85223ea3f2d698fdc@eircom.net>,
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> Of course a modern approach to reliable applications is to build
>> everything as a Docker swarm and let application level redundancy and
>> eventually consistent distributed storage keep things up. Devices fail,
>> systems fail, networks fail, whole countries fail and the applications keep
>> running - at least that's the idea.
>
> I would prefer that my bank not have an eventually consistent idea of
> what my account balances are.
>
That’s about what I usually have.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396173 is a reply to message #396146] |
Thu, 25 June 2020 19:04 |
|
|
Originally posted by: J. Clarke
On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <anksil@yahoo.se> wrote:
> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>
>> It's not just the speed, it's the whole design that has enough
>> redundancy to recover from nearly any possible failure. A Z system has
>> hot spare CPUs that can take over for a failing one in the middle of
>> an instruction. They similarly have multiple paths to I/O devices so
>> if one fails, it can recover on the fly.
>
> Quite right. I believe it's said that you can swap an IBM mainframe out
> entirely, piece by piece, without getting any interruption in service.
If that were possible I'm sure there would be a demonstration
somewhere.
I have seen this demonstrated with a Tandem system, with a young lady
wearing little other than makeup and her rather nice conformation
removing half the boards from a machine, then one at a time putting
them back and removing the other half, with the machine not missing a
beat, with output scrolling by on a connected terminal the whole time.
She didn't replace the backplane, and for all I know the terminal was
connected to a CP/M machine hidden in a drawer, but it was a nice
show.
|
|
|
|
| Re: IBM S/360 - 370 [message #396179 is a reply to message #396173] |
Thu, 25 June 2020 21:29 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <anksil@yahoo.se> wrote:
>
>> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>>
>>> It's not just the speed, it's the whole design that has enough
>>> redundancy to recover from nearly any possible failure. A Z system has
>>> hot spare CPUs that can take over for a failing one in the middle of
>>> an instruction. They similarly have multiple paths to I/O devices so
>>> if one fails, it can recover on the fly.
>>
>> Quite right. I believe it's said that you can swap an IBM mainframe out
>> entirely, piece by piece, without getting any interruption in service.
>
> If that were possible I'm sure there would be a demonstration
> somewhere.
>
> I have seen this demonstrated with a Tandem system, with a young lady
> wearing little other than makeup and her rather nice conformation
> removing half the boards from a machine, then one at a time putting
> them back and removing the other half, with the machine not missing a
> beat, with output scrolling by on a connected terminal the whole time.
> She didn't replace the backplane, and for all I know the terminal was
> connected to a CP/M machine hidden in a drawer, but it was a nice
> show.
>
How could you watch the demonstration?
>
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396183 is a reply to message #396179] |
Thu, 25 June 2020 23:54 |
|
|
Originally posted by: J. Clarke
On Thu, 25 Jun 2020 18:29:24 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <anksil@yahoo.se> wrote:
>>
>>> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>>>
>>>> It's not just the speed, it's the whole design that has enough
>>>> redundancy to recover from nearly any possible failure. A Z system has
>>>> hot spare CPUs that can take over for a failing one in the middle of
>>>> an instruction. They similarly have multiple paths to I/O devices so
>>>> if one fails, it can recover on the fly.
>>>
>>> Quite right. I believe it's said that you can swap an IBM mainframe out
>>> entirely, piece by piece, without getting any interruption in service.
>>
>> If that were possible I'm sure there would be a demonstration
>> somewhere.
>>
>> I have seen this demonstrated with a Tandem system, with a young lady
>> wearing little other than makeup and her rather nice conformation
>> removing half the boards from a machine, then one at a time putting
>> them back and removing the other half, with the machine not missing a
>> beat, with output scrolling by on a connected terminal the whole time.
>> She didn't replace the backplane, and for all I know the terminal was
>> connected to a CP/M machine hidden in a drawer, but it was a nice
>> show.
>>
>
> How could you watch the demonstration?
She was well trained--she would move boards in front of the strategic
bits to make sure we saw them.
|
|
|
|
| Re: IBM S/360 - 370 [message #396186 is a reply to message #396170] |
Fri, 26 June 2020 01:59 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 25 Jun 2020 15:54:17 -0700
Peter Flass <peter_flass@yahoo.com> wrote:
> John Levine <johnl@taugh.com> wrote:
>> In article <20200625082733.a0d21ca85223ea3f2d698fdc@eircom.net>,
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>> Of course a modern approach to reliable applications is to build
>>> everything as a Docker swarm and let application level redundancy and
>>> eventually consistent distributed storage keep things up. Devices fail,
>>> systems fail, networks fail, whole countries fail and the applications
>>> keep running - at least that's the idea.
>>
>> I would prefer that my bank not have an eventually consistent idea of
>> what my account balances are.
>>
>
> That’s about what I usually have.
That is what eventual consistency means, multiple versions of the
data that will eventually all agree.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: IBM S/360 - 370 [message #396197 is a reply to message #396173] |
Fri, 26 June 2020 09:06 |
Niklas Karlsson
Messages: 265
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-06-25, J Clarke <jclarke.873638@gmail.com> wrote:
> On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <anksil@yahoo.se> wrote:
>
>> On 2020-06-25, John Levine <johnl@taugh.com> wrote:
>>>
>>> It's not just the speed, it's the whole design that has enough
>>> redundancy to recover from nearly any possible failure. A Z system has
>>> hot spare CPUs that can take over for a failing one in the middle of
>>> an instruction. They similarly have multiple paths to I/O devices so
>>> if one fails, it can recover on the fly.
>>
>> Quite right. I believe it's said that you can swap an IBM mainframe out
>> entirely, piece by piece, without getting any interruption in service.
>
> If that were possible I'm sure there would be a demonstration
> somewhere.
>
> I have seen this demonstrated with a Tandem system, with a young lady
> wearing little other than makeup and her rather nice conformation
> removing half the boards from a machine, then one at a time putting
> them back and removing the other half, with the machine not missing a
> beat, with output scrolling by on a connected terminal the whole time.
> She didn't replace the backplane, and for all I know the terminal was
> connected to a CP/M machine hidden in a drawer, but it was a nice
> show.
Yes, Tandem I can definitely believe. After all, that sort of thing is
basically the entire point of Tandem systems.
Niklas
--
if (!this->with_sin())
(int) stones[0];
-- Joe Pfeiffer's friend
|
|
|
|
| Re: IBM S/360 - 370 [message #396198 is a reply to message #396197] |
Fri, 26 June 2020 09:35 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 26 Jun 2020 13:06:46 GMT
Niklas Karlsson <anksil@yahoo.se> wrote:
> On 2020-06-25, J Clarke <jclarke.873638@gmail.com> wrote:
>> On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <anksil@yahoo.se> wrote:
>>
>> I have seen this demonstrated with a Tandem system, with a young lady
>> wearing little other than makeup and her rather nice conformation
>> removing half the boards from a machine, then one at a time putting
>> them back and removing the other half, with the machine not missing a
>> beat, with output scrolling by on a connected terminal the whole time.
>> She didn't replace the backplane, and for all I know the terminal was
>> connected to a CP/M machine hidden in a drawer, but it was a nice
>> show.
>
> Yes, Tandem I can definitely believe. After all, that sort of thing is
> basically the entire point of Tandem systems.
I heard tell of one Tandem system where you could pull a CPU or RAM
chip from the motherboard and the only visible effect would be the adjacent
fault LED starting to glow[1], and the only invisible effect would be some
performance degradation. Sadly I didn't get a chance to witness it only
hear (repeatedly) from someone who did and was mightily impressed.
[1] Yes it did go out when the part was replaced.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: IBM S/360 - 370 [message #396199 is a reply to message #396198] |
Fri, 26 June 2020 10:18 |
scott
Messages: 4239
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> writes:
> On 26 Jun 2020 13:06:46 GMT
> Niklas Karlsson <anksil@yahoo.se> wrote:
>
>> On 2020-06-25, J Clarke <jclarke.873638@gmail.com> wrote:
>>> On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <anksil@yahoo.se> wrote:
>>>
>>> I have seen this demonstrated with a Tandem system, with a young lady
>>> wearing little other than makeup and her rather nice conformation
>>> removing half the boards from a machine, then one at a time putting
>>> them back and removing the other half, with the machine not missing a
>>> beat, with output scrolling by on a connected terminal the whole time.
>>> She didn't replace the backplane, and for all I know the terminal was
>>> connected to a CP/M machine hidden in a drawer, but it was a nice
>>> show.
>>
>> Yes, Tandem I can definitely believe. After all, that sort of thing is
>> basically the entire point of Tandem systems.
>
> I heard tell of one Tandem system where you could pull a CPU or RAM
> chip from the motherboard and the only visible effect would be the adjacent
> fault LED starting to glow[1], and the only invisible effect would be some
> performance degradation. Sadly I didn't get a chance to witness it only
> hear (repeatedly) from someone who did and was mightily impressed.
A friend of mine was working for Tandem when systems started crashing
in Australia, and as the earth spun on its axis, the system crashes
progressed eastwards. It took about 14 hours for him and the team
to find and hotfix the firmware bug (related to wall-clock time).
As of 2014, Tandem systems ran on x86 CPUs.
|
|
|
|
| Re: TANDEM NON-STOP SYSTEMS [message #396223 is a reply to message #396173] |
Fri, 26 June 2020 22:50 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Friday, June 26, 2020 at 9:04:21 AM UTC+10, J. Clarke wrote:
> On 25 Jun 2020 08:42:46 GMT, Niklas Karlsson <a.....@yahoo.se> wrote:
>
>> On 2020-06-25, John Levine <j......@taugh.com> wrote:
>>>
>>> It's not just the speed, it's the whole design that has enough
>>> redundancy to recover from nearly any possible failure. A Z system has
>>> hot spare CPUs that can take over for a failing one in the middle of
>>> an instruction. They similarly have multiple paths to I/O devices so
>>> if one fails, it can recover on the fly.
>>
>> Quite right. I believe it's said that you can swap an IBM mainframe out
>> entirely, piece by piece, without getting any interruption in service.
>
> If that were possible I'm sure there would be a demonstration
> somewhere.
>
> I have seen this demonstrated with a Tandem system, with a young lady
> wearing little other than makeup and her rather nice conformation
> removing half the boards from a machine, then one at a time putting
> them back and removing the other half, with the machine not missing a
> beat, with output scrolling by on a connected terminal the whole time.
> She didn't replace the backplane, and for all I know the terminal was
> connected to a CP/M machine hidden in a drawer, but it was a nice
> show.
They were promoted as Tandem Non-stop Systems.
|
|
|
|
| Re: IBM S/360 - 370 [message #396225 is a reply to message #396059] |
Sat, 27 June 2020 00:59 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> z/Architecture has PC Program Call, PR Program Return.
> One instruction, but it has to do the same register save.
> My guess is it won't be any faster.
PC/PR was part 370/xa "access registers" (up to eight alternate address
space pointer control registers) ... alternate address space. when VS2
went from SVS (basically MVT in 16mbyte virtual memory, very similar to
running MVT under CP67 in 16mbyte virtual machine) to MVS with separate
16mbyte virtual address space per application ... they had enormous
problem with OS/360 pointer-based API. For kernel services they solved
it by mapping a 8mbyte kernel image into every application virtual
address space (kernel svc routine could directly address caller's
parameters).
However, there were still a lot of system services that were outside the
kernel, now resident in their own separate virtual address space. To
invoke it, the application made kernel call, which swapped address space
pointers and entered the non-kernel system services. The problem was
that those system services know had pointer to parameters back in the
caller's address sapce (not in the non-kernel system services address
space). A stop gap was they created "common segment area" ... a one mbyte
area that was mapped in every virtual address space (reducing
application to 7mbytes out of 16mbyes) ... API parameters would be
allocated in the CSA so that same parameter data area appeared in both
the application and the non-kernel system services address spaces at the
same address.
Problem was by 3033, late 370 ... MVS bloat required CSA size somewhat
proportional to number of concurrent applications and number of
non-kernel system services ... the CSA was now "common system area"
.... typically 5-6 mbytes at many installations (leaving 2-3mbytes for
applications) and threatening to increase to 8mbytes (leaving zero
mbytes for applications).
370/xa PC created hardware referenced kernel table with entries for
every (non-kernel system service) callable routine ... that included the
system service address space. PC would save the caller's address space
pointer, load the system services address space pointer and enter the
system service at specified address.
To go along with PC ... there were instructions where the system service
could fetch/store data from the callers address space ... rather than
addressing the system services address space.
It allowed moving all sorts of servicee & library code out of the
application address space ... and made the address space swap in
hardware (rather than kernel call) as well as allowing the system
service to access data in the caller's (different) address space.
PR then returned to the calling application address space (swapping
address space pointers in hardware rather than kernel call software).
Library routines in different address spaces could now be called almost
as fast as if they were in the same address space.
Program Call, pg 10-57
https://www.ibm.com/support/pages/sites/default/files/inline -files/SA22-7832-00.pdf
(Program Call) PC-number translation, starts on pg 5-27 and then
continues with the entry-table entry 5-30, and then (more) PC-number
translation 5-31, then linkage-table looking and entry-table lookup
(5-33)
https://www.ibm.com/support/pages/sites/default/files/inline -files/SA22-7832-00.pdf
now "home-address" and up to 15 "AR-specified address spaces), pg 3-16
and goes on for more than you would ever want to know
https://www.ibm.com/support/pages/sites/default/files/inline -files/SA22-7832-00.pdf
trivia: MVS also had another kind of bloat in 3033 area ... where real
storage requirements were exceeding 16mbytes (and system could page
thrash). real & virtual addressing was 24bit/16mbytes ... they came up
with hack for 3033 to use two unused bits in the page table entry ... to
prefix the 12bit 4kbyte page number ... allowing to "address" up to
64mbytes of 4kbyte pages. Instruction addressing was still limited to
24bit/16mbyte ... but a 24virtual address could be translated into a
26bit/64mbyte real address.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
Members
Search
Help
Register
Login
Home
