z/OMG(qntm.org)
qntm.org
z/OMG
http://qntm.org/?zomg
33 comments
The same author wrote a really great piece on gay marriage from a database engineering perspective: http://qntm.org/?gay
He's also active on everything2.com, a Slashdot sister site from way back, as sam512. If you poke around on his site that's linked here, you'll also find some excellent science fiction and various other entertaining bits of writing, including that set of essays on how to destroy the Earth that I'm sure you've read at some point.
The author paints too grim a picture of mainframes. Isn't legacy code supposed to be that way? As far as I know, not many new code projects are being done on mainframes. But whatever is there, has to be maintained/upgraded. Mainframes are NOT as difficult to use as the author says. They power most of the big life/general insurance companies, and they do interface well with front-ends [with XSLs in middle to convert from/to string streams]. I have worked for two years on mainframes, and loved the simple editor. Like with any command-line type editor, it has its quirks, but once you learn it, it is very fast. Also, z/OS has some version control systems (Endevour), and really good debuggers.
Absolutely.
After all, you can happily run DB2 on Z/OS, and access everything via stored procs from smaller machines. his gives you external access to data without going through green screens.
After all, you can happily run DB2 on Z/OS, and access everything via stored procs from smaller machines. his gives you external access to data without going through green screens.
Some people still refuse to invest in DB2 though, and so you're stuck with VSAM/Flatfiles for your data. It's a horrible time sink.
This account right here makes me want to be a mainframe programmer for a living.
Writing software for microcomputers that sells is for chumps. Mainframes are where it's at, if for no other reason than the fact that "relabel[ing] one line of [a] procedure between one software version and the next will break somebody else's program."
Writing software for microcomputers that sells is for chumps. Mainframes are where it's at, if for no other reason than the fact that "relabel[ing] one line of [a] procedure between one software version and the next will break somebody else's program."
I get the impression that moving away from COBOL, "Big Iron", and such dinosaurs has, after the initial wrench, made companies more productive. All of which makes me wonder what part the army of salesmen that go with these things play in their continued existence. (And the executive-ego-stroke of having an impressive room dominated by a bond-villianesque monolith.)
In my experience, the reasons are mostly just because it's been the standard for so long at said shop.
Most people using mainframes don't make money off of their IT department, their programmers are expensive and don't produce profits. Investing in a large change from "what works and has a fixed cost" to something new and possibly troublesome or more expensive (initial cost) just isn't a priority for them.
Not to mention the retraining you'd have to do. A lot of these programmers are either old and unwilling to learn, or just uninterested in rocking the boat. So is it worth it to have to fire people or get subpar code, or just stick with what's working that keeps you generating a profit and keeps your current programmers job security?
Most people using mainframes don't make money off of their IT department, their programmers are expensive and don't produce profits. Investing in a large change from "what works and has a fixed cost" to something new and possibly troublesome or more expensive (initial cost) just isn't a priority for them.
Not to mention the retraining you'd have to do. A lot of these programmers are either old and unwilling to learn, or just uninterested in rocking the boat. So is it worth it to have to fire people or get subpar code, or just stick with what's working that keeps you generating a profit and keeps your current programmers job security?
I like this guy's witty banter, and his substitution of acronyms. But I particularly like this:
ICBM System z is the Stonehenge of computing platforms.
Looks like an over-sized gaming console to me -- like if someone created 10 times larger PS3 for a videogame store display.
A couple of years ago I spent just over a year working as a mainframe developer on a System/360 set of mainframes and the author's description of mainframe development seems accurate.
I grew very fond of JCL, EBCDIC and the text editor despite, or perhaps due to, their idiosyncrasies. Not that I would ever go back ;)
I grew very fond of JCL, EBCDIC and the text editor despite, or perhaps due to, their idiosyncrasies. Not that I would ever go back ;)
Reminds me of working on HP's MPE OS (I believe I was using an HP 3000) in COBOL to keep a couponing system up and running. I won't say it was a terrible experience, but I certainly wasn't a fan of MPE or COBOL by the time I left.
The thing that struck me about his awestruck description of the awfulness of System Z and its editor was "hey, that sounds a lot like vi".
I heart my graphical IDE.
I heart my graphical IDE.
Well they are graphical IDEs for mainframes. Java is also running very well on mainframes, as well as many web/appservers. This article makes a simplistic, though a bit funny image of the mainframe. Yes, the core and old stuff looks like that - no, there is also modern software running on the mainframe, else companies would stop investing in it.
Take a week to learn modal editing and you'll never go back.
I am a counterexample to your claim; hence, it is false.
I'm very fluent in vi(m), but I still end up going back to Emacs (well, MicroEmacs) every time for anything beyond doing hacks to configuration files. Why? I like having a heavily extensible development environment.
I also write Scheme, but that's another thing altogether.
I'm very fluent in vi(m), but I still end up going back to Emacs (well, MicroEmacs) every time for anything beyond doing hacks to configuration files. Why? I like having a heavily extensible development environment.
I also write Scheme, but that's another thing altogether.
It is a minor sadness that Bram didn't choose a lisp as the vim macro language.
But I still love vim...although Ive forgotten more bindings than other editors have features.
But I still love vim...although Ive forgotten more bindings than other editors have features.
I'm not actually all that certain I want Lisp as my extension language. Lisp is very, very nice, and while I may have a preference for it, someone else might not. FWIW, MicroEmacs uses an in-house extension language that, while really repulsive to look at at times, gets the job done.
That said, I also have a preference for Lua when it comes to more maintream languages, and to boot, there's a project called LuaJIT that performs just-in-time compilation of Lua to native code.
There's also MetaLua, which adds the feature of macros to the language.
Better still, there's lua-Coat, which is a port of a subset of Moose from Perl (which is, in turn, a port of CLOS and other things to Perl) to Lua.
Consider also just using Python or Io or any number of other languages.
I guess my point is that it really doesn't depend on the language. If the environment isn't going to be extensible within reason, I probably won't use it.
(Did you know that vim lacks the functionality to emulate Emacs' `create-frame`? That's a huge turn-off for me personally.)
That said, I also have a preference for Lua when it comes to more maintream languages, and to boot, there's a project called LuaJIT that performs just-in-time compilation of Lua to native code.
There's also MetaLua, which adds the feature of macros to the language.
Better still, there's lua-Coat, which is a port of a subset of Moose from Perl (which is, in turn, a port of CLOS and other things to Perl) to Lua.
Consider also just using Python or Io or any number of other languages.
I guess my point is that it really doesn't depend on the language. If the environment isn't going to be extensible within reason, I probably won't use it.
(Did you know that vim lacks the functionality to emulate Emacs' `create-frame`? That's a huge turn-off for me personally.)
I did for a year. I went back.
Running.
Running.
Heh. I'm about the opposite. Even when I have to work in an IDE (or pretty much anything that's not vim or a roguelike, for that matter), I become annoyed quite quickly that I can't navigate "properly" and how limited (in the case of many IDEs) or "backwards" (in the case of, e.g. emacs (I'm perfectly aware this is all entirely subjective, of course)) the editing capabilities are.
Choose your poison and all that.
Choose your poison and all that.
Editing isn't modal for everyone. I've used vi and Vim for years but I don't use them for more than a quick edit in a file these days.
Nice clean blog pages. I don't care as much for the home page, but the individual article pages are easy on the eyes.
What are these things used for? Why can't they ever go away? I don't really believe it...
They're used by people running massive systems that want all of their data to be accessible at incredibly high speeds.
We're talking about systems designed for throughput. For processing huge amounts of data in overnight batch processes. For five nines uptime. And for still being compatible with the code you wrote 30 years ago that still manages millions of customers.
We're talking about systems designed for throughput. For processing huge amounts of data in overnight batch processes. For five nines uptime. And for still being compatible with the code you wrote 30 years ago that still manages millions of customers.
Right, and incredibly high speeds is definitely accurate. I can't remember the amount of instructions/second our mainframe can handle, but I remember it being in the multiple hundreds of thousands.
Several hundred Kilohertz? :-)
It IS incredible - but modern Computers are even more incredible.
It IS incredible - but modern Computers are even more incredible.
How fast would one of those monsters be compared to, say, a modern day Mac Pro?
The actual CPUs are pretty impressive, and operate at 3-4.5GHz range. The system will have up to ~80 of these, so it would effectively blow away a Mac Pro. Let's be honest though, at the prices IBM fetches for these (millions for the top end), you could build a VERY healthy Hadoop cluster.
The reason why these are kept around is that the custom software that runs on them often implements very complex business rules that are otherwise undocumented (the code is the documentation). If you're talking about a financial institution, the mainframe IS the business.
As far as reliability, these things are rock-solid and proven, but mainstream distributed systems design has pretty recently surpassed the mainframe model IMHO. It's relatively simple (compared to just a few years ago) to implement clustered data processing using MapReduce, replicate the data across multiple datacenters, and not care about individual node failure.
The reason why these are kept around is that the custom software that runs on them often implements very complex business rules that are otherwise undocumented (the code is the documentation). If you're talking about a financial institution, the mainframe IS the business.
As far as reliability, these things are rock-solid and proven, but mainstream distributed systems design has pretty recently surpassed the mainframe model IMHO. It's relatively simple (compared to just a few years ago) to implement clustered data processing using MapReduce, replicate the data across multiple datacenters, and not care about individual node failure.
80 processors? Big potential for writing concurrent apps. Do mainframe developers exploit that?
When you consider that not only do these systems run a lot of batch processing daily, they also have user interfaces through things like CICS, which users are allowed to login and initiate jobs. Most of the time it has it's own form of concurrency in which it will lock certain datasets for processing and release them when it's done. Of course, it's still possible to get deadlocks and other issues because of this.
The architecture is very different.
You have every piece of I/O handled by its own subsystem; in the old days when they had lots of green screens they had FEPs, front end processors, that took care of all the busywork for displaying and accepting data - the main CPU never saw any of that. Same thing with networking, with disk I/O, you name it.
You have every piece of I/O handled by its own subsystem; in the old days when they had lots of green screens they had FEPs, front end processors, that took care of all the busywork for displaying and accepting data - the main CPU never saw any of that. Same thing with networking, with disk I/O, you name it.