PREPARING FOR ESCORT ACTIVATION

With the coming of ESCORT, the Data Processing Department was re-designated Computer Services, Bill Wolf continued as its manager, along with his “Lieutenants” Duane Pedlar and Fred Voth. His added responsibility was to insure all aspects of the new system were identified, planned, executed, and tested – on time, on budget, and reliable. He did.

It is noteworthy to ponder the full range of tasks to be completed prior to Mr. Sweets publicly announced ‘cut-over’ date. The command was, “Have it done, done on time, expect fate worse then death - if late”.

Major parts constituting ESCORT are;

Computer hardware (mostly in MSP) to house data necessary to process agent quires

Computer (programs) software to make the hardware useful

Agent terminals to access the computer

Data network linking agent terminals and computer.

Tasks were plenty; a whole book would be required to cover ‘all’ details. The more major were;

Ordering of central/remote site equipment and services

Staff acquisition/training of computer operators, network operators and programmers

Computer room preparation and hardware (inter-connected boxes) installs

Data network creation

Agent terminal installs

Development of NC unique requirements (100 were identified as needed)

ESCORT activation – ‘cut-over’.

Network and agent terminals

Over 500 new computer terminals (agent sets) were required at each and every of the 160 NC locations within the 12 state system. The net of this task was the timely installation of at least one keyboard/hard copy 1977 (neat machines, heh!) and a Sanders stand alone CRT in each NC Station (some after ESCORT was initially activated), 2915 CRTs in the 3-CROs and Sanders CRTs in a number of non-station locations. NC was the first airline to have a CRT installed in each of its stations. This permitted everyone equal access to ESCORT. Imagine the enormity of the physical facility planning and ‘bird-dogging’ of vendor construction required for wiring and installing all those new agent terminals.

Concurrent with terminal installs, an equally daunting task was creation of a new technology data network linking them to ESCORT. This required almost 20,000 miles of ‘hard’ wire. A simple task it was not, getting those wires from the end of telephone poles into each unique NC building to the specific terminal location took planning and work. From the telephone pole to MSP required intense coordination with AT&T, who bills monthly for each circuit allocated to NC – in use or not.

Network costs were significant. An added task was the coordination to de-activate the soon to be obsolete teletype network. All timed to meet the not distant cut-over date. Leo Finley, a 1955 YIP (Detroit/Willow Run) SA, later PIR (Pierre, South Dakota) then BTL (Battle Creek, Michigan) SM (station manager), was graced with the task. A task likened to unraveling a bowl of spaghetti!

Another challenge was in the CRO’s using 24/7 the Eastern Airlines contracted UNIVAC reservation terminals. The change over to ESCORT CRT’s could not disrupt ongoing business. The planning for de-installs, installs and agent training, all timed to meet a specified ‘cut-over’ date, was coordinated by John McElroy, formally the CHI Regional Supervisor and MKE training supervisor.

Agent Training

Training was required for Agent use of ESCORT functions. The majority of former agent procedures were changed; ‘stubby’ pencil work would be severely lessened. Agent inputs to make ESCORT perform the desired result were of a very precise fixed format. A self-teach training PIRT (Programmed interactive realtime training) program was developed at Eastern Airlines and provided at ‘no’ cost to NC along with IBM Tech support to install in ESCORT and introduce in use. PIRT instructions are maintained by the NC Training Dept, its lessons available for simultaneous agent training at all locations, at time of their choice. Training content was developed and administered by the Norm Taylor and Dan Breister staff.

Another tool available for training and storing all manner of data was DRS (Direct Reference System). Data was entered by the ‘owning’ entity, indexed by topic and readily accessible by agents. DRS programs were used to enter, store and receive all manner of information. The DRS System was written by Eastern Airlines. In a reflection of those pre-deregulation airline days, when the NC need for such a system was recognized, after phone calls to Florida’s Eastern Airlines, they immediately agreed to GIVE a copy of those programs to NC, and even to have one of their Eastern IBM System Engineers travel to Minneapolis, and at no cost to NC, help install the programs and provide instruction for its use!”

Dan’s training staff, Duane Hutchens, John Heider, Rogel Loebel, and Marv Obarski also prepared for agent use, a “Prompt Manual” with a ‘quick-reference’ page for each of the many ESCORT transactions. They also maintained DRS (Direct Reference System), which contained many types of information not found within other sources. How they were able to complete their task is a mystery to me – but they did.

