I was hired by Bell Labs in 1979 and worked on SCCS for several years, then a few years on a Shop Floor Control system for AT&T’s factory automation systems. When that project was moved to Western Electric in about 1989, I had to look around the company for more work. I had a few options but Conversant stood out to me in that it was, at least at that time and in previous years that I noticed, like a small company within AT&T. At one time some of the hardware that Conversant Systems ran on was manufactured at the Columbus Works. Practically everyone involved with the development, marketing and support of the products was based in Columbus. That changed over time but I was attracted to the idea of working in a small company environment. I wasn’t disappointed. Looking back on my career in software engineering, I still consider my roughly 10 years working in that department as the most challenging, interesting, stimulating and productive years of my life (in spite of the frustrations and issues that come in any work environment).
I think it was not only the interesting work but the great people that made the difference. As a new person on a very different project, I struggled at first. Alfredo Gonzalez helped me get on board with my first assignment, writing call data reports. From there it wasn’t long before I was handed the assignment of supporting TSM and its application script compiler, TAS. Talk about wading into the deep end! It was the hub of the Conversant software architecture. Few people wanted to touch it, it seemed. Tom Geers once warned me that working on TSM had already “broken” a few engineers. It was a difficult challenge, in the first year or two, getting familiar with that code and being able to make significant changes to it, but I gradually became known as the “TSM Expert”. It stretched me. Since it had been worked on by so many different people before me, the code wasn’t terribly consistent or easy to comprehend. Joy Joglekar was a great mentor for me when I was learning TSM. I went to her to review my changes and she helped me correct some of the things that had been done to it that she didn’t like. It was the first real time, multitasking software application that I had ever worked on. I had worked on other features in Conversant, like one called Form Filler, but it always came back to TSM. When it became time to rearchitect the system I was in for an even bigger challenge.
That opportunity came in 1994 when it was decided that we needed to open up the application architecture of the Conversant base so voice response and voice mail applications could be written in the C Language instead of TSM/TAS based script applications. A few of us, Cary FitzGerald (our project leader and architect), Jim Murphy, Tom Esh, Rod Warren and myself, were given the task of designing, implementing and documenting a comprehensive C Language API that could do everything our script-based application could do (and more). Since TSM was a multichannel, multi-application “virtual machine”, the API had to be able to support multichannel applications. That became known as the Intuity Response API (IRAPI) and, for it to be truly comprehensive, it would need to support a re-write of TSM based entirely on the IRAPI interface. The “deep end” I had walked into years before now seemed to have no bottom. Yet, it seemed to me, and maybe the others too, like the opportunity of a lifetime. We came up with an acronym, YABR!, which stood for Yet Another Boring Release (Not!). Four of us moved our desks into some unused lab space so we could work closely together for over a year. It was a risky endeavor. When we were done TSM/TAS scripts needed to run as before without any modification of the script source code. TSM would become “just another IRAPI application” albeit one that ran applications itself. Some system functions like Application Dispatch and Resource Management had to be moved out of TSM to be accessible by other applications. Cary, Tom and Rod contributed those, among other things.
My part in the project, of course, was to do the TSM rewrite. The API had to be able to do everything that TSM did (and more) so Jim Murphy and I worked pretty closely to ensure that would be the case. The API had to be “event” driven, as TSM was, with non-blocking function calls that would return immediately so the application could service other channels and wait in a single blocking function for resulting events. This made it inherently multithreaded. Since TSM was going to be rewritten, it made sense to rewrite the TAS script compiler too. It was written entirely in C and was difficult to modify and add instructions to the language. It was rewritten using LEX and YACC, tools made for writing compilers, which made adding new instructions and features to integrate scripts with IRAPI applications much easier. An object-oriented design for TSM and TAS also made adding new instructions easier with code that could use IRAPI header files in the compilation. One crisis occurred during development when the hard disk on our server stopped working and it was found out that our one tape backup was full of someone else’s home directory files instead of our own (and there was no second tape). By late evening, Cary had somehow gotten the disk working again and properly backed up, but not before we had panicked some of our managers. (We never should have told them.)
When we were done with all this, the ironic thing was that so few people outside the five of us noticed any difference. The system worked just as it had done before but also offered a rich C API interface that would later be enhanced and used in new voice mail and voice response applications. The internals of the API were later compiled with C++ while keeping the ANSI C application interface so that IRAPI could more easily be made thread safe for multithreaded applications like AUDIX. It was also ported to Windows NT at one point when our management and some of our system architects and developers became convinced that it would replace UNIX. Some others thought something called Linux could be the answer. No one took them seriously at the time, but we all know now how that turned out. One other product, which never got beyond the prototype stage, was a C++ object framework, dubbed IRAPF, which handled all the multitasking aspects of IRAPI allowing multichannel applications to be written more simply.
Not too long after this we were in for some turbulent times. The acquisition of Octel had a profound change on our organization, and the burst of the dot-com bubble left the whole industry in a lurch. Sad to say that it ended my career at a workplace that I had come to appreciate very much. I left in March 2001. That was the epicenter of a very difficult period in my life lasting some 10 years, but it taught me some of the most valuable life lessons. In leaving, I missed the people that I worked with more than anything. They were the very best. I’ve kept this picture sitting on my computer desk at home ever since. I look forward to seeing some of you again at the reunion. –Paul Dubuc
