TROUBLES / PROBLEMS

I know I’ve often used the word “tested”. No apology from me. Ya ain’t lived until you’ve stood within a circle of dancing red-eyed bigwigs, with telephones blasting, explaining the ‘why’ of an ongoing system wide computer outage - while not yet really knowing the specifics. Oh yeah, did I say, agents and planes were awaiting their paperwork - almost forgot that. All followed with several days of explaining ‘how to prevent’.

Realizing that ESCORT was a pioneering system, as was its PARS parent, problems were bound to occur. To this end, a 24/7 trouble reporting function was established – and it got used. True, at times, a ‘glitch’ disrupted part or full ESCORT service, but when that happened, immediate 24/7 attention was given. I’d be unable to identify all those ‘glitches’, even all of those for which I had close knowledge. For sure, all management from Mr. Carr downward knew any ‘glitch’ impacting passenger/flight operations.

Should one ponder all the bits-and-pieces of circuitry, hardware and software making up the full system, extending from the most distant station to MSP, it’s a miracle there were not more ‘glitches’. We all knew an out-of-service agent cared not what or where the problem was – “just fix it”. Often the problem was AT&T circuit failure. Some were computer room ‘box’ failures, fixable only by a replacement box. Many replacement spare hardware parts were kept on hand and timely installed by our always onsite IBM technicians. Should a needed part not be on hand, they’d find one, no matter how wide the search.

Software issues required programmer fixes who were on call 24/7. I received many middle of night problem calls. Most were resolved while my head was still on the pillow, some - would restart sleep, too many others a trip to work. It was not uncommon to be questioned about overnight calls. Nor was it uncommon to not remember some overnight calls. Nope, there was no OT for the programmer staff – zip, nada, none.

At times, long-long hours were necessary to identify problem cause, develop and install a fix. Some problems had folks working several twenty-four hour days non-stop – all the while phones rang non-stop. How sensitive were central site computer systems? Consider that smoking was dis-allowed in the computer room BECAUSE ‘smoke particles’ could lodge in electrical components. I smoke cigars. Overall, some problems were quickly fixed, others less quick. Eventually my cigars were banned.

At times, unusual agent activity caused a unique system failure. Typically, the system was quickly restarted. Some problems were crazy. Example; Each time a DTW agent hit a particular key on his 1977, ESCORT was killed, and immediately restarted. Again and again the key was hit, the results the same each time. This went on for awhile, till we figured the cause and killed that 1977-or was it the agent!

Another early problem was the result of agents using their 1977 (keyboard/typewriter) to write a (biz/personal?) ‘long’ letter. The method by which 1977’s sent data to ESCORT, resulted in depletion of resources – the issue was ‘fixed’ Another problem resulted in failure of 1977 terminals to print the number 5. Not a nice problem, in particular for flight papers headed for airplane pilots, not to mention FMR’s, Fuel Data and Weather. Once identified, it was fixed. More often than not, time to identify the specific cause was the larger portion of the time to implement a solution.

Another interesting pre-cutover problem surfaced – rather quickly. It was identified that the ‘time stamp’ on messages was always off by exactly 24 hours. A ‘nail chewing’ fix was thought to cure the problem and it was installed. OOPS, while not immediately apparent, the result was seat inventory records and passenger PNRs and Name Lists differed by “one” day. This required a full hours long data base restore. Not a major-major issue at the time since the system was still in training mode, but it was a major lesson.

This ‘one-day-off’ problem surfaced in a MSP-GO hallway, when a CRO agent asked, “Why is it when I book a reservation for one day, I can only retrieve it using the following days date?” Whoa, not all fixes work as expected and quick installing an obvious fix to get the ‘show back on the road’ could ‘bite’. It was not uncommon for such an innocent question to result in the identification of a major developing problem. Agent reported troubles were like a presidential election, we don’t like’em, but we got’em.

I’ll not even mention the OMA (Omaha) agent who got so disgusted with his 1977 that he ‘dashed’ it upon the ramp concrete. We had a ‘hated’ 1977 in the programming area, his point, tho nasty, was astute.

