1981-1985 TSI: The Quest for the Holy Grail

Who made the hoofbeats with coconuts? Continue reading

We knew what the Grail looked like, but finding it was another matter.

Systems that were designed and implemented to the specifications of each client were both fun and challenging. They were not, however, very profitable. From the beginning I was always on the lookout for a way to market one system to a dozen or more clients. It had to be a business that was unique but also substantial. Another limitation was geographic. In the early eighties there was no good way to support systems remotely. We therefore needed to concentrate on companies that were within relatively easy driving distance.

It wasn’t in the construction industry.

I realized the importance of finding such an industry in which to concentrate our efforts almost immediately. The search for this Holy Grail led us down several paths that turned out to be dead ends for various reasons.

When we first moved back to Connecticut we had not yet developed any significant software aimed at businesses. Sue had expertise working with the construction industry and IBM’s payroll package for those companies. Unfortunately, we did not have access to a list of IBM’s installations of this product.

I spent some time putting together a card file of construction companies in New England. I think that my source was the Yellow Pages in the Hartford Public Library. We may have even done a mailing to them. I am not sure that we had stationery and envelopes yet. In early 1981 the first class postage rate was only fifteen cents. So, we could have mailed to one hundred companies for $15. That was within our marketing budget.

At any rate, nothing came of this effort. For several years Sue continued to do work for those clients, but we got no new ones in any aspect of the construction field.


As soon as I had completed work on the software for Diamond Showcase (described here), I undertook research to find out how many small chains of jewelry stores there were in New England. I located very few indeed. Undaunted, I composed a letter that boasted of our success at Diamond Showcase. I only got one response.

Would you buy a jewelry inventory system from this guy?

Before my first interview with the president of Harstans Jewelers, Frank Sikorski1, and his wife (whose name and title I don’t remember), IBM had already announced the Datamaster. So, I had to persuade them to have faith not only in my ability to produce a system for them but also my recommendation that they buy a computer system that was just hitting the market. They also had to let us take delivery on the system. At the time I still looked like Tommy Chong (minus the headband and the ever-present joint), and my wardrobe was that of an impoverished grad student. Nevertheless, they agreed to our proposal.

Harstans was a family business, but there was no one with the surname of Harstans. Rather, it was a combination of the first names of Stanley Sikorski, Frank’s brother, and Harriet, Stanley’s wife. Stanley, I learned, operated a wholesale jewelry business in New York City that was the source of all of Harstans’ diamonds. Frank was the president; I am not sure what Harriet’s title was, but she was in charge of payroll and paying the bills. They used IBM’s payroll system for the former, but they did not like it. Eventually we installed the payroll system that we had written with some minor modifications.

The Harstans store in Hamden, CT. I could find no photos or mentions of the West Haven store.

The company’s offices were on the second floor above the West Haven store. There were four other Harstans stores at the time. Eventually they even opened one in the Enfield mall. I was never actually on the sales floors of any of these locations. I parked in a lot behind the West Haven store, entered through the back door, and took the stairs to the second floor.

Harstans insisted that we make one major enhancement. When a batch of new items had been entered, they wanted the system to print small tags for each one. The tags contained both the retail price of the item and the price that Harstans paid—in code. The code was BUICKSEDAN. B was 1, U was 2, etc. If they paid $523 for an item, the tag said KUI.

A Harstans ad in the Hartford Courant in 1991.

No customer paid the retail price on the tag either. The store had the peculiar policy of running a permanent half-off sale. So, if the tag said $350 the real price was $175. Competitors tried to force them to abandon this tactic, but for as long as we were associated with them, it persisted.

I visited Harstans many times over the years. Here are some of my most vivid memories.

  • Harstans had many customers from New York. The store, which was near I-95 and Route 1, did not charge these people sales tax, which was required for on-site retail sales. Harstans allowed these people to take the goods they bought home with them, but they also mailed them an empty box to prove that no exchange of money for goods had taken place on the site.
  • I locked my keys in my Celica once. I had to borrow a coat hanger to get in.
  • Harriet told Sue that she and her daughter had been at their house in Branford when some men broke in and tied them up. Some items were stolen, but no one was injured. The incident induced Harriet to buy a pistol and take shooting lessons. She always carried it in her purse after that.
  • I was working in the office in December when the store manager brought up a stack of bills from downstairs that was as thick as his fist. He wanted to count them in private. The first eight or ten were $100 bills. I stopped watching after that.
  • Frank asked me to give a speech at the Lions Club of West Haven. I told the attendees how much I liked my job. A few people asked me about horrible situations that they had had with their computers. In every case they had sent a boy to do a man’s job. Their computers were not designed for business applications.
  • Frank asked me to do something once that was almost certainly unethical. It involved writing a program that produced one page of printed output that looked vaguely like a computer-generated report—not one from our system—but actually contained fabricated numbers that he supplied.
  • The store, of course, had burglary alarms. I was occasionally the last person still working in the office. Usually people were still working in the selling area. However, on once occasion the last person downstairs had left without checking the office. When I opened the door to exit all of the alarms went off. I just strolled to my car and drove home No one ever mentioned it.

