David F. Leigh

Home Page / Contact Information

Professional Biography

USAF Software

While in the Air Force I had the fortune of being able to automate quite a bit of the tasks at hand. The Air Force had just contracted with Zenith for the delivery of the Z100 (and later Z150) machines. Software on these machines included WordStar, SuperCalc, and Condor III database. The Z150s included Windows 1.0.

Wideband Outage Record Management System (WORMS)

This was my first "professional" program. Of course I didn't get paid for it, but it was used in a mission-critical government capacity. I'm still quite pleased with the design and implementation of it, given that it was written in the mid-80s.

WORMS automated the Quality Assurance position to which I was temporarily assigned due to short staffing at RAF Croughton's Technical Control Facility. For those who don't know, Tech Control routes most of the communications into or out of a base. Each circuit is broken out and routed through patch panels, so that any downed circuit can be re-routed manually without affecting the "distant ends". This is probably all automated and software routed now, but it wasn't when I was there.

I simulatneously held two jobs there; Circuit Outage Coordinator (COC) and Quality Assurance (QA). As COC I was responsible for rerouting circuits that were down for scheduled maintenance and documenting the downtime. As QA I was responsible for collecting tickets that documented the unscheduled outages, calculating the percentage of downtime for each of the circuits, and comparing the performance against two criteria: Performance Objective and Management Threshold. The PO is your uptime target... typically 95%. The MT is the degradation you'll allow before reporting the circuit to management... typically 97-98%. For each circuit that fails MT or PO, a detailed report was generated and a graph was prepared showing the trend of each criterion. These graphs were prepared manually using graph paper and colored tape. The performance of all circuits was logged. Needless to say, this took a lot of time... about a week out of every month just to prepare the reports.

With the blessings of the NCOIC, MSgt Steuer, I created WORMS in dBASE II. Normally DOD programs must be written in Ada, but we received special dispensation for RAD development, although RAD wasn't a term then. WORMS displayed a standard outage ticket on the screen and allowed these tickets to be input directly instead of being logged on paper (although we did maintain duplicate tickets on paper due to regulations and for disaster preparedness). The tickets were visually similar to the paper form, and met all regulatory requirements for reporting, including lookups for RFO (reason for outage) codes. The outage reports were generated from a menu option, and the graphs were generated by creating a formatted text file (SYLK) and shelling to SuperCalc to do the graphing on an HP four-color plotter. Instead of reporting on only failed or "Commander's Special Interest" circuits, a summary of ALL circuits could be included in the report. Instead of one week to complete, month-end reporting took two hours, including color graph generation.

Originally written for the Z100, which contained 2 floppies and no hard disk, WORMS fit on 3 diskettes. The program ran in A:, primary data files were stored on B:, and ancillary and working files were manipulated in a RAM disk for speed. Later I revised the system to operate from a hard disk when we purchased Z150 computers.

Quickdraw and Slideshow

This pair of programs performed exactly the same function as PowerPoint does today. Unfortunately, Powerpoint wasn't around at the time, so I wrote these in GWBASIC. They were handy for doing visitor briefings, and were certainly more impressive in a high-tech shop than the flip charts we previously used.

Quickdraw allowed the user to draw on a graphics mode screen. It had mouse and cursor support, and could also cut and paste portions of the screen, as well as save cut portions to multiple clipboards to be used as clipart. Screens were saved as memory image.

Slideshow simply displayed successive memory images according to a list maintained in a text file. The user could manually step through the images forward or backward, or could set up a timeout value to have the slideshow display images automatically. The slideshow could exit on completion or loop indefinitely. Quickdraw and Slideshow were quite nice at the time. In addition to the GWBASIC version, I wrote versions for the TI-99/4a and the Commodore Plus 4.

Status Display Emulator

One of the nicest parts about having worked with older technology is that non-digital technology is so damned ingenious. Nothing impresses me more than the sort of creativity that developed the Teletype.

Consider that the radios that we used in our remote sites could communicate status back to the Control Site, and that this status was displayed visually on a compact console about the size of a stereo component. Analog frequency information was converted into MultiFrequency Tones (TouchTone) for transmission to the Control Site, and then were converted into a "two of five" code which was applied to a spinning magnet. Painted on the magnet were numbers, and the voltage applied to the electromagnets surrounding it determined where the wheel stopped, and which number was displayed.

This thing broke. And as you might surmise, it's not easy to find parts for. Add to that the fact that it had been so reliable for so long that there was a shortage of expertise on the thing, and you have something that's very expensive to fix... Not because it's difficult, but because it's unusual.

Using a Myarc Geneve 9640 (a TI-99/4a compatible computer) and TI-99/4A Home Computers, I created test equipment that enabled us to salvage some of these status control units. The TI-99's sound chip was capable of generating the MF tones and timing necessary to send control tones, and the program I wrote combined this with a visual graphical interface that enabled the technician to manipulate a facimile of the display, then transmit the proper codes to the the receive unit for testing.

Reception of codes was through the cassette tape interface, which was designed from the start to receive and decode sound. This enabled the technician to decode signals from the transmit unit to test it for proper operation.

The tone generator code was written in Myarc BASIC for the TI-99/4a, and ran in 48k of RAM. The tone receiver code was written in TMS9900 Assembly language, compiled, then converted to DATA statements so that the Myarc BASIC program could POKE the code into RAM. I was exceptionally pleased with the results, and I've kept a copy of the code just because it's so cool.

Other Software

Personnel and equipment management: As Equipment Custodian, I was responsible for tracking the fixed assets of the RAF Croughton receiver site. As Training NCO, I was responsible for tracking the training status of personnel. I wrote tools in dBASE II to enable me more control over these additiional duties than were afforded me through the default systems that the USAF provided.

Work Scheduling: Generating weekly work schedules is always a bother. My USAF scheduling system was basically a system of SuperCalc macros that took some basic scheduling criteria into account and tried to generate a valid schedule. Vacations were simply marked into the grid and were discounted by the macro. It was certainly not perfect, especially where vacation planning was concerned, and required human review. However, experience with this was valuable in later creating the scheduling portions of the Medical Office Manager.

Flight Planning: This was not for the USAF per se... at the time I was becoming interested in the Aero Club, and this Multiplan spreadsheet calculated time and fuel consumption for each leg of a flight plan, and for the total trip. Latitude and Longitude of surrounding airports and landmarks were stored in a lookup table, and prevailing windspeed and direction were entered manually. Some account was taken of the average fuel consumption of the various planes the Aero Club had on-hand. The tool was written in Microsoft MultiPlan because my home computer was a TI-99/4a at the time and MultiPlan ran on it.


The informational content of this website is copyright 1997-2002 by David F. Leigh unless otherwise stated. Permission to distribute is granted under the terms of the GNU Free Documentation License.