In a later year, new tele-ticketing functions were installed. ESCORT would automatically dial a pre-stored telephone number to deliver overnight Tele-Tickets. The problem was twofold: #1-The tickets disappeared and #2 -A little ole lady in Detroit kept getting late night telephone calls. The stored telephone number was wrong.

Another ‘glitch’ category was failed software. Software testing was exhaustive, but covering all possibilities was challenging. Nonsense, you say! Later while working at another airline, the computer failed. Cause; a program installed 10+ years earlier killed the system. It was unable to handle a winter time MGL Calculation using temperature exceeding -49 degrees. Ghezz, you think the MIA folks cared!

On a Friday close to 5pm, uncontrollable heat buildup required computers to be shut down. After much scurrying about, unwanted assistance and ringing phones, the cause was identified by an electrician. The fix: Tighten the lug nuts in the electrical switch boxes. Over time, electrical heat expansion and contraction caused them to loosen, bingo - power interruption. Later, within days of my new employer start date, that experience made me a hero. For weeks, intermittent electrical failures were killing their system. I hired an electrician to tighten electrical lug nuts – problem resolved; I was a ‘newbie’ hero. Now, my home electrical boxes get checked.

In the mid-1970s, the biggest ESCORT problem ever, occurred during my time. The database had been trashed due to an operator activity gone awry. The resulting corrupted database prevented its use. Hours passed before the specific problem cause was identified. The culprit, a 3 word computer command “almost” exactly like the one intended, found buried in a stack of computer logs. The problem finally understood, the fix was a tough one, never previously necessary on the operational system.

The fix was a full database restoration, beginning with the 24 hour old data. A process never before executed. Testing at earlier times was discussed, but the system outage time requirement prevented it. This was a lengthy process, during which the system remained out of service, plus hours of manual data fixing was required by the full ESCORT staff and a number of folks from CRC, MSP-CRO and others. After some 36+ hours, the system was again made available, tho some data remained “shaky”. Folks looking in the “fish bowl” lobby windows that day, “saw no Heroes”.

One side benefit of this long problem resolution was that at Mr. Sweet’s invitation, John Southam was returned to the NC Account as the lead IBM’er. John’s get it done, find a way attitude was always a propellant to getting issues ‘knocked-down’.

Well, ya caught me, I lied. There was a bigger problem when Southern Airways (SO) was ‘cut-over’ to ESCORT from the Eastern Airline system in 1979. Those SO locations would surely recall our failing. Planning and testing the SO move to NC was routine, a pre-shakedown ‘cut-over’ was successful – the system was “frozen”. A week later, the ‘cut-over’ during early morning hours looked good. That is until it was discovered that SO stations, unlike the previous week ‘shake-down’ test, could not access ESCORT - NC stations could.

SO was getting their agent services from the Eastern Airline system in MIA. The SO network was routed to MIA via a network concentrator located in ATL in preparation for linking SO locations to ESCORT in MSP. A new high-speed link was installed to link ATL to MSP at cutover time. Its testing was successful. Hours after cutover, the problem was isolated to the new MSP-ATL network link, but the specific fault remained evasive. More hours later, in a long oppressive rehashing meeting of senior computer muck-a-mucks, an outside vendor finally spoke up. It just happened that following the ‘system-freeze’ date, they witnessed a network change, done by an individual sitting in the meeting.

While no admissions were forthcoming, soon after the meeting, the problem was corrected. The visibility of this event to NC/SO management resulted in a cloud over ESCORT that never vanished. Multiple varying tales have been spoken about this problem. My version is first hand, I was there, in the trenches, involved like the “pig and bacon’, unlike the “chicken and egg”. As Paul Harvey would say, “And that’s the way it was”.

The Hughes AirWest switch from EA (System One) to the Republic Airlines (ESCORT) in October 1981 was ‘picture book’.

Both computer operators and programmers had to deal with a number of various problem issues, most under duress, most timely resolved. Many lessons were learned and hopeful preventatives put in place.

