Yes, I know it’s Thursday as I write this.  However, this is ‘Patch Tuesday’ week – where all the monthly patches from a certain software vendor a little east of Seattle get pushed out and we have to apply them to all the servers at work.  It’s a lot of work, a lot of musical servers, and a lot of ‘hurry up and wait’.

It’s during those ‘wait’ moments that I find myself pondering things – and found myself going way back to some computers I saw a long time ago, in a data center far, far away…

A number of years ago – when the electrons in our computers were still young and frisky, I took a college class in data processing.  One of the things we did during that time was go to the Washington State Computing Center in Olympia to see how real data was processed in huge amounts.

I remember them showing us one of the first laser printers – and talking about how it could print 21,000 lines per minute.  It took many pages just to get it up to speed, and then it was like a very, very fast freight train… it would print statements, bills, invoices – whatever was needed – in astonishing amounts at blinding speed.  One of the things the operators had to be careful of was simply keeping enough paper in it.  Just like it took a while to get up to speed – it took a while to slow down, and running out of paper with this thing was a bad thing.

I remember walking past some of the computer terminals, which, at the time, looked like many other computer terminals – amber text on a black background.  They didn’t look much different than the Apple IIe’s we’d been programming on in class (other than the color of the type).

The keyboards back then were the ones that IBM made during the transition from manual typewriters to what we know now as a keyboard.  On these keyboards you had to push the keys pretty hard – and they’d click, both on the way down, and on the way up.

Typing on one of those keyboards was actually almost as loud as typing on a typewriter, and because you got two loud clicks for every keystroke, absolutely anyone sounded fast, even if they were typing with two fingers.

They took us to a room that was full of about 50 disk drives.

And I know, just know, there are some of you wondering how a room can be full of 50 disk drives.  Either the drives are really big, or the room is really small…

It was the first one.  The drives themselves – the motors – were in this casing a little bigger than a dorm room refrigerator – about waist high.  The disks themselves were stacks of disks in dark plastic housings – you could actually see the disks through that housing, and the disks were stacked 17 high inside it– and were about 18 inches in diameter.

There were, as I remember, three lights on each one – a green one, a white one, and a little red one.  The white one was lit constantly for power, and as I recall, the green one was – well, if it was green and on, it was a good thing, and as I recall, the little red one was when it was actually reading or writing.

We were told that you could store the name and address of every man, woman, and child in the state on one of them three times and still not run out of room.

It seemed like a lot at the time.

And then we went back to the terminals, and the person leading the tour showed us the power in those terminals.  She said there were about 500 of them around the state at the time – and when someone made a request on one of them, asking for an address, for example, the information would come through a dedicated telephone or telecom line to the data center we were in, it would hit the computer, which would look up the information on those drives we’d just seen, and then send the answer back to the person who’d made the original request.  You could actually see it sometimes, where this wave of little red lights flickered on for a split second as the request worked its way through the system.

Total time for this? – well, depending on the request, the answer could take anywhere from a couple of seconds to minutes.  Complex requests took longer, and you could tell when one of them came, in – a lot of red lights would go on – and it was almost like a little game of electronic volleyball as the information moved back and forth, until all the problems that question was supposed to answer were indeed answered, and then you could see the lights flicker again as the answer was sent out.

It was a pretty neat thing to watch.

And then the person leading the tour told us one thing that sounded so casual that we didn’t realize its importance until much later.  We walked back to the computers – at the time we didn’t know the difference between a computer and a terminal – and we were told that if the terminals weren’t hooked up or dialed into the mainframe we were looking at, then they were simply dumb terminals, that’s what she called them.  They only had the power that they had inside themselves, they didn’t have the power of this entire data center that was dedicated  to doing nothing but solving the problems these 500 terminals sent in all day, every day.

She told us about how, once a connection was made, it was better to keep the connection open than to close it and try to reopen.  If you did that – the terminal would have to resynchronize itself with the mainframe computer – and there’d be a lot of data moving back and forth just trying to do that, before you could actually get any work done.

The longer the terminal was off, the longer it took to get back in sync, so even in those days when time on telephone and data transmission lines was expensive, it was still cheaper to leave them on than to use the incredibly precious time on the mainframe computer just to get the terminals in sync – so the terminals were, for the most part left on, and connected to the mainframe.

Let’s move forward a few years.

I now work at a job where I spend my days with computers, irritating electrons all over the world, and once a month, we get what are called “patches” – little fixes to programs where – well, just think of patching a pair of jeans.  Either someone made a hole, found a hole, or wore a hole into the jeans, so you patch them.  Same thing with software, only instead of patching with needle the patching is done with herds of electrons, and they come from the company that created the software in the first place.

The patches can be pretty tricky sometimes, and it’s good to keep things maintained.

Every now and then something falls through the cracks, or a computer (we just call them boxes) either isn’t able or isn’t set to connect to the net to get all the patches, and then things get weird.

The software on the box, because it hasn’t been able to connect to its creator, has not been patched, and has weaknesses that other boxes don’t have.

The box is out of sync.

The box is no longer synchronized with its source, and the whole process involves the box checking in with the creator, the box and the creator finding out what’s wrong, and what’s right, and then fixing what’s wrong and affirming what’s right.

I talked to a friend about all this, and we came to the conclusion that this was a lot like any communication in any relationship.

Whether it’s a relationship between machines, or between people, or even if it’s a relationship between you and God, check in often.  Make sure you understand the other person, make sure you’re being understood.  Don’t assume that because you think everything’s hunky dory that it actually is.

At work, we had one box just like this – it had been up and running for 461 days without being patched.  While this is a testament to the way the box was built, and the software running on it, there was a problem. The box thought everything was hunky dory, but at the same time, the box was well over a year out of sync, and the time it took to patch that one server was absolutely agonizing.  I had to patch some, then reboot the box, and patch more, and reboot again for the better part of a day get the box back into sync, but it would be in fits and starts, and it would be very, very hard, sometimes tenuous where you weren’t sure if you’d be able to get the box back up again.  I ran into one box where I simply couldn’t patch it at all.  It’d been out of sync – or out of compliance for so long, that there simply wasn’t room on the box to do the patching without rebuilding the entire box.

That was rough.

It made me realize that even though it takes time, patching works much better when it’s done in little steps, and done consistently, and continually.  Conversely, the longer the space is between times that you communicate, the longer it takes to get back into sync, and sometimes that can be enormously challenging, whether that’s talking about servers at work, or relationships with people.

And that’s rougher.