When the courier contacted the station by either radio or phone, dispatches were given to to him, and then put into an adjacent slot for that route(indicating these had already been given to the courier.

Congestion

In the larger cities (ie Chicago, New York, Los Angeles etc) only about 10 percent of these dispatches went out via radio. Again the number of agents were growing in the station. Before the agents answered customer calls, now the volume of calls were from the couriers. Dispatches could only be given to couriers when they called in, and when on the radio only about 8 seconds for each dispatch was used, enough to give an address and time ready.

There were other concerns concerning the radio systems. Some other company had bought crystals for our radio frequencies in a large city, presumably so they could listen on the radio and pick off our customers.

Project DADS

Jim Moore was the Project Manager of the Radio group and led the DADS project. He had been given approval to proceed with a prototype in Memphis which would put computer terminals in the vans, and allow communications to the vans at most all times. The objective was to send dispatches as a digital message versus by voice on the radio or via a phone call.

The system was code named DADS (Digitally Assisted Dispatching System).

Jim found a company based in Vancouver called MDI (Mobile Data Company). They had sold terminals to a police department and a couple of fire stations. A protocol had been developed to handle hundreds of terminals on one radio channel. Funding for the protocol had come from the Canadian government.

Jim Moore hired programmer, Jim Bentley; they purchased a few MDI terminals, a Comm controller(interface box) and one Digital Equipment PDP-11/34 mini computer.

The PDP 11/34 was the size of two small refrigerators. One cabinet handled the processing and IO, the other cabinet held two disk drives; each containing a whopping Five megabytes of data.

Video to Right: Jim Bentley memories

Initially there was no communications from the DADS processor to the radio terminals or the mainframe(that is where I came in).

Jim Bentley documented and coded several screens that the dispatchers would use; Jim was an RPG/Cobol programmer and the intial screens were coded in Cobol and Fortran. DEC's compilers took up almost all the computer memory to run these two languages and there was little room left over for an application. The best that could be done , with high level computer languages, was generate dummy screens that didn't have an application behind them.

The Demo of All Demos

I witnessed an amazing feat my first week at FedEX. Jim would sit behind the computers and start screen 1, while Jim Moore would start discussing the future of the system and do a demo. After explaining the system a few minutes and talking about the first screen, Jim would give a queue to Jim Bentley, who would Stop the screen 1 application and start Screen 2 application; with synchronized timing...Jim would push a key and the other screen would pop up....jim would assign a dispatch number...and a manual message had been queued to go to an MDI terminal on the radio.

This was an amazing feat, given the limited amount of software,, but it did the job. Jim Moore was able to get out the message that sell the idea that this system would increase connectivity to the couriers and solve the problems in the growing cities.

Needs

There were at least 4 major issues that had to addressed to have a functioning DADS system

I had been offered a position at FedEx(by Ancel Hankins) in December of 1979; I wasn't able to start until Feb 1st, 1980 due to an internal ear surgery. I was hired in the Data Engineering department which consisted of Ancel Hankins(Mgr); Terry Cox, Dick Winter); and matrixed to Jim Moore's department.

My initial project was to evaluate the DADS system and figure out how to interface it to COSMOS.

DEC's Failure Story

Jim Barksdale took over Data Systems in 1979. He had several major projects to roll out including DADS, COSMOS, centralized call centers, and COSMOS IIa which was the first scanning application.

Digital Equipment had promised FedEx that it would deliver a communications interface that would allow the DADS computer to communicate with COSMOS. DEC discovered that this interface under development in their company would not work.

That is why FedEx started looking for someone who could write communications software.

In my first meeting with DEC and with Jim Barksdale, FedEx only had a one DEC computer and a vision. They also of course had an empty promise from DEC. Instead of being humble, the DEC salesmen began to push Barksdale to order at least 30 of the systems. If FedEx ordered these systems, then they would give the company a 5% discount. Instead of falling on their swords because of their failure, they proceeded to hard sell. Mr. Barksdale was not too kind to them.

Also at the meeting, they gave me the documentation on the software they had developed and would also provide me the source if it would help. I reviewed the documentation and discovered that they had started to develop a new IBM look alike product...that IBM had cancelled. That was the reason they had stopped its development.

COSMOS SDLC/SNA Interface

I reviewed specs for the COSMOS link and felt it would take about 3 weeks to do. The interface board(DUP-11) was ordered but it would take a while to arrive.

Jim Barksdale asked me if there was anything I needed to speed the development. I told him a week training class in DEC macro assembly language would help. There was a spending freeze, but he authorized two weeks training for both Jim Bentley and myself in Los Angeles.

Radio Task

Upon returning, I developed the files, database and macros so that Jim could continue developing the application interface that the dispatchers would use. DEC provided an operating system called RSX-11M and it was the ideal OSr to process thousands of messages an hour between COSMOS and the MDI Radio terminals.

I wrote the Radio task (MDI) in a few weeks and we could now send messages from the DADS PDP-11 computer to the radio terminals. I was able to add in some diagnostic and operations screens and in talking with the radio engineers there were going to be times of no communications (called NOACK)when the radios were in bad areas(like in between tall buildings) or out of the radio coverage area(about 30+ miles out). I put in variable timers for each courier so when they were out of range, we wouldn't waste radio time trying to communicate with those terminals. At the end of the NOACK timer or if any courier hit any button on the terminal, we would automatically start transmitting to them again.

The COSMOS LINK

The SDLC interface board finally came in, and I could start coding. I had already written the high level software, but the low level driver software would be the most difficult. After a week of despair, I finally asked for a budget for $500 for consulting time, to ask Digital Equipment experts what wasn't working. I finally got a hold of a DECNET programmer and sent him my software. He called back and told me that the documentation that DEC had provided had been printed wrong. I needed to add one blank byte at the beginning of my software. I re-compiled..and it worked.

Bob Higgins who was working on COSMOS in Colorado Springs came into town one day. I showed him what I was doing and that I was going to build a table to convert EBCIDIC to ASCII character and to map this into a 3270 screen. IBM used terminals that used 1920 characters. When applications sent messages, you had to convert it to something you could use for your terminals or printers.

Bob said something like...'well all you have to do is take the sixteen bit address, take the lst 6 bits of each byte, jam them together and you will have a number from 0 to 1920 that corresponds to the position on a screen...."

That was a lot of bits and bytes, but I went back and code this in a few lines of code and it worked, and it saved me hours of work.

Success

At midnite that same day, the PDP-11 DADS computer started communications with COSMOS. It was a happy time.

We already had a minimal station set up in Jim Bentley's office on the 17th floor on Clark Tower. Either Jim or the Memphis dispatcher had been taking printouts and just typing in the dispatches into the comm controller to send to the couriers, just for test.

Jim Barksdale came down the hall with some guests and stepped inside Jim's office. He asked me how it was going, and when did I think I could get the COSMOS interface going. I said, 'Oh, I got that working at midnite yesterday'; I had a datascope monitoring the COSMOS - DADS link. I pointed to it and said, 'it's working pretty well, there is only one problem' He paused and said with concern, 'what is it'; I said, 'the dispatches are being transmitted to the couriers perfectly, but when I go to print them(for just backup), the first line is shifted over one character on the printer....' He had a rolled up set of papers in his hand, which he bopped me on the head with...and said 'don't ever scare me like that again.....and Congratulations, Great Work....he went out and told his guests...the bop on the head kind of hurt....but it was another happy day

We were now ready for a full Memphis test,,, around 10+ vehicles.

We could now automatically receive dispatches from COSMOS & into a file(queue) and let the dispatcher assign them. It would only take a few seconds to assign and transmit.

Testing the system was a crazy time. Jim Bentley and I hung out in in his office for weeks with the dispatcher waiting for something to happen. After completion of the days work, we would work at night to correct any issues, and start again the next day.

It was a good prototype test; and we were given the go ahead to prepare the system for a major city test.

Keyboard, no Keyboard, Keyboard again....

Jim Moore was over the Project, the demo's, interace with MDI, setting up plans for rollouts, and working on optimizing the radio channels for data and voice.

The MDI terminals was based on a Zilog Z80 micro. It had a full alpha numeric keyboard but MDI would customize it for FedEx since we would become their largest customer supposedly. Jim wanted simple operation and the terminal had some fixed buttons for STATUS, EMERGENCY and to alert the dispatchers what he was doing.(at LUNCH, DELivery, PickUp etc).

I heard Jim Moore and Jim Barksdale several times discussing whether to have a keyboard or not. The couriers were not typists. The company didn't want to confuse them with keys they would not use.

It was decided to take off the alpha keyboard and just have a numeric pad on the terminal plus the status keys. With numeric keys, the courier could eventually type in the airbill number, showing they delivered a package or picked one up.

So the keyboards came off, then they went back on again. It was decided it might be nice to have an alpha keyboard so the courier might be able to type the name of who the package was actually delivered to.

so keyboard, no keyboard, keyboard again

The Memphis Dads test was a great success. All the pieces were in place to show that this system could get more data, more quickly and perform.

ReVamp - ReWrite the System

From the time I started in Feb 1980 we only had about 4 months to get the system from demo to Memphis testing. Over 15,000 lines of code were generated in that time, plus many files, tables, screens, COSMOS and Radio Link interfaces.

There wasn't time to optimize the system or memory. The next system would support 80 to 100 vehicle terminals and it had to be up all the time.

COSMOS had been written on the mainframe using an operating system that airlines used called ACP (Airline Control Program).

For the next larger system, I decided to model it on ACP characteristics.

I would put all the tables(which were disk based) in a common core memory. I would update an mirror image on disk every 60 seconds. If any application went down, I would re-load the common table, and at worst case only the last 60 seconds of dispatches would be retransmitted, nothing would be lost.

This took a couple months to write, gen and test. Jim Bentley continued optimizing the dispatch applicaiton (ISC) and getting gens down for the next systems.

Problems the new Software

Before the next city, we had several issues

The Aborting Radio Task

Problem #3 was difficult to find. I split up the radio task into segements to find out if it was a driver or application error. I did find that it was an application error, but couldn't debug the problem.

Then John Schwarzmann and Jim Moore approached me and relayed that they were installing the radios and terminals in Chicago. They wanted to start the application so they could be testing the system. I said, OK...but don't make this system live till I can fix this worrisome problem...

The next week, Jim and John was in my office....the system had been turned on, was working and being well received...but the Radio Task was aborting 4-5 times a day....and we needed to fix it

....so disallusioned, I was off to Chicago to see if I could locate the problem. Jim Bentley was up there and monitoring the system. If the app died, he just restarted it.

I stayed a week and couldn't located the problem. I did write a new app that monitored the Radio Task, and just restarted it automatically..so that Jim Bentley didn't have to do this.

It was a great trip though, because I was able to see what the dispatchers did, what information they used, and what else they needed. I wrote several new apps for the Dispatcher and one for the couriers while there.

Back to Memphis, I continued to beat my head day and night the next week. Jim stayed and baby sit the system.

Every night I would take the software home and go page by page looking for errors

FOUND

Then I found it, it wasn't supposed to be there. Somehow the compiler had injected a command to load a register R0(R and a zero)...but it listed this as RO (R and an alph O); the line wasn't supposed to even be in the software and would cause a crash.

I called Jim Bentley, he made the change and compiled it......and it ran...and that was another Happy Day.

New Tasks

This pretty much ended my work on DADs. Jim Moore took these systems to the largest cities, and then with project Zapmail, there was a need to be able to dispatch couriers to pick up and deliver zapmail documents. These systems were rolled out to over 380 locations using over 800 towers. Over 5,000,000 transactions per day were transmitted to and from COSMOS.

Called to CIO's Office

I was called to Jim Barksdale's office one day for a chat. Jim was notorious for correcting spelling errors in his employee's memos. He had just finished correcting several as I sat down. He had hired someone who previously had been an English teacher. He told her as I came in, we have to get some training for our Managers. They've got to learn to write, and we also need Manager guidelines to help them. This led to the first Manager's Guide.

Then, I was told "you have done good, and will continue to do well at FedEx. Your success,though, is de-moralizing some of my software departments. A new job will be posted next week, it will be for you, and is a promotion, in a new department. You don't have to take it, but if you want to continue developing systems, this will be the place for you. I know you will be a success where ever you are in this company."

Thus, I took the advice and started anew....

Onward

Jim Bentley and Gary Holmes continued development. Jim became an expert on DEC systems, especially finding the best prices. I don't think we bought but a few systems from DEC directly. Jim Moore was able to find OEM companies who built smaller and smaller DEC systems and much less expensive than DEC.

Ahead of it's Time

It was vision ahead of its time. It was almost a decade before there were public systems available, and they were much more expensive that Jim Moore's team had spent in implementing this system.

In Chicago, the first major city the scenario changed in one day.

One day they were dispatching via voice and phone. Two Dispatchers and all the Couriers were working 2,3,and 4 hours late each day to keep up. On the first day, at 3:00pm all was quiet except for the printer which was printing the little slips of paper holding dispatchers (this was done as a backup); and most all the couriers finished their pickups early.

On my trip to Chicago, the dispatchers decided to cut off all the printers...they were making too much noise; they trusted the system...and didn't want a back up plan with the noisy printers and paper.

A good story "Where's the Package???" (Courier Arrives before customer ends phone call)

Before DADS, customers would call for a pickup, and say the package is ready NOW. The customer hadn't even packed what they wanted shipped yet, but they knew it would be a couple hours before a courier showed up.

In one case, the customer was on the phone to book a dispatch, and the agent entered and gave them a COSMOS number. The customer then asked some follow up questions about a previous shipment. While still on the phone, the FedEx courier enters the business and said "where's the package", pretty much frightening the customer, and creating a Twilight Zone moment. It seems, that the courier had just pickup up a package next door, went to his van, saw the new dispatch on the DADS terminal and just turned around and walked into this customers office.

It wasn't long before customers changed their package ready times, to realistic ones.

Larry Curly & Moe - the 3 Stooges

In Chicago, before DADS was installed, most of the couriers worked overtime to get to their customers and pick up their packages. There wasn't a lot of time to kid around.

As DADS was installed around 1981, the couriers were able to finish early and even have some slack time. The radio channels which had been at max capacity now had some idle time.

Three couriers then decided to stage Three Stooges commentary on the radios while they were driving between stops. The dispatcher tried to find out who this was, to no avail.

It was Gary Holmes who made one change to the DADS software. The terminal in the van would transmit a code, telling which radio was in use. This though wasn't displayed anywhere. Gary made a modification on the Dispatcher screen, which would display, who was talking, as they keyed the microphone.

The next day, the dispatcher awaited the stooges re-enactment… as soon as all 3 had done their act… The dispatcher announced via the voice channel: "Bob xx, Terry xx, & Sam xx…..I would like to see you immediately after your pickups are done…" ,,,,there was silence ….and no longer did the 3 stooges hog radio channel time…..

About five years later, Jim Moore did a bold thing. He authorized a SuperTracker interface to be added to the DADS terminal. This was not part of the initial plan. It was planned that the Couriers would initially scan packages at the customer locations, then bring the trackers back to the station and scan in a PC like device called the SmartBase. The SmartBase had startup problems the first year, and the fall back became the DADS wireless system. Scans could be transmitted seconds after picking up the package and on delivery, the package was scanned, the person's name was typed into the tracker and the device put into a 'shoe' connected to the DADS terminal in the Van. FedEx could now have positive proof of delivery scans and the signature of the receiver in minutes after delivery.

This was a great boon to customer service agents.

Richard Dunn comments concerning 40 year anniversary of the first cell phone article:

The cell phone 40 years ago is somewhat misleading - a phone with no network. The cellular networks didn't get started until the early eighties.

To put the DADS radio network in perspective:

First FedEx radio system in New York City - January 1977

First Alpha DADS system in Chicago - June 1980

Followed by Beta DADS system in New York City - December 15, 1981 (peak season?)

The DADS program began in 1982 and was rolled out nationwide by 1986. This was about the timeframe the cellular networks became viable...

Some Whining

"Sure, They got the SNA interface working, and got the interface to the Radio Terminals, and got the Application going, but they will never be able to do proper Documentation"

Other software groups wanted developmental control to be transferred from Jim Moore. After each success, some other issue was raised to Jim Barksdale.

After the Memphis test, word came down from Mr. Barksdale's office, "I would like to see the DADS documentation".

Now, we had been burning midnight oil and everyone was concentrating on making sure all these components worked. There was only Jim Bentley and myself writing software, there weren't any tech writers.

So, in 24 hours we pulled together what we had. Fortunately Jim Bentley, had documented the screens, tasks and had a great start. I took my flow charts, description of the system tasks, inter-communication formats, components, and we printed all our software source code. Fortunately, the software had comments throught the printout, which was several inches thick.

We put a cover letter on it, sent it upwards and waited.... This is what came Back

Happy Days again....

I was sorting through some paperwork the other day and this turned up.

Thought you would get a kick out of it. I know I did.

Clark(Hinds)

PS. Also found a copy of the 1996 BERT Guide spiral bound. I will get it to you if interested.

Who wrote the first BERT Guide?

JJ Woods started the BERT guide out of necessity. If you remember, B.E.R.T. was an acronym for Basic Electronic Repair Team. Before the days of field and station techs there were BERT techs.

Highly intelligent couriers who, with a bit of coaching over the phone could perform elementary repairs to the mobile radio fleet. The original guide was produced on a Wang Word Processor and copied many times.

I am in search of one of those copies. The guide I have in my possession was produced and formalized by Technology Services.Copyright 1987-1996.

Clark Hinds