kochbeck

It’s not that the mainframe is hard to learn. In fact, the environment is pretty easy to understand once you get past the archaic naming (but let’s not kid ourselves: on the POSIX side we’re still running t[ape]ar[chive] and other archaic tools too).

In a way, the ease IS the problem: the runtime environment for COBOL (and other stuff on the mainframe) assumes that the underlying platform and OS deal with the really hard stuff like HA and concurrent data access and resource cost management. Which, on the mainframe, they do.

Now, contrast that with doing the same thing in, say, a Linux container on AWS. From the stock OS, can you request a write that guarantees lockstep execution across multiple cores and cross-checks the result? No. Can you request multisite replication of the action and verified synchronous on-processor execution (not just disk replication) at both sites such that your active-active multisite instance is always in sync? No. Can you assume that anything written will also stream to tape / cold storage for an indelible audit record? No. Can you request additional resources from the hypervisor that cost more money from the application layer and signal the operator for expense approval? No. (Did I intentionally choose features that DHT technology could replace one day? Yes, I did, and thanks for noticing.)

On the mainframe, these aren’t just OS built-ins. They’re hardware built-ins. Competent operators know how to both set them up and maintain them such that application developers and users never even have to ask for them (ideally). Good shops even have all the runtime instrumentation out there too—no need for things like New Relic or ServiceNow. Does it cost omg so much money? Absolutely. Omg you could hire an army for what it costs. But it’s there and has already been working for decades.

God knows it’s not a panacea—if I never open another session of the 3270 emulator, it’ll be too soon. And a little piece of me died inside every time I got dropped to the CICS command line. And don’t even get me started on the EBCDIC codepage.

Folks are like, “But wait, I can do all of that in a POSIX environment with these modern tools. And UTF-8 too dude. Stop crying.” Yup, you sure can. I’ve done it too. But when we’re talking about AI lifting and shifting code from the mainframe to a POSIX environment, the 10% it can’t do for you is… all of that. It can’t make fundamental architectural decisions for you. Because AI doesn’t (yet) have a way to say, “This is good and that is bad.” It has no qualitative reasoning, nor anticipatory scenario analysis, nor decision making framework based on an existing environment. It’s still a ways away from even being able to say, “If I choose this architecture, it’ll blow the project budget.” And that’s a relatively easy, computable guardrail.

If you want to see a great example of someone who built a whole-body architectural replacement for a big piece of the mainframe, check out Fiserv’s Finxact platform. In this case, they replaced the functionality (but not the language) of the MUMPS runtime environment rather than COBOL, but the theory is the same. It took them 3 companies to get it right. More than $100mm in investment. But now it has all the fire-and-forget features that banks expect on the mainframe. Throw it a transaction entry, and It Just Works(tm).

And Finxact screams on AWS which is the real miracle because, if you’ve only ever worked on general-purpose commodity hardware like x86-based Linux machines, you have no clue how much faster purpose-built transaction processors can be.

You know that GPGPU thing you kids have been doing lately? Imagine you’d been working on that since the 1960s and the competing technology had access to all the advances you had but had zero obligation to service workloads other than the ones it was meant for. That’s the mainframe. You’re trying to compete with multiple generations of very carefully tuned muscle memory PLUS every other tech advancement that wasn’t mainframe-specific PLUS it can present modern OSes as a slice of itself to make the whole thing more approachable (like zLinux) PLUS just in case you get close to beating it, it has the financial resources of half the banks, brokerages, transportation companies, militaries, and governments in the world to finance it. Oh, and there’s a nearly-two century old company with a moral compass about 1% more wholesome than the Devil whose entire existence rests on keeping a mortal lock on this segment of systems and has received either first- or second-most patents every year of any company in the world for decades.

It’s possible to beat but harder than people make it out to be. It makes so many of the really hard architectural problems “easy” (for certain definitions of the word easy that do not disallow for “and after I spin up a new instance of my app, I want to drink poison on the front lawn of IBM HQ while blasting ‘This Will End in Tears’ because the operator console is telling me to buy more MIPs but my CIO is asking when we can migrate this 40-year old pile of COBOL and HLASM to the cloud”).

Mainframes aren’t that hard. Nearly everyone who reads HN would be more than smart enough to master the environment, including the ancient languages and all the whackado OS norms like simulating punchcard outputs. But they’re also smart enough to not want to. THAT is the problem that makes elimination of the mainframe intractable. The world needs this level of built-in capability, but you have to be a bit nuts to want to touch the problem.

I have been to this hill. I can tell you I am not signing up to die on it, no matter how valuable it would be if we took the hill.

