The AS/400 hardware, the OS/400 operating system, and the and DB2 database were introduced in 1988. The AdDept system that TSI developed for the administration of the advertising departments of large retailers was one of the very first systems developed … Continue reading →
The AS/400 hardware, the OS/400 operating system, and the and DB2 database were introduced in 1988. The AdDept system that TSI developed for the administration of the advertising departments of large retailers was one of the very first systems developed on and for the AS/400. At the time TSI was an IBM Business Partner for its GrandAd system on the System/36. Earlier TSI had been one of the first software companies to be recognized as an IBM Business Partner for the Datamaster.
Prior to the late nineties the only requirement for a company to become a Business Partner was to have some successful accounts that were using its software or services. At times it was a huge advantage to be an IBM Business Partner. At other times IBM employees treated the partners as competition.
At some point the concept of Value-Added Retailer (VAR) was introduced. VARs were at first allowed to order and sell systems for which their software or services had qualified as adding value to the sale of IBM equipment. Too many bad sales by VARs prompted IBM to take away the ability to take orders from smaller companies such as TSI. Instead they were assigned to a “Super-VAR” who vetted and placed the orders for them. In 1999 TSI was assigned to a company called BPS, which shortly thereafter renamed itself Savoir.
The next, but by no means last, set of restrictions imposed by IBM was to require any company involved in sales of IBM equipment to have at least one employee who had passed proficiency tests for the the equipment. At the outset there were two levels with separate tests, one for sales personnel and one for technical.
My partner Denise Bessette and I judged at the time that it was critical to the future marketing of AdDept and any other future product that we continue to participate in IBM’s partnership program. I knew more about the hardware offerings than she did, and so I was chosen to study up and take the technical test. It made little sense for a different person to study for the sales one, which was reportedly much easier.
I think that I must have taken the exams in the first half of 1999 or late 1998. I have a lot of notes from the second half of 1999, and there is no mention of them.
IBM published study guides for both exams. One or two Redbooks may have also been on the syllabus. I remember that there was a considerable amount of technical material about several things with which I was not at all familiar. One was the cabling required to connect two AS/400s. The other was setting up partitions on a single AS/400 so that each partition had a separate file system. It was more complicated than it sounds because each device needed to be defined in each partition that used it. I remember practically nothing about either of these topics, but we did encounter partitioning at Dick’s Sporting Goods (introduced here).
I spent as much time as I could bear going over the course material. Hardware and operating systems have never really been my thing. It took a lot of discipline to force myself to understand the details of things that we would never use.
The day arrived on which I was scheduled to take the tests. I drove to an office in Farmington that specialized in administering exams for corporations. I had already consumed one 20-ounce bottle of Diet Coke before I arrived, and I brought another with me.
I gave my registration document to the receptionist. She asked me which test I wanted to take first. I selected the sales test. I seem to recall that each test lasted for about ninety minutes. All questions were multiple choice. I was required to enter my answers on a PC.
The sales test was not too difficult; I reported back to the receptionist ten or fifteen minutes before the deadline. She told me that I had passed.
I told her that I wanted to take a break before taking the technical test. I went to the men’s room and sat in the lobby. I drank my second Diet and tried to clear my mind. Then I took the second test.
It was much more difficult than the first. A few questions were beyond my ken. I skipped them. I read all of the others carefully and only answered after I was fairly certain. I used up nearly all of the allotted time. I was pretty relieved when the receptionist assured me that I had passed both tests.
So, I was certified by IBM as knowledgeable about both the sales and technical aspects of the AS/400. If I ever had physical certificates, I certainly have not seen them for a decade. TSI’s Sales Manager Doug Pease told me that his contact at Savoir had told him that almost nobody ever passed the technical exam on the first try.
I am not sure how much good my success did us. I am not sure that TSI sold any new hardware at all in the rest of the time that we were in business. We might have ordered an upgrade or two through our Super-Var.
On the other hand, we did get to go to the PartnerWorld convention in San Diego. That adventure has been described here.
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.
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.
In the latter half of 1986 Sue and I realized that a serious business required a better office space than our house in Rockville could provide. For one thing we realized that neither of us was a salesman, and we had no place for a salesman to work. It was also a little embarrassing to bring in clients, especially since we now had two cats in residence, Jake and Rocky.
At the same time Sue’s dad was in the process of converting one of his barns at 178 N. Maple in Enfield, two doors north of Sue’s parents’ house, into office space for the Slanetz Corporation. Sue worked her magic with him to design a headquarters for TSI there as well. The new building also was designed to serve as a headquarters for Moriarty Landscaping1 in the basement below TSI’s space.
Two doors allowed access to TSI’s offices. The first was on the east side, where our space bordered on that of the Slanetz Corporation. The other was on the south side. It was eight or ten feet below the level of the office. From the door a staircase led up to the middle of TSI’s office space
That arrangement meant that a good bit of the space on the west side—between the staircase and the west wall—was essentially wasted2. There was not enough room for both a corridor and a work area.
The north and east sides of TSI’s area had no windows. The west side had two sets—the double in Sue’s office and another one in the wasted area. The south side had three windows.
Sue bought white wooden shelves that were deployed to create a corridor from the door on the west wall almost to the stairs. The programming and reception/accounting areas were partitioned into work areas with dividers.
South of the building was a parking lot that could hold eight or nine cars.
Sue and I were well aware that we had enjoyed a sweetheart deal in our lodging in the front house of the Elks Club in Rockville. Since January of 1980 we had rented—without a lease—a nice old three-bedroom house with another room that was large enough for an office for three or four people. We paid the Elks, as I recall, $300 per month, we had no lease, and no one ever bothered us. On the first of every month we put the check in an envelope labeled “Rent”, walked it up to the Elks Club bar, and gave it to the bartender. I don’t think that we ever missed a payment.
In October of 1986, Sue received the following letter from the Elks Club:
October 16, 1986
Sue Comparetto TSI Tailored Systems 9 North Park St. Rockville, CT 06066
Dear Ms. Comparetto:
This letter is to inform you of several changes which are taking place in the landlord/tenant relationship between the Rockville Elks and you. From now on, all correspondence is to be directed to the Chairman, Board of Trustees. Until April 1, 1987 this is David Mullins3 (address and phone number below), All correspondence should be directed to the Chairman at his personal residence. When a new Chairman takes over, you will be informed and given any necessary address changes. Normally, this will occur every April.
Rent payments are to made as they are now except that the full rent is to always be paid. Do not deduct for anything unless authorized by the Chairman – no other member of the Board of Trustees has this authority.
New rental rates will be taking effect as well (a lease is enclosed). Your new lease will run from April 1 to March 31. For your benefit, we are phasing in the rental increases until April 1, 1987 (when the new lease takes effect). Starting December 1, 1986 your new rent is as follows:
Additionally, you are now responsible for minor repairs and maintenance totalling less than $100. Starting with your new lease (4/1/87 – 3/31/88) you will receive a $100/moth rent credit if you meet the following conditions. First, the rent must be received on time (by the 5th day of every month). Second, all minor repairs and maintenance described above are to be taken care of by you. This credit may be deducted off of your rent payment. If you fail to meet both of these requirements you forfeit the rental discount for that month.
Please sign both copies of the enclosed lease and return them to me ASAP. I will sign one and return it to you.
David Mullins
We did not sign the lease. Instead, Sue negotiated a temporary arrangement with the Elks Club for us to stay a few months until we could find another place. We paid more than $300/month, but nothing close to $11004. Sue thinks that we actually paid them $600/month. Evidently they did not want to try to find another tenant.
We moved all of TSI’s stuff over a weekend in early 1988. I don’t remember if we hired a moving company or not. I don’t recall lifting desks, and so I suspect that we hired some local people to do it. If someone helped us, we might have been able to do it. The Slanetzes had an old grey pickup truck. I am pretty sure that I brought most of the computer equipment in my Celica, which was a hatchback.
On Friday we were doing business out of Rockville. On Monday our headquarters was in Enfield.
For a few months Sue and I commuted from Rockville to Enfield. Since we worked drastically different schedules—she is a night owl; I am an early bird—we always brought two cars.
Near the office Sue found two houses that were for sale. We ended up purchasing the one shown above situated on a large corner lot at 41 North St. in the Hazardville section of Enfield. From North St. it still looks much like it did when we bought it in 1988. The maple trees were much smaller forty-three years ago, and the Burning Bush on the left must have grown to be ten times as large as it was then.
The lawn in 2021 undoubtedly has far more weeds. Both the previous resident and the one before him were landscapers. Their care for the lawn amounted to an obsession. One of them even installed a sprinkler system. The first time that I mowed the lawn with my new Sears lawnmower, I filled twenty-three large black garbage bags with clippings. It took me over three hours. For the second mowing I set the machine to mulching mode and never set it back.
I undid all of that TLC with a few years of neglect. As you can see from Google’s photo, it still looks fine.
The sidewalk was added between April 22, the day on which we signed the mortgage for $135,000, and some time in June when we finally finished moving in. On the west side of the house was a fence. Beyond it was a driveway and walkway leading to Hazard Memorial Elementary School, which Sue had attended decades earlier.
So, our lot actually bordered on only one other, 1 Hamilton Court.
Behind the house was a one-car garage. Between the house and the garage was an entryway that was about 10′ by 15′. We installed one of the Datamasters and the daisy-wheel printer on a long table in that room5.
The house had a rather small kitchen, a pretty large area for a living and dining area, one bathroom, and three small bedrooms. To that extent it reminded me of the house on Maple St. in Prairie Village, KS, in which my family lived from 1954-1962.
We had accumulated a lot more stuff during our years in Rockville. For weeks I filled up my Celica before I drove to work every morning and emptied it at the new place before I returned home. Even so we had to hire movers to move the big things.
Our bed went in one bedroom and another double bed appeared from somewhere in another, which was in theory a guest room. The other bedroom became a kind of library. The barnboard shelve were located there. It soon hosted another resident, Buck Bunny, as is described here.
This house, thankfully, had much more storage space—a full basement and an attic. That was only sufficient for a year or two. The garage was soon too filled with junk for a car—or anything else—to fit.
We made one important improvement to the house. We installed a cat door in the basement window that was below the guest bedroom. Some wooden shelves were already in the basement near that window. The cats entered on the top shelf. I built a make-shift ramp so that they could easily get down, but they often preferred to walk to the edge of the shelf and jump from there to the washing machine and then the floor.
1. In 2021 Moriarty Landscaping still occupies the basement area of 178 N. Maple.
2. I wondered why the entrance was placed there instead of next to the east wall, with the steps outside. Sue said that she thought that it might have been a town requirement for two fire exits. My other question was why the staircase could not have been to the immediate left of the door.
3. In 2021 David Mullins apparently lives in Farmington.
4. $1100 might have seemed like a fair price on paper. However, there were at least three major drawbacks to the property: 1) The ceiling in the living room/dining room space was severely cracked. The middle was at least 6″ lower than on the edges. It was a pretty scary situation. 2) There was no shower on the floor with two bedrooms, only a bath tub. 3) The heating bills were outrageous. The hot air went right up the staircase to the unused floor.
5. The garage and the entryway were eliminated during the renovation that is described here.
When we moved from Michigan to Rockville, Sue and I knew almost nothing about marketing. When the business was closed over three decades later, we knew a lot more. Unfortunately, at least half of what we had learned was probably wrong.
In Detroit Sue had depended on IBM for referrals. When we moved we learned that the branch offices had no specific policy on this. Each salesperson knew a few of the independent software companies. Since no one in the Hartford office knew us, it was folly to depend on IBM in Connecticut.
The first year or so was the only time in the first three decades of the company’s existence that I had time on my hands. I wrote a little system on the 5120 to keep track of leads. I got most of my information from the Yellow Pages in the reference room of the Hartford Public Library.
I definitely remember sending a letter to the area’s jewelry stores. I think that we also sent one to construction companies. I do not remember how we did these exactly. Perhaps I just wrote a program on the 5120 to print letters with data from the lead tracking system. It seems unlikely that we had letterhead and company envelopes with our Rockville address yet.
I think that we got the lead for the Harstans account from the jewelry store mailing. I don’t remember any responses from anything in the construction industry. If we received any inquiries, Sue would have dealt with them.
After we had purchased a Datamaster with a letter-quality printer, we converted the lead tracking system to run on the new machine. We also invested in company letterhead and web-mounted company invoices. Both were Nantucket grey with light blue lettering. The TSI was striped in imitation of IBM’s logo, but we used a sans serif font.
We definitely did several mailings to ad agencies. Potter Hazlehurst responded to the first mailing. Other mailings may have at least produced a few lukewarm leads.
We received two free pieces of publicity. The GrandAd installation at Harland-Tine was featured in Basic Society News. This was described here. The other article, an interview with Dick Keiler, was published a few years later in AdWeek New England. It is described here.
We also bought our only ad ever in the same issue of that magazine. It was a waste of money.
By 1983 we began to get quite a few leads from IBM. We closed many of these deals, but most required significant custom programming and offered virtually no opportunity for additional business. What we wanted to sell were ad agency systems that took advantage of work that we had already done.
We participated in a campaign organized by a marketing manager at IBM to allow its salesmen to promote “IBM Advertising Agency Solutions.” He asked the third-party developers of ad agency software to provide a list of how their software could benefit ad agencies. Someone then took all of these items, assembled and sorted them all into one huge list, and put them into an attractive fold-out piece in which each of these advantages was claimed for “IBM solutions.”
Of course, no system marketed by anyone actually did all of those things, and some of the advantages were incompatible with others. Furthermore, none of the names of the companies that marketed and supported the software were included. The pamphlet only mentioned “IBM solutions” until the very last paragraph, which stated, “When you combine the specialized capabilities of IBM Business Partner applications for advertising with the quality control, product support and service that accompanies IBM systems, you have a comprehensive and powerful solution. One that can meet the needs of your agency today—and continue to serve you and your clients tomorrow.”
I was very upset when they sent the finished product. Set aside the atrocious grammar of the last sentence fragment. Who will possibly use this piece? IBM reps could not (or at least should not) use it because it doesn’t indicate which business partner could address which problem. No ethical business partner could hand it out because the prospect might think that the software company was claiming all of these advantages for its own product. I suppose that if we were allowed to white-out the parts that did not apply to our systems, we might be able to use it, but it would not look too professional.
When I explained that this was false advertising because the “IBM solution” described within did not exist, he was taken aback. He honestly thought that we would all be happy just to be associated with IBM. I admitted that we were. However we were ALWAYS in competitive situations. We could not afford to be associated with erroneous claims like “IBM creative applications help your writers and artists work more efficiently.” Our software did not improve the efficiency of the creative staff one iota, and if we tried to get the writers and artists to trade in their Macs for IBM iron, we would be run out of the office on a rail.
In addition, there were a couple of advantages that were unique to our approach. Of course, I had listed them, and they appeared in the pamphlet. I resented that every other Business Partner was authorized to claim these advantages, if only implicitly, for its own software.
With the help of Ken Owen of the Edward Owen Company we developed some leave-behinds that were at least a little professional looking and much less likely to get us sued. We put the write-ups of various aspects of the system in notebooks that had the company’s name and logo on it. The first batch were blue with white lettering. Subsequently we reversed the color scheme.
When we gave presentations. we put all of the handouts in folder like the one shown at left. The cover was generic enough that we could use it for any of our software products.
Our mailings for the ad agency system included self-addressed prepaid bounce-back cards on which the recipient could indicate the agency’s interest in our product. This certainly increased the quantity of positive responses that we got, but it also meant that we needed to spend more time qualifying the leads.
By 1986 Sue and I were frustrated with our sales efforts. We had been in business for more than five years. We had amassed a reliable set of reference accounts, but we were still struggling just to meet our payroll.
Sue set up some kind of business relationship with a guy named Joe Danko. I think that he was a consultant who had somehow come across our GrandAd product. He wanted to be our representative in southeast New England. Since the proposed arrangement involved no investment on our part, we agreed to it.
Sue corresponded with a former IBM VAR (as we were) named Jim Holland, who had started a business in Colorado helping others selling “turnkey systems”. Sue liked his approach, but he sold his business to a company in Paramus, NJ, called Motivational Marketing1. He convinced us to drive there for a “Motivational Marketing Working Session” in January of 1987.
We drove to the company’s offices and met with, I think, one of the founders of the company, Gary Farber2. We told him that we were having trouble closing deals for our software system for advertising agencies. We thought that we needed to hire a salesman, but we were not sure how to do it. He outlined a plan for us. It seemed pretty costly and did not directly address the need for a salesman, but if we scored even one or two deals, it would be worth it.
Two guys from the marketing company came to our office in Rockville. The older guy was named Irving; the younger one was Nick Pitasi. They told us that the first step in their plan was to contact our clients to get a more objective view of TSI’s strengths and weaknesses. Nick called everyone on our list of clients. He reported back to us that our clients loved us, and they particularly liked the fact that we educated them. This was rather nice to hear, but we already knew that we had very good reference accounts. We had thought that we were not doing a good job of using this information to our advantage.
Since we had said that we needed a “closer”, and since we already had a relationship with Joe Danko, Irving invited him to our office to interview for the job of salesman. Irving conducted the interview in Sue’s office upstairs in Rockville. I sat in. Sue might have attended as well, but she doesn’t remember it.
I was astounded at how awful Joe’s performance was. Without being asked about it, he went on and on about his involvement in lawsuits over his divorce. I would never have considered hiring him to take out the trash.
After the interview Irving told us that he thought that Joe would be OK as our salesman. Perhaps we should have cut our losses at this point. Irving and Nick might be able to help us in some way, but they certainly seemed unwilling or unable to address what we considered our most critical problem.
Their next step was to hire someone to call the presidents of ad agencies. We had a pretty good list in our lead tracking system. By this time Nick was handling our account by himself. He engaged a guy named Paul Schrenker for this purpose. Nick wrote a script for him. I could not believe how many presidents talked with him when he asked for them by name. I would have bet that he would not reach any of them.
The only person who accepted Paul’s call and expressed any interest was Bill Ervin at O’Neal and Prelle in Hartford. I visited them a couple of times, and they eventually agreed to a contract. The story of that installation is here.
One day I observed Nick while he was calling one of the presidents. It was impressive. A secretary answered the phone. Nick said, “Put Bill on, please.” When the secretary asked who was calling, he just said with supreme confidence, “It’s Nick from TSI.” The president picked up the phone, and Nick talked with him. I certainly couldn’t have done this.
Nick dropped by the office a couple of times after that. He had been in the office enough to see how things were run. By then he was familiar with how Sue would miss appointments and how disorganized she was. On one occasion I asked him whether he thought that we could make a go of it. He said that he did not see how. What a depressing moment that was.
Maybe I should have given up at that point, but I had no plan B. I was almost forty years old. I had burned through several occupations already. I did not want to start over.
When I first started to work with Sue I figured that I would do most of the programming, and she would do the rest of the work. After all, she had much more experience in business than I did, and she loved to talk on the telephone. She was certainly much more of a “people person” and less of a tireless coder She could figure out how programs worked and fix them, but I had never seen her write so much as a single program.
That was not the way that things worked out. As the years went by I took on more and more of the responsibilities. By the late eighties she was doing the accounting and the payroll, and that was about all. Even so, she could not keep up with it. The answer was not increased staff. We went through as many administrative employees as Murphy Brown.
We needed help with sales. The marketing consultants were nearly as worthless as all the other consultants that we had dealt with. We needed to hire a salesman. We terminated our agreement with Motivational Marketing in February 1988.
On March 2, 1987 (Sue’s thirty-sixth birthday), we sent out out a newsletter to all of our clients. It was three pages of 10-pitch single-spaced type on 8½x11″ paper. Mostly it dealt with hardware, but there was also half a page of information about changes that we were making to the S/36 version of the GrandAd system.
I located copies of issues numbered 1 through 6. The fifth issue, dated March 29, 1988, reflects the influence of Michael Symolon, our first marketing director. The first page of this issue announces three new ad agency clients. In addition, the first page is printed on GrandAd stationery that Michael ordered rather than on TSI letterhead. A post-it note attached to the copy that I found indicated that I was slightly annoyed that the subsequent pages did not match the cover page in either color or weight.
This issue is really meaty. I think that Michael or Kate Behart must have done most of the work on this issue and the others in this format. Issue #5 contained six pages of text and a copy of an article from the November 30, 1987, issue of ADWEEK about the installation of the GrandAd system at Rossin, Greenberg, Seronick, and Hill.3
I do not remember how many issues of those newsletters we produced. After I purchased and taught myself how to use PageMaker, the name of the newsletter was changed to Sound Bytes from TSI. At first it was 8½x11″, but the later versions were printed on both sides of 8½x14″ paper and folded to be 8½x7″. They also contained two columns per page, different fonts, and graphics. I located only one copy of each of these formats.
The main purpose of most of the subsequent newsletters was to announce new AdDept clients or new modules developed for existing AdDept clients. There may have also been one focused on TSI’s Internet insertion order system, AxN.
1. I think that Motivational Marketing still exists, but it has now evolved into a call center located in Rochelle Park, NJ. Its website is here.
2. Gary Farber’s LinkedIn page is here.
3. Much more about Michael Symolon’s career at TSI can be read here. More about Kate Behart has been posted here. The description of the installation at RGS&G is here.
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 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 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.