The making of ESCORT Programmers

Another indication of North Central’s forward looking executive leadership style, was the staffing of ESCORT. They were committing to $8+ million dollars in computer hardware to install a computerized airline system that was unproved and not in production use by ‘any’ airline. Their decisions were made in an era, unlike today, where computers were not in common use supporting all aspects of our lives. Key to any computer system is the ability to grow the system as changing needs dictate. But, given the enormous expense, they did not elect to bring in ‘outside’ skills, instead they elected to train and grow skills from their employee ranks.

While 1969 was the official ESCORT announcement, initial staffing began in early 1968. A majority of the initial study group members became the initial leadership. Next was the arrival of ESCORT “wanta-be” programmers

Fred Voth began his NC career in 1965 and was a member of the study group that resulted in ESCORT. He was given the ‘enviable’ ESCORT Programming Supervisor position. The task was simple; hire and train brand new programmers, supervise their program modifications, test programs exhaustively – over and over, and install the PARS software. Fred was a very nice detail guy with hidden toughness. Tough he had to be, since his staff was mostly made up of opinionated Ex-NC field agents - who had to be a bit different to take such a job. Only 1 of the 12 was ‘lost’, the balance bruised and abused, turned PARS into ESCORT.

On February 14, 1968 the initial three ‘to-be’ programmers arrived, ex-CMX (Houghton-Hancock, MI) SA Mike Falkner, ex-Milwaukee Res Agent Greg Knipp and myself, ex-MKG (Muskegon, MI) SA Skip Powell. Now an ex-10 year station agent, I began a 15 year career with the mighty soon-to-be “state-of-the-art, leading edge” computer system - ESCORT. Our ALEA union seniority protection vanished – it was now “sink-or-swim”.

Additional ESCORT programmer trainees arrived during 1968 and 1969. Among the first to arrive was Jack Brown ex-GRR (Grand Rapids) SA and PTK (Pontiac, Michigan) SM, the smartest man and “hottest” technician I ever knew (also, the only Navy man I know who trucked his boat from Incheon, Korea and left it on the shores of Chosin Reservoir and hiked back south to “friendly” lines).

Also arrived were; Ex-Station Agents; Ed Helms (Ashland, WI), Dave Engelsjerd (Winona, MN), Harlen Lea (Aberdeen, SD), Paul Ward (Kansas City, MO), Ron DeGroot (Green Bay?), plus ex-PSGR Service Agents; Dennis Bowen and Sue Reed along with one fresh out of technical school, Sharon Schmidt. This completed the ESCORT programming staff of 12, available for the early 1970 ‘cut-over’ date. Technical training for the final nine mirrored that of the first three.

The staff grew to 33 by 1979, yet including more ex-NC agents. As others followed, they also become keen inventors and leaders in developing ESCORT software. Some of those were; John Wilkinson, Stan Scheif, John McElroy, Bill Berg, Jim Vartmann, Sandy Renner, Harlen Lea, plus significant others.

On February 1, 1968 we three reported to the mysterious DP Manager, Bill Wolf in an office surrounded by funny looking boxes, said to contain computer ‘stuff’. His judgment was already suspect by his nervous selections for the prototype clutch of ‘newbies’. We were orientated as to our future life and General Office permissibilitys. Following was a razzle-dazzle tour of the former “Redtail” (Northwest Airlines) HQ edifice. Next, we were turned over to our new leader, Fred Voth and sent to our new quarters, the blockhouse (former NC engineering) building located between the Maintenance HQ Hanger and the Air Force NCO Club. As a former military NCO, the NCO Club’s purpose (5 cent beer, 25 for higher paid customers) was clearly understood – and its offerings utilized.

We three constituted the complete ESCORT Programmer Staff for the immediate future. We may have been expert at completing O-24’s, 3x5 Res Card’s and dispatching DC-3s, but this new stuff was quite different. Closely watched by our new boss and his assisting IBM Experts John Southam, Dave Olshanski and Walt Thomsen, and several other striped tie and wingtip shoed experts, we progressed through our technical programmer training.