I see a lot of “good” answers where good translates to reasonable business or social goals. But I can think of quite a few bad reasons.

The top reason is, management wants workers back in the office because managers never learned how to manage people, so they practice management-by-walking-around, aka interrupt-driven behavior. Many companies have a culture of MBWA, and it’s a hard curse to break.

Another bad reason is, distanced work has led to a substantial reduction in workplace unfairness behaviors such as sexual harassment and race-based favoritism. And this, logically, has made female and minority employees more valuable and better performers. But in many workplaces, favoritism is the order of the day, and women and minorities were not the favorites. The favorites are now performing worse than the people they stepped on to be unfairly promoted, and it makes incompetent executives look, well… incompetent.

Another reason is that many people, particularly executives, have more authority, respect, or control in the workplace than they do at home. For quite a few people, their office has become their primary social outlet. And taking that away has proven unlivable for them.

The other reason that immediately came to mind is that executives are, by and large, older than the rank and file, and they (we) come from a time when building, maintaining, and overseeing an office space was both a critical part of the job and a source of pride / ego. For older management, offices are still a real-world manifestation of the success of the company that signals to other people how effective the leadership of the company is. People are less able to derive the same sense of awe from abstractions like sales numbers. If people don’t return to the office, it will not continue to make economic sense to have flashy offices, and this ego outlet will disappear.

Are these good reasons? They are not. But these reasons, honestly, ring truer to me than “hallway collisions.” In the real world, all motivating reasons are self-centered reasons, and executives simply don’t benefit from hallway and breakroom magic or mentoring of the young. They do perversely benefit from showy offices, discrimination, avoiding overt displays of their lack of skill, and forced social conduct, though.

The author could not be more wrong.

Branches exist to handle and process A) cash demands, B) check and other non-specie instruments, and C) paper for commercial clients. If they’re a community or specialty bank, branches also exist to serve the particular, unusual needs of their community,—usually business needs. These special needs often include unusual skills such as assessing the quality of a crop or meeting with specialized experts.

That branches happen to also offer convenience to consumers is a happy accident, mostly, and it’s happier in that businesspeople are themselves consumers and often select their business bank based on where they personally bank. Branches are JUSTIFIED regulatorily by their public benefit which centers, in most cases, around consumer and SMB (which is to say, prosumer) access. But like many things, the regulatory rationale and the real purpose do not fully correspond. I’m sure you’re as shocked as I.

If branches were about sourcing consumer deposits, they would be uninsurable properties, because banks would burn their branches to the ground. Rest assured.

Source: I run banks.

Well… I read it. And I’ve gotta say, that sounds like a blatant violation of Regulation Y, the requirement that bank holding companies engage only in, “The business of banking.” There are lots and lots of activities that fall under that umbrella, but enterprise B2B software sales isn’t one of them.

CapOne may be too big to fail, but it’s not too big to receive a C

Oh wow, that made me feel old. I actually read that article just before making the switch from the Radio Shack TRS-80 ecosystem to Commodore. See the Tussey ad for a 64C with an FSD-2 floppy? I bought that package from them with a repackaged c.Itoh thermal printer. It actually had the mail-in redemption offer the Commodore guy referred to in the article.

It felt like I had that C64 forever. I learned CBM BASIC, 6502 assembler, and even K

Goodness, Rexx. I’m pretty sure I got the job at IBM when I was a kid because I already knew Rexx on the 390, ARexx on the Amiga, and the OS/2 version. I also knew HLASM and ia32 assembler, so I was instantly useful with no further training.

Thanks for the career Rexx!

During US v Microsoft, I was in the middle of writing a brief to the court arguing that the solution to Microsoft’s monopoly was not to split the OS from the application groups, but rather to disallow Microsoft from publishing its own compilers anymore. Because, you see, then they would be forced to have fully documented OS calling structures, because they would have to communicate them to the compiler vendors. In spite of their weakened state at the time, IBM would have gladly bought Microsoft’s dev tools groups, dooming them thoroughly as they attempted to merge them into the VisualAge group (née CSet).

I always believed the net effect of this would be that Microsoft would suddenly have to do an about face and support one of the OSS compiler chains, probably GCC. At the time, they had a current Mach-compiled version of Windows that was still being maintained, and odds are Windows—not MacOS—would have been the ascendant Mach-based OS, because MS would have lost a lot of its ability to fix its problems by losing control of its dev chain. They’d need more radical abstraction than the NT kernel was giving them at the time. Because it was still a branch from OS/2 1.2 which was… special and half-baked. (It’s important to remember that Linux was still considered a toy by most—the “serious” OSS OS was still BSD. And if you had real workloads you ran Solaris, even though you knew Sun was somehow going to doom themselves. The world then looks nothing like the world now.)

