Chapter 6: The Automated Weather Network
A pioneering effort
Captain Norm Phares always seemed to find things out before anyone else. As we left the office for the New Years holiday weekend, Norm told me that a message from Headquarters AWS was received that afternoon requesting three people by name for a new high-priority project. The Pentagon had approved an innovative weather communication computer network for AWS. Although my name was not mentioned in the message, Norm thought I would make a better choice than one of the persons named. He didn’t say whether he had mentioned this to Colonel Lewis.
I thought about Norm’s hot news all the way home. My first reaction was, “Surely Colonel Lewis wouldn’t give me away; he still needs me!” I liked my job – my first experience as a supervisor after ten years of service – and I still had lots of ideas I wanted to implement into our new computer. My five NCOs were intelligent, energetic, and a lot of fun to work with. I had an inner office which impressed me at the time, and I also wanted to stay in Washington.
Over the weekend I continued to think about it, and as I left for work on Monday, I was still concerned about what my fate might be and didn’t have long to wait. Colonel Lewis called me to his office first thing to tell me something important. He apparently agreed with Norm, for he had already arranged for me to be loaned to this major new project that was to be completed by the first of July. It was a relief to hear it would be just temporary. Big Red, as we called Colonel Lewis, painted an exciting picture of the project, and as I heard more details about the system I began to understand his enthusiasm. He had just talked to headquarters at great length and was convinced this project would have a major impact on Air Weather Service and weather communications in general.
He was certainly right. In fact, the AWN would not only revolutionize weather communications for the Air Force, but for the Navy and the National Weather Service as well. By mid-year 1965 the Air Force’s Automatic Weather Network (AWN) – a pioneering effort in computer networking – would become a national resource. It would take the United Nation’s World Weather Watch almost a decade to duplicate our efforts.
Justifying the need
Soon after President Johnson took office in November 1963 he began to escalate our involvement in Vietnam. The Gulf of Tonkin incident off the coast of Vietnam in August 1964 had prompted Congress’s Tonkin Resolution to increase financial support of Johnson’s policies.
The Air Force and its weather service were also becoming more involved, but AWS had a problem. Our forecasters at SAC headquarters desperately needed better communication with Southeast Asia, so AWS sought a way to speed up the delivery of observations from Vietnam to its Global Weather Central and SAC at Offutt.
Weather observations from Southeast Asia were relayed a number of times before finally arriving at Global. Long delays at each retransmission site were common; most bulletins were transmitted according to a schedule rather than “as available” and this too slowed them down. It was not unusual for the latest Saigon observation to arrive at Global five hours later. Data from other militarily-sensitive areas of the world were similarly routinely delayed. Each retransmission also meant additional atmospheric-interference induced garble in the data.
For an answer to their problem, AWS turned to the three major computer manufacturers of the day: IBM, Control Data Corporation (CDC), and Sperry Rand UNIVAC. At the time, IBM was preeminent in business computers, CDC held the edge in scientific computing – number crunching as it was called while Sperry Rand UNIVAC lead the pack in communication-computer technology.
Currently in the middle of their 1960’s race to the moon, NASA had just selected a UNIVAC 418 system for their proposed NASCOMNET: a computer network that would speed delivery of their world-wide administrative traffic to a central point. UNIVAC was contracted to install a network of four U418s – one in London, another in Tokyo, a third at the Goddard Space Flight Center in Greenbelt, Maryland, plus a fourth at their Houston Space Flight Center. All of their low-speed teletype administrative circuits would be multiplexed (read simultaneously) into the first three 418s. The two overseas computers would transmit their traffic via high-speed, 2,400 bit per second (2,400 baud), leased lines on existing sub-oceanic telephone cables to the 418 at Greenbelt, Maryland where it would be merged with Goddard’s own low-speed input and sent high-speed to Houston. Traffic from as far away as Australia would arrive at Houston within seconds.
Based on this NASA contract it was obvious that UNIVAC could satisfy AWS’s needs “off the shelf.” In the fall of 1964 a proposal recommending UNIVAC’s NASA solution for AWS was presented to the Air Staff at the Pentagon. In late December the proposal was approved with a “Brickbat 1-1” (war emergency) priority with an operational date of 1 July 1965. According to Fuller, assurances that the AWN would also support certain “special strategic programs” whose needs had “sufficient clout in national security circles” ultimately justified this project.
Similar to NASA’s system, an AWS 418 at High Wycombe Air Station, England, and one at Fuchu Air Station, Japan, would be linked to a 418 at Tinker AFB, Oklahoma. The Tinker 418 would merge its 2,400 baud overseas traffic with their own low-speed input and forward all of it high-speed to a final 418 at Global. UNIVAC was awarded a sole-source (non-competitive) contract.
Air Force’s weather intercept program
High Wycombe and Fuchu were selected as the AWN’s overseas sites for good reasons. High Wycombe and Fuchu were close to two of Air Force Communication Services (AFCS’s) weather intercept antenna farms.
For many years, AFCS operated a weather intercept program to help Global support SAC’s targeting requirements and “other strategic programs.” According to Mr. Art Gulliver, the program was initially funded by and dedicated to support the classified customers of the Air Force Weather Center, originally located at Andrews AFB, Maryland.
“The USSR apparently gave high priority to their weather observational network, because by 1953 it had become a denser network than any other nation’s, particularly in the Arctic.” While meeting their commitment for weather data sharing to the World Meteorological Organization (WMO), the Soviet refused all efforts of the western nations to provide surface supplemental groups (precipitation amounts and additional cloud information) plus “second transmissions” of upper air observations (data at 100 millibars [approximately 53,000 feet] and above). They claimed that these data were of no value to anyone else.
As military aircraft ceilings climbed well above 53,000 feet in the late 1950s, it became more important than ever that the Air Force copy the USSR’s internal broadcasts that contained such data. The CIA’s U-2 was perhaps our nation’s most famous (notorious from Russia’s point of view) high-altitude airplane, although its operational ceiling was always kept a closely guarded secret.
When weather data, or any other kind of information, is broadcast into the atmosphere by radio-teletype, such data is available to anyone within listening range of the signal who wishes to tune a receiver to the broadcast frequency and copy (intercept) the broadcast.
This is not possible when data is broadcast via hard-wire circuits unless someone physically attaches an electronic bugging device to the wire.
By 1965, U.S. domestic weather data was no longer being transmitted point-to-point via radio-teletype. A hard-wire weather circuit system called the Continental United States Meteorological Teletype, or COMET, was implemented in 1962 with an automated weather relay center at Tinker AFB in Oklahoma. The main trunks of the system transmitted at 1200 baud – twelve to eighteen times faster than its feeder loop-circuits. Its data was accessible only to receiving station or stations at the other end of the wire.
At this same time, Russia and China were still broadcasting most of their weather observations via radio-teletype. Over thirty years later, they still do. Weather has yet to gain sufficient priority in either country to merit expensive upgrading.
AFCS clustered radio-receiver towers at a few locations around the world. Sites at Fuchu AS, Japan, and Croughton, England, copied data originating from within the Sino-Soviet, and the AWN would now dramatically speed up the delivery of these data to Global.
Croughton listened to broadcasts from Moscow, Kiev, Leningrad, Archangel, Tbilisi, Alma-Ata, Kuibyshev, and Novosibirsk. Fuchu tuned into a similar array on their side of the globe. The weather intercept system was unclassified.
Every three hours, Novosibirsk transmitted about twenty surface synoptic observations from surrounding communities in central Russia to Moscow while the Air Force passively copied this same data at Croughton. Moscow copied Novosibirsk’s broadcasts plus all of its others, and then rebroadcast some of this synoptic data to other countries in Eastern Europe. Since we were listening to all of the weather broadcasts from within the Soviet, Moscow’s rebroadcast contained mostly duplicate information, however, because of the high garble rates on radio-teletype circuits, this redundancy was a useful backup.
There was even more redundancy in our total collection system. Moscow had an international commitment through the World Meteorological Organization (WMO), an adjunct of the United Nations, to send some of this same data on a hard line to Paris through Prague. Paris then transmitted the identical data to Britain’s Met Office at Bracknell and we paid for a trunk off Bracknell’s line to Wycombe. This data, however, did not contain the supplemental surface data mentioned above, nor “second transmissions” from upper air observations.
Since data from minor reporting stations inside Russia were not included in international exchanges, our intercept program provided us with critical data not available elsewhere that better satisfied Global’s requirement to provide SAC with targeting forecasts.
A joint effort
The AWN would basically be a communication system and therefore would be owned and operated by AFCS. AWS and AFCS had worked together on the proposal, but AFCS currently had their hands full with a much larger system – AUTODIN: a computer communication system similar to NASA’s NASCOMNET but much more expansive and complex. Its traffic load was immense, much of it was classified TOP SECRET. AFCS decided that they didn’t have the resources at the time to commit to the development of a project with such a short lead time. In fact they initially felt that the 1 July 1965 implementation date was impractical, even idealistic. They agreed to the proposal only after AWS volunteered to assume responsibility for software development. AFCS and UNIVAC agreed they could complete site preparation and hardware installation on time, but it would be close.
Gathering a team
When AWS first began using computers in the early 1960s they decided to teach meteorologists how to program rather than teach meteorology to programmers, and by 1965 had many experienced meteorologist-programmers available for the AWN.
A programming team of twelve was quickly assembled: nine from AWS, plus three from AFCS. While Colonel Lewis played it honestly and provided competent people, other units sent us their “dead wood.” Seven of the twelve of us would do most of the work.
Lieutenant Colonel Scotty Williams managed the project for AWS and made frequent visits to us in DC. Major John Ball from Global and I were put in charge of two teams. John and his group would modify the software package for the hub computer at Tinker and my team would adapt the overseas packages. Due to other construction projects, installation of Global’s 418 was delayed until later. Until their computer went on line, they would simply print their data out. They would also have to write their own software that would satisfy their different needs.
While the other ten programmers attended a UNIVAC programming course on real-time programming, John Ball and I attended meetings at AWS Headquarters and Global Weather that extended into early February.
The more I learned about the AWN the more excited I became, but also present was the specter of possible failure; we certainly had little time to accomplish such an ambitious task. Were we boarding a sinking ship, or would we in the end sail triumphant into history books? Only time would tell.
Waiting for Godot
Programming classes ended and organizational meetings were completed by mid-February and the team of twelve was finally assembled at the UNIVAC computer center in Georgetown. This was convenient for Al Polston, Harry Rice, and me. Each morning Air Force chauffeurs picked us up at ETAC and delivered us to the UNIVAC building, out-of-towners stayed at Andrews AFB.
UNIVAC was to provide us with the program code they were developing for NASA as soon as they were able to assemble it, which was supposed to be in just a few days. We were then to adapt their program to our own purposes. This would be a relatively easy task as long as UNIVAC provided good code.
For the first week or so we arrived at work each morning expecting to receive our listings. We were “Waiting for Godot,” and just as in Samuel Beckett’s allegorical play, Godot never appeared. Or was there even such a person?
After a time, perhaps a week or two, we guessed the truth. Unlike its major rival IBM, UNIVAC in the 1960s didn’t have an army of experienced programmers available for this project. Most of the UNIVAC’s NASA program team were neophytes with less experience than we had, and were still scrambling around out at the Goddard Space Flight Center trying to get their code to assemble.
UNIVAC’s Ms. Roxanne O’Leary, an experienced system analyst, had completed the program’s design, but the actual coding was left to less experienced employees.
Real-time programming
We live our lives in real-time. Some of us are better than others at processing multiple input as fast as we receive it, but no human can simultaneous read more than one document at a time. Our two eyes work in binocular fashion, limited to focusing on a single written page. In 1965 the UNIVAC 418 was undoubtedly the finest piece of real-time computer hardware on the market, but its utility depended on the cleverness of the complex logic conceived within human brains and given birth as “software,” the instructions loaded into the otherwise stupid computer and executed verbatim, exactly as written and assembled.
Real-time programming is more complicated than batch-processing. Real-time data is not collected beforehand, but flows into the computer as it becomes available, usually from communication circuits. Each of our 418s would read input from thirty-two input circuits and the program must be able to read and process all of these data streams simultaneously without losing a single character. The AWN’s input circuits transmit at either sixty-six or a hundred words per minute (WPM).
MSG Al Polston and I were the most experienced programmers in our group, but like all of us, our experience was in what is called batch-processing, where input data is read one block of information at a time from a passive input device such as an IBM card-reader or a magnetic tape drive. A batch-processing program reads only the amount of data it wants and then processes this data before reading the next unit of data. Unlike real-time, batch processing systems control the rate of data input flow. The next block waits patiently on the input device for an invitation to enter.
A whole day’s worth of data could be processed by ETAC’s 7040 in an hour or two. In contrast, the AWN’s 418s would spend twenty-four hours processing a day’s worth of observations, but in real-time: as made available on transmission circuits. The 418s would spend 50 to 60% of their day waiting for something to do. Each would read its multiple data streams simultaneously without getting them mixed up (interlaced) with one another. Separate messages, weather bulletins from any one of thirty-two different incoming Communication Line Terminals (CLTs), are then transmitted contiguously into a single high-speed circuit to the next 418. This amazing juggling is accomplished by using what is called multi-tasking programming techniques described in Technical Note 1 in Appendix A. (The computer literate and other interested readers may refer to these notes if you wish.) Again, the secret lies in the software’s clever logic that allows this single-minded robot do all of this. An essential feature of real-time computers is that they be able to handle maximum potential traffic flow – those times when every circuit is carrying data.
Blue-suiters take over
Al Polston had an intuitive ability to write computer programs, and since we first met two years earlier had become an outstanding system programmer-analyst. He could grasp the larger picture and I considered him my secret weapon. Al also respected my competence.
Harry Rice’s skills were also impressive, but unlike Al, Harry enjoyed focusing on more limited but still complex parts rather than on the whole system. Harry’s analytic mind was well suited to writing weather decode sub-routines: decision trees to identify and error check specific weather data types. At ETAC, Harry wrote our surface synoptic decoder.
For over a year and a half, the three of us had worked as a team and part of my enthusiasm for this new project was knowing these two men would continue to work with me.
After his retirement in 1969, Al went to work for UNIVAC and had a very successful second career with that company during their hay-days in the 1970s and 80s. Harry retired that same year and took his skills to the National Weather Service’s Communication division.
After a couple of weeks of waiting for Godot we convinced UNIVAC to provide us a listing of their coding no matter what condition it was in. They reluctantly consented. Al and I and two of the AFCS officers, Ron Cooper and Jerry Shuster, dug into this coding and immediately saw that the Goddard group had still not yet been able to assemble their program.
The listing we were given also showed how inexperienced UNIVAC’s programmers were. For instance, labels are inserted at important points in computer programs to act as addresses where program control may be transferred from other points in the logic during program execution. These labels, called mnemonics, are supposed to be meaningful names to assist the programmer’s memory. Labels inserted by UNIVAC programmers were intended more to elicit a giggle. Their only utility was that all of the labels in one section began with the same letter: labels in the low-speed input processing section began with an “L.” High-speed input labels began with an “H”: HOTBED, HOTEL HOHUM. Such mnemonics gave no hint about the program’s logic at that point.
If UNIVAC was in trouble then so were we. Godot finally arrived but made no sense, so the four of us got very busy learning the basic system design and data flow. I hadn’t been privileged to attend the real-time programming classes with the others, but I was already well versed in assembly language programming and with Al’s help was able to pick up the essential concepts of this new computer and its language.
We quickly found a few programming errors (bugs) in their partial listing, and after snooping around a bit found the telephone number of the Goddard group. Without asking UNIVAC management team’s permission, we called Goddard directly and relayed our findings. In doing this we established our credibility with them, and the two groups began to work together, but not for long. They sent us more complete listings from which we punched up our own program card deck and quickly began our own development in earnest.
The UNIVAC project manager overseeing our system was anxious at first, but how could he stop us? We were the customer and the customer is always right. But did his customers know what they were doing? What would Air Force say if this brash bunch struck off on their own and failed? What would NASA say if the Air Force’s system went on line before theirs? UNIVAC management had no choice but to step aside, and, perhaps, to pray.
If our group of Air Force blue-suiters had not taken the initiative at this time we would have missed our target of 1 July by a wide margin. Proud to say, the AWN went on line months before NASA’s system.
Primitive modems and other challenges
By now we had less than four months left to finish the job. UNIVAC installed a 418 for us to test with and we began our checkout by inputting tiny pieces of phony data into memory through keys on the 418’s front panel. Through trial and error, we slowly began to understand the intricacies of real-time multi-tasking programs. When weather circuits were later attached to the communication multiplexer, we could begin dealing with the real thing.
Data from each input circuit flowed into its separate buffer and we debugged our system chronologically from these input buffers through critical program points until we were finally able to send a message out onto a simulated high-speed circuit to what would eventually be the hub at Tinker AFB, Oklahoma.
It had become an exhilarating experience and we all awoke each morning eager to get to work. Every problem solved brought greater satisfaction and increased confidence that we would meet our July 1st target date.
My friend, Castor Mendez-Vigo from Pinecastle days was AWS’s liaison officer with the National Weather Service’s satellite group at Suitland, Maryland, and visited me one day at UNIVAC to see what we were doing. After his tour he said that, in his opinion, this project would guarantee the future success of my Air Force career. Although I hadn’t given this much thought before, Cas’s prophesy proved to be accurate.
One day I stood and watched Air Force and UNIVAC electronic engineers ponder a problem they were having with the Air Force owned modems we would use. A modem is an electronic “black box” used on high-speed circuits between computers to change – modulate – a computer’s digital output into analog form – a sound wave that can be carried by the connecting circuit to the receiving computer. When this analog signal arrives at its destination it’s again passed through a modem to be demodulated back into a digital form that the receiving computer can read and understand: mo-dem, modulate-demodulate. 1965 modems were much bulkier than present day modems – they measured about thirty-two inches wide, fifteen inches deep, and six inches tall. The modem attached to my Macintosh is nine by six by one and one half inches.
Just as humans must be in sync when they are talking to each other, modems too must also be synchronized before information can begin to be passed back and forth between them. If I’m reading a newspaper or even day-dreaming when you begin talking to me, I may miss your first word or two if you don’t first get my attention; if we’re not first in sync.
The engineers were sending messages to another 418 some distance away and the two modems kept falling out of sync between transmissions. I listened as they decided that they must build an idle-character generator into our modems. A continuous stream of idle-characters transmitted between actual data transmissions would keep the modems synchronized. This technique also required that each modem sends two special characters signaling that real data is about to follow; sort of like when we humans clear our throat with an “ahem” to get the other person’s attention before we begin talking.
Sharp, you’re our man
In late May, about one month before the AWN was to go on-line, I was anointed to manage further development of the AWN and when the system goes on-line, Al Polston and I would be transferred to Tinker AFB, Oklahoma. This was flattering news, and it pleased me, for I had already begun to envision how this system could grow. Our 418s could do so much more for us than the NASA program was designed to do.
I was not too thrilled at the prospect of living in Oklahoma, this would be farther from an ocean than I had ever lived before. It would also be hot as blazes in the summer with lots of tornadoes in the spring.
MSG Harry Rice and Captain Vilhelm Bjerknes were to be sent to High Wycombe. Lieutenant Ron Cooper would be AFCS’s man on the spot at Wycombe and Vil and Harry would work for Lieutenant Colonel Ed Maykut. Ed had been my boss for a short while at ETAC where he had computer experience with satellite data. Major Dick Wilson at Fuchu would be doing the programming for Major Telfer in Japan. Dick was already stationed at Fuchu and I would soon get to meet him.
Lieutenant Colonel Wendell Phillips was sent to DC from Headquarters to inform me that I was their man and I asked him two very important questions. Who would I be working for, and what did this person know about computers and the AWN? He told me that their plan was for me to be assigned to the 6th Weather Squadron (Mobile) at Tinker
The 6th Weather Squadron (Mobile) was AWS’s famous original tornado chasers. Their mobile balloon launchers traveled all over tornado-alley, releasing balloons into unstable air that had the potential to breed tornadoes. During each spring’s tornado season they followed severe storm outbreaks from Colorado to Ohio, and from Texas to Minnesota and the Dakotas, wherever strong winds did blow. Their commander was a fine gentleman but he knew nothing about computers.
I said emphatically that I would prefer to work for someone more knowledgeable about what I was doing. The prospect of breaking frontiers in weather communication technology for a boss who had no idea what I was all about didn’t appeal to me at all. Since I would really be working for Headquarters Air Weather Service and would have to coordinate development with programmers in two different weather wings, the 2nd Wing in Europe and the 1st in Japan, wouldn’t it make more sense for me to be placed directly under Headquarters AWS? The authority of AWS behind me would help if and when the AWN’s diverse units came to a disagreement. (This eventually – perhaps even inevitably – happened.) Wing commanders have what are called commander’s prerogatives and only the commanding general of AWS has line-of-command authority over them.
I must have argued my case well, for the very next week Lieutenant Colonel Phillips called me from Scott AFB in Illinois to advise me that I would become Headquarters AWS Operating Location 7 (OL-7) at Tinker. Scotty Williams in the Operational Systems Directorate at AWS would become my rating official. Since he was undoubtedly the one who recommended me to assume control of future development, it was a break for me to continue working for someone who was already impressed with my work. I was very pleased with this arrangement and felt good about looking out for myself as well as the interests of the Air Force. The other arrangement would not have worked.
At home I had a problem. For two years our son Doug, now thirteen, had been a member of an active and well-run Boy Scout troop that camped a lot. Doug enjoyed camping very much and didn’t want to leave his scout friends. It nearly broke my heart to hear Doug cry himself to sleep for a few nights when he first heard the news. I seriously considered resigning my commission and going to work for the National Weather Service so I could stay in the Washington DC area. I was well known out at Suitland, and my participation in the AWN project I was sure had not gone unnoticed there. Doug worked through his pain and finally seemed to be reconciled to the move and I decided to stay on active duty. The lesson I learned from this was that the worst time to move a child is in their early teens. Peer loyalties are important at this age. I remembered how I had felt at age fifteen when my own parents moved our family from Philadelphia to Los Angeles. I was just as pained as Doug, and I didn’t recover from my grief until, fortunately for me, six months later we moved back home again.
But for now I had to help get our system on-line and then pack up and move once again. Our three years in Washington had been a great experience. In 1950 we had spent our honeymoon there and now had many more memories that would draw us back to visit DC as often as we could for the rest of our lives.
“Through Tinker to Offutt by chance”
Site preparations at Fuchu, Tinker, and High Wycombe were completed in early June and we decided that our program could do all that was asked of it. Now was the time to go on-line.
We knew that the system would initially be far from perfect. NASA’s needs were much less complex than ours. We were confident, however, that the program could handle peak traffic load and deliver it all its data to Offutt – at least in fits and starts. The system still halted about once an hour or so, but we simply restarted it and began with whatever data we could recover.
The quality of the data that finally printed out at Global would not be pretty, but Global wasn’t yet ready to feed it directly into their large computers anyway. We had no idea how they would initially use it, but that was their problem. We had to focus on our job. Once the AWN was on-line and Al and I were at Tinker we could address all remaining problems.
Someone had to go to each site to bring the system up. I went to Fuchu, Ron Cooper and Ed Maykut went to High Wycombe, and Al Polston, John Ball, and Jerry Shuster went to the hub at Tinker. Al took his family with him to Oklahoma and stayed.
AFCS Captain Jim Schwartz and I left DC on June 4th and arrived at Fuchu on the 7th of June. Twenty-four days remained until July 1st. I ran into a little problem. When I checked in for my overseas flight at Travis AFB, California and the sergeant at the desk asked to see my shot record I realized immediately that I was in trouble. My immunization card was in my wallet where I always carried it, but I knew that it was way out of date. When the clerk looked at it, he sort of frowned and asked, “Was this an unexpected trip Captain?” I smiled and answered, “No, I just wasn’t thinking.” He was used to the likes of me and just smiled politely and pointed down a hallway to their shot clinic. I received at least six inoculations, including one for the Bubonic Plague and later joked that they needed a courier officer to carry some classified germs to the Far East and I was selected. By the time I climbed aboard the plane two hours later I was sinking fast. I slept most of the way to Japan and remember little about the flight. This actually made the time past more quickly, but I certainly was not comfortable. By the time I reached Fuchu Air Station on the outskirts of Tokyo I was back to normal with my immune system reinforced with a bevy of new antibodies.
Detachment 1, 20th Weather Squadron, located at Fuchu put Major Ray Telfer in charge of its AWN terminal, but Major Dick Wilson would do the programming. Dick was an excellent choice for the job. Lieutenant Colonel Edward O. Jess was the commander of the Tokyo Weather Central at Fuchu and when I paid my courtesy call he didn’t seem to believe that this new computer would help him do his job any better. He made it clear that to him the 418 seemed like an albatross. My explanation didn’t help. True, it would take a lot more program development before his organization would benefit, but within a few years the AWN would replace scores of manual weather editor positions at weather communication centers world-wide and eliminating so many Air Force jobs overseas would help stem the gold flow that was a national concern in the ‘60s.
Dick Wilson had taught himself the 418 coding language before I arrived, and was eager to learn our program. For the next two weeks we worked many long hours together; Dick stayed close by my side the whole time and caught on quickly.
As soon as we loaded the software into the system and cranked it up it appeared to work as well as it did in DC. We made only a few minor changes, many of them site-specific. Since Tokyo was nine time-zones west of Oklahoma, much of our work with Al and Jerry had to be done at night. That was fine by me for my circadian clock was still set on Eastern Daylight Time. Our sub-oceanic cable circuit to Tinker was voice quality; we could talk to Tinker programmers as easily as if they were in the next room. Tinker could even patch us through to High Wycombe and the quality of the signal stayed the same.
The system had a few troublesome bugs. It still halted two or three times a day, but we would continue to simply restart it with minor data loss. One day while Tinker was testing its line to Offutt’s IBM 1004 printer I addressed an administrative message through to Global that read: “THROUGH TINKER TO OFFUTT BY CHANCE.”
Al Polston told me recently that he saw my message go through Tinker because he was printing all of our traffic out at the time and I had alerted him that a brief message was coming, but I’ll never be sure whether this paraphrase of an early 20th Century baseball poem was ever read and its humor appreciated at Offutt. No one called me back to tell me I had made them laugh. My fantasy was that my epistle had arrived OK but got buried under reams of other weather data stacked on the floor behind the printer. I’ve waited thirty years to share my humor with the rest of the world.
Air Force target dates are important, and we made ours, so on June 22nd I flew home to Washington with my luggage filled with gay colorful robes for the whole family, dolls for the girls, and Samurai swords for the boys.
Back
to Cold Fronts Table of Contents