Some training was self-teach, most was off-site with IBM instructors, during which we were expected to pass written tests – ghezz. Guess what we did on Saturdays and Sundays? This difficult and strange training was made much easier to ‘swallow’ by head IBM’er (and Steeler fan) John Southam, saying often “Well, suggest something!” He frequently held our hands. IBM’er John became a long term member of the Computer Services team. His advice, often detrimental to his employer, always proved advantageous to NC and me. His ‘make-it-happen’ talents were often under estimated, but not his Viking pre-season football or smelt fishing expedition antics.

Some months later we were ‘pronounced’ competent rookie programmers – barely. Here I learned, and perhaps others yet wonder; “What’s a Programmer?” Easy, Ha! They string a series of computer instructions together to perform a specific function. Tools were; flowcharts, coding pads, a language reference card and pencils with BIG erasers.

We were training to be BAL Programmers. BAL (Basic Assembler Language) was also called ALC or assembler. BAL is rarely used by typical modern day programmers, nor do they know of its existence, much less how to utilize same. They use a much higher “level”, quicker to learn and write languages which are massaged by other programs to produce executable computer and/or PC instructions.

BAL is a very basic low level series of coded instructions sequenced to satisfy customer requirements.

Computers execute, or try to execute, ‘exactly’ what the programmer writes. If a computer input can not be processed by the program, the computer aborts the process – at times killing the complete system. This I know from experience.

This means that the executing computer program must be prepared to process each and every agents possible entry. This includes any kind of ‘odd-ball’ situations such as; Leap Year, standard/savings time, time zones, 28Feb, crossing to a new century, invalid garbage agent inputs (Ex: 29 Feb, 31 Jun) and other exceptions. Other examples; flights whose next stop arrival time is earlier then its previous departure time (such as a 15-30 minute leg between EDT and CDT stations), International dateline (yes even ESCORT), math calculations (rounding issues) and more.

Programs must be able to anticipate each and every imaginative agent input. Believe me, experience has proven there were plenty of imaginative agents who tried to ‘trick’ the system. We did get caught ‘short’, I don’t want-to-say often, but caught we got. Program exactness was computer enforced. Even our super fast computers would get ‘overflowed and kilt’. Those station agent terminals had lots of buttons; some when pushed, send a message to the computer. Clever agents (we caught some of ‘em) would rapidly push those buttons (I suppose while eating lunch), over and over. Resulting messages to the computer could and sometimes did cause system outages. When identified, ‘cleverer’ programmers nixed future abuse.

When writing a program, the programmer always had to be mindful of the hundreds of pre-existing programs, insuring no conflicts or computer processing rule violations. Not an easy task, failures were visible to not only the computer, but many humans – who did not mind making mention of such.

Requirements for writing programs had to be specifically stated, all waffling eliminated. Perhaps the most difficult phase of programming was ‘nailing-down’ specific inputs, outputs and processing requirements, especially when multiple departments were involved – this at times was tenuous. Not infrequently, the gauntlet was tossed on the table with the utterance, “If you can all agree on “it”, “it” can be programmed”. And would you believe, at times after ‘it’ was programmed and fully in use, the telephone would ring with the question, “Why did you do “it”. Thus, good note keeping was important for job retention.

Once requirements were clear, diagrams (flow charts) would be prepared illustrating how the programs were to be organized. Next, was writing the ‘human’ version series of BAL instructions, following the flowcharted plan. Then, the programmers work was sent to the keypunch ladies, who (in those days) returned a stack of IBM punch cards. The cards were next tendered to a computer program that compiled them into computer executable instructions. Almost always the compiler identified logic errors, typically readily correctable. Errors were often mine, BUT also often a keypunch error, which is why I always tried to use Ellen – easy on the eyes, proficient and a good crystal ball reader.

Next was testing the program on a mini-sized system, pre-conditioned to somewhat mirror the live ESCORT system. By this time, the Training Department was providing agent training about “Its” use.

Elapsed time for completion of these steps could be weeks to years - dependant on degree of difficulty and project magnitude. Example: To invent the ESCORT Weather System, over 6,000 programmer hours were expended to plan, program, test and install the 20,000 plus computer instruction programs (about 8 man years).

Once our basic BAL training was pronounced complete, we spent several mid-summer 1968 months in White Plains NY. There, IBM Instructors taught (often over our heads) the rudiments of PARS. Then, back to our MSP hands-on training. One of the initial tasks was the development of program modifications designed to suit NC management needs – and there were many, some never done. This was followed by exercising and testing the many agent functions delivered from IBM. This phase identified errors and problems, most resolved locally or some referred back to IBM.