We also installed an accounts payable system at Frank’s insistence. I had already noticed Harriet’s approach to accounts payable. Her lower right desk drawer was devoted to invoices from vendors. Sometimes she took the invoices out of the envelopes, but just as often she threw the envelopes in unopened. This infuriated Frank, but there was not much that he could do about it. He was the president and she was an employee, but she was also an owner, and he was not. He was counting on the A/P system to solve the problem.

It was an ugly job, but someone had to do it.

Vendors called complaining about unpaid bills pretty often. I once heard her tell one of them that she would cut a check to them that day. She also begged them not to tell her boss about it because he would probably fire her, and she really needed the job. She got a tear in her voice while she said that. She also usually asked the vendors how much she owed them instead of looking through the invoice drawer.

To set up the accounts payable system we had to go through the stack of envelopes and invoices one at a time. We had to take Harriet’s word that some of them had already been paid. It was a humiliating experience for her, and she probably hated both Frank and me for it. When we were finally done, A/P was turned over to the lady (I can’t remember her name) who ran the inventory system.

I had an interesting meeting with the proprietor of Michaels Jewelers, a chain of stores based in New Haven. I don’t remember his name. He lost interest in our system when I told him that there was no way for two Datamasters to communicate remotely. This was becoming a bigger drawback to the design of the hardware every year.

Who cares if they buy it?

He told me that his biggest problem was inventory “lost” at his branch stores. He said that he really didn’t care that much if he sold the jewelry. It could just be melted down and resold as something that was more popular at the moment. Is there anything else that one could say that about?

Another great thing about the jewelry business is that you can depreciate the inventory for tax purposes, but in fact the value of the goods is more likely to increase rather than decrease for reasons that I have never understood. After all, they are just shiny rocks of little utility.

Unfortunately, there was not much that we could offer in the way of loss prevention, especially if the problem is focused on employees. Really good solutions to that problem were not available until at least a decade later.

One other thing that I remember is that the proprietor of Michaels called the people at Seiko “whores”. I think that he meant that they did not care who sold their watches.

I also pitched Westerly Jewelry Co. in Westerly, RI. An IBM rep from Providence drove to Westerly and brought a Datamaster with him so that I could do a demo for Larry Hirsch, the owner. The reception to my presentation was not great. I tried to follow up, but there was not much interest. If they had owned two or three stores, we might have had a better chance. Managing one store without a computer is much easier than managing several.

Not at IBM in the eighties!

What I remember most about the experience is that the IBM rep wore a yellow shirt. I had never seen any male IBM employee in anything except a white shirt. This was, of course before IBM did a 180-degree turn on its expectations about the attire of its employees.

I called the 5360 model of the System/36 the washer-dryer unit.

Harstans used their Datamasters for many years. They hired a young man named Jim Coer to oversee the systems. We had a pretty good relationship with him, but they eventually decided to buy a System/36 at a cost that dwarfed what they had spent on Datamasters. They must have also bought a competing software system that they expected to do things that we could not provide. I suspect that whoever sold them on this idea also said that no one used BASIC on the System/36 because the performance was bad. The first part of that statement was pretty much true, but the performance of well-written BASIC programs was, we later determined, roughly equivalent to that of RPG, the simplistic column-oriented language used by most S/36 programmers.

We parted with Harstans on amicable terms, but the loss of our main reference account ended the hope of concentrating on jewelry stores.


TSI’s installation at Avon Old Farms School was, by all measures, an unqualified success. It is described here. The Datamaster was perfect for their requirements, and all of the modules were successfully completed in a relatively short time.

Even before we met with them, I suspected that this installation might be the first step into a lucrative market. When I learned that Walter Ullram’s younger brother held a similar position at Westminster School in Simsbury, I grew even more optimistic. However, at the meeting that Walter set up for me with him the younger Ullram seemed only mildly interested. I followed up with a letter, but I heard nothing back.

I discovered that there was a book listing all of the private schools. It might have been restricted to New England. At any rate I mailed to the business managers of all of them and never heard anything in reply. By that time we had our hands full with other clients.


We had designed a report that provided Paul Prior of Ledgecrest Convalescent Hospital with the information that he needed to maximize his reimbursements from the state. The installation is described here. When it was completed, I decided to try to market it to the other nursing homes in Connecticut. By limiting it to Connecticut, I would only have one set of regulations to deal with.

By the mid-eighties it was becoming difficult to sell Datamaster systems. PC’s were so much cheaper. It was hard to explain why they were inferior. In response to this a developer named Gary Hoff2in Minnesota had created a PC program called Workstation Basic3 that ran programs written for the Datamaster without any conversion. TSI bought a copy and converted our report program to run in WB. I also designed add-ons so that people without the TSI G/L system could enter the appropriate numbers and the month they represented. The program would tell them how they were doing towards staying under the state’s predetermined caps.

A woman who worked for a company that sold personal computers helped me to market this product. I sent letters to all operators of nursing homes in the state. Quite a few responded, and I did a few demos and talked with a few owners. She offered them discounts on the computers. No one was ready to buy. One of them finally told me, “Our accounting firm does this for us. You really should talk with them.”

I asked Paul about this accounting firm. He said that he was well aware that everyone else used them, but he didn’t like them. He did not trust them, he said, and they charged quite a bit just to do the arithmetic for customers.

This is one of DEC’s VAX-11 780 computer. You know at least as much about it as I do.

I scheduled a meeting with the accountants. They seemed very interested in what I had done, but they wanted me to convert it all to run on the mini-computer that they had purchased from the Digital Equipment Corporation (DEC)4. I was looking for many clients, not one big one. Also, I knew nothing about their system. I had no interest in becoming a DEC programmer.

Maybe not as bad as the Vanguard TV3.

On the other hand, if I did not work with them, it was very unlikely that we would ever sell even one copy of this system, which I called CAPS5, to anyone. Since nearly every nursing home in the state used this firm, and they were the recognized experts, the project was doomed to die before it had a single installation. It was the worst (or at least tied for the worst) software launch ever.


Fortunately, our efforts in the other industry that we targeted, advertising agencies, worked out much better. That story can be read here and here.


1. The only Harstans store that still exists in 2021 with that brand is in Guilford, CT. I think that Frank Sikorski lives in La Quinta in eastern California..

2. Gary Hoff is still working in 2021 as a contract developer. His LinkedIn page is here. A few years after the CAPS fiasco Gary visited our office in Enfield. He spent one night at the Red Roof Inn and one day in our (then empty) sales office trying to get one of our System/36 BASIC programs to work on an AT using a new version of WB. He flew back to Minnesota without getting a single screen to appear. He did not get errors, but this new version of WB was unbelievably slow. He later used me as a reference account!

3. I was astounded to discover that Workstation Basic is still supported in 2021. You can read about it here.

4. After divesting most of its assets. DEC was acquired by Compaq in 1998, when TSI’s business was really taking off.

5. CAPS was an acronym. C stood for Connecticut, and S was for system. I don’t remember the rest.

1981-1985 TSI: IBM System/23 Datamaster

The beloved Databurger. Continue reading

In July of 1981 IBM announced a new system for small businesses. It replaced the system that we were familiar with, the IBM 5110/5120. Outside of the people who programmed software for small businesses, the unveiling of the System/23 Datamaster was greeted with very little enthusiasm. For one thing the model that IBM was promoting looked very much like the 5120. The cost was half as much as the 5120, but it was still a lot more than what people were paying for “personal computers” that were marketed by competitors. Most people eagerly awaited IBM’s approach in that market.

That answer would come in a few months. To us at TSI the Datamaster was just what the doctor ordered. The information about this system on the Internet is shamefully incomplete and, in a few places, erroneous. Here are details of the original announcement.

The 5322 took up much of a desk. The printed documentation shown here was uniformlyexcellent.
  • The processor was an eight-bit 8085 chip from Intel, which was a little bit surprising. IBM did not usually outsource processors, and the 5110/5120 used a sixteen-bit processor. The 256K of memory seemed more than adequate.
  • The only programming language supported was BASIC. Nevertheless, IBM offered no method of converting programs from the 5110/5120. This did not bother us much, but software companies that had put a lot of effort into systems for those computers were not happy.
  • There were two models. The 5322 looked a lot like a 5120. The 5324 came in three pieces. Its processor and diskette drives were housed in a standing steel box the height of a two-drawer file cabinet. The display and keyboard for the 5324 were separate.
  • The displays for both models used green letters on a dark background. Research had shown that this was slightly easier on the eyes than other combinations. This was somewhat important.
  • Two CPU’s could be connected to a box that held two additional diskette drives. We never saw anyone who purchased this box, which was benerally called a “toaster”.
  • IBM supplied several business applications, including accounts payable, general ledger, and payroll. We worked with several customers that had bought these packages. In general they found them extremely cumbersome and painfully slow.
  • A word processing program was also available from IBM. Unlike the business applications, the word processor was extremely good.
  • At first only two printers1 were available. Both were dot matrix printers. One printed at 80 characters per inch, the other at 120 characters per inch. Only idiots bought the 80 cps one, but it allowed IBM to quote a lower base price.
  • The most important change as far as TSI was concerned was that the BASIC interpreter allowed variable names of up to eight characters. This was a huge improvement over the 5110/5120, which only allowed one character and an optional digit.
  • The BASIC interpreter was also changed to allow up to five digit line numbers. There were a few other improvements as well. I don’t remember all of them, but I remember being very impressed with what we would now be able to do.
  • The system came with a set of templates that fit at the top of the keyboard. Each template displayed what it meant to use the key labeled “Cmd” and one of the keys. Every system command, every BASIC command, and every operation of the word processing program could be accessed by pressing two keys. This feature made it possible even for people who were not good typists to key in long BASIC programs very rapidly.
  • The components of the system were of very high quality. Many of our customers used the systems for years without ever encountering problems with hardware or the system software.
The 5324 was called “ergonomic”. It took up less desk space, and the tilt of the display could be adjusted.

I don’t know the date of the additional features, but they came within a year or so

  • A letter-quality printer that used a daisy-wheel. In my opinion, the addition of this printer made the Datamaster the best stand-alone word processor available. It was certainly superior to the Displaywriter that IBM sold for that purpose. When we got one, we used it for all of our word processing (and everything else) for many years.
  • A hard drive unit that could hold up to 30 megabytes. Up to four Datamasters could be attached to it. The software for record-locking had already been delivered in order to make the toaster usable by two Datamasters. So, the delivery of the hard drive made the Datamaster a true multi-user system. Also, access to the hard drive was much faster than to diskettes. Reliable PC networks were still years in the future, and the PC’s themselves were notoriously subject to the dreaded “blue screen of death” and other catastrophic failures.
The brains of the 5324 was in this stand-alone box designed to fit under a desk. The hard drive was the same shape minus the two diskette slots.

There were, of course, some severe limitations. Most of them were similar to limitations that the users of the 5120 also faced.

  • All of the hardware interfaces were unique and strange. This made it difficult, if not impossible, for third-party hardware vendors to develop printers or anything else that could attach to the computer. IBM had done this for years, but Datamaster prospects were not accustomed to this approach.
  • There was still no way to communicate with the system remotely. This meant that it was very difficult to market a software system to customers outside of driving distance.
  • There were no subprograms that could be called repeatedly as routines. Programs could be linked together, but all the needed data also had to be passed. The first program was erased from memory when the second was called. So, commonly used routines—such as date functions—needed to be built into every program that needed them.
  • There was no text editor with a search function.
  • The system had no graphical capability at all.
  • Calculation-intensive applications were so slow that no one could possibly use them. One company developed and tried to market a spreadsheet program through other software vendors. The instructions for showing the software to a potential client highlighted the places in which the person doing the demo should have some patter ready to distract the prospect from watching the screen. I would not have been able to keep a straight face.
  • The only backup medium was diskettes. We dreaded when users backed up because they sometimes designated the wrong drive as the target.
The system came with several “templates” that showed what the various keys did when used in combination with the Cmd key. One template was for system commands, one for BASIC, and one for the word processor.

From TSI’s perspective one of the best things about the Datamaster was that the IBM sales reps were suddenly eager to work with software companies. They could sell Datamasters to many diverse businesses, and the starting price had been cut in half. They brought us in to meet with prospects, but only when the IBM software packages were not applicable. Therefore, we ended up creating systems with little chance of being appropriate for more than one customer. It was enjoyable and satisfying work, but not very profitable.

Eventually IBM started a Value-Added Remarketer (VAR) program that allowed software companies with qualifying products to sell Datamasters. When that happened, the IBM reps treated us as competitors even though they got some credit for our sales.


1.There was really only one printer. The slow one could be “field upgraded” by an IBM customer engineer who made a slight adjustment to speed the printing.

1979-1981 IBM 5110-5120

TSI’s first computer. Continue reading

IBM 5110.

The 5110 and 5120 were essentially the same computer. The 5120, which was introduced in 1980, provided a larger display area. It also eliminated the quarter-inch tape device and added a second 8″ diskette drive. Both of these changes were important. The 5110’s display was so small that some people could not use it. Designing a system that could work with only one diskette drive was extremely difficult. If the software required more than one drive, the 5110 customer needed to purchase a stand-alone unit that could house two diskette drives. It was the size of a two-drawer file cabinet.

The 5120 and the printer that both systems used.

Both systems came with random-access memory (RAM) ranging from 16K to 48K. It had two different operating systems. One used APL and one used BASIC. A switch on the front of the console controlled which one was active. Practically all of the customers used BASIC.

IBM marketed at least one application for the system, a construction payroll system. Most of TSI’s customers had licensed that system.

Strengths: The hardware was reliable and durable. IBM supported the hardware with a maintenance agreement. If the software was licensed from IBM, telephone support was also available. In that era this was an enormous advantage. IBM’s systems engineer (hardware support guy) once spent an entire day working on TSI’s 5120 He finally got it to function correctly. If he had not been able to get it to work right, we would have expected a new unit the next day. Systems from other vendors did not offer anything comparable. 5110/5120 customers expected the system to work every day.

Data files were stored in EBCDIC format and were read by programs using IBM’s Indexed Sequential Access Method (ISAM). If the keys to the files were sorted, access to the individual records was relatively fast. Of course, it was important to keep the keys sorted. The standard practice was to sort the keys at the end of any program that added new records. The operators knew to do something else during this process until the beep sounded that meant if was finished (or something had gone wrong).

BASIC was easy to learn, and everything was well documented.

Limitations: Although the system had a fairly fast 16-bit PALM processor, the paucity of the memory made the applications excruciatingly slow.

Only one model of dot matrix printer was available. Its interface was, like all IBM interfaces of this period, not standard. So, it was difficult and expensive for third-party manufacturers to provide an alternative.

There was no hard drive available except the one offered by a third-party vendor named CORE. By the time that this product was released, the 5110/5120 was nearing obsolescence.

It was possible to connect two computers to the external floppy disk unit, but it was difficult to write software that would overcome the inherent disadvantages of two users fighting for the same diskette drives.

The 5120 console weighed ninety-nine pounds!

Yes, we had push-button phones. We were not savages.

The only interfaces were for the printer and the external diskette unit. It was not possible to connect it to phone lines or anything else to the system. If a bug was found in a program at a remote location, the developers had to talk the users through the process of changing the code. This was, of course, both dangerous and frustrating.

If more than a few lines of code was added or changed, someone often needed to visit the customer to install the changes. The alternative was to use an overnight delivery service to send a new diskette.

The BASIC interpreter used line numbers, not statement labels. The highest line number available was 9999. TSI circumvented the lack of statement labels by always using the same sets of line numbers for standard routines. The end of program routine always started at line 6000. The page heading subroutine always started at 9000. Individual lines on reports always started at at 9200. Date functions always used the same numbers.

Born free; everywhere in chains.

BASIC had some limitations. One program could “chain” another, but it was not possible to have two programs in the RAM at the same time.

It was easy to write a BASIC program with an infinite loop. Here is one:
10 GOTO 20
20 GOTO 10

Discipline was therefore required. Some programmers avoided the GOTO statement altogether, but we found it useful in specific instances.

A rose by any other name would smell as sweet, but an R4 could be a rose variety or a rhododendron or a row number or …

The most annoying problem with BASIC was that the variable names were restricted to one letter followed by nothing or a single digit. Thus, the employee number field could be called E in a program or E4, but it could not be called EENUM. This restriction made it absolutely necessary to maintain a list—either in comments in the program or on a separate sheet of paper—as to what every variable stood for in every program. It was also difficult, if not impossible, to keep the variable names consistent among all programs.

I just assumed that the absurdly short variable names were an inherent limitation of the BASIC language, and so I learned to live with it. Fortunately, I only developed one fairly elaborate system on the 5120, and so this did not cause any great problems for me. Sue maintained the systems that were written by IBM or AIS. I don’t know how much it bothered her.

This problem was corrected in subsequent hardware systems, and I had almost forgotten about it when I wrote this.

The 5110/5120 was designed for accounting and other administrative applications. It had absolutely no capacity for graphics. Furthermore, spreadsheets had not yet been invented. What do you want for $18,000?

I seem to recall that a utilities diskette included a game that involved shooting down enemy spacecraft. There definitely was a pseudo-random number generator. There was also a program for printing biorhythm charts.

Unique feature: When a BASIC program was running, the line number that was being executed was displayed in the lower right corner of the display. This provided a little entertainment for the operator when a lengthy process (such as updating a large batch of transactions) was being performed.

1972-1974 Connecticut: Working at Hartford Life

My short career at Hartford Life. Continue reading

The Hartford has two adjacent buildings. I worked in the tower.

Needless to say, I spent the first half of my first working day at the Hartford1 filling out forms. Then I was told that I would be working in the Group Department. My supervisor for the afternoon was the woman who kept score at basketball games. However, the next day I was reassigned to the twenty-first floor, the home of Life Actuarial, Individual Pensions, and Special Risk Underwriting.

The insurance world had advanced somewhat while I was in the Army. The hordes of clerks with huge Fridens on their desks were still there, but there were a few electronic calculators as well. In 1972 electronic calculators required electricity, and cost as much as the Fridens, about $1,000 each, roughly half the price of my car, Greenie! The companies took strong measures to keep them from being stolen.


Mike Winterfield
Mike Winterfield

My specific assignment was to assist Mike Winterfield,2 an actuary who had joined the Hartford when his old company (in St. Louis, I think), which specialized in variable annuities3, was purchased by ITT and folded into the Hartford. He had a vacation planned, but first he needed to submit a business plan for the VA product to his bosses at the Hartford.

My recollection is that ITT required a return on investment (ROI) of 15 percent for all of its subsidiaries. So, the algorithms that Mike developed for the business plan fixed the return ratio at .15 and juggled the other assumptions to make it work. There were no spreadsheet programs available yet in 1972.4 To evaluate the assumptions Mike designed an accountant’s worksheet with about eleven columns and I don’t know how many rows, probably one for each year. I only helped worked on this for a few weeks; I don’t remember many details. He would change one or two assumptions, I make all through the calculations to determine how much capital infusion the infant product needed to reach the desired rate of return.

These columnar worksheets were ubiquitous at insurance companies in the early seventies.

Someone else would check my work and put little red dots beside each number that had been verified. This approach, of course, meant that all of the clerical work in the department had to be done twice, but when programs were written to replace the accountant’s sheets, nothing replaced the red dots.

Finally, after many iterations everything seemed to be in order. The plan was submitted, and Mike went on vacation. A day or two later I had the dubious distinction of being quizzed tin a three-way phone call about the plan. The interrogators were Don Sondergeld,5 Vice President and Actuary, and Bob Goode, a high muckety-muck of the Hartford. They asked me several questions that stumped me. I disclosed what I did know, which was limited to how each cell on the worksheet was calculated. I am pretty sure that this information was not what they were looking for. Before I hung up I had to wipe off about a quarter cup of perspiration from the receiver for the telephone, which I shared with Sue Comparetto,6 the only clerk with an electronic calculator.

I have always had an aversion to phones. My VA experiences did not help.

The only other duty that I remember from my time in the VA area was calculating proposals for salesmen. They told us how much money prospects wanted to invest and when they wanted to receive the annuities. I, of course, had no clue what the market would do in the interim. So, we made an assumption of a specific interest rate, perhaps 6 percent. The sales agents would occasionally call to complain that a competitor’s proposal assumed a higher return that yielded a higher annuity amount or lower premium. I tried to explain that any company could in theory use any interest rate, but the Hartford’s policy was to use the same rate on all proposals. The salesmen often heard the first part, but not the second. They would try to pressure me into giving them a better quote. I never gave in, but once again the phone got drenched with sweat.

Hartford's insurance companies had hundreds of these.
Hartford’s insurance companies had hundreds of these.

For some reason I kept getting moved around. My recollection is that in my first six weeks or so at the Hartford, I sat in five or six different grey steel desks. All of the actuarial students were rotated from one area to another, but nobody moved as much as I did.

My next stop was in the Individual Pensions Department. The name was a little misleading. The purchasers of the product were small businesses, not individuals. For some of the prospective customers it worked out better to buy individual policies for each eligible employee than one group policy.

My first assignment there was to take over maintenance of the program that was used to calculate proposals for the pension plans. An actuary named Fred Smith had been doing this, but the bosses had more important assignments for him. The Hartford offered several varieties of them from single-premium fixed interest to variable annuities. The proposal program could use any interest rate to generate the premiums for a fixed-benefit plan or the benefits for a fixed-cost plan.

TT

This program ran on a computer that was located not at the Hartford but at Kaman Aerospace. The Hartford had its own computers, of course, but their use was jealously guarded by the Data Processing Department. Many actuaries were quite capable of doing the programming, but it was very difficult to get access to the mainframes. So, the Actuarial Department rented time from two different companies. Kaman had an HP 2000A; Tymshare had a DEC PDP-10. Kaman was cheaper, but Tymshare had more features. We used interpreted BASIC on both systems.

Each punched row on the tape contained one byte (character) of information. Fred Smith could read these tapes!

We gained access to the remote systems using a teletype machine connected to a phone line. Our data was stored on paper tape. I think that we stored the programs on the remote hard drive, but I might be mistaken. The teletype had the ability to take information from the keyboard and/or the tape reader. Output was printed on an 8.5″ continuous roll in 10-pitch Courier at a breathtaking ten characters per second. The unit also including a tape-punching device. Because it made a lot of noise when printing or punching, the teletype was isolated in a very small room, maybe 4′ x 8′.

Later a second unit was added. It did not have a tape device, but it printed at thirty characters per second using a round disk. It was not a “daisy wheel”; the disk was metallic and was perpendicular to the page. People came from every floor and from the Hartford’s other building just to watch that baby hum. To many it seemed magical that it could print so quickly and accurately.

Pamphlet

The pension proposal program was in good shape when Fred turned it over to me. There was an up-to-date listing, and Fred had inserted a lot of comments. I had to learn BASIC, but a thin handbook of the commands was available. BASIC was similar enough to MAD, the only language that I had ever coded in, that I mastered it fairly quickly.

The first thing that I did was stupid. I removed all the comments to make the program more efficient. In my defense:

  1. I documented what the program did did on a separate document referencing the line numbers.
  2. Programs in those days were so slow that removing the comments actually did make it slightly more efficient.
  3. My one and only programming class was six years earlier, and Господин Muchnik never taught us about documentation.
  4. I had no training for this job.
  5. Shut up; I already admitted that it was stupid.

Patti Lewonczyk7 was in charge of producing the proposals. A girl named Paula, who was, I think, fresh out of high school, did most of the data entry. One time something went wrong. I don’t remember what the problem was, but I fixed it easily. However, I had to ask Paula to run the program again for one plan—perhaps a fifteen-minute job. She got very upset and started crying. Evidently she thought that I was yelling at her. I told her that she did nothing wrong, but she was still very distraught.

My second big project in Individual Pensions involved the reports that were sent annually to the companies that had purchased one of these products. A company in New York had developed a software program to produce these reports. A group of clerks led by Carolyn DesRochers filled out coding sheets with the current census information for each plan a month or so before the anniversary. This information was supplied to the Hartford by the customer.

Same-day service with the dog.

How, you may ask, did we get the coding sheets to the software company? Someone from the Hartford transported a box of them every day to the bus depot downtown. A Greyhound bus then brought them to New York where someone from the vendor picked them up. The vendor’s software program then processed the data and created the report on attractive formatted paper and sent it to Hartford in a box on another bus. Someone from the mailroom picked it up at the bus station and delivered it to Carolyn.

Dave McDonald’s8 title was only Secretary, but that indicated that he was the top man in the department. He summoned me to his office one day to tell me that for some reason the program to produce the annual reports was no longer producing accurate information. The clerks had been observed whiting out the numbers printed on the reports by the computer and inserting corrected numbers using typewriters. This required a great deal of time and produced ugly reports that reflected badly on the company and especially the department.

I Iinterviewed Carolyn and a clerk or two about it. I also talked with someone knowledgeable at the vendor. It turned out that the vendor only allowed for a few choices of interest rate when setting up a policy. This caused no problems for a while, but by 1972 interest rates had started to rise, and the Hartford was quoting (and selling) plans with higher interest rates than the program could handle. The proposal program that Patti’s group ran calculated the interest using standard compound interest formulas. The report program, however, did not calculate interest; it looked it up on tables that someone had populated when the system was written. Evidently the designer of the program did not know the actuarial formulas, and no one had foreseen the significant increases in interest rates. I asked my contact at the vendor if their programmers could fix this. He was not sure that anyone would know how to address it.

I reported back to Dave McDonald all that I had discovered. He was gobsmacked. I never found out what was done about it, and I did not ask who had approved the purchase of a service with such a severe and obvious flaw in it. I designed thousands of programs over the subsequent five decades. I took some wrong turns, but I never made this big of a mistake.

The other task that I remember concerned lapse rates. In determining a reasonable premium for any life insurance product—all the pension plans had an insurance component—it is important to account for the possibility that whoever pays the premium might allow the policy to lapse. In general, there are quite a few lapses in the first year of life insurance policies and much lower rates later. On these policies there were inordinately high lapse rates for the first five or six years. I was asked to examine a sampling of the policies to determine what the causes were.

I discovered that most of the alleged lapses were not caused by the customers’ failure to pay the premiums. Instead, the sales agents were arranging “attained-age conversions”. The agent went to an existing customer and told them that the Hartford was now offering a new product that would be a better deal for them. He would request a quote from Patti for converting the plan. This was done by lapsing the policies on the old plan and issuing new policies based upon the current age of the policyholders. The agent was right. The customer who converted received either lower premiums or higher benefits.

Everyone (except the Hartford) profited from attained-age conversions.

It was a win-win-win-lose situation. The customer and its employees got a better plan, and the agent got a first-year commission on the same plan. Since the first-year commission on many life insurance policies is more than 100% of the first annual premium, this was a real windfall for the agents. Moreover, since the Hartford had four or five individual pension products, an agent could pull the same trick more than once. Quite a few agents had been doing this for years. The Individual Pension products were yielding good sales but no profits.

I know that there were fairly high level meetings that involved Dave, Paul Gewirtz, the actuary in our department, and the Sales Department. The sale people were adamant that this technique should not be taken away from them. Evidently some of the agents who used it were very influential. The problem was not resolved by the time that I left, but in the end my understanding is that the Hartford (and most other companies) stopped selling these products.

The A model of the HP 2000 could support 16 users, the F could manage 32. Rumors claimed that some employees on the twenty-first floor had found the built-in game programs, including a nifty one in which two people could call plays for opposing teams in a football game.

At some point someone put me in charge of the computer room and the computers. This did not involve much responsibility, but no one was suspicious if I spent time in there during slack periods. I wrote a program to produce sheets for a football pool. Each week I selected twenty competitive college games and five programs. At the bottom of the page I listed my Bottom Ten college teams. I think that I charged $1 per entry, and the person with the highest score won the whole pot, which was between $20 and $30. I might have gotten in trouble for this, but the spirit of “Don’t Ask, Don’t Tell” prevailed. I won the jackpot once.

On paydays there was also a pool that was run by Wayne Foster. At first employees bought tickets, and the person whose ticket was drawn won the prize. I bought a ticket every week, but I never won. Sue Comparetto won the pool once, and she tried to use the money to buy a round of drinks at the Shoreham Hotel, the site of the customary Friday night get-together of employees from the twenty-first floor. Since she was almost certainly the poorest person in attendance, the offer was rejected and, in fact, roundly disparaged as contrary to the spirit of the payday pool.

After Connecticut instituted a lottery, the rules were changed so that half of the pot was used to buy lottery tickets. The lucky winner got both the remaining cash and the tickets. I never participated in this, and it surprised me that any actuary would have anything to do with lottery tickets, which have a worse payoff than the numbers racket.

Don Sondergeld.
Don Sondergeld.

At some point Don Sondergeld assigned a special project to Tom Corcoran and me. The company that marketed the software for the APL programming language wanted to sell the Hartford the rights to use the language on the mainframe. The plan was to install in the handful of departments in which actuaries worked expensive APL terminals that were connected to the mainframe. A certain portion of the computer’s disk space would be allocated to the APL users. Something may have been done about sharing memory, too.

The advantage was that the actuaries would gain access to the computing power of the mainframe without being subject to the rules of the Data Processing Department. In those days tying to get new software projects approved and implemented by the DP people was an incredibly time-consuming task. The standard joke was that if you wanted to know how long a project would take, double the estimated amount and use the next higher unit. So, one hour meant two days; six months meant twelve years, etc.

APL programs require far less (in terms of number of characters) of computer code to make the same calculations. However, the APL representatives were unable to give us an example of a project that was relevant to Life Actuarial or Individual Pensions that APL could handle significantly better than Fortran or BASIC. It would be totally inappropriate for the two big projects that I had worked on. Both required extensive use of string variables. In APL a string of characters was treated as an array rather than a different type of simple variable. To me this seemed like a fatal flaw. Tom was more enthusiastic than I was. He liked the simplicity, and he had heard good things about it elsewhere.

