My grandmother supposedly died in 2017.  Except she didn't.

One of her favorite restaurants was Piazza Roma on route 6 in Mohegan Lake.  She loved when we went there.

She wasn't happy when my aunt and uncle moved out of town in 2016 and were not up front with her about their intentions.  She was also not happy when my sister got married in 2017 and had the wedding out of town, with Grandma too frail to travel.

So it's pretty clear what happened.  Grandma didn't die.  She faked her own death and has been hiding at Roma's ever since.  She's 101 years old now and as far as I'm concerned she's still there.

A couple of months ago my father died at age 81 with mid to late stage Alzheimer's disease.  It is also very clear that, because of the Alzheimer's, he forgot that he was dead and went to go hang out with Grandma at the restaurant.

I'd like to go visit them both, but the restaurant isn't there anymore.

Let's talk 60 KHz.

As you may know, I have a lovely WWVB-synchronized clock that I built by hand about five years ago.  Here's a photo:

The firmware is my own code and once in a while I tweak it a bit to try to get a little better performance out of it.  The little module on the top left, just below the ferrite antenna, is a WWVB receiver module that pulls in the 60 KHz signal and outputs it on a single pin, as a high-or-low state.  The pulse train from this pin must then be decoded.  I think you can see that I used an Arduino Nano as the brains of the operation.  It then speaks to the display using I2C.

We had a brief power blip, just for a few seconds, on Monday morning.  Here on Wednesday evening it still hadn't picked up a full frame of time code.  There is no battery backed RTC on this thing, and no manual setting buttons (a deliberate design choice) so it's been sitting there with a blank screen for three days.  Not cool.  As I drifted off to sleep last night, I noticed that the time code pulses (the yellow LED) were totally readable by me just by looking at them, so why couldn't I train the software to be smarter?  What it needed was some hysteresis.  The original code read the receiver pin every loop cycle and considered high=1 and low=0, so if there was even the tiniest flickering of the signal in the middle of a pulse, it would throw the whole frame away.  I added some new code: now we take 100 samples (which still happens in less than 1 millisecond) and if at least 20% of those samples are high then we consider that a 1; fewer than 20% is a 0.  If that sounds like a ridiculously low threshold to you, I agree.  But I originally set it to 50% and it was still not enough.

The photo above was taken this evening, right after I brought the clock back into my bedroom after reprogramming it.  It locked on to the time signal in the very first minute and set the clock.

That's what the red LED on the bottom is, by the way.  I cut out the Nano's power LED.  The built-in LED on D11 illuminates when the software has detected the top-of-minute frame marker and is locked in and receiving time code.  If it receives any pulse length other than 200 (logical 0), 500 (logical 1), or 800 (marker bit) milliseconds, it assumes it's receiving junk and throws the frame away.  The red LED goes out and it waits for a new frame to begin.  If it completes the frame, however, it sets (or resets) the time, and illuminates the green LED.  When I see green, I know it has performed a complete synchronization within the last 24 hours.

It's got a few more tricks up its sleeve, however.

As previously noted, there's no battery backed RTC.  It's completely a free-running software clock timed by the 1 ms timer interrupt on the Arduino.  That means 60,000 timer ticks is one minute.  Or is it?  As it turns out, the accuracy of this timer is terrible.  One minute is somewhere around 60,000 ticks, give or take a few hundred.  So even if we didn't receive a full frame of time code, if we receive the start-of-minute marker we can do a couple of things:

1. We know the end of the marker is exactly 800 ms past the top of the minute.  So if the software clock reads anywhere between :45 and:15 seconds, we snap to :00.8

2. If we have two top-of-minute markers in a row, even if the time code in between was garbled, we now know the exact number of timer ticks that comprise a minute on this hardware.  So we save that number.  Up to ten of them, actually.  And we average those out, and that becomes our reference minute.

Bonusfest: there's also a cadmium cell detecting ambient light.  We crank up the display brightness when the room is bright, to avoid it washing out, and we dim the display in darkness, so it doesn't blasticate the room with display light while we're trying to sleep.

All in all it's been a ton of fun, and in addition to being a useful bedroom clock that never needs to be set manually, it also lets me geek out every night while I am drifting to sleep by watching das blinkenlichten.

Thirty years ago, I completed a college degree and joined the millions of people who discovered that a college degree is completely useless and I want my money back. But that's not what this blog post is about.

My alma mater ran just about everything on a Burroughs A-9 mainframe. Burroughs was later acquired by Sperry-Univac and at some point they upgraded to a Unisys A-12 mainframe. Whatever. Today, they are still keeping track of class enrollments, grades, tuition, housing, and all the other day-to-day minutiae using the same software, but on "Unisys ClearPath" -- which of course runs on bog-standard AMD64 hardware and emulates the old mainframe.

Unisys people have accepted this fate. IBM people have not. Because they are morons.

From a purely subjective level, you know a platform is dead when the information stupidhighway is saturated with articles written by people who insist that it is not dead. Oh, it's so MODERN now, they breathlessly chant to anyone who is willing to listen (which is nobody, so they then move on to bothering people who don't want to hear about it). It has files and pipes and internet and cloud and rainbows and unicorns and all sorts of modern wonders!

This is very true with regard to AIX (sorry, "IBM p") which is so dead that IBM has sacked all of their AIX developers in the United States and moved support-and-maintenance to an offshore sweatshop. But it's *extremely* true with regard to System/38, which eventually got renamed to "AS/400" and is now known as "IBM i" and runs on the same hardware as AIX, using the same CPU that Apple abandoned two generations ago.

There's a litmus test. Simply ask yourself, "Would I build a brand new (greenfield) workload on this platform?" And I'm not talking about some bank or insurance company that has a bunch of old AS/400 stuff already running and just needs to add one more task. If you're opening a new organization with a new IT department and all new software, are you going to build them on "IBM p" or "IBM i"? No, you would get fired for that, and you would deserve it.

Anything from IBM is, without question, a legacy platform. You might be supporting existing workloads for a few more decades, but as a go-forward play it's dead. It's technical debt. Call it what it is, and stop trying to pretend otherwise. You sound like an idiot.