Slashdot Mirror
Fifty Years Ago IBM 'Bet the Company' On the 360 Series Mainframe
Hugh Pickens DOT Com (2995471) writes "Those of us of a certain age remember well the breakthrough that the IBM 360 series mainframes represented when it was unveiled fifty years ago on 7 April 1964. Now Mark Ward reports at BBC that the first System 360 mainframe marked a break with all general purpose computers that came before because it was possible to upgrade the processors but still keep using the same code and peripherals from earlier models. "Before System 360 arrived, businesses bought a computer, wrote programs for it and then when it got too old or slow they threw it away and started again from scratch," says Barry Heptonstall. IBM bet the company when they developed the 360 series. At the time IBM had a huge array of conflicting and incompatible lines of computers, and this was the case with the computer industry in general at the time, it was largely a custom or small scale design and production industry, but IBM was such a large company and the problems of this was getting obvious: When upgrading from one of the smaller series of IBM computers to a larger one, the effort in doing that transition was so big so you might as well go for a competing product from the "BUNCH" (Burroughs, Univac, NCR, CDC and Honeywell). Fred Brooks managed the development of IBM's System/360 family of computers and the OS/360 software support package and based his software classic "The Mythical Man-Month" on his observation that "adding manpower to a late software project makes it later." The S/360 was also the first computer to use microcode to implement many of its machine instructions, as opposed to having all of its machine instructions hard-wired into its circuitry. Despite their age, mainframes are still in wide use today and are behind many of the big information systems that keep the modern world humming handling such things as airline reservations, cash machine withdrawals and credit card payments. "We don't see mainframes as legacy technology," says Charlie Ewen. "They are resilient, robust and are very cost-effective for some of the work we do.""
Should be required reading for anyone planning to manage a large engineering project. It's full of tips that can save you from significant embarassment. If you're not managing a software development project, at least make sure your boss reads it. If your boss has *already* read it, he might be worth working for.
There's little point throwing away decades of refined code just for the sake of it. When it comes to financial systems and the law, the last thing any manager will do is push to move platform on their shift, no matter how many times Microsoft's reps come in to wine-and-dine those further up the ladder.
"We don't see mainframes as legacy technology," says Charlie Ewen. "They are resilient, robust and are very cost-effective for some of the work we do."
Love this kind of talk! Go get'em Charlie Ewen!
Would've got an FP if I hadn't dropped the card deck.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Data and processing on a remote computer, accessed via a dumb terminal.
Yep, that's "cloud computing".
Everything old is new again.
I'd estimate that it killed something like ten years of pushing research results into practice (out-of-order execution, largely invented in the 1960s, didn't really catch on "thanks" to S/360 until 1990s - because it had the unfortunate distinction of having been invented in a non-S/360 project that got cancelled).
Ezekiel 23:20
When I arrived at Carnegie-Mellon University in 1968, all programs were running on a Univac 1108, soon to be replaced with a much more powerful IBM 360. In those days every science major learned to code in their freshman year. You would type your program onto punch cards, one instruction per card, then type your data onto cards, and dump into the submission box. Hours later you'd pick up your printout in your (physical) mailbox. Faster turnaround if you submitted at say 2AM. No security at all in those days, so occasionally your program cards would be stolen, if you hadn't duplicated it you'd have to start from scratch.
When I first heard about this book in my CS class I misread the title and thought it was called "The Mythical Man Moth".
I thought that's gotta be a book worth reading even if it is about project management!
Because of course, no iPhone, MacBook or iPad ever connects to a website which has its database running on a mainframe.
Sphinx of black quartz, judge my vow.
Sure, all those so-called "telephones" running on 99-cent "apps" are plentiful, like cockroaches, but if you're running one the million- or billion-dollar companies that let those awkward thumbpaint-smudge-laden gadgets actually do anything, you're talking mainframes one way or another (call them a "cloud" if you must).
Too bad that IBM is long, long gone.
The heat from below can burn your eyes out
If you work for a large company, chances are a mainframe prints your paycheck.
If you work for a small company, they probably outsource their payroll to some company such as Paychex, and a mainframe still prints your paycheck.
Ooh, moderator points! Five more idjits go to Minus One Hell!
Delendae sunt RIAA, MPAA et Windoze
Although these days the hardware is System 390/Z-series, but I still login via TSO, I review COBOL code with comments going into 1980 (and yes, they all have Y2K patches)... The financial industry *never* throws anything away (especially if it's still making them money). Except programmers. Those they throw away.
If telephones are outlawed, then only outlaws will have telephones.
Show software you've done lately. Don't have any? Thought so. You're a blowhard bullshitter.
Yup, the cloudies reinvented timesharing (;-))
What they don't have, however, is a uniform memory architecture. Modern large processors (running AIX, Solaris, etc) are non-uniform memory (NUMA) machines, with memory on the same board as the cpu being faster then memory on the buss.
Memory on cloud/array-computing machines is the extreme of NUMA: the "bus" is an ethernet (;-))
On mainframes, the memory is in the "center" with the CPUs around it in a ring, using a "system controller" (the Honeywell term) to mediate multiple accesses to memory and manage cache consistency. That used to be the most expensive part on the machine, and typically scaled to between 4 and 8 CPUs on the Honeybun. On modern machines it's part of the CPU and cache structure and scales to about 4 sockets on a board. Six on a good day.
Thus you see lots of effort to handle NUMA effects, and get more ALUs and decoders per chip, to get more threads per socket.
davecb@spamcop.net
I started on an IBM 360, doing assembler coding. Still have the IBM books I bought at the college bookstore. I was always amazed how much it felt like coming up from deep sea diving after a day of coding registers, doing multiplication via shift commands and all the other great little tricks that now seem ancient history. I still find myself comparing manuals based on how well they follow basic IBM rules: you can not self-reference a term in explaining the term, the explanation must not reference other terms that are not explained or that can not be identified as precursors to the term. It was a great machine to learn on.
It's ironic that a VM performing dynamic translation of legacy S/360 binary code would probably work just as well as rewriting the legacy systems into Java, and without the need to install multiple VMs. :-)
Ezekiel 23:20
The problem was solved by making the ISA independent of the microarchitecture. That wasn't just solved, it was an industry-wide convention by the time Java appeared.
I am TheRaven on Soylent News
I am not the developer, I am merely the user, and I have to use what's installed on the systems, because that's their maintenance interface, and I am not going to develop an own interface in my free time.
I threw an exception trying to parse that post.
Have gnu, will travel.
>>
But if the mainframe job market have a problem, is lack of people. Mainframes are not user friendly, and youngsters are not likely to devote two or three years learning something from the grannies, on a very harsh learning environment, with a step learning curve, when all their peers are talking about creating a new app and selling to Google for a gazillion dollars.
There is also the problems of: you cannot realistically teach yourself, no classes are offered, and you cannot get experience until you already have experience - and experience is *always* mandatory.
Go home, you're drunk,
I, too, became proficient in programming in a mainframe environment. I was fortunate enough to work for a department on campus (University of Florida, the Institute for Food and Agricultural Sciences) that treated their employees very well (even students) and gave us advanced tools (like CRTs so we didn't have to use cards at all). Later I worked at Texas Instruments in IBM mainframes. I agree with the worker17 (previous post) that IBM documentation was excellent & well-supported. The discipline required for mainframe programming (256K was considered a HUGE amount of storage!) has also proven useful in today's environment where 1G is considered "small".
It has been decades since I used mainframes, but I got quite deeply into them (I attended "internal logic" classes at IBM while at TI) --- where would I go to find a job now? I could retrain myself very quickly since I got so deep the first time 'round ...
C
... revere the COBOL, for Holy is the COBOL. Thou shalt take no other language before it ...
You can say a lot of bad things about Java, but the JVM really neatly solves this problem.
It solves the problem so neatly that we keep several VMs around with different Java versions, just to maintain older systems that were developed with Java 1.3 or 1.4 and break as soon as you install Java6 oder Java7.
Using VMs to have multiple JVM ???? Geeezzz
You know that you can have several different JVMs in the same OS without interference (setting JAVA_HOME in a starting script is not so complicated you know).
Not sure if you were being sarcastic or not, but consider this: At least you can still run those older systems. If they weren't contained in a VM, you'd have to keep not an outdated VM, but an entire outdated system - hardware, software, everything, around.
A company I worked for once had an ancient AIX system around because it was running some crucial thing they had long forgotten how to migrate elsewhere...
Assorted stuff I do sometimes: Lemuria.org
My second computer was a 360. I began life coding Fortran IV on one of the 360's immediate predecessors, the IBM 1410. At the time, mainframes occupied two distinct categories: "business" machines like the 1410, which organized data as individual 6-bit bytes, and "scientific" mainframes like the 7090 series, which saw data as 32-bit integers and floats. Most programming as done in machine-dependent assemblers, which were totally different on each machine.
The 360 merged the two styles of computing. Memory was now organized as 8-bit bytes acted on by a single instruction set. You could address individual bytes, pairs of bytes as short integers, blocks of 4 as long integers or floats, or blocks of 8 as long floats. Not only was it easier to port existing languages like Fortran to this single architecture, but IBM's own new language, PL/I, became everyone's new language of choice on mainframes.
Mainframes were still huge and expensive, internal memory still took the form of iron rings, one per bit, strung into grids of wire by hand, and moist software was still a batch operation pulling its data from an "input tape" and writing to an "output tape", but with System/360 the way to the future was clear. I'll never forget the arrival of our first disk drive, the IBM 2311. It was the size and shape of a top-loader washing machine and held two million bytes of randomly accessible data. Clearly the millennium had come early for us as we dreamed of databases that could use such vast quantities of data.
In many ways Java is a regression relative to C++, Smalltalk and LISP.
But if you drum a message 100 times into the ears of people, they will finally believe it. Ask Mr Goebbels for details.
Been there, done that. Back to C++, which is not perfect, but does not suck donkey balls like the SUN invention.
Given its was not the best standard - 86x with BIOS. But it was a standard countless competing companies did optimaize until the profit level dropped below IBMs tolerance and they sold it to Lenevo.
There have apparently been a number of JIT'ed versions of hercules http://www.hercules-390.org/.
The only problem is that IBM won't license zos to run on it. So, its a major NO NO for the kinds of companies that are still running mainframe applications.
Worse yet, is that Hercules is actually faster (on a reasonable server) than the base BC series mainframes because of the "capacity on demand" features that result in mainframes running at 1/100th their capacity.
You can say a lot of bad things about Java, but the JVM really neatly solves this problem.
It solves the problem so neatly that we keep several VMs around with different Java versions, just to maintain older systems that were developed with Java 1.3 or 1.4 and break as soon as you install Java6 oder Java7.
Are you so blind that you don't realize you're using the exact solution virtual machines provide? You don't have to run everything under the latest JVM. Even then, you can set the latest JVMs to mimic older JVMs.
You can write bad software that depends on minor version quirks of *any* platform.
Doesn't mean it's the norm.
I've personally run tons of software from the 1.3 era on modern JREs with absolutely no problem. Perhaps you're just stuck with shite code?
Programmers cost money, they don't make it. Where did you get your MBA, anyway?
You have no idea what you are talking about. "Capacity on demand" has nothing to do with why a BC would run at 1/100 it's capacity (and there is no such thing as a 'base' model.)
In the mainframe world software is often priced by the capacity of the machine it is running on. Therefore, a customer who does not require speed can save significant money by ordering a machine that has had it's capacity reduced. That saves money on both the hardware and software.
One of the reasons IBM does not license z/OS to run on Hercules is because it breaks that pricing method. How would IBM and/or ISVs price their software, when the performance of the machine it is running on is completely unknown and changable? The other reason they won't license is z/OS is because Hercules infringes several of it's patents.
The other reason they won't license is z/OS is because Hercules infringes several of it's patents.
Awesome, so now software emulators that people can write in their spare time can infringe precious patents of huge hardware companies? Those patents can't have much in terms of actual worth, then.
Ezekiel 23:20
Is Slashdot really just getting worser and worser? What the f*#$ kind of grammar is "but IBM was such a large company and the problems of this was getting obvious". And like, they done maked a betterer computer than what they had maked before, I expect. And selled it to alot of they're customers and stuff. Their very clever at /. More cleverer by far than they are rivals.
Bollocks
http://www.acetonestudio.com
Tom got his ass kicked for libel http://slashdot.org/comments.p... and even worse, multiple times for Tom's numerous fails, here http://slashdot.org/comments.p...
The model 360 was the first machine I coded in assembler. I didn't realize until I learned assembler on a more sophisticated machine (an XDS mainframe) that the 360 didn't have stack instructions (i.e., push registers onto or pull registers off a stack).
Does anyone know whether IBM ever added push/pull instructions to their mainframes?
Circle the wagons and fire inward. Entropy increases without bounds.
You have no idea what you are talking about. "Capacity on demand" has nothing to do with why a BC would run at 1/100 it's capacity (and there is no such thing as a 'base' model.)
Not really, sure what your trying to say? Are you trying to say that IBM doesn't license the capacity (performance) of the hardware? Or that the minimum capacity you can for a machine is only a tiny percentage of the the capability of the hardware that arrives. Or maybe your being pedantic about the exact usage of CoD in relation to how IBM licenses the hardware/zOs/linux? Cause in the case of IFL (processors for running linux) the license is most definitely tied to the _HARDWARE_ and not the OS.
Because, i'm not going to get into a pissing contest, but I don't think you have ever been involved in the purchasing, scaling etc of a zSeries machine from IBM, because I can assure you the hardware is absolutely licensed.
Here is link I have handy from a couple years ago, where approximate prices for a z114 are listed.
http://www.tech-news.com/publi...
Notice, the fact that the minimum configuration is a 2818-A01 at 26 MIPS, and it goes up from there. Realize that there are actually only a couple different hardware configurations and that nearly all those "models" are simply capacity changes (via license keys) on the PEs.
You can click the EC12 button for more recent hardware.
Don't http://slashdot.org/comments.p...
Funny Tom shuts up disappearing after that post (not). Tom's busy "eating his words". At least Tom's polite (now that apk humbled him http://slashdot.org/comments.p... after that libel of Tom's for Tom's numerous mistakes). Tom doesn't talk with his mouth full (of his own words he had to eat).
I learned this one at Genericon, but it's older than that:
Music: "The Children's Marching Song"
Robert Osband, c.1974
This machine, it played one.
It pushed start and program run.
It's an IBM 360/85;
This computer came alive.
This machine, it played two.
Overloaded voltage to the CPU.
It's an IBM 360/85;
This computer came alive.
This machine, it played three.
Designed its memory to 1 IC.
It's an IBM 360/85;
This computer came alive.
This machine, it played four.
Changed its logic from AND to OR.
It's an IBM 360/85;
This computer came alive.
This machine, it played five.
Memorized data from tape drive.
It's an IBM 360/85;
This computer came alive.
This machine, it played six.
Told the CE what to fix.
It's an IBM 360/85;
This computer came alive.
This machine, it played seven.
Printed out the road to Heaven.
It's an IBM 360/85;
This computer came alive.
This machine, it played eight.
Shipped itself to Rome, Air Freight.
It's an IBM 360/85;
This computer came alive.
This machine, it played nine.
Told the Pope it was divine.
It's an IBM 360/85;
This computer came alive.
This machine, it played ten.
To sing once more push start again.
It's an IBM 360/85;
We computers are alive.
"Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
My one regret is I never learned any mainframe technology except from the client end. Over the years of my career, I worked with pretty much every other platform and OS that was available except for the mainframe and AS/400.
It's not an issue of marketability; I'd still be unemployable due to my migraines and therefore out of work. But it would have been fun to tackle yet another platform.
I do not fail; I succeed at finding out what does not work.
Trust me, I know infinitely more about it than you do.
You said 'because of capacity on demand...'. This is, in fact, false. The thing that lets them control the performance and configuration of the machine is not 'capacity on demand', it is 'Licensed Internal Code Controlled Configuration.' The use of LIC CC also allows them to offer 'capacity on demand', but they are not the same thing, and LIC CC does not require COD. Also, notice the name of that facility, it should give you a clue as to what is actually licensed.
Having said that, I already explained why multiple performance levels are offered. Why would you pay (for hardware and software) for more performance than you need?
Programs?! Try languages and APIs! Check out the docs for Processing, a pop "lanugage" (it's Java with some libs default linked in) for example. Online, service APIs frequently mismatch documentation and implementation.
Lower barrier to entry on all fronts means a stronger signal but much more noise, and attenuating well in the contemporary digital world is almost impossible. Choose the right subset and find entry (for you, worker17, maimframes) and it's a great filter, but not everyone wants to work on the same frequency as you.
Ok that metaphor got pretty tortured! But it holds. Docs blow, with precious and worthwhile exceptions.
So lets measure in big macs instead of bits.
Trust me, I know infinitely more about it than you do.
I make it a point to never trust someone who says the words "trust me." Also you're using hyperbole to support your position -- any position supported primarily by exaggeration should be treated as such and dismissed wholly.
I assume the reason that you're being so assertive is because you actually do know something about mainframes/IBM stuff. You're probably even known as 'the mainframe guy' in your circles. In fact, it looks like you got in an argument solely to announce to the world that you know not-only-something-but-more-than-most-people about this subject. You're pushing an agenda, it just happens to be narcissistic.
You have no idea what you are talking about.
I'm not saying that you don't know what you're talking about, but you sure like to tell other people that. It's almost like it's a required condition for some dearly-held part of your self-image or worldview.
... they invented the computer, created modern civilisation, etc. Where would be without them!
Oh, wait...
They couldn't even invent THE WHEEL, or a WRITTEN LANGUAGE...
Slashdot was never good.
-
'capacity on demand', it is 'Licensed Internal Code Controlled Configuration.' The use of LIC CC also allows them to offer 'capacity on demand',
Ok, so I got my terminology incorrect for the part that actually controls the hardware license. Other than that I believe my point stands (that Hercules on an inexpensive midrange x86 is faster than the slowest licensed BC12 config). And so your point was?
Why would you pay (for hardware and software) for more performance than you need?
That is not the right question. The question is why I should pay IBM millions of dollars to unlock the hardware I am paying the power bills on, providing the floor space for, and have "purchased". Yes, I know IBM won that lawsuit, but that doesn't mean IBM doesn't come across as the slimiest of business dealings for coming up with such a model. At least when HP rapes you for ink you actually get a product for it, rather than having them just unlock extra ink in the cartridge in your printer.
Especially since I don't actually need the mainframe. All the RAS features i need are available on machines that run Linux faster, for less than $15k, and require me to interact with the CE on a less frequent basis because in our sample of 1 mainframe vs a bunch of HP DL 580's. the HP's are actually more reliable. The HP's haven't needed any service since they were installed, unlike the mainframe which seems to need constant babysitting. Plus, I can spin up new VM's in vmware with a couple clicks of a button vs, screwing around with zVM for days.
So, asking why I should give IBM exorbitant fee's for something I can acquire elsewhere for far less is not the right question. Maybe a better question is why I'm paying hundreds of thousands of dollars for performance that is equivalent to the 20 year old Pentium that is sitting in the junk room next door. Or why I'm maintaining a machine that requires me to manually configure device addresses, and IODF's with text editors, or writing system exits in assembly to do simple things like roll log files or get notification of tape insertions.
Furthermore, if you want to understand where I'm coming from, take a look at the specCPU results in OMVS for a 240 MIP EC12. So, next time I'm sitting there wondering if I should pay IBM a couple thousand dollars to run my job a little faster this weekend, I will remember you asking me why.
So, yah, there is a reason younger people don't want to work on those archaic machines. They don't want to work somewhere that compute time is so carefully guarded, especially since they could just spin up 1000x the compute (and even IO with the SSD instances) performance for a few dollars on EC2.
You can say a lot of bad things about Java, but the JVM really neatly solves this problem.
It solves the problem so neatly that we keep several VMs around with different Java versions, just to maintain older systems that were developed with Java 1.3 or 1.4 and break as soon as you install Java6 oder Java7.
It fairs pretty well compared to other environments when you are ripping the 2000-2002 carpet out from under an application for a 2006-2011 one.
For example, jumping from Red Hat Linux 7/8 (this is before RHEL!) to Red Hat Enterprise Linux 5/6, good luck with that!
Or, Windows 2000/XP to Windows Vista/8, I'm sure mileage varies here quite a bit as well.
And libeler: How'd "eating your words" taste? See here http://slashdot.org/comments.p... were they flavorful (lol) seasoned with "the bitter taste of SELF-defeat" + YOUR FOOT IN YOUR MOUTH you bigmouth libelous Open SORES bullshitter?
As to the rest of my subject, let's let TOM speak shall we:
"I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage
FROM -> http://slashdot.org/comments.p...
The Computer History Museum and Richard Tedlow put on a very interesting and entertaining talk about the circumstances that led up to the birth of the 360 here:
http://www.youtube.com/watch?v=DcqganpWfd8
My information may be about a decade out of date but in the Memphis, TN area, I know of several mainframe users:
FedEx
Autozone
USPS (although this was moved to Indiana 7 or 8 years ago, but the jobs are still on-site last I heard).
Big Iron is one of those niches that I've always wanted to work with, much like how UNIX in general is what I fell in love with in the 90s.
If you were me, you'd be good lookin'. - six string samurai
And if you get paid electronically via bank transfer, its a good bet that the machines at both your bank and your employers bank that handle the transactions are mainframes of some sort.
IBM Mainframe cpus are really slow. A very large mainframe with 75.000 MIPS (one of the largest and most expensive) with 24 sockets, is matched by two 8-socket x86 servers in terms of cpu performance. One guy who ported Linux to IBM Mainframes, could test same software on x86 and on Mainframes and concluded that 1 MIPS equals 4 MHz of x86. So, 75.000 MIPS = 300 GHz worth of x86 cpus. But one decent Intel x86 cpu has 10 cores running at 2GHz, thus, it equals 20GHz. This shows that 15 intel cpus gives 300GHz. Thus, you need two 8-socket x86 servers to match the largest baddest most expensive IBM Mainframe:
http://www.mail-archive.com/linux-390@vm.marist.edu/msg18587.html
Another source builds IBM Mainframe emulators for a living, and you can emulate a Mainframe on a laptop using the open source TurboHercules software. In fact, a 8-socket x86 server gives 3.200 MIPS under emulation. But if you could run natively, the code would run 5-10x faster. Hence, those 3.200 MIPS from one 8-socket x86 server, would translate to 16-000-32.000MIPS. And again you only need two 8-socket x86 servers to reach 60.000 MIPS (equivalent of the largest IBM Mainframe):
http://en.wikipedia.org/wiki/TurboHercules#Performance
There is a reason IBM shut down the open sourced TurboHercules emulator. Because it threatens the Mainframe business. You just need a cheap 8-scocket x86 server which gives a mid-sized Mainframe. IBM was really ugly against TurboHercules:
http://www.zdnet.com/blog/open-source/why-the-turbo-hercules-case-matters/6209
There is a reason IBM never releases benchmarks of Mainframes to x86 or POWER or SPARC cpus. Because Mainframes have sloow cpus. Yes, they are slow, I am talking about this one: 24 such IBM cpus give 50-75.000 MIPS (which is matched by two 8-socket servers):
http://www.engadget.com/2010/09/06/ibm-claims-worlds-fastest-processor-with-5-2ghz-z196/