EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: MK14 on August 28, 2016, 03:55:10 pm
-
This video (approx 45 minutes long), is about an 18 year old, who decides to buy and get working, a somewhat vintage IBM Mainframe computer (IBM z890).
https://www.youtube.com/watch?v=45X4VP8CGtk (https://www.youtube.com/watch?v=45X4VP8CGtk)
EDIT:
Unknown to me, until AFTER I made this thread. This video was linked to on the second page of the following thread, from a few months ago.
https://www.eevblog.com/forum/chat/us-nuclear-force-still-uses-floppy-disks/ (https://www.eevblog.com/forum/chat/us-nuclear-force-still-uses-floppy-disks/)
-
That's pretty cool. :-+ His Twitter has some good stuff going on. Appears he's going to be interning at IBM. :)
https://twitter.com/connorkrukosky
-
Pfffft! I thought we were talking about a proper mainframe! One with loads of toggle switches, flashing lights, and spinning reel-to-reel tapes! :(
-
Pfffft! I thought we were talking about a proper mainframe! One with loads of toggle switches, flashing lights, and spinning reel-to-reel tapes! :(
Me too. I figured something like a DEC PDP-10 or even PDP-8. I am dissapoint - this thing still seems viable! :-DD
-
That's pretty cool. :-+ His Twitter has some good stuff going on. Appears he's going to be interning at IBM. :)
https://twitter.com/connorkrukosky (https://twitter.com/connorkrukosky)
Thanks. I especially enjoyed looking at the assembly language programming guide, linked to via your link.
http://www.cbttape.org/ftp/asmbook/alnv200.pdf (http://www.cbttape.org/ftp/asmbook/alnv200.pdf)
Pfffft! I thought we were talking about a proper mainframe! One with loads of toggle switches, flashing lights, and spinning reel-to-reel tapes! :(
Me too. I figured something like a DEC PDP-10 or even PDP-8. I am dissapoint - this thing still seems viable! :-DD
Replying to BOTH of you, at the same time. I agree, sorry!
(But the PDP-8 was more of a mini-computer, I thought).
Here's one example of a "real" mainframe computer, then...
https://en.wikipedia.org/wiki/IBM_7090 (https://en.wikipedia.org/wiki/IBM_7090)
(Which is mentioned in the manual I linked to, earlier in this post).
IBM_7090 circa 1961 as regards the photo.
(https://upload.wikimedia.org/wikipedia/commons/9/94/IBM_7090_computer.jpg)
-
Pfffft! I thought we were talking about a proper mainframe! One with loads of toggle switches, flashing lights, and spinning reel-to-reel tapes! :(
An IBM Z-series even a relatively small one like a z890 IS a real mainframe. The lights and toggle switches have been replaced by a laptop or perhaps in those days a desktop running OS/2. Spinning tapes were largely superceded by small enclosed tape cartridges and most large sites would have had a robot to insert the tapes. Aside from looking through a viewing window for the purpose of impressing the curious and those that paid for it there was nothing to see.
What amazes me is why an 18yo would even be interested or even know a machine that was obsolete about the time he was born existed.
Still giving him :-+ for the effort. The world needs more people too silly to know something can't or shouldn't be done. He carries the enthusiastic nerd character quite well.
Yes, I'm also extremely impressed with the initiative and hard work, he has put in for that project.
He has amazing parents as well. Not many would say something on the lines of, "Don't worry about the 2.2 Ton, massive Mainframe being too big for the door openings and entrances. We can use the big digger, to make a huge hole in the ground, to fit it in, to the basement".
Most (>99%, I guess), would say "NO".
He seems to have skills in life, which can/would be very useful in business to get difficult/tricky/problematic stuff sorted out. He seems to solve problems, rather than letting them put him off.
But I also worry, that in 10 years time, he might appear on one of those hoarders, programs. He does seem to be showing early signs of over collecting, stuff. In fairness, he does at least try and get them to work. But it does seem overly cluttered, even now, to me, at least.
-
I'd like one of these myself
https://en.wikipedia.org/wiki/IBM_1360
-
I'd like one of these myself
https://en.wikipedia.org/wiki/IBM_1360
Thanks, that made an interesting read. So they managed to sell, zero of the 1350's.
A one terrabit, storage device, is rather amazing, for 1961 (or so).
I learnt a new word, from that article. Boustrophedon.
I can't even pronounce it, let alone know what it means. Before reading about what it means, which I still only partially understand.
-
It means reading left to right, then right to left, so no "retrace" of the eyes.
-
It means reading left to right, then right to left, so no "retrace" of the eyes.
That makes sense. Because I have been brought up with English (typical in the UK), we have a bit of difficulty with some words, even if they are English. Because they are really German or French (etc, Germanic). So people who use other languages, can be at a distinct advantage, with words like that.
E.g. En Passant in Chess, is distinctly NOT English (it's from French, but perfectly allowable in English, these days), in principal.
Some of the (now mostly obsolete) dot matrix printers use to do that (writing onto the paper, rather than reading from it), bidirectional, to help speed up the printing.
TV's (UK) PAL, does something similar, where each scan line (in the now obsolete analogue TV transmission system), alternates.
PAL = Phase Alternating (by) Line. Old VHS (and maybe other systems) video cassette recorders, did similar, to minimize the interference, between adjacent helical writes on the tape.
But maybe in the strict definition of the word, my examples are invalid, as it maybe is strictly for eye scanning and/or reading ?
-
That's pretty cool. :-+ His Twitter has some good stuff going on. Appears he's going to be interning at IBM. :)
https://twitter.com/connorkrukosky (https://twitter.com/connorkrukosky)
Thanks. I especially enjoyed looking at the assembly language programming guide, linked to via your link.
http://www.cbttape.org/ftp/asmbook/alnv200.pdf (http://www.cbttape.org/ftp/asmbook/alnv200.pdf)
Yeah, thanks for posting the vid. :-+
-
When we were teens, a friend of mine picked up a VAX (https://en.wikipedia.org/wiki/VAX (https://en.wikipedia.org/wiki/VAX))... this was back in the early 1990's. Now that was a mainframe!
Sadly, this is where they all end up... While it is amazing to pick up an old machine and learn to get it running, once you do so it is best left turned off. The power drain/cost/computing value is no match for modern hardware. Alas, they are great learning/hacking tools and a wonderful challenge but otherwise not efficient enough to do much with. Never mind the size of the unit... but does a graph exist of the MIP/Watt ratio or some benchmark, to show how computing efficiency versus power consumption has improved over time?
(http://thestoryboardartist.com/tcpiplab/mainframe.jpg)
-
Doesn't mean I don't admire the hardy souls who try it and can afford it. One day I will set up a DEC system10 (emulator) running TOPS-10. Apparently that is the machine Bill Gates ran an emulator on for the development of Microsoft Basic for the Altair.
... an emulator written by his Microsoft co-founder, Paul Allen. You can apply for an account on a real PDP-10 at Allen's Living Computer Museum.
http://www.livingcomputermuseum.org (http://www.livingcomputermuseum.org)
I think even an original RPi might run rings around it in terms of CPU performance.
You only think that? A KA-10 executed 380,000 instructions per second (peak).
As far as the MIPS/watt or whatever, that is not a meaningful comparison. A Scion xD gets better gas mileage than a Jaguar XKSS, but anyone making that comparison would rightfully be considered a philistine. I don't know why it gets shrugged off when it comes to computers.
-
Heh, not quite as big, but reminds me of when a friend of mine decided to rescue this AS/400 from the local junkyard, many years ago. Alas, he never got it running.
It was very heavy for the twiggy bastards we were back then!
-
TV's (UK) PAL, does something similar, where each scan line (in the now obsolete analogue TV transmission system), alternates.
PAL = Phase Alternating (by) Line.
Yeah, alternating colour burst phase. It still scans left to right, so not quite the right example.
-
TV's (UK) PAL, does something similar, where each scan line (in the now obsolete analogue TV transmission system), alternates.
PAL = Phase Alternating (by) Line.
Yeah, alternating colour burst phase. It still scans left to right, so not quite the right example.
That's true. In that sense the bidirectional dot matrix printer, was probably a better example.
Some early, very fast Mainframe printers, were amazing to watch. The rate the paper moves through the printer and yet gets fully printed, was amazing at the time, and would probably still be nice to see.
In those days, it was so wasteful of resources.
You could send a job to the mainframe (possible compile if necessary, and run of your program, split into jobs (batches), because in the past computers were very rare, rather slow and very expensive), there could be a tiny bug in the program/data, so the program crashes and/or exceeds the memory/time/other limits. So a huge core dump is printed. This can consist of many hundreds of pages of hex values.
But such core dumps were usually a waste of time/resources and trees!. Because you can usually see what was wrong with your program and/or data. E.g. A loop with incorrect termination conditions, so it runs until the mainframe times out and/or stack/memory space runs out.
If you could exclusively grab such a Mainframe computer, it was NOT that slow. E.g. 1.5 Mips. With careful programming, that can do quite a lot of stuff. But in the old days, you had to share that 1.5 Mips, with perhaps hundreds of other users, and there were limiting timeouts as well.
So in reality you could type a few things into the terminal, which could look like this:
(https://upload.wikimedia.org/wikipedia/commons/thumb/3/33/Teletype-IMG_7287.jpg/320px-Teletype-IMG_7287.jpg)
and/or produce paper tape(s) and/or punched cards and/or more modern crt screened serial terminals, or even PC's running terminal emulation software, later (historically speaking).
So you would type in "run" or something to start your program. The terminal would then go "dead" for about ten seconds (it could be as fast as a second or two, or take even longer, depending on the mainframe speed, user privilege level and how many users are using the Mainframe at the time), then the results from your program run would appear on the screen, or be printed out (mechanical terminal) or even have to be collected later, where ever the printouts are collected.
-
Pfffft! I thought we were talking about a proper mainframe! One with loads of toggle switches, flashing lights, and spinning reel-to-reel tapes! :(
An IBM Z-series even a relatively small one like a z890 IS a real mainframe. The lights and toggle switches have been replaced by a laptop or perhaps in those days a desktop running OS/2. Spinning tapes were largely superceded by small enclosed tape cartridges and most large sites would have had a robot to insert the tapes. Aside from looking through a viewing window for the purpose of impressing the curious and those that paid for it there was nothing to see.
What amazes me is why an 18yo would even be interested or even know a machine that was obsolete about the time he was born existed.
Still giving him :-+ for the effort. The world needs more people too silly to know something can't or shouldn't be done. He carries the enthusiastic nerd character quite well.
The z890, is not that old. It was announced in 2004. The z890 was on the lower range of IBM mainframes of its time, Business Class, while the z990 was the higher range, the Enterprise Class. The z990 was replaced by the z9 in 2005, followed by the z10 in 2008. The current family is the zEnterprise System, with the z13 announced in 2015 and z13s this year. Most large companies still run mainframes at the core of their systems, with tons of Intel and Unix servers around them.
This is how modern mainframes look like,
https://en.wikipedia.org/wiki/IBM_zEnterprise_System#/media/File:System_z_Frames.JPG (https://en.wikipedia.org/wiki/IBM_zEnterprise_System#/media/File:System_z_Frames.JPG)
I was for 30 years with IBM.
-
Some early, very fast Mainframe printers, were amazing to watch. The rate the paper moves through the printer and yet gets fully printed, was amazing at the time, and would probably still be nice to see.
They were called "line printers", as each line of text was struck more or less instantly. That's why Unix has an "lpr" command.
The sound they made resembles a machine gun firing. Quality of the type, well... that's not what they were for; the impression comes out severely distorted. Mainly they were used so that they could keep up with batch jobs, which almost all yielded printed output; the computer was too expensive to wait for a slow printer. The computer was the really valuable resource: truckfulls of printer paper wouldn't come close to what it cost to buy and operate a 1950s or '60s mainframe.
You could send a job to the mainframe...
You neglect to point out that this means putting a stack of paper punch cards in a rubber band and handing it over a counter. With batch computing, the customer never touches anything connected to the computer. Only trained operators are allowed to do that.
But such core dumps were usually a waste of time/resources and trees!. Because you can usually see what was wrong with your program and/or data. E.g. A loop with incorrect termination conditions, so it runs until the mainframe times out and/or stack/memory space runs out.
The reason that the core dump is printed is that is the only time the program's state is available to be inspected. A second later and it will be gone forever when the next job is loaded. If any errors were visible in the job like in your example, they would be found long before the job was ever submitted. You simply did not ever submit a job without checking it.
So you would type in "run" or something to start your program. The terminal would then go "dead" for about ten seconds (it could be as fast as a second or two, or take even longer, depending on the mainframe speed, user privilege level and how many users are using the Mainframe at the time)
That is a horribly jumbled description. In batch computing, you do not have access to the computer through a terminal or anything else, full stop. Programs were entered using a card punch: there were specific card punches with editing capabilities. In the beginning even this task was performed by a dedicated typist who re-entered your program into the keypunch, but by the '60s they were placed in customer areas for self-service.
The case where teletypes were in use was to operate small, desk-sized computers that had no batch capability (not mainframes). They would use paper tapes instead of cards for program storage, because the Teletype machine had a built-in tape reader and punch. It acted as operator console, printer, and mass storage, unlike mainframes which had special devices for all those functions.
By the end of the 1960s, timesharing was added to all large computers. This allowed several users with teletypes or "glass ttys" to each have their own session concurrently, and use the computer in a "conversational" way, the same familiar CLI paradigm used today. This is much more wasteful of computer cycles, because the computer must sit there and interpret each keystroke, including typos and backspaces, but machines were getting faster (not cheaper quite yet) and this was seen as a worthwhile sacrifice. The different sessions were swapped in and out on a millisecond level; there was not any "dead" time, how absurd.
-
You could send a job to the mainframe (possible compile if necessary, and run of your program, split into jobs (batches), because in the past computers were very rare, rather slow and very expensive), there could be a tiny bug in the program/data, so the program crashes and/or exceeds the memory/time/other limits. So a huge core dump is printed. This can consist of many hundreds of pages of hex values.
But such core dumps were usually a waste of time/resources and trees!. Because you can usually see what was wrong with your program and/or data. E.g. A loop with incorrect termination conditions, so it runs until the mainframe times out and/or stack/memory space runs out.
I had an opportunity to perform some *real* programming on a mainframe* in mid/late 80's. This incident makes me still grin: I was programming / debugging some batch processing script requiring a certain tape to be mounted into the tape unit. I just couldn't get it right and I was pretty frustrated. But I wasn't the only one who was frustrated, I was soon to learn. After seventh or so attempts, the nice Operator gave me a phone call and asked me politely: "I do not know what you are trying to accomplish, but please tell me what you want to do and let me to do it for you". The poor Operator was swapping the tape reel back and forth in the data center as I was trying to get my batch program to run correctly. Sorry about that. :palm:
* It was either CDC Cyber 180 or some model from the CDC Cyber 200-series.
-
Some early, very fast Mainframe printers, were amazing to watch. The rate the paper moves through the printer and yet gets fully printed, was amazing at the time, and would probably still be nice to see.
They were called "line printers", as each line of text was struck more or less instantly. That's why Unix has an "lpr" command.
The sound they made resembles a machine gun firing. Quality of the type, well... that's not what they were for; the impression comes out severely distorted. Mainly they were used so that they could keep up with batch jobs, which almost all yielded printed output; the computer was too expensive to wait for a slow printer. The computer was the really valuable resource: truckfulls of printer paper wouldn't come close to what it cost to buy and operate a 1950s or '60s mainframe.
You could send a job to the mainframe...
You neglect to point out that this means putting a stack of paper punch cards in a rubber band and handing it over a counter. With batch computing, the customer never touches anything connected to the computer. Only trained operators are allowed to do that.
But such core dumps were usually a waste of time/resources and trees!. Because you can usually see what was wrong with your program and/or data. E.g. A loop with incorrect termination conditions, so it runs until the mainframe times out and/or stack/memory space runs out.
The reason that the core dump is printed is that is the only time the program's state is available to be inspected. A second later and it will be gone forever when the next job is loaded. If any errors were visible in the job like in your example, they would be found long before the job was ever submitted. You simply did not ever submit a job without checking it.
So you would type in "run" or something to start your program. The terminal would then go "dead" for about ten seconds (it could be as fast as a second or two, or take even longer, depending on the mainframe speed, user privilege level and how many users are using the Mainframe at the time)
That is a horribly jumbled description. In batch computing, you do not have access to the computer through a terminal or anything else, full stop. Programs were entered using a card punch: there were specific card punches with editing capabilities. In the beginning even this task was performed by a dedicated typist who re-entered your program into the keypunch, but by the '60s they were placed in customer areas for self-service.
The case where teletypes were in use was to operate small, desk-sized computers that had no batch capability (not mainframes). They would use paper tapes instead of cards for program storage, because the Teletype machine had a built-in tape reader and punch. It acted as operator console, printer, and mass storage, unlike mainframes which had special devices for all those functions.
By the end of the 1960s, timesharing was added to all large computers. This allowed several users with teletypes or "glass ttys" to each have their own session concurrently, and use the computer in a "conversational" way, the same familiar CLI paradigm used today. This is much more wasteful of computer cycles, because the computer must sit there and interpret each keystroke, including typos and backspaces, but machines were getting faster (not cheaper quite yet) and this was seen as a worthwhile sacrifice. The different sessions were swapped in and out on a millisecond level; there was not any "dead" time, how absurd.
Sorry if I've been too confusing and jumbled up.
It's because of a combination of it being a very long time ago, and my recollections are at least a bit fuzzy, now. I was also combining my experiences from a number of different time periods and organizations. The UK in some areas of computing, especially in those sorts of eras, could be significantly behind that of, e.g. the US.
I am also tending to be cautious (perhaps/probably too much, as I like to be relatively anonymous here), to not reveal things too specifically. As it could lead to me being identified.
The batches I was referring to (although some were completely offline and involved punched cards), were partially/fully created online. But limited resources at the time, meant that the batch system was used, when resources had run out or were too low.
E.g. The printer(s) were sometimes stretched too much, and there was a significant delay, before we could get the printouts. Of perhaps a few hours, which could be long enough to mean that to would effectively be over-night.
My memory is failing me here. I can't remember, exactly how (or maybe even why), batches were used online. It might be because the printers sometimes broke, and the printouts were important (as they were the main purpose of the programs, usually), so you could still submit jobs, but they would actually run (and print) a number of hours later.
Or maybe it was because there was too much work for the mainframe to cope, so job queues sometimes were very short (almost instantaneous), but at other times, a number of hours delay, could exist before the job would actually run on the Mainframe. Even though, you might be interactively online, using the Mainframe. I just can't remember it that clearly.
EDIT:
Maybe my use of the term "BATCH" is wrong here.
Probably strictly speaking the batches would be when the punched cards are submitted.
Whereas the rest of what I was talking about, was simply a job queue. Which sometimes built up to long lengths of time. Such as hours.
-
My memory is failing me here. I can't remember, exactly how (or maybe even why), batches were used online. It might be because the printers sometimes broke, and the printouts were important (as they were the main purpose of the programs, usually), so you could still submit jobs, but they would actually run (and print) a number of hours later.
Or maybe it was because there was too much work for the mainframe to cope, so job queues sometimes were very short (almost instantaneous), but at other times, a number of hours delay, could exist before the job would actually run on the Mainframe. Even though, you might be interactively online, using the Mainframe. I just can't remember it that clearly.
One of the most important reason was money: The interactive job processing cost a lot of more compared to the batch processed jobs. I remember seeing some experienced guys performing basic editing tasks like find-replace as a batch job in order to make savings in the project's expenses. :phew:
-
You could send a job to the mainframe (possible compile if necessary, and run of your program, split into jobs (batches), because in the past computers were very rare, rather slow and very expensive), there could be a tiny bug in the program/data, so the program crashes and/or exceeds the memory/time/other limits. So a huge core dump is printed. This can consist of many hundreds of pages of hex values.
But such core dumps were usually a waste of time/resources and trees!. Because you can usually see what was wrong with your program and/or data. E.g. A loop with incorrect termination conditions, so it runs until the mainframe times out and/or stack/memory space runs out.
I had an opportunity to perform some *real* programming on a mainframe* in mid/late 80's. This incident makes me still grin: I was programming / debugging some batch processing script requiring a certain tape to be mounted into the tape unit. I just couldn't get it right and I was pretty frustrated. But I wasn't the only one who was frustrated, I was soon to learn. After seventh or so attempts, the nice Operator gave me a phone call and asked me politely: "I do not know what you are trying to accomplish, but please tell me what you want to do and let me to do it for you". The poor Operator was swapping the tape reel back and forth in the data center as I was trying to get my batch program to run correctly. Sorry about that. :palm:
* It was either CDC Cyber 180 or some model from the CDC Cyber 200-series.
I think in the old days (I've read that), when C programmers would compile their programs on PDP11's. They would courteously shout out "I'M ABOUT TO COMPILE". Or something like that, because there a a big chance that the compile may crash, the entire computer system. So the warning gave the other users time to backup their work, and get ready for a possible crash.
I guess virtual memory and other protections, were in their infancy at that sort of time. (e.g. 1960's).
-
My memory is failing me here. I can't remember, exactly how (or maybe even why), batches were used online. It might be because the printers sometimes broke, and the printouts were important (as they were the main purpose of the programs, usually), so you could still submit jobs, but they would actually run (and print) a number of hours later.
Or maybe it was because there was too much work for the mainframe to cope, so job queues sometimes were very short (almost instantaneous), but at other times, a number of hours delay, could exist before the job would actually run on the Mainframe. Even though, you might be interactively online, using the Mainframe. I just can't remember it that clearly.
One of the most important reason was money: The interactive job processing cost a lot of more compared to the batch processed jobs. I remember seeing some experienced guys performing basic editing tasks like find-replace as a batch job in order to make savings in the project's expenses. :phew:
That was definitely an important issue. I was VERY short of interactive time then. But I agree, cost was a big part in the limitations, then. Looking on the bright side, I like to think that experiencing times like that, when computing resources were in very short supply. That it has helped me build up my skill levels, and appreciate the crazy excesses of computing power we have, these days.
Depending on the specific organization there could also be issues, simply waiting for other people to finish using the (too few) computer terminals or computers (in later years).
-
You could send a job to the mainframe (possible compile if necessary, and run of your program, split into jobs (batches), because in the past computers were very rare, rather slow and very expensive), there could be a tiny bug in the program/data, so the program crashes and/or exceeds the memory/time/other limits. So a huge core dump is printed. This can consist of many hundreds of pages of hex values.
But such core dumps were usually a waste of time/resources and trees!. Because you can usually see what was wrong with your program and/or data. E.g. A loop with incorrect termination conditions, so it runs until the mainframe times out and/or stack/memory space runs out.
I had an opportunity to perform some *real* programming on a mainframe* in mid/late 80's. This incident makes me still grin: I was programming / debugging some batch processing script requiring a certain tape to be mounted into the tape unit. I just couldn't get it right and I was pretty frustrated. But I wasn't the only one who was frustrated, I was soon to learn. After seventh or so attempts, the nice Operator gave me a phone call and asked me politely: "I do not know what you are trying to accomplish, but please tell me what you want to do and let me to do it for you". The poor Operator was swapping the tape reel back and forth in the data center as I was trying to get my batch program to run correctly. Sorry about that. :palm:
* It was either CDC Cyber 180 or some model from the CDC Cyber 200-series.
I think in the old days (I've read that), when C programmers would compile their programs on PDP11's. They would courteously shout out "I'M ABOUT TO COMPILE". Or something like that, because there a a big chance that the compile may crash, the entire computer system. So the warning gave the other users time to backup their work, and get ready for a possible crash.
I guess virtual memory and other protections, were in their infancy at that sort of time. (e.g. 1960's).
And how could you tell whether a person was an experienced PDP-11 user or just a n00bie. The n00bie needed a paper from which to read the PDP-11 bootstrap code sequence to be entered manually using the front panel switches each time the system was to be started.
-
A couple of years ago I was on vacation in Vegas, walking down the street half a block of a famous tourist street and saw a PDP-11 in the window of a non-descript office.
I stopped and peered in the window at it having not seen one for years (like 20+), and a guy came to the door and said "Can I help you". I said "wow, haven't seen a PDP-11 in years" and he replied "Yes, this is the SynShop a Las Vegas hacker-space - would you like a little tour?". First hacker-space I'd come across in the flesh and I wasn't even trying.
As for VAXs in this day and age, I do miss assembly language instructions like ACBL (add,compare and branch if less than), and FFCB (find first clear bit). It was like writing in your very own high level language. It was total BLISS-32
-
We were given part of a mainframe when I was in college. We got the washing machine side hard disks with the big removable platters.
What we did with it, well we were asked to stop when the big Frisbee took a chunk out of the concrete wall of the school :)
-
I think in the old days (I've read that), when C programmers would compile their programs on PDP11's. They would courteously shout out "I'M ABOUT TO COMPILE". Or something like that, because there a a big chance that the compile may crash, the entire computer system. So the warning gave the other users time to backup their work, and get ready for a possible crash.
I guess virtual memory and other protections, were in their infancy at that sort of time. (e.g. 1960's).
https://www.bell-labs.com/usr/dmr/www/odd.html (https://www.bell-labs.com/usr/dmr/www/odd.html)
Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not only did not support virtual memory, but didn't support any kind of hardware memory mapping or protection, for example against writing over the kernel. This was a pain, because we were using the machine for multiple users. When anyone was working on a program, it was considered a courtesy to yell "A.OUT?" before trying it, to warn others to save whatever they were editing.
Virtual memory was first available in the Burroughs B5000, shipped in 1963, and protection (segmentation) was in use before that. Possibly the first machine with protected memory was the Rice Institute Computer, operational from 1959. But those were orders of magnitude bigger than a PDP 11/20. When your program contains a bug, it crashes during execution, not compilation (or rather, in this case, assembly). That was the reason for the shouted warning.
The C language came together from 1971-3, simultaneous to the re-implementation of Unix in C based on the earlier assembly version. a.out was originally just the name of the output file from the PDP-7 assembler.
https://www.bell-labs.com/usr/dmr/www/chist.html (https://www.bell-labs.com/usr/dmr/www/chist.html)
-
Sadly, this is where they all end up... While it is amazing to pick up an old machine and learn to get it running, once you do so it is best left turned off. The power drain/cost/computing value is no match for modern hardware. Alas, they are great l earning/hacking tools and a wonderful challenge but otherwise not efficient enough to do much with. Never mind the size of the unit... but does a graph exist of the MIP/Watt ratio or some benchmark, to show how computing efficiency versus power consumption has improved over time?
WARNING! Terrible impersonation incoming! :P
:rant:
Wot matee?! AAARRRRRR! You upset us Power Pirates! What is this efficiency ye speak about?! Sounds like them be fightin' words! :box: We run on tubes matee! How dare ye tell us what to do with our power! We will plunder all ye power and turn it to heat! AAARRRRRR! End of line!
But anyway, people with overclockers, giant GPUs and tons of fans are also being highly inefficient.
Don't worry, I'll soon post a thread on some deliciously peculiar things (projects) I've found on this subject (old computers in general).
-
My memory is failing me here. I can't remember, exactly how (or maybe even why), batches were used online. It might be because the printers sometimes broke, and the printouts were important (as they were the main purpose of the programs, usually), so you could still submit jobs, but they would actually run (and print) a number of hours later.
It could also be because operator intervention was required. A batch job on a mainframe had (well, still has in z/OS!) a JCL 'card' that controlled parameters of its execution like input and output formats. If the device the job needed was offline or busy, it wouldn't be able to run until the operator mounted it. The 1/2" magnetic tapes were all labeled with special numbers, and operators could see which tapes were needed and load them into the tape drives. It's also completely possible that another task had higher priority or was first in the queue.
IBM (and Amdahl, etc) had a strange terminal architecture that put a lot of layers between the user and the mainframe. So unlike with Unix minicomputers, each keystroke didn't immediately interrupt the processor. There was a screen-based protocol based on "forms" or "fields" that could control which lines the user could edit, and whether fields were numeric or alphabetic, etc. Only when the user pressed 'Enter' would all of their input be spat back to the computer in a single packet. They were trying to reduce the machine time taken by interactive users, because it was still very expensive. (This idea is eerily similar to HTML forms.)
-
I think in the old days (I've read that), when C programmers would compile their programs on PDP11's. They would courteously shout out "I'M ABOUT TO COMPILE". Or something like that, because there a a big chance that the compile may crash, the entire computer system. So the warning gave the other users time to backup their work, and get ready for a possible crash.
I guess virtual memory and other protections, were in their infancy at that sort of time. (e.g. 1960's).
https://www.bell-labs.com/usr/dmr/www/odd.html (https://www.bell-labs.com/usr/dmr/www/odd.html)
Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not only did not support virtual memory, but didn't support any kind of hardware memory mapping or protection, for example against writing over the kernel. This was a pain, because we were using the machine for multiple users. When anyone was working on a program, it was considered a courtesy to yell "A.OUT?" before trying it, to warn others to save whatever they were editing.
Virtual memory was first available in the Burroughs B5000, shipped in 1963, and protection (segmentation) was in use before that. Possibly the first machine with protected memory was the Rice Institute Computer, operational from 1959. But those were orders of magnitude bigger than a PDP 11/20. When your program contains a bug, it crashes during execution, not compilation (or rather, in this case, assembly). That was the reason for the shouted warning.
The C language came together from 1971-3, simultaneous to the re-implementation of Unix in C based on the earlier assembly version. a.out was originally just the name of the output file from the PDP-7 assembler.
https://www.bell-labs.com/usr/dmr/www/chist.html (https://www.bell-labs.com/usr/dmr/www/chist.html)
Presumably the A.OUT file is renamed, to the program title or similar, as soon as it has been confirmed that it works reasonably well, and there are no obvious pointer crashes and/or crashes for other reasons.
So what I should have said is that when freshly compiled programs are RUN, rather than specifying the compile process. A warning is shouted out.
My memory is failing me here. I can't remember, exactly how (or maybe even why), batches were used online. It might be because the printers sometimes broke, and the printouts were important (as they were the main purpose of the programs, usually), so you could still submit jobs, but they would actually run (and print) a number of hours later.
It could also be because operator intervention was required. A batch job on a mainframe had (well, still has in z/OS!) a JCL 'card' that controlled parameters of its execution like input and output formats. If the device the job needed was offline or busy, it wouldn't be able to run until the operator mounted it. The 1/2" magnetic tapes were all labeled with special numbers, and operators could see which tapes were needed and load them into the tape drives. It's also completely possible that another task had higher priority or was first in the queue.
IBM (and Amdahl, etc) had a strange terminal architecture that put a lot of layers between the user and the mainframe. So unlike with Unix minicomputers, each keystroke didn't immediately interrupt the processor. There was a screen-based protocol based on "forms" or "fields" that could control which lines the user could edit, and whether fields were numeric or alphabetic, etc. Only when the user pressed 'Enter' would all of their input be spat back to the computer in a single packet. They were trying to reduce the machine time taken by interactive users, because it was still very expensive. (This idea is eerily similar to HTML forms.)
That makes lots of sense. There was a hive of activity, with the computer operators, looking after the mainframe computer, its printer(s), and other stuff.
Somehow, compiling and running programs on Mainframe computers, a long time ago, was really something. A bit like taking a ride in a Rolls Royce, or flying on your first Concorde Flight, or sailing on the original Titanic.
I still perceive Mainframe computers to be extremely powerful beasts, even though it was probably only about 2 Mips, and a modern day Raspberry PI computer, would probably be hundreds or thousands or more, times more powerful.
Even today, they still have a kind of reliability (of sorts) and dependability, which seems to be partly lacking in PC's and perhaps rack servers.
I agree, I lacked any kind of priority, on the Mainframe system. In some places, you would not only get a higher priority, but also your own, personal terminal. It could be "painful" having to wait an hour or few, just to see if your program had compiled and run ok, without errors.
One possibility (but I can only weakly remember it, so could easily be wrong), is that if the program compiled ok, you could run it immediately, on screen, if you were online. But if it had compile errors (and maybe if they were busy), you had to wait a number of hours for the printout to come out and be sorted out into the respective places, so that you could collect it and see what the errors were and/or check the program ran ok.
There were at least two different languages used, so maybe one of them was more interactive (Pascal) than the other. One was Cobol, (which I've mostly completely forgotten), and I think it was entirely NOT interactive. So maybe that had to go through the job queue system, every time.
N.B. My usage of the ARS33 mechanical terminal (I'm NOT sure of the exact model number, but expect it was that one), was a number of years before, using the Mainframe I was describing. The ARS33 connected to a somewhat early, Mainframe computer, as well. Using some kind of modem (but connections to the telephone system were not allowed. So it used a cradle which held the mic and speaker, close to the phones handset, I presume we had to manually dial though to the Mainframe computer). It was probably 110 baud.
Due to its age, you could crash the Mainframe, and get ALL users thrown off it, simultaneously (I believe). Unfortunately I managed to do that. (If NOT, the problem was that my "error", caused the system operator, terrible problems).
-
My memory is failing me here. I can't remember, exactly how (or maybe even why), batches were used online. It might be because the printers sometimes broke, and the printouts were important (as they were the main purpose of the programs, usually), so you could still submit jobs, but they would actually run (and print) a number of hours later.
It could also be because operator intervention was required. A batch job on a mainframe had (well, still has in z/OS!) a JCL 'card' that controlled parameters of its execution like input and output formats. If the device the job needed was offline or busy, it wouldn't be able to run until the operator mounted it. The 1/2" magnetic tapes were all labeled with special numbers, and operators could see which tapes were needed and load them into the tape drives. It's also completely possible that another task had higher priority or was first in the queue.
IBM (and Amdahl, etc) had a strange terminal architecture that put a lot of layers between the user and the mainframe. So unlike with Unix minicomputers, each keystroke didn't immediately interrupt the processor. There was a screen-based protocol based on "forms" or "fields" that could control which lines the user could edit, and whether fields were numeric or alphabetic, etc. Only when the user pressed 'Enter' would all of their input be spat back to the computer in a single packet. They were trying to reduce the machine time taken by interactive users, because it was still very expensive. (This idea is eerily similar to HTML forms.)
THIS! IBM mainframes used something called IMS which essentially provided a form to the dumb (but slightly smarter than a tty) terminal so the user could fill in all the fields then press the send button to get the next page. These terminals were replaced with Windows and the users had to use a terminal emulator to access them.
I remember demonstrating a 3 tier application using Microsoft Transaction Server (stateless programming) and ASP web pages with HTML forms - the COBOL dinosaurs who had previously been unimpressed with Windows client/server applications were suddenly impressed when the penny dropped and they knew they were right all along! HTML forms processing is nothing but old fashioned mainframe IMS :-DD
-
THIS! IBM mainframes used something called IMS which essentially provided a form to the dumb (but slightly smarter than a tty) terminal so the user could fill in all the fields then press the send button to get the next page. These terminals were replaced with Windows and the users had to use a terminal emulator to access them.
I remember demonstrating a 3 tier application using Microsoft Transaction Server (stateless programming) and ASP web pages with HTML forms - the COBOL dinosaurs who had previously been unimpressed with Windows client/server applications were suddenly impressed when the penny dropped and they knew they were right all along! HTML forms processing is nothing but old fashioned mainframe IMS :-DD
What I'm about to say is probably open to much technical criticism (but it is because I am trying to be philosophical about computing, rather than 100% specific/technical). But my (limited) experience with both server computers/(racks) and the software which often runs on them, reminds me a lot, about the earlier days, on big iron mainframe computers.
Although a server (often in a rack), is considerably smaller, cheaper and sometimes easier than the old mainframe computers. I perceive similarities, because one mainframe (application), may have a thousand users. Similarly a server, may also have a thousand users. Unix/Linux, especially in terminal (console) mode, reminds me about the earlier mainframe operating systems.
I concede that from what I remember of real mainframe usage, they were (or could be), much more feature packed, as regards the operating system. But it could also be because I was wowed by the massive manuals, and phenomenal instruction/command set/features it/they had, then.
My gut feeling is that Linux/(Unix) (there are others, such as windows server), are more compact, and have less features than some of the older operating systems. I guess part of it was that the handling of (computer) tapes, itself was a significant subject area. Whereas these days, it is replaced by some kind of hard disk raid array, or other robust storage system. With mega gigabytes of system memory making such techniques to handle the tapes, unnecessary, because (if necessary), the entire database, could easily fit in memory, and even if it can't, the MySQL or whatever, can just handle the situation.
tl;dr
Whenever I sit in front of a Linux terminal window, it brings back memories of the old days, of mainframe computers, and terminals. Even though things have changed a lot, in the meantime.
Somehow a dos command window (somewhat rarely used these days), just does not cut the mustard, and simply reminds me of the early days of PC's, when DOS was used, almost exclusively.
-
What I'm about to say is probably open to much technical criticism (but it is because I am trying to be philosophical about computing, rather than 100% specific/technical). But my (limited) experience with both server computers/(racks) and the software which often runs on them, reminds me a lot, about the earlier days, on big iron mainframe computers....
...
I think it is definitely that after the PC boom (as in everyone's computer at their desk did all the stuff for whatever they were doing) we have seen a return to the old skool approach.
Mainframe + dumb terminals == Server + thin clients.
I hate those god-awful web-based applications, and as for Citrix et al, grrrr....
-
My gut feeling is that Linux/(Unix) (there are others, such as windows server), are more compact, and have less features than some of the older operating systems. I guess part of it was that the handling of (computer) tapes, itself was a significant subject area. Whereas these days, it is replaced by some kind of hard disk raid array, or other robust storage system. With mega gigabytes of system memory making such techniques to handle the tapes, unnecessary, because (if necessary), the entire database, could easily fit in memory, and even if it can't, the MySQL or whatever, can just handle the situation.
I think there's something to that. The overall size of the operating systems has of course bloated with all other software (in the 1960s a 60 MB disk was a huge device), but some features were also jettisoned. Record-based storage, with its punchcard inheritance, was one of them (it still exists in a way in OpenVMS). Some mag-tape features too, as you say. In Donald Knuth's The Art of Computer Programming Vol. 3, he devotes what seems like a huge amount of space to discuss sequential search algorithms for tapes. There's even a centerfold sheet with a diagram of the optimal sorting procedure for records on a tape! There are still many databases that are too large to fit in memory (or Oracle wouldn't exist) but tapes are no longer used that way.
-
I think there's something to that. The overall size of the operating systems has of course bloated with all other software (in the 1960s a 60 MB disk was a huge device), but some features were also jettisoned. Record-based storage, with its punchcard inheritance, was one of them (it still exists in a way in OpenVMS). Some mag-tape features too, as you say. In Donald Knuth's The Art of Computer Programming Vol. 3, he devotes what seems like a huge amount of space to discuss sequential search algorithms for tapes. There's even a centerfold sheet with a diagram of the optimal sorting procedure for records on a tape! There are still many databases that are too large to fit in memory (or Oracle wouldn't exist) but tapes are no longer used that way.
I think human nature is a strange beast.
Although massive mainframe computers, taking up a huge room full of equipment, often air-conditioned and costing millions of £/$'s, and many technical people to look after it. Can now be put into a considerably smaller, rack mounted case.
The human nature of the situation, means that the requirements for the computer centre, go up and up. With it doing more and more functionality.
So we end up with lots and lots of racks, full of servers, and other related equipment. Again with many technical people milling around, and still costing many millions of £/$'s. Also still taking up a huge room full of space, and often air-conditioned.
So things have not really changed as regards mainframe computers. Just that (the name changes from mainframe to server) instead of one big mainframe computer, we now typically have hundreds (depending on the organizations size and needs) of rack servers, in lots of big racks. Probably doing many hundreds of different applications, for the organization. Spread between the various servers.
tl;dr
I think it is one of those laws (like murphy's law), where the needs grow, to match the new capabilities. So the capabilities never reach or exceed the needs/wants, of the users.
E.g. A few terrabytes of storage space on a hard disk today (rapidly being taken over by SSD's), is unimaginably big for many computer people, of the 1960's. Paper tape had a few K (assuming it is fairly short length of tape), perhaps of storage space. Punched card only a line (80 chars I think), of information. Yet this is still know where near the upper limits, of peoples wants. Because they just fill them (for home use), with gigabytes of blu-ray movies or massive internet downloads, or some other usage, such as big games, until they are full up again, some 12 months later.
-
mainframes still exist today. They are just made tiny, being modular and scalable and hooked up via high speed networking in the hundreds of thousands now called the cloud.
-
mainframes still exist today. They are just made tiny, being modular and scalable and hooked up via high speed networking in the hundreds of thousands now called the cloud.
EDIT:
In some respects, I agree that the "cloud" (not that I particularly like that term), is a sort of mainframe/supercomputer, when viewed as lots of connected nodes, and tiny computers, can be extremely powerful. On the other hand ...
You can still buy (current) mainframe computers.
E.g.
(http://www.wired.com/wp-content/uploads/2015/01/20150114afmIMB-SYSZ-0031.jpg)
http://www.wired.com/2015/01/z13-mainframe/ (http://www.wired.com/2015/01/z13-mainframe/)
IBM QUIT MAKING PCs in 2005, and it quit making servers last year. But it looks like Big Blue will keep pumping out its mainframes forever.
On Tuesday, IBM launched the z13, which it bills as the first mainframe specifically designed to accommodate the booming mobile app economy. Mainframes—the refrigerator-sized, pre-PC computers beloved of government, corporations, and Tron—were long synonymous with IBM, which introduced its first mainframe in 1952. The company has long since reinvented itself as a provider of business services rather than hardware. But it turns out the old standby is still around.
The first mainframes were designed to serve Cold War clients like the US Department of Defense. (Its first mainframe, the IBM 701, was known as the Defense Calculator while under development.) The mainframe of today is designed to serve a very different world—and economy.
This 1954 photo provided by IBM shows a 700-series Electronic Data Processing Machine. Click to Open Overlay Gallery
This 1954 photo provided by IBM shows a 700-series Electronic Data Processing Machine. IBM/AP
IBM claims the z13 mainframe is the first system able to process 2.5 billion transactions a day (or the equivalent of 100 Cyber Mondays every day, according to the company). It can encrypt mobile transactions in real-time and provide on-the-fly insights on all transactions that pass through it. This will help companies and governments improve fraud detection, IBM says, and it give them a live view of a client’s purchasing habits so they can push related promotions to consumers right when they’re in-store.
The first mainframes were designed to serve Cold War clients. The mainframe of today serves a very different world—and economy.
“We’re driving toward a world where more and more people are using mobile devices, or embedded devices, to interact with systems,” John Birtles, director of IBM z Systems, tells WIRED. “We need to make sure that those devices are secure, that the transaction’s secure, and that our clients get the level of analytics that gives them opportunities to improve their businesses.”
The concept of a “mobile transaction” is a bit of marketing-speak. Tons of transactions take place via mobile devices, and the mainframe is good at transaction processing. Put them together, and voila: a computer the size of a backyard shed becomes a mobile product.
Apple Meets Mainframes
For IBM, staking out this space makes sense. Though the company has, for the most part, left hardware to move towards higher-margin businesses in the age of cloud computing, investing in this particular machine still makes sense. The company showed its dedication to mobile when it teamed up with Apple back in July to create business apps for iPhones and iPads. Now it’s designed a computer to act as a powerful backend engine for apps on those devices.
Across so many industries—retailers, financial institutions, telecommunications services, insurance companies, airlines, and governments, to name just a few—transactions are going increasingly mobile. If you think about how much banking you do on your tablet or phone, or even how you might check in to your next a flight, this growth starts to make sense. And that’s not even counting the myriad payment processing schemes you might have tried, from PayPal to Square to Intuit.
Investing in industrial-grade hardware still aligns with IBM’s focus on serving as an engine for business.
IBM’s z13 mainframe is supposed to help with all of these tasks—along with any other business that gets done on a mobile platform. In order to get the job done, IBM says it has equipped the z13 with a processor that contains 300 percent more memory than found on most servers and 100 percent more bandwidth for speedier mobile transactions. The z13 also does analytics natively, rather than requiring data to be moved off the mainframe to other computing systems.
As developers of new applications come to rely on the ease and power of the cloud, the mainframe remains a powerhouse for tasks computers have performed for decades, such as transactions. IBM has realized it can no longer make money selling traditional hardware, and as of late, the company has been focusing its efforts on software and data analytics, including a recently announced partnership with Twitter. But investing in industrial-grade hardware still aligns with IBM’s focus on serving as an engine for business. Business is more mobile than ever. Yet however lightweight those mobile devices feel in your pocket, they can still make good use of a big, powerful machine chugging away in a back room, not going anywhere.
UPDATE: 20:20 ET 01/15/15: The caption on the second photo was updated to correctly identify the computer.
Also probably any of the computers in the current Top500 list:
https://www.top500.org/lists/ (https://www.top500.org/lists/)
would count as some kind of Mainframe or SuperComputer. Depending on peoples definitions. I agree "mainframe" is debatable, but "supercomputer" is much more clear cut a term for them.
Examples:
(http://www.afr.com/content/dam/images/g/q/d/c/b/j/image.related.afrArticleLead.620x350.gqczf1.png/1469604020583.jpg)
(http://images.en.yibada.com/data/images/full/108531/chinas-new-supercomputer-leaves-the-us-farther-behind.jpg)
-
Lol that's awesome. When I was around the same age, probably a bit younger, I got a lot into computer stuff too and my parents were always annoyed. It took forever so I can convince my parents to let me build my own computer. Eventually a server... eventually two servers... then I really wanted a rack... that never happened but I knew I'd be moving out soon and realized there was really not much room in the finished basement so did not push that hard. I never got to THAT extent though, a mainframe, that's quite impressive lol.
When I moved into my own house at 23 I was already planning where I wanted my rack - in fact that was one of my requirements when looking at houses. Started off with something that was quite mickey mouse:
(http://gal.redsquirrel.me/thumbs/lrg-904-dsc02794.JPG) (http://gal.redsquirrel.me/images/house_projects/basement_and_data_infrastructure/dsc02794.JPG)
And years later, now I have this:
(http://gal.redsquirrel.me/thumbs/lrg-3293-dsc_0337_01.jpg) (http://gal.redsquirrel.me/images/other/random/dsc_0337_01.jpg)
As a side note, at my work we work a lot with DMS10 and DMS100 switches, if someone actually offered one to me, not that I have any room for one... but I'd totally make room. :P
I wonder if Connor is still looking for fibre channel storage... I have about 500lbs worth of it that I'd gladly get rid of for cost of shipping from Canada. LOL.
-
And years later, now I have this:
(http://gal.redsquirrel.me/thumbs/lrg-3293-dsc_0337_01.jpg) (http://gal.redsquirrel.me/images/other/random/dsc_0337_01.jpg)
That is quite a lot of stuff. My computer setup is much more modest. (The black cabinet/chip-die is the 64 core cpus, and the grey/white one, higher up in the picture is the 256,000 core GPU) Look:
(http://files.abovetopsecret.com/images/member/77f26671f551.jpg)
Or I'm joking.
I think I have seen Mainframe installations (when they were more popular, in the past), which are SMALLER than that, and I'm NOT joking, here.
In the early days, mainframe installations tended to be huge. But much later, they could be somewhat compact. The smallest (live, in use) Mainframe installation I've seen was about the size of a double set of cabinets.
But there was another big/separate section of the room, which I could not see so clearly, which may have had more stuff in it, like hard disks and printers etc.
Something like this (yes, I know that is not ALL of the mainframe):
(http://ed-thelen.org/GE-AmpexTapeHandler-Controller-.jpg)
-
Large installations often separated various parts, with tons of cables in the underfloor space connecting it all. The company I worked for in the early 90's supplied banking software, and ran hosted installations of it for many banks that didn't want to have their own mainframe installs. In one room of the data center we had all the processor complexes, 6 IBM 3090's (some were the Amdahl clones). In another room we had row after row of drive cabinets comprising 13TB of DASD (my server had home is in a short ATX tower case and has 13TB of storage - and none of my drives are the highest capacity currently available - if I replaced them all with say 6TB drives I'd have 36TB). Another room housed some tape drives. Another room had racks of lead acid batteries that were just enough power to maintain the CPU and cooling until the generators could come online. We had 3 large diesel generators, any 2 of which supplied sufficient power. Then there was the operator's room, and another huge room which terminated all the telco circuits connecting out to these customers - rack after rack of equipment terminating individual 56k connections.
I was back there a few years ago, they have switched everything to Windows and Linux, there is one remaining 3090 for legacy access because of banking industry data retention rules, but the rest of what was the processor room is just rows of standard racks filled with standard PC servers, some running Windows and some running Linux. The former DASD room is not the operations center with lots of cubes and desks for the data center operators. The space formerly occupied by the tape drives was empty at that time, big open space of raised floor.
-
Lol that's awesome. When I was around the same age, probably a bit younger, I got a lot into computer stuff too and my parents were always annoyed. It took forever so I can convince my parents to let me build my own computer. Eventually a server... eventually two servers... then I really wanted a rack... that never happened but I knew I'd be moving out soon and realized there was really not much room in the finished basement so did not push that hard. I never got to THAT extent though, a mainframe, that's quite impressive lol.
When I moved into my own house at 23 I was already planning where I wanted my rack - in fact that was one of my requirements when looking at houses. Started off with something that was quite mickey mouse:
And years later, now I have this:
As a side note, at my work we work a lot with DMS10 and DMS100 switches, if someone actually offered one to me, not that I have any room for one... but I'd totally make room. :P
I wonder if Connor is still looking for fibre channel storage... I have about 500lbs worth of it that I'd gladly get rid of for cost of shipping from Canada. LOL.
My rack is much smaller and probably just as powerful.
(http://i306.photobucket.com/albums/nn275/eugenenine/Misc/KIMG0433.jpg) (http://s306.photobucket.com/user/eugenenine/media/Misc/KIMG0433.jpg.html)
-
Are those RPIs? They look a bit longer but maybe it's the angle.
With the ever increasing prices of hydro, it's crossed my mind to downsize my network to just a bunch of those too. :P My network/server setup is kind of overkill.
-
4 pi's and a beaglebone in 1/2 wide 1U high each.
-
overclocking low end 6 core xeons to almost double their frequency is a very cheap way for some computing power. You can now buy SFP+ cards cheap 2nd hand as datacenters phase out older ones in favour of newer ones (prob 100G), Just managed to set up 2 compute computers which are basically desktops crammed into 2U complete with high end desktop GPUs, 3.5 inch drives, ATX PSUs. Cooling in racks are also much better as the fans have more coverage compared to desktops.
Now once i can plug in the SFP+ to SFP+ direct without the NIC falling off the PCIe bracket i will be able to benchmark some high end network gear :D
in the game no one lives forever you will typically encounter those tape mainframes and controls with many bulbs in them.
Mainframes have evolved to work over the network. The storage may be some servers dedicated to storage. The main CPUs would be another bunch of servers with more CPUs and ram. Or it could be distributed where every machine does a little of everything in the form of a cloud. The concept is still the same just everything is virtual now and inexpensive.
-
It ain't a mainframe or supercomputer unless it says 'CRAY' on the front plate...
everything else is just wannabe's.
Definition of a Cray computer :
- the only machine that can run an endless loop in under 4 hours.
And the only thing faster than a Cray is a newer model Cray
-
It ain't a mainframe or supercomputer unless it says 'CRAY' on the front plate...
everything else is just wannabe's.
Definition of a Cray computer :
- the only machine that can run an endless loop in under 4 hours.
And the only thing faster than a Cray is a newer model Cray
So CRAY are the only real computers, and farmers buy VAX 11/780's then ?
Cray did an amazing job designing the Cray1 supercomputer, entirely out of a single type of ECL logic gate (from memory it might have been a three input Nor gate, but I'm not sure. It would have had complementary outputs, anyway, so other logic functions are fairly easy to do/obtain).
80 Million flops (or 160 million if you are pedantic but unrealistic) of vector processing, was very powerful then (in the early 1970's I think).
It looked "COOL" with its seating arrangement, but needed huge cooling and an electricity sub-station worth of electricity to power it.
tl;dr
I would probably love to have one, but it is completely impracticable and (virtually) unavailable to buy, in its genuine original form.
It would have been really nice to meet Seymour Cray in person, while he was alive.
-
It ain't a mainframe or supercomputer unless it says 'CRAY' on the front plate...
everything else is just wannabe's.
Definition of a Cray computer :
- the only machine that can run an endless loop in under 4 hours.
And the only thing faster than a Cray is a newer model Cray
So CRAY are the only real computers, and farmers buy VAX 11/780's then ?
Cray did an amazing job designing the Cray1 supercomputer, entirely out of a single type of ECL logic gate (from memory it might have been a three input Nor gate, but I'm not sure. It would have had complementary outputs, anyway, so other logic functions are fairly easy to do/obtain).
80 Million flops (or 160 million if you are pedantic but unrealistic) of vector processing, was very powerful then (in the early 1970's I think).
It looked "COOL" with its seating arrangement, but needed huge cooling and an electricity sub-station worth of electricity to power it.
tl;dr
I would probably love to have one, but it is completely impracticable and (virtually) unavailable to buy, in its genuine original form.
It would have been really nice to meet Seymour Cray in person, while he was alive.
don't focus on the cray -1. there are many many more Cray machines. look up the 'Jaguar' machine and how it was built . there is avideo on Youtube showing the installation of the machine over a multi month timeframe.
The installation manual of a Cray machine typcially specifies how wide the driveway should be (for manouvering the delivery trucks) and how many tons the floor need to handle. You know you are dealing with 'serious iron' when installation manuals specify that ...
-
Funny, speaking of Cray, in my communications class in college we were learning about proper letter writing techniques and stuff. Lot of the stuff you see in letters like "to whom this may concern" is actually really bad format, we learned all the proper ways etc... one assignment involved writing a letter to a company. I decided to write to Cray to inquire about a mainframe recommendation for my basement. I outlined requirements, like it needs to be able to run certain games. I never got a response. :( They probably thought I was insane. :P "Great it's one of those space elevator people, don't even bother responding".
-
Funny, speaking of Cray, in my communications class in college we were learning about proper letter writing techniques and stuff. Lot of the stuff you see in letters like "to whom this may concern" is actually really bad format, we learned all the proper ways etc... one assignment involved writing a letter to a company. I decided to write to Cray to inquire about a mainframe recommendation for my basement. I outlined requirements, like it needs to be able to run certain games. I never got a response. :( They probably thought I was insane. :P "Great it's one of those space elevator people, don't even bother responding".
Here is a slightly similar letter, from someone famous:
(https://upload.wikimedia.org/wikipedia/commons/1/14/Bill_Gates_Letter_to_Hobbyists.jpg)
-
I stared out in the Burroughs (now Unisys) "Large System" (later "A series" then Clearpath) mainframes. Our "Assembler" was Algol and the machines had a non Von Neumann architecture. Those machines had a lot going for them.
One of the funny things was that the "blinking lights" were all behind closed panel doors. When they gave a tour they would show people the tape drive controller that had tons of lights and switches.
-
Some early and very impressive line printer art:
http://privatewww.essex.ac.uk/~alien/aaa.html (http://privatewww.essex.ac.uk/~alien/aaa.html)