ESCORT GROWTH - March 1970 to 1983

Quickly after ESCORT was birthed, agents became proficient with its functions. Reservation (PNRs) creation, Name list (PNLs) retrievals for PSGR check-in, posting of departure/arrival times to FLIFO, and sending/receiving messages became routine activities. Together with a number of NC unique enhancements, all these were oriented around PARS, a reservations system.

Early on, NC Management realized that ESCORT was producing employee productivity and cost benefits. This started the stampede for more computer functions – more enhancements.

Many new functions were installed. I’ll name some of those added during my 15 year ESCORT tenure. Many of these were pioneering efforts. Few were purchased from outside sources. Some were sold to other airlines. With each new ESCORT function, it grew to be a full function airline system.

The principal mission of ESCORT programming staff was to provide new system functions. After several years I was privileged to become its Programming Manager. A number of programmers worked their way up to Senior Analyst and supervisory positions making my tenure much easier, e.g.; Jack Brown, Stan Schleif and John Wilkinson.

Improvements made were coordinated with the friendly folks from departments headed by Marv Freund, Ken Hubertus, and Joe Sims. Dan Breister’s training folks were our constant companion and advisor. All wanted more; our small staff gave’m lots.

The real fun part of preparing new ESCORT programs was getting specific requirements from those requesting same. Often (most always) multiple corporate departments had ‘differing opinions’ about particular issues. At times small amounts of ‘heat’ resulted within excessively long discussions. This was particularly true after several years of ESCORT use and the growing numbers of “programming experts” within those departments. True, those ‘experts’ would not, or could not, perform the work, but, well, their advise was ‘ahh’ golden. Always, relationships were more then cordial.

The bottom line was, after many meeting hours, specifics were rare. At times, working to get a single opinion, I was prompted to utter, “If’n all you folks can agree exactly on what you want, we will make that happen”. That they didn’t always do, but we did. Our ‘tea leaf reading’ skills worked wonders. Thank goodness, the core of our staff was ex-agents with strong understanding of the non-GO business end of NC operations. AND, we were not shy about going directly to folks ‘in the field’ for their opinions and guidance.

Computer Hardware and Network Upgrades

Over the next few years, periodic “computer horse-power’ increases were necessary. New programs gave Agents more ESCORT capabilities. Over the first 10 years of ESCORT system use, passenger numbers increased almost 200% and the number of employees almost 70%. Increased use demanded faster computers, larger-quicker data storage, and upgraded data network speed and capacities. Such hardware upgrades occurred several times keeping pace with IBM’s latest and greatest. Concurrent with hardware upgrades was the ongoing work to improve program processing efficiency to minimize need for upgraded computer boxes. All of this was driven by the guideline to keep agent response time under 3 seconds, the majority within one second.

ESCORT collected data (flight times, FMR’s, etc) was increasingly needed in other systems. Initially such data was ‘hand transported’ to adjacent computers. This work was soon replaced by ‘in-house’ invented software to electronically real-time pass data to other NC management systems via min-computers. Later, additional ‘in-house’ invented software along with new technology was developed that enabled both the sending and receiving data between such systems as SCEPTRE.

New/changed programs (brief description with approximate date) – Plenty of lesser scale unlisted.

As you peruse the following you could see a number of ESCORT additions to assist airborne flight operations. During my ESCORT years, I was also an Army Officer doing Reserve duty at nearby Fort Snelling. Thusly, at times, I ended the evening at the Officer Club, where often NC aviators also ‘rested’. As you might deduct, their exploits were often the principal topic(s) of discussion. While always having respect for their skills, I would inject my perspective (to wit); “Did you aviators ever notice those ESCORT provided papers you clutched while boarding your aircraft. They provide your departure time, destination, air route, fuel, weight and more”. I loved it. Elbow shiners often changed the subject.

1970-1975 Message Switching: A number of agent functions still required ‘paper’ copy, mostly for passenger check-in (PNLs) and flight departure papers. Initial delivery of hardcopy was very slow. In-house software improved the control of print between the computer and printers. The result; much faster delivery, a 50+% print time reduction – whew.

