Mainframe Programming to Make a Comeback? 262
ajw1976 writes to tell us that IBM has released a series of announcements today "introducing many new software tools, academic programs, and support for outside developers." The new releases are designed to help entice programmers and businesses back to the mainframe. From the article: "The announcements, according to analysts briefed on them in advance, signal a shift from defense to offense in the company's mainframe strategy. Last month, I.B.M. introduced a machine priced at $100,000, about half the previous starting price for its mainframes, which can run up to several million dollars. The announcement of the low-end mainframe was made in China, which I.B.M. regards as a promising market for the machines."
mainframes rock (Score:5, Insightful)
Cool, I can dust off my old bell bottom pants and platform shoes. I knew they would come back!
All seriousness aside, I started out coding for mainframes, mostly assembly. To this day some of the most screaming and cool programs I ever wrote were on mainframes (wrote (in assembly) an on-line trouble logging system to replace a paper system back in '76).
I did lots of COBOL programming and maintenance for a major, now absorbed by increasingly corrupt larger pseudo-telcos, telco. COBOL, not the most exciting language, but the throughput and data integrity of those days I've not seen matched since (and I still love Unix as my first choice for environment).
Which brings me (and us) to what I think works in favor of mainframes having a chance at a major comeback:
This is a partial list. I've long lusted for the raw power of mainframes with the standard support and the nimble Unix utilities.
Re:mainframes rock (Score:4, Insightful)
Does anyone know of any (non VENDOR) studies & comparisons vs traditional computer architectures?
Re:mainframes rock (Score:5, Insightful)
Although in the days of clusters, I don't know if mainframes can make it. Clusters have the same edge and much lower cost. I think we're more likely to see some of the OS advantages of mainframes get ported down.
Re:mainframes rock (Score:2)
Re:mainframes rock (Score:2)
Re:mainframes rock (Score:3, Interesting)
With an AS/400, you are talking about 2 hours of unscheduled downtime per year.
Windows computers win because they are cheap- not because they are fast or reliable.
Also mainframes are typically built to deal with phenominal amounts of data in ways that intel architecture PC's just can't handle.
Re:mainframes rock (Score:2)
Re:mainframes rock (Score:3, Informative)
Re: Running CPUs in pairs on mainframes (Score:4, Informative)
I worked with Stratus machines running a version of UNIX in the 1980s.
The machine could have up to eight or sixteen CP cards in it, I forget which.
Each CP card had four CPUs on it, running as a pair of pairs, with each outer pair running a separate path to redundant memory modules on other cards in the computer cabinet (powered by redundant power supplies, UPSes, disks, etc., with redundant paths between components, and everything constantly checking its counterpart).
All four CPUs would execute the same instruction, and each pair would compare the results, first with each other, and then with the other pair.
If a pair of CPUs didn't agree with each other, that pair would take itself off-line, and the other pair would write any (presumably correct) results to both memory modules, then the entire card would go offline, and the machine would run with reduced performance until a new CP card could be hot-swapped in.
(The machine would "phone home" whenever a part failed, and Stratus would ship a replacement part immediately.)
I don't remember what would happen if each CPU pair thought that it was right, but the two pairs disagreed with each other.
Space-time paradox, maybe.
At any rate, everything in the computer was pairs or pairs of pairs, executing in parallel, comparing results, etc.
It was advertised as a "never-fail" machine, that could survive the failure of any one component.
Sometimes a FedEx guy would show up at the door with a CP card, memory card, disk unit, or whatever, and that would be my first indication that something had failed.
I'd take the new part back to the machine, open the cabinet, pull the card or disk unit with the red light lit, and replace it with the new one.
A few seconds later, it would green-light, and the machine would be back up to full steam.
The only time that the whole thing failed is when we had an ice storm that knocked out power to the building for nearly a week, and the UPSes couldn't hold out that long.
So, to make a short story long and boring, yes, there are times when CPUs run in pairs.
Re:mainframes rock (Score:5, Insightful)
Mainframes are traditional computer architecture! Unix is 'new' compared to mainframe technology.
The modern mainframe is, in general, vastly more reliable than even the best of the best of 'big servers.' Mainframes are generally redundant to the point that you can change out thefr CPUs, memory, drives, etc. without turning the power off or rebooting the machine. Linux and Unix servers might boast about a couple of years of uptime, but many mainframe systems have been up for decades.
Many mainframe systems can process orders of magnitude more transactions than your typical *nix system running Oracle -- even when compared to systems with SMP, gigabytes of memory and the latest in high-speed storage. In fact, the stuff that people use nowadays for high-speed, high-reliability storage -- storage area networks (SANs) -- have their roots in mainframe technology. EMC, one of the market leaders in SANs was formerly part of Data General. In fact, so does most of the rest of your high availability 'enterprise-class' technologies -- SMP, NUMA, clustering, etc. Where do you think Linux's current SMP technologies came from? IBM. Who developed them on mainframes, ported them to AIX and then eventually ported them to Linux.
Massively-clustered systems like Google's are quickly become the norm for high-end stuff. But there are certain things that will probably always run on Big Iron. Whenever tasks are mission-critical and need to 24x7 and 'three 9's' doesn't even touch the tip of the iceberg in what you need in reliability -- you'll see mainframes running those tasks more often than not.
Re:mainframes rock (Score:4, Insightful)
Re:mainframes rock (Score:2)
Like graphics. Isn't this exactly what high-end graphics cards are high-end for? Just my ha'penny, I couldn't afford tuppence.
Re:mainframes rock (Score:3, Informative)
Re:mainframes rock (Score:4, Informative)
Same with the big Unix servers. Unix was considered "ready" for Big Iron usage once machines started shipping with crossbars (for hotplugging CPU boards) and redundnat everything. If you open a Sun E10000, you'll find that it looks a lot like a mainframe on the inside.
The modern mainframe is, in general, vastly more reliable than even the best of the best of 'big servers.'
Right up until Unisys invented "Clearpath" technology. Blech. Leave it to Unisys to take great tech halfway to nowhere.
Re:mainframes rock (Score:4, Interesting)
Yeah, I've seen 'em. Sun E10Ks are practically mainframes. And they cost about as much, too.
Of course, when it comes to raw transactional throughput, your average E10K running Solaris and Oracle just doesn't hold a candle to, say, an IBM z9 Enterprise Class running z/OS and DB2.
Re:mainframes rock (Score:2, Interesting)
Just FYI, the Sun E10K is an old system--it was released in 1997. I wouldn't expect it to hold a candle to a recent IBM enterprise machine (I assume an IBM z9 is pretty recent).
It's pretty interesting how Sun ended up delivering the E10K to market. Especially considering how SGI fared in the end. The San Diego based t
Re:mainframes rock (Score:2)
Some years ago, that is, when I was younger and stronger (and stupider). Maybe that explains the back problems I get now and again...
Anyways, if you really hauled that monstrosity across the building by hand... remind me to never piss you off in person.
Re:mainframes rock (Score:3, Informative)
Data General wasn't a Mainframe vendor. They produced Minicomputers, not mainframes.
Re:mainframes rock (Score:2)
My crystal ball says mainframes may come back, but not like that - not with assembler and COBOL on punchcards. My guess is you'll just log into a linux box (virtual box, that is) with all your famil
Yup, that's possible. Even so... (Score:2)
I'd love to be able to do that. Sadly, I suspect the licensing costs are far too expensive for my employer to seriously consider.
Re:mainframes rock (Score:2)
Java has been available on the mainframe in some form for
at least 6 years , C++ for at least 9 and pure C for at least 15.
You currently have two third generation Java VMs one which runs
in Unix System Services (basicly the mainframe pretends its a
POSIX comliant UNIX) and a whole separate one which runs inside
CICS ('cause CICS does its own thread and memory management).
Under the USS JVM you can run any standard Java or J2EE
application you just install the jar
Re:mainframes rock (Score:2)
All I know is this (Score:3, Insightful)
Re:All I know is this (Score:2)
Re:All I know is this (Score:4, Interesting)
Exactly - this is the wrong tool for the job. The hardware is fantastic - and yes, I've never seen a hardware problem, though crappy code (waves hand) can hork an instance. One of the machines I use is a eServer zSeries 900. Max of 16 CPU's, and this one has less than that - think it has 6, but not sure. Not that they would ever *allocate* all the MIPS my direction.
But lets say I had some stupid money. From the website, the latest greatest box...
If you need to crunch hard numbers - especially in parallel - there are much better options out there for the money. The folks a few miles down the road from me do a fantastic job with large Opteron clusters (waves to Malice). The mainframe is not the hardware you want when it comes to getting the math on.
IO and uptime... that is another story...
Not mainframes, SMP UNIX boxes (Score:2, Insightful)
Re:All I know is this (Score:2)
Super computer is not a mainframe.
Challenges (Score:4, Funny)
Plus, just imagine a Beowulf cluster of virtual servers!
Re:Challenges (Score:2)
Re:Challenges (Score:2)
Virtual Machines == running several machines on a single system.
Mainframe == single system with incredibly high data throughput, which can be partitioned into smaller systems (or virtual machines).
Re:Challenges (Score:2)
Limit the bleeding ... bah! (Score:3, Insightful)
It makes sense for IBM to make less expensive mainframes. The jobs will expand to fit the computers available. If you build it they will come, etc. etc.
I recently met another co-irker who used to program mini-computers. He said his students were calling him the old fart. I pointed out that he could be right up-to-date if he just prefaced all his comments with the word 'embedded'. There are modern chips that have exactly the same architecture and instruction set that the old minis he worked on had.
There is a market for what IBM is doing and it isn't going away any time soon. It will just be done on cheaper machines.
But how can anyone learn to use mainframes? (Score:4, Insightful)
So where are you young mainframe people learning how to use mainframes?
Re:But how can anyone learn to use mainframes? (Score:3, Funny)
Re:But how can anyone learn to use mainframes? (Score:2)
Re:But how can anyone learn to use mainframes? (Score:2)
Re:But how can anyone learn to use mainframes? (Score:2)
Besides, mainframe screens can get quite sophisticated. A UTS terminal can handle a lot of the field alignment, field protection, and alpha/numeric data enforcement locally without any interaction from the host, leaving the network bandwidth and server resources for more important things (like processing the actual data that you end up transmitting after you've done
Re:But how can anyone learn to use mainframes? (Score:3, Informative)
That's how people learn, especially in the trendy world of Comp-Sci.
Geek1: "Have you tried [insert language du jour, such as Ruby on Rails]"
Geek2: (12 hours later) "Check out my new ap; it's in [language du jour]"
Re:But how can anyone learn to use mainframes? (Score:2)
It would be a lot easier to learn programming on mainframes if companies started giving out ssh accounts to VM environments.
Re:But how can anyone learn to use mainframes? (Score:2)
Re:But how can anyone learn to use mainframes? (Score:3, Informative)
From the "old farts", as you put it.
We've got a large mainframe contingent where I work - there are lots of critical legacy apps that nobody wants to pay to build replacements to - and I doubt any of them are under 40. But man, they all know their stuff. You could easily bring in one of them to train people if you needed to.
I'm do not belong to the set of "mainframe people" per se however I do sometimes have to use the mainframe on my
Re:But how can anyone learn to use mainframes? (Score:3, Funny)
Re:But how can anyone learn to use mainframes? (Score:4, Informative)
I wish we could have more like him.
Mark Jacobs
Time Customer Service
Tampa, FL
Re:But how can anyone learn to use mainframes? (Score:2)
Re:But how can anyone learn to use mainframes? (Score:3, Informative)
Re:But how can anyone learn to use mainframes? (Score:2)
"Young mainframe people" (Score:2)
Of course, I owe my mainframe skills to the fact that I work for IBM.
Re:"Young mainframe people" (Score:2)
I have even read Z series manuals as end user.
The thing is, everyone interested in "huge power" stuff.
Funny is, there are some amazing "doom" errors in Z series, I can't imagine guys face if he reads them on an up and running 10 million $ mainframe.
All ends up saying "call IBM service", I add "and shoot yourself from head"
Beside jokes, of course it keeps running even after such error
Re:But how can anyone learn to use mainframes? (Score:2)
Re:But how can anyone learn to use mainframes? (Score:2)
The value of the mainframe is in the hardware... (Score:5, Informative)
The same is true of their memory subsystems, their disk subsystems, etc., though their backplane performance tends to be second to none. Mainframes are designed for throughput.
Mainframes are capable of staying operational for decades at a time. If you don't want your computer to ever go down and can afford the price, a mainframe is what you want.
One other nice benefit: they've had virtualization figured out on mainframes since the 1960s, so allocating resources is a relatively easy thing to do.
If you're interested in finding out what the older mainframe OSes were like, check out the Hercules IBM mainframe emulator here [conmicro.cx].
Re:The value of the mainframe is in the hardware.. (Score:3, Informative)
It is worth adding that this emulator lets you run 31 (not a typo) and 64-bit zSeries Linux distributions as well. Very cool stuff.
Cluster computing is better (Score:5, Interesting)
It turns out to be a lot like mainframe computing in terms of physical infrastructure and administration, and in fact often takes over disused mainframe computing centres, at least in the university space.
Unlike the mainframe environment, anyone with Unix/Linux experience is already equipped to take full advantage of cluster and grid computing. Either enviroment provides specialized resources that you have to learn how to access, but to me, the advantage goes to whichever environment provides the most universal expression of those resources, and is least likely to lock my efforts into one particular architecture.
A mainframe is an especially proprietary architecture. Portability has never been its strong point. Conversely, most cluster computations that I've seen have been quite trivially ported from one cluster environment to another. And to some degree it's in every vendor's interest to make it so.
The exceptions are interesting but, at this point, surprisingly rare. Relatively few researchers are decomposing problems in a way which requires either MPI or shared memory. Perhaps the field is not mature enough for that yet, much less for the sorts of computation envisioned by the Grid community, though that day will eventually arrive.
What I mean is, the biggest market for massive computation is always going to be driven by ordinary computation which happens to operate at a massive scale. And for that, the plainer, more symmetric, and more standardized the architecture, the better, because development and testing costs are not going to go down in the face of massive computing resources, they're going to go up.
The perfect mainframe, in other words, is one node in a Beowulf cluster. And that's fine. Just don't go running MQ Series on it, okay?
Re:Cluster computing is better (Score:5, Informative)
Actually, no. The IBM 370 architecture is open, as a result of an antitrust decree decades ago. There are plug-compatible peripherals and software-compatible CPUs. There's even a good emulator for PCs. It's actually more open that x86 or PowerPC.
Re:Cluster computing is better (Score:2)
http://www.power.org/ [power.org]
Re:Cluster computing is better (Score:5, Insightful)
They compete with supercomputers, not mainframes.
A lot of people confuse the two, but they're very different sorts of machines designed for very different purposes, with very different characteristics.
Supercomputers are great for intensive calculations. When you have a relatively small dataset and a very long string of operations to be performed on that dataset, you want a supercomputer.
A subset of supercomputer tasks are easily parallelised, and on that subset, in particular, a cluster can really rock.
But the weakness of clusters has always been in throughput - their ability to move large amounts of data around is rather weak.
Mainframes aren't great at intensive calculation, they don't compete with supercomputers, what they're designed for and great at (besides incredible reliability) is throughput. Those suckers can move enormous quantities of data around very very quickly.
Want to calculate more digits to pi? Break an encryption key? That's a supercomputer job, and a cluster can probably handle it fairly well.
Want to search a database that contains every transaction your company has ever had, with any customer or supplier, globally, for the past fifty years? That's a mainframe job. And neither a supercomputer nor a cluster is going to get close to a mainframe at doing it. All those hot little cpus will sit mostly idle while waiting for all the data to trickle in through a relatively narrow set of connections, while on the mainframe, all those (relatively slow) CPUs are being kept busy by a massive array of hard drives on an interface with more bandwidth to memory than most of us can even imagine.
Apples and oranges.
Re:Cluster computing is better (Score:3, Insightful)
I suspect you don't know what large means. 300,000 tapes. 2,048 drives. The complexity on mainframes isn't computation, it's data management. Trust me, it's a completely different world, with (solved) problems that simply do not appear in any but the largest enterprises. Those are the 400GB carts, btw.
Here's a pretty good analogy I just made up: think of how inappropriate FFT multiplication would be for most arithmetic, and how inade
Re:Cluster computing is better (Score:2)
Not to detract from your argument, but actually, it would.
WestGrid, for example, where I used to work, has a storage cluster with a HFS which I recall supported 30 TB on disk and 200TB on tape. That was a couple of years ago, and it may have been augmented since then, given the amount of data from CERN that we expected to process. A lot of research infrastructure funding is going in this direction, because what makes these facilities
Re:Cluster computing is better (Score:2)
Starfish, 300,000 400GB tapes hold 117185.5 terabytes. WestGrid fits in about 0.2% of that. And the notion of staging terabyte datasets to disk is ... umm.
Look, the simple fact is you just looked right at 114 petabytes didn't recognize them, and
Not to detract from your argument,
... but actually, that system you used hasn't got a clue.
Re:Cluster computing is better (Score:2)
You should have stopped there.
Or, even better, googled "SL8500" and checked the [storagetek.com] datasheets [storagetek.com]. IBM specs the z9 [ibm.com] at over 1Tb/s. You think customers who'll pay for that are going to let the library use 2,048 tape drives to play keepaway with their petabytes?
Re:Cluster computing is better (Score:2)
I've been doing mainframe C++ programming (Score:4, Funny)
For the past year or so. The environment has potential. But the CPU speed is horribly slow. I would have really loved a cross compiler that could offload CPU intensive C++ compilation off onto some other box that wasn't so CPU limited.
It's really interesting the things that take no time at all on the mainframe (grepping the source tree) and the things that take forever (compiling it). It's an odd architecture. There are definitely things you should not use it for, but it would likely make an excellent web server.
Re:I've been doing mainframe C++ programming (Score:2)
What makes a mainframe a mainframe? (Score:5, Insightful)
I've always believed that mainframes have their place in the world, even when the world was announcing the era of the personal computers and the death of mainframes. But while I understood them to be highly specialized high-throughput high-reliability machines, I never had a personal experience with a mainframe operating environment. So I never truly understood what a mainframe is...
I've worked on (relatively) bigger Unix systems (8 processor SPARCservers, 4-rack Sequent NUMA-Q's, and others), but at the end of the day, they seemed no different from a single desktop Unix machine -- just faster and with more memory and storage. I've also used a VAX, briefly, during my freshman year in college. I've always imagined that VMS was closest to what a mainframe environment must be like.
So, to the folks that understand the mainframe -- what is it about them that makes them more than just faster versions of desktop machines, or even server systems that us non-mainframes are used to?
Re:What makes a mainframe a mainframe? (Score:5, Informative)
This beast can be physically partitioned into multiple domains. One OS runs on each domain. CPU/Memory boards and I/O boats can be dynamically moved from one domain to another. You can run Solaris 8 in one domain, Solaris10 in another, Linux in a third, and um...*BSD in a fourth. Any of them runs independently of the others. If a board dies, you can deallocate it from a domain, swap it out, and add it back in--all live.
Now multiply that by a LARGE number, add crazy amounts of fault tolerance, and you're getting into the world of mainframes.
Re:What makes a mainframe a mainframe? (Score:4, Informative)
It's not the fastest thing in the world, but would you want to haul a load of water main pipes with a Porche?
background.. I'm a mainframe systems programmer..
There are two major aspects of a mainframe. One is the physical hardware (and software), on how it is designed and the other how they are used. The hardware is designed from the ground up to be robust and redundant. Yes it costs thousands (millions?) of dollars for a mainframe system, but with that you get the assurance that the system *WILL NOT CRASH* when an error happens. Instead the system will perform a self diagnosis, make an automated phonecall back to support. Support will send out an engineer (CE) with the replacement parts, which will be replaced while the system is still running (note that there are some (very few) instances where the repair does require downtime to actually perform the repair).
A few years ago, one of our CE's informed me that one of our mainframes had called home with a CPU failure. I asked if he would need to schedule some downtime to replace the card(s). He said ".. No.. we would have to lose 5 more before they would get worried.." Now.. from my viewpoint, I did not see any error, I still see the same number of "Processors" as I did before. What happens is that the system has a bunch of spare CPUs that are kept online. Instructions are run in parallel across multiple CPUs and then the results are checked. If there is a failure (as in the results don't all agree) the system will determine which CPU "failed", perform a diagnosis on that CPU and if it's determined that there is a problem will fence the failed CPU off from use. Note that this is all done under the covers from the operating systems. There is nothing that I need to do to enable or disable this.
Mainframe operating systems behave very differently then the Windows/Unix world. -- Lets take a simple example. An application allocating memory. Under Windows/Unix what happens if the memory allocation fails? -- Answer, the program is handed back control with the hopes that it will test the returned value. On a mainframe by default if there is a memory allocation error, the application will be "abended". Now the program *can* request that if there is an error to allow it to continue by explicitly stating that it will handle the error. This concept is carried throughout the system API. By default the application will be halted if there is an error. Under Windows/Unix the default is to simply return some error flag and hope that the application will handle it.
The way mainframes are used and maintained is a little different. Things are usually not done on a whim. This really isn't due to anything physically different on a mainframe, but more of the "culture". Yes these are big expensive boxes, therefore the company that owns (rents) them wants to make sure they are maintained and running efficently. When changes are made, they are researched and documented with fallback plans. When even minutes of downtime could mean millions of dollars lost, it's well worth the investment in time to make sure that a change is correct. Going back to the 18-wheeler analogy, I suspect that when it's time to do a scheduled maintenance on the tractor there is a lot more testing/verification then you would have done on your family car.
Mod Parent Up. (Score:2)
I do not have any mod points now, but I really hope someone mods this as Informative.
It is certainly more useful than the 'mainframes are awesome' vs 'cluster are th3 rock' posts that pop up all over the place.
Re:What makes a mainframe a mainframe? (Score:2)
Funny is everyone seem to prefer OS X and Windows to access mainframe.
I know a mainframe coder which I have showed him how to defrag a windows disk
Re:What makes a mainframe a mainframe? (Score:2)
Mainframes (old ones and new ones with legacy data requirements) still do (but don't have to)
MF + Linux (Score:4, Informative)
Perhaps most interesting to this community is that Linux on the mainframe solves a major problem that all large institutions are dealing with: Power. Power density and consumption for intel/amd boxes is through the roof and is breaking most data centers. Exponential growth is not an understatement. Mainframes however, remain very predictable with a fairly flat and linear power curve. Porting quantitative trading and analysis applications to the mainframe would solve this problems and literally save 100's of millions of dollars.
Re:MF + Linux (Score:2)
So the whole porting issue depends on whether the application is data throughput bound, or CPU bound.
I'll be brushing up on my APL (Score:4, Funny)
Algol
Ada
They never went out of style ... (Score:2, Interesting)
Mainframes are industrial strength. Full stop.
Gibsons (Score:3, Funny)
Re:Gibsons (Score:3, Funny)
Re:Gibsons (Score:2)
password: GOD
becomes
password: G0d
Much gooder!
Forget z/OS, try Linux under z/VM (Score:5, Informative)
Mainframes are Obsolete - The Law speaks (Score:2, Informative)
Obligatory (Score:3, Funny)
Re:Obligatory (Score:2)
I'm surprised one aspect hasn't caught on... (Score:2)
It may not be every application, but I know that IBM's MQSeries product (now called WebsphereMQ, I believe) had a per-cycle cost on big iron (on top of some huge monthly maintenance fee). I know this because I wrote some middlew
Re:I'm surprised one aspect hasn't caught on... (Score:2)
Mainframes were deterministic (Score:3, Interesting)
IBM allowed fine-grained control of CPU time, IO bandwidth, RAM, and disk storage. And this control was not a weighted-selection algorithm, it was WYSIWYG deteministic control.
In mainframe shops, there were well defined workloads, often represented by a batch of transactions needing to be run against a database. These "batch jobs" would run on predictable intervals, daily, weekly, monthly. They could be scheduled to run at fixed times for known durations.
This made the whole mainframe environment very easy to manage. Instead of having to guesstimate workloads, and install CPU and I/O capacity to match unexpected peak demands ruled by chaos theory, mainframes were safe and predictable. The need for CPU MIPS and RAM was clearly visible and easily monitored and planned.
So when people say that mainframes were "more reliable", they don't just mean the MTBF numbers of the hardware.
They mean that when you ran work on a mainframe, you knew exactly what programs were using what resources at what times. And when something screwed up, you could very simply back up to the previous version of the affected files and re-run the batch job.
Life with mainframes was safe, logical, and predictable.
Introducing some of that into UNIX or Linux would not be a bad thing. Not every problem has to run in real-time with dynamic adjustment of resources. Deterministic, static allocations of memory, CPU, and I/O can work very well for predicatable workloads.
Linux needs a good Batch Spooling manager system.
Re:Wow! (Score:3, Interesting)
Probably not a whole lot.
High performance computing is not a Mainframe's purpose. A typical personal computer is going to have a much more powerfull proccessor then what you'd find in your average mainframe.. Of course if you have a few million dollars laying around you can find all sorts of stuff that is blazing fast.
The thing that Mainframes are good at are I/O. That is sorting and managing massive amounts of information. You'll have transactions
Re:Wow! (Score:2)
Re:IBM and human rights (Score:2)
If they were aware of what their products were being used for and could have stopped their supply, then yes. The only difference is that I suspect the holocaust would not have ground to a halt for lack of paperclips, so their non co-operation would have been nothing more than symbolic, whereas IBM's (or more precisely Dehomag's -
Re: Mainframe Programming to Make a Comeback? (Score:2)
This simply shows your ignorance. Over fifteen years ago we quit using 3270's. XEdit? Before that.
Re: Mainframe Programming to Make a Comeback? (Score:2)
Re: Mainframe Programming to Make a Comeback? (Score:2)
It goes like this
emacs notepad xedit jedit vim Kate ISPF Edit
Truly, the rest of the world needs to have a line editor with proper macro support embedded into whatever language you want (which is always Rexx, but C should work).
Re: Mainframe Programming to Make a Comeback? (Score:2)
It's an XEDIT clone for *nix -- uses rexx, etc.
Re: Mainframe Programming to Make a Comeback? (Score:2)
--As long as they dump TSO like a bad habit, and implement VM/CMS with decent REXX throughput, I'd do it...
Re: Mainframe Programming to Make a Comeback? (Score:2)
Come to Ireland, get a contract working for government.
I had fun working on VAX and Alpha Minicomputers - VMS has an actual interface you can use to, you know, run programs. The people there knew their stuff. All was good. Even the fact that most of my work involved COBOL didn't phase me too much. Then...
I was moved to another department with OS/390 - f
Re:Gee, at only 100k (Score:2)
Re:Gee, at only 100k (Score:2)
Re:Gee, at only 100k (Score:2)
Re:Whoot (Score:4, Funny)
Re:Whoot (Score:3, Insightful)
If your going to do the joke, at least do it correctly, with valid syntax.
ADD 1 TO COBOL GIVING COBOLRe:STop H1Bs!!!! (Score:2)
Re:"Mainframe" is a class of computing. (Score:2)
If you have a problem- just throw the transaction then the customer can just start over and reorder the item again. The problem being that my companies transactions can have 700 items on them and the bloody web programmers were just throwing them away left and right as a way of handling errors. (there were similar issues with data entry- the web server wants to time out if the person takes more than 30 minutes to update a screen.)
Re:No more downtime! (Score:2)
Likewise true.