SABRETALK was a Program Language, developed jointly by Eastern and American Airlines. Its prime purpose was said to reduce programmer training time and reduce program development time, compared to the basic BAL language. Perhaps these benefits were valid for those large shops having hundreds of programmers, but our shop had, at max some 3-dozen. I felt the benefits within our staff, considering their necessity to become proficient in another tool, would be rather ‘skimpy’. Back in the 1970s computer hardware “cycles” and capacities were expensive. Using SABRETALK, their program execution would consume more cycles, thus making the ‘skimpy’ benefits of Sabretalk even ‘skimpy’er’. A controversial issue, it was not used at NC during my time. Of course, its inventors trying to market its use loved it.

Testing – turning PARS into ESCORT

By late summer 1968, programmers were ready to take delivery of PARS software from IBM. It arrived by US Mail on a half-dozen reels of magnetic tape, along with a stack of instructions and pre-identified ‘fixes’ IBM had not yet found time to install.. The number of programs exceeded 1300, plus serious sized communications (message switching) and control programs. We were also graced with some thirty plus, 3-ring notebooks full of mystery documents.

With PARS programs now on hand upon office shelves and our desk tops in the ole engineering block building, it was time to get’em computer installed. Time was pressing and our new GO computer room was yet not a reality, thusly program installs and testing was done on a downtown MSP IBM computer – at night, when ‘they’ were asleep. During this phase, our very own written programs were tested. The net was lots of “darkness of night” work. When that work day (night) ended, it was re-hashed along with consumption of ‘Juicy-Lucy” burgers, appropriately watered-down to ease the trip home.

In addition to programs, lots of NC unique data had to be prepared and tested. This included a profile of NC itself, each of the Other Airlines, each of the 120+ NC locations, and all those other cities with which we would do business; such as time zones, minimum flight connection times, multiple city airport relationships and available airport services..

Along with these profiles, flight schedules had to be coded and keypunched, along with a number of Other Airline flight schedules. Keeping airline schedules current was a twice monthly chore. Considering that NC flight departures alone exceeded 200,000, this was a sizable task, even tho initially the number of OA flights was limited. The number of IBM punch cards necessary for this startup phase exceeded 8,000.

Each NC flight typically required coding an average of 10 punch cards, 5 or 6 for OA flights. The cards (about 6,000) were sorted, listed, proofed, and then loaded to the system. Added cards were prepared to move passengers from canceled or changed to new flights – a long process. Processing of schedule changes proved to be a headache. It was overall slow, requiring too much system down time, and too many program bugs. The NC Schedule guy, me, assisted by IBM’er Bruce Gobioff expended many dark hours to resolve. Some took several years before the majority of downtime to load the ever changing flight schedules was eliminated.

To provide the unique networking support for the ‘stand-alone’ station located CRTs and printers in locations outside the three CRO’s, a pioneer non-IBM system was required. It was SANDAC, Inc. Braniff Airlines was using a comparable SANDAC system, thus this was not totally a pioneering task. But, retro fitting this system into ESCORT processors and software did require extensive effort.

Exercising PARS and our ‘hands-on’ testing of our very own programs was a very important step in our technical training. We also had to incorporate the many ‘always arriving’ software fixes coming from IBM. During our testing, we also uncovered a number of ‘fixes’, which we documented and returned to IBM. The benefactor to all these ‘fixes’ were those airlines later taking delivery of PARS.

It was an equally important learning process for newly trained ESCORT computer operators. It was they who would operate the system 365 - 24/7. Operations Manager Duane Pedlar, Supervisor Dave Olson, Sr. Operator Mike Knudson (RIP), Sr. Operator Tom Krieling and super IBM’er Bill Farrar prepared the ESCORT operator procedures. Those procedures had to cover in precise detail, each of the many cyclic tasks required by the operators to keep ESCORT healthy. Such procedures had to be specific, detailed and readily understood. Over time, many changes were incorporated, based on growing experience levels.

The downtown Minneapolis experience prepared operators, programmers and procedures for the next step. We had begun with PARS- after many, many night time hours, we had turned it into ESCORT. We were now ready to move into the new GO computer room and the pressing March 1970 ‘cut-over’ date.

