Skip to content

Category: Uncategorized

It’s been 30 years!

January 1st, 1989 was my first day at work for my first job in IT.

You would think that everything was completely different 30 years ago. The advance in sheer computing power and the evolution of languages and frameworks had me think for a bit that this is the case as well. But actually, the difference is not that big!

A “Point 4 – Mark 12”, this doesn’t exist anymore.
Those keys are not for opening the front, they could litteraly be used to start and stop the thing.

My work consisted of operating one of these things in the picture above, they were called “Mini computers”, sized like a fridge, so not really what we consider “mini” these days.

What was different in those days?

So, this really happened. Debugging in the early 90’s:
Client calls because he has an error on his screen: “I have a stop at 5654”
I would walk to a closet and get the printed source code of the customer so I can look at the line number he just gave me to see what that line of code does!
Turns out, he was printing invoices and that specific line of code would get a customers information from the system. But unfortunately he deleted that customer that morning while still having sold goods in the system that were not invoiced yet.
The client would now have to go a different terminal to re-enter the customer into the system with the same number. After that he would then change a few lines of code in such a way that processing the invoices would restart but only actually start printing at the exact line where it broke. (and the client would have to move the printer back exactly 3-clicks to printing would start at the right place)

A Line Printer, a box of paper would go in the front and invoices would come out the back. We had 3 of these, filling the room with a constant rattling noise. Think “matrix” but a whole line in one go.

The client would run the program (without saving the code ofcourse) and then we would wait until we would hear the printer. I asked the client if he could check if it started printing at the right place with the right data but he wouldn’t hear that anymore, having already dropped the phone to quickly run to the printer to see if all was ok.

If you were at all impressed with me using printed source code, never mind that, check out this amazing woman. Margaret Hamilton is standing next to a the code of Nasa’s Apollo project she and here colleagues created a whopping 20 years before my first day at work. We have her to thank for naming our work “Software Engineering”.

What was similar to today?

The software was written in something called Business Basic. This was old-school stuff with line numbers. Every program that could print something would have a “Printer Choice” menu. The code for this was never exactly the same and always in a different part of the software. At some point that printer choice had to be changed (because we got a new printer!). I decided to create a single set of code to be used as the standard printer choice code for all programs. I picked a set of line numbers that was not in use in any program and loaded it into everything after thouroughly testing it.
Today re-using code by creating modules, functions or whatever your language of choice supports is a common thing.

and

A specific program was slow and would be in the way of daily work, we couldn’t start it earlier because the data would not have arrived yet. I discovered that finding data took too long. So I created an extra dataset containing only the account number we needed to have and the data we used to look for the account number. Searching through this much smaller dataset was way quicker than using the main dataset. After that we still had to go to the main dataset to get the rest of the information, but now we had the key already, so this could be a direct lookup.
Database people will immediately recognize the “non-clustered index” I made to get rid of the “table scan”. (I’m putting the terms in quotes because you couldn’t call it a database what we were using)

Am I trying to say that I was born ready as a database tuner? far from it! I’m only saying that there’s no magic involved in what we all do. Things haven’t changed much, not really. Common sense and experience are good skills to have!

The most important thing that hasn’t changed at all though is that people keep telling me that in a few years our work will be fully automated and we would be out of a job. I have never been busier! As long as we keep learning, keep investing in our (soft) skills, we will have no problem to stay ahead and stay relevant and busy!

Leave a Comment

A fun way to learn about Database Corruption

corruptionchallengeshirt-300x336For 10 weeks in a row now I’ve been participating in Steve Stedman’s “Database Corruption Challenge”.

I’ve learned a ton of stuff and I was able to add some new scripts to my toolbelt because I needed them to solve the challenges.

In the coming months I will be blogging about some of the interesting things I learned, I can’t do that just yet right now because the final weeks is still running. I look forward to meet Steve in Seattle, where I’ll hopefully get a t-shirt for ending in the top 10.
(Which depends on my final submission which is underway as I write this).

Congratulations to my fellow participants, there are just a few who have been able to solve all of them.
And of course congrats to Rob Farley for winning!

Interested in trying this out yourself? The weekly challenge may be over but they are all still available for you to try out, here is the link: http://stevestedman.com/server-health/database-corruption-challenge/

Leave a Comment