In 1999 people were predicting an end to civilization because of the imminent arrival of a new century. Art Bell interviewed a doomsayer almost every night. Key software programs were expected to crash a few seconds into the year 2000.
The calamity did not happen. A few systems probably had difficulties, but no major problems were reported at all. In the late nineties employees and contract workers at companies around the world ad devoted a great deal of time and money fixing or replacing software that would not work as designed in the year 2000. TSI was one of those companies.
The software programs that we had installed at clients and we used in TSI’s office often involved dates. For example, every business that does billing needs to know whether the clients are paying the bills within a reasonable time. This involves a comparison of the date of the invoice and the effective date of the report. The routine that makes the comparison must know the year for both dates. As long as both dates are in the same century, the familiar two-digit version of the year will suffice. However, if the invoice date is in 1999 and the report is run in 2000, the calculation must be adjusted.
This aspect of the problem was relatively simple to solve, but in large systems like the ones that we had installed there were thousands of references to dates. The challenge was to find all the situations that needed to be fixed and to implement the appropriate changes in a manner that minimized the inconvenience to the user.
From our perspective the problem was twofold: the way that dates were stored and the way that dates were collected—from data entry screens or from other files. As we entered the nineties we had three groups of clients: 1) System/23 (Datamaster) users, most of which had extensive custom code; 2) System/36 users, most of which were ad agencies that had a lot of common code, but a mixture of custom and standard programs were stored on separate media for each client; 3) a few AS/400 AdDept users; 4) TSI itself, which used a version of the ad agency system on the System/36.
I decided to inform all the Datamaster users well in advance that TSI did not intend to make their code Y2K-compliant. Most of them were not surprised; IBM no longer supported the hardware. However, the sole user at one customer, Regal Men’s Store, begged us to make their system work in 2000. I replied that it would probably be cheaper for them to buy a new system. As it turned out the company went out of business shortly after year end without purchasing a new system.
Fixing each ad agency system would have been a monstrous job of minimal benefit to anyone. By January 1, 2000, their hardware would have been obsolete for a dozen years. So, I sent a letter to each suggesting an upgrade to a small AS/400. Only a few of them took us up on the offer.
We did create a version of the ad agency software for the AS/400 that was Y2K-compliant. Our employees used it for administrative tasks for about twenty years. We had a great deal of trouble marketing it even to the ad agencies that love their GrandAd systems. Fortunately, by 1994 AdDept sales had really taken off, and we did not really care too much about the difficulties of marketing to ad agencies.
The AdDept system had to work perfectly, and the transition must be smooth. We had already promised a number of users that it would be Y2K-compliant. I intended to spend New Year’s Day 2000 watching bowl games, not dealing with Y2K catastrophes.
Why, you may ask, was there even an issue with data storage? That is, why were the dates stored in a format that caused the difficulties in calculations? The answer lies in Moore’s Law, the preposterous-sounding claim that the number of transistors in a dense integrated circuit (IC) doubles roughly every two years. In point of fact, the astounding 41 percent growth rate applied to many aspects of computing—processor speed random-access memory, and the ability to locate and retrieve large amounts of data very quickly.
For TSI’s first handful of years in business the clients stored all of their data and their programs on diskettes with a capacity of only one megabyte1. Those users crammed years worth of historical data on these thin slices of film. To put this into perspective, consider this photo of an eight-inch diskette:
Storing the simple photographic image shown above requires more than seven megabytes. So, storing a file of the size of this one image—something routinely done in 2021 by cameras, phones, watches, eyeglasses and countless other “smart” devices—would require (using the technology of the eighties) eight diskettes and perhaps an hour of computer time. Much of TSI’s systems were designed in this era in which both disk and memory were precious commodities. Good programmers were always conscious of the the physical limitations of storing and manipulating data. The prospect of a client’s system crashing because it ran out of space for its data was a nightmare to be avoided at all costs. Everything was therefore stored in the most efficient way possible. The idea of using two extra bytes to store the century occurred to almost no one in the early eighties.
I could think of several possible approaches to the storing of data to circumvent the problem of the new century. The four that we considered were:
Replace all of the YYMMDD numbers in every data file with eight-digit YYYYMMDD fields;
Keep the dates the way they were but add a new field to each record with the date in the YYYYMMDD format and use the latter for comparisons, calculations, and sorting;
Add a two-digit century field (filled in for existing data with 19);
Add a one-digit century field (filled in with a 0 for existing data).
Rejecting the first option was an easy call. All of TSI’s systems had hundreds of programs that read fields by their position in the record, not by the field name in the database. If the total width of the fields that preceded the field in question, was, for this example, 50, the program read the six-digit date field beginning at position 51. This was not the recommended method, but it had always worked better for us for reasons that are too wonky to describe here. The drawback was that whenever it was necessary to expand the size of a field, it was also necessary to change or at least check every line of code that read from or wrote to the file. This could be an imposing task for even one field. Since a very large number of files contained at least one date, almost every statement that read, wrote, or rewrote data would need to be checked. If it needed to be fixed—or even if it did not seem to need fixing—it needed to be tested thoroughly with data that contained dates in both centuries. We had no tools for the testing, and every situation was at least somewhat unique.
Large and dangerous.
Attempting this for every date and season field was such a large and dangerous task that the only way that I would consider it was if, at the same time, we abandoned reading and writing by position and replaced it with reading by field name. I thought about it, but I decided that that approach would result in even more work and was only a little bit less dangerous.
I reckoned that the other three methods were roughly equal in difficulty and in the amount of time required for implementation. I eventually decided that the one-digit method would suffice.
There was one additional issue in the AdDept system. The first two digits of the three-digit identified the year. So, it was necessary to add a century field for every file that included the season number as well. The season was a key field2 for many files. Fortunately, it did not seem to be necessary to add the century to the construction of any of those keys.
The other issue concerned data entry. Users of TSI software were accustomed to entering dates as a number in the form MMDDYY, the way that dates are commonly written in the United States. The programs validated what had been entered by converting the number into YYMMDD format and checking that each piece was legal. The check for the year normally involved checking to make sure that it was within ten years of the system date. So, every validation routine needed to be changed because the date entered and the system date could be in different centuries.
All of the work was to be done on the AS/400. The first step was to locate all of the files in both the AdDept database and the agency database, which we called ADB, and to add century fields that defaulted to 0 at the end of the files. At the same time, every program that wrote records to these files was found. A peculiarity of BASIC helped us find these programs. BASIC associates numbers with files in each program, and TSI consistently used the same numbers for files. Thus every instance of updating of the job file contained the phrase “WRITE #22”.
A single callable program was written to calculate the century. Its only input was the two-digit year. It was incredibly simple. It set the century to 1 if the year was less than 80 (the year that TSI moved to Connecticut); otherwise it set it to 0. In BASIC it required only two lines of code: CENTURY=0 IF YR<80 THEN CENTURY=1
This approach will work flawlessly until the program confronts dates that are in the 2080’s. If anyone is still using code produced by TSI when that happens, someone will need to come up with a rule for setting CENTURY to 2. I don’t lose any sleep over this possibility. Yes, you could say that we just kicked the can down the road, but who is to say that roads and cans will even exist in 2079?
A much more time-consuming problem was correcting all of the programs that produced reports or screens in which data was sorted by one of the date or season fields. I set up an environment for the Y2K project that contained both programs and data. Whereas it seemed important to insert the century field into all the affected files as soon as possible, the reports and screens would work fine for a few years and could be addressed one at a time.
I evaluated this part of the project to involve mostly busy work—repetitive tasks with almost no important decisions and no creativity whatever. We had hired a college student to work with us for the summer. I thought that Harry Burt and I could set up the projects for him. Harry, who had experience as a college-level professor, could supervise him and check his work. This method did not work out at all, as is described here, and it used up some precious time.
I may have overreacted to this setback. I decided to make this a very high priority and to assign it to myself. One of the programmers surely could have done it as well as I did, but I did not want to assign it to any of them because I did not want anyone I was counting on to consider their job as drudgery.
So, for several months I spent every minute of time that I could find fixing and testing programs to handle the century fields correctly. A few cases were trickier than I expected, but the coding was completed, tested, and installed before any of our clients started planning for the spring season of 2000, the first occasion that would requir the code.
I am not certain about when this occurred, but at some point I received a letter from, as I remember it, someone in the legal department of Tandy Corporation. It said that the company had received a letter from someone named Bruce Dickens demanding that Tandy pay him a proportion of its gross income every year to license the software that handled the Y2K problem because it must have used the technique of “windowing”, for which he had been issued a patent by the U.S. patent office.
The letter, of which I cannot find a copy, contained a technical description of the term3 as described in the patent and asked me two questions: 1) Did the software that we installed at Tandy use this technique? 2) Would TSI indemnify Tandy Corporation in a lawsuit over its use?
I answered both questions truthfully: 1) “This does not sound like what we used.” 2) No.
Dickens sent demands for payment to all of the Fortune 500 Corporations. He said that if they did not agree, the percentage of income required for the license would be increased.
I have searched high and low to find out how this situation was resolved. I know that the U.S. Patent Office scheduled a review of the patent, but I could not find a report of the outcome. I also could not locate any information about whether any of the companies that he had extorted ever paid anything to him or the company that he reportedly founded, Dickens2000. I doubt it. I found no evidence that he actually sued any of them either.
If I had been asked directly whether any of our code calculated the century using the year, I would have changed the code listed above to remove the IF statement and simply set CENTURY=1 in all cases and then answered “No”. A few months into 2000 employees of the companies that used the AdDept system no longer entered twentieth-century dates on new items, and the programs only used the code to assign a season when new items had been entered.
We did not charge any of our clients for the Y2K fix. A few people told me later that this was a mistake. Since our customers depended upon AdDept, and there was absolutely no alternative system available, we probably could have gotten away with charging them. The companies may have even set aside funds for this purpose. However, all of the AdDept users had software maintenance contracts, and I considered it our duty to keep their systems operational.
1. A bit is a binary storage unit; it has only two possible values: off or on. A byte contains eight bits, which is enough to store any kind of character—a letter, number or symbol. A megabyte is one million bytes, which is enough to store approximately eighteen Agatha Christie novels. However, it is not close to enough to store even one photograph. Videos require vastly more storage.
2. A key is a set of fields that uniquely identifies a record. A well-known key is the social security number. The VIN number on a car is also a key. A zip code is not a key because neighboring residences have the same zip code.
3. The most readable and yet comprehensive description of the windowing technique that I have seen is posted here. The application for the patent, which was granted to McDonell-Douglas in 1998 (long after everyone had decided on the approach to use), was (deliberately?) designed to appear much more elaborate than the two lines of code that we used.
TSI’s first, last, and best programmer was Denise Bessette. For three decades she was one of the most important people in my life. More details about her relationships with TSI, me, and the rest of the crew can be found here.
During the years that Denise worked only part-time most of the programming burden fell on my extremely narrow shoulders. By 1987 it had become too much. We needed to hire a full-time programmer. I placed ads in the Hartford Courant and the Journal-Inquirer. It was not a good time to be hiring. The state’s unemployment rate was heading toward a record low of 2.8 percent, and the demand for programmers far exceeded the supply. I understood that a small firm like TSI would be at a disadvantage when competing with giants like the insurance companies. Besides, our office was in a converted barn, and we were not able to offer any benefits to speak of.
Sandy in the kitchen in TSI’s East Windsor Office.
A few people responded to our ad. The only one that I had any interest in hiring was Sandy Sant’Angelo, whose name was Sandy Scarfe when she started at TSI. She had taken a few programming classes. She worked for the Springfield (MA) Public Library system. A major part of her job there was helping to set up the new computerized system for keeping track of the books. This was not very close to anything that we did, but at this point my choices were to hire her or start the recruiting process over. I chose the former.
Sandy turned out not to be a great coder, but she had other traits that I valued highly. She learned how to use the computer systems rather quickly, and if a project was well-defined, and I provided her with a somewhat similar program to use as a model, she was eventually able to save me a little time. What I liked the most about her were her dependability and her attitude.
Harry Burt, Lucia Hagan, Chris Bessette, Sandy, and Denise at the summer outing in Old Saybrook.
Unfortunately, the great bulk of our work in the nineties was quite complicated, and it became more and more difficult for me to find appropriate projects for her. One thing that I had noticed was that she was good at talking to the users at our clients’ installations. She had a cheerful demeanor, and she was pretty good at getting to the bottom of problems.
At the time TSI’s office had two telephone lines1, a generic number that we published in our promotional materials and a support line that we provided to our clients. I decided that Sandy’s primary responsibility should be answering calls on the support line. If they were simple questions, she could deal with them immediately. Otherwise, she recorded them. At first we kept track of the problems on paper, but soon we devised a simple system for recording them in a database available to all the programmers.
Denise, Sue, me, Sandy, Lucia, and Harry. Chris or a restaurant employee must have taken this photo.
This system worked pretty well. The key question that we asked was whether the problem was holding up the client’s work. If it was, the problem was automatically escalated. In nearly all cases these problems were addressed the same day.
I did not often work closely with Sandy. Actually, no one did. Her telephone voice sounded fine on the other end, but for some reason it really carried inside the office. I had to move her desk away from the programmers’ area.
Although I had hired Sandy, when Denise took over application development, she became the boss of all of the programmers. After a few years, Denise, who knew Sandy’s limitations, decided to eliminate her position. The meeting in which she was the terminated was very hard for me to witness. Sandy broke down and cried. I understood that Denise had made a business decision, but I doubt that I could have done it. By then I thought of Sandy as part of the TSI family. Nevertheless, I never considered overruling Denise’s decision.
Sandy, me, and Harry at the door to the TSI office in East Windsor after a blizzard.
I don’t have a lot of vivid memories of Sandy. She got married after she came to work with us, and she seemed happy. Her attendance record over the years was nearly spotless. She also attended all of TSI’s summer outings and Christmas parties.
I only recall her expressing a strong opinion about one thing. She loved the Harry Potter books. Her endorsement, however, was not sufficient to prompt me to dip my literary beak there.
Sandy was the person who alerted the rest of the office about the attacks on 9/11/2001. Everyone else in the office was shocked at this, but I had spent more time in airports than the rest of them put together. The airport security by that time was unbelievably lax. I had concocted in my mind at least three ways of sneaking a gun aboard a plane. It was also no surprise to me that plenty of people in the world who despised the United States for its arrogant and interventionist foreign policy and its unquestioning endorsement of anything done or said by Israel.
I find it personally embarrassing that I know so little about Sandy, a person with whom I worked for more than a decade. I just let her live her life as she wanted to and expected her to come in every morning. I can never remember her asking for anything.
After assigning Sandy to answering support calls, I reckoned that we needed another programmer. The Internet was still in its infancy, and so the process again involved expensive want ads in the local papers. Before finding someone who fit the bill I hired two different people, neither of whose names I remember.
The first was a woman in her twenties or maybe early thirties who already had programmed in BASIC at another company. I hired her. I was pretty excited about the prospect of working with her. It seemed likely that she might be able to get up to speed in record time. On the first day she appeared in the office at 8:30, TSI’s starting time. I immediately put everything aside to help her understand how we programmed and to go over some of the peculiarities of the hardware and operating systems.
If I had a sick pet, I would also ask permission to go home, but I don’t think that I would quit my job.
At some point she must have received a phone call. It only lasted a couple of minutes; I thought nothing of it. However, just before lunch she told me, “I’m sorry, but this won’t work. My dog is sick, and I need to be with him.” I don’t remember what I replied, maybe nothing.
I immediately initiated another job search. This time I hired a guy in his twenties who claimed to have done some programming for a previous employer. I spent a couple of weeks training him, and he seemed to be making little or no progress. I began to doubt that he had ever written a program, or at least one that did approximately what was required.
I have only a vague recollection of what he looked like or anything about his personality. I do remember that he was into the martial arts and worked out. He was in very good shape.
I probably would have worked with him for another week or two before deciding, but we had a twinax connectivity problem. As is explained here, the individual terminals and PC’s were connected to the server via twinax cabling. Each station was dependent upon the cabling, pigtails, and settings of the other devices on the line. Some of our cables were very long. We ordered these custom-made from a company in New Britain. They were expensive. Moreover, the company needed a little time to make them, and it was located forty or so miles from TSI’s office.
It was an “all hands on deck” situation until we got the situation resolved. Everyone was checking connections. I asked the new programmer to connect one of the cables to one of the devices. I showed him how their were two holes on the “pigtail” and two pins on the end of the cable. The pins, of course, fitted into the holes. Once the connection was made, a cap on the end of the cable could be turned so that it was impossible for the cable to come loose. I honestly thought that it was impossible for anything to go wrong. I had done this many times, and nothing had ever gone amiss.
Those two pins are not supposed to lie flat next to each other.
We spent an hour or so trying to get the line to work, but we had no success. I eventually examined the connection that this new fellow had made. The pigtail was tightly attached to the cable. I unfastened it and looked inside the head of the cable. Both pins were bent at a 90° angle, one to the right and one to the left. They resembled a pair of arms stubbornly crossed on someone’s chest. I would have bet that no one was strong enough to do this. To this day I had no idea how he accomplished this feat.
I was so angry that I had to retreat into Denise’s office for a few minutes so that no one could see me. I decided on the spot to fire him, but I waited until the end of the day to do it.
I thought at first that we would need to order another custom cable. However, we found a spare cable, and with a few adjustments to our wiring scheme, we were able to get the connectivity resumed within a half hour.
Casual Corner’s headquarters as viewed from South Rd. The pond was usually full of geese.
Twice when I advertised for a programmer, I received applications that I could not believe. One was from the lady who was IT director at Casual Corner3, a large retail chain. Their home office was in Enfield. My customary jogging route took me right past their complex. The IT department even had an AS/400! Casual Corner did not advertise much, but with and “in” we might even get an AdDept installation out of it. I tried to contact her, but she never scheduled an interview.
The other guy was retired. He had been an IT director at a large company. He came in and talked with me. He said that he would work cheap. He just wanted to write code. I don’t know whether he would have been a good programmer or not, but my primary interest was elsewhere. At the time we were just beginning to try to work with IT departments, and the process always left me frustrated. I thought that having this guy on TSI’s team might help me learn how managers of IT departments made decisions.
It was a close call, but I decided not to make him an offer.
I think that Steve might be setting up TSI’s F10.
Instead I hired a much younger guy, Steve Shaw. He had been an RPG programmer at Riverside Park4 in Agawam, MA. He picked up BASIC pretty quickly, and I was able to give him reasonably challenging projects. I really liked working with him. When he started his coding was a little sloppy, but the quality improved quickly. When I told him this, he seemed slightly insulted.
While he was working at TSI Steve acquired a multi-unit property in Massachusetts. I could not understand why he wanted to be a part-time landlord. To each his own.
Steve was something of a daredevil. He purchased a jet ski while he worked for us. At some point he disclosed that he had been in a motor cycle accident in which he lost a number of teeth. I wrote a little song to cheer him up. My sister Jamie and I performed it for him in the office. It was a smash hit.
I found a copy of the lyrics:
Home, brain, nerve, heart (teeth not in photo).
On corn cobs I’d be gnawin’. I could graze upon your law-n. It is my firm belief. My dentitions would be so neat. I’d devour piles of roast beef, If I only had some teeth.
Oh, I could eat a pie. I’d chew up all the steaks that you could buy. I’d masticate on pork chops bye the bye. If you object, I’ll bite your thigh.
From ear to ear I’d be grinnin’. Young girls’ hearts I’d be winnin’. I’d steal them like a thief. I would floss away my tartar, and stop actin’ like a martyr, If I only had some teeth.
Music by Harold Arlen; Words by Mike Wavada
TSI’s Christmas party with the Edward Owen Company at the Nutmeg House: Jamie Lisella, Steve, Doug Pease, Ken Owen, Denise, Sandy, someone, me, someone else.
Steve only worked with us for about four years. I appreciated that he might see it as a dead-end job. However, the work was, I think, potentially very exciting. We were solving problems that no one had addressed before for large corporations that everyone has heard of. I tried to talk him into staying, but there was no way for me to argue that he could ever climb the corporate ladder at TSI. We did not have a ladder.
The next programming hire was Harry Burt2, who was almost exactly my age, forty-something. He had a degree in math, and he had programmed in BASIC. He had been a vice president at a bank in Simsbury (I think) that had had closed under fairly suspicious circumstances that did not involve Harry. I hired him and terminated the job search at the end of my interview with him.
Harry mostly did programming projects for us. However, I also assigned him to monitor the work of Fred Pease in the huge Y2K project, which is described here. Fred was a college student who had never had a job before. The plan was for him to work part-time at TSI for the summer. He wanted to set his own schedule. By his own omission he tended to stay up late playing video games. Sometimes he stayed up all night.
That much was OK, but Fred constantly changed his schedule without telling Harry or anyone else. Harry had to ask him every morning how long he was going to work. He usually said “Until 11:30” or “Until 12:30”. The last straw was when he said “Until something-thirty”.
Fred’s work was also slipshod. I decided that I needed to take the project more seriously. If I was going to need to check every program anyway, I decided to do it all myself. Frankly, I did not want to assign such a tedious and unrewarding task to any of my good programmers. I did not want risk losing them. I took it on as a sort of penance; I should have seen it coming back in the eighties.
Sandy and Harry are on the left. Myself (hat), Denise and Chris are on the right. This photo is from our cruise on the Connecticut River.
Harry (who was NOT hairy—I thought of the Fuzzy Wuzzy rhyme whenever I saw or heard his name) was a great fit for TSI for at least a decade. After a couple of years I began to worry that Harry might realize that there was no path for advancement at TSI and decide to look for work elsewhere. After all, he was definitely overqualified for his job.
I decided to give Harry a small percentage commission on our software sales every month. I think that this was probably a good idea. He could see that he was profiting from our delivery of new software.
While he worked for us he also taught college-level math classes in the evenings. At some point in the twenty-first century Harry quit in order to become a full-time teacher . He told Denise, who was his boss, that he was having trouble dealing with the pressure at TSI. The environment did not seem pressure-packed to me, but from my office — even with the door open — I could not hear any conversations.
I liked Harry a lot. For a time we were the only two males in the office, and it was very nice having someone with whom I could discuss a football game. Also, since we were almost exactly the same age, we had many of the same cultural landmarks.
Harry is between Doug Pease and Denise. A little bit of Sandy is visible on the right. I think that this was the day of our Christmas dinner after the trip to Hawaii.
Harry’s best friend was Vinny, his barber. Harry often told amusing stories about Vinnie or recited humorous quotes. I devoted a fair amount of effort to buying appropriate (and usually light-hearted) Christmas cards for the employees. One year I actually found one that featured a barber named Vinny.
Harry had a 24/7 tan. I assume that he went to a tanning studio. He did not seem like the kind of person who would do that, but you never know. One of my proudest achievements was to compare tans with him on my return from Hawaii. For the first and only time, my arm was darker than his.
Denise recruited and hired all of the new programmers who worked in our office in the twenty-first century. By this time we were using Monster.com for hiring. It was cheaper and better than newspaper ads, but it was still a time-consuming practice that tied up TSI’s most productive employee.
August 16 is National Airborne Day.
Brian Rollet was the first person that Denise hired. I remembered that he started while I was in Hawaii for the sales/vacation in December of 1975 (described here). I brought everyone back souvenirs for the employees. For Brian, whom I had never met yet, I purchased a hula-dancing bobble-head doll.
Brian was an Army vet. In fact, he was Airborne. Had I been doing the hiring, this would have given me pause in two different areas. 1) Why would anyone with a marketable skill like programming ability volunteer for three years in the Army? 2) Why would anyone jump out of a perfectly good airplane?
He also had a pretty long commute. He lived in Ware or Belchertown — one of those towns near the Mass Pike. There is no way to get to East Windsor from that area without driving through Springfield.
Denise was most upset about one of Brian’s most unprofessional traits — dozing off in the afternoon. She asked me what I would recommend. I told her that the obvious solution was caffeine. Who ever heard of a programmer anywhere who did not consume immense amounts of caffeine at work?
Brian, Harry, Denise, and Sandy at Mystic Seaport.
My second choice was to advise Brian to work something out with Harry, who was in the adjoining cubicle. If I were in Brian’s situation, I would have asked Harry to throw an eraser at me whenever he saw me nodding off. That would have worked, wouldn’t it?
When Denise called him on the carpet about it, Brian’s solution was to eat only salads at lunch. That might have helped a little, but Denise finally had to let him go. I don’t think that she was too satisfied with what he produced while he was awake anyway.
She confided to me that she would never again hire anyone who had been in the military.
Denise’s second hire, Michael Davis, worked out much better. He got up to speed very rapidly, and Denise really enjoyed working with him, and she definitely got to depend on him. Unfortunately, he did not stay at TSI very long. He moved to Pittsburgh, where he had family or a girlfriend or something.
Lucia Hagen, Harry, and Michael.
The good news was that he liked the work at TSI well enough to work for us remotely for a period after he moved away. So, the transition was not too difficult. Of course, he could not answer the support line from Pittsburgh.
Michael’s boat.
My most vivid memory of Michael was on our summer outing at (I think) Rocky Neck State Park. He took me out on his small sailboat. People from Kansas do not often get opportunities like this. Of course, he did all the sailing. My only job was to duck my head down by my knees when he decided to swing the sail around.
I remember that after Michael had been at TSI for a year or so he decided to buy a new car. Well, not a NEW car, but a NEWER car. He chose a Volkswagen; I don’t remember the model. The few times that I shopped for a car I never considered buying a used one. I would be too afraid that I was just buying someone else’s problems. Nevertheless, Michael seemed satisfied with his purchase.
Sean Finnegan.
I don’t remember much about Sean Finnegan7. In fact, I had to ask Denise about him. He worked for TSI for two months in 2010. He was apparently a pretty good programmer, but he had difficulty talking with clients on support calls.
Jason Dean8 lived in the Springfield area. Before coming to TSI he had worked in Friendly’s IT department. He joined us in October 2007 and was still employed when we closed down the company in 2014.
Denise got along with Jason nearly as well as she did with Michael. She was very satisfied with his attitude and performance.
I did not really get to know Jason too well until Denise started working remotely in 2013. One thing that I quickly learned was that he was a terrific bowler. He had bowled at least three 300 games, which blew my mind. He had quite a few bowling balls. He told me that getting the ball to spin correctly depended on both the surface of the ball and the surface of the lane. So, different balls were needed depending on the condition of the lanes..
I was very surprised to learn that Jason’s bowling balls had only two holes. He did not have a hole for his thumb.
Jason knew my bridge friends Bob and Shirley Derrah from bowling in Springfield.
Jason and his wife were, in my opinion, fanatical about coupons, Groupons, and all other ways of obtaining discounts. They were always shopping for bargains. They switched their cell service from Verizon to T-Mobile to save on phone charges. However, the T-Mobile phones got no signal in their apartment. They got their money back, but it was a big hassle.
Jason had a son when he started working at TSI. His second son was born quite prematurely, and it was touch-and-go for a while, but he pulled through and was quite healthy the last that I knew. The family also had three rescue cats who were too eccentric for my tastes.
In his middle school in Springfield Jason had twice been a spelling champion. He was the only other person whom I have ever met who competed in the national spelling bee.
Jason and his family loved Disney World. They spent every vacation there, and they always stayed in the same Disney hotel. They monitored the situation very closely and always made reservations on the first day that the discounted fares were offered.
Jason had an older brother who lived at home with his parents. He spent most of his time in the basement playing Worlds of Warcraft. Although he had never worked, Jason insisted that he was a brilliant guy. He urged Denise to consider hiring him. I don’t remember the details, but he never came to the office. I am not sure that he could drive.
Jason actually contacted the Dr. Phil show to try to get them do do an intervention to help his brother get out of his shell. His parents vetoed the idea.
Jason and his parents were very conservative. He could not believe that Obama had defeated Romney in 2012. He told me that he suspected that there had been voting fraud, but he readily admitted that he had no evidence.
1. By the time that we moved the office to East Windsor, CT, in 1999 TSI had eight phone lines.
2. In 2021 Harry Burt is teaching math at Naugatuck Community College. His LinkedIn page is here.
3. Casual Corner closed all of its stores in 2005. Since then the headquarter building in Enfieldhas been used by Brooks Brothers, which also is now in bankruptcy.
4. Riverside Park was acquired by Premier Parks in 1996, a couple of years after Steve started at TSI. The name was changed to Six Flags New England.
5. Steve Shaw sent me emails a couple of times. In the one in February of 2000 he reported that he was working at the Phoenix, and they had sent him to classes on Websphere and Java. However, we never got together. Because he has such a common name, It was difficult to locate him, but I finally found his LinkedIn page. You can see it here.
6. I think that Brian Rollet lives in the Ware, MA, area in 2021.
We installed at least part of the GrandAd system at all of the companies listed below. A few may have actually been Datamaster clients. My recollections of some installations are very dim. In a few I had little or no involvement
Visitors to O&P went through this red door on Elm St.
Although Keiler Advertising evidently had a famous red door in the twenty-first century, in the eighties the most famous red door in Hartford’s advertising community belonged to O’Neal & Prelle1 (O&P), the agency that was housed across the street from Bushnell Park in Hartford. Our negotiation was with Bill Ervin2, who was, I think, already the president of the agency.
We got this account because of a phone call from Paul Schrenker, the graduate student hired by our marketing company (described here). Paul called dozens of presidents of ad agencies. Bill responded that he was interested in our system. This was probably the only positive outcome from that endeavor.
I seem to remember that O&P bought a model 5364 from TSI. I do not remember doing any custom programming, but we almost always at least customized the invoices that they sent to clients.
I worked mostly with Liz Dickman, who was the bookkeeper. Of all of our agency liaisons, she was among the best to work with. She was able to do the reconciliations by herself more quickly than anyone else. I am not sure who drew the following beautiful schematic of the installation. It certainly is not my handiwork.
Evidently we installed a 5363. A 5364 would not have supported so many devices.
Here are my most vivid memories:
On one visit I had to carry something down to the basement. Halfway down the staircase I felt a stabbing pain in my right knee. It did not last, but it was the first time that I had felt pain there since I recovered from the operation in 1974, as described here.
If I was at O&P at lunch time, I generally bought a couple of tacos from one of the food trucks. I then sat alone on a bench in Bushnell Park and chowed down. One day while I sat with my legs crossed a starling popped up on my right shoe, which was about six inches off the ground. He perched there for at least a minute or two to see if I would reward him for his clever trick. When I failed to do so, he flew away.
I recall Liz informing me that she planned to take the CPA exam as a flyer. She said that she did not study for it, or at least not much. She was legitimately shocked when she later learned that she had passed. Perhaps it dawned on her that she was suddenly overqualified for her job. They made her a vice-president.
The installation really went downhill after Liz departed. The guy who operated the computer called TSI and asked for some training. We scheduled a day for him at our office in East Windsor. He was shocked when we billed O&P for it. Evidently either no one told him that TSI had a contract with O&P that clearly designated how much free training (plenty) they received, or someone gave him some bad advice. O&P didn’t pay the bill, and shortly thereafter the agency announced its liquidation.
I am pretty sure that we sold a model 5364 to Eric Tulin Inc.4 of Hartford, CT. It might have been TSI’s developmental system. I can remember spending a few days at the office on Hamilton St. The primary operator was a guy, but I don’t remember too much about him. I must have met with Eric as well, but I don’t remember the occasion.
The agency was not very large at the time. I don’t think that they had more than five or six employees.
I recall even less about Knorr Marketing5, which was (and still is) located in Traverse City, MI, which is in the northwest part of Michigan’s lower peninsula. The agency, which must have already purchased a S/36, called TSI one day out of the blue.
We sent them some materials, and even though they had never sen a demo, they purchased some portion of the GrandAd system. We sent Kate Behart to do the installation and training. Because we used almost exactly the same system for our record-keeping, Kate knew the accounting and job costing portions of the system. So, I assume that we did not install the media portion.
Kate must have done a good job. We hardly ever heard from them, but Knorr Marketing sent us a Christmas card for many years.
Another mystery GrandAd client for me was Brannigan-DeMarco of New York. They purchased their hardware from IBM. Sue took care of this account. I am not sure how much of the GrandAd system they used.
Sue worked closely with Angela Vaccaro, who was the primary operator of the system. She called for support every few months. Sue always took care of her problems.
Similarly, I know very little about Sullivan & Brownell6 of Randolph,VT. Sue handled everything about this account, too. She visited them occasionally. Sue did not need much of an excuse to schedule a trip to Vermont. She has always loved the whole state.
The only thing that I recall about the account was the fact that the media director was a Black woman. That would not ordinarily be even a little surprising, but this was, after all Vermont. In 1990 there were a grand total of 1,951 Black people in the state, including exactly zero lawyers and judges. In fact, only eleven Black people in total lived in Randolph.
Sue told me that the media director and her husband had a farm in the vicinity. Sue told me that she might have stayed overnight there once or twice.
Using a chain saw the husband carved a fox out of a tree trunk and gave it to Sue. It sat placidly on guard out in the grass just beyond the parking spaces of our office in Enfield for many years. In 2021 it wards off coyotes in our back yard. I took a photo of it. It has seen better days.
I handled most of TSI’s interactions with Knudsen-Moore (K-M), an advertising agency located in Stamford, CT. I thought of this as an important account because it finally gave us a toehold in the southeastern (wealthy) part of the state. I also thought that it was cool that one of our clients did business with both King Oscar and the WWE (then known as the WWF).
The audience for my demo was the seventy-two year-old7 bookkeeper whose name was Irene. I must have brought a PC, our 5364, and a terminal that we were evaluating for another client. Its screen was very large for the time. This became important because the bookkeeper had very bad vision. In fact, she later confided to me that the reason that she insisted that they choose TSI’s system was because of that terminal. Ordinarily my strikingly good looks are the deciding factor, but as I mentioned, her vision was poor.
The McMahons never showed up at their ad agency when I was there.
It took us several months, for reasons that will soon be apparent, to get them up and running. During this period the agency changed hands not once, but twice. Its final name, which persists to May of 2021 was CDHM8.
The holdups for going live with the system were the balances in accounts payable and accounts receivable. The values in these accounts are generally positive for A/R and negative for A/P. If a vendor bills you $100, and you immediately bill the client with a 10 percent markup, A/P will have a transaction with a value of -100, and the entry in A/R will be +110. There will also be offsetting entries, of course. The point is that every company should be able to justify its A/P with a stack of unpaid bills from vendors and its A/R with a stack of open invoices sent to clients.
I entered in all of the open A/P and A/R into GrandAd. I printed a list of each with totals. The system’s totals did not agree with what Irene’s hand-written worksheets said were the current balances. Not only that; her balances, which were reflected in the company’s official general ledger, had the wrong sign! The A/P showed a positive balance, and the A/R showed a negative balance. According to these figures the agency’s vendors owed them money, and they were in debt to their clients!
Irene still insisted that her figures were right. I asked for a meeting with the president, Bill Hoag. The bookkeeper attended, as did a couple of other people. Their accountant was not present. I explained the situation with words similar to those of the previous paragraph. She insisted that her numbers were correct because she had checked every entry. She knew this because there was a little dot next to each figure. Much screaming ensued.
The lady had been using the “balance forward” method. After each transaction a new balance is calculated. This is OK, but at least monthly this balance must be checked against the list of invoices. She had NEVER done this. I later looked over her sheets. They were replete with errors. She simply could not read her own handwriting.
The irony of the situation did not strike me until much later. If someone had caught this egregious error earlier, we would not have won the contract. She recommended us solely because of the big screen on the terminal, remember?
How in the world could an agency with books in this deplorable condition be sold twice? I don’t know.
They asked the bookkeeper to retire. The guy that replaced her was, in some ways, worse.
I am pretty sure that his first name was George. I don’t remember his last name, but I do remember that he insisted that any communication to him include the title “Esq.” Now, I don’t pretend to know who gets to use that title, but I would be willing to bet that not many of them lived at the YMCA, which is where this character lived. George got into arguments with us all the time, and he was abusive to TSI’s employees.
For the first and only time, I finally called the agency’s president about George’s behavior. He said that he would look into it. He called me back less than hour later. He said that the guy had not been in all week, and he was now officially terminated.
The next week the president told me that they had hired a new person. I think that his name was Roger. He was very easy to work with, and he had the record-keeping straightened out in short order.
I drove to CHM an least half a dozen times. I never saw Vince or any other McMahon. It was a big disappointment.
Sue handled the account of Charmer Industries of the Astoria section of Queens. The company distributed wine and liquor products. This was probably a referral from Quique Rodriguez, an IBM rep with whom we had a good relationship.
Sue and I drove there on, as I remember it, a Sunday, carried their computer and printer into the building, and made sure that they were working. Then we drove back to Rockville. I found the whole drive within the city terrifying. I wanted to stop, get out of the car, and kiss the earth when we were back in Connecticut. I have been to NYC many times, but I have never driven inside the city limits.
Ed Wolfe.
Charmer had a lot of companies. One specialized in the design of point-of-sale products in bars and liquor stores. Over the years it went by a number of names, including ACC Marketing and the Sukon Group. These were the people who used our system.
Our final liaison in the nineties was Ed Wolfe. As I recall, the company later decided to purchase a small AS/400, the system that replaced the S/36. The AS/400 is described in some detail here. I took the train to New York a couple of times to help with the setup of the new system. Ed was a nice guy and a good client.
Doherty-Tzoumas occupied this building on Dwight Street in Springfield.
I have always thought of Doherty-Tzoumas of Springfield, MA, as a bizarre advertising agency. Dianne Doherty9 was the president. She was totally unsuited to running this agency or any other business. Her husband was a very prominent lawyer. I think that he must have set her up in this business, perhaps for tax reasons. I can only speculate.
Her partner, Marsha Tzoumas10, knew her way around advertising and the business world at least a little, and she was very nice. I felt a little sorry for her.
The agency certainly tried hard to succeed. It always seemed to be a beehive of activity. Quite a few employees had been hired. They liked to hold “focus groups”11 for their clients’ products or services, an idea that I had never previously encountered.
I worked with Marsha and the agency’s bookkeeper to set up the system, and for the most part it seemed to go rather smoothly. However, when we showed the reports for the first monthly closing to Dianne she was overwhelmed.
Dianne hired a financial consultant to help her run the business. He might have been the company’s accountant, but that is not my recollection. I was in a few meetings with him. Most of them were fine, but in one meeting we were discussing the general ledger. Dianne made a very peculiar request. She asked if there were just two or three accounts that she should concentrate on. The request was, in my opinion, absurd. There might be a few that she could pretty much ignore, but to try to focus on any small subset of a company’s books was unthinkable. Most small businesses fail, and there are many paths to failure.
Nevertheless, the consultant took the bait and named a few accounts. I can’t even remember which ones he chose. I assume that cash was one. It is generally a good idea to know how much cash you have. He probably also picked A/P and A/R.
At any rate I knew in that instant that this business was doomed. I was right. In 1991 we received a letter from Dianne’s husband Paul proclaiming that the business was being liquidated. It was the only such letter that we ever received from an ad agency. They owed us less than $100, and so we did not consider suing for it.
I remember that on one occasion Marsha mentioned that she was looking for a good book to read. I recommended Larry McMurtry’s Lonesome Dove. I wonder if she took my advice.
In 1987 Rossin Greenberg Seronick and Hill (RGS&H)12 was the hottest agency in Boston, MA. The president, Neal Hill13, was not an advertising guy. Although I never met any of the other three partners, I am sure that they all had a good deal of advertising experience.
The agency had enjoyed two years of explosive growth. It wanted a computerized system for word and data processing. Neal and Ernie Capobianco14, the director of finance, interviewed us and all of our principal competitors. Their choice of the GrandAd system was a real feather in our cap. We were confident that we could do a great job for them, and we hoped that it would open the Boston market, which we had previously never been able to crack, for us.
A Wang word processing terminal.
The holdup was the word processing element. Neal loved Wang’s approach to word processing, and he thought that DisplayWrite/36 (DW/36) was inferior. However, no ad agency software had ever been written for Wang’s operating system. In fact, I had never encountered anyone who used it for anything other WP.
When Neal told us that they had decided to use our system, he asked what we would recommend for word processing. I said that I was not an expert, but the future was in PC’s. Furthermore, if they planned to use the S/36 only for GrandAd, a 5362, which could support up to twenty-eight locally attached devices, would be more than sufficient.
WordPerfect running in DOS did not look like the answer.
My assessment turned out to be correct, but in 1987 buying PC’s with good word processing software (the most popular at the time was WordPerfect) and connecting them would have been a formidable task. Personal computers in those days were still really personal.
Neal insisted that one system should address all the needs. IBM persuaded Neal that a model 5360 with DW/36 would serve their needs.
Neal approved the purchase of a 5360 (the washer-drier model) directly from IBM.
In the meantime I received a phone call from a salesman at Wang. He wanted us to convert our software to run on Wang’s equipment. I informed him that this would be a monumental task, and, although we had dozens of successful installations on IBM hardware, we had absolutely no experience with Wang’s approach. He told me that if we agreed to convert, he had an agency lined up that would use our system. I asked him if he was referring to RGS&H. When he confirmed it, I told him that they had already signed a contract with us. This was news to him.
The system that IBM proposed included terminals for almost all of the employees. The ones with PC’s got 5250 emulation adapters. Our end of the installation went fine. We did a great deal of custom coding for them. They had spent a lot of money on the system, and they reasonably insisted that it do exactly what they wanted.
Then the bombshell exploded. Microsoft let the world know that Neal Hill had written a letter to them. In it he bragged that RGS&H had poached the copywriter and artist from the agency that had handled advertising for Lotus Development, which at that time was considered Microsoft’s biggest competitor. Microsoft had not yet assembled its Office package, and Lotus 123 and Approach were very popular applications. Neal said that RGS&H knew what Lotus was up to, or words to that effect. He also sent them two plane tickets from Seattle to Boston.
I could sympathize. Evidently no one checked Neal Hill’s work either.
This episode caused a major scandal that has been widely written about in legal, advertising, and business circles as well as in the local press. In fact, if you google the agency’s name you will get several pages of articles about it. There are so many that is very difficult to find any other information about the agency.
Neal resigned in December of 1987. Ernie was named as the interim president. Our system was fully functional by this time. Ivan Dunmire served as our liaison. He did an excellent job.
TSI indirectly got swept up in this brouhaha. The articles in the local press mentioned that RGS&H had recently purchased a computer system that was characterized either as a mainframe or as a system that was much too large for the company. So, despite the fact that the people who actually used our software appreciated greatly what we had done, we never had the good reference account in Boston that we had hoped for.
Here are some of my recollections of my experiences with RGS&H:
You can’t make it in thirty minutes if you are afraid to exceed 10 miles per hour.
When I was driving Ernie to lunch one day he complained that my car smelled like tobacco smoke. It must have been Sue’s. Nobody previously had mentioned it. Evidently I was “nose blind” to it.
One of the two contenders for the most harrowing experience of my life (the other, getting caught in the Blizzard of ’77, is described here) occurred when driving back to Rockville. It was snowing lightly, and the traffic was moving at a fairly steady pace on the Mass Pike when I reached Exit #9 for I-84 near Sturbridge. To my surprise I-84 was nearly empty. There were no tracks in the road at all. I could clearly see the reflective markers on both sides of the road, and I used them for navigation. There really was no place to stop between Sturbridge and Rockville. The Celica and I passed no one, and we were only passed by one car traveling at perhaps 30 mph. A mile or so later I saw a car that had slid into the median; I assume that it was the one that had passed me. I did not consider stopping. When I finally reached the exit for Rockville, I had to guess where it was; the asphalt was covered with several inches of snow and there were no tire tracks. I did not think that my car would make it up the steep hills in Rockville, but it did. Sue was very worried; there were no cellphones in those days.
After we moved the office to Enfield in 1988, I usually drove to Springfield, took a Peter Pan bus to Boston, and walked a few blocks to the RGS’s offices. By that time “&H” had been dropped from the agency’s name.
I loved working with Ernie, Ivan, and the other people at the agency. There were no quarrels or misunderstandings.
I remember that I usually walked to McDonald’s for lunch and ate a Quarter-Pounder with Cheese and a Big Mac.
In the nineties Ivan called us a few times for support. By that time PC networks were becoming widespread, and people were touting the idea of “client-server” systems, a term that simply meant that the data was on one system used by everyone, but each person’s computer had its own set of programs. However, Ivan said that many of the people at the agency did not understand this. They thought that the term designated a system constructed to provide better service to the agency’s clients, and they wanted to know why RGS did not have one.
I tried to recruit Ivan to work for TSI, but he turned us down. I am not exactly sure what role he would have played at TSI, but I am pretty sure that he would have done a good job.
Our other installation in Boston, Rizzo Simons Cohn (RSC), was an even bigger fiasco. I was surprised to discover that Sue has almost completely repressed the memory of The Sign of the Three.
We had been contacted by a firm called Computer Detectives (CD). The guy on the phone told us that his company had been hired by the agency to find a computer system for them. It turned out that CD was a two-person company, the guy with whom we talked and his wife. His name was Larry Ponemon16. I don’t recall hers. We dealt almost exclusively with Larry.
Sue and I went to supper at a Chinese restaurant with them. The both ordered moo shu pork; this is the only thing that Sue remembered about them. They were very surprised when we told them that we had never really had a vacation.
We showed them the system, and they liked what they saw. We gave them a proposal for the GrandAd system running on a S/36 model 5363.
AT&T 3B2 model 400.
Larry called us to tell us that they had recommended our system to RSC, but the agency preferred to run its system on 3B2, a UNIX computer manufactured by AT&T. They asked us if we could convert our system to run on it.
We researched whether the S/36 version of Workstation Basic17 would work on a 3B2, and we were assured by the company that wrote and marketed it that it would. We told CD that we were pretty sure that it would, but we would need to adjust our quote to cover the conversion costs. We did so.
We then got to meet another consultant, who, among other things, sold and marketed AT&T computers. We told him that we were accustomed to working with IBM, and we trusted its commitment to support. If he sold the system to RSC, we wanted to know whom we would contact when we had problems or questions. He said that he was our contact. Remember that there were no cellphones, and this guy practically lived in his car. We would need to leave messages. The best that we could hope for was a beeper. Then we would need to depend on him to find someone who was willing and able help us. We were used to dialing 1-800-IBMSERV from anywhere. Someone ALWAYS answered.
The CD people were there at the meeting. They and the AT&T guy assured us that we and the agency’s users would get all the support that we needed.
We converted the software to work on Unix without an inordinate amount of difficulty. That, however, did not mean that it would efficiently do everything that RSC wanted in their environment. We knew nothing about how the operating system would perform when numerous users were working on the same files at the same time. Sue spent several days at RSC trying to get the system to work, but she ran into one roadblock after another, and no one was available to help her.
After a few weeks of this foolishness, the agency got fed up. CD had not disclosed to RSC, who had paid them handsomely to conduct the search, that they were being paid a “finder’s fee” both by us and by the AT&T guy. RSC had never voiced any preference for hardware; that was just a lie. Evidently they had told RSC quite a few whoppers, too. RSC sued CD, and Sue testified for the agency. AT&T took the hardware back and refunded at least part of the cost.
RSC reopened the software search. We submitted the same proposal that we had previously given to CD. Since we had already been paid for the UNIX version, we charged nothing for the GrandAd software or for the customizations. The other contender was a New York company (I can’t remember the name) against whom we often competed. Its software ran on UNIX.
I called the finance guy at RSC, Jonathan Ezrin18, and asked about their decision. He informed me that they had chosen the other vendor. I asked him what the basis for the decision was. He responded that mostly it was the cost. The answer astounded me. I asked him what the other software company had bid. It was about $10,000 higher than ours. I asked him how they could have considered this less than our bid. He said that to be fair they had included the cost of the software in our original proposal when making the comparison.
I assured him that we were not going to give that money back. I then told him frankly that theirs was the stupidest line of reasoning that I had ever heard, and I slammed down the phone.
RSC dissolved in 1990, less than a year after that phone call. I don’t know what happened to CD. I found no trace of them on the Internet, although Lavinia Harris has published a series of novels about a young couple who call themselves “computer detectives”.
I remember visiting Fern/Hanaway19 of Providence, RI, a few times. The agency had a System/36 that they had bought from IBM. I think that we installed one or two modules there, but I don’t remember which ones.
IBM must have told Arian & Lowe (A&L)20, an advertising agency of sorts in Chicago, IL, about TSI. Sue said that she went there once. She remembers that the floor of their office would have been good for dancing, but the only thing that she remembered about the company was that their main client was the Beef Board. They mostly produced point-of-sale posters and signage.
I installed some modules of the GrandAd system there and flew out for a couple of month ends. I remember several very strange occurrences.
The Director of Financial Operations for the agency was Neta Magnusson21. We generally had lunch together. She always had more than one martini. I could never have concentrated in the afternoon if I had imbibed a small fraction of what she downed. I stuck with Diet Coke or iced tea.
A&L used its S/36 model 5360 for word processing. One time when I was there working on the GrandAd system, they somehow lost some WP documents. A few people blamed me for this. I protested that I had not done anything to any documents. Fortunately I knew enough about how DW/36 worked that I could also demonstrate that I could not possibly have done anything.
I ordinarily stayed at a Holiday Inn that was a short distance from A&L. On one trip I had to stay an extra day. The Holiday Inn had no availability for that extra night, but they found me a place to stay and called a cab to take me there. The cab driver said that I definitely would not want to stay there. Instead, he took me to another place that was in a rather rough part of town. However, the room was OK, and it was only one night. I was, however, happy to be out of there the next morning.
The agency’s was in downtown Chicago. I had to take cabs back and forth to O’Hare. One time I somehow left my glasses in the cab. Believe it or not, the next time that I went to A&L I stopped at the taxi dispatcher. My glasses were in the Lost and Found box safe and sound.
One of the cab drivers spoke no English at all. His girlfriend sat in the front seat and translated for him.
Another cab driver picked me up at A&L. I wanted to go to O’Hare. He asked me for directions. I actually rode with a cab driver in Chicago who did not know how to get to the airport! Fortunately, this was one of my last trips to A&L; I could have given him instructions blindfolded.
The favorite expression of the system operator at A&L was “Have a good one!” I realized that this was cheerful and completely innocuous, but for some reason it really irritated me.
My favorite part of the trips to Chicago was the prospect of having an Italian beef sandwich, either at the airport or bought from a street vendor.
It seems appropriate to end with the bittersweet tale of Charnas Associates of Manchester, CT. TSI and IBM scheduled a presentation to the agency at the IBM office in Hartford. The presentation was scheduled to take two hours. I went to the office early and loaded our GrandAd demo system onto the 5360 at IBM. I also went over my notes for the presentation.
The turnout was unbelievable. Around twenty people showed up from the agency. I was always happy if we got one; I had done worse than that.
I had a lot of experience at this. The format varied by only a little. Someone from IBM acted as the host. He or she was always dressed impeccably and spoke glowingly about how wonderful IBM’s systems and support were and what a close working relationship IBM had with independent software developers like TSI. Then they turned it over to me.
I hated whiteboards after this.
Not this time. The IBMer went around to each and every person in the room and asked them what they would like the computer to do to help with their jobs. After each answer he would rush back to a whiteboard and add it to the list of items that were already on the board. The he would ask them to evaluate how important this was to them. He was hoping that they would attach a monetary value to it, but he was willing to settle for peace of mind or saving time. He dutifully recorded the values as well.
This went on for at least an hour and forty-five minutes. Then he spent a few minutes praising the System/36 before he let me talk for a couple of minutes. I could not possibly do my presentation in less than a half hour. So, I had to forget about my slides and my demo and try to talk about the big picture. The worst part was that damnable list on the whiteboard behind me. Needless to say, our software addressed less than half of the wish list. Of course no one suggested “Help us find which clients are unprofitable and why” or “Help us improve cash flow”.
I was so angry at the IBMer that I could have punched him. If I had not sworn after that fight in the fifth grade with Tom Guilfoyle that I would not engage in fisticuffs, I might have.
We followed up on this, but we never heard from Charnas.
A few years later in 1989 I was scheduled to give my first AS/400 demonstration of the AdDept system that I was still in the process of installing at Macy’s in New York. TSI did not own an AS/400 yet, and so I had made a backup tape at Macy’s. I planned to install Macy’s programs and data, dummy up the data so it was not recognizable, give the demo, and then erase the programs from the disk.
I never finished the first step. Something about the tape made the AS/400 system at IBM hang up. Commands could not even be entered at the system console. I worked with these incredibly reliable machines for twenty-six years. This was the only time that I saw something like this happen.
The IBM people were furious at me. They were certain that the problem occurred because our programs were written in BASIC. I calmly explained that the programs never got restored. Something happened during the restoring process.
Nobody from IBM attended my demo. I went to the demo room to do a song and dance with no accompaniment. Only one person was there, and she was not even one of our invitees. She identified herself as a media buyer at Charnas who had heard about the event from one of her clients. I explained how the GrandAd system worked and which agencies were using it.
She told me that Charnas had a S/36. She did not know the model. I asked her how big it was. “Oh, it’s big!”
She said that they used it only for word processing, and everyone hated it. That guy from the first demo had sold them a 5360 with no software except DisplayWrite36!
I don’t remember what happened after that too clearly. I am sure that I went to Charnas’s office in Manchester at least a few times in the early nineties. I think that I installed an abbreviated media system for them. Then I got heavily involved in the AdDept system.
Charnas apparently went out of business in July of 1992.
While I was looking for information about the agency I came across the book shown at the right. It was commissioned by Robert Bletchman, an attorney from Avon who died in 2008. His obituary is here.
There is only one copy of the book on this website. The title is How to Achieve the Release of Unidentified Flying Object Information from the United States Government.The first reader with $50 can claim it. Shipping is free!
The publication date for this book is in 1985. I am pretty sure that this effort antedated Art Bell’s Coast to Coast AM show on WTIC radio by approximately ten years.
1. O’Neal & Prelle went out of business in 2000.
2. Bill Ervin died suddenly in 2003. His obituary is here.
3. Liz Dickman is now the CEO of Integrated Physicians Management Services in East Hartford. Her LinkedIn page is here.
4. Eric Tulin Inc. changed names and ownership a few times before giving up the ghost in 1991.
6. In 2007, as reported here, Tom Brownell apparently transferred his client list to a group of his employees. They changed the name of the agency to 802 Creative Partners and moved the headquarters to Bethel, VT.
7. By coincidence 72 is my own age as I write this in May 2021. To be honest, if I tried to keep a manual ledger, I probably would not be able to read my handwriting either.
9. Dianne Doherty now goes by Dianne Fuller Doherty. She resides in Longmeadow, MA, in 2021. After the agency’s failure she devoted her life to helping other small businesses, especially those run by women, get started. Her story is described here.
10. Marsha Tzoumas is now known as Marsha Montori. In 2021 she is the Chief Marketing Officer at Six-Point Creative Works, an ad agency in Springfield. Her LinkedIn page is here.
11. I used focus groups in my short story (described here).
12. RGS&H went through five name change. Its final incarnation, GSOD, Inc. dissolved in 2007.
13. Neal Hill landed in Canada. His LinkedIn page is here.
Ernie Capobianco.
14. Ernie Capobianco telephoned me in the early 1990’s. At the time he had just started working at Valentine-Radford, a big ad agency in Kansas City. He arranged for me to meet with some principals and the IT guy. I also visited Ernie’s apartment in Johnson County. I think that I caught him at a bad time. His LinkedIn page, which skips over his time at RGS&H, is here.
15. Ivan Dunmire lives in New York City. His LinkedIn page is here.
Larry Ponemon.
16. I think that Larry Ponemon now runs the Ponemon Institute, which has something to do with privacy, security, and computers. His page on the organization’s website is here.
17. Workstation Basic was designed to emulate the Datamaster version of BASIC running under DOS and later UNIX. More information is here.
18. Jonathan Ezrin apparently now lives in Plymouth, MA. He does not have a LinkedIn page.
19. Fern/Hanaway was dissolved in 1998.
20. It appears that in 1991 A&L was taken over by Daryl Travis. Various versions of Arian, Lowe and Travis (no Oxford comma) existed after that, but I think that the operation in Chicago did not survive for long. The Beef Board account represented a high percentage of its billings.
21. I think that in 2021 Neta Magnusson lives in Geneva, IL, a suburb on the west side of Chicago.
In the eighties IBM sold two mini-computers1, the System/36 and the System/38. It was hard to understand why. They both supported the same programming languages (RPG, COBOL, and BASIC), cabling, and peripherals. They both were aimed at small businesses that used them for traditional “business” applications—as opposed to graphics or calculation-intensive jobs. There was a large overlap in the targeted customers for each system. Both systems were even designed at the same IBM facility in Rochester, MN.
For several months rumors abounded in the trade magazines for these products that IBM would soon announce a new computer to replace both of them. The code name was Silverlake.
The announcement was made on June 21, 1988. I attended a briefing at the IBM office in Hartford. The name of the new system was AS/400. The “A” stood for “application” because every program ever written for either the S/36 or the S/38 would run on the new system. Neither the S/36 nor the S/38 could be upgraded to an AS/400, but the new system accepted all of the software and most of the peripherals. The thrust of the pitch was that IBM was providing the “best of both worlds.”
A System/38.
This claim was possible because the “native” environment of the new operating system was based on the System/38. The new system also supported a “System/36 environment” that allowed programs written for that system to run with no changes. Since the native environment was much more efficient than the S/36 environment, software developers were expected to migrate their code to the native environment as soon as they could.
My immediate interest was in the price of the low-end systems. I was bitterly disappointed. The least expensive model, the B10, cost much more than the 5363, which was a perfect fit for most of our target market. Once again, IBM just refused to address the millions of small businesses that could be served very well by an economical system that could handle a handful of simultaneous users. In 1987 IBM had finally introduced such a system. With this announcement just one year later a perfectly good solution was replaced by a much more expensive and unproven one.
So, from the perspective of selling to local advertising agencies and other small businesses, the announcement was a nightmare. However, as is described here, Macy’s gave TSI no choice but to embrace the AS/400. They wanted to hire us to develop a system for them, but they had no interest in purchasing obsolete hardware.
IBM’s approach eventually worked out in our favor. The AS/400 had many outstanding features that were not available on the System/36.
The B10 was the size of a two-drawer file cabinet. The B60 required four racks. All were announced in 1988.
The new system’s operating system was built over a relational database. I am not sure that most people in the S/36 community knew this at the time because IBM did not even mention it at the announcement meeting, and the database was not even given a name (DB2/400) until much later. All anyone knew was that it sure had fast file access.
The defining feature of the operating system was inherited from the System/38: Single-Level Store. I never have understood this completely, but the effect was that the main processor did not care whether programs or “pages” of data were already in memory. The task of managing storage was managed by other processors. So, the problem that occurred on the System/36 when too many jobs were running simultaneously would not occur on the AS/400. Moreover, the compiler on the AS/400 took advantage of this setup to make the programs run much more efficiently under normal conditions as well.
For our purposes the big advantage of the AS/400 was that BASIC programs on the AS/400 were compiled, not interpreted. This meant that we could externalize routines that were performed by many programs, and one program could call several other programs that could run simultaneously as “batch” jobs without tying up any terminals. These were huge advantages.
The BASIC interpreter that was invaluable for debugging was NOT eliminated.
The AS/400 operating system was designed to be able to take advantage of future hardware advances. Because potential customers were more concerned about solving their immediate problems, this was not a great selling feature. However, it was definitely a great “keeping” feature. Ever program that we wrote in 1988 still works on hardware marketed by IBM thirty-one years later!
The first announcement did not require this, but eventually every AS/400 came with a 1/4” cartridge tape drive. This eliminated the nightmare of having to convert repeatedly from one storage means to another.
Priority could easily be assigned to certain jobs.
A modem could be attached for faxing. Our AdDept customers used these for insertion orders until we devised a better way of handling them.
The system could be attached to an Ethernet or Token Ring network.
IBM’s query tool was a big improvement. We insisted that all of our clients licensed it, and I personally trained at least one employee in its use. That worked fine unless the person who had been trained left the company or was reassigned. We also offered support for designing and helping with queries, but we charged a monthly fee for this service.
Printing was much more flexible. Even laser printers attached to PC’s could be used for printing reports. I learned PCL, Hewlett-Packard’s printer language, so that I could design customized reports with fonts and simple graphics (borders and the like could be generated on HP printers. This was very popular with our customers.
Although some things continued to frustrate me about the AS/400, I grew to appreciate it more and more. It was not designed for tiny developers like TSI, but it allowed us to produce software with features that went way beyond the capacity of any model of the System/36. By the time that the E models of the AS/400 were released in 1992, the low-end systems represented very good investments for the companies who were interested in TSI’s products and services.
On the other hand, IBM’s approach meant that independent developers who marketed to the end users directly rather than to IT departments—and there were a lot of us—had to devised a way to survive until IBM provided us with a reasonably priced product. Those four years were very difficult for TSI. The company survived, but the grim reaper’s shadow was on our door quite a few times.
TSI’s B10 had a diskette drive and a QIC tape drive.
Over the course of twenty-six years, TSI had at least four AS/400’s (or follow-ons. named iSeries or System i) All of them worked spectacularly well. We hardly ever called IBM for either hardware of software support. We purchased or leased all of them at big discounts because we were developers. On the first one, a B10, I prudently scraped together enough cash2 to order the maximum amount of memory and disk. It was adequate for development purposes, but if one of our clients had tried to run its business on it, it would have been embarrassing. For one thing the operating system itself required almost half of the unit’s disk space! Subsequent releases of the OS required much more disk.
Still, we lived with it, and we came through on the other end.
How well did the strategy work for IBM? In 1988 IBM was one of many competitors in the mini-computer market. The others were DEC, Hewlett-Packard, Data General, Wang, and a host of other companies. By the mid-nineties all of the competitors had conceded the entire market for reasonably priced multi-user computers to IBM. All of them except HP went out of business, and even HP (after several mergers) now makes and sells only PC’s and printers. This stunning event went almost unnoticed by most so-called experts. They blamed poor management by these companies for their demise. Were they all stupid? No, the AS/400’s were demonstrably superior.
Lou Gerstner.
The mini-computer market still exists, but almost no one talks about it, because IBM has hidden its premier product inside hardware with other brands. The only thing that IBM left for the AS/400’s legions of devotees to cling to was the letter i. When Lou Gerstner took over the reins of IBM in 1993, he put a heavy emphasis on services, which were very profitable, over hardware and software, which evidently were not. So, Gerstner never liked the AS/400 approach because the IT departments that used it had little demand for IBM services. For example, at some point in the twenty-first century I visited Macy’s IT department in a suburb of Atlanta. Dozens of IBM employees went to work there every day. One extremely large office contained desks for them and no one else. Macy’s had several AS/400’s or i series systems there. One person managed them all, and he worked for Macy’s, not IBM.
Users of TSI’s software systems loved their AS/400 computers, and they never purchased any services from IBM beyond maintenance contracts.
The AS/400’s operating system (OS/400) employed strict typing of objects. Every object had one and only one type, and it was unchangeable. On a PC a developer—or even an end user—can change the type (as designated by the three-digit “extension” after the period). For example a text file named sample.txt can easily be changed to a comma-separated-values file sample.csv. Users could even make up their own extensions.The operating system might warn the person that changing the extension might make the file unusable by certain applications, but it would still allow it.
The AS/400’s native environment, in contrast, had a limited number of well-defined object types, many of which had equally rigorous subtypes:
Database files could be physical or logical. A logical file is equivalent to what is called a “view” in SQL.
Programs had subtypes for each supported language. A new language called CL3 was added.
Menus were lists of options displayed on the screen, usually with a command line at the bottom. Each option had a number.
Commands were routines that could be invoked on any command line. A command was essentially a shortcut for calling a CL program.
The names of the commands supplied by the operating system. were consistent throughout: VVVAAANNN, where VVV was a three-character abbreviation of a verb, AAA was an optional three-character abbreviation of an adjective, and NNN was a three-character noun. For example, DSPSYSVAL was the command for Display (DSP) System (SYS) Value (VAL).
Most commands had parameters. For example, the GO command required the name of a menu object as a parameter. GO BACKUP caused the system to display and execute the menu object named BACKUP. Pressing F4 after keying in the command displayed a data entry screen for all of the parameters.
TSI created a large number of commands in
Several other object types, such as line descriptions and spool queues, were used by the system software. Most system objects of all types (except commands) began with the letter Q.
BLOBs were objects that did not fit any of the other types. They included all types of images, video, sound, etc. They were added in later releases.
Users could not create new object types or subtypes, but new ones often appeared in new releases of the operating system.
Every object had a name, which was limited to only ten characters. A letter was required for the first character. The other characters could be letters or numbers. A few special characters were also allowed. The names were NOT case-sensitive.
Every object resided in a library, which was itself and object with a ten-character name. This was a departure from the S/36, where data files were not assigned to libraries. On the AS/400 two objects in the same library could not have the same name.
On the S/36 and for a short time in the S/36 environment on the AS/400 TSI used periods in the names files that were associated. For example, files that began with “M.” in the GrandAd system were media files. In the native environment of the AS/400 such files caused a problem for some third-party programs that users might wish to employ to create customized reports. So, TSI changed the names so that the first one or two characters served to group files.
Third-party programs and programs written in other languages also had difficulty with integers that were left-padded with blanks4, as BASIC programs have always done. TSI changed all of its programs to pad integers with zeroes instead of blanks. So, when the value of a three-digit number was 15, it was written on the AS/400 database as 015, not (blank)15.
1. The terms mini-computer and midrange computer referred to multi-user systems that were not powerful enough to run the business applications of major corporations. The System/36 and System/38 were certainly mini-computers. At its introduction so was the AS/400. The twenty-first century models, however, were more powerful than the mainframes of the eighties.
2. I suspect that TSI actually leased it.
3. CL stood for Control Language. CL was the easiest language ever. It was simply a list of commands to be executed in order. Since CL programs were compiled, they could be called from other programs written in any language.
4. I considered this an intolerable bug in the software developed and marketed by the other company. I encouraged the person trying to use the software to complain to whomever claimed that the product would work on AS/400 files. Eventually, we changed our files and programs to forestall a brouhaha.
A fairly detailed description of the design of the GrandAd System can be found here. More information about IBM’s System/36 (S/36) is posted here.
The purchase of the GrandAd software system in early 1985 by Keiler Advertising (KA) was definitely a milestone for TSI. The agency was one of the two largest in the Hartford area, and its founder and president, Dick Keiler1, was highly respected in the local advertising community.
Although I had recommended to Sandy Procko3, KA’s finance manager and our liaison on the installation, that they buy two Datamasters and a hard drive, IBM had talked her into ordering the recently announced S/36 model 5362. They made the right decision.2 The Datamaster was on its way out, and the S/36 gave them better peripherals and room for growth. It also had many more subtle advantages.
Her decision was a great break for us. We would have needed to convert the system anyway. The sooner that we got started on it the better.
The only problem was that no one at TSI had ever worked on a System/36. We knew that the system had a BASIC interpreter, but we were uncertain about the compatibility of the two versions. IBM provided KA with a huge stack of documentation. I read the BASIC manual thoroughly and was relieved to find that it was very similar to what we were accustomed to. I read enough of the other manuals to get an idea about how to set up their system.
I also had to write the file definitions for each file. We had versions of these created in the Datamaster’s word processing program, but on the S/36 it was important that they be stored as Data Definition Specifications (DDS). The final preliminary step was to write a procedure for creating all of the empty data files from the DDS.
IBM’s office had a 5360, the “washer-dryer” model.
IBM allowed us to work on the S/36 in its downtown Hartford office before KA’s system was delivered. I saved our programs onto 8″ disks. I created a library for them on IBM’s 5360. Then I restored them as text files. I edited them to conform with the S/36 syntax and changed the names of all of the files to use the dot format that SSP required. I then tried to load them in the interpreter. If any lines were rejected, I fixed them and kept trying until the program loaded. Then I went on to the next program, of which there were several hundred.
When I was done with the programs and procedures, I saved the library onto diskettes, brought the diskettes to KA, and restored them. Then I executed the procedures to create all of the files. It never occurred to us that there might some day be a way of populating the data files from files that they had stored on their PC’s. I think that it was possible to save the specs table, which was a fixed-record-length file.
For nearly all of its forty-two years of its existence KA was located in a large house in Farmington, CT. It is portrayed in the photo at the right. During the period in which I was regularly vising the agency, the trees and the bushes were much smaller, and they were surrounded by wood chips. Sandy called Dick “the mulch king” of Farmington.
From the beginning, or shortly thereafter, Sandy was assisted by a younger woman named Shelly. I don’t remember her last name
Getting the code to work on the S/36 caused us fewer problems than one might imagine. By this time we understood how IBM thought about things. The fact that all of our programs followed strict procedures also made it easier to adjust to the differences. I don’t remember encountering any problems that necessitated consulting IBM or anyone else.
Here are my most vivid recollections of the installation.
KA’s 5224 printer was much faster than anything available on a Datamaster.
KA not only had a kitchen. It had a chef who prepared meals for clients and prospects and a dining room as well. I was never invited to one of these occasions.
The parking lot at KA, which was in the back of the house, had a few narrow grass covered areas with skinny trees in them. I parked my Celica to the left of one of them once. When I exited I turned the wheel too soon. The mirror on the right side of the car got caught on the tree and broke off. Thenceforward there was no mirror on the Celica’s right side. Changing lanes to the right required extreme caution.
The first few monthly closings at KA were, as always, difficult. Query/36 sometimes helped the reconciliation process. Nevertheless, on one occasion we had a discrepancy of ten cents in the accounts payable account. Sandy told me not to worry about it, but we had the tools to find it, and so I persisted. I eventually discovered that no vendor was off by a dime. Instead, three invoices were off; all three had discrepancies of more than $100, but they almost perfectly balanced one another.
Sandy taught me that if a discrepancy was divisible by nine, it was probably a transposition error.
On one occasion guys from the Australian national swimming team were in the office for some reason. Sandy and most of the other female staff members thought that they were very hot.
Sandy liked the system’s reports a lot. I am pretty sure that she asked for a couple of revisions, but I do not remember the details. I do remember that, despite the fact that we spent a lot of time making sure that the results of the cost accounting system agreed with the cost accounting system, she never showed any client profitability reports to Dick. She said that that would open a can of worms.
I went to KA once during the period in which I was weak from cat scratch fever (as described here). It happened to be on the day that KA was moving its accounting department from the ground floor to the second floor. I carried a printer or something, but the effort totally exhausted me.
At some point in 1988, I think, Sandy fell out of Dick’s favor. She was reassigned to take charge of the scheduling of production jobs, a clear demotion. I never learned why all of this happened.
Dick hired a woman with experience from a New York agency to replace Sandy. I tried to explain to her why the system’s method of calculating work in process (WIP) was superior to the method advocated by the AAAA, but I don’t think that she bought it.
The last time that I went to KA Shelly was in charge of the finance department, and the New Yorker was gone. On that occasion Michael Symolon, our salesman at the time, accompanied me. Evidently he had gone on a date with Shelly once and was embarrassed about it. He stayed in the background. That was the only time that I ever remember him being shy.
When the system had been working successfully for a few months, Dick Keiler arranged to be interviewed by AdWeek New England about our system. It was a very nice article that heaped praise upon our system. It started on the front page, and it continued for several paragraphs in the middle. I had only one minor quibble: THEY NEVER MENTIONED THE NAME OF THE SOFTWARE OR THE COMPANY THAT DEVELOPED IT!!!
TSI had, for the first and only time in its existence purchased an ad. It appeared somewhat close to the article’s continuation page. However the ad was not precisely the same size as the hole that the magazine needed to fill. The way that they floated it in made it look really unprofessional.
I was quite upset about this. I wrote a letter to the editor complaining about both of these things. He called me. He did not apologize. He said that he did not think that it would have been proper to identify TSI. I reminded him that the article clearly identified the hardware vendor as IBM. What was the difference? He repeated that it just did not seem proper. He also thought that our ad looked fine. I hung up on him.
I made lemonade out of this by writing to all the prospects in the northeast about the article, providing “what AdWeek neglected to mention.” It generated a few inquiries.
1. Dick Keiler founded the agency in 1972. He started his retirement process in 1999 and left the company five years later. In 2021 he lives in Tucson Arizona. The agency went out of business in 2015. The last few years are described here.
2. I am pretty sure that in 2021 Sandy Procko resides in Westbrook, CT.
3. I was slow to come to the realization that when trying to sell systems that generated no revenue for the purchaser, it was best to strike when the iron was hot. One of our clients later told me “Christmas only comes once.” The person recommending the purchase always dreaded making a mistake. He/she most feared the prospect of telling the boss a little later that the company needed to purchase more hardware. I always thought that IBM proposed systems that were bigger and more experience than necessary, but they were more experienced at this process than I was.
4. The S/36 operating system, called SSP, used the term “procedure” for a list of commands that were to be executed sequentially. In addition, BASIC used the same term for a sequential list of BASIC commands that could be executed inside the interpreter. On the Datamaster the user was always in the interpreter, and so there was no confusion.
