Professional Software Consulting

• Home
• Philosophy
  • Introduction
  • Delivery
  • Maintenance
  • Teamwork
  • Expectations
  • Automation
  • Conclusion
• Background
  • Introduction
  • ASDC
  • Young Systems
  • Bennett
  • Premiere
  • AT & T
  • @IS
• Areas of Focus
  • Introduction
  • PHP
    • Sample
  • CakePHP
    • Sample
  • HTML / CSS
  • Apache/MySQL
  • FreeBSD/CentOS
  • RealBasic
    • Sample
  • AWS Cloud
  • C / C++
    • Sample
  • Shell Scripts
    • Sample
• Sample Projects
  • AWS S3
    • s3_bucketContent.php
    • s3_bucketCreate.php
    • s3_bucketDestroy.php
    • s3_bucketList.php
    • s3_fileDelete.php
    • s3_fileDownload.php
    • s3_fileInfo.php
    • s3_fileUpload.php
  • DB Backups
    • backupDb.ksh
    • backupTable.ksh
    • restore.ksh
    • getSchema.ksh
    • showUsers.ksh
    • showDatabases.ksh
  • Get Field
    • getField()
    • getFieldMB()
    • getLocationMB()
    • countFieldsMB()
    • utl_memStr()
    • Conventions
  • Digits to Words
  • Time Logs
    • Listing
    • Import
    • Export
• Contact

Application Software Developement Corporation

1992-1994

Restaurant Point of Sale Systems

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 job, 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 keyboard.

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

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

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