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
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.
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.