IBM’s introduction of the System/36 (S/36) in May of 1983 was not a monumental event for TSI. From our perspective the new system seemed more like a marginal upgrade of the System/34, which had always been much too pricey for anyone who would talk to us. The new system had only one basic model, the 5360. The starting price for one of these was still $140,000. It was also gigantic and had special electrical requirements. It was clearly designed for a small data processing department, not a small business without one.
The biggest advantage of the System/36 over any system that we had worked with was that it supported a fairly large number of terminals and printers. This was because it could run a number of jobs at the same time. It also supported batch processing, which meant that time-consuming jobs need not tie up any workstations.
We appreciated these benefits. In fact, we drooled over them. However, no prospective customer of ours ever had a six-figure budget for hardware.
The peripherals were also rather expensive. IBM in those days ignored standards used in the rest of the industry. It set its own standards, and they were all proprietary. So, cheaper hardware from other vendors would not work with IBM systems.
Although the price went down through the years, a 5250 terminal cost around $2,000 when the 5360 was introduced. The cheapest printers, which used dot-matrix technology, were in the $5,000 range.
The cabling was also not cheap. The system used twinaxial cables for direct attachment of these devices. Most competing systems used serial or parallel connections. Twinax was decidedly better, but it was also more expensive.
The local devices were connected in a serial fashion to a controller. Up to seven devices could be connected on one twinax line. Each device had two female twinax connections on the back, either in one T-shaped unit or with two short cables. One was called the “gozinda”; the other was the “gozouta”.
So, if the S/36 had four devices named A, B, C, and D. A would be connected to the controller by a twinax cable, B would be attached to A by a twinax cable, C would be attached to B, and D would be attached to C.
A switch on device A, B, and C needed to be set to allow pass-through to the next device on the line. On device D that switch needed to be set to denote that it was the last device on the line.
For device D to communicate with the S/36, all of the connections must be functional, and all of the switches set correctly. It reminded me of Christmas tree lights in the old days.
The S/36 also came with a serial port. Since a modem could be attached to this device, it would be possible for support people at IBM or the software vendor (or anyone else, for that matter) to sign on from a remote location. This was, of course, our dream; it would make support so much easier. The announcement brought it a little closer to reality.
The hard drive capacity varied from 30 MB to 400 MB. In the twenty-first century, of course, those quantities would only hold a handful of photos. However, to most software vendors in the eighties this meant that total storage was no longer a big concern. However, the default backup device was a magazine that held only ten 8″ diskettes. Each diskette had a capacity of only 1MB each. This was a rather obvious limitation on the practical storage.
It was possible to attach an 8809 1/2″ reel-to-reel tape unit to address this. I could not find a price for these monsters. It may well have been the case that if you had to ask the price, you could not afford it.
The System/36 had two processors. The main processor (MSP) executed the code; the control processor (CSP) managed the work for the main processor. The CSP was four times as fast as the MSP, and they worked perfectly in tandem. The S/36 could perform an amazing amount of work at very fast speeds with embarrassingly puny processors. It was also extremely reliable.
Some actions, such as IPL1 and backing up files, needed to be initiated from the system console. The system console on the 5360 was built in to the top of the box. Your system operator needed a wheelchair? Life was rough all over.
The System/36 supported five programming languages: RPG II2, COBOL, FORTRAN, BASIC, and Assembler. RPG II, a simplistic column-based language, was the most popular. Wikipedia says that this was because it was the least expensive3. The BASIC language was similar to the one used on the Datamaster. I never heard of anyone who programmed in FORTRAN or Assembler on a S/36.
BASIC programs could not be compiled. Therefore, a copy of the BASIC interpreter needed to be loaded into memory for each program that was running. Nevertheless, because the CSP was so efficient, TSI’s benchmarks showed that there was no noticeable difference in the speed of interpreted BASIC programs and compiled RPG II programs performing the same tasks. So, we never considered converting our program to anything besides S/36 BASIC.
IBM also positioned the System/36 with its DisplayWrite/36 software as a word processing server. We found it to be inferior to the Datamaster product in most ways.
The file structure of the S/36 was somewhat different from the Datamaster’s. Programs and other executable items such as BASIC procedures and system procedures were stored in “libraries”. Libraries were somewhat like directories or folders on a PC. However, there was no such thing as a sub-library.
Data files needed to have unique names. They did not reside in libraries. In order to identify which files belonged to which application, the names were preceded by a short identifier and a period. In GrandAd all the media files started with “M.”, and the other files started with “T.”.
The S/36 did not have a relational database4. However, the fields in each file were defined in the system using field names, positions, and length/type designations. These data definition specifications were called DDS. Programs could access files using the same ISAM techniques with which we were already familiar. However, IBM also offered a product named Query/36 that allowed someone who know how the files were named and structured to write queries in a manner that was similar to SQL. These queries could then be saved and executed on demand.
Query/36 was a valuable debugging tool. TSI required all of our clients to buy it.
IBM announced the 5362 in 1984. It was much smaller than the 5360—only about as large as a two-drawer file cabinets. It also had no special electricity requirements. It used the same operating system as the 5360, which was called SSP. It came with one diskette drive and up to 120MB of hard drives. A QIC (1/4″ cartridge) external tape drive was available. A 5250-type terminal plugged into the first twinax spot served as the system console. Fewer devices could be attached, but none of our clients ever reached the limit. Best of all, the starting price was only $20,000, about the same as two Datamasters and a hard drive.
Many advertising agencies in the northeast could afford this level of investment. It took some time for TSI to convert the ad agency programs. I remember spending many days at IBM’s office in Hartford working on this. After tat we needed to change the focus of our marketing efforts to larger ad agencies. At this point IBM had no system to offer to the many whose needs would be satisfied with one Datamaster with diskette drives.
We were happy with this announcement, but it was a disappointment that IBM had totally abandoned the market that had produced the majority of TSI’s sales.
The 5364 (or System/36 PC), which was announced in June of 1985, was IBM’s belated attempt to recapture that market. The starting price of $5,995 was quite attractive. For some reason the system console had to be an IBM PC, XT, or AT with a special card inside. The S/36 part was the same size and shape as an AT. It contained a 5 1/4″ diskette drive that was compatible with neither the attached PC nor any previous model of the S/36. Compatibility was not a high priority for IBM.
This bizarre arrangement was very difficult to explain to a prospect. Why would a super-reliable S/36 be coupled to the least reliable hardware ever to wear the IBM logo? It did guarantee that at least one IBM PC was installed at each location, I guess. However, most installations probably did what we did—attach the oldest, slowest machine available as the system console, and then use it only when necessary.
The 5364 had two severe limitations. In the first place, only four devices (counting the system console and the printer) could be attached. So, the S/36 customer could really only attach two more displays or one display and a printer. Still, that would suffice at most small ad agencies and at TSI. We immediately ordered one.
The other limitation was, in some ways, worse. The 5364 came with only 256K of RAM. Each session could use up to 64K. However, batch jobs counted as sessions. If one person started some lengthy reports or other process, the system could possibly reach the point where jobs needed to be swapped between memory and disk. This could severely impair the system’s performance.
The announcement of the 5364 created a good deal of business for a company named Black Box. They sold a box with slots for one 8″ and one 5 1/4″ diskette and software to make image copies from one to another. We bought one, and I used it a lot.
In 1987 IBM finally fixed all of the problems, at least the ones that most concerned us. The 5363 was a reasonably priced machine that was suitable for almost any small business. If it had been announced two years earlier instead of the 5364, we could have sold a lot of them.
I could not find anything either on the Internet or in our basement that listed the price of one. I don’t remember that anyone balked at the cost. I also could not discover how much memory it had, but I remember distinctly that it was plenty. It could handle at least seven devices, too, and you could get one with a built-in QIC tape drive.
We enthusiastically ordered one for TSI’s office and tried to get our Datamaster customers excited about it.
By the middle of the eighties most office workers had some kind of personal computer on their desks. They did not want someone to install a terminal next to it as well. But how could they gain access to the S/36 without a terminal? There were no networks worth mentioning in the eighties, and there was nothing like USB. The only way to reach the server was through a twinax line, and IBM did not share its knowledge of how the display and printer connections worked. IBM considered anything that it produced was proprietary.
IBM and many third party companies brought 5250 terminal-emulation packages to market. The idea was to be able transform the PC into a terminal on demand and then change it back. Although the other vendors had to reverse-engineer the 5250 interface, they still were able to produce competitive products that were cheaper and had more features than what IBM offered. They generally consisted of a three pieces:
A hardware card that fit into an expansion slot on the motherboard of the PC. That’s right. You had to take the cover off of the machine and add a card that had the brains needed to make the PC act like a 5250 card. You might also need to physically flip switches on the care to configure it. Then you had put the PC back together again. What could possibly go wrong?
A dongle (sometimes lovingly referred to as a “pigtail”) that screwed into the interface on the part of the card that stuck out the back of the PC. It provided a gozinda and a gozouta for the twinax cable(s).
Software to run on the PC.
When they first appeared, the cost of these packages was well over $1,000, nearly as much or more than a PC or terminal. However, the emulators had one very substantial advantage. The inexpensive printer attached to the PC could also be configured as a S/36 printer. This not only saved money and office space; it was also much more convenient.
For a few years the companies selling these packages did a land-office business.
1. IPL stands for Initial Program Load. It just means the starting process for the system. IBM had three-letter abbreviations of everything, including a three-letter abbreviations (TLA).
2. RPG is short for Report Program Generator. I could never understand why anyone used it.
3. IBM required separate licenses for each programming language that was used.
4. Two IBMers, Donald D. Chamberlin and Raymond F. Boyce, codified the Structured Query Language (SQL) used in relational databases in the seventies. IBM rejected it because the Indexed-Sequential ISAM structure that it used in its computers had much better performance. About three decades later the company changed its mind.
In early 1988 Sue Comparetto, who had handled the GrandAd accounts in New York City, received a call at TSI from IBM’s Manhattan office. One of our contacts, Quique (KEY kay) Rodriguez1 wanted to talk with us about Macy’s New York. Its advertising department had been using software programs on an obsolete System/34 to keep track of its advertising expenses and income. The system had been developed internally by people who no longer worked for Macy’s. Documentation was minimal.
Macy’s New York had recently merged with Macy’s New Jersey. The new entity was called Macy’s Northeast, and its offices were on an upper floor of the “world’s largest store” on 34th St. in Manhattan. The advertising department’s existing system had already been stretched to the limits and would never be able to handle the increased load. Moreover, the users were not happy with some aspects of the code. Alan Spett2, one of a very large number of vice-presidents at Macy’s, had been provided by corporate with a budget for replacing or updating the existing system.
I jumped for joy and clicked my heels when I heard about this opportunity. For some time I thought that companies that produced and/or scheduled their own advertising represented a attractive untapped market for the skills and knowledge that we had acquired from our seven years works with advertising agencies. Evidently I was right. We had never approached any of these departments because I had absolutely no idea how we could even identify which companies created and placed their own ads.
Coincidentally, IBM had just announced a new mini-computer, the AS/400, to replace the System/36 (which had replaced the System/34 in 1983). This announcement and its implications for TSI are described in considerable detail here.
I made several trips by Amtrak train to the city to document the requirements for the new system. Sometimes I was accompanied by Michael Symolon, TSI’s marketing director at the time, and sometimes by Sue. We soon learned that Macy’s advertising department did everything that an ad agency did except keep track of the amount of time spent on individual production jobs. In fact, they had an advertising agency name that they used when ordering media. In addition, the department had many other needs that regular ad agencies lacked. Specifically, they were required to allocate both production and media expenses to the selling departments. These departments were identified by three-digit numbers. Each was assigned to an administrative group that also had a number. In turn there were three levels of vice-presidents who “owned” administrative groups3.
Macy’s also billed the merchandise vendors (Clinique, Ralph Lauren, Levi’s, etc.) a portion of the expense for ads that featured their products. The cost to the merchandise department was net of these “co-op” billings. The contract could be for a percentage of the media cost or it could be a fixed amount.
The first phase of this job entailed providing Macy’s with everything that they needed to get the ads in all media scheduled—printed schedules in the format that they liked, “insertion orders” (called “delivery tickets” by other retailers) to accompany the materials sent to the media vendors, and so on—in every media. It also included keeping track of expenses and co-op for each level of the merchant hierarchy. There were several different formats that they used for reporting these breakdowns.
I envisioned that the creation of any ad would consist of five steps:
An ad number within the season and a version code that was usually blank would be entered, or ad numbers could be assigned by the system by pressing a function key.
A new ads screen allowed selection of the ad type (e.g., black-and-white ROP) and entry of the primary run date, which must fall with the season.
The other information that applied to all of the media for the ad would be entered on a header screen. This varied by type of ad, but each screen included selection of a pub group—a list of newspapers, markets, or stations.
A media selection screen showed one line for each pub in the pub group with dates, quantities, rates, and other costs or discounts. Any line could be edited or deleted. Additional pubs could be specified.
A participants screen to provide the list of departments or groups for the ad with the expected cost percentages and co-op amounts for each.
Storewide ads could be entered rather quickly. Ads with many departments or groups might take a few minutes. This approach was warmly received. The employees were accustomed to specifying the participants for each pub in the ad.
After the schedule was created, any aspect of an ad could be changed, or the ad could be killed, (in exceptional cases), deleted, or moved to a different date. New ads could be defined. Once the ad was run, the actual participants and the actual co-op could be provided. History records with dates, times, and user ID’s were kept for all changes.
How did Macy’s determine the percentage of the actual cost of each ad that was to be allocated to each department or administrative group? The process astounded me. In one room4 were seated from three to five clerks. Each was provided with a stack of newspapers and a list of ads that were scheduled to be run as well as lists of department numbers and the numbers of administrative groups. They looked through the newspapers to find the ads that Macy’s had run. They then measured—with a ruler!—each of the “blocks” in the ad to see how many columns wide (six columns to a page) and how many inches deep (i.e., vertically) the block was. They then entered the column inches for each block. For blocks that were not specific to a department or group, a special “storewide” department #999 was created. The total of the measurements must exactly equal the total size of the ad.
My approach changed this process so that the clerks measured ads, not insertions (the ad in a specific paper). If the ad was already measured, the clerk could see what had been entered, who did it, and when.
A similar process was also required for each page of each direct mail piece and newspaper insert. The ads for other media were not measured, but actual percentage breakdowns were recorded.
Similarly, the actual co-op dollars received from the selling departments (a process called “turning in”) could be recorded. Lists of missing co-op could be printed.
The most important financial reports for Macy’s compared the committed co-op and costs with the actual measured costs and actual co-op. They could be run for any or all merchants (the vice presidents who owned the departments) and any or all media.
In addition to all of this, Alan had ideas for other modules such as an inventory system for the merchandise used for photo shoots in the studio in Newark and a system to manage the shoots themselves. He also wanted us eventually to work on an interface with the Camex system that Macy’s used to create the images for the ROP6 ads and books. Thank goodness these ideas were not included in the original contract.
TSI’s GrandAd system for ad agencies had been built around a file for ads, the key to which was a three-digit client number and a five-digit job number. So, each client could have up to 99,999 jobs. For the departmental system, which I decided to call AdDept, I designed a similar structure, but, since Macy’s itself was the only client, I made the three-digit code stand for the season. 891 meant spring of 1989. 892 was fall of 1989. Eventually, a one-digit code for the century was added as well, but otherwise this proved to be a very feasible approach.
Many other structural changes were necessary. The most significant one was the designation of a one-character version code as part of the unique identifier (key) to the main media file. This could be used to make distinctions that varied by pub (media vehicle). For example, one item in an ad might be “swapped out” for a different item in another ad. The catalogs sent to some markets might not include some pages.
The new table for the pub groups mentioned above allowed Macy’s to identifying papers in which they often ran the same ad, e.g., the tabloids. There was no limit on the number of pub groups, and pubs could be in any number of pub groups.
I did not mention this to anyone at the time, but while I was gathering requirements, I noticed a very serious flaw in the design of Macy’s existing software for the S/34. The same ad was run in a few papers, but each insertion in each paper was given a separate ad number. The clerks doing the measuring were each assigned one or more newspapers. They measured and then entered into the computer the amount of space for each department in each ad. The person next to them might have already measured the same ad in a different paper, but there was no way for them to use that information; they had to key it all in again. So, with the S/34 design the increase in the number of papers added by the merger would more than double the work in allocating costs. My approach would decrease the work even with more papers. They would only measure the ad in one paper.
How great was this? The ROI for this feature alone would easily surpass the cost of the entire system in the first year!
How was such a colossal blunder possible? Well, the S/34 programs were designed for Macy’s New York, which advertised almost exclusively in only three papers: The New York Times (a broadsheet), the Daily News (a tabloid), and Newsday, a Long Island newspaper with a unique shape. Each of these would require separate versions and therefore separate measurements. However, all of the new papers were either tabloids or broadsheets. There was no need for separate measurements.
At some point in mid-summer TSI needed to do a presentation for Macy’s at IBM’s office on Madison Avenue in New York. There was no competition; no other software developer wanted anything to do with this project. The alternative for Macy’s was to enlist their IT department to do something. No one mentioned this, but I was quite certain that the IT department would not be able to deliver a functioning system that met all the requirements within the required time frame. Of course, I was not certain that we could do it either. However, we had delivered several large projects on schedule, and I was willing to put in the hours5 to make this one a success.
I wanted to demo the GrandAd system and explain how we would adjust the database to fit Macy’s. I made arrangements to use a S/36 in IBM’s office at 590 Madison Avenue to show how our advertising agency system currently worked and how it could be adapted. I considered–and still do–this to be the most important presentation that I ever gave. It was my only chance to persuade Macy’s Advertising Director, Howard Adler, that TSI should be contracted to do the project. I figured that if we got Macy’s, and we did a good job, a whole new market would be opened to us. At that point I was still naive enough to assume that other retailers would surely be much less difficult because we had already done the programming for the largest retail advertiser in the country.
I needed to transport our GrandAd programs and our demo data to New York. Not only was it not possible in 1988 to send them there electronically using something like FTP. We did not even have access to a compatible medium. The I/O device on IBM’s S/36 in NYC read 8” diskettes. Our system in CT used 5¼” diskettes. So, I saved our programs and our data onto nine 5¼” diskettes. Then I used a machine that I had purchased for just this purpose to copy the 5¼” diskettes onto previously blank 8” diskettes. I then loaded the 8″ diskettes into a “magazine” that I had obtained somewhere. The S/36 in New York included a device for reading diskettes from such a magazine.
You say that you are not familiar with the concept of diskette magazines? For over a decade IBM used them on the S/34 and the S/36. As far as I know, no other system from any manufacturer followed suit.
They were almost completely plastic. Their width was about an inch and a half. The other dimensions were just large enough for 8” diskettes. One side was open to allow insertion and removal of diskettes. Small plastic rails on the top and bottom of the open side kept the diskettes separate from one another. The only thing on the magazine that was not plastic was a small metallic bar near the top of the open space that held the diskettes in. The bar could be lifted up on a hinge to allow access to diskettes. The machine that read the diskettes could also do this (like a juke box), and it was smart enough to read them sequentially.
The process of saving and converting the programs and data, which I probably did over a weekend, took several hours. I then inserted the 8” diskettes into the magazine, put it in my sample case with my other materials, and then stowed the sample case in the trunk of my Celica. I do not remember why, but I must have left the car in the sun for several hours. When Michael and I reached New York and took out the magazine, we could see that the little iron bar that restrained the diskettes had apparently become hot enough to melt little notches into all the diskettes. The magazine drive on IBM’s system refused to read them. O tempora, o mores!
Michael had a brilliant idea. He used a sharp knife to slit the edge of each damaged diskette and nine new diskettes that we borrowed from IBM. The actual data was not, of course on the plasticized paper that one could handle (and therefore slit). It was on a very thin circle of magnetized film inside. For each new diskette Michael replaced the blank film disk inside with the one that he had retrieved from a diskette that I had made. Then he carefully inserted the nine new diskettes that hopefully contained our programs and data into the magazine. I then loaded the magazine into the S/36’s magazine drive again and entered the command to restore the files. The machine successfully read six diskettes. However, at that point it made an awful noise and totally mangled the seventh diskette including, because we had no way to reseal the side that Michael had slit, the precious film inside.
So, I was faced with the prospect of making the most important presentation of my life with absolutely no software to demonstrate. The pony in my “dog and pony show” was a stick-figure drawing. Would anyone notice?
Fortunately, my many years of experience in debate at adjusting a presentation at the last minute kept me from panicking. I began the presentation by apologizing for the technical problem. I then illustrated the approach that we proposed to take using the whiteboard that IBM provided, and I answered questions as well as I could.
It was enough. Macy’s agreed to put in motion the process of contracting with TSI. As Alan later said, “You were definitely the only game in town.”
The plan was to install the system in the “System/36 environment” of a B30 model of an AS/400. The I/O devices were a single 8” diskette drive and a ½” tape drive. TSI had no system that had either of these drives, and so our only choice was to execute the cumbersome conversion process every time that we needed to make changes.
I sent Alan our usual two-page contract. He sent it to their legal department and returned one with about twenty-five pages. I should mention that the TSI was dirt poor at this time. Sue and I had been low on funds before, but this was the first situation that rose to a crisis level. Details are posted here. We certainly could not afford a lawyer. I had to read the contract very carefully and assume the worst. After a few changes, we agreed, signed it, and started work. I did almost 100 percent of the coding. The other programmers were busy with work for our other clients, and I did not trust Sue to do the work.
I was not able to use a single program from the GrandAd system. I thought that at least one of the many insertion order programs that we had written for ad agencies would be usable without much modification, but I was wrong. The people in retail advertising just do not think like the people in advertising agencies. Every single program was written from scratch.
We had no time to produce a detailed design document describing the project. Our drop-dead deadline was the end of the season in late January. All programs must be totally functional. The process was:
Write the code.
Get it to the point where there was something to show to Macy’s.
Save the changes to 5¼” diskettes.
Copy the 5¼” diskettes to 8” diskettes.
Take the train to New York.
Install the new software from the 8″ diskettes. This could take up to an hour.
If changes had been made to the database definitions, make them on Macy’s system.
Make changes on the fly as necessary.
Show Macy’s how the new code works.
Save the changes to 8” diskettes.
Bring the 8″ diskettes on the train ride to TSI.
Copy the 8” diskettes to 5¼” diskettes.
Install the changes on TSI’s system.
This was, to be sure, a terrible way to do things. It required me to make at least one trip to New York every week for several months. Usually it was up and back on the same day. I stayed overnight at a hotel a couple of times. Often I made two up-and-back trips in a week. Each trip required a twenty-five minute drive to the train platform. I boarded the train at 6:00 AM in Windsor Locks. There is only a platform there. I therefore sat in my car with the heat on until I saw the light of the train approaching.
If everything went well, I arrived back at the train platform at 9:30PM. The trains in the evening, however, were almost never on time. Those trains originated in Miami, FL. There were plenty of opportunities for delay as each one crawled its way north. A report on my most memorable Amtrak experiences is posted here.
During this process Alan would quite often come up with new thoughts as to what should be in the “base system” covered by the contract. I grumbled, but I almost always did what he asked. One morning I saw a Daily News in Penn Station with the headline “Macy’s Computer System is Driving Me Crazy!” I bought a paper, cut out the headline, and taped it to the inside of my sample case.
Meanwhile, TSI had received only a deposit from Macy’s. However, we were desperate to receive that final check. I saw no alternative to this nightmarish schedule.
The scope of the project was enormous, and almost nothing from the GrandAd code was usable for this project. In addition to everything else, the emphasis at Macy’s was on newspaper ads. In my experience ad agencies used the term “print”, which for them referred to direct mail and magazines. Most agencies treated newspapers as magazines that published more often on cheaper paper to a geographically limited audience. The ingrates who ran the papers did not even offer discounts to ad agencies. Macy’s, on the other hand, could run a dozen or more ads in one issue of a newspaper.
Mirabile dictu! By February, 1989, the system was stable enough that Macy’s paid us most of the balance. This did not end the crisis at TSI, but it allow us to meet the payroll for a few months. In retrospect, I cannot imagine how we pulled it off. I remember working seven days a week. I was always at work by 6AM, and I seldom left before 7PM7. I admit that I always went home for lunch, and I usually took a short nap.
What enabled the completion of this seemingly impossible task in that amount of time was the fact that Alan somehow got Gary Beberman8 to serve as the project manager. He could speak advertising to the workers at Macy’s and geek to us. I only trained one person; Gary trained the others. I am not sure where Alan found Gary or how he got assigned to the project, but he was a godsend. He saved us a huge amount of time and frustration, and he was also quite adept on pouring oil on troubled waters during the frustrating periods in which I was working feverishly on the code.
The next two projects for Macy’s were an inventory system for the “loan room” (usually called “merch room” at other retailers) and a more sophisticated system of entering and reporting actual costs, what Macy’s called “financials”. I gathered the specs for these projects on trips to Macy’s and produced detailed design documents, which Alan quickly approved.
Denise Bessette did almost all of the programming on these two large requests, and she did an outstanding job. I installed the code and showed the people at Macy’s how to use the programs.
The loan room gathered merchandise needed for photo shoots and sent it to the photo studio in Newark or to some other location. Part of the automation of this process was the printing of tags for each item. Almost as soon as this was implemented, the amount of pilferage reportedly decreased dramatically. The merch room manager told me that previously a lot of merchandise had trouble remembering the way back to Manhattan from Newark. She was extremely happy with the new system.
Denise also completed the other project according to the approved design document, and I delivered it. The finance manager then produced a bevy of changes that she wanted. I offered to quote the changes at TSI’s usual fee of $75 per quote. Alan said that Macy’s was under the impression that these programs fell under the terms of the original contract. It clearly did not include them. He was also surprised that I insisted on charging for my time at Macy’s after the warranty period. I would not give in on these matters, and this caused some bitterness.
At some point in this process TSI leased an AS/400 model B10 from IBM. We hooked everyone up to it, and we converted all of Macy’s programs to run in the native environment instead of the System/36 environment. This project went fairly smoothly. I don’t remember any great headaches, and the programs were considerably faster.
In other respects the installation also proceeded rather smoothly as long as Gary was there, but when he and his wife moved to the West Coast, things started to get a little testy. Alan hired Satish Rahi9 (accent on the second syllable in both names) to manage the installation. Satish must have presented himself as an alternative to paying TSI to program reports. He thought that he could produce any desired output using a third-party query product from a company called Gupta Technologies. Their Wikipedia page is here.
Satish was shocked that the product did not work on most of our tables. I told him that there was nothing in our contract that said or implied that third-party products (of which even then there were quite a few) would work with tables that we designed and implemented. IBM’s Query/400 product had no trouble with any of our tables. After considerable digging I determined that the source of the problem was that we wrote records in BASIC, not in SQL10, which was not even available on the AS/400 yet. The designers of Gupta’s product evidently did not take this into account when they began marketing to AS/400 customers.
Satish started lecturing me about industry standards for databases. I explained that the industry standard for writing x-digit positive integers in BASIC was N x, which left-pads these numbers (such as the ad number) with blanks, as opposed to ZD x, which left-pads with zeroes. In fact, most versions of BASIC did not even have a way to write “zoned decimals” without writing extraneous code to do it11. One day I got so upset while arguing with Satish about this that I seriously considered driving down to the Amtrak stop so that, after sitting on a train for over three hours, I could ride the elevator up to his floor at Macy’s and punch him in the nose.
Not long after this conversation Alan fired Satish, and eventually we changed all the programs to “zone” all the integers. Of course, we got paid for neither this project nor the conversion to the native environment, but we felt that we had to do them to hope to stay in IBM’s and Macy’s good graces.
From that point on we dealt with Denise Jordaens12 and Lee Glickman13 at Macy’s. Things stabilized, but the department did not get nearly as much out of the system as it could have.
Over these years Macy’s went through a lot of changes. In January of 1992 the company declared bankruptcy, thereby leaving TSI with a stack of unpaid invoices. In 1994 Macy’s was absorbed into Federated Department Stores, which had itself just emerged from bankruptcy. This gave them a new set of standards to abide by. Eventually other acquisitions gave Macy’s in New York a large number of new stores to manage on the east coast. They continued to use the loan room system and to pay our maintenance bills. They never asked about any of the enhancements that were installed at Macy’s South and Macy’s West.
There were other complications as well. On one occasion Macy’s asked for someone from TSI to visit so they could explain their problems with and aspirations for the system. My schedule was totally booked for weeks in advance. I asked Sue to take the trip. She did. I don’t know what transpired, but Denise Jordaens later told me that they made a voodoo doll of Sue and stuck pins in it.
I may have made some bad decisions about Macy’s. I did not yet understand how decisions about products and services like those offered by TSI were made in a large retail advertising department. This issue is discussed in more detail here.
TSI probably should have charged more for the original installation and used the money to hire another full-time programmer. Maybe we should have tried to borrow money from somewhere. I was unwilling to put all of our eggs in the Macy’s basket. Macy’s declaration of bankruptcy was a devastating blow to TSI. When Macy’s was acquired by Federated Department Stores14, it appeared to me that the decision to concentrate our efforts elsewhere had been a sound one.
As it turned out, however, Macy’s eventually gobbled up nearly all of the regional department stores in the entire country. The strategy that I chose helped TSI succeed for more than twenty years, but if I had gambled on Macy’s, we might still be in business in 2021. On the other hand, we would have been working almost exclusively for Macy’s for most of that time. Such an experience might have really driven me crazy.
The story of the Macy’s installation had a bizarre final chapter. It is recorded here.
1. According to his LinkedIn page (which is here), in 2021 Quique Rodriguez is retired and enjoying family time. I suppose that it is possible.
2. Alan Spett lives in Atlanta in 2021. His LinkedIn page can be found here.
3. So, I designed the database with five levels of participants. The lowest level was always called a department, but the names of the other four levels to be used on reports and screens could be specified by each AdDept client. At all Macy’s divisions they were called Administrative Groups, Group VP’s, Senior VP’s, and Group Senior VP’s.
4. This same room housed the AS/400, at least for a while. I sat at an empty desk when I was there. When the first phase of the installation was completed, some of the measurement clerks were reassigned to other tasks.
5. Unfortunately, I don’t think that I was careful enough to account for the large number of unproductive hours that I would spend on trains, in meetings at Macy’s, and in converting files. The round-trip train ride alone accounted for six or seven hours and a drive of nearly an hour, So, each full day at Macy’s was matched by another full work day getting there and back!
6. ROP stands for “run of press”. All display ads (as opposed to preprinted inserts) that are run in a newspaper are called ROP. It is not an acronym; all three letters are pronounced.
7. I am a “morning person”. Any work that I did after 7PM was likely to be counterproductive. Moreover, I needed a few caffeine-free hours so that I could fall asleep at 10PM and stay asleep.
8. I have kept in touch with Gary Beberman. He moved to California to work as a consultant and then was employed by Macys.com. Macy’s West and Neiman Marcus hired him as a consultant during their AdDept installations. He was the only consultant whom I ever respected. He has lived in Marin County for the last five years. He and his wife are hoping to retire to Italy.
10. SQL (structured query language) was invented in the seventies by two IBM researchers, but at the time of the debut of the AS/400 no IBM computers used it much. The reason, we were told, was that it was much less efficient than the ISAM methods that IBM endorsed. Later IBM computers, including the AS/400, were designed to maximize the efficiencies of SQL queries.
11. What I said to Satish was correct from my perspective, but perhaps I should have asked him what made Gupta Technologies think that the AS/400’s relational database conformed to these “industry standards” that he cited. After all, SQL had been invented by IBM, and IBM was not yet positioning its AS/400 as an alternative to the “standard” databases such as Oracle, Sybase, or Informix.
12. According to her LinkedIn page (here) Denise Jordaens still works as coordinator of media systems for Macy’s.
13. I think that this might be Lee Glickman’s LinkedIn page.
14. A more detailed discussion of TSI’s long and torturous relationships with Federated Department Stores can be found here.
IBM’s introduction of the System/23 Datamaster in June of 1971 was a tremendous opportunity for TSI. In fact, if the announcement had been a month later, I probably would have given up on TSI and looked for a job.
The Datamaster was one of the very few systems in the early eighties that offered small businesses of all shapes the opportunity to automate their operations. There were competitive hardware systems, of course. Some of them offered more processing bang for the buck, but none of them had the three magic letters I-B-M on the hardware. IBM had a well deserved reputation of delivering high-qualiity system with unmatched service. “No one ever got fired for recommending IBM,” was a popular saying.
What we did not realize until we got our hands on it was that the Datamaster was extremely easy to program. Of all the systems that we worked with, I enjoyed working on a Datamaster the most. We delivered an enormous amount of code to meet incredibly diverse requirements in a very short period of time.
We depended on IBM for most of our new clients. The exceptions were Harstans Jewelers (described here) and advertising agencies (described here and here). I am uncertain of the order in which we acquired the new clients. The order in which I have listed them here may not correspond to the order in which we did the projects.
In most cases we took delivery on their systems in our office in Rockville and then carted them to the user’s location when the systems (or at least the most important modules) were ready. Once this started we always had at least one system in the office until the time that we bought one for ourselves.
One of the most memorable clients was Ledgecrest Convalescent Hospital, a nursing home in Kensington, CT. The proprietor was Paul Prior1, one of the most interesting people whom I have ever met and one of the few clients whom I got to know pretty well.
When Sue and I first met Paul I was quite intrigued by his business. Paul’s goals were not much different from those of any other small business. He wanted to bring his company into the twentieth century. Most of the applications that interested him were fairly standard,—patient billing and accounts receivable, accounts payable, and general ledger.
The last was his top priority because a high percentage of his receipts came from reimbursement from the government. The amount that the state reimbursed the business depended on his keeping a close eye on expenses. A mistake could cost thousands. So, the objective was to produce a system that allowed Paul to keep Ledgecrest’s expenses within state guidelines year after year. Anything over the legally prescribed “caps” would be disallowed.
The important thing was for him to learn where he stood while he still had time to do something about it. He needed to project his spending fairly accurately beginning in the middle of the year or even earlier. This sounded to me like something that would be valuable to all of the nursing homes in Connecticut. I had high hopes of marketing it to the dozens of nursing homes in the state, and I did. That effort is detailed here.
Paul also ran a second company called Priority Services. It provided Meals on Wheels to aged and disabled people.
After we won the contract and delivered the first part of the system, Paul told me how much he enjoyed working with the system. For reasons that I did not yet understand he had done all of the initial data entry himself. As usual he was drinking coffee from his dirty cup. He never washed it because, he said that it protected him from a weak cup. That was the day that he identified for me the feature in our systems (I forget exactly what impressed him) that convinced him to hire us. I chuckled when I informed him that our systems did not actually have that feature. He must have mixed us up with someone else.
Paul told me that he had been drafted in the fifties and took part in the Korean War. I don’t use the word “fought” because he told me that as soon as he got close to combat he “went over the hill”, was apprehended by MPs, and then spent some time in the brig.
When he got his discharge (I didn’t press him for details) and came home, he discovered that his older siblings had taken control of the family business that had been founded by their parents. According to Paul, everything was a mess. Bills were going unpaid, and the standards of patient care had dropped precipitously. Meanwhile his brothers and sisters were living high on the hog.
Paul somehow chased them out and took over the management and eventually the ownership of the business. He went to each creditor and arranged a plan for paying all the bills. Eventually he reestablished the reputation of the institution. I was very impressed by this. Nobody had ever related for the origin story of his business.
While I worked with Paul on getting reports from the G/L system to provide the information needed to maximize his income from the state, I got to meet the other three people in the office, all of whom were female. The first was named Dorie. She served as secretary and reception. She also paid all the bills. I don’t remember the second lady’s name. She was, among other things, in charge of Priority Services. The last was Paul’s daughter, Kathy, who helped out part time. I think that she was engaged to be married.
I don’t remember exactly what the system that we designed for Priority Services did. I think that they recorded who was to receive meals on specific days, and the computer printed delivery routes. I seem to remember that it also did billing. One day Paul asked the lady who ran this system to get me a cup of coffee. She asked me how I liked my coffee. I requested just a little bit of sugar and no cream.
The beverage that she brought me back was so sweet that I could not drink it. She explained that she could not find any sugar, and so she substituted a packet of Sweet’n Low. That didn’t seem like enough to her, and so she poured in a second envelope. From that day forward I drank my coffee black. I eventually learned to appreciate the bitterness.
The last system that we got working was accounts payable. I spent one session with Dorie in which I tried to learn how she did things. I asked her how many bills they had in accounts payable. She responded “None.”
I mansplained to her that I meant how many invoices that she had not paid yet. She insisted that she had none. Eventually I realized that, unlikely as it may seem, she was right. As soon as she got an invoice from the mailman she wrote out a check, stamped it with Paul’s signature, put it in an envelope, and mailed it.
Paul, perhaps mindful of his terrible experience with debts to vendors when he took over the business, tolerated this approach. However, he understood, that it tied his hands with respect to cash flow. Furthermore, after Dorie paid the bills they still had to be entered into the general ledger system.
The problem was that Dorie was terrified of the computer. The night after I talked with her about accounts payable, she could not sleep at all. I wasn’t there, but the next day she came to Ledgecrest and was ready to quit her job. Paul assured her that she would not be required to use the computer.
Instead, Paul entered in records for all the vendors himself. Once he had done so, it was easy for him to keep up with them. He did not need to enter a stack of open invoices and reconcile balances. Paul found something else to keep Dorie busy.
I doubt that anyone with an MBA would have approved of this extreme “Theory Y” management style, but it seemed to work for Paul.
Ledgecrest and Priority Services upgraded to a System/36 in the late eighties.
In many ways National Safe Northeast was not an exceptional company. Most of their customers were banks. By the time that I started working with them their primary products were no longer safes, but Automated Teller Machines (ATMs). Their office was in an industrial park in West Hartford2. The most peculiar thing about it was that four family members were often present: Tony Bernatovich, who ran the company, his wife Lynn, who had a title but no evident responsibilities, his daughter, who was sort of the office manager when she was there, and a very large dog.
They wanted us to install a rather standard bookkeeping system. We made very few adjustments to the accounts receivable, accounts payable, and general ledger systems. It made me wonder why the IBM rep did not just sell NSNE IBM’s packaged systems. They would have worked pretty well.
Tony’s real interest was in a customized payroll system. NSNE used a method called “half-time due”. You haven’t heard of it? Neither has anyone whom I have ever met. There is not the slightest passing reference to it on the Internet.
NSNE did not want its installers to work overtime. Since they were out on the road, it was difficult to control their hours. Employees who put more than forty hours on their timesheets were only paid half of their usual rate for the excess. Not double-time, not time-and-a-half, just half-time. If the total pay for the period was less than the minimum wage, they were paid the minimum wage.
Was this legal? I don’t know. There are several case files for lawsuits involving NSNE3, but I did not find any that involved complaints about illegal compensation schemes. Incidentally, although I was always on the lookout for an edge for our software, I never considered marketing this feature.
We primarily worked with three people at NSNE. Joan Kroh was the accounting manager. Her assistant’s name was Darlene. There was another employee named Jimmy. I do not recall either last name.
I am not sure what Jimmy did, but one morning no one else was there, and he was supposed to enter some accounts payable. The system was on, but he could not get it to work. I tried to talk him through it over the phone. I asked him to key in GO APMENU and then press Enter. As God is my witness, I talked on the phone with him for forty-five minutes, and he could not accomplish this. Finally, Darlene came in and keyed it in with no difficulty. It took her less than a minute.
I have two other fairly vivid memories. In one of them I was driving my car to NSNE. It overheated. I had to pull over to the side of the road. I loosened the cap on the radiator, and steam and hot water blasted me in the face. I was not hurt, but I was a mess. I went to NSNE anyway. I never have cared much about appearances.
Darlene and Joan played in a woman’s football league. It was flag football, but these ladies were serious, and Joan was one of the best players. I was very impressed.
When the Lingerie Football League appeared on television I could not help thinking about the contrast between the ladies on TV playing “tackle” football in bikinis and shoulder pads and Joan’s teammates wearing sweatpants and tee shirts knocking one another on their asses.
I never felt as ill-at-ease at a client’s offices as I did at John LaFalce, Inc., on Route 44 in Canton, CT. John4 was (and apparently still is) an interior designer. His retail office in Canton showcased a lot of eclectic furniture and doodads. I avoided the showroom lest one of my elbows occasion an unintended purchase. Rich people came there to hire him to redo the interiors of their Connecticut homes while they were living in one of their other houses. Or maybe vice-versa.
I think that TSI just implemented accounts payable and general ledger systems for them. We might have done some other programming that I don’t recall. There really was only one user, the bookkeeper, whose name was Jan Shustock.
I remember a meeting that involved one of the guys who ended up buying out John LaFalce, Inc. After the purchase they changed the name to LaFalce Campbell Robbins. The third person in our meeting was an IBM sales rep. The new owner mentioned something about red and blue not going together. As one, the rep and I held out our red and blue ties and looked down at them.
I also remember being stunned when TSI delivered the Datamaster that we had been working on to JLF. They asked me where, in my professional opinion, in their business office they should locate the computer system . They had sixteen employees, most of whom designed interiors for a living. They were asking a coffee-swilling code jockey how to arrange their furniture. I told them how long the cables were, but I refused to venture any further opinions.
Sue did most of the work for Standard Metals. The proprietor was Steve Buzash5. The person with whom we worked the most was named Carol. I recall very little about what we did for them, probably A/R, A/P, and G/L. I remember Steve talking with us about designing an inventory system. His inventory consisted of pieces of metal of various compositions, shapes and sizes. He often cut off pieces and sold them. It sounded like a nightmare to me.
Carol and Steve got married. They invited us to their unusual wedding, which took place on a large boat on the Connecticut River. After the ceremony there was a supper, which was followed by something that most of the people in attendance had never heard of, Karaoke.
Two people ran the show, a guy who served as MC and a woman in a sparkly dress who was obviously a professional singer. He told us tha we were going to be the entertainment, and we were going to have FUN!!!
To get things started, the lady sang a song. Needless to say, she hit every note perfectly and also inserted a few bel canto flourishes. Everyone was totally intimidated. I, for one, was wondering how far the shore was, and whether it would be worthwhile to try to swim for it in my suit and dress shoes.
When no one volunteered, the MC tried to coerce people into trying it. He promised “we will make you sound good.” A few people eventually ventured forth. I think that Sue sang a duet of something with Carol. The event lasted at least ten hours. No, I guess that would be impossible, but it sure seemed like it.
Dave Tine asked us to provide a computerized system for his sister’s company, Videoland, a company that sold home entertainment systems and rented VHS tapes. Its store and office were on Farmington Avenue in Hartford, but we never went there. I have a vague recollection that TSI did a simple inventory system for her. We probably also provided A/P and G/L systems. We billed Dave Tine for our work.
The company went out of business when Blockbuster Videos started appearing on every corner.
After we had a few installations, IBM accepted us into its fledgling Business Partner Program, which meant that we could make a little money selling hardware. One of our very first sales was to the Business Office of Avon Old Farms School. The Business Office Manager was Walter Ullram6. We sold them three diskette-based Datamasters. One was used for accounting functions by Mary Lee Pointe. One was used strictly for word processing by Walter’s secretary. The third was used by the bank. I don’t remember the names of either of these ladies.
The best thing about the AOF installation was that one-third of it required no support at all. The secretary loved IBM’s word processing system, and she learned how to use it from the manuals.
The first time that I visited AOF Walter showed me the system that he had developed for tracking on accountants’ sheets the school’s usage of oil in comparison with the heating-degree days. I was very impressed with how he had devised a scientific system to pinpoint inefficiencies and control the amount of money spent on heating all of the buildings. I was less impressed when I visited a few of the other buildings and saw that people there were coping with the cold weather by using incredibly inefficient electric space warmers.
I went to a very good prep school, but it was nothing like AOF. All Rockhurst students commuted. Most of the AOF students were boarders. They had uniforms, but they deliberately looked like slobs. We had no uniforms, but everyone dressed pretty nicely. The tuition at AOF was about thirty times what my parents paid. I soon learned that a lot of the AOF guys were “trust fund” students. Neither parent paid the tuition. It was paid by a trust set up when the parents divorced. Nearly all of the students were wealthy. Few were on scholarships.
I mostly worked with Mary Lee, whom I liked a lot. She had one very strange mannerism. A light on her telephone indicated whether calls originated inside the school or outside. When she answered outside calls, she began in a voice nearly as deep as Lauren Bacall’s, “Good afternoon, Mrs. Pointe speaking.” For inside calls, she sounded like Jerry Lewis’s falsetto, “Hello-oh?”
AOF reported a problem with connectivity. I cannot remember why they had to run long cables (maybe for Mary Lee’s printer), but they did. The cables did not run along the floorboards. They went through the walls and ceiling. We eventually discovered that the connections were OK, but some squirrels living above the ceiling had chewed through the cables.
I was surprised to learn that AOF had a bank for its students. The parents did not send money for incidentals directly to the students. Instead the money went to the school, and the students were allowed to withdraw it. It was a simple system to write, and the lady who used it really liked it.
All in all this was a very satisfying installation. Walter and the users bragged about it to others in the faculty. I was considered a hero by all of the people that I worked with, and TSI made quite a bit of money on it.
I knew that there were quite a few prep schools in New York and New England. I was hopeful that there might be business office managers at some who were interested in automating. When I learned that Walter’s brother held that position at Westminster School in Simsbury, I was pretty optimistic. The story of our attempt to market Mary Lee’s system is told here.
Another favorite client was Viscom International in West Simsbury. Although their business was the importing and marketing of parts for boats, three of the four employees had formerly worked at advertising agencies. In fact, “Viscom” was short for “visual communication”. They were therefore very interested in the ad agency system that we had developed for Harland-Tine.
The principals were Curt Hussey and Frank Hohmeister7. The third advertising guy was an artist. I don’t remember ever even talking with him. Mostly I dealt with Curt and the administrative person, whose named was Mary. She also doubled as a model in ads that they produced to feature marine equipment that they imported from France. As Frank remarked once, “She could fill out a pair of jeans.”
The most enjoyable thing about this account were the lunches that Kurt, Mary, and I consumed in the small restaurant in the shopping center in which they were located. I recall good food and good conversation.
The account itself was a fairly difficult one. The primary system was inventory, and users are often unhappy with their inventory systems. Every transaction must be perfect, and designing a bullet-proof auditing system is difficult. Although their system was working fine at the time, they eventually decided to buy an IBM AT and ditch the Datamaster. The primary motivation was that Curt wanted to be able to do spreadsheets.
My recollection is that Curt had a heart attack while I was still visiting Viscom frequently. He came back to work not too long after that.
Mary left Viscom to work in a restaurant well south of Hartford that was managed by her husband. Sue and I went there for supper once, but I don’t remember any details about it.
Viscom went out of business in 1993.
We sold two Datamasters to the Feldman Glass Co. in North Haven. That was one less than the number of companies that they had. The parent company manufactured glass bottles that they sold and delivered to companies in the Northeast that distributed food or anything else in bottles. This company required only fairly standard accounting software.
The second company was named Anamed. It provided hospitals and the like with small plastic bags that contained tooth brushes, combs, and other hygienic items for patients. I think that we wrote a billing program for this service.
The bookkeeping for these two companies and the data entry for the computer was done by a mother-daughter team. The mother was named Isabel Blake. I don’t remember the daughter’s name.
I don’t remember the name of the third company. It specialized in “fulfillment”. Liquor companies ran contests in which they awarded fairly valuable prizes in exchange for some large number (fifty or more) of labels from their bottles. I don’t know how that Feldman Glass got involved in organizing and keeping track of all of this, but I guess that it was no more distant from its core business than Anamed was. At any rate they told me how they wanted it to work, and I did it.
One day I overheard one of the Feldman/Anamed ladies say that they had bought the wrong computer. I knew very well that it was unlikely that they would have found anyone who was willing to customize three different systems for them on any other computer. It was much easier to criticize the Datamaster’s specs than the quality of the installations. Someone had probably scoffed a the notion of using an underpowered system. I assume that they bought something else after using our systems for several years. It was just as well. Their businesses were so unique that we could not really even use them as a reference account.
I could find no evidence of the existence of any of these companies past the early nineties.
One of our strangest clients was Hartford Cutlery, a one-man operation owned by Bob Burke8. His parents owned East Granby Machine9, which had actually purchased the Datamaster. Bob’s business was sharpening knives and scissors for restaurants. I don’t think that he had any employees. His grinding equipment was kept in a little room at his parents’ company, but the Datamaster was actually in his house a few blocks away. That’s right. We sometimes made house calls.
Evidently all restaurants of any note had at least two entire sets of knives and scissors. Once a week Bob picked up a tray of cutlery from his clients, sharpened all of the pieces, and then returned them to the restaurant. Maybe he could pick up and deliver at the same time if he came very early or very late.
We wrote a billing program for him. It saved him a lot of time. It fed accounts receivable and general ledger systems.
Bob felt constrained by geography. There were not enough high-quality restaurants within an easy drive for him to make very much money. I could see what he meant; East Granby is not usually considered the center of the culinary universe.
Bob then told me his plan, or maybe it was his dream. He wanted to invade New York City. His scheme was to rent (or inherit or buy or steal) a helicopter and begin making daily flights to the city to collect knives to sharpen. He figured that he could undercut the prices of the local competition and still make a hefty profit. We didn’t talk about how he would get around in the city. I suppose that he could buy (or inherit or rent or steal) a truck of some sort to hold the trays of cutlery as he went from one posh dining establishment to another. There might be a place to park it near the helipad, although, now that I think of it, parking spaces there went for upwards of $50 per day even in those days.
Bob used our software for quite a while, but then we lost touch. I have seen no evidence that he ever implemented the plan or, for that matter, that he didn’t.
Putt Brown ran his family’s business, Mono Typesetting, in Bloomfield. I think that he may have gotten our name from a mutual friend and client, Ken Owen, whose story is here. We did a time and materials billing system for him that fed rather standard accounting systems.
Putt and I often ate lunch together. He was a peculiar dining companion in that he saw a menu as not so much a list of food choices as an agglomeration of type fonts. He often lamented about the state of his industry. He said that he was forced to purchase new electronic typesetting equipment every year. As soon as he got a new system it was obsolete.
I don’t think that he realized it yet, but not very long after this conversation everyone would become a typesetter. Every font imaginable became usable by every Tom, Dick, and Harry with a personal computer that cost a tiny fraction of the systems that Putt was burning through. I am pretty sure that Mono was the last standing typesetting company in the Hartford area, but Moore’s Law killed it as well.
At the time I was a fairly serious vegetable gardener in the small patch of courtyard behind our house in Rockville. Putt told me that he was going to try raised beds for his next planting. Raised beds are quite a bit of work, but they allow more heat to reach the roots, which, for some plants, stirs more growth. It seems like the technique would work best for root crops. The other advantage is that you can sit down rather than kneel down when weeding the crops.
I wonder if Putt actually tried it and whether it worked.
In 1988 I was very surprised to see Putt again in a very unusual setting. In fact, I was wearing a disguise. The incident is described here.
Suzanne Nettleton owned and operated a company in Middletown, CT, called Professional Relief Nursing. The company maintained two lists, nurses looking for work and institutions looking for nurses. PRN then matched them up.
Suzanne had already had two bad experiences with computing systems. Several years earlier she had tried to get someone to develop a system for her on an Atari computer. You could play Pong on it, sure, but I never heard of anyone trying to develop an administrative system on one.
On her second attempt she did a better job of selecting the computer (a Datamaster), but she chose the wrong people to develop the software. It worked OK at first, but at some point they refused to support it any longer. So, Suzanne asked us to take over the maintenance.
We printed out the listings of the programs. They did not meet our standards by a long shot, but they were fairly simple. We insisted on converting the programs to meet our standards. She agreed, and we signed a contract. Over the years we did a fair amount of additional programming to provide a more comprehensive system.
I have two vivid memories of this installation. The first was the drive to the PRN office. I was shocked that there were two stoplights10 in Middletown on Route 9, a six-lane high-speed highway.
The second memorable event occurred when I showed up early one afternoon for an appointment with the guy that Suzanne had hired to operate the Datamaster system. When he saw the McDonald’s bag that I brought with me, he exclaimed, “Oh, you eat styro-food!”
By far the most prestigious name on out A4$1 client list was only three letters long, IBM. A new department devoted to the IBM Business Partner Program resided in the company’s Armonk, NY, complex. We drove there and talked with Dick Patten, the IBMer in charge of the program, about installing a customized system for lead-tracking on a Datamaster. He liked our approach, and we were equally enthusiastic because we had already developed lead-tracking software for our own use. We also had installed it elsewhere a couple of times.
So, we signed a contract. Dick was then shocked to find out that he could not get IBM to deliver him a Datamaster for several months. He was astounded even more when we told him that if he ordered it through TSI, we could deliver a system in two weeks. Our orders went through “the channel”, which, sometimes but not always, had much better delivery times than were available elsewhere.
For a moment Dick actually considered our offer. Instead, he informed his hardware contact at IBM about our offer. He then demanded to know why the business partners had better access to systems than the man IBM had chosen to manage the business partners. Evidently they found one for him.
While we were in Armonk we chatted one day with a female college student who was employed by IBM for the summer. She told us that IBM had a policy of providing summer jobs to offspring of its employees who were at or above a certain level. She qualified because of her father’s rank.
She said that hers was the best job ever. She astounded us when she disclosed her hourly pay rate. $17 sticks in my mind, but that seems excessive. Also, on her first day her supervisor told her to go to the supply closet and take whatever she thought that she might need. No one kept track of anything like that.
When IBM found itself in financial difficulties in the nineties, this young lady’s tale popped into my head.
TSI had two clients in East Greenwich, RI. One of our most important was an advertising agency that is described here. The other was on the other end of the spectrum. Thorpe’s Wine and Spirits, which I think was just called Thorpe’s Liquor Store in those days, was a small adjunct to Thorpe’s Pharmacy. The pharmacy was sold to a major chain (weren’t they all?), but the liquor store still survives.
The proprietor, Gill Thorpe, told us that he had a Datamaster that he would like to used for an inventory system for his liquor store. We had quite a bit of experience doing retail inventory by this time, and the liquor operation was much simpler than a chain of jewelry stores. So, we took on the project in spite of the distance. I found the contract for this account in a box that Sue stored in my garage. We only charged them $500!
We evidently did a good job. The operator, Richard Thorpe11 (Gill’s son), called us for support a couple of times, but he never complained about the system, and they never asked for any enhancements.
One of the last Datamaster clients that we worked on, and certainly the site of the last such system that was still in use was the Regal Men’s Store of Manchester, CT. This store also had the distinction of being the only TSI client (other than IBM) that I personally patronized. I did not go there often, but when I needed something, I generally made the drive.
There was not much to the system. My recollection is that they did nothing but accounts payable on their Datamaster. I would have remembered if we had installed an inventory system.
IBM stopped marketing the Datamaster in 1985. We still supported our clients, and more than once we helped them find used parts—usually diskette drives. In the early nineties we were still supporting all the software that we had written for the Datamaster, but we sent a notice to all of these clients that we would NOT address the Y2K issue on these systems, and we would not support them after 1999. By this time IBM had reasonable hardware alternatives for most of them, but none of the A4$1 clients hired us to convert their code.
In 1999, however, the computer operator at Regal’s, Ann Gareau, begged us to make her system work past New Year’s Eve. I told her that they really should get a new computer and that all of our other Datamaster customers had moved on. She told me that management would never approve the purchase of another computer. She was probably right. The company closed its doors in 2000.
I told Ann that the programs would probably still work in 2000, but the aging would look strange. They might occasionally need to fudge the system date to get the program to accept some dates. She seemed satisfied by that.
I have a strong feeling that I left out at least one other A4$1 client.
1. I think that Paul still lives in Berlin, CT, in 2021.
2. The address was 21-C Culbro Drive. The street no longer exists. I don’t know what happened to it.