1970 Flight times: Each flights “out, off, on, in” times along with a/c number were now inputted to Flight Times. As such data was entered, it was sent to down line stations, serving as a current flight location status. This data was also passed to Maintenance management systems. The NC flight schedule was used to determine any exceptions to schedule. Later it became the prime source to update Flight Following for Dispatchers.

1971 Other Airline Flight Schedules. Replacing paper flight timetables and manual preparation of punch cards, we began semi-monthly electronic loading of other airline flight schedules direct from magnetic SCIP tapes. These tapes were received from Reuben H. Donnelley, the long time publisher of the obsoleted OAG and QRE. By 1977 all North American scheduled airlines, plus some international flights were maintained in ESCORT. This permitted NC agents quick ability to access flight schedules across multiple connection cities to anywhere USofA, along with their constantly updated seat availability status.

1972 Flight Release: This system authorized a flights operation; its a/c type, ship number, fuel, route restrictions, alternates, any MGL restrictions and other operational data. Content was created using both computer stored and dispatcher inputs. When activated by the flight dispatcher, it was distributed to pertinent stations for captain concurrence.

1972 Flight Following: A flight dispatch system, provided to each flight control dispatcher the current status and location of all flights operating under their control, both active and pending activation flights. Screen updates came from FLIFO and Flight Times. Later split screen CRTs provided dispatchers with a constantly updated display of their flight and a 2nd screen for related tasks. Joe Sims was happy – for awhile!

1972 Weather System: Hourly Aviation (SA) WX, Terminal Forecasts (FT), Winds Aloft (FD), NOTAMs (NS), Area Forecasts (FA) and more were collected realtime direct from the Weather Service computers as it arrived in their system and immediately stored in ESCORT. Using the flight release for alternates and NC flight schedule for downline stops, only specific WX required for a flights operation was crew delivered.

Ergo, less print time, less paper in the cockpit. After much mutual arm twisting with Capt Dick Brown, it was deemed “golden”. Moreover, any NC agent CRT could retrieve current WX and/or forecasts, for any US or Canadian city.

NC was the first airline to integrate WX in their reservations systems. Thus, the governments Weather Service collection system had to change. NC computer terminals and printers could not handle those long in use “special” print symbols depicting cloud cover. It was our (Jack Brown) suggestion they be changed to; CLR, SCT, BKN and OVC. Would you believe that government agency adopted the change – quickly? This system was sold to multi-other airlines and remains in use to this day.

A new box, an IV Phase mini-computer was used to link the Weather Bureau computer to ESCORT. This was also an intense pioneering effort requiring the invention of new programs. The IV Phase communicated with the Weather Bureau in their ‘language’, converting it to a language protocol compatible to ESCORT.

Soon, another first when ESCORT electronically delivered direct to Weather Service Computers the NC Agent observed Supplemental Aviation Weather Reports (SAWR) WX. You can not lead, where you do not go.

1973 Fare Quote and Ticketing System (FQTK): This enabled agents to quickly price passenger itineraries, and attach the results to a completed PNR as it was being constructed. Initially, over 85% of the new ‘Quick” tickets could be entirely electronically completed; priced and printed within 3-seconds, compared to 3+-minute manual preparation. For this purpose, ESCORT electronically stored fares, routings and rules received from C.C. Squire, the long time publisher of the paper fares tariffs, whose use was now drastically reduced. The result was accurate priced tickets, per trip routings and rules.

Ticket pricing rules were prepared by the ESCORT Data Base Staff; Lucille Walter, Ron Rickey, Steve Brandt and Greg Knipp. Their task was laborious as the rules of airline travel were continually changing and becoming increasingly sophisticated as the airline business became more competitive.

