Friday, January 5, 2018

Recession Was a Good Teacher

When I graduated from high school in Mission, BC, I decided that I wanted to go into Mining, so I enrolled in Mining Engineering Technology at BCIT, and moved to Vancouver, rooming with my brother.  Mining at BCIT had never, since BCIT had started, had a year where they did not place their students in summer jobs by the winter break, so the choice looked like a good one.  Unfortunately for me, the year I entered BCIT was the year a big recession hit the mining industry in BC.

Mining was the number 1 employer in BC, so this was likely to have ripple effects, and it did.  I lost the part-time job that helped me pay my bills to go to college, and then, as I started going into debt to get into an industry that suddenly had massive unemployment, I tore some ligaments and the cartilage in my left knee.

I dropped out of BCIT after one term, returned home, and as soon as my knee healed, I got work with some local loggers.  That's another story; one for my SoTotallyBC blog.

After bouncing around looking for work, I got some with my brother, helping him with computer software, as noted in the two previous blog posts. After the PBD job, Toga offered me full time employment, which I took.  They had me take an accounting course at BCIT, since I was generally helping customers with systems that did at least some accounting functions, or integrated with an accounting system.  And began to get pretty good at programming in BASIC or PROC.

But as the year moved on, the recession's ripple effects began to have an effect on the company. Work slowed down, and people began to come up with ways to fill their time.  One of those ways was to start assigning learning projects.

One group began to reverse-assemble the Reality operating system.  I would watch as they did this, and learned lots of interesting tricks. I also learned about how a virtual machine worked.  A system engineer from the hardware vendor accidentally left their firmware manual behind. By the time they came by and picked it up, it had apparently fallen into the photocopier.  This gave us even more insight into how the system worked. I was a complete sponge, and absolutely loved it!

At the suggestion of Antoon and Gary, I started working on a reverse compiler.  The DataBASIC implementation on Reality, and PickBASIC on almost every Pick system compiled into P/Code. This P/Code, referred to as object code, was then executed by an interpreter.  On Reality there was a compile option (M) that would create a variable map record along with the object record.  The Map record contained all the variables, which allowed the BASIC debugger to show you variable names and contents.  I started by compiling a couple of very simple programs and hex-dumping the object code record. It didn't take long for me to create a table that showed what the different P/Code instructions were.

Then I wrote the reverse compiler (in BASIC).  My reverse compiler would create a program that would recompile to identical object code, whether you had variables or not. If you had the variable map, you'd pretty well get your original program back.

There were two things I couldn't do for you:

First, if you had comments, I'd put the comment marker in, but the actual text of the comment would be gone.

Second, if you had a set of GOTO commands that mimicked an IF/THEN/ELSE structure, I'd give you an IF/THEN/ELSE.  I had been trained to use structured programming concepts, and to avoid GOTOs, so that was the obvious thing to do, but it was possible to use GOTOs in a manner that was indistinguishable from IF/THEN/ELSE. In a pinch you could also use GOTOs for loops and a few other constructs. I'd give you structured code, if in doubt!

The side effect of these two exercises is that I now understood what the operating system was doing, and I understood what a BASIC program actually did!

Some time after doing this, I was doing some work for a Toga customer called CJ Management.  While applying a change to one of their most heavily used data entry programs, I noticed some code that I knew was inefficient, and while in there, I replaced it with a more efficient approach.

The customer's key data entry people noticed the change right away, and I was asked to take a run through several other programs and apply some optimization!

While many of the systems I've worked on since then were quite different, I've always had this underlying need to understand, to the best of my ability, how the system worked, what made it efficient or inefficient.  This curiosity has been a key feature of my career, and has benefited both me and my customers!

I also had an understanding of how the security worked. This was before the internet and hackers, so people were not very security conscious!  I remember a financial institution I was working for, where the administrator lost the password for the SYSPROG account. This was the admin, or root account on a Reality system.  They asked me to get them in, which I did in minutes.  This knowledge started me on the way to having a consciousness about security!

Don't get me wrong, recessions are awful, but we made the most of it, and for me, it was a learning experience I would undoubtedly never have had if there had not been a recession!

Next blog: Paranoia is a Life Skill

1 comment:

  1. Fascinating. I remember when you took the accounting course at BCIT; you would talk formulas in your sleep. (in the days when I had to get up to go early to work)