Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fifty Years Ago IBM 'Bet the Company' On the 360 Series Mainframe

timothy posted about 5 months ago | from the y'-tell-the-kids-that-today dept.

IBM 169

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.""

cancel ×

169 comments

Sorry! There are no comments related to the filter you selected.

Cool (-1)

Anonymous Coward | about 5 months ago | (#46682367)

Cool :)

The Mythical Man-Month (5, Informative)

Peter Simpson (112887) | about 5 months ago | (#46682377)

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.

Re:The Mythical Man-Month (2)

Anonymous Coward | about 5 months ago | (#46682527)

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.

I still have that book (one of my favorites). It was required reading while pursuing my graduate degree in Software Engineering.

I also have fond memories of working on the IBM 360 iron writing assembly code.

Without the big horses running in the background, technology and life as we know it would crawl at a snails pace.

Pointless fact (1)

Anonymous Coward | about 5 months ago | (#46682559)

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!

Re:The Mythical Man-Month (2, Interesting)

Anonymous Coward | about 5 months ago | (#46683171)

I once worked on a project for a big client, and was duly impressed that the manager had a whole case (well, half-empty by the time I saw it) of copies of MMM. He offered me one and was pleased to hear that I already owned a copy. One of the best customers I ever worked with.

It's a big warning sign when a manager has not only not read Mythical Man-Month, but has no idea what Brooks' Law is.

Re:The Mythical Man-Month (1)

ebh (116526) | about 5 months ago | (#46683785)

Definitely. Add to that "Quality is Free" by Crosby, and "Peopleware" by DeMarco and Lister.

Re:The Mythical Man-Month (1)

CastrTroy (595695) | about 5 months ago | (#46684167)

Maybe good for those starting out in the field, but I read it after a few years in the field, where I had already been through a few big projects. I didn't much I didn't really know or suspect already. It's pretty obvious working in the field that adding more people to a project, especially when it's already late doesn't make things go faster. I think that probably applies to many types of projects, not just software development. I can see how it might be useful for non-technical managers read it, because if some of the concepts may be new to people who haven't worked in the trenches before. But I also think people who haven't worked in the trenches in most cases are the best candidates for managing a big project.

software (1)

Anonymous Coward | about 5 months ago | (#46682395)

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.

Re:software (4, Interesting)

jfdavis668 (1414919) | about 5 months ago | (#46682435)

The problem is finding someone new willing to maintain the software. We have large systems running on big iron. The people who maintain it are getting older and fewer. We struggle trying to get someone new motivated to learn the technology. It's not an issue with the hardware, you can continue to upgrade that. It's finding someone who is willing to work in software that is no longer popular.

Re:software (5, Insightful)

serviscope_minor (664417) | about 5 months ago | (#46682493)

We struggle trying to get someone new motivated to learn the technology.

I wonder how the banks end up getting people working in banking. After all, it's dull (yeah, the maths in the software is generally not that interesting), high stress and ultimately pointless. I guess they find *some* way of motivating those people.

Basically, if you're running mainframes, then your business is large enough (heck the individual computers are expensive enough) that you can afford to pay top dollar to motivate some very solid programmers to work for you.

Offer a good package with good benefits for what is in your region (e.g. healthcare in the US, 5 weeks time off in the US---these things are standard elsewhere so other regions will need other benefits), a low stress, no overtime working environment (no regular crunches or whatever), decent work-life balance sort of thing and a decent pay package and you will find good people. Oh, and training, too.

You won't get the youngsters who are happy to burn out on 80 hour weeks for a year who want to hack the latest cool thing in the latest fad tech but with a small chance of becoming a billionaire, but you will get very, very good, experienced and almost certainly older programmers who want a work-life banance. They might have families, hobbies or even just shifted priorities, you see.

You might have to train them up, but that's not goint to cost all that much in the grand scheme of things.

Basically, if you can't get the people it's because you're not prepared to pay (that includes money, benefits and training).

Re:software (1)

Anrego (830717) | about 5 months ago | (#46682707)

You have to weight that cost, and the ongoing cost of that approach against migrating to something new.

As pre-canned software becomes more flexible and cheaper, and talent to tweak it into what you need, simply tossing out a perfectly functional system starts to make more sense.

Then again, we've got crap like SAP as a pretty good encouragement to pour more money into that old mainframe and hold off for a few more decades..

Re:software (5, Insightful)

serviscope_minor (664417) | about 5 months ago | (#46683109)

As pre-canned software becomes more flexible and cheaper, and talent to tweak it into what you need, simply tossing out a perfectly functional system starts to make more sense.

True, but the annals of software engineering are littered of examples of hugely expensive failures along those lines. It is possible, but it is almost certainly much more expensive and much more difficult than most people in a position to pay realise. I think part of the problem is it's basically a wholesale change in one go. This makes it very difficult to have a staged migration of any sort.

Also, every company is unique, especially those big enough to own their own mainframe. Those are also likely to be old and have baggage. That generally means an "off the shelf" system requires so much customisation it's more like a rewrite from scratch using a large, expensive and probably badly written framework.

Here there be dragons.

Re:software (2)

jythie (914043) | about 5 months ago | (#46682867)

Beyond initial pay though there is a bigger problem, job prospects. Young programmers often look at jobs in terms of how good it will look on a resume when trying to find their next job, and mainframe jobs are perceived as being resume stains, filled with buzzwords that will get your resume thrown in the bin even at another company using similarly aged technology.

Re:software (5, Informative)

thoriumbr (1152281) | about 5 months ago | (#46683029)

Looks like you know nothing about mainframes and "aged technology". I work with mainframes. zVM, DASD, DirMAINT, RACF and other buzzwords are in my resume, along with Linux, Java, PHP, XML, jQuery, MariaDB, HTM5, Eclipse and others.
Mainframes are not aged technology. They are perceived as such by small companies and people. Big companies with big bucks know a lot about mainframes. They know mainframes are the most reliable hardware platform on the market today, and I guess it will continue as so for a couple of years, because mainframes were made from the start to be reliable. Other platforms got they reliability implanted on them. Mainframes were designed reliable and resilient.
Mainframes today runs Linux too, not only the "aged mainframe operational systems." And here we have mainframes running hundreds of Linuxes with jBoss. They are about to be orchestrated by OpenStack, so managing all this "aged technology" will be done in brand new Android and iOS tablets.

Job prospects in my area, at least for the next decade, are very good. Half the openings in my area are still open, paying for a intermediate zVM administrator almost twice what a senior Java programmer or MCSE will receive. And there's no people applying!
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.
Peer pressure is a greater force than job prospects. I faced this pressure when I talked to my peers that I was learning mainframe and everybody laughed at me. Now I earn 3 times what they do, and I am training some of them to work with me.

Other problems . . . (1)

walterbyrd (182728) | about 5 months ago | (#46683537)

>>
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.

Re:Other problems . . . (2)

serviscope_minor (664417) | about 5 months ago | (#46683623)

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.

Then don't insist on programmers in their 20s. There is a good and continually renewed supply of programmers in their 30s and 40s. The only reason to insist on 20 year olds is cost, and this is a problem easily solved with the application of money.

We're talking about companies big enough to own whole mainframes. These are not small companies.

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.

It's only tautologically mandatory from the companies that insist it is so. If they're having trouble recruiting the problem is not the lack of supply but that the salaries are too low/the benedits are too bad/the requirements are needlessly strict.

Sure training isn't free, but my thesis here is that supply is only a problem because companied aren't willing to pay. If they're happy to fork out for programming and salaries and benefits suitable for programmers in their 30s and 40s, their supply problems will disappear.

Re:software (3, Interesting)

jandersen (462034) | about 5 months ago | (#46684503)

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.

Well, that's the problem to solve, then.

1) Make it less difficult to learn - this is only a matter of investing in producing good teaching material and making it easily available.
2) Make the idea of mainframes much more appealing. There's loads of stuff in a mainframe and even in z/OS, that is way cooler than the average PC crap.
3) Make it legal for people to download and run z/OS etc on the Hercules emulator for development and study purposes after a similar model like Oracle's

People have taught themselves Linux and Windows, not because it is more interesting, really, but because it is much more approachable; and within the reach of a tight budget. Which teenager is going to invest tens of millions in a mainframe? Make it free, like Oracle did with their database - it worked for them.

Re:software (-1)

Anonymous Coward | about 5 months ago | (#46683065)

I work for a company that uses a mainframe system designed in the 60's/70's. After a few years of that, I'm leaving because it's seriously killing my tech skills outside of that world and I don't see myself working on this crap for the next 25 years. Proprietary mainframe infrastructure and apps all around don't make for good job marketability. At this point, cramming for an MSCE feels refreshing.

Re:software (0)

Anonymous Coward | about 5 months ago | (#46683861)

I can see your point to a certain extent but I can only assume you're a z/OS guy as Linux and VM are very much a growing market and z/VM skills are few and far between with a great deal of people who have those skills are retiring. I'm pretty thrilled to be a young(ish) person working on the platform with the potential of filling the skills shortage in the future. That combined with the zNextGen initiative I think will keep a small but enthusiastic group employed for decades to come.

Re:software (4, Interesting)

serviscope_minor (664417) | about 5 months ago | (#46683073)

Beyond initial pay though there is a bigger problem, job prospects. Young programmers often look at jobs in terms of how good it will look on a resume when trying to find their next job, and mainframe jobs are perceived as being resume stains, filled with buzzwords that will get your resume thrown in the bin even at another company using similarly aged technology.

Part of the problem is targeting young programmers then: companied often do because they're cheap, can be easily bullied into working long hours and don't have a family/life outside work. Older programmers generally demand more pay and less crap which makes them more expensive.

The other thing of course is if you can offer training and/or a mixed job, e.g. 50% on mainfraim, 50% on whatever more modern front end the mainfraim connects to, you can also keep your employees current with their skills. Quite possibly more expensive, but it may well have hidden benefits too to have an experienced programmer with experience and knowledge of the complete system.

Either way, though it still comes down to cost.

Re:software (1)

Zontar_Thing_From_Ve (949321) | about 5 months ago | (#46682989)

Basically, if you can't get the people it's because you're not prepared to pay (that includes money, benefits and training).

I agree with the post (just quoted the last part to save space), but I'd also point out that banks are going to have to overpay to get young people interested in learning this. You're trying to get new workers interested in what actually is dying technology. If one day your bank has an epiphany and decides to port everything to Linux, those trained young workers are likely to be out of a job and finding that the number of people who use that old technology is shrinking, not growing. Your bank could get bought out by a larger bank who uses more modern computers and the same problem occurs for the displaced younger workers who have skills that nobody wants.

Re:software (1)

bws111 (1216812) | about 5 months ago | (#46683075)

What computer do you consider 'more modern' than an IBM EC12? What makes you think the technology in mainframes is 'dying'?

Re:software (1)

bored (40072) | about 5 months ago | (#46683433)

What makes you think the technology in mainframes is 'dying'?

Fewer actual machines being installed. No new projects being started on native mainframe tech (new mainframe projects seem to be overwhelmingly Linux/java/other platform agnostic technologies). IBM advertises the fact that their "capacity" install numbers are going up every year, but the machines have been getting significantly faster the last few years as IBM started taking machine performance seriously again so they bury the bad news.

Re:software (1)

bws111 (1216812) | about 5 months ago | (#46684153)

What are you talking about? What the heck is 'native mainframe tech'? z/OS? By that logic, x86 is also 'dying' because servers are moving from Windows to Linux. In 2012 IBM sold more mainframes, as measured in units, capacity, and dollars, than at any point in it's history. Over half of the capacity was in the form of 'new workload' engines. In other words, the market grew, not shrank.

And what do you mean by 'taking perfomance seriously again'? There has never been a time when they didn't take performance seriously. Mainframes have been on an 18-24 month release cycle for decades, and every new machine has been significantly faster than the previous generation. The only time this wasn't true was in the mid-90s, when IBM changed the technology from bipolar TTL to CMOS microprocessors. That change wasn't because they didn't care about performance, but because customers no longer wanted machines that cost $40M and took up an entire room and used enough energy to power a small town. CMOS technology finally caught up to the performance of the old bipolar machines around 2000.

Re:software (1)

Oligonicella (659917) | about 5 months ago | (#46683113)

Spent most of my career working in banking. No, it's not dull, yes (like every other career) it's stressful, no it's not pointless. Banking also makes use of much more than mainframes; Tandem, networks and PC's for instance. Perhaps one of the reasons is the attitude you can see displayed here frequently, older tech is "bad" and to be disparaged for the newest thing on rails.

Re:software (-1, Flamebait)

clintp (5169) | about 5 months ago | (#46683471)

We struggle trying to get someone new motivated to learn the technology.

I wonder how the banks end up getting people working in banking. After all, it's dull (yeah, the maths in the software is generally not that interesting), high stress and ultimately pointless. I guess they find *some* way of motivating those people.

Agreed. Adding my own anecdote.

(modesty filter off for a moment)

I'm a talented programmer. Yes, I'm in my 40's, but I'm also well-versed in tech both new and old. I keep up with the kiddies and their frameworks-of-the-month for web, mobile, and other development platforms. I grok my systems from the applications down to the network protocols on the wire and the byte arrangement on the disks. I can train, have written books, deal with management well, and mange people adequately. I can work where I want to, command good salaries, and have turned down good offers recently.

(modesty filter back on)

I'm currently working in the Payroll industry in the midwest. Not quite banking, but well, it's close. The core application here is from the 1980's. Legacy shit abounds in this place. Our vendors are using tech even older, judging by how file exchange and their API's look. Government and regulatory agencies are terrible partners. Progress is slow, cumbersome, and painful.

Why the hell would I work here? Employers take note:

    * They pay me very well.
    * I have a short commute. I don't waste a lot of time in my car or on a train.
    * They don't work me very hard. Honestly I can come and go as I need. My time off is mine.
    * Regulatory deadlines are distant, well-known, rock solid, and usually easily achieved. Congress notwithstanding.
    * There's money here. If I need equipment, it shows up. If I need software, it gets bought.
    * My software is quietly useful. Millions of people look at their paychecks (or bank statements) and most of the time it's just right.
    * I am not technologically micromanaged. I can use the tools I want, the way I want.
    * My employers are good at weeding out poisonous co-workers. I don't work with assholes, ever.
    * The challenges are of my own devising. I have enough time to experiment, throw away, re-work, and try new things.

All of that is how dull industries like banking (and payroll) wind up with talented people.

Re:software (0)

Anonymous Coward | about 5 months ago | (#46683503)

I know I'd certainly be motivated by a solid salary, reasonable job security, regular hours and decent benefits. I'm not ancient, early 40s, but a good work life balance and not having work be a major stress factor in my life is what's important to me now.

Re:Software (0)

Anonymous Coward | about 5 months ago | (#46683585)

Offer a good package with good benefits for what is in your region (e.g. healthcare in the US, 5 weeks time off in the US---these things are standard elsewhere so other regions will need other benefits), a low stress, no overtime working environment (no regular crunches or whatever), decent work-life balance sort of thing and a decent pay package and you will find good people. Oh, and training, too.

Nope. Too hard. Maybe there's someone in India will to work on this.

Re:software (2)

bored (40072) | about 5 months ago | (#46683633)

Basically, if you can't get the people it's because you're not prepared to pay (that includes money, benefits and training).

I'm going to second this. Because I had a z114 dropped on my lap as part of my current job. I hear about the talent shortage all the time. I even took the time to do some basic research on mainframe pay scales... And let me quote some other guy answering a similar question..

"why should I learn mainframe tech, when I can make 30% more doing PHP, and I don't have to worry about being sidetracked out of the job market in 5 years"

At this point companies are willing to pay IBM 7-8 figure numbers for hardware that performs similarly to high 5 figure x86 hardware, but choke over paying starting z/OS systems programmers (with other industry experience) 100k+ a year.

At this point companies running mainframes better start expecting to pay gold plated compensation packages (pushing 200k+) or they will continue to have a hard time finding people willing to spend a couple years learning technology that is pretty archaic in the grand scheme of things.

We install our product into mainframe shops, and I can't tell you how many I've seen that have their old retired mainframe guy on "retainer" for emergencies. He shows up once every couple weeks to fix something that has broken, but nothing else. Usually, he is just there to support the machine long enough for the team rewriting the application in java/whatever to get it working. Probably half of these shops, thought they would be off the mainframe a few years ago, but their replacement application still doesn't work... Frankly, after having interacted with some of the teams I can understand why the mainframe guys is probably going to die before they get it done...

Re:software (3, Insightful)

K. S. Kyosuke (729550) | about 5 months ago | (#46682507)

Use the free market solution: offer a sufficiently high salary!

Re:software (2, Interesting)

Tom (822) | about 5 months ago | (#46682581)

That's because the software is largely crap. I say that as someone who still learned COBOL and yes, on a mainframe, in university.

Seldom have I been so glad to forget everything about a programming language as quickly as possible after passing the exam.

The thing about old systems is that there are some that got lots of things right - Multics ACL and security still runs circles around Unix and giggles about Windows - and some of them were just horribly misguided (like COBOL, the programming language invented specifically so the business types had the wrong impression they could understand it).

Computing is this strange discipline where people either take the old and with it everything that sucked about it, or reinvent the wheel even though there was nothing wrong with the old one. Only rarely do people leave the good unchanged and improve only the bad.

I don't mean inventing a new programming language with all the best features from all the other programming languages you like - you still create a new language that needs to be learnt, will have implementation bugs early on, etc. etc.

Re:software (1)

Anonymous Coward | about 5 months ago | (#46682671)

Business types could understand it. It is far easier to teach programming to an accountant (General Ledger, payroll, billing), engineer (power plant modeling) etc then to teach a programmer the business/engineering. And we were teaching them PL/I. with pointers and call backs.

Re:software (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46682777)

And we were teaching them PL/I. with pointers and call backs.

Not with blackjack and hookers? PL/I has everything in the language. ;-) (Which is probably why it failed to gain any broader acceptance in the first place.)

Re:software (2)

Tom (822) | about 5 months ago | (#46683697)

I disagree on that. I've seen plenty of management and business types "do programming" with their excel and access scripts and word macros, or with SQL or javascript or whatever else they have available. Because their first mistake is taking what they have available, and not what's the proper tool for the job.
The problem with teaching non-techie people programming is that you end up with software that I would've ripped you a new one for back in university when I was the assistant for the C programming course.

Basically, this ultra-low level of programming will be lacking exactly the parts that you really, really want in a business application. Exception handling, input validation, that kind of stuff that makes sure a user error doesn't blow up your accounting system.

Programming is not about being able to write:

$pay = $wage - $taxes;
sendToPaymentHandler($employee, $pay);

It's about making sure that $taxes can't be negative, $employee is properly set, the input field for $wage only accepts numbers, the payment handler returns a success code and your money still arrives if the connection is down at that second and the call needs to be repeated, everything is logged properly so in case one of the "impossible" failures does happen you can trace where the money went and a thousand other things that aren't half as sexy as that.

Technical and business people both live under the same illusion of thinking that with a bit of training they could do each others job. Few people think that about brain surgeons. But studying computer science, or business economics, or medicine is really quite comparable. (I only personally studied the first two, but I have plenty of friends in the 3rd field, which is why I think I can make the comparison.)

I know that I can't do the job of a marketing or sales person, because I lack the knowledge and experience to do it. I can't do a callcenter job, either. Or a firefighters duty. So don't tell me that someone with no prior experience in my field can be brought up to speed with a bit of training.

Answer a question Tom (-1)

Anonymous Coward | about 5 months ago | (#46684271)

How'd "eating your words" taste? See here http://slashdot.org/comments.p... [slashdot.org] were they flavorful (lol) seasoned with "the bitter taste of SELF-defeat" + YOUR FOOT IN YOUR MOUTH you bigmouth libelous Open SORES bullshitter?

Tom, you're a lot of TALK (no action) (0)

Anonymous Coward | about 5 months ago | (#46683077)

Show software you've done lately. Don't have any? Thought so. You're a blowhard bullshitter.

Re:Tom, you're a lot of TALK (no action) (1)

Tom (822) | about 5 months ago | (#46683551)

Plenty of it on github, lots more in older Free Software projects and another 150,000 or so lines of code in closed-source applications, including several commercial ones. Before you troll me, make sure you're not running any of my code on your Linux machine right now, because it could be. :-)

Bullshit: Answer a question (-1)

Anonymous Coward | about 5 months ago | (#46683569)

How'd EATING YOUR WORDS taste? http://slashdot.org/comments.p... [slashdot.org] were they flavorful (lol) seasoned with "the bitter taste of SELF-defeat" + YOUR FOOT IN YOUR MOUTH?? Any moron can copy others' code from "Open SORES" & call it his own (like you obviously do).

Tom's also a libeler (-1)

Anonymous Coward | about 5 months ago | (#46683095)

Who had to "eat his words" here http://slashdot.org/comments.p... [slashdot.org] So, how did "eating your words" taste, Tom? Were they flavorful (lol) seasoned with "the bitter taste of SELF-defeat" + YOUR FOOT IN YOUR MOUTH??

Re:software (1)

Oligonicella (659917) | about 5 months ago | (#46683211)

(like COBOL, the programming language invented specifically so the business types had the wrong impression they could understand it).

Oh bullshit. Do you realize that there's levels to COBOL beyond one, right? That it's business oriented was not to sell to bosses, but to streamline development for business applications. Get your head out.

Re:software (0)

Anonymous Coward | about 5 months ago | (#46683499)

Tom's a libelous blowhard bullshitter man: Accept it. Read other replies to his here and see that much. Especially Tom having to eat his words for libeling the work of others (which tom doesn't even have anything like or other apps to his name he can show he actually programmed either - like I said, he's a libelous blowhard bullshitter talker).

Re:software (1)

Tom (822) | about 5 months ago | (#46683527)

There's a difference between writing a language streamlined for a specific purpose and writing a language where a = 1+1; is expressed as ADD 1 TO 1 GIVING A.

I'm fairly sure I've heard every argument pro-COBOL. I studied this stuff. I've had this discussion a dozen times. I remain unconvinced. :-)

Big talk: Why avoid a question then? (-1)

Anonymous Coward | about 5 months ago | (#46683601)

How'd EATING YOUR WORDS taste? http://slashdot.org/comments.p... [slashdot.org] were they flavorful (lol) seasoned with "the bitter taste of SELF-defeat" + YOUR FOOT IN YOUR MOUTH?? Big talking BLOWHARD Tom got his ass shot the fuck down for his big mouth he can't back up his b.s. on.

Re:software (1)

smallfries (601545) | about 5 months ago | (#46684417)

I was going to mod you up as I once had to study COBOL for exams, a long time a go. But then I clicked on your hidden replies and my, oh my. I had to reply instead to say that you really have attracted one of the most virulent trolls that I've ever seen on slashdot. You should get some kind of flair next to your username or something.

Re:software (0)

Anonymous Coward | about 5 months ago | (#46682681)

It's not entirely the popularity of it.

Maintaining legacy code generally sucks. The code has decades of history. Mounds of workarounds. It's been hacked on and tweaked by a precession of shitty devs and interns, retooled over the years to do things it was never meant to do, etc.

It's bad enough doing this in a language like c, where you've at least got encapsulation helping out a bit. Trying to work on a massive code pile with 20 years of history and not break something is an exercise in extreme tedium.

Very few people out of school want a job maintaining something someone's already written. Most people will settle for maintaining something that is at least maintainable. Becoming the master of some old arcane system is unappealing regardless of language.

Re:software (1)

ebh (116526) | about 5 months ago | (#46683925)

Unappealing, yes (I'm in the throes of it now), but good for job security.

Re:software (1)

Anrego (830717) | about 5 months ago | (#46684181)

Yup.

I know someone who is a guru in foxpro. Remember foxpro! I laughed until she pointed out that it had basically paid for her house.

It seems like one of those bubbles that's too late to get into now, but if you got into it 10 years ago, you are now very well off with probably enough remaining work out there to ride out to retirement.

Re:software (1)

jacobsm (661831) | about 5 months ago | (#46683129)

You're 100% correct, but I'll add that it's very difficult to get management to bring in new people and give them the opportunity to learn from people who've had decades of experience in the technology and systems that the business depends on.

In my case I'm coming up on 36 years experience in the mainframe world, and I've got no one to teach my skillset to. As for people not wanting to work in a mainframe environment I've got a few comments that might help change their minds.

1) The mainframe isn't going away anytime soon.
2) Competition for jobs in the field is going to be on the side of the job seeker, not the employer once demand picks up (as we geezers retire) and supply of talent will be lower than for the more sexy IT positions.
3) According to the the free market system, if demand is high and supply low, prices rise. And in this case that means your salary.

Re: software (0)

Anonymous Coward | about 5 months ago | (#46683941)

It's not enough to motivate them to support something like a mainframe. Remember, we're been telling people that mainframes are old. That's one problem. We also tell developers that unless you are experienced in the latest frameworks and languages, you're SOL when it comes to getting a new job.

To developers, a mainframe means lock-in at a dead end job. To most managers, a mainframe programmers is unemployable. Being a mainframe programmer is a feast or famine kind of thing: when they need to you, they desperately need you. When they don't you're out of luck.

Until that's addressed, no one can expect an old platform to be supported much beyond it's moment of glory.

Re:software (1)

Wootery (1087023) | about 5 months ago | (#46682489)

There's little point throwing away decades of refined code just for the sake of it.

I agree, but who's saying otherwise?

Re:software (0)

Anonymous Coward | about 5 months ago | (#46682813)

Lots of people. There is (or at least used to be) some sort of strange disease among upper management at tech firms that caused them to view old code as stale. Never quite understood it but it was amusing watching companies in the early aughts self destruct because of it. After all, it's basically what killed Netscape.

Re:software (0)

Anonymous Coward | about 5 months ago | (#46682901)

After all, it's basically what killed Netscape.

What did "viewing old code as stale" have to do with Microsoft's illegal destruction of Netscape?

Re:software (2)

Will.Woodhull (1038600) | about 5 months ago | (#46683595)

On the contrary, there was lots of reason to suspect old code of being inefficient on new machines.

Much of that old code used clever techniques, highly rewarded when they were developed, to fit the software to the limitations of those ancient machines. When you have 48 K of core, and that is all you've got, you choose algorithms that can be written in tiny loops that will fit, and you use re-entrant techniques so that the code that is already in place for the date calculation can be re-used to calculate part of the return on investment, depending on the state of a one bit flag tucked into some other process. That could save seconds, or even minutes, by avoiding loading new code from tape. You optimize the size of the Hollerith card decks, to decrease the number of boxes that have to be hauled around on hand trucks, and the hours needed to read and compile the cards to tape.

It was much more important that the program could be compiled to tape in the 11 pm to 5:30 am time slot than how efficiently it would perform during the workday. Workday performance enhancements could be added in later revisions.

Love it (1)

Anrego (830717) | about 5 months ago | (#46682401)

"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!

Frists Pot (2)

Hognoxious (631665) | about 5 months ago | (#46682445)

Would've got an FP if I hadn't dropped the card deck.

"The cloud" == reinventing the mainframe (1)

Anonymous Coward | about 5 months ago | (#46682453)

Data and processing on a remote computer, accessed via a dumb terminal.

Yep, that's "cloud computing".

Everything old is new again.

Re:"The cloud" == reinventing the mainframe, badly (1)

davecb (6526) | about 5 months ago | (#46683087)

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.

Re:"The cloud" == reinventing the mainframe (0)

Anonymous Coward | about 5 months ago | (#46684159)

Mainframes are more expensive then cots x86 server hardware...ECONOMICS FTW...

Virtual Machines (-1)

Anonymous Coward | about 5 months ago | (#46682463)

"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,"

You can say a lot of bad things about Java, but the JVM really neatly solves this problem.

(Someone will say "just recompile it", but even assuming you've kept your own source code cross-architecture safe, which isn't a given in C/C++, good luck tracking down the source for all the libraries you use, especially when some of them are proprietary.)

Re:Virtual Machines (-1, Flamebait)

Sique (173459) | about 5 months ago | (#46682689)

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.

Re:Virtual Machines (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46683201)

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. :-)

Re:Virtual Machines (1)

bored (40072) | about 5 months ago | (#46683999)

There have apparently been a number of JIT'ed versions of hercules http://www.hercules-390.org/ [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.

Re:Virtual Machines (2)

bws111 (1216812) | about 5 months ago | (#46684331)

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.

Re:Virtual Machines (-1)

Anonymous Coward | about 5 months ago | (#46683253)

Let me guess: that code only runs on hotspot? Yeah, thought so. This is what happens when you let morons code. The documentation for com.sun.* says it's not part of the java api and that is could change for no reason whatsoever. Then you go and use it. Well tough titties, dumbass.

Re:Virtual Machines (0)

Sique (173459) | about 5 months ago | (#46683309)

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.

Re:Virtual Machines (0)

Anonymous Coward | about 5 months ago | (#46683675)

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).

Re:Virtual Machines (1)

Tom (822) | about 5 months ago | (#46683741)

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...

Answer a question Tom (-1)

Anonymous Coward | about 5 months ago | (#46684291)

How'd "eating your words" taste? See here http://slashdot.org/comments.p... [slashdot.org] were they flavorful (lol) seasoned with "the bitter taste of SELF-defeat" + YOUR FOOT IN YOUR MOUTH you bigmouth libelous Open SORES bullshitter?

The Power of PROPAGANDA (0)

Anonymous Coward | about 5 months ago | (#46683917)

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.

Re:Virtual Machines (0)

Anonymous Coward | about 5 months ago | (#46684063)

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.

Re:Virtual Machines (0)

Anonymous Coward | about 5 months ago | (#46684069)

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?

Re:Virtual Machines (1)

TheRaven64 (641858) | about 5 months ago | (#46683239)

The JVM nearly solves a problem that was solved by the IBM/360 in 1960? That's... great.

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.

It also killed innovation (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46682497)

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).

Re:It also killed innovation (3, Insightful)

serviscope_minor (664417) | about 5 months ago | (#46682553)

I'd estimate that it killed something like ten years of pushing research results into practice

I don't see how. Apparently the CDC6600 was OoO in the 1970s. I think the main problem is that OoO requires a lot of resources.

I think it took until the 90's because before then there were just not enough on-chip resources to make it worth doing out of order. There were other things that took higher precedence, like wider busses (moving up to 32 bit at the time), things like hardware multiply and divide, wider static issue, floating point in hardware, etc.

In other words, OoO is only really worth it when your processor is so wide that you can't easily fill all the execution slots with static scheduling.

Re:It also killed innovation (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46682605)

I don't see how. Apparently the CDC6600 was OoO in the 1970s.

I don't think so. It's my understanding that CDC6600 handled interlocks but not reorderings. My point wasn't really as much about whether it was possible to widely employ this in the 1970s but rather that IBM got onto a track that essentially cast the S/360 ISA into stone (an irony, given how much was this ISA actually designed to be microprogrammed), and without that, a project similar to IBM 801 combining its own research with the ACS-1 results probably would have happened earlier. For a long time since the inception of S/360, there was a lot of pressure inside IBM to not do things that didn't have anything to do with S/360.

Re:It also killed innovation (4, Informative)

Required Snark (1702878) | about 5 months ago | (#46682919)

The IBM Stretch had an early form of out of order execution. This was in 1959.

http://people.cs.clemson.edu/~mark/stretch.html [clemson.edu]

Amdahl discussed his original idea for lookahead with John Backus "two or three times". "And John thought what I had proposed initially, he couldn't do a compiler for. So we went ahead and redid it. And we came out with the thing that was the look-ahead structure of the STRETCH." [p. 71, Norberg]. Amdahl recalls that "principally the look-ahead pre-fetched instructions to see branch instructions early enough so that we could get the succeeding instruction and data for each of the two alternative branch paths"

The CDC6600 a more advanced form in 1964.

http://en.wikipedia.org/wiki/Out-of-order_execution [wikipedia.org]

Arguably the first machine to use out-of-order execution was the CDC 6600 (1964), which used a scoreboard to resolve conflicts. In modern usage, such scoreboarding is considered to be in-order execution, not out-of-order execution, since such machines stall on the first RAW (Read After Write) conflict. Strictly speaking, such machines initiate execution in-order, although they may complete execution out-of-order.

From the same source:

About three years later, the IBM 360/91 (1966) introduced Tomasulo's algorithm, which made full out-of-order execution possible.

CMU 1968-72 (2)

lfp98 (740073) | about 5 months ago | (#46682521)

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.

Re:CMU 1968-72 (1)

Anonymous Coward | about 5 months ago | (#46682651)

No security at all in those days, so occasionally your program cards would be stolen

For once, the phrase 'software piracy' is accurate here.

Re:CMU 1968-72 (1)

Lawrence_Bird (67278) | about 5 months ago | (#46682703)

My older brother shuffled your deck.

Re:CMU 1968-72 (1)

Hugh Pickens DOT Com (2995471) | about 5 months ago | (#46682869)

Same here.

We had a 360/50 that occupied one entire floor of the building.

Turn in your cards then wait 12 hours to get your print out and see if it even compiled.

Basicly if you had a CS problem due in a week you had 14 chances to write your program and get all the bugs out before it was due.

Re:CMU 1968-72 (0)

Anonymous Coward | about 5 months ago | (#46683283)

The 360/50 wasn't that big, you must have had a lot of tape drives and/or DASD (aka disk drives). We had a 360/50 that occupied a corner of the (relatively small) computer room, the general use campus mainframe was a Burroughs B6700. I ended up hacking myself a CANDE (timesharing) account on that to get around the punch card bottleneck. (Although it wasn't that bad. We didn't have to "turn in" our cards; there were RJE stations around campus with card readers and line printers so we could submit our own jobs.)

First job I had after college we had a 360/40 and a 360/50, the computer room occupied about 1/3 of the floor of the building. No huge storage farm, we didn't really need it (or storage densities were improving by then).

Re:CMU 1968-72 (0)

Anonymous Coward | about 5 months ago | (#46683515)

The good-old days...
I remember, picking up card decks (when they weren't lost) only to discover many missing, torn or cards added in from some other deck.
And the joy of figuring out the puzzle to replace cards when multiple cards didn't have print on from because the card punchink ribbon was dry.
Let's not forget about print-outs.. sometimes when flipping pages, the ink went slowly from almost black to gray to light gray to blank sheets.
Was fun!

Not really all that important in the big picture (-1)

Anonymous Coward | about 5 months ago | (#46682537)

Contrast the importance of the mainframe to the importance of the iPhone and the Macbook. While a handful of mainframes are sold each year, TENS OF MILLIONS of iphones and macbooks are sold. Apple has FAR FAR FAR surpassed IBM in importance and brouight about the promise made in the 1984 ad of bringing uniqueness and self expression to the age of the PC. The mainframe is in reality long dead, long live Apple.

Re:Not really all that important in the big pictur (2)

WillAdams (45638) | about 5 months ago | (#46682645)

Because of course, no iPhone, MacBook or iPad ever connects to a website which has its database running on a mainframe.

The Night of the Living Mainframe (3, Insightful)

jabberw0k (62554) | about 5 months ago | (#46682675)

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).

Re:The Night of the Living Mainframe (2)

evilviper (135110) | about 5 months ago | (#46683323)

if you're running one the million- or billion-dollar companies [...] actually do anything, you're talking mainframes one way or another (call them a "cloud" if you must).

A cloud is usually a cluster a commodity computers, not a mainframe. A cluster can easily outperform a mainframe at lower cost, while having much higher reliability.

Certainly, the Fortune 1000 companies used-to run lots of mainframes, and they've got plenty running legacy apps, but today, they're just as interested in clusters of cheap PCs as the little guys. Google, Facebook, Amazon, et al, aren't interested in mainframes at all.

Re:The Night of the Living Mainframe (0)

Anonymous Coward | about 5 months ago | (#46684141)

if you're running one the million- or billion-dollar companies [...] actually do anything, you're talking mainframes one way or another (call them a "cloud" if you must).

A cloud is usually a cluster a commodity computers, not a mainframe. A cluster can easily outperform a mainframe at lower cost, while having much higher reliability.

Certainly, the Fortune 1000 companies used-to run lots of mainframes, and they've got plenty running legacy apps, but today, they're just as interested in clusters of cheap PCs as the little guys. Google, Facebook, Amazon, et al, aren't interested in mainframes at all.

That is the horsiest of shit stated by someone who clearly knows nothing about the nature of TCO or reliability. I work in a mixed Mainframe/Distributed environment. We in the mainframe team have maybe one hardware failure, resulting in 0 downtime, every two years. Generally it's on its way to being replaced before we notice and it has never effected performance. The guys running Linux on Intel boxes envy our performance and reliability plus the ease of disaster recovery is unknown to those relying on multiple physical boxes. You've imbibed the Intel Kool Aid I'm afraid, performance and reliability of System z far outweighs that of clustered consumer-grade hardware.

Re:Not really all that important in the big pictur (4, Informative)

L. J. Beauregard (111334) | about 5 months ago | (#46682841)

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.

IBM is now a business process company (-1)

Anonymous Coward | about 5 months ago | (#46682659)

I went to the IBM web site looking there latest desktop and laptaps and all they have now with used Lenevo available. They have "mainframe (blade boxes actually) but there main business with "business process services". Which is pure bullshit. My "company" (who works for a computer these days, I have work for a subcontractor?) is kicking out IBM out the door and GOOD RIDDANCE!!! I hope that NEVER after a part of life again!

Re:IBM is now a business process company (1)

PPH (736903) | about 5 months ago | (#46683435)

I threw an exception trying to parse that post.

Re:IBM is now a business process company (0)

Anonymous Coward | about 5 months ago | (#46683599)

Go home, you're drunk,

Invent? Nah. (0)

motorsabbath (243336) | about 5 months ago | (#46682785)

Too bad that IBM is long, long gone.

Still working on one... (1)

tekrat (242117) | about 5 months ago | (#46682871)

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.

Silly tekrat... (0)

Anonymous Coward | about 5 months ago | (#46684279)

Programmers cost money, they don't make it. Where did you get your MBA, anyway?

Good Mental Floss (5, Interesting)

worker17 (2525968) | about 5 months ago | (#46683119)

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.

Excellent point about a rich learning environment (0)

Anonymous Coward | about 5 months ago | (#46683659)

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

Re:Good Mental Floss (0)

Anonymous Coward | about 5 months ago | (#46683703)

I still have a book at my desk Programming the IBM 360 by Clarence B Germain (a copy is on ebay currently for 99 cents if interested), although when I started it was mostly using the successor 370 system. I will also never throw out my Principles of Operation manual!

I spent 20 years in the mainframe world and most of the last 20 outside of it. I still regard the Unix and Windows environments as amateurish compared to that of IBM mainframes, despite all of the obvious technical advances and advantages.

Long live the mainframe and praise the assembler.

And thou shalt ... (1)

Rambo Tribble (1273454) | about 5 months ago | (#46683667)

... revere the COBOL, for Holy is the COBOL. Thou shalt take no other language before it ...

Uphill both ways! (1)

Applehu Akbar (2968043) | about 5 months ago | (#46683867)

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.

repeated this strategy with IBM PC (1)

peter303 (12292) | about 5 months ago | (#46683993)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>