Improvements were continually made to price more complicated itinerates. One change was to permit agents to manually pre-price tickets not computer price-able and attach the result to the PSGR PNR. This resulted in 100% of ESCORT Quick Tickets being fully priced when printed. This produced side bonuses later when ESCORT Revenue and Accounting, Ticket Agent (close-out) TAR and Cash Concentration systems were installed.

NOTE: Computer issued tickets during this era were known as “Transitional Automated Tickets”, printed as a single booklet multi-page 4-coupon ticket. It was much later when ‘machine speeds’ were adequate to support current day ‘Computer Tickets” which were printed one coupon at a time.

1974 Revenue & Accounting (Rev & Atg) Ticket Pricing: PSGR Check-in agents ‘lifted’ a tickets flight coupon for each enplanement. These were bundled by flight number and sent to the MSP Revenue and Accounting (Rev & Atg) Department. Maybe 50% of the ‘lifted’ coupons then came from tickets written by other airlines or travel agencies, tickets for which NC would not get paid until the issuing entity was invoiced. The first 3 digits of a ticket number identified its seller, ‘032’ was NC. To collect monies now owned to NC, Rev & Atg personnel would ‘price’ the lifted coupons, bundle them together by issuing entity and initiate (in effect) an invoice. Settlement of such airline invoices was handled via the ACH (Airline Clearing House), to include 032 coupon lifted by other airlines. This ticket pricing process was the major input to the NC Earned Revenue Ledger.

Coupon pricing was somewhat complicated. Often for travel across multiple airlines, a published ‘Joint Fare” was collected, a portion of which belonged to each airline. A room full of clerks was required for all of this manual Lifted Ticket Flight Coupon pricing.

An Idea was born. Since ESCORT already had a large fares data base used to write tickets, why not use that data as the source for Rev & Atg coupon pricing. New CRTS were installed in Rev & Atg, attached to ESCORT via new mini-computers. Software was invented to tailor their CRTs for their unique purpose. Labor required within Rev & Atg was dramatically improved. “Let it be said, let it be done” – and it was.

I understand in later years (after my departure) there were several attempts to replace this ESCORT function with an ‘improved’ system – failures resulted, I assume they had eventual success – had to, when ESCORT vanished.

1974 Prevent acceptance of bad Checks and Credit Cards: Passengers were increasingly using credit cards. ESCORT began accessing the ‘bad’ credit card file of major card vendors. This avoided bad card acceptance and associated charge back fees. Agents could receive $50 for each tendered bad credit card they confiscated. Likewise, a ‘bad check’ system reduced their acceptance by agents.

1974 Automated Ticket Agent Report (TAR): By this time, 100% of NC issued tickets via ESCORT were priced, including their form of payment. This system automated the ticket agent’s cash drawer close-out out process. Sales were listed and totaled by form of payment. Agent close out time was reduced by 50%.

This system laid the basis for the Cash Concentration System.

1981 Cash Concentration: Previously, collection of NC ‘money’ could begin only after each days TAR (Ticket Agents Report) arrived several days later, via Company-mail at Rev & Atg, This system electronically transferred end-of-day agent sales (TAR) data to MSP-GO accounting systems. Issuing credit card companies were immediately electronically invoiced. Local bank deposits were electronically moved to the central bank and credited to the NC account. The glitch with this project was an initial inability to get all ‘cross checked’ totals to balance, often off by one cent. Our U of Minnesota Math genius John Wilkinson soon realized and solved the issue by rounding totals based on the 4th digit.

1974? ARTCC (Air Route Traffic Control Center): Software was developed to electronically send monthly NC Flight Schedules to the Farmington, MN ARTCC. This avoided manual flight plan filings, unless change for a day’s flight was necessary. When Flight Control activated a flight release, ESCORT would notify ARTCC to initiate activation. The stored flight plan was also made part of the crew’s flight papers. The result was reduced administrative tasks, and cockpit work dealing with ARTCC.

1975 Flight - Weight and Balance: Using PSGR enplanements, Flight Loading (FMR), and Flight Release, this system insured proper aircraft load distribution within specific aircrafts’ configuration limits.

