Tales from Mainframe Modernization | Hacker News Reader

Tales from Mainframe Modernization

oppi.li

65 pointstodsacerdoti31 comments

This would be fun to work on.

But, as an over-30 on HN, I'd be afraid that having the word "mainframe" on my resume would alienate a 20-something co-founder or hiring manager. :)

OK, OK, I did once do a little bit of mainframe-related work. It was reverse-engineering a small part of a certain domain-specific mainframe network protocol, with the goal of replacing at least one of the companies' mainframes with... 21st century Linux servers running... Lisp. (IMHO, the HN karma should at least balance out there by using Lisp, like the post did by using Rust.)

Just say you worked on an on-prem private cloud.

With 99.99999% availability guaranteed

I’m mid 40s, had mainframe on my resume from probably 15 years in financial services (not the exciting, high paying kind either). I moved into tech in my mid 30s and am now in a fairly senior leadership role. But that person that gave me a shot in tech, at a YC company that pretty much everyone here has heard of, was in their 20s! I tell you this to encourage you to do interesting things, whatever you think those are. You wouldn’t want to work with a founder or manager who dismisses you because your keywords don’t overlap theirs. You want to work with the founder or manager who asks questions and wants to understand what you learned and how that experience helps you now.

Mainframes may not be what you’d work on at a startup today, but they’re complicated pieces of engineering, and writing software for them requires you to understand a lot about how they work. Updating or rewriting their software further requires you to understand how the people before you _thought_ they worked. That’s how I tell that story.

Interesting. Looks like everyone on HN is getting interesting jobs left and right.

The most compiler-ish work I ever worked on is a yaml to yaml transpiler. I mean, yeah...at least I got to write some recursions.

Writing a transpiler is easily the most boring and tedious job you can have, especially if the target or source language is useless (so you don't learn anything useful as a matter of course).

Unlambda is a thoroughly useless language, but writing a compiler from any sane language to Unlambda would teach you a lot, including some useful things.

I once briefly worked on a transpiler from Windows .BAT ("batch script", going back to DOS) to C#. The reason we wanted this is because some part of the Windows build system was a huge pile of .BAT files plus some PowerShell. The .BAT files were so unpleasant to work with, that we figured it would be good to at least translate them to a language that is easier to understand.

We didn't learn anything "useful" except we got to understand things like the bizarre FOR construct for the first time.

I'm sure Raymond Chen could write an airtight argument why the batch scripting language HAD TO BE exactly the way it is, and there was no alternative to iterating over files and lists using the FOR command with its bizarre flags, but once he leaves the room, I'll go back to insisting that this is one of the most screwed up things that have ever been done with software, and it's a travesty that this was still being used to run the Windows build system at Microsoft in 2013.

I'm surprised modern languages haven't gone farther with base 10 numbers. C# has decimal (not sure how widely used that is) but what other language has built-in, non-library base 10 numbers?

Python has decimals for example as do many other languages. C# decimal is used everywhere currency is used (I really hope). But apart from currency... why would you use base 10? We've got native bigints in lots of languages so you don't even have to care how they're represented internally.

Not all decimal numbers have finite binary representations. 0.3, for example, is 0.010011 with a repeating block of 0011. For some business applications, you know you're being given a base 10 decimal of finite (but possibly very large) length.

You can use an arbitrary length integer to store the number of cents? (Or whatever your smallest unit is.)

Many languages also have libraries (or standard libraries) for supporting arbitrary length and precision rational numbers.

Decimals are always represented in a way that preserves the exact value. That doesn't mean internally it needs to be stored in base10. There's lots of ways to achieve that.

I'm not quite sure why anyone would need a 'decimal' data type for currencies?

Couldn't you just express everything in eg cents, if you want that?

Otherwise, many languages also have libraries for working with exact rational numbers.

You're kind of asking why would anyone need decimal data, if they can implement their own decimal data with explicit decimal shifts around the codebase... The answer is - so they don't have to do it.

Some countries don't have cents, some countries have 3 digits of cents. So, yes you can but you also then get thinking you can express everything as ints. But, the moment you need to convert from KWD to VND (84000.00:1) you could be at the edge of the size of a 64 bit int. Note: VND is pretty stable, when currencies start deflating the numbers can get crazy.

Well, obviously you put the smallest unit in your integers.

Cents was just an example. Old British currency used to be even crazier than your example of a unit divided into 1,000.

> But, the moment you need to convert from KWD to VND (84000.00:1) you could be at the edge of the size of a 64 bit int.

So? You should use arbitrary length integers for that. Many languages have good support for them. Eg in Python they are the default integer you get.

The COBOL syntax for that looks like

    PICTURE IS $-999,999.99

which defines a signed money value represented in decimal. If you print that value, it will be formatted as requested.

There are a few other formatting characters. A "CR" at the end will cause negative numbers to be printed with "CR" (Credit) at the end. A "Z" causes lead zero suppression. "*" causes lead zeros to be replaced with asterisks, for check-writing. Numeric display formatting is an attribute of the data.

That concept, and built-in support of money-like values, has been lost in later languages. In Rust you can have implicit Display or Debug functions for types, although it's mostly used for debugging.

> Numeric display formatting is an attribute of the data

Mixing value and presentation wasn’t the brightest idea. In their defence, everything was new at the time, and everywhere they were breaking new ground.

> Mixing value and presentation wasn’t the brightest idea.

Spreadsheets still do that.

Not really. Cell formatting is a layer on top of the cell values.

Nice read but I don't get, and maybe someone here knows;

> 9(3) is shorthand for 999

I did some cobol work in the past and know 9(3) but you can write 999? And how is 4 chars shorthand for 3?

I think it's uniformity. You have 9(n) all over the place, and only pay attention to the number in parentheses. It's more error-prone to count repeating characters, and it's easier (to me) to notice a typo in the form 9(4) instead of 9(3) than 9999 instead of 999.

There are millions and millions of lines of old COBOL code. I’m surprised there isn’t a commercial “pluggable” transpiler product. Read in COBOL, output Java, Rust, Go… Many COBOL systems also have a lot of intelligence in the job stream order, and dependencies - so that needs to be converted too. This seems like a no-brainer to build a consulting practice and tools around. Oh, and the data has to be converted too.

That exists. There are multiple vendors that have solutions to automatically transform COBOL code.

Deloitte, for example, has quite a big practice around Mainframe modernization with a toolsuite https://www2.deloitte.com/us/en/pages/consulting/topics/appl...

And AWS bought a company with such a toolsuite and offers it now as a service https://aws.amazon.com/de/mainframe-modernization/capabiliti...

gnu-cobol is likely what you're after (cloudflare even used it to demo their Worker platform) but my experience has been that the language isn't the nonsense it's the environmental that's horrific to port

Consider a hypothetical Python example:

  import os
  os.system("DIRECTORY ./SHELVED_STATE")

if you ported the python to C# it wouldn't suddenly work on Windows or Linux

Mainframe OSs are fun to learn precisely because they are profoundly alien to users of modern computers. You don’t even need to go the mainframe route - installing OpenVMS on an x86 machine already gives you an environment full of mysteries to be explored.

Reply on news.ycombinator.com