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

Premiere Technologies

1996-2000

Multi-Threaded Programming on a Single-Threaded Operating System

Premiere Technologies originally made its money in the business calling card industry. This was back in the day before cell phones were ubiquitous and pay phones were still heavily used by people on the road, and calling cards were a common way for those people to save money. The company has since changed name to Premiere Global Services.

To support the calling card business, a DOS-based telephony system written in C was developed. It used an assembly language routine to enable threading in the application, thereby allowing a single Intel DOS machine to handle as many as 48 inbound and outbound phone lines simultaneously. Dialogic hardware was used to handle from 1 to 4 T1 lines (providing the 48 in and 48 out phone lines), and sometimes conference calling

Because the application ran on DOS, I learned a lot about memory constraints. Nowadays, having a program that is 30 megabytes in size is no big deal, but back then, the program had to fit within 640 KB when running. I came face to face with this limitation shortly after I started. My experience up until this point had been programming in a unix environment - where how much memory a program uses doesn't matter much. In unix, memory is laid out like a gigantic field, and your program is given a little patch to operate in. If your program needs more memory, it simply asks the operating system for an addition to its patch, and more is provided. If the operating system ever runs out of actual memory, it has provisions to start using part of the hard drive as extra memory. Of course, the reality was far more complex, but the programmer didn't really need to know about it.

As a result, when programming in unix, there are things you don't think about, such as how much memory your string literals take up, or how large your stack grows. I was used to thorough logging in my programs, and so the first task I gave myself was to add what I considered "proper" logging to the system. Well, it wasn't very long before I found out why the logging in the application was so sparse: it wouldn't compile. In the memory model used at Premiere, the maximum amount of space allowable for all string literals was 64 KB - and a lot of that was already filled before I started adding my logs.

To get around the fact that logging could not effectively be done, the designers of the application created a scheme whereby as the program pointer entered functions, a numeric code was printed on the screen, with one code printed for each level of nesting or each time a sub-routine was entered. That way, if the program were to lock for some reason, one could deduce where it locked by looking at the codes that were on the screen.

I learned a lot about bitwise operations because inter-thread communications were handled by setting bits in a particular area of memory. Memory limitations made every bit precious, and so I had to think differently about how I coded (this was in C). While this wasn't an embedded environment, the limitations sometimes made it feel like one.

I started out as a developer, and eventually became the manager of the department. Later I moved on to be involved in configuration control for one of the tech company's Premiere bought, moving back into my favored environment of unix.

Achievements at Premiere Technologies

Here are a few of the notable things that I did while in the employ of Premiere Technologies.

• Database Driven Telephony Menuing System. Calling cards typically have menus, the "For X press 1, for Y press 2..." sort of thing. I built a menu engine into the system to move this complexity out of the code and into a database. It supported parameters, menu nesting, and prompt variations based on clients, to name a few.
  
  
• "Personal Assistant" Product. We took the idea of a calling card and added concierge-like capabilities, like routing to a flight-reservation system, setting up reminder notifications, and other things one can get far more easily today from a PDA. I was responsible for the coding and implementation of the entire project.
  
  
• Redesign of Email Distribution Subsystem. Premiere had one of the first text-to-speech email notification capabilities in their products. Unlike the other parts of the system, this was done using a unix platform, but the original implementation was designed such that it only worked when run as the root user (for those of you who don't know, running user applications as the root user is a very bad thing). The result was that a bug in the application could cause the system to crash. This was during my time as department manager; we had to re-write the application from scratch.
  
  
• Linguistic Sub-System Design. To support Mandarin Chinese and Spanish, I enhanced my menuing system to accommodate voice prompts in any language.
  
  
• Database Driven Dialing Protocol Language. To facilitate using different hardware as well as having different connection purposes, I designed and implemented a dialing protocol language to abstract out the details of call connection for normal as well as conference calls, plus notification (i.e., outbound-only) calls. This is similar to what the modern CCXML language is used for.
  
  
• "Take Back and Transfer". I designed and implemented a feature allowing the telephony user to end a call and call another number. While this functionality is trivial with today's systems; using a modern system, this task could be accomplished using VXML.
  
  
• Design of layered client-server model for clustering server processes. I designed a layered client-server model for message passing in an attempt to add encryption to our existing IPX/SPX protocol stack.
  
  
• "Polish" Notation C Coding Standard. While quite similar to Hungarian notation, the standard I developed was designed to make code more readable and enable to developer to save time by not having to search to see what type of variable something is. It also introduced a naming convention for structures and function pointers.
  
  
• Call/Feature Rating Engine I helped develop the schema and architecture for an engine that would facilitate the maintenance of call and feature rating for the phone card products we sold.
  
  
• PVCS Wrapper Scripts. One of my responsibilities when working on the unix systems was as PVCS administrator. I wrote a series of Korn shell wrapper programs that facilitated code archiving in an orderly manner according to the needs of the other managers.