1975 Flight Departure - MGL (Maximum Gross Load) calculation: This system used the Flight Release, Flight Loading (FMR), and departure/arrival airport runway profiles, producing the allowable MGL.

1975 ESCORT – SCEPTRE Bridge: Hardware and software was installed to implement an electronic data bridge between the two systems. Plenty of new ‘in-house’ software was invented to enable ‘real-time’ exchanging of data between the two systems. In addition, the majority of NC terminals could access either ESCORT or the growing SCEPTRE system – administrative and maintenance folks included.

1975 SCEPTRE – System Computerized for Economical Performance; Tracking, Recording and Evaluation): ESCORT was not the only programming entity in Computer Services. There were basically three programmer groups, #1 Administrative Systems Programmers who for many years was developing payroll, ticketing accounting, cargo billing, statistical, financial, and administrative systems #2 ESCORT and #3 the newest group, SCEPTRE, staffed by ‘in-house’ programmers.

SCEPTRE was ‘birthed’ in 1972. Ten year NC Programming veteran Clive B. Schuelein was its manager, assisted by Ev Wright, Archie Lee, Connie Kouba, and other NC Staff. SCEPTRE was an IBM Information Management System (IMS) based systems. SCEPTRE would co-exist in a physical computer hardware system with corporate accounting, revenue and administrative systems.

I worked with ESCORT, tho my office was nearby, I was not immediately involved with the SCEPTRE project, nor can I claim much knowledge of aircraft workings. I include this SCEPTRE info, since it was an equally important NC entity and it might otherwise disappear. I will suffer the penalty of my ‘here-in’ and otherwise errors – no doubt.

The SCEPTRE staff worked principally with Section Manager, John Pennington a/c Maintenance and Engineering ‘expert’ along with Stores and Inventory Control Assistant Manager, Joe Williamson. They received assistance from IBM’er Bill Farrar. Together, requirements for the initial SCEPTRE system were developed, a herculean task. The extending of current methods were mostly shelved, pursued were innovative optimum methods. A dicey endeavor, opinions equaled the number of folks involved.

NOTE: John Pennington “Penny” described “a flying airplane” as; “a group of closely assembled parts”. The principal SCEPTRE mission was the management and maintenance of those ‘parts’. A sizeable task considering the NC $11 million 35,000+ spare parts inventory, plus spare a/c engines worth $12 million.

Principal SCEPTRE objectives; #1 Improving costs of a/c maintenance; #2 manpower utilization planning; #3 Improved scheduling of a/c parts removal and overhaul; and #4 improve periodic aircraft parts check times by timelier posting of elapsed time on the various a/c components. Expected result was reduced aircraft downtime, improved labor productivity, improved part processing and less paper work.

More effective and timely management of a/c rotables and expendables would optimize the costly burden of NC parts inventory. SCEPTRE connected CRTs at all maintenance locations, would enable ‘floor-level’ shop personnel quick access to manpower needed for aircraft inspections and required parts replacements. Source of time on a/c parts would be ESCORT Agent initiated flight times delivered from ESCORT real-time, across a new electronic ‘bridge’ to SCEPTRE. Its first phase was made operational in 1975. Initial results were ‘up-to-the-minute’ service record information on all aircraft and components, with required maintenance work scheduling - including Pilot Reports resolution.

SCEPTRE, unlike ESCORT, is a corporate system supporting not only maintenance operations, but requirements of finance and flight operations departments. As SCEPTRE became a ‘proved’ system, like ESCORT, the clamor for more function followed – they got it. A few of those add-ons’ were; Station supply ordering, FMR flight load data, frequent flyer – passed via the electronic bridge from ESCORT.

NOTE: At the out-set of SCEPTRE there were discussions; should it be developed for use on ESCORT or should an entirely separate technology be used. The decision was for a separate from ESCORT system using the IMS (Information Management System) and its higher level, more flexible programming languages available to IMS. No doubt exists that this decision to use, was a correct one.

SCEPTRE was another NC pioneering system. It attracted much notice by the airline and other industries. It was sold to multiple airlines and non-airline organizations.