NEW MSP-GO AND COMPUTER ROOM

The Computer Room was neatly located off the new headquarters main entrance. Two walls of the room were full floor-to-ceiling glass, inviting GO Guests to admire the color coordinated red and white boxes and spinning tape reels along with computer operators keeping all tidy and operational. The glass “fish bowl” configuration was the contribution of Charlotte Westberg, the assistant to CEO Mr. Hal Carr. Who would defy Ms Charlotte her dominate applied wishes! Thus, per her guidance, the windowed Computer Room became an attraction to visitors using the NC Headquarters main entrance. The windows lasted until the age of ‘disaster planning against intruders’ arrived.

Typically, computer boxes were painted IBM Blue. Ours were converted to Red. Why? Manager Bill Wolf thought red was more bright and cheery, a more appropriate attraction to those entering the headquarters main entrance - AND it was Bill’s favorite color. White complimented the red to provide the computer gods some hope for purity among its operatives.

Along the way, “experts” informed us that computer chips would soon be sized to allow them to pass through the eye of a needle. Well that may be true, but that ‘needle’ required many supporting boxes, wires and space. BUT, perhaps I laugh too soon, since in my little desk top PC is 1 and ½ million bytes of memory – size; apprx 2”x 6” x 3/16”.

While making ESCORT ready, the new General Office was being built. Even though priority was given to its early completion, the Computer Room was not yet entirely ready when truck loads of computer boxes began (had to) arriving late 1969 to meet the ‘cut-over’ date.

Almost ready, but not quite, it was essential to proceed installing the many computer boxes, getting them ‘wired’ together and across box diagnostics ran. But since the rooms’ environmental systems were not ready, the full complement of systems could not be tested because of their heat buildup. Overheated computer gear can quickly become scrap iron. IDEA: Borrow the units used to cool aircraft. A temporary window for duct pass-through completed the solution – it worked.

NOTE: When the computer room boxes began to arrive on site, construction for the new facility was yet on-going. The construction workers therein worked under their union’s rules. Watching these boxes being installed by Tom’s IBM Tech’s linking the boxes with electrical and cable connections, the Electrical Union Members thought those tasks were within their ‘bailiwick’ and demanded that work! Solution: Tom’s team assembled the components in a truck van outside the building. Moving assembled and linked boxes from the truck to the computer room was dicey – but done.

IBMer Tom and Jim for years considered NC their home and themselves part of the NC Team. Their job was to maintain and the timely (immediate) repair of failing hardware components. They were effective ‘horse-traders’ when a failed component was needed but not readily available; they would find a way – via normal or outside of accepted supply channels.

As 1969 ended, IBM’s latest and greatest computer boxes were installed, or near so. Box installs nearly filled the room. Hidden beneath the 12 inch raised floor were miles of coax, cable, coke bottles and who knows what. Computer room expansions were to come, as did ‘bigger/faster boxes’. Attendant to this was a large basement room (maybe 20’ x20’) filled floor to ceiling with batteries through which electrical current to computer boxes flowed. Their purpose was to ‘even’ the flow of electrical power, thus shielding ‘tender’ computer boxes against power spikes. They also provided a short period of un-interrupted electrical power until rooftop generators came online, during external building electrical failure.

Early 1970 training, testing and double checking was intense. Were agent set installs on time? Was the network operational, training of 24/7 computer operator staff, reservations and station agent training progressing, and were programmer testing and fixing of identified (known) problems complete? Scramble – fill the holes.

ESCORT ACTIVATION (Cut-over)

How to ‘cut-over’ ESCORT and abandon existing systems was a major management issue. Should the cut-over results turn nasty, the impact on passenger services and flight operations were thought to be significantly negative, not to mention agent confidence in the much heralded system. Earlier airlines had opted for a phased (a little at a time) implementation, station by station or other partial activations. A phased cutover was considered to complicated, since a part of the airline would be operating with one set of procedures and the remainder another. Thus, a gutsy decision was made. ESCORT was to be a ‘flash’ cutover following a system wide ‘toe-in-the-water’ shakedown while current airline procedures remained in place.

Stage 1: On February 1st, 1970 it was an overnight ‘cut-over’ of the message switching system, while permitting previous agent, passenger and flight handling processes to remain operational. Usage was limited to the sending and receiving of manually prepared messages, very similar to their existing teletype messaging capability.

