![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> http://fosspatents.blogspot.com/2010/08/western-civilization-runs-on-mainframe.html
I think the article makes it a bit unclear what "mainframe" means.
A cursory examination of wikipedia makes me think that mainframes are:
- mainly (if not even exclusively) used as servers or, in some cases, as
supercomputers,
- designed to be very scalable and be able to handle significant amounts
of users and/or traffic (or in the case of supercomputers, heavy-duty
processes), and
- designed on the hardware side to run uninterrupted even in the case of
partial hardware failure (meaning that most components are hot-swappable
and have redundancy).
In other words, they are very reliable big-ass servers aimed at having
zero downtime. Which sounds like a really important feature of big servers.
The article seems to talk like all mainframes dying has been something
expected for a long time, and that it's a big surprise that they are quite
alive and well, even today. This is probably a common sentiment (not just
exclusive to the author of this article, that is).
I don't really get it. Why are people expecting (if not even hoping)
for mainframes to quietly die? What would they be replaced with? If
mainframes are extremely *reliable* servers with zero downtime, wouldn't
it be in the interest of everybody that they *don't* die, and instead
their technology developed even further? What are you going to replace
them with? A PC (which would go down immediately when its PSU dies or its
HD gets a bad sector)? Why would that be a good thing?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: Weren't we talking about mainframes here?
Date: 2 Aug 2010 15:56:07
Message: <4c5722d7@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> What would they be replaced with?
A google-like cluster. Distributed processing.
Google is very reliable in its processing too, but it isn't transactional.
The thing that makes mainframes difficult to build is that they're both
reliable and transactional. You can clear 100,000,000 credit card
transactions an hour and not lose any. Contrast with Google, where when one
of their 5,000 PCs doing the anaylisis crashes, they start that bit up again
on a new PC. That doesn't work when you're trying to account for money in
real time.
And, too, it's I/O. The mainframe I worked on in college has 8-port RAM.
One port for each of the two CPUs, one port for the "slow I/O" of printer
and cards, one port for the tapes, and four ports for the disks. I think the
four for the disks were two for the large disks and two for the one fast
disk, which was damn impressive in itself. The fast disk had 6 heads per
track and rotated at something like 10,000 RPM, in spite of this being built
in the 70's and the disk being about two feet in diameter and looked like it
probably weighed 20 pounds just for the platter. It took something like 12
minutes to spin up and 18 minutes to spin down, if I recall.
The OS was arranged so that you could swap out several processes (for want
of a better word) and swap in another set all without rotational latency or
talking to the CPU. The kernel calculated the layout of swap pages on the
disk such that it left enough latency that when the job information table
got into memory (I don't know what Linux calls this, but it's basically the
slot in the table "ps" gets all its data from, the memory maps, etc)...
Well, the system arranged it so that when the job information table got into
memory, the CPU had enough time to service the interrupt and fill in the
list of pages where it wanted the rest of the process to be read into
memory, and then dispatch a disk controller to handle it, just as that first
page was coming under the head of the disk, and the shifting of the
electronics to read subsequent pages took just the right amount of time to
get the next sector under a read head. (Six heads per track, 8 or 16 sectors
per track, leaving about half a sector to switch heads before the next
sector hit.) Lots and lots and lots of care went into the IO processing.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
we were?
What this really shows me is that niches never die. People invent some new
activity/craftsmanship and 500 years from now there will still be people working
on it no matter how niche and irrelevant it is.
The other day I read this:
http://www.creativereview.co.uk/cr-blog/2010/july/the-helvetica-killer
it got me thinking how much importance font really design has. He makes some
passionate arguments that only a few colleagues from the same craft will truly
understand. How much more legible fonts should be than ancient roman font
engravings? In the end it's all a matter of personal taste, some experts
claiming this or that should be the ideal for this or that occasion.
So, font foundry has some 2000 years of history, even though in the end of day
it is a very irrelevant and personal thing. I'm sure some Cobol programmer some
500 years from now will still be making bold claims about the language.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> The OS was arranged so that you could swap out several processes (for want
> of a better word) and swap in another set all without rotational latency or
> talking to the CPU.
As I understand it (something I remember from the University), the most
reliable mainframes are quite complicated on both hardware and software
(well, the operating system) with respect to the CPUs (if there are multiple,
redundant CPUs which ensure uninterrupted uptime even if a CPU malfunctions).
If a CPU suddenly gets fried, first the hardware and then the OS have to
detect this and then the OS has to transparently transfer the process which
was currently being run on that faulty CPU to another one, *without the
program breaking* (in other words, the program doesn't even notice that
something went wrong).
I suppose that in the good old days when there were no caches nor
pipelines to speak of, this is relatively easy, as the OS could probably
keep track of the exact instruction where the process was going, and
simply "simulate" a context switch when it gets the signal that the CPU
went dead, and then transfer the process to another CPU as usual. However,
I assume that with modern CPUs, with all the parallel pipelines, microcodes,
out-of-order execution and such, this becomes quite a big challenge (and
probably makes the CPU design quite a lot more complicated, if it has to
be prepared for malfunction in this way).
That's the reason why you can't simply use a PC as a reliable mainframe.
I don't think Intel processors support anything like this. If a CPU fries,
you are more or less toast. (Or, in other words, you are going down, no
matter what, especially if the malfunction happens when the CPU is
executing some critical kernel code.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: Weren't we talking about mainframes here?
Date: 2 Aug 2010 16:22:56
Message: <4c572920@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> As I understand it (something I remember from the University), the most
> reliable mainframes are quite complicated on both hardware and software
> (well, the operating system) with respect to the CPUs (if there are multiple,
> redundant CPUs which ensure uninterrupted uptime even if a CPU malfunctions).
Yes. This is rather newer than my experience, tho. I never worked personally
with redundant hardware of that degree of correctness. Most of my bitching
about lack of correctness in the OS is simple operating system stuff, like
actually locking files when locked, not leaving temp files around if you
crash, not starving a write lock just because there are bunches of brief but
overlapping read locks, etc. The sort of thing that EINTR is symptomatic of.
> That's the reason why you can't simply use a PC as a reliable mainframe.
> I don't think Intel processors support anything like this. If a CPU fries,
> you are more or less toast. (Or, in other words, you are going down, no
> matter what, especially if the malfunction happens when the CPU is
> executing some critical kernel code.)
Yep. But you *can* get simulators, if you want to learn how to use the OS
that the mainframes run and such. (I can't imagine it's strictly POSIX on a
mainframe, even if they often run some variant of UNIX nowadays.)
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> 500 years from now will still be making bold claims about the language.
This one's a joke:
http://www.coboloncogs.org/INDEX.HTM
This one is cringingly real:
http://www.netcobol.com/info/whitepaper/oocoby2k.pdf
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> http://fosspatents.blogspot.com/2010/08/western-civilization-runs-on-mainframe.html
>
> I think the article makes it a bit unclear what "mainframe" means.
There isn't a concise or precise definition:
Mainframes are enterprise level (expensive reliable) machines that are
optimised for running large transactional workloads (more optimised for
processing huge amounts of data than performing complex calculations).
They have an obsession for backwards compatibility and most (~95%)
mainframes are IBM machines running an operating system based on the 40
year old System/370 and are backwards compatible with System/360.
> What are you going to replace
> them with? A PC (which would go down immediately when its PSU dies or its
> HD gets a bad sector)? Why would that be a good thing?
There are many PC based servers running *nix/Windows with redundant hot
swappable, power supplies, hard disks (ideally with battery backed
cache) and fans. These have pretty good reliability but are not
mainframes. They generally can't cope with CPU/Memory or board failures.
If you really care about availability you can run multiple redundant
servers (on different sites) or use a proper transactional system.
The thought was that it'd be cheaper to use several smaller cheaper less
proprietary machines to achieve what had previously been done with one
big mainframe. IBM would say it is cheaper and simpler to just run one
big expandable system, than lots of little systems.
The question raised by this story is why is IBM trying to squash
Hercules? Mainframes and their software provide a huge proportion of
IBM's revenue. One of the biggest problems IBM has with its mainframe
business is there are skill shortages, as few people know how to use
mainframes or have access to learn about them. An emulator would help
people get these skills but no-one would get very far trying to replace
a mainframe running on their laptop.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Verm wrote:
> there are skill shortages,
Another interesting article:
http://www.businessweek.com/technology/content/aug2010/tc2010082_274669.htm
Of course, once again businesses bitch and moan that universities aren't
teaching job-specific skills, instead of sucking it up and doing what every
company did before WW2 and just teach people the skills they need.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Verm wrote:
>> there are skill shortages,
>
> Another interesting article:
>
> http://www.businessweek.com/technology/content/aug2010/tc2010082_274669.htm
the comments were interesting too :-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Of course, once again businesses bitch and moan that universities aren't
> teaching job-specific skills, instead of sucking it up and doing what every
> company did before WW2 and just teach people the skills they need.
On that note, many do indeed have the view that Universities (besides all
the research and such) are not places where you learn a specific job (that's
what vocational schools are for), but instead they teach the basics which
help people learn any job (in the field they are studying) more easily. There
are basics that apply to most or all of the jobs in the field, and teaching
these basics makes the students more prepared to learn any of them (besides,
at least in theory, other more higher-level knowledge which helps them
do research and improve the field or industry, if so needed, which is why
there's more of an emphasis on the theoretical stuff).
Many people complain that universities/colleges don't prepare people for
the real world, for real jobs, but I'd say these people are missing the
point. In fact, the universities *are* preparing them, but at a more "meta"
level that, in the long run, is actually more helpful both to the student
himself and the industry as a whole.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |