I have pretty clear memories of most of the clients¹ from the very early days of TSI in Rockville, but I did not remember how we managed to develop the software for the first few. All of them except one either bought a new Datamaster or already had one at their offices.

The only computer to which TSI had access was a 5120. Both the 5110/5120 and the Datamaster used the BASIC programming language, but there was no easy way to convert code from one system to the other. If we did not develop the systems for new customers on the 5120, how did we write the code? I was pretty sure that we did not park ourselve in the client’s offices for weeks on end. For one thing, that would inhibit cursing, and it is not really possible to write good code without giving vent to a great deal of foul language. For another, we would have had to meet the client’s dress code every day. I would have certainly remembered that.

Sue reminded me that IBM in those days endorsed the policy of having the software developer take delivery on the customer’s hardware. The system would then presumably arrive at the customer’s location a short time configured and ready to use. Needless to say, this approach lasted only a few years, but it definitely gave struggling developers like us the opportunity to write a lot of software and simultaneously to put aside enough money to buy a system of our own.

TSI’s first Datamaster client¹ was our accounting firm, Massa and Hensley. Looking for a system to do time and material billing, they had purchased the tabletop model of the Datamaster. We met with them and designed a system that used three diskettes: JCPROG, which held all the programs, JCDATA for the keyed tables, and JCDET, to hold the transactions. The system had the following tables:

• A table of client-related data that was keyed by a three-digit client number.
• A table for each job opened for a client. The key was a concatenation of the client number and a five-digit job number.
• Two job cost tables. One had every transaction; the other had the summary of costs by category. This arrangement violated the rules of normalization, but it facilitated some requirements. By the standards of the day the detail file was gigantic.
• An employee table that was keyed by a three-character code.
• A table of cost categories that also had three digit keys. The categories were of two principal types: time and materials. The entries in the time categories consisted of hours worked on a job. The entries in the materials categories were dollar amounts.
• A rate table with a key consisting of the employee number and the category number. It might also have had a date so that they could increase rates to keep up with inflation.

The JCDATA diskette also had a table for a batch of transactions. This table might have been keyed by a letter so that more than one batch could be open at the same time.

My recollection is that there was only one menu on the JCPROG diskette. The user would place the program diskette in drive 1 and key in GO JCMENU. GO was a system command (ass opposed to a BASIC command) and JCMENU was the name of the program that displayed the menu of options.

Every day the operator keyed in a batch of transactions. The source documents were time sheets from the employees and other forms for billable materials. The program checked to see if the JCDATA diskette was in drive 2. If not, a message was displayed on line 24 of the screen to put it in. The entry and editing programs validated each field (client number, job number, employee number, category number) as it was entered. It printed a record of the transactions as they were entered. Transactions could be edited or deleted. When everything seemed correct, the program to update was run. The user was told to remove the JCPROG diskette from drive 1 and to insert JCDET. The records were then written on the history file on JCDET. Summary records at the job level were also written.

There might have also been a program to produce invoices to send to clients. Mass and Hensley may have opted just to produce a cost sheet for the jobs that they wanted to bill. I don’t remember.

We finished this project pretty rapidly, and everyone liked what we had done. Previously they would have had to rewrite and calculate costs for the information from the time sheets onto cost forms for each job. So, this was an ideal project for an early eighties software system. The savings in time and the increase in accuracy of costing and billing were immediate and substantial.

The users must have called TSI for support a couple of times, but I cannot ever remember when we needed to “put out a fire” for them.

Since I was doing the bulk of the programming, I implemented a set of standards for all of the programs. The goal was to make it as easy as possible to understand and debug them.

• Many BASIC programmers eschewed the GOTO statement and use the RENUM command when they have changed their programs. I never renumbered the programs. Instead ,certain types of statements ALWAYS were in the same range of line numbers:
  • Line 1 was always OPTION BASE 1, LPREC. That meant that all counting started with 1, not 0, and all numbers had as much precision as the system could handle.
  • Line 250 always opened the specs table, and subsequent lines read in whatever specs were used by the program.
  • Lines 10000-10999 opened the tables used by the program.
  • The main loop of the program started on line 15000.
  • The exiting routine started at 60000.
  • Program-specific subroutines and functions were located on lines in the 70000-89999 range.
  • Headings for reports were subroutines that started at 90000.
  • Detail lines on reports were subroutines that started at 90000.
  • Reusable functions were 95000-99998.
  • Sections of code were separated by comment lines consisting of asterisks or dashes.
• Every program had a meaningful number.
  • 1-99 was for programs to insert new records into tables or to work on existing records.
  • 100-199 was for lists of items in tables on the screen.
  • 200-299 for transactions.
  • 300-399 for printed lists of items in tables.
  • 400+ for reports.
  • The program number was in the upper right corner of every screen and every report.
  • Program listings and variable cross-references were placed in accordion files by client and program number.
• Variable names were consistent and meaningful. CLNUM was used for client number in every program. Looping variables were always I or J. Counting variables started with N. NEE=NEE+1 would be used to count the number of employees selected.
• In this version of BASIC all files were accessed by a number between 1 and 255. We consistently used the same number for a file. The printer was always #255.
• Although BASIC allowed reading in all of fields at once, thereby assigning values to all of the variables with the corresponding field name, we never did this. If we had, we would have not been able to use the same field names for the same concept in different files. Instead, we read in only the fields that we needed by their position in the file. The disadvantage was that if we decided to change a field, e.g., to make it bigger, every program that referenced that file needed to be changed.
• Disk space was precious. If a customer ran out of space on a diskette, it was a catastrophe. To save space all numbers except codes were “packed” to fit nine-digit numbers in five bytes in every layout. Dates were stored as six-digit numbers in the form YYMMDD. This all worked fine until the late nineties when we, as well as everyone else, needed to address the Y2K problem.
• The screen layouts were consistent, and the behavior of Cmd keys² was also consistent.
  • F2=Online help for every screen.
  • F3=Orderly exit.
  • F4=List of items in a table.
  • F12=Cancel and return.
• The screens validated every field as soon as it was entered. If it was not accepted, the reason for the problem appeared in bold print on line 24, the alarm sounded, and the cursor remained at the field. This worked very well for the 5120 and the Datamaster, but when a single computer had many terminals attached, it became important to minimize traffic going to and from the server. Our programs on the System/36 and AS/400 therefore validated the entire screen at once. Problems were still reported on line 24 of the screen, the alarm still sounded, and the cursor was positioned at the source of the problem.

By and large these standards serve us well. We never really abandoned any of them.

This rather simple project was memorable not so much for what we did but for what it led to. Our accountant, Dan Marra, had a client named Harland-Tine, a new advertising agency in downtown Hartford. The two principals were Dave Tine³ and Susan Harland⁴.

I have dozens of vivid memories of this installation. At our first meeting Dave introduced himself as the president of the agency. He did not say what his partner did, and, in all honesty I never saw her do anything but cook. I think that they might have attracted clients by wowing them with her culinary skills.

Dave said that the agency desperately needed to become more organized and efficient. He said that he turned to IBM for help, and both the IBM rep and his accountant had told him that he should talk to us. He envisioned using the computer for all of the administrative tasks of the agency. We spent a couple of days talking with people there. A large part of what the agency did was analogous to what Massa and Hensley did, but there was a whole other side to their business. They also purchased media (newspaper and magazine ads and radio and television commercials), which they marked up and billed their clients. Sometimes they created and produced these projects in-house, but most of the time some or all of the work was done by other companies or freelancers. There were a lot of other miscellaneous things that they also billed—public relations consulting, billboards (always called “outdoor” even if it wasn’t), direct mail campaigns, and “collateral”, which covered virtually anything else that promoted products or services.

They also wanted a billing system that could handle every type of work that they did. They wanted fairly standard accounts receivable, accounts payable, and general ledger systems. Their payroll was handled by an outside service.

The agency’s ultimate objective was to analyze the profitability of each client. Producing the reports for this was a very complicated assignment. Each client had negotiated a separate agreement with the agency. Harland-Tine billed some clients for items that others got free. For example, the agency’s largest client, Hitchcock Chair, was billed a monthly fee but did not pay anything extra for media expenses. They only paid what the publication or station charged the agency. So, if Hitchcock ordered a lot of media in a month, Harland-Tine did a lot of work with no reimbursement at all.

In addition, some jobs were billed in advance, some when the job was completed, and some in stages. So the profitablity reports, which we called “cost accounting”, needed to match the period in which income was counted with the period in which expenses were incurred.

We did not have the wherewithal to put together a detailed proposal. Instead we outlined in fairly broad terms what we would do for them. We broke it out by module, but we knew that it was really all or nothing. Their most important objective required all of the pieces. Our proposal was a great deal for them. We were desperate, and we did not want them to start looking around.

Sue and I immediately noticed the resemblance of this agency to TSI. They were another company that would do anything for a buck! We decided that when we designed the system for Harland-Tine, we would also make sure that it could be used by TSI as well. We did not purchase media on behalf of clients, but pretty much everything else that the agency did had an analog in the way our company did business. For example, we did not advise about public relations, but we did consult about connectivity and hardware decisions.

I did a little research and discovered that there was a paucity of computer software for advertising agencies. Moreover, there were many agencies within driving distance, especially if New York and Boston were included in our sphere of influence. I figured that the best way to make TSI profitable was to sell a base package with customization to a lot of agencies. We had to start with one or two happy and successful clients. We resolved to make Harland-Tine the first.

Detailed recollections of the installation itself can be found here.

1. We never called the people who paid us money customers. We thought of our business as more service than product. We never installed a system that did not include at least a modicum of customization.

2. There were no function keys on the Datamaster keyboard. Instead there were 24 active Cmd keys in BASIC programs. The user held down the Cmd key in the panel on the left and the appropriate numeric key on the QWERTY portion of the keyboard for the 1-12 Cmd keys. For 13-24 (seldom used by TSI) the user held shift and Cmd and pressed the appropriate key (less 12). Shift Cmd 1 was 13, Shift Cmd 2 was 14, etc.

3. Dave Tine’s LinkedIn page is here.

4. Susan Harland died in 2000. She and Dave Tine opened the Connecticut Culinary Institute in 1987.Her obituary is here.