I am pretty sure that the Hartford never purchased the product. This project was probably doomed from the start; my specialty was debating on the negative. Selling me on anything is very difficult.

The bills from Kaman and Tymshare produced a strong reaction. The Hartford bought its own HP 3000 computer and charged the Operations Research Department, not the Data Processing Department, with its management. A guy named Gerry Schwartz was put in charge of the new machine. Its operating system supported both BASIC and Fortran. The connections were over telephone lines using teletypes. Users in several departments brought over some simple BASIC programs that they had been using on Kaman’s HP 2000, and things went quite well for a while.

After my stint in Individual Pensions I was rotated to work for Jan Pollnow. My primary responsibility was to produce a monthly report, which my predecessor Chris DesRochers9 (husband of Carolyn), had been generating using a set of columnar accounting sheets.

The Hartford got its very own HP 3000.

I decided to write a BASIC program on the HP 3000 to replicate Chris’s sheets. As I added more code it got slower and slower. Eventually it brought the system to its knees. I had to set it off to run when I left at 5:00 and hope that it finished before I arrived fifteen hours later.

Gerry Schwartz blamed this on BASIC. He said that I should convert this new program to Fortran. Since I had never used Fortran, it took a while to do this. The conversion helped a little, but it still was horribly slow. Then Gerry suggested that I use “the segmenter” on the Fortran code. This involved breaking the program into pieces. This was a new concept for me, but at least there was printed documentation. I don’t remember any details of this implementation, but segmenting did improve the performance to a level of barely tolerable.

I spent a great deal of time getting this to work, but it made the monthly task much easier. The program ran without problems for a few months, but then one month’s data produced erroneous results. The problem was easy to fix, but it was a black eye for the department, and Jan called me on the carpet for it. As usual, no one checked my work.10

A few months before my departure Jim Cochran was brought in to our area to work with me. I made sure that he understood both the technical and operational aspects of the program before i started my next adventure.

* * *

I retain a few other vivid memories of my days working at the Hartford. People with a “coffee cart” came around every day at about 10 a.m. to sell coffee, donuts, and other pastries. This prompted a coffee break that became longer and longer over the weeks. Eventually the bosses warned everyone not to turn it into a floor party

I cannot remember the exact time that the buzzer rang to indicate that it was closing time. I wager that most of the clerical employees can. A large portion of the clerks, almost all of whom were female, would have all of their materials put away and their belongings gathered well in advance. The mad dash to the elevators when the buzzer sounded was somewhat comical.

Friden

Most of the clerks in Life Actuarial were supervised by Bob Riley. Almost all of them had Fridens on their desks, and they used them all day long. The machines were not 100 percent reliable. Every once in a while one would go berserk while performing division and start making awful noises. I am not sure why the clerks themselves were not allowed to unplug the calculators, but Bob always rushed over to take care of it. They generally seemed to work OK after they were plugged back in.

There must be a mountain of those Fridens somewhere. I wonder where it is.

Making copies of documents in those days was a process. At the time photocopiers were both rare and expensive. To my knowledge there was only one in the entire tower. It was manufactured by Xerox, and everyone called it the XM11 machine. Someone would carry the document from the department to the floor on which the machine resided. The courier would stand in line near the operator of the machine. Sheaves of documents were presented one at a time to the operator, who passed judgment on whether they were worthy of duplication. For those that qualified copies were made, and both sets were given to the courier.

It might have been possible to use interoffice mail to do this, but there was no telling when (or even if) the documents would be returned.

I searched the Internet for pictures of photocopiers from this era, but I found nothing that approached the bulk of the one used at the Hartford (as I remember it).


1. I did not realize this at the time, but the Hartford was owned by ITT, which was then the prototypical conglomerate. Under Harold Geneen the company acquired all kinds of businesses. When Geneen left, the ITT spun off the Hartford.

2. In 2023 Mike Winterfield was still an active member of the Hartford Bridge Club. I played with him at a tournament once, as described here.

3. The purchaser of an annuity agrees to pay an amount—all at once or in installments. The party selling the annuity adds interest and deducts expenses and profit before paying it back in installments when the purchaser reaches a certain age. In variable annuities the interest rate is recalculated each year based upon the performance of the stock market or another index. Insurance components complicate the calculations. In the early seventies few actuaries were familiar with this product.

Not available in 1972.

4. VisiCalc was released in 1979, but it only ran on an Apple II. Lotus 123 did not appear until four years later! Excel was introduced in 1987.

5. In 2020 Don Sondergeld is retired, but he is an active member of the Hartford Bridge Club.

6. There is much more information about Sue here and in subsequent entries.

7. Patti and Tom Corcoran married while I was coaching debate in Michigan in the late seventies. They had two children, Brian and Casey. In 2021 they both live in Burlington, VT, with their respective families. Patti died in 2011. My tribute to her can be read here.

8. Dave McDonald retired from the Hartford in 1995 as a Senior Vice President. He died in 2011. His obituary is here.

9. Chris died in 2013. His obituary can be read here.

10. These four words will probably be on my tombstone: Nobody checked his work.

11. XM stood for Xerox machine, but everyone still added another “machine” on the end when talking about it.