“Redtail” elected to keep SCEPTRE, integrating their maintenance and engineering systems, along with their internal accounting systems run on IBM Computers. Significant work was necessary to accommodate the increased numbers of parts on 747’s. There were plenty of embedded relationships between ESCORT and SCEPTRE, how they were resolved remains a mystery to me. BUT, in the data processing game, most all things are possible – only time and money required.

1975? Incoterm Split Screen CRTs: When activated, an ESCORT CRT could only display one image at a time. Later programmable CRTs became available and were installed. This was done by Incoterm mini-processors. Software was invented to make the Incoterm compatible to ESCORT and to support split screen CRTs, i.e.; the user could have multiple displays on one physical screen. Flight Control was an early benefactor, ole J.D. Sims loved them. But Joe’s continual requests never faltered, “I want to push just one key – and get what’s on my mind!” Eventually, Joe had to work hard to dream up something “he just had to have”. Incoterm systems were later installed elsewhere, its software modified to meet that locations needs.

1975 Program Downloads: There became an increasing number of ‘mini – small’ computers remotely located from the central computer room. These required software, that changed from time-to-time, to function, software that differed for it specific locations purpose. Such boxes delivered by the vendor required onsite folks to load new software. Logistics became an issue, thus ESCORT programs were invented ‘in-house’ to effect electronic delivery and installation of software in most such boxes.

1976 Fuel Inventory Management System (FIMS): Provides the ability to quickly determine location of available fuel, for refuel stop planning. A management tool was developed to isolate a/c and schedule characteristics that cause higher than normal fuel consumption. Result, 200,000 fuel gallons saved in 1977. A ‘glitch’ did develop when fuel price exceeded $1.00 per gallon. It was quickly resolved.

NOTE: Tightened fuel management controls began with the first Arab Oil embargo in 1973.

1976 Teleticketing: When a PNR was created, the agent could specify ticket delivery on a specific date direct to special customer’s printer. Using a new ‘dial-up’ box, this system recognized such arrangements, with ESCORT electronically delivering the ticket without agent intervention. Another glitch; a wrong phone number resulted in disappearing tickets; instead a little ole lady would get early morning calls and a funny ‘beep’ in her ear.

1977 Flight Movement Reports (FMR): This system permitted agents to pre-plan destination loads for their flight departures. This system used the NC Flight Schedule and Flight Release system to obtain a/c type, any loading exceptions and downline stations. Expected or actual passengers, baggage, mail, and freight were recorded by cargo bin and destination, including downline ‘transfer’ station loading. Finalized flight load data was passed via the electronic ESCORT-SCEPTRE bridge to the GO FMR statistical system implemented in 1966 by Fred Voth.

1979 Real Time Schedule Change: Previously, when a new NC flight schedule was released for use, the individual flights were coded, keypunched, tested and loaded to ESCORT. This was a lengthy process, requiring significant manpower and scheduling processing time on multi-computers. Typically, a week plus was required to introduce a new NC schedule. Real Time Schedule Change enabled the ESCORT Data Base staff to enter schedule changes direct via CRTs. The result was much quicker public introduction of the new NC schedule, plus the ability to enter ‘hurry-up’ interim changes.

1979 - Creation of Republic (RC) by the merger of North Central (NC) and Southern (SO) Airlines:

Announced mid-1978, CAB and the USofA Presidential approvals were expected the 1st Qtr of 1979.

NOTE: When first announced, NC was to become “Republic”, YUK, - rebellion in the ranks, it smacks of south of the border. Then realization set in, “once seen on the paycheck it would be ok” – and it was.

The two airlines would become RC, con-current with installation of the October 1979 nationwide annual daylight to standard time schedule change. It was quickly determined that the numbers of increased passengers, flights, airports, and message volumes required major changes. ESCORT simply did not have adequate processing horse power, data storage or networking to handle the expected work loads.