Otherwise, it was ‘closed-within-NC only’ permitting agents to exercise their new passenger/flight handling skills and to continue their education using the self-teach training PIRT and DRS systems. An important side benefit from these activities was assurance that all newly installed terminals and associated ESCORT access boxes worked as intended. Considering the magnitude of work completed to this point and the numbers of different NC and vendor skills involved (pig & bacon) - it was a success. The few identified issues were readily corrected.

Stage 2: Two months earlier then the earlier announced date, overnight ESCORT was ‘flash cut-over’. On March 1st, each of the almost 400 NC agent terminals had less than 3-second immediate access to 1,300 NC flight arrival/departures, 3,800 connecting flights of 21 other airlines, along with their accurate seat availability status. Here I must comment; the “School-of-Hard-Knocks” teaches: “of those folks not in-the-arena, one voice will always arise, that they could have done it better and quicker”. I do not recall hearing any such voices on this occasion.

NOTE: The 1967 Evaluation Report recommended that ESCORT be cutover by May 1970. The cutover date was advanced to February/March because the original date conflicted with Easter activities.

The head IBM’er commented; “I’ve heard of cutover delays, but never of a ‘moving up’ date!”

For NC it was indeed a gutsy decision; many folks were needlessly uptight and holding their breath, kinda reminded one of a summertime Wisconsin bull with a tightly held tail in a fly strewn barnyard. Over night, one minute everyone was denied the ‘old-ways’ and the next, everyone operational with new computer tools. Come morning, passengers and flight crews got their almost hot coffee from a smiling “Stew”. This was quite an achievement. The entire computer service staff were new to the system. ESCORT programmers were just recently SA, PSA and RES Agents, trained from scratch.

The computer operators who ran the 24/7 operation were newly trained. A ½ dozen partner IBM’ers were instrumental to success, ‘lead’ by hard driving (he would shake ‘heaven and earth’ when warranted – no problem was too small or too large) John Southam, his key NC loyal aides were (there were more, but none more experienced with the system), Walt Thompson, Dave Olshanski, and Bill Farrar. Not to forget IBM’ers Tom Bedford and Jim VanKuren who ‘strung’ the computer room boxes together and tested their work.

All-in-all, events went smoothly; sure there were a few problems, most all resolved quickly. Completed were many, many tasks required to ready the ‘full’ system; computer room, hardware, network, programs and training for its March 1970 ‘cut-over’. Considering that work had begun only 2 years earlier, it was a significant achievement. More so, when realized the work was done mostly by NC and IBM ‘rookies’ to such work, plus the involvement of many coordinating diverse organizations, it was almost beyond comprehension.

Yet to this day, I’m amazed that such a small number of ‘newbie’s’ to such an endeavor, across a large range of skills and tasks, brought their work to a concerted end on schedule within a severely constrained time frame. Today in the ‘computer age’ of 2008, you would have to search hard and long to find knowing folks who would commit to such a schedule. I suppose the whole bunch of us were just dumber than rocks! What can be found, are many experts who ‘just-know’ – no way, it’s impossible.

Editorial: Following my NC days, I spent an additional 15+ years ‘putzing’ with similar systems where simpler activities took longer periods of time and much more manpower. Some had (have) upward to a couple hundred staffers and programmers who typically take more time to do less. One event stands out. As you might know, the “redtail” first decided to use ESCORT, later reversing that decision, to use their long in place UNIVAC (later named UNISYS) system. When that failed, they concluded arrangements to use an ESCORT like system, remote from MSP.

Later that multi-airline used system was relocated from Kansas City to Atlanta. In concept and reality, this was a much simpler task compared to ‘cranking-up’ a brand new start up system with all its users ‘brand-new’ to the system. Users of the ‘moved’ computer system would not suffer any ‘computer’ use impact; perhaps not even know its location had moved overnight some 800 miles. That relocation effort consumed dozens, plus dozens and more dozens of long experienced expert technicians. CONJECTURE; Perhaps the elapsed time requirement was really due to vacillating management’s lack of success confidence, maybe simple resistance to the move or perhaps too many experienced technicians with spurious ‘what-if’ concerns? – Elapsed time about 2 years. As Grand Daddy often said, “More is sometimes less”!

copyright 2009 by Coston "Skip" Powell

 continues next page > > >