I.T. Professional: Carleton University Computer Center, 1976-80

In April of 1976 I moved back to Ottawa to take a job at Carleton University’s Computer Center. This was like a dream to me!

The job was primarily to support academic use of the computer systems and software by students and professors. Each of us had responsibility for certain programs, and since my background was in geography, I ended up supporting certain mapping (SYMAP) and mathematical (MATHLAB) programs.

SYMAP was a very rudimentary (but heavily used) program that could produce maps using the computer printer — made up of typewritten characters overprinted to create densities. Like I said, very rudimentary. Graphic plotters were just emerging, and although the university owned one, there was no decent software for them yet.

Some professors expressed a desire to somehow be able to “overlay” two different maps in order to show various relationships — for example, a map of rock-types and a map of vegetation types, when overlaid, could potentially indicate best places to look for precious minerals… So I took on the challenge and created a SYMAP add-on program which I called SUPERMAP (for its ability to super-impose, not because it was superior!) This became quite popular with some social-economic geographers.

There was already a program called SYMVU that took SYMAP data points and produced a small three-dimensional graphic plot — however it was a cumbersome program and could only output the results to the plotter. Plotted output was very slow and expensive. So I undertook creating a very similar program that would run faster and be able to output the plots on CRT screen monitors. I called it PREVU, and it became quite popular within the Carleton geography and social studies departments.

A geology professor was suitably impressed and asked me to give a special lecture to his class. I accepted and showed how such a system could be used for remote sensing mapping — taking map data from early Earth-mapping satellites and using it to help in mineral exploration. [See also my “side note” at the end of this post for more interesting details]

One year Carleton had a visiting scholar from the university of Edinburgh in Scotland. He had developed one of the World’s first mapping programs that used a graphics plotter, and came to Carleton to continue that development. HIs program, GIMMS, could produce what were at the time high-resolution black and white plots of maps. Because of my background I worked quite closely with the GIMMS project and provided technical support to its users.

In my last year at Carleton, 1975-6, micro computers were just emerging. I saw potential in them, whereas the computer center itself had little interest. But as grad students and professors started inquiring about the potential use of such simple computers, I was given the added responsibility of being their Micro Computer Liaison.

My main project (which took come convincing) was to use a micro computer and a digitizing table to replace the aging and problematic digitizer that the geography department had used for mapping creation. Although the original digitizer was worth close to $100,000, I was successful in creating a functional replacement using a North-Star Micro computer and a new large digitizing tablet — which if I remember correctly cost a total of about $2000.

I have attached a couple of Carleton newsletters which showcase some of the projects I worked on…

Just before I left Carleton to move to Toronto, I participated in a software conversion project. Carleton had decided to move to a Honeywell mainframe after Xerox unexpectedly decided to exit the mainframe business. I converted and certified SYMAP and MATHLAB to run on the Honeywell machine, in cooperation with the companies that produced those software programs.

Side note: the geology professor that I mentioned earlier was named Patrick Arthur Hill. I took a class from him when I was an  undergraduate student, and the following year — because I enjoyed his class so much —  I actually sat in on his lectures for a class I was not enrolled in. He was an amazing teacher, and I’ve mentioned him to many people as my idea of what a university professor should be. His lectures, although on geology, included all sorts of references to countries around the world, cultures, etc. I remember him even describing how a certain geological formation had affected the music compositions of a particular area!

In any case, when I visited Carleton campus 20 years after I graduated, I tried to look him up. The geology department office told me that he was retired but that he still maintained a box and if I wanted to leave a note I could do so. So I wrote an impromptu note telling him how much I had enjoyed his lectures, reminding him that I had taught a guest lecture for him at one point, and just wishing him well. I was astounded when a few weeks later I got in the mail a handwritten note from him which I present below…

Sadly, I found out that he passed away two years after I left that note… And from his obituary learned a lot more about him that I wish I had known…

Computer Analyst: Litton Systems Canada, 1980-1992

Shortly after moving to Toronto I took a job at Litton Systems Canada (LSL) — a division of Litton Industries. This division was primarily tasked with producing guidance systems, and at one point most of the commercial airline guidance systems in the US and Canada came from LSL.

My position was in a section called Test Equipment Engineering. They were responsible for making sure that all pieces of test equipment used in manufacturing were precisely in spec and accounted for. There were literally thousands of items that were considered “test equipment” — anything from a sophisticated electronic device down to a screwdriver, and also the software that ran any automated tests. Our task was to track every item, recall it according to its schedule, have it tested in a lab, and then update the records and return it to use. Our customers (many contracts were from the US pentagon and other countries) required such records be kept accurately.

When I started there, they had a rudimentary program based on old hierarchical database technology, but they wanted to modernize and improve the system. I was in charge of the migration to Unix-based computers (Hewlett-Packard HP-UX) and a relational database (Informix). I was instrumental in selecting the computer model and other related hardware, doing most of the database programming, and managing a few other workers.

The system pumped out printed forms for each item that was due for calibration, then these forms went to the calibration labs where engineers would retrieve the physical devices (each had a serial number tag). After they were calibrated (tested against standards), the forms were filled in and the devices were returned to use. Some devices required calibration only every few months, while others called for weekly or bi-weekly testing.

I was also responsible for our department’s computer terminal installations and re-locations. In those days, workers had a terminal on their desks, not a computer. The terminals were connected using a COAX cable, and communicated directly to the UNIX computer. One of the attached photos shows the COAX cable tap that was used to connect an individual terminal to the coaxial network line.

Another project that LSL worked on was the first “heads-up” display for the Apache helicopter. Although I wasn’t an engineer, someone offered me a tiny role just for fun: The system had some control buttons with a novel LCD backing that could change icons depending on its function. I was given the opportunity to design one of the LCD icons! I don’t recall what it was, nor do I know if it was ever actually used in production, but it was something of a thrill.

The Litton job (which I kept for 12 years until we left Toronto), was my introduction to UNIX, Hewlett-Packard, and relational databases.

Litton System Canada keychain souvenir
Coax tap connector

Computer Room Designer: Litton, 1988-89

Sometime in 1988 Litton decided to move our section to a different building. Prior to that, all of our computing equipment was in a crowded room that was not properly designed as a computer room. When they told us about the plans, they also allowed for us to design and implement a properly-outfitted computer room, since our systems were by this time deemed essential to the business.

The task of designing the computer room was given to me. This included the layout, placement of equipment, cabling requirements and design, and some hardware selection. It was, for me, something new and challenging — but I enjoyed doing it.

When the room was finally ready and all cables pre-installed, I was asked if I could manage to get the systems back up within 3 days after the move. I readily agreed, but because of all my pre-planning and careful labeling of all cables, we were back up and running in 24 hours!

I found a video that I took shortly after the room was put in service, and added some descriptive narration. (I noticed afterwards that I stated it was around 1985, but I saw a date stamp later in the video that showed 1989. Assuming the camera date was set correctly, this was likely 1989.)

Consultant: Soft-Touch Systems Consulting, circa 1989-92

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.

Business card

Typical 9600 baud modem that I would install

Computer Analyst: Abbott Labs, 1992-1994

In 1992 we decided to move from Toronto to Chicago. After 12 years at Litton, this was a major change in my career. After taking a few months to settle in Chicago, I turned to job searching. I found an ad for a consulting position at Abbott Labs headquarters in north Chicago, and easily landed that temporary position.

Turned out that one Abbott division was trying to move from legacy mainframe computing to HP Unix-based systems to save money. After a few months working at Abbott, they offered to make me full-time and I accepted.

The division I worked for was called Clinical Services, and was responsible for gathering, analyzing and reporting on all the clinical trials data for new pharmaceutical products. Of course, my role was as an HP Unix expert, figuring out the hardware, software and design best suited to meet the division processing requirements. The work was interesting, and looked to be a 3-year project to get all the users and applications moved to Unix.

The Abbot Park location was beautiful, very much like a university campus, with multiple buildings in a large park-like setting. Many of the people I interacted with also reminded me of a university environment, since they were PhD medical researchers.

Working at Abbott gave me a deep insight into the trials and tribulations of pharmaceutical research. Although these companies charge what seems like crazy prices for new drugs, and they do make huge profits, then also take huge risks. A small anecdote that made me more sympathetic to this: There was a research scientist that I became friendly with. I’d pass his office a couple of times a week and often stop for a brief chat. He was always at his computer with all sorts of molecular models displayed. One day as I passed I saw him sitting in front of a blank screen. I asked why and he told me that after 5 years researching a promising new drug, he had just proven it to be ineffective! His last 5 years was for nothing, as he said “I’m back to the drawing board.”

I was also blown away by the requirement to print literally 3-5 CARTONS of paper reports about each drug trial — and the FDA required 3 copies, so that could be up to 15 cartons! I had to set up a room with multiple high-speed printers and design a method to organize the print queues to optimize print times while keeping reports organized.

I was two years into this 3-year project when I was spirited away by a local headhunter that I knew. We had already showed solid success by moving more than half of the users and applications to Unix, with the costs being less that a single year of support costs on the mainframe. Moreover, turn around times were faster, so everyone was happy. This headhunter described a new venture within a large company that desperately needed HP Unix expertise, and I had the perfect reputation. The company was Mercer, described in a separate post.

Computer Analyst: William Mercer, 1994-1995

A headhunter I knew called me while I was at Abbott Labs, encouraging me to check out a new job. Although I was happy at Abbott, the challenge sounded interesting, so I went on the interview.

William Mercer, a large New York based insurance company was launching a new venture which they called the Mercer Administration Center (MAC). This was to be a service to outsource employee medical insurance management for large corporations. They had been at it for a year, but were facing some major challenges, many of them, it seemed, HP computer related.

The idea of being involved from the ground up in a new venture sounded good, and they wanted me to take over total ownership of the computing requirements, including showing them how to properly separate the phases of the software development lifecycle (Development, Test, Production.) In addition, they were offering a significant increase over what I was getting from Abbott, and the drive from home was less than half the distance. So I accepted.

