ASDC was the first job in my career where someone paid me to do programming.
I had dabbled with programming in the past, and in high school had written a
fairly complex program that supplemented a table game I played back then. But aside
from my programming classes in high school and college, it was all for fun.
I was originally hired by ASDC as a technical writer, but several months into
the company started having issues with some of its programs, and more
importantly, with its programmers. I offered to lend a hand.
Basic architecture of an ASDC system
The company's primary product was a restaurant point-of-sale system, the design
of which the owner of the company had come up with himself. The basic
architecture as a single SCO Unixware server with a custom serial port
board that, depending on the install, gave us anywhere from two to thirty-two
serial ports. Each serial port was wired to one of the stations in the
restuarant. A station could be as simple as a kitchen printer or as complex
as a touch-screen terminal with a card reader, attached printer, and
Because of the hardware architecture, practically anything
could be connected to the application. At one point, we integrated the system to a hotel
management system and created a room-reservation system based on our
standard restaurant table reservation system. While the POS systems were
designed for touch-screen input instead of keyboard input, a pizza ordering
system preferred keyboard, and it was relatively easy to adapt the system
The programming was all in C and Bourne shell scripting, and the data was
stored in a C-ISAM database. This was back in the day before USB had been
invented and database server software cost multiple thousands
of dollars - way beyond what a restuaranteur would be willing to
pay. The RPG programming language was used for a full-fledged accounting
package that was sometimes sold in addition to the main POS application. The
accounting system was what I was originally hired for; my job was to
migrate the user manuals into a modern publishing program.
Point Of Sale Stations
I started writing reports, and quickly took ownership of the two
most significant programs in the system: the end-of-day reconcile program,
and the point-of-sale workhorse.
ASDC system point-of-sale station
The beauty of the architecture was in its relative simplicity, given what
it had to do. At one end of the wire was the point-of-sale program, with
standard output and input both redirected to and from (respectively) the
serial port. On the other end of the serial port was the terminal, with
special wiring to integrate a receipt printer, card reader, touch
screen, or keyboard so that they appeared to the application as a single data
The master program was a complex state machine, spending most of its time
waiting for input, that being a touch on the screen, a swipe from the card
reader, or a keystroke on the keyboard. An up-front dispatcher would read
the bits to determine which of the three occurred, and then the state machine
would execute whatever action was appropriate - anything from causing a button
on the screen to flash while the item was added to the order area of the screen,
to initiating a back-end credit card pre-authorization to a credit bureau.
The credit authorization process occurred in the background, using a modem
(this was in the days before the world wide web existed). The master process
put its credit request in the queue, and the authorization program would
dial to the credit card clearinghouse and get a pre-authorization. Once the
meal was complete and the tip was known, a similar process would occur to
perform the actual charge to the customer's credit card.
Achievements at ASDC
In the course of the several years that I worked at ASDC, I began understanding
how complex systems can get. The master POS program was a single source code
file that was over 15,000 lines long, not including comments. The end-of-day
reconcile program was written by a foreign programmer who could barely speak
English, and her comments and variable names reflected this. But at the same
time, I would say both programmers were talented and I learned much from
contrasting their styles and picked up quite a few of their
more useful techniques.
Here are a few of the notable things that I did while in the employ of ASDC.
Implementation of credit card back-end process and queuing system.
Probably the most significant programming task I had ever had at that point
in my life, I worked with a consultant to determine the basic approach, and
then I took the bull by the horns and wrote the entire credit card processing
subsystem. I also modified the master POS program to work with it, and
deciphered the protocol specifications as written by the credit card
clearinghouse (First of Omaha) to certify the system as qualified to
perform credit card transations. I eventually certified with several
clearinghouses. This was my first introduction to
what the first 15 or so bytes of ASCII are actually used for.
Country Club System. I modified the master POS system for
implmentation in a country club, including their restuarant and golf store.
Hotel Reservation System Integration. I modified the master POS system for
integration into a partner's hotel reservation system.
This enabled authorized users to use
the restaurant point-of-sale as a way of checking room reservations as
well as charging meals to rooms.
Pizza Delivery System. As it existed when I first started, the
POS stations did not support keyboards at all. However, one client
demanded this, so I added keyboard support to the master POS program.
POS Maintenance Program. The master POS program used a complex
configuration file to learn about what was to be sold and how to display
it logically so the wait-staff could quickly and efficiently enter
orders. This configuration file was a text file housed in a unix system
with no graphical interface or mouse, so only ASDC staff were qualified
to modify it. Using a unix library called curses, I created
a graphical user interface that read the configuration file, re-created
what would appear on a POS station, and allowed the user to change
things like position, grouping, color, name, and price. This enabled
restaurant managers to be able to modify their menus whenever they
wanted, without requiring ASDC services. It ran on the console
in the back-office.
Back-office Menuing System. The back-office was run using
a text-based menu program that controlled everything from
starting a POS stations to running yearly tax reports. The original
program was entirely in C and exceedingly difficult to change, much
less customize for each of our customers. I redesigned this program
as a generic engine that used a configuration file to dicate what
appeared on each menu and what happened once someone selected an option.
This enabled the easy customization of menus.
Database Maintenace Interface. At the time, SQL as a concept
was considered bleeding-edge, and database engines weren't used by
startup companies like ASDC. There was no simplistic viewer into the data;
if you wanted to see what was in the database, you had to write a C program
to get it. Because many of the tables were based on the accounting system
written in RPG, we decided to use RPG as our data definition language,
and I wrote an engine in C that used these RPG files to generate a user
interface for any table so defined. In this way, the company was able
to create a table definition in RPG, and then use my program to create the
table, as well as the standard add/update/delete/view row options.
RPG to C Report Generator. Many existing reports written in RPG
were desired by the restaurants - however, none of the machines had RPG
installed, and no one wanted to pay for it. So I wrote a program that
converted in a rudimentary fashion RPG source code to C source code,
thereby enabling us to compile C reports that could easily be deployed
to our customers' systems.
Wrote POS User Manual. While the job of re-writing the accounting
manuals was a fairly simple job of formatting and entering existing text,
writing the POS user manual allowed me the freedom to make something that
was very useful as a tutorial on how to use the various aspects of the
system. In total, it was over 200 pages, and I ended up being
the most logical person to maintain the manual since I was involved in
every aspect of the user experience, from training new users to
changing code to make the system easier for them to use.
Trade Show Representation. I represented the company at several
restaurant trade shows where the company had bought a booth for sales