This really would have obviated the need for Apple to sell to Sun. Instead, MS would never have made the rescue investment, Sun would continue to skitter off the rails, and Apple would have sold to… I dunno, probably someone weird like Sony. Remember them? Because MS going to Mach would have poisoned the shift from Copeland to NeXTStep… the world barely wanted one Mach-based OS, much less two. One neat side effect, though, is we would have probably seen something a lot like WSL back in 2000 or so. Because the Mach Win build took much more advantage of the OS “personalities” features than MacOS did.

Back then, all of this mattered a lot, because things were far less elegant than they are now. It’s hard to imagine how far we came in the intervening 25 years. So very far.

But in the middle of writing that brief, Judge Jackson shot his stupid mouth off, and I was like, “Welp, nobody’s getting split up now.” And I put it in my archive of good ideas that aren’t gonna happen.

So no, I don’t think there was ever a real scenario where Sun bought Apple.

I still have a Model 100. It replaced the one I had in high school. It has, by far, the most comfortable keyboard I’ve ever used on a laptop. My typing speed on it approaches the speed I can reach on a Model M mechanical keyboard.

There’s still a very active community around the 100, and there are a few old hardware guys who still make new expansions for it. Recently there’s even a CP/M board for it which means it can run a lot of apps like WordStar, making it very useful day-to-day. It’s a nice, distraction-free environment.

I notice IBM was a major licensee. If you can figure out which product it was used in, the successor to that division (since I suspect it was something that’s now dead like PSP or mass storage) almost certainly has a clean copy of the source that’s been indexed on a mainframe tape wherever that program group’s library is now archived. It was a massive PITA to go on that sort of hunt when we HAD 3270s on our desks, so I can’t imagine what kind of untoward favors you’d have to offer IT to find it now. But unless decades of archival policies were rolled back, is there somewhere. Look for a product they sold to the federal government. They’re probably still supporting it.

Heh, yeah, as someone who still occasionally advocates for converting something back to batch, I know. Bear in mind, I'm typing this from an XOpen-certified UNIX machine, so obviously I wasn't a total rwars ideologue (religious OS wars for those too young to remember the term).

The main issue was job completion predictability - most things we do with computers are fundamentally batch, and almost all the really, really important ones like bank account daily settlement and reconciliation are totally batch. There's simply nothing to be done while you wait for the process to complete nor anything of higher priority that you'd want to preempt that task. So the question is, if the task is business-critical important or if it's critical to major institutions such as the global economy - like, say, the Depository Trust Corporation's nightly cross-trader settlement process which is, in fact, still a mainframe batch - why would you want the process to be anything other than a deterministic length of time for a fixed input? You'd be willing to commit a whole piece of hardware to getting the job done, right? As it turns out, that's the reason. There are an awful lot of things that are more important than economical full-utilization of a machine, and most of those tasks are still carried out on mainframes, and usually they're still done in batch.

There are a bunch of secondary reasons as well, though: a 3270 terminal ran in the thousands of dollars a unit in the 1980s; the network was really, really slow, and sharing the terminal server was worse than slow; if you were lucky(?) enough to have a token ring desktop and CM/2 on your machine so you didn't need a 5250 death-ray CRT next to you, you were unlucky enough to be on token ring and good luck with that; at 9am when the world woke up and logged in, the entire SYSPLEX ground to a halt waiting for all the interactive logins to complete, even though folks would then idle most of the day... on and on and on, and all of those were issues with time-sharing systems that, for most applications, worked just as well if you punched a record card (I know, right? Punch cards...), put it in a stack, and handed it off to the data processing department at 5pm.

If I still had $X billion in transactions to clear a day where X > a number that would get me jail time if I screwed up, I would probably still do it on a zSeries mainframe running CICS and IMS but running almost totally in batch. Because why chance it?

Meh, these guys got it blindingly wrong. But I suppose now that MIT TR picked it up, I have to write up a a response. Bother.

Umm... that was a pile of mediocre advice. They compared a bunch of plans to costs in San Francisco, but they overlooked the #1 most important thing: for persons with fairly low to zero income, San Francisco already has universal healthcare. For founders, the care is actually pretty good, and the premiums are very low for end-to-end primary, emergency, hospital and prescription coverage. I've used it. No major complaints.

The program is called Healthy SF. If you're presently living in SF and not covered, check the enrollment site and get registered right away.