After a few weeks I started to understand what had happened there. Seems that the “subject experts” — the ones responsible for figuring our all the ins and outs of a medical insurance management system — didn’t really understand the business. As a result, the company failed to deliver as promised to their first big customer, Pepsi. They had quoted a one year development time, but then failed to tell the customer until after 11 months that they were not going to meet their own deadline. When Pepsi asked how much longer they needed, they said “another year!” Remarkably, Pepsi agreed…

I did my job and established a proper software life cycle computing environment, and trained the programmers on how to properly use it. Over the months that followed, I became very uneasy because it was apparent to me when attending business meetings that they still seemed to have the same problems. Soon, it became clear that one upper level manager based in Louisville was actually lying about the project to the Mercer Insurance parent company! He was (again) re-assuring management that they were on track, when in fact everyone knew they were a mess.

I could clearly see that they were going to miss delivery, probably by another year! So I jumped in (because I’m not the type to silently watch something like that), and at a company meeting where that manager and others were re-assuring all the staff that everything was on schedule, I stood up and asked how they expected us to believe that when we could see that things were still a mess. There was a bit of a tense exchange, and I stated that Pepsi was highly unlikely to grant us another year to complete the project. The meeting, needless to say, became quite noisy, and was quickly ended. Afterwards I was approached by many employees, thanking me for having the guts to state publicly what we all knew was true.

However, I could see the writing on the wall, so I called up my friendly headhunter and said I was ready to move on. Luckily, he found me a great position — because a few months later, William Mercer found out the truth and pulled the plug on the MAC, shutting it down permanently.

I.T. Manager: VP Unix Systems, Information Resources Inc, 1996-2001

When I wanted out of my job at Mercer, my headhunter quickly found me a position at Information Resources in downtown Chicago. I already had a reputation as being a very good problem solver, and IRI was having some problems. But what convinced me even more was that this position carried a vice president title, and paid a lot more that I was making.

My first interview was with a consultant who worked long-term at IRI. He was older, and quite technical. In the interview I got the idea that he wasn’t telling me the whole story, so I pressed him about the problems. He then pulled out a paper from his desk and explained what was going on. Even during the interview, I had some suggestions, which he got excited by. A few days later I was called in for a second interview with one of the “Group Presidents”. The one pressing question that was concerning him was “What if we have a major failure on a Friday night or Saturday, and you can’t be reached?” — To which I looked him in the eye and said “If I am the only person in my organization that can fix the problem, then I’m not doing my job.” He loved that answer, and I got the job offer.

By the way, although I was impressed by the “vice president” title, this was a very large company, and they had about a dozen VPs!

When I came on board, I found out that the Unix servers were repeatedly crashing for all sorts of reasons, disrupting work for clients, and severely affecting data delivery times. (IRI processed scan data from retailer sales, both providing analysis and raw data back to the product manufacturers and distributors. Getting the data in a very timely manner was critical to keeping up to or ahead of competition in the retail space.)

In my third week, while I was still getting to know people and evaluating the situation technically, I was asked to participate in a video conference with Proctor and Gamble. In those days a video conference was a big deal — required a special room with thousands of dollars of equipment and a dedicated high speed line. What I discovered was that P&G was IRI’s biggest customer (millions per year), and they had almost 1000 people whose job it was to analyze the data we supplied. If we were late by even a day, that was 1000 people being paid to sit on their hands!

Although they understood that I was new, they pressed for a fix to their problems. Without really knowing yet what was going on, I promised them a short-term fix within two weeks, and a longer-term fix within 3 months. I basically went out on a limb, just trusting my technical instincts, knowing that these systems should be stable.

Long story short, I found out that the people managing the servers had not applied system software patches for over two years — because, in their words, they were “too busy fighting fires”. Well, those fires were mostly due to the missing software patches! I brought in HP themselves to quickly bring the systems up to the latest patch levels (dozens of software patches were missing), and in a week we suddenly had almost no outages!

I made quite an impression in the first year, solving many similar issues. Some problems were much more complex, but I was not only technically proficient, I was very good at bridging the gap between the technical staff and the business staff, so I was able to get both sides to understand each other better and work out difficulties.

I’ve posted a few interesting emails from the first year. One of the major products at the time was called “Timeshare”, and was basically a portal into our servers that our clients could use to access our analysis programs. The actual packages of analyzed data were called “InfoViews”. Some of these terms may appear in the posted emails.

I will create a couple of separate posts covering specific episodes of my tenure at IRI.

The above letter was written immediately after I returned to my office after a company meeting. It was to my staff but of course I copied senior management.

The snippets below are some of the replies I got to that letter, which management forwarded to many departments, and to the events of the meeting in general.

I.T. Manager: IRI, the EDT project, circa 1997-2001

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.

A partial client list of companies that I got onto the EDT platform

The following are clips from emails ( bragging rights 🙂 )

Consultant: IRI lead-up to exit, 2001-2002

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.)