Specific work had to be quickly planned and implemented within a very tight time frame, October 1979. Once “gotta-be-done” tasks were identified and phased completion dates determined, the staff reaction bordered on dis-belief - ‘its not-doable, can’t be done – you’re kidding. By this time the ESCORT programmer staff had grown to a bit over 30. Only 9 of the original staff remained; most of the new folks were ‘rookie’ to new hire’s. It was going to be a ‘ball-buster’ year – and it was.

The more major tasks were:

#1 Implement support for data network required to support SO (Southern Airways). The SO network was re-routed to a site in ATL and initially linked to the MIA Eastern system. A new ATL-MSP installed to permit “flick-of-the-switch” to route SO locations to MSP ESCORT.

#2 Replace existing mainframe computers with recently available larger computers.

NOTE: The NC/SO merger solved a small mystery. Without the merger, a larger computer was needed. During this period, the newer IBM computers where in such demand that IBM finally decided their delivery dates would be established by a lottery. NC was kinda lucky and drew a favorable date, but for the larger than needed (and more expensive) computer. NC was unable to wrangle a ‘needed-by-date’ for the smaller model. Explaining the conundrum to the NC Finance Executive, he mysteriously (and un-expectedly) stated “why don’t we go ahead and buy the larger computer” – and we did, unaware of the secret proposed merger.

#3 Increase data storage capacity by installing larger/faster data storage devices and move all data from the replaced storage devices.

#4 A new technologies control program was required. The control program is the ESCORT ‘engine’, controlling all data storage boxes, networking and agent use of the system. Installing virtually untried control program software at this time was not an option, but mandatory to support the combined airline. Thusly, NC was again, with much trepidation, ‘plowing-new-ground’ to become the 1st USofA airline to use IBM’s new control program – TPF (Transaction Processing Facility). NOTE: By this time, IBM support for the basic PARS system had long vanished. Tho the work schedule was particularly tight, it was done. TPF did bring added goodness; the door was opened for future use of ‘common industry technology’ devices such as ‘special’ function mini-computers, controllers and agent CRTs & printers.

#5 Write software to #1) move SO passenger, etc data from the Eastern Airline MIA system, #2) convert earlier NC/SO passenger flight bookings to RC and #3) notify other airlines of the NC/SO change to RC.

#6 Implement the October 1979 RC flight schedule, modify all NC/SO Passenger Bookings (PNRs) as appropriate, initiate RC vs. NC/SO notifications to Other Airlines (OA) and establish RC Seat Availability in OA Systems.

#7 Install the new RC passenger fares, rules and trip routing.

#8 Insure the new network technology changes supported SCEPTRE and ESCORT requirements.

Overnight October 1st, 1979 it was done – successfully. If anyone took a lunch break, I didn’t catch’em.

Ah, sadly, although in spite of reasonable in place preventatives, the SO cutover had a major embarrassing network glitch (Ref above Trouble section).

1981 SITA: Installed new SITA P1021 support permitting worldwide real-time conversational messaging.

1981-1982 Multi-hosting of Other Airlines in ESCORT: Between 1981 and 1984, ten regional airlines were ESCORT hosted for reservation and other services.

1981 Hughes AirWest (RW) move to RC: Moved RW data from the Eastern Airline system to ESCORT and changed RW data to RC with OA notifications. Changes were made overnight – successfully.

1982 Rental Car System: Reservation agents now had the ability to price and book car rentals.

1982 Reservation Office Series/1 System: Series/1 computer terminals, attached via local mini-computers were installed in the MSP and PHX Central Reservations Office. This enabled agents to split their single CRT screen into as many as 3 unique displays, each organized to meet agents specific work. They could now retrieve multiple displays from ESCORT, thus improving their passenger reservation elapsed time.

1983 Seat Selection/Assignment: Enabled passenger check in agents the ability to provide pre-boarding seat assignments. Later, reservation agents were able to perform seat assignment in advance of flight departure dates.

Above not all, but enough to tell the story, besides by 1983 I’d moved on to much ‘greener’ pastures.

copyright 2009 by Coston E. "Skip" Powell

continues next page > > >