Some interesting stats:

http://fosspatents.blogspot.com/2010/08/western-civilization-runs-on-mainframe.html

The links inside are interesting too.
-- 
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

Darren New <dne### [at] sanrrcom> 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

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

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

Darren New <dne### [at] sanrrcom> 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

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

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> 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

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

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