 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> >> Files only on disk? Or on tape too?
> >
> > Obviously tape files were contiguous. I must be misunderstanding what
> > you're asking.
>
> From what little I've seen, with punch cards it's a case of "please
> read this bunch of cards". You don't have filenames or anything.
> Presumably on magnetic disk you have a file *system* which describes
> logical files with names and things. I'm asking whether the same holds
> for tape, or whether it's just treated as an endless stream of bytes (or
> records or whatever).
If the mag tape has standard labels, the file attributes are defined in the tape
label header record. The tape label also contains the last 18 characters of the
dataset name. If its an unlabeled tape, it has no tape label headers, so the
program has to have the attributes hard coded in the source code. 98% of all
the tape we process are created internally. We have a tape management system
that keeps track of what dataset is on what tape volume. If the operator mounts
the wrong tape, it will be rejected and the operator will be re-prompted to
mount the right tape. If its an external tape we just tell the TMS to bypass
validity checking.
>
> >> OK. But does the system know where the *fields* in a record are? Or
> >> just what size the records are?
> >
> > You compiled it into the program. Often when they weren't actually fixed
> > size, they were fixed size anyway and padded (like cards). Or the size
> > was stored in the header of the file.
>
> Right. So it's a property of the program, not the system.
Yes, typically the record structure is defined in an include file, much like C.
Thus a common record format is available to all programs that access that file.
>
> >> Yeah, I think the term "mainframe" is probably obsolete now. There are
> >> probably more exact ways to describe what type of computer you mean.
> >
> > Could be. There's something clearly between "small" and "large" now.
>
> Minicomputers! :-D
There can be so much overlap in performance of PCs, Minis, and mainframes, it
can still be difficult to classify where a particular machine goes.
>
> --
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*
Isaac
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> Now that's reliability engineering for ya.
> >
> > Indeed. That's another important differentiation.
>
> Even today, I see people selling "servers" which are really like
> "desktops". (1.2 GHz Intel Celeron with 512 MB RAM? I don't think so...)
>
> I think the "real" difference between a desktop and a server is probably
> fault-tolerance. When I first joined the 2-bit company I'm with now, we
> had a server with a 500 MHz AMD Thunderbird CPU and 128 MB RAM. Now we
> also had 4 GHz Intel Pentium IV workstations with 256 MB RAM in the lab,
> which makes a bit of a mockary of the "server" tag. But the lab PCs
> didn't have multiple Ultra320 SCSI HDs, hardware RAID controllers,
> redundant PSUs or 30,000 cooling fans. But the "servers" did. ;-)
>
> (Seriously, it didn't have 30,000 cooling fans, but it did have *a lot*
> Probably way, way more than necessary, IMHO...)
>
> The HP ProLiant I was briefly in charge of was really nice, actually. It
> had a little diagram on the front showing the system board, and a little
> red LED for every component on it for which a failure sensor exists.
>
> It has ECC RAM, and yet it has multiple RAM banks, and it can compare
> them and tell you if one RAM bank is faulty. (I gather this works in up
> to a 4-way configuration, for 4x RAM redundancy, in case the ECC doesn't
> catch it. Oh, and the RAM is hot-swap. HOT-SWAP!)
>
> It also has more fans than it is sane for any one device to have...
> although... it is quite a small form-factor, so maybe it does need it,
> actually.
>
> Also has hot-swap HD bays with indicator lights. The RAID software even
> has a function to make the lights change colour so you can yank the
> correct unit. (Nice!)
>
> And as if all that wasn't enough, there's a second computer inside it
> which you can use remotely to manage the server. Do stuff like see the
> video output, control the keyboard and mouse, and even make the main
> computer think there's a CD in the drive when really it's an ISO image
> you're serving from your remote control PC. So you literally turn the
> server on and off, fiddle with the BIOS and install the OS, all without
> ever physically being in the same country.
>
> Some day I may own a desktop computer which makes this server's dual
> quad-core Xeons seem puny and pathetic. But it won't have reliability
> and management features like a "server" does.
>
> --
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*
Reliability and redundancy is one of the strong points of IBMs last few
generations of mainframes. If any page of memory fails, the error can be
corrected, if it is a hard error, that page of memory will be automatically
taken offline. If a processor fails, there are spare processors that can take
over and continue the operation if one fails. Multiple paths to all i/o devices
where possible. Of course redundant power supplies. Much of the machines
circuitry has redundant components. When a component fails, the machine phones
home and reports the failure. Many time operations is completely unaware of any
problem until an IBM CE shows up at the door with a replacement part in hand.
And many components can be replaced on the fly, with out any downtime. The
latest machines are not totally fault tolerant, but each new generation is
better than the last. I think the latest z/9 and z/10 models have a MTBF of
over 30 years.
Isaac
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Clarence1898 wrote:
> Yes, typically the record structure is defined in an include file, much like C.
Heh. More like a COBOL file division. ;-)
"Hand me the stack of cards for the payroll file definition."
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/05/2010 11:34 PM, Gilles Tran wrote:
> Now he had to use a regular keyboard just like a secretary and type
> lists of foreign-looking commands that didn't make any sense. He hated
> that.
>
typing their letters and keeping their own diaries. I think it was in
1996 when I overheard an office worker talking about her C: drive, in
the street. Before that it was just geeks who knew about those things.
--
Best Regards,
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Then why are you using the American billion above?
Because he doesn't realise he is using the same billions as America (as have
the rest of the UK for a few decades now).
I wonder if there are actually any English-speaking countries that use 1
billion = 1e12? If you see "billion" written (in English) then you can
probably assume it is 1e9.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It still slightly frightens me that Haskell is actually this old...
>> Just think how much better the world could be today if its ideas had
>> caught on back then?
>
> A lot of the stuff you take for granted wasn't possible back then.
>
> It's like "how much cooler would movies be if the ideas behind modern
> GPUs caught on back when we were still using discrete transistors and
> core memory?"
A GPU isn't much use without the ability to actually display the image
it produces. (Hell, they didn't even have enough memory to implement a
framebuffer. You'd have to print the image on to film incrimentally or
something.) And given that they also didn't have colour TV yet... or
even colour film, IIRC...
A paradigm for writing mathematical transformations, however, would seem
useful no matter how slow the system is. (Although compiling the sucker
might take a while.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yes, typically the record structure is defined in an include file,
>> much like C.
>
> Heh. More like a COBOL file division. ;-)
>
> "Hand me the stack of cards for the payroll file definition."
Suddenly Pascal makes so much more sense... o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Yes. That's why DEL is up at 127. Think about it.
>>
>> Oh... oh dear god. You *are* kidding me, right??
>
> He is not. It the smart thing to do. Is it not?
Chances of making the new holes line up with the existing ones? Minimal. :-S
> Oh! on second thoughts you could glue the chad back into the holes. :-P
Or just, say, print a new card? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Yes. That's why DEL is up at 127. Think about it.
>>
>> Oh... oh dear god. You *are* kidding me, right??
>
> He is not. It the smart thing to do. Is it not?
But the really scary part, of course, is that today, 60 years later, the
DEL code-point is *still defined* and still has the same value. WTF is
up with *that*?!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Then why are you using the American billion above?
>
> Because he doesn't realise he is using the same billions as America (as
> have the rest of the UK for a few decades now).
More exactly, I didn't realise that that is how Wolfram Alpha would
interpret it.
> I wonder if there are actually any English-speaking countries that use 1
> billion = 1e12? If you see "billion" written (in English) then you can
> probably assume it is 1e9.
I always assumed that 1 billion = 1 million million.
The solution, of course, is to simply never use the word "billion". Then
there can be no ambiguity. (Possibly the one and only grammar suggestion
from MS Word that actually makes sense...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
