🔥 The DB Grill 🔥

Alright, one of the junior devs, bless his heart, sent me this... blog post. Said it was a "deep dive" into how computers work. I’ve seen deeper dives in the office coffee pot. He's reading a book called "Three Easy Pieces," which is your first red flag. Nothing in this business is easy, kid. Not when you've had to restore a corrupted VSAM file from a tape backup that's been sitting in a warehouse in Poughkeepsie for five years. But fine, let's see what "brilliance" the youth have discovered this week.

It's cute, watching them discover the "process" like it's some lost city of gold. They draw their little diagrams of the stack and the heap and talk about it with such reverence. "A living process in memory," they call it, quoting some sci-fi nonsense about "hydration." Give me a break. Back in my day, we didn't have fancy "hydration." We had the WORKING-STORAGE SECTION in COBOL and a fixed memory partition on the System/370. You got what you were allocated, and if your batch job overran it, you didn't get a polite "segmentation fault." You got a binder full of hexadecimal core dump printouts on green bar paper, and you liked it. This whole "stack vs. heap" debate feels like two toddlers arguing over building blocks when I was building skyscrapers with JCL.

And the hero worship over this fork() and exec() song and dance is just baffling. The blog author breathlessly calls this two-step process "unmatched" and the "gold standard." Are you kidding me? You're telling me the peak of operating system design is to create an entire, exact clone of a running program—memory, file handles, the works—only to immediately throw it all away to load a different program? That’s not brilliant design; that’s like buying a brand-new car just to use its radio. We called that 'wasteful' in the 80s. A simple SUBMIT command in JCL did the same thing without all the theatrics, and it was a hell of a lot more efficient. DB2 didn't have to copy itself every time it spawned a utility process.

Then they act like I/O redirection is some kind of dark magic.

The 'wc' program writes to standard output as usual, unaware that its output is now going to a file instead of the screen.

Unaware? It’s not sentient, kid, it’s a program. And this "magic" is something we perfected decades ago. Ever hear of a JCL DD statement? //SYSOUT DD DSN=... We could route anything to anywhere—a dataset, a printer, a different terminal, a tape drive. It was explicit, powerful, and declared right up front in the job card. We didn't rely on this shell game of closing and reopening file descriptors, hoping the OS gives you the right number. You kids reinvented the Data Definition statement, made it more fragile, and are now patting yourselves on the back for its "simplicity."

I had to chuckle when he mentioned the author's nostalgia for Turbo Pascal in the 1990s. The 90s? That was practically yesterday! That was the era of GUI nonsense and client-server fluff. We were debugging CICS transactions with command-line debuggers on 3270 green-screen terminals while he was watching a call stack in a cozy IDE. The fact that he thinks the 90s are "30 years ago" ancient history tells you everything you need to know.

And the best part, the absolute kicker, is the final paragraph. After pages of praising this design as a work of timeless genius from the "UNIX gods," he mentions a paper from 2019 that calls fork() a "clever hack" that has become a "liability." Finally! The children are learning. It only took them fifty-five years to catch up to what any mainframe guy could have told you in 1985 over a cup of lukewarm Sanka. It is a hack. It was always a hack.

Mark my words, this whole house of cards built on "simple" and "elegant" hacks is going to come tumbling down. One day soon, all this distributed, containerized, forked-and-exec'd nonsense will collapse under its own complexity. And when it does, you'll all come crawling back to the rock-solid, transactional integrity of a real database on a real machine. I'll be waiting. I’ve still got the manuals.