RunScore History Part 1

Part 1 – Terminal and Mainframe

Alan Jones

RunScore

My first computer-scored race – 1970

In 1970, I met Bob Osborne when we both ran the Boston Marathon. Bob was cross-country coach at Union-Endicott High School. He put on an invitational meet every fall at the IBM Country Club in Endwell. I scored the race for him in 1970 and 1971 but then stopped since it was so much work. We think that this might be the first race scored in real time by a computer. Here is a photo of us working at the terminal in the golf shop during the 1970 race.

Yes, that’s me at the terminal. The woman helping is Bob Osborne’s wife, Donna. The young woman is Cathy Young.

The terminal costs $4000, borrowed from IBM. We connected by telephone to a million dollar IBM computer at the State University of New York at Binghamton using the APL system developed by IBM.

New York State Intersectional Cross-Country Championship — 1973

In 1973 the New York State Intersectional Championship came to Binghamton and I was asked to score it. I then wrote an article and sent it to Runner’s World. Joe Henderson, the editor rejected it since they had just had an article on computer scoring of races. But he said he would include it in the book, The Complete Runner[1], which he was in the process of editing. Here is that article:


COMPUTERIZED SCORING

BY ALAN JONES

Jones is a senior engineer with IBM in Endicott, N.Y.

Anyone who has run cross-country knows how disconcerting it is to sit around after a large meet while the officials try to figure out the team score. Also, unless his coach has been manning the finish line, the runner may not know his time for days — until the official results are printed. Even then, the results may include the times of only the top finishers. It would seem that in this day of rapid data processing, a runner should know his place, time and team position shortly after finishing a race.

To fill this gap, I began working on such a system in 1970 with Bob Osborne, who coaches a local high school team. Bob runs a large meet every fall which consists of three races (varsity, junior varsity and junior high). In the fall of 1973 the New York State High School cross-country championships was held at Binghampton[2], and the meet director, Ron White, asked us to score it.

Data processing in cross-country scoring is nothing new. The NCAA meet was scored with IBM card equipment in the 1930s. Al­so, the last few years the NCAA and National AAU meets have been scored by computer (see “Computerized Cross-Country,” by Jack Daniels and Jimmy Gilbert, Runner’s World, Aug. 1973).

We timed our meet in real-time (while the race was happening) as well as scored it. We did this through a computer terminal which was connected via an ordinary phone line to the computer (which may be miles away). The terminal looks like an ordinary typewriter. The difference is that what a person types is transmitted over the phone line to the computer[3]. The computer, if programmed properly, can transmit messages which are typed out automatically by the termin­al. The computer we used was on the campus of the State Universi­ty of New York at Binghampton, while the terminal was in a build­ing only about 200 yards from the finish line.

The computer was programmed to allow easy data entry. Sev­eral days before the meet, we typed in the names of all of the en­trants, including alternates, their competition numbers and school affiliations. Any entry in the list could be easily altered up to the time of the race.

On the day of the race, we set up two terminals near the finish. A friend of mine, Andy Lavin, was stationed at the finish line with a walkie-talkie. The other end this communication link was at one terminal, where I was stationed. A similar link was established from the end of the chute to the other terminal, where another friend, Steve Bespalko, was stationed. It was the job of my terminal to record the timing information and Steve’s to record the finish order. This actually can be done with one terminal, but with the use of two, things were speeded up since we could be doing both jobs at the same time.

This is the way the timing worked. As the first runner approached the finish line, Andy alerted me over the walkie-talkie. When the winner crossed the line Andy said, “one,” and I would press the carriage return key on the terminal. This signal was passed over the line and recorded by the “time-of-day” clock built into the computer. Also, a finish judge recorded the winner’s time in normal fashion with a stop watch. When the next runner crossed the line Andy said, “One,” and I again hit the carriage return.

As the race progressed, the runners would be closer together. In fact, they started crossing the line so fast that there wasn’t time for Andy to say “one,” have me hit the key and be ready for the next “one.” In this case, Andy would group the runners as they crossed the line and say, for example, “three” as a group of three crossed. Then I would depress the “three” key and the carriage return. This told the computer that three runners crossed at the same time. We kept this going up until the last runner crossed the line.

While this was going on, another helper was reading out loud the competitors’ numbers as they emerged from the chute. This list was being recorded on paper and also being sent over the of walkie-talkies so that Steve could enter this list of numbers into his terminal. Since there was the chance of error by sending numbers over the walkie-talkie, we proofread them against the list sent up from the finish line. As back-up for both timing information and the finish order information, both Andy and the helper at the finish line recorded what they said on a tape recorder.

After all of this information was stored in the computer memory, we entered the winner’s time. Then, since the computer knew all of the finishers’ time-of-day finish time, the program was able to ad­just each time based on the winner’s time. The program checked to make sure that a number was not entered twice, that there was an entrant for each number, and that the number of finishers was the same as the number of times.

The result sheet was then typed at the terminal onto a stencil. After typing all of the finishers with their place, school and time, the program did the team scoring. To do this, it has to cull out all individual runners and all runners on a team with fewer than five finishers. Also, if a team had more than seven finishers, extra run­ners were culled. After this culling, the positions of the first five runners were added to obtain the team scores. The teams were sort­ed using this information and the final team scores printed by the terminal.

We scored three races (classes A, B, and C) at the state meet and three at the sectional meet the week before, using this system. In most cases, we were handing out results within 35 minutes of the time the last runner crossed the line. At the state meet, we record­ed exactly the same number of runners crossing the finish line as emerged from the chute in all three races. The only error that caused a problem in scoring was a human one. As I entered the auditorium where the awards were being handed out, Bob Osborne ran up to me and said, “The computer messed up!” It seems that a coach had a boy finish in 22nd spot but the computer listing had another boy in that spot who hadn’t run. There was no mention of the fellow who had finished 22nd. After studying the final result sheet, we found the error. The person writing down the finish or­der had written the competition number “3” so it looked exactly like a “20.” If we had used our tape recording of the finish judge calling out the numbers instead of the written version, this would not have occurred.

The advantage of this system is the rapidity with which the re­sults can be entered into the system and the fact that the computer is aiding in recording a time for each finisher. All of the sorting of entrants into the order of finish is done automatically, thus reduc­ing the chance of human error. Also, it may be a small point, but a system of this sort virtually eliminates misspelled names since the names are typed in ahead of time and can be carefully proofread.

It has always been my opinion that a runner should be able to leave a race with a copy of the results including a time for each fin­isher and the team scores. Systems such as this allow this to happen with more accuracy and speed than possible before.

To use our system, the meet director would have to have available a computer which runs the APL system and a person who understands the system well. Since APL is being run currently on many campuses, it should not be hard to find such a system. Also, it should be recalled that the computer can be many miles away. All one needs at the race site is a terminal and a phone.

[1] The Complete Runner, Avon Books, A division of Hearst Corporation, New York, 1974, Runner’s World, p. 377.

[2] This should be spelled “Binghamton.” After the book was released, I wrote to Joe Henderson and told him that there was no ‘p’ in Binghamton. He wrote back something to the effect, “There isn’t a ‘p’ in Binghamton? I’ve been putting a ‘p’ in Binghamton for years!”

[3] We used an “acoustic” coupler into which one could place a telephone handset. It would send sounds into the ear piece and pick up sounds from the mouthpiece and convert them into signals which were sent over the telephone line. The baud (bits per second) was 134.5, the speed of the typing element on the Selectric typewriter mechanism in the terminal.