

z/OMG - dmoney
http://qntm.org/?zomg

======
tsally
The same author wrote a really great piece on gay marriage from a database
engineering perspective: <http://qntm.org/?gay>

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

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

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

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

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

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

~~~
thismat
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?

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

You go to the wiki page and look at the picture of the system and think "I can
actually imagine a circle of these systems being set up and seeming very very
much like stonehenge".

~~~
83457
Looks like an over-sized gaming console to me -- like if someone created 10
times larger PS3 for a videogame store display.

------
baxter
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 ;)

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

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

~~~
DannoHung
Take a week to learn modal editing and you'll never go back.

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

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

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

------
rman666
Nice clean blog pages. I don't care as much for the home page, but the
individual article pages are easy on the eyes.

------
Tichy
What are these things used for? Why can't they ever go away? I don't really
believe it...

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

~~~
GeneralMaximus
How fast would one of those monsters be compared to, say, a modern day Mac
Pro?

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

~~~
GeneralMaximus
80 processors? Big potential for writing concurrent apps. Do mainframe
developers exploit that?

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

