Having dabbled for a few years in the fledgling micro-computer field, I decided to see if I could turn my knowledge into some sort of business, advising companies in ways to use these new micro systems to help with some basic business tasks. Of course this was very part-time, as I was working for Litton Systems those years.
Remember, there were no computer graphics yet… so I picked the name MicroDyamics, and created a logo using Lettraset (rub-on letters and lines). Then I printed a business card. I still have samples of the last two iterations of these cards: the first showing our Carling Avenue apartment address in Ottawa, then a second version at our York Hill Blvd. address in Thornhill (Toronto).
Although I did approach and speak to a few small businesses, I don’t believe anyone took me up on my suggestions. It was simply too early to turn this into a business. But I had fun creating the name and designing the logo. Years later I was approached by some firm in Vancouver asking permission to use the name MicroDynamics (which I had registered in Canada). Since I had no plans for it, I said OK. (The concept of selling URL’s — which didn’t exist yet — wasn’t applicable, and I didn’t ask for any compensation since they planned to use a different name if I said no.)
Small ad run in the Ottawa Journal December 28, 1979
After the collapse of the HP150 computer line, I decided to try my hand at consulting. At Litton Systems I had gained much expertise in UNIX and the Hewlett-Packard Unix (HP-UX) server line. I had also developed some good contacts at HP both from my software development venture and from dealing with the local HP sales reps for Litton.
I decided to recycle the (already-incorporated) Soft-Touch name as a consulting venture specializing in HP Unix systems. I initially got a couple of referrals from my HP sales rep, and slowly built up a few customer contracts. I don’t recall all of the company names, but Black & McDonald Electrical, and Four Seasons Hotels were two of them. There was also at least one real estate developer. I probably had only about 4-6 clients at its peak, before we decided to relocate to Chicago.
The way it worked was that I helped in some cases as these companies installed or switched to HP servers, and also was their “on-call” technical support if they had problems. I set up backup systems for them, and also helped them with communications and networking.
A very notable event was when I got a call from the head office of Four Seasons Hotels (in Toronto). They were opening their first hotel in Chicago, and their local IT guy was not too comfortable with the HP systems. An HP sales rep referred them to me. After meeting with them at the head office, they arranged to send me to Chicago to assist with configuring the system after the installation. Although it only required a couple of days onsite, I did get put up in a nice brand new Four Seasons hotel room! Afterwards I assisted the local staff by phone as required.
One of the difficulties of IRI’s data delivery to its customers was that many of the monthly files were very large. In those days most electronic transfers were slow and often unreliable, especially with very large files. So most of our deliveries were on tape cartridges, send to our customers.
Although this had been working for some years, it was fraught with problems. The tape creation process was finicky, and often had to be restarted. Sometimes delivered tapes couldn’t be read by the customer and we had to create a new set, resulting in an additional 2-day delivery delay.
In particular, we have very large monthly deliveries to our offices overseas — the U.K., Italy, France, etc. These had become especially problematic. No one understood why, but most of the time one or more tapes in a delivery set couldn’t be read. They suspected airport x-ray screenings, so they actually started having someone hand-carry them to Europe! However this didn’t solve the problem.
Much effort had been spent on the mainframe side (where the tapes were generated), yet they could not determine the cause of the problems. So they next tried using FTP to electronically move the files. However, in those days, FTP had file size restrictions, and it was also unreliable and non-recoverable — meaning that if the transfer failed 2 hours into a 3 hour transfer, it had to be started over from the beginning.
I was approached to see if I could help. After some thought, I proposed a software solution that I would engineer and program with the help of one of my staff. There was some skepticism (especially from the mainframe folks), but I was given the green light to try.
I had three main objectives: (1) Transfer any size file 100% reliably, (2) maintain security (data lines were not very secure, and much of the data was considered proprietary), and (3) engineer a solution that our client IT departments would be willing to install on their systems.
The third of those requirements steered me towards developing the entire system using only Unix scripting rather than any compiled language, and in a way that did not require special system privileges. As an IT manager, I knew that would be the only way to overcome any client objections.
I designed a system based loosely on package deliveries by the likes of FedEx. I defined each delivery as a package, with an accompanying manifest. Much like when you ship a lot of goods, you divide your shipment into smaller packages, my large files would be split into “chunks”, each of which would be sent separately, re-assembled at the receiving end based on the manifest. For reliability, if any “chunk” failed to deliver (verified by a mathematical checksum), the system would proceed with the other chunks and only later re-deliver those chunks that got missed. In that way, an unreliable line would never force a restart, simply require one or two small chunks of the delivery to be resent.
Obviously there was a lot more to this, but that’s the nutshell version. The EDT system (as I called it) became quite a success story. Clients were thrilled because it cut a day or more off their delivery times; the European offices saw a 4-5 day reduction. Even more importantly, once in place there were zero errors!
I’ve attached a number of email images, and a full slide show that I presented live to Frito-Lay in Plano, Texas.
After 911 (Sept 2001) many businesses suffered as the economy sank. IRI was already in some business trouble versus its competitors before that, but this made it much worse. Everyone could see that we were in for some significant layoff, although we didn’t know exactly when or how bad it might be.
In mid-2001 I was “offered” a different role in IRI — still a VP, but as an “Internal technical consultant.” There were two reasons for this — 1) The poor business results caused the board of directors to toss out some senior management (including the brilliant founder, Gian Fulgoni) and replace them with their old cronies. To some of these stodgy managers, I was a “threat” because I was outspoken and known to be very innovative. 2) Although never confirmed, I believe that they were preparing for the layoffs that they knew would be coming, and it would be easier to retain a lower-paid younger worker in charge of the Unix groups, and would be easier to “justify” laying off an older manager in a “consultant” role.
Be that as it may, I accepted the change, because it actually allowed me to do more of the sorts of things I was interested in. I spent more time expanding and enhancing the EDT product, and also took a lead role in charting a course for replacing IRI’s “Load balancer” — software to move batch jobs around to various servers to make best use of the total computing power. We had a legacy load balancer that was no longer supported and did a poor job. I was charged with finding a new product and working out the migration path. After sourcing the best product, I worked with the software vendor to make a number of changes that I was able to demonstrate would vastly improve their product, changes that they actually implemented.
Small anecdote: When we were still about two months away from making the load balancer move, we suddenly had a serious failure of the old existing product, and it was significantly hurting the business. Since a young guy was now in charge of the Unix systems, I left it to him to solve the problem. He poked around a bit and declared that it was not able to be fixed, and that we needed to move to the new system. Senior management asked me if we could switch, and I told them we were not ready to make that move yet, still waiting on some of the software vendor’s changes and full testing. So there was a meeting with the group president (the same one who did my second interview and hired me). At the meeting, when it was strongly stated that the current system couldn’t be fixed, he looked at me and asked me directly if I agreed with that opinion. I said I did not; it seemed to me that whatever the problem was could be discovered and corrected, allowing us the time to get the new system ready. My answer infuriated the new guys, but the president simply asked me “How long do you think it would take to get it fixed?” Not knowing anything about the problems, I replied “48 hours.” I remember there were chuckles and a few gasps — they had already been dealing with it for over a week. I simply trusted my diagnostic skills and felt that I could do it. They gave me the green light to take over, and I locked myself away in my office and started examining the system, logs, files… anything that might give me a clue. I got to a point where my intuition told me that there must be corruption in a certain key file, and further, that if I removed it, the software should re-build it. I had no proof of this, just a strong technical intuition. So I removed the file and fired up the system — and we were back in business. Total time: about 12 hours, much to the astonishment of many (and the chagrin of those who said it couldn’t be done.)
By January 2022 the company did its first massive round of layoffs — between 150-200 people, many middle managers. I was one of them. Over the next year, they laid off many more, and outsourced all the computer work to India. They then took the company private (had been traded), and within another year they were a shadow of what they had been. When I joined IRI they had about 55% of their market; that steadily dwindled staring in 2001, and today they are less that 15%.
I’ve attached a couple of documents just as an example of the complexity of the projects I was leading, and maybe to show off my communications skills (I was known at IRI to be excellent in both written and verbal presentation skills. Several times I addressed groups of 20-50 people to present and explain a new technology project… the teacher in me I guess.)
