Being a consultant in technology it was necessary to keep up to date with the latest developments and I became interested in what was at the time a new technology in which data was recorded optically on a large disc, called a videodisc. This was a large diameter disc (about 2.5 times the diameter of today's CDROM) which could store considerable amounts of data or images. I became quite an expert in the technology and in its capabilities, as a result of which I gave a paper to the government entitled The promise of optical discs which was very well received. In addition I was asked to do some consulting for the government on whether optical discs could help solve the space problem of huge data volumes required to store all types of social and insurance data on Canadian citizens, which in many cases had to be stored for the lifetime of the individual and often beyond.

I visited the Maritimes, where this data was stored, and examined the problem, also reviewing a proposal which the government had received from a manufacturer of optical discs. This proposal was ludicrous in the extreme and said that all the government records could be stored on a few discs. From my knowledge of the video disc capacity at that time I told the government, much to their chagrin, that the videodisc system proposed by the manufacturer would handle only a very small percentage of their data and that, even if the units could be linked together in series (which was not possible at that time) they would need a fortune in hardware with the current technology, even to address just a part of the problem. I would have liked to suggest a videodisc project for their application but in all honesty could not do so.

A different manufacturer called Olivetti had developed a videodisc juke box arrangement, in which a videodisc could be selected from knowledge of its contents, and then be placed under the data reading heads of the unit. This was an interesting innovation but was quite slow in accessing the data. Fast access is usually required for useful data retrieval applications involving large data volumes.

In this regard I did receive a request from a company in Vancouver, asking if I could advise them on a project upon which they were embarking. The company, called Fairchild Data Systems, whose founder was Lloyd Pond, was interested in setting up large data storage and retrieval systems in World Trade Centres.

Their idea was to locate a cache of videodiscs at a videodisc centre and attach it by what was at that time a high speed telecommunication link called a T1 link, to local companies. These companies would transfer their updating data overnight and then do their data retrieval during the daytime. It was a concept which, for the time, could have been quite viable, given a good marketing team, the technology itself being fairly simple. They were thinking of using optical disc juke boxes, which I have mentioned had a slow access. I suggested to them that they link a number of videodiscs electronically rather than use the juke box approach, and they liked this idea.

One of the reasons for their approaching me, apart from my videodisc knowledge, was that they had become aware of the promise of the software concepts I had been developing, which would have meant they only needed one conventional computer program to handle all their needs (this was the software that later became known as GENETIX). I agreed to form a company, to be called GENETIX Software Inc., which would become the research arm of Fairchild Data Systems, while continuing as an independent entity. Lloyd Pond tried unsuccessfully to get funding for his ideas, later moving to Tacoma, in Washington State, and a good idea died on the vine.

Soon after this I was asked by the government to evaluate a proposal by a major systems integration company, who had done an initial study to show what might be done to establish an automated system across Canada to handle Search and Rescue operations carried out by the Royal Canadian Air Force (RCAF) and by the Canadian Coastguard (CCG). I evaluated the proposal but pointed out that while it appeared to solve a technical problem the vendor had given no thought to the infrastructure that would be needed, which was of far more importance than the technical aspects. As a result I was asked to supervise the development of the system from then on.

The system study had been requested by a group called the Search and Rescue Secretariat. This group was given responsibility for Search and Rescue policy within the government and was formed because of the perpetual squabbles between the senior echelons of the CCG and RCAF. From its formation the RCAF and CCG tried to destroy the Secretariat, which of course made for a more interesting, and sometimes frustrating, development.

Before going out to tender for systems implementation I decided to get a handle on the needs, doing a shortened broad brush study. This involved travelling to each of the Rescue Coordination Centres (RCC), interviewing both RCAF and CCG officers and men, and getting a feel for their operation. During the study I was fortunate in being present during a major search operation, which stressed to me that any installed system should have a fast response time. It also became evident that unless there was a system that could enable the on-line use of maps there was little point in automating the system.

I therefore set out to try and find where on-line mapping might be available and came across a mapping database development by a New York based company called IBI, which offered on-line map capability. In company with several officers I flew to New York to evaluate this offering, but came away somewhat disappointed. We did, however, discover that a company in Washington were building customised videodisc maps, so we went to investigate. The information proved to be correct, but their work was for the US government. Our Canadian defence needs helped in this regard, and we were able to evaluate their work. They had been building accurate videodisc maps of North Korea, which could then be viewed on a standard videodisc player with zoom capability. It meant that you could locate a place on the map, and then zoom in on a particular location. If it was a building, for example, you could then measure the size of the building.

This appeared ideal for our needs so we arranged to have one of the videodiscs made available for test purposes, and purchased a videodisc player. Even though we were working with North Korean data it showed us the potential usefulness of the approach for Search and Rescue activity.

At this time there were no videodisc maps of Canada so I approached the Canadian government agency responsible for map production and persuaded them, in conjunction with the Department of Defence, to arrange for the production of small and medium scale maps of Canada, and larger scale maps of certain areas on the East and West coasts. They agreed to the proposal, which meant that there now existed a feasible way of automating Search and Rescue activity in Canada.

With this assurance we went to tender. The company which did the original feasibility study, thinking no doubt that their bid was "in the bag" because of their previous work, put in a greatly inflated bid, which was rejected, the development contract being given to another systems integrator. The successful bidder had some freedom of choice but had to follow closely the solution I had proposed. Their first manager was unsuitable and I asked that he be replaced, which happened.

Most database software at that time was similar in capability, the general capability of all of them not being very impressive. One of the problems we faced was that the database had to operate in two languages. If an incident began on the East Coast all data was generated in English but if, as occasionally happened, the rescue also involved the CCG in Quebec City, all English activity up to the point of transfer between sections had to be made available in French. The opposite was true for a rescue that began in Quebec and then was transferred out of the French speaking region. I solved this problem by developing a code system for the vital information, automatically generated as the data was entered (in a manner similar to the code generated in hospital data activity, discussed in a previous chapter), which was interpreted in French if the operator was French speaking, and in English otherwise.

We had previously ascertained what data was needed urgently and what data could be entered at a later stage. In an Arctic rescue, for example, it was necessary to know the location of air strips, with the facilities that existed at the air strip (fuel reserves, first aid equipment etc.) It was also important to know the location of all hospitals in the country and what services they could provide. Other required data included the names and (hopefully correct) telephone numbers of police and search volunteers. We needed to know where light aircraft might be located, and where the owners could be contacted, the same for large and small water craft that might be useful in the rescue. Initially the search was for marine and air incidents, later extended to people. The type of data referred to was needed to plan the rescue operation.

In addition it was necessary to have knowledge of weather conditions for at least the preceding 24 hours, preferably 48 hours, with some forecast of what weather lay ahead. This meant that the system had to be tied in with the weather services. If an incident occurred in one of the Great Lakes a boat could move in one or two directions, due to an underflow in the lake. If the boat had a small keel it could drift with the prevailing wind at the time of the incident, with a larger keel it could move in the opposite direction, being driven by the undertow. On the West coast, in particular, there are strong river currents and a variety of tide conditions. A body in the water (or a small craft) could move almost anywhere. If the time of the incident was known then it was possible to determine roughly where the drift might be, otherwise it was an educated guess.

With aircraft incidents there was usually a flight plan available, but not always so. Even with a flight plan it may have been that the pilot veered from the original intent, due to mechanical failure, adverse weather conditions or other causes. On occasion an illicit drug carrying plane or vessel would get into difficulty, with no data whatsoever.

The Rescue Coordinators would trace on their video screens the filed flight plan (if available) and then sketch out on their screens a proposed search pattern for the aircraft and/or helicopters they had available for their search. Commercial pilots en route to destinations that coincided with the incident would be contacted by radio and asked to watch for unusual scenarios, or listen for the emergency locator beacon carried by aircraft. On one occasion an emergency locator beacon was being sent from Edmonton by train and somehow became switched on. The beacon indicated a different location for the crash after every satellite pass (the system had also to be linked with the orbiting satellite system). It was finally ascertained that these signals were spaced each satellite pass at a distance corresponding to the speed of a train (trains in Canada are generally slow, around 50 mph), and so it was, the beacon was on a train.

There were also the problems of false alarms, particularly from satellites, and the system had to cope with these. In addition cranks would phone the emergency number and had to be dealt with (all incoming calls were recorded on tape). The system also had to fail safe so that if an RCC became inoperative (due to equipment malfunction, tornadoes etc,) another location could take over. This meant that all data during a rescue operation had to be backed up to another RCC. It was also backed up to Headquarters computers.

Other needed data was more difficult to obtain. This involved knowing the people involved in the incident (how many, sex, ages etc.), where the incident occurred and at what time, the type of equipment (small plane, vessel etc.), the type of clothing being worn (of particular value for an Arctic incident), whether there was a fire involved, or a collision. If there were witnesses to the incident their testimony needed to be recorded and evaluated.

Having defined and tested the system the next requirement was to train the 120 or so officers of the RCAF and CCG in the use of the system. Here another snag was encountered. The two groups could not decide who was responsible for the training function. As the time approached for us to start testing the system with live data I became more and more frustrated with the lack of government decision making. Finally I set times and places for training and did the initial training myself, ignoring the squabbling between the two groups. My presentations went over quite well. After I completed the project squabbling was still prevalent between the two groups, not at the working level but at the senior officer level.