In 2003 Sue and I took the “Best of Italy” tour sponsored by Rick Steves. I then wrote a journal compiled from the notes that I had recorded every day. After I was satisfied with the results I assembled them into a pdf file called “How I spent my Italian vacation” that I shared with other tour members and a few other people. That document is posted here.
The programming tools: During this same period IBM discontinued support for the Net.Data product that I had used to write the software for AxN (introduced here), TSI’s online clearinghouse for insertion orders from advertisers to newspapers. Instead, IBM had agreed to offer the php environment that had been developed by Zend1. I had previously learned about php from Ken Owen (Introduced here). He had told me that I could create and run php programs on my Windows computer for free by downloading WAMP, which stands for Windows (operating system) Apache (HTTP server) MySQL (database) php (scripting language). I downloaded it to my PC, set it up, and used it to write a little problem management system for TSI that was actually used for several years.
I had already learned that in order to do programming for the Internet that accessed a database you really need to know five languages: HTML, JavaScript, Cascading Style Sheets (CSS), SQL, and a scripting language to fit all the pieces together. I had books that documented the first three. I soon discovered that books on php and MySQL were not necessary. The syntax of each was thoroughly documented online, and answers to every question that I had were easily found using google. I never had to ask anyone for help.
The first project: Sue and I had planned for another trip to Italy in 2005. This time we invited our long-time friends Tom and Patti Corcoran to accompany us on another Rick Steves tour, “Village Italy”2. I intended to take notes and assemble them into another journal. This time, however, I wanted to do it a little more professionally. I purchased a Cascio point-and-shoot digital camera, mostly using points from one of my credit cards. Since I wanted to allow others in our tour group to be able to enjoy the journal, I needed to build a website. I knew how to do that on an AS/400, but I wanted projects like this to be independent of the business, and I was not about to buy an AS/400 and try to run it from my house. I wanted someone else to manage the site for me.
I did a little research on the Internet. A company named iPower seemed to offer everything that I needed at a fairly reasonable price. Its tools seemed to be well documented, and, especially for the first few years, the technical support was excellent. My first contract with them was signed in July of 2005. I might have had a free month or two before that.
I decided to name the website Wavada.org. Wavada.com was available, but I had no intention of using the website to make money. I wanted to a place to noodle around with Internet programming (my personal computer, which at the time was a laptop) and a separate place where I could show some of the things that I had developed to the world.
I needed some tools on my PC to let me edit the text and images. I had previously downloaded TextPad, a “shareware” (free but with requests for donations) product that was better at editing text than the program that came with Windows. I purchased a copy of UltraEdit, which could be tailored for use with the color-coded and spaced text of php scripts, and Paint Shop Pro, an inexpensive program for editing image files. My plan was to do all of the development on my PC and, once everything was working, upload everything to Wavada.org using either File Transfer Protocol (FTP) or the File Manager program that iPower provided.
The first journal: My first big project used php to create one web page for each day of the 2005 trip. I created a folder named Images and inside of that folder a folder the trip (VI). Inside the trip folders were folders for each day (VI01, VI02, etc.) and one each for the full-page version of the photos3 and the page (VI00) describing the preparations and the travel day. I later wrote a php script that was included at the top of the code for each trip that. This contained all the common scripts for handling layout and navigation as well as the unique elements such as character sets for foreign words.
A separate php script for each page contained the code necessary to display the page. Most of the necessary functions were stored in a file named JournalFunctions.php. A file named JournalSetup.php contained other settings. These were all “required” on every page. Styles were stored in JournalStyle.css and JournalMenuStyle.css.
For the most part the original design worked fairly well. One difficulty that I had no way to anticipate was that the Unix version on the iPower servers was more sensitive to capitalization than the Windows version. I had to be careful with the file names assigned to images.
Twenty years later I find it astounding to report that I completed all of this within a few months. To each member of the tour group I sent an email that invited them to view the finished product on Wavada.org. Quite a few of them looked at a good portion of the journal and responded that they really liked it.
Other projects: I needed to design a home page. I knew that I wanted to have a huge wave as the background so that people would know how to pronounce the name Wavada. I found a photo of with very high density that depicted a monstrous wave better than I could have even imagined. It was on the Internet, but I don’t remember the location.
iPower offered an incredible array of free features that were associated with the website. The two that I made the heaviest use of were email and WordPress. I only needed to create three or four email accounts, but I made good use of them. I made Mike@Wavada.org my primary email account. Much later I created another account called Yoga (the name of my laptop at the time). Email sent to the Mike account was automatically downloaded to Outlook on my desktop. The Yoga account was not. So, I could send or forward emails from Mike to Yoga for activities (such as ZOOM meetings) that required the laptop.
I also set up an account for Sue, but I don’t think that she ever used it.
The other free feature that I employed a lot was WordPress, the software that I used to make this and hundreds of other blog entries. The oldest object in the WordPress section of Wavada.org is from 2010. However, I don’t think that I made much use of the product until March of 2012. That is the date of the oldest images that I uploaded. I might have written a few earlier blog entries that contained no images. An incredible number of these images—and a few other files—were uploaded during the pandemic and the subsequent months.
At first the home page for Wavada.org simply contained links to the few items that I wanted to allow the public to see. I changed the format dramatically when I discovered a widget that was available in google’s jQuery library. This allowed me to present the table of contents in an attractive tabbed manner.
I wrote a large number of programs concerning the game of bridge (introduced here) for my own use. For a while I maintained a complicated set of programs that I wrote to keep a detailed record of the bidding agreements with my partners. Eventually I decided that this was too much work (as of 2023 I had played with 141 different partners). I also created online programs for displaying an article index for topics covered in the Bridge Bulletin (posted here) and for providing game plans for challenging declarer problems (posted here).
I figured out how to parse the pdf files for hand records from bridge games. I created a database of these hands so that I could establish probabilities to associate with certain bridge situations. For example, I determined that Losing Trick Count4 was more accurate at predicting the number of available tricks at game level or lower than point count that has been modified as suggested by Marty Bergen in his Slam Bidding Made Easier book. However, the opposite was true for higher contracts.
I started to attend Wednesday evening games at the Simsbury Bridge Club in 2004. At some point I created a webpage for the club. It was still in use in 2023. The link is here.
As an adjunct to my job as webmaster I created a database of bridge players throughout North America on Wavada.org for District 25 of the American Contract Bridge League (ACBL). That story has been chronicled here.
I adapted the code for the travel journals to create online pages for each chapter of the book that I wrote on papal history entitled Stupid Pope Tricks. The book is posted here. The story of the Papacy Project that led to its creation is chronicled here. I also posted in the same format Ben 9, my historical first-person novel about Pope Benedict IX, here.
1. In 2023 this product is still offered for the i5 operating system. Zend has been purchased by other companies a few times.
3. I used the same file names that Cascio provided with the letter b at the end. For later journals I dispensed with the uploading of the smaller versions of the photos and instead uploaded a full-page version of each image and used HTML to specify the size displayed in the journal. I also changed the naming of the images in the daily folder to be meaningful.
4. Losing Trick Count is explained here and elsewhere on the Internet and in print.
Dick’s Sporting Goods is as old as I am. It started as small store in Binghamton, NY, that sold fishing equipment. In 1994 it was moved to the Pittsburgh area. In 2022 it had over 850 stores with over 50,000 employees.
TSI and Dick’s had a very long courtship. I am sure that I made several trips to Dick’s before we signed the contract. The first time that I visited the company it was still in its previous building, which was much smaller than the complex that it constructed in Coraopolis, PA.
We never gave up on selling them a system even though many of AdDept’s features would never be of much use to them. I knew that Dick’s IT department was committed to the AS/400 architecture. Therefore, the cost to them would not include the cost of additional hardware, which was often a deal-breaker.
I remember one sales trip in which I was asked to talk about the way that our system handled co-op—ads that feature a single vendor who has agreed to pay a portion of the expenses. I was pretty sure that no one would buy the AdDept system just to handle co-op, but I always tried to do what they asked. I have read through pages and pages of notes about the project of installing AdDept at Dick’s, but I found no subsequent mention of co-op
TSI and Dick’s formally tied the knot in a contract dated March 4, 2003. It was signed by Eileen Gabriel1, who was Dick’s CIO at the time and me. I still have a pdf file of the document. Most of our contracts were far simpler than this one. Their lawyers obviously added quite a bit of language to the one that we submitted. Neither side ever had any difficulty about it during the more than eleven years that it was in force.
At the time that we negotiated the contract I did not understand (or, for that matter have much interest in) why Dick’s, which up until 2003 had always been in the “kicking the tires” column of prospective AdDept users, suddenly was rarin’ to go. I subsequently discovered two factors that probably contributed to the change in attitude: 1) The company went public in 2002. That probably provided a good deal of cash. 2) By then the advertising department had hired several employees who were familiar with what TSI and AdDept could accomplish2. There probably were other favorable conditions that were not evident to me.
Planning for the AdDept system: Dick’s already had several large AS/400’s that were used for other aspects of its business. On one of them were PeopleSoft3 applications designed for the accounting and human resources departments. One of TSI’s major challenges would be to implement an interface between AdDept and PeopleSoft’s A/P and G/L systems. When employees in the advertising department entered expense invoices into the AdDept system they would automatically be sent to the PeopleSoft system for payment and posting to the General Ledger.
Paul Marshalek
Krista Gianantonio
Adam Sembrat
I found a document created by Paul Marshalek4, the first project manager for the AdDept installation. It provided the agenda for a one-day “discovery session” that was held in the Final Four room on April 16, 2004, almost exactly one year after the contract was signed. The scheduled attendees were Krista Fullen5 and Adam Sembrat6 from advertising, Don Steward7 from IT, Joe Oliver8 and Jeff Jones9 from finance, Paul, and myself.
Don Steward
Joe Oliver
Jeff Jones
The agenda includes a dozen items. During my preparation for this entry one caught my attention. I remember spending a lot of time at Dick’s on various aspects of print media from insertion orders (sent via AxN10 from the beginning) to payment of bills to allocation of costs to stores. I did not remember much about broadcast. At the time they used an advertising agency called Empower MediaMarketing11 based in Cincinnati. I could not find any evidence that we ever implemented an interface by which the buys from the agency were uploaded to AdDept. TSI provided this for most AdDept users, but it usually required custom programming or at least some fine-tuning.
Getting the AdDept system operational: It was made very clear to me that TSI’s client was the IT department, and the people in advertising and accounting were the IT department’s clients. So, the IT department made all the calls in this installation. In some ways this made things more difficult for me. I was never sure whether the advertising department was satisfied with our progress. On the other hand, we heard very few complaints, probably because everything that the advertising department really wanted was installed in phase 1, as described below.
Aeolus, god of testing.
Dick’s insisted on having two separate AdDept environments, one for testing of new code and one for production. Both of them were named after Greek gods of wind. Aeolus, the developmental system, was named after the keeper of the winds. Boreas, the production system was named after the personification of the north wind. TSI employees had no credentials for signing on to Boreas and no way to reach it from our office in East Windsor.
Aeolus and Boreas actually resided on the same AS/400, but they were in different partitions designed to make accidental intermixing of the two environments impossible. If separate boxes had been purchased, separate licensing agreements would be required for the operating system and IBM system-level programs. This would have made the installation of upgrades a much more difficult and time-consuming process for the IT department.
This installation involved a large number of interfaces and a great deal of custom programming. When we delivered a new batch of program changes—both routine updates and code specifically for Dick’s—we had to install the new code in Aeolus, implement the required changes to the database, and test them there. Advertising employees would then be required to sign on to Aeolus and make sure that both the new and previously installed AdDept programs worked. If the changes were not ones that they requested, it was difficult to get them to take this seriously.
During the testing and approval period a process that “refreshed” the AdDept system in Aeolus with the programs and data from Boreas needed to be suspended. If the timing of the suspension was not perfect, then all of the changes that we had installed during that period could be wiped out. A few times this happened to us, and it was quite upsetting.
Boreas.
When all of the advertising department asserted that the changes were good to go, the Aeolus system was refreshed, and TSI needed to install the changes again. The people in advertising would spot check what we had done. During this second period the AdDept system on Boreas was frozen. When the advertising people validated the changes, the Boreas system was refreshed with the new code and the transformed data on Aeolus. Only at that point could work resume. The primary purpose of all this was, I suspect, to eliminate the possibility that IT people might be blamed for deleterious outcomes.
This approach was much less efficient than our usual method of delivering code. I routinely installed new code to four or five other AdDept installations every weekend. Most of the time the users did not even know that I had done anything. There were occasional problems, but never anything that we could not address in an hour or so.
I don’t blame Dick’s for insisting that we follow their protocols, but we had had great success at over thirty installations with the approach that we had developed, and we would never have been able accomplish so much if we had been tied to Dick’s approach in all of them.
Inevitably, despite all of the precautions, some bugs slipped through the testing process—both TSI’s and the advertising department’s. Dick’s had a method that allowed us to make emergency changes to address them, but I don’t remember the details of how it worked. We only needed it once or twice.
If there was a problem or a request for new code, the users had to go through the IT department. The people who served as TSI’s primary point of contact—the liaisons—were people who worked in the IT department as project managers.
Perhaps the biggest problem with the enforced separation of the users from the developers was that Dick’s insisted that I do all the training after the initial installation in one of their training rooms. I did not like this at all. Often the people who showed up at these training classes were not the people who would be using the programs that we were installing. Sometimes I did not know what roles were played by some of the people. I did the best that I could under the circumstances.
At other installations—even the ones with AS/400s owned and operated by the IT department—I was allowed direct access to the users. I had a thorough understanding of the administration of retail advertising, a claim that could be made by none of our liaisons. Many times I could address their issues on the spot and direct them to programs or techniques that they were previously unfamiliar with.
I am certain that the installation would have proceeded more rapidly and with fewer problems if the IT people had allowed us to use our time-tested methods, but the idea was absolutely anathema to them. The IT department owned the AS/400’s, and they insisted upon their right of ownership. Bypassing this interference from the IT department was the primary reason that we always preferred for the advertising departments to have their own smaller systems that could eventually communicate with the systems running the other aspects of the business.
Our main contact at Dick’s during the installation and for some time afterwards was John Nelko12, an IT employee whose specialty was the workings of the AS/400’s operating system, OS/400. Under his supervision I installed AdDept on Aeolus and built all the files that they would need to use. I also installed IBM’s BASIC compiler and interpreter. That product was no longer supported by IBM, but TSI was authorized to sell and install it. Most of the other IBM software—SQL, query, FTP, faxing, etc.—that would be needed was already on the box.
On that very first day John and I got the faxing to work. I also was able to send an insertion order through AxN to TSI’s server. That required that FTP over the Internet was working. It also required that Dick’s be set up on TSI’s system as a valid sender.
TSI was assigned a user ID on Aeolus called TSIDICKS. I was told that the password was set to expire every sixty days. John worked with Denise Bessette in our office to get the SDLC communication working over the telephone lines. In the beginning that was how we accessed the system from TSI’s office.
There was a little time left over in that first visit for extensive training. My notes reported:
We got through the season table, expense classes, ad types, markets, pubs, rates, and print rates in the first training session. Everyone seemed comfortable with everything. In the second training class we went through the more difficult tables pretty thoroughly and entered a couple of ads.
The pub-store master table for inserts was not set up correctly by the program which13 I wrote to create the table. I fixed it. I used the Saks programs as the basis for DM220RDX and DM230RDX. Adam wants to show the costs on insertion orders. Most of the programs do not do this. I added a column for the Skid Color to the insertion order. I did this all during a long meeting which everyone in advertising attended on Wednesday afternoon.
I remember that the names of the insertion order programs for ROP and inserts began with DM220 and DM230 respectively. The “Skid Color” refers to the color of the tag that was attached to a “skid” (a pallet with no bottom deckboards) on which the inserts were stacked and packaged for delivery. Each version of an insert was assigned a different color.
These were my last few comments on that momentous trip:
Amanda Sembrat, then known as Amanda Greener.
We had a good luncheon meeting about the rest of the project. Steve Manning, the Budgeting Director, attended. They are considering whether to use AdDept to create real purchase orders for all advertising expenses.
I almost made the mistake of going to a Mexican restaurant on Cinco di Mayo.
I showed Krista how to respond to errors. At this point both Adam and Amanda were involved in other things.
I think that Adam overstepped his authority last time when he decreed that we did not need the broadcast interface. Helen said that we may need to revisit this. We had better be careful with Adam. He sounds like he has more authority than he really does.
Request #1 was approved.
They certainly want me to return for the first insertion order run. They may want me sooner than that.
The fact that Dick’s ran so many inserts in so many markets caused some unique challenges that were also mentioned in the notes:
Adam says that about 15 papers have separate rates for flexis, which are also called minis. We need to come up with some way of handling this.
Most of their events start on Sunday. If the paper does not publish on Sunday, they want it to default to Saturday, Monday, Friday (before), Tuesday, Wednesday, and Thursday (after) in that order. I set things up to work this way, I think, but I was not able to test every possibility. For Thursday drops, they want it to default to Wednesday, Friday, Saturday.
They want to use the holiday quantities for Thanksgiving. Is there a good way to do this?
They have some “events” which involve sponsorships with sports teams. The costs are spread over several months. I am thinking that we might use Stage’s amortizing programs for this.
The second trip June 14, 2004: Dick’s was one of the few clients for which a one-day trip was at least somewhat reasonable. USAir had many direct flights between Bradley and Pittsburgh. Because Dick’s was so close to the airport, I could easily get to the office at the same time as the employees.
I did encounter one major problem: I discovered that it was not trivially easy to meet with people in the advertising department.
I got there about 9 a.m., but I had to wait about 30 minutes as they tried to figure out what to do with me. Advertising is in the new building, but the reception desk is in the old building. Eventually they managed to contact Adam, and he showed me into the building.
Here is what happened once I got to the advertising area:
I spent most of the morning making sure that all papers were correctly designated as F for faxing or T for AxN. I called Lucia15 to make sure that we were in agreement concerning every paper.
I met with Adam, Helen, Paul, and Steve about where we stand and what is on the agenda. Steve said that they need to keep track of actuals versus budgets. It took me a while to figure out that he means by category on each book. Right before he left he gave me a list of the categories which they currently use. They also decided that advertising should meet with Jane Walker and the accounting people to make sure that everyone is on the same page.
I helped Adam set up a pub group for all of his insert papers. He also needs one of his main papers. I think that he now knows how to do this.
We put on an ad and printed insertion orders. Adam noticed that only the first 12 characters of the fax number appeared. I fixed this.
The sequence number for the NJS market was incorrect. Adam fixed it.
We discovered that there were no rates for 6-page tabs. They sometimes run 12-page minis (same as flexis) which ordinarily use these rates. I wrote a little program to help Adam key these rates in fast.
I was able to establish an FTP session on TSI270.
Amanda16, who is engaged to Adam, said that she had looked over the quote for the run list. It looked good to her. They would like to have it by 6/28, although, of course, they have not approved it yet.
They were unable to print. The printer which they formerly used is no longer near them. I called John Nelko. He eventually identified the printer. I need to send him a memo telling him which user profiles need to be changed to use the new printer, which is called Ad_Dept.
I think that DM022 should use the text description from the book size file rather than the dimensions for the size on screen #M22A.
We could not fax because the modem was not available. I will send an e-mail to John to try to reserve the modem one day this week. Adam wanted to wait until Friday, but I told him that I would be out of town on Friday.
The rest of the story: An AdDept Progress Report dated October 15, 2004, and prepared by (I think) Paul Marshalek identified phase 1 of the installation as “print media”, which for Dick’s was primarily in the form of newspaper inserts. Phase 2 was much more detailed. It had the following sections:
Pub-store allocations, which included implementation of an interface with the system that Dick’s used for sales analysis.
Other media: broadcast, magazines, and billboards (which everyone in advertising called “outdoor” even if the signs were in a building).
Another interface to “refresh” AdDept’s vendor table so that its data was consistent with PeopleSoft’s.
Expense invoices, which in AdDept were divided into media (which were entered against the schedule) and non-media (which were entered by job categories or sub-accounts). This project included the expense payables interface.
Media accruals that created the journal entry for the G/L in PeopleSoft. The document notes that the file containing the journal entry for August 2004 was delivered to Jane Walker14 in the IT department.
Cost accounting, which in their case meant advertising costs (including overhead) in all media per store.
Non-media closing, which included accruals from purchase orders and prepaids.
This list, which resulted from the four-day trip that I made in October of 2004, included some really big programming jobs, but I am pretty sure that they were all eventually implemented.
I met several new people on that trip:
Carol Mazza was a media manager who worked for Helen Burkholder. Krista and Erika Crawford worked for her.
Linda Weiss was tasked with entering broadcast invoices. She reported to Steve Manning.
Dave Derry was an internal auditor.
Todd Schultz worked in Expense Payables.
Jeff March, who worked at Galyans, a company that Dick’s had recently acquired, was scheduled to start work the next Monday as broadcast manager.
Rick Kohout provided me with files that I used to implement the sales interface.17
Krista at her desk.
Most of my time on the October 2004 visit was spent with Krista. I checked over what she had done for ROP and inserts and helped her set up other types of ads. At the time Dick’s was rapidly expanding. New stores were provided with pre-opening and grand opening advertising support. These ads had their own separate G/L accounts, and we had to devise a way of handling them.
My next trip was in April of 2005. I gave a talk to eleven people to explain how AdDept does accounting. The tone of my notes indicates my frustration. Accounting for advertising is complicated. I could not explain it very well in a few minutes in a classroom setting.
I learned that Jeff Jones accrued to plan. Here is what I reported about the reconciliation process:
Jeff explained that he made his “accrual entry.” He actually closes to plan. He takes the planned expenses, subtracts out the invoices paid, and spreads the difference to markets in a spreadsheet.
We got the February accrual to match. This is not really much of an accomplishment. We just matched one AdDept report to another after eliminating all possible sources of error. We got the March accrual to match within .5%. We ran the report by ad so that Jeff could compare it with the list which he used for his accrual.
Accrual to plan is a bogus concept. The whole idea of accruing is to make the expenses and income occur in the appropriate month so that one can isolate problem areas as soon as they develop. Accruing to plan disguises difficulties because the actuals are forced to match budgets. However, it was not my job to explain this.
I came up with a list of eleven things that needed to be changed in the production system. At other installations I would have just fixed them myself, but I was not allowed to touch anything. Denise and I had to come up with ways to circumvent this restriction in each case.
I also listed six or seven small changes that they requested.
I returned to Dick’s on May 31 for one day to look at their pub-store allocation records. I discovered that because someone skipped the step of creating these records, the allocations of costs to stores for 2005 have all been wrong.
I also helped them address the issue of paying bills for ads that ran in 2004. I came up with a Mickey Mouse method that at least got the accounting right at the G/L level.
The notes from my only visit in 2006 are very sketchy. There were a couple of new people whom I do not remember, and someone in advertising asked us to quote a massive database of zip codes to help with ordering insert distributions. Some—but by no means all—newspapers allow specifications of zip codes for insert distribution. Both AdDept and AxN handled this by special instructions.
I remember quoting creating this database, but I don’t think that we ever did it. The notes make no mention of any other media or any accounting issues.
Bob Pecina.
I made one four-day visit in 2007. I met a lot of new people. Included in that group were Carl Abel and Bob Pecina,18 who would be our primary contact for the rest of our relationship.
Among other things I learned that the advertising department had begun using AdDept for billboards and magazines.
They expressed considerable interest in copying all ads from one year to another for planning purposes. This was an important but very complicated task for any retailer. TSI had software to do this. If everything was set up perfectly, or at least nearly so, it could save a lot of time and make for more accurate planning. If anything important about the process was ignored, it could make a gigantic mess.
I knew that it would be a nightmare at Dick’s for more reasons than I could name. I am pretty sure that nothing ever came of this.
I learned that their change reports were essentially useless because they included ads that were created in order to estimate costs under a specific scenario and then deleted. There were a lot of these ads. I think that we put in a Y/N field on the selection screens for change reports to allow them to be excluded.
The last major project that we did for Dicks was to create a separate installation for Golf Galaxy, a retail chain that Dick’s had acquired in 2006. The administrative functions were not moved to Coraopolis until 2008. I decided to create a separate blog entry for the Golf Galaxy project. It can be viewed here.
Mike Krall.
When reading my notes for the two trips that I took in 2008 I discovered that I also spent time with Mike Krall19, a young guy who had been assigned the daunting task of managing the “cost accounting” programs that showed in summary and in detail how expenses were attributable to stores using rules that Dick’s created. The reports depended upon all aspects of the data—media and production costs, sales, store allocations, etc.—being accurate.
Here are some of the notes from the time that I spent with him:
I spent most of the day on Wednesday with Mike Krall. He runs the month end programs in AdDept, but he did not really know what he was doing. He had a detailed set of instructions to follow.
I made some queries in ADVMOQRY for Mike Krall to provide him with net indirect expense (INDNETEXP) and net production expenses for ads in prior months (PRIORMOEXP). I explained that these would only get the data from Dicks. If he wants Golf Galaxy, he should make copies and change the libraries from TSIDATA to TSIDATAG.
Does DX112 expense the indirects? Mike Krall said that he does not create a journal entry for indirects.
The white areas are buildings. The main entrance was in the middle of the top set. The bottom building and most of the parking (grey) areas did not exist when I visited last.
The atmosphere at Dick’s headquarters: Working at Dick’s was unlike anything that I experienced at any other retailer. For the most part the administrative departments of the department store chains that dominated the list of AdDept clients were located on the highest floors of large downtown stores. The ambience in the lower floors was designed to generate excitement. The upper floors were at best boring and sometimes even dingy. Even the offices of retailers that housed their administrative functions elsewhere were mundane.
The gigantic lobby at Dick’s headquarters.
Arrival at Dick’s was not an overwhelmingly pleasant experience. Despite the massive size of the complex—and it is much larger in 2022 than it was in my last visit of 2008—the offices in Coraopolis were not trivially easy to find within the industrial park. The parking was not a bit convenient. In those days there was only one lot, and by the time that I arrived with my rental car only spots that were a long way from the main entrance were available.
I don’t think that I was ever in this room.
From the front door one entered a huge waiting area. No one without an employee badge could get past it without being escorted. My memory may be faulty, but I don’t recall that they ever gave me a temporary badge.
Incidentally, it would not have been a good idea to arrive early to try to claim a better parking space. I would not have been allowed past the lobby until the person or people with whom I was meeting were there.
The cafeteria.
Surrounding the lobby were eight or ten conference rooms. Each was named after famous sporting events—Super Bowl, the Masters, World Series, etc. They were extremely elegant. A few of our early meetings were held in one of them.
Dick’s also had a very nice cafeteria, which was called the Court Street Café. I am pretty sure that I ate there every day—except the time that lunch was delivered to our meeting—on every visit. It’s a good thing, too. There were no restaurant in or near the industrial park in which the headquarters resided.
I remember feeling quite short on one of my first visits there. I was at least six feet tall, but almost everyone I met was quite a bit taller. Later I heard about a volleyball tournament held somewhere inside the facility during the lunch break or maybe right after work. They already had an indoor basketball court when I visited. Now they have that (with a track around it), tennis courts, and a huge workout room.
The Dick’s store at State Line Plaza.
Epilogue: Alone among TSI’s clients, Dick’s still seemed to be thriving in 2022. They even have a store in Enfield next to Costco. A very large percentage of the people with whom I worked in the early twenty-first centuries are still employed there in Coraopolis.
A decision made by Dick’s in late 2013 was the cause of the decision to close down TSI. At the time the income from maintenance fees was not enough to keep the company running. The income from custom programming had also dwindled, and there were no real prospects for sales of new AdDept systems.
We therefore depended on the steady stream of checks from the newspapers that subscribed to the AxN service. Because several of our other largest AxN users had outsourced the buying of their newspaper space to third parties, Dick’s many newspapers accounted for a large percentage of the remaining income. I knew immediately that the decision by Dick’s management to let an advertising agency order its newspaper space was the death knell for TSI. The details are described here.
The people at Dick’s were quite surprised by TSI’s decision. Someone called us and told us that they still wanted to use AdDept. They evidently thought that we had misinterpreted their communication about the agency. We had to explain that the AxN contracts generated a considerable amount of income for us.
Denise Bessette may have made a private arrangement to provide some support for the AdDept system at Dick’s. I was 65 years old when we made the decision to close, and I was not interested in such a venture.
1. I am not sure that I ever met Eileen. If I did, I don’t remember the occasion. Her LinkedIn page is here.
Helen Burkholder.
2. Two people who may have played significant roles behind the scene were Helen Burkholder, an executive in Dick’s advertising department, and Bill Dandy, her boss. I did not spend a lot of time with either of them in this installation, but they were both certainly influential.
I had worked closely with Helen when she was a media manager at Kaufmann’s. The blog entry about the Kaufmann’s installation is posted here. I am not sure what Bill Dandy’s title was. I met him when he took over that job at Michael’s in Irving, TX. That very profitable installation has been chronicled here. Helen’s LinkedIn page is here. Bill’s can be viewed here.
3. In December 2014 PeopleSoft was acquired by Oracle. I am not sure what effect this had on Dick’s. It did not seem to affect the design of the interface.
4. Paul worked in the IT department, not advertising. His LinkedIn page can be viewed here.
5. Krista Gianantonio (née Fullen) was our day-to-day contact in advertising. Her LinkedIn page is here. She was familiar with AdDept and TSI from her previous jobs at Hecht’s (described here) and Kaufmann’s (described here).
6. Adam Sembrat’s LinkedIn page can be found here.
7. I don’t remember Don Steward at all. I don’t think that we had any subsequent dealings with him. He might have been Paul’s boss. His LinkedIn page is here.
8. I don’t remember Joe Oliver. His LinkedIn page is here.
9. Jeff Jones actually worked with the financial side of AdDept. His LinkedIn page is here.
10. Dick’s had stores all over the country, and they advertised in hundreds of newspapers. The fact that the advertising department was excited about electronic delivery of insertion orders gave a big boost to TSI’s efforts to expand the use of the AxN product.
11. In 2022 the company is just called Empower. Its Wikipedia page can be found here.
13. When researching the notes I definitely realized that I had not yet learned when to use “that” and when to use “which”. This “which” should be a “that”. So should the “which” in the last sentence.
14. Like many of the other people listed in this entry Jane Walker is still employed at Dick’s in 2022. Her LinkedIn page is here.
15. Lucia Hagan was the administrative person at TSI during this period. Her history at TSI is described here.
16. My notes say that Amanda Greener was not actually employed by Dick’s; she actually worked for Dick’s printer. She evidently married Adam. Her LinkedIn page is here.
17. I have only the vaguest recollections of any of these people, but I found LinkedIn pages for several of them: Carol Mazza’s is here. Todd Schultz’s is here. Jeff March’s is here. Rick Kohout’s is here.
In large measure this entry is based on and inspired by a set of recently discovered messages that I sent to my partner, Denise Bessette, about new projects that we were researching or working on. The first email was dated in late 1999. The last was in early 2001. The messages portrayed an exciting but scary time for both of us.
By the middle of the nineties it was evident to us that the way that TSI had been programming in the past fifteen years was becoming obsolete or was at least losing popularity. In 1992 Microsoft left IBM at the starting gate when it released Windows 3.1, the first version of its operating system that featured a graphical user interface (GUI) and was also stable enough that large corporations took it seriously. One could still make the argument that text-based software systems like the ones that we had developed were appropriate for many business tasks—in fact, most of the most important ones. However, if you did, you were probably dooming yourself to the fate of typewriter salesmen.
Great if you have just 2 fingers.
In fact, systems like AdDept and TSI’s other systems were branded by many of the magazines of the day as “legacy systems”. The emphasis of the new approach centered around the appearance of the screens, which now featured colors, images, text boxes, radio buttons, and varied fonts. They were certainly more interesting to look at than anything that we had produced. The mouse was the thing! The keyboard was only used when absolutely necessary. Whether they were as efficient or as easy to use was debatable, but, as I already noted, we were well aware of what had happened to the typewriter salesmen.
Another thing that happened during the middle of the nineties was the explosive growth of the Internet. All software developers wanted to be a part of it, but few were exactly sure how to approach it. I knew that we needed to figure out what aspect we should concentrate on, but it was not an easy decision to make. A few early participants made a lot of money, but an awful lot of ideas were catastrophic failures.
The Search for a GUI: I spent countless hours researching ways that we could provide a GUI for the AdDept system that did not involve a complete rewriting of the hundreds (and growing daily) of screens that we had already implemented. Every developer who worked on IBM midrange or mainframe systems must have been faced with the same problem. We all wanted a way to provide a system that looked modern but also took advantage of the thousands of lines of functioning code that had already been written.
I don’t know why, but IBM was not much help in this endeavor. Instead, in the late nineties IBM became a strong proponent of an object-oriented programming language developed by Sun Microsystems called Java. This was a startlingly new language. The first version was released in 1996.
I bought and read ten separate books that purported to teach Java programming. The structure of the language was consistent with the first principle of its design: “It must be simple, object-oriented, and familiar.” Well at least it was simple and object-oriented. The structure of the code was nothing like what I was accustomed to. Its main orientation was to a computer display, which it considered a set of objects, each with a set of properties and methods. That approached worked well enough for a screen, but how would it work for other things? After downloading the software development kit to my laptop and spending hundreds of hours mulling the contents of those books, I could do all of the exercises in every book, but I had not the slightest clue how to begin to code a system to manage any aspect of retail advertising. In fact I could not replicate even one screen of the AdDept system.
I did not completely discard the notion of using Java somehow, but if we did, we would definitely need some help. As I look back on this, maybe this is the reason why IBM was so crazy for Java.
The Spreadout Project: Users of TSI’s systems seldom complained about the look or feel of our data entry screens. Those screens would never have won any design awards, but the formats were completely consistent throughout the application, and everyone knew that they got the job done efficiently. Furthermore, they knew that TSI could implement requested changes rapidly and at moderate costs.
What they did not like much was the look of the reports, which was limited to one non-proportional font—Courier—with no images or even styles like italics or bolding. Many, if not most, of the people who used AdDept were quite good at making and manipulating spreadsheets. They were used to controlling the format of the output, and they liked the flexibility. For example, if they wanted someone to concentrate on one column or row, they could easily change the font, color, or style for just those cells.
Several clients asked us if it would be possible for us to produce an Excel spreadsheet as the output from designated programs in AdDept instead of or in addition to printed reports. I did not know if it would be possible, but I said that I would look into it. I dubbed this project “Spreadout”.
It was rather easy to produce an output file that contained the same rows and columns as the report, and we implemented that option in a large number of AdDept reports. The user could then download that file to their PC. That file could then be loaded into Excel with the rows and columns intact. However, the fields (or cells) in the file contained only text or numbers. It was not possible to download formulas for totaling or designate any kind of formatting. Furthermore, the process of downloading the file was not exactly speedy.
I tried to figure out what it would take to produce code that could provide files that could be opened in Excel with predetermined formulas and formatting. I found some documentation from Microsoft of the Excel files, but I never could concoct a way to provide what our customers asked for. Furthermore I never heard of anyone else who had accomplished this, and —believe me—I searched..
I did, however, managed to provide an alternative that proved popular to some clients. Almost all the AdDept customers used Hewlett-Packard printers that were accessible by the AS/400. HP sold books that documented the format for files in HP’s printer command languages, PCL 4, PCL 5, and PCL 6. I could then write code to produce spooled files that contained the output in exactly the format that the client specified. The downside was the considerable amount of coding required for each report, many times as much as it took to produce it in the Courier-only. It also required an extra step to send the output directly to the printer without being reformatted.
However, a few clients were so insistent about the need for a precise format that they were willing to pay the price. These reports were almost always the ones that they distributed to other departments or to higher-ups.
If anyone else ever did a project like this for the AS/400, I never heard of it. Unfortunately, I never figured out how it could be marketed as a stand-alone product usable with other AS/400 software.
As the new millennium approached, we—that is, Denise Bessette and I—felt that we needed to expand TSI’s horizons. In January of 2000 we flew to San Diego for IBM’s PartnerWorld conference in the hope of making contact with people who could advise us how to adapt to the need for modernization and the Internet. That enjoyable but frustrating experience has been described here.
On February 25, 2000, I took the time to write up in a fairly detailed manner how, given the inherent limitations of a small business like ours, TSI should to proceed in trying to develop a second line of business. Here is a portion of that memo:
General principles:
1. We should get the best people available to help us.
2. We should maintain AdDept as a dependable source of income. Whether we should invest a lot of time and/or money in enhancing and marketing AdDept is still to be determined.
3. We should try to leverage our assets better. Our income is too heavily dependent upon the number of hours put in by Mike and Denise.
4. We should assume that the economy will remain strong for another two years. On the other hand, we should avoid debt or at least large amounts of debt in case this assumption turns out to be false.
5. We should add new skills that are more marketable. That means learning some subset of Windows, object-oriented programming, and the internet. We should be thinking past the next project to the one after that if we can.
6. We should look for partners with skills and assets that complement ours.
7. We should not be deterred by the fact that some of these principles seem incompatible.
8. We need to act fast. Pursuing René2 cost us seven months. On the other hand we might have gone down some less profitable paths if she had been on board.
I think we should take the following steps as soon as possible.
1. Find out what it takes to get our existing clients to use AdDept for insertion orders. The following clients are not using AdDept for IO’s: Macy’s East, Neiman Marcus, Filene’s, Saks Fifth Avenue, and Hecht’s. I checked Herberger’s. They have ads through March 29, 2000, at least. Macy’s West is apparently starting. Gottschalks ran insertion orders yesterday. I don’t know about Meier & Frank, but I can take care of that on my trip.
2. Find out which advertising departments have access to the internet and would be willing to use it to check on insertion orders. I don’t think that this would be a problem with most of them. Unfortunately, we don’t really have anyone in the office who can do this for us.
3. Make an appointment with Ken Owen3 to run the idea of a clearinghouse for insertion orders by him. He may be very interested in working with us on it. I have quite a bit of respect for him. At the very least, he is smart and completely honest.
4. Run the clearinghouse idea by at least one of our clients. Why not schedule our trip to New York and run it by Tom, Chris, and whoever their ROP person is?4
5. Run the clearinghouse idea by at least one newspaper or someone who knows how newspapers think about these things today.
6. Start trying to package and market AdDept and/or AS/400 products and services. We need to maintain or enhance our cash position over the next six months.
7. We should find out what, if anything, the National Newspaper Association (NNA)5, the AAAA6, and AP AdSEND have done in this regard. The AP is a potential partner in this venture. I once had a copy of the NNA’s EDI spec7, but I seem to have thrown it out when we moved. I will see what I can find on the Internet.
Requirements for hiring a marketing/client services person:
1. He/she must be able to get along with Mike and Denise. This includes having a good work ethic. I think Doug barely met these qualifications.
2. Must be able to get along with the clients.
3. Must be willing to spend a lot of time on the phone.
4. Must be able to talk to decision-makers and occasionally presidents of corporations without looking foolish. Doug could do this, but his ability to identify the real decision-maker was just so-so. He was also almost always overly optimistic, but this might be necessary to offset my tendency to see the negative side of everything.
5. Must be able to refrain from overselling.
Pluses:
1. Intelligence. Determination can go a long way to overcome deficiencies in this categories, but I don’t think I want to try to explain things to someone any duller than Doug.
2. Retail experience.
3. Newspaper experience.
4. Other advertising experience.
5. Good business sense.
6. Sales experience.
7. Computer experience.
How to proceed.
1. We can run an ad in the Courant. There are almost as many classified ads for sales and marketing people there as for programmers. The only major retailer in the immediate area now is Ames, and they run no ROP. Therefore the chances of finding someone in Hartford who understands retail advertising are slim.
2. We can contact a headhunter. We don’t have to pay unless we find someone, but we will have to pay plenty if we do. It might be worth it if it speeds up the process.
3. We can advertise on the Internet. Does that cost money? If so, how much?
4. In interviews I think that we should consider dangling a carrot of a spinoff of a .com company for the insertion order clearinghouse. I am not exactly sure how to present this idea to someone. Maybe we could offer them a percentage of the new company with the understanding that we would try to sell it once it has become established.
In retrospective I find it impressive that I was able to earmark in advance so many important issues that TSI would face over the next few years. We made some mistakes, but we made a lot of good decisions.
A month later, on March 25, 2000, I mailed a letter to our contacts at all of the companies that used AdDept. I solicited their opinions on what TSI’s priorities should be in the new millennium. Here is a copy:
TSI is in the process of evaluating how best to allocate its resources over the course of the next year or so. Our highest priorities will remain providing excellent support for existing installations and responding to requests for custom programming from existing clients. However, there are a few additional projects that we are considering. We are very interested in learning what our existing clients think about them.
1. Menu maker: This is a fairly simple idea both in concept and in implementation. You would be provided with either a PC/Mac program or an AS/400 program that would allow you to create your own menus. The menus would reside in a separate library so that they would never get mixed up with the standard AdDept menus. You would provide the name for the menu and the heading text. For each option you that want to add, you would be allowed to select from a list of AdDept programs and menus. You could also enter your own command or an IBM command (e.g., WRKQRY). If you selected an AdDept menu or program, the description and the online help would be filled in for you, but you could override the text to make it say what you wanted.
2. GUI front end: Most software companies that market systems of a size comparable to AdDept have budgeted more than $1 million to “modernizing” their data entry screens to use a “graphical user interface” that is consistent with the methods used by Windows and Mac programs. It is now technically feasible to create a fairly nice GUI front end for AdDept for much less than that using products available from third party vendors. However, there is still a considerable capital outlay involved. We also estimate that it would take at least half of a man-year of labor. Furthermore, the PC or Mac would have to meet certain minimum requirements. Terminals would still use the green screens. TSI’s support regimen would be more difficult. The interactive programs would probably run slower on older AS/400’s. They may actually run faster on newer boxes.
3. Output to Excel: We believe that it is technically feasible (albeit difficult) to create a file from the AS/400 that is usable by Microsoft Excel with no intervening steps. It is a relatively straightforward task to download data files (or even spooled files) to spreadsheets today, but many intervening steps are required to get something presentable. TSI’s proposed method would allow you for each report that is eligible for this kind of treatment to designate (and permanently store) the formatting of the worksheet—report titles, column headings, “fit to page”, and most of the other values in “File, Page Setup.” You would also be allowed to designate fonts and sizes for the report title, the column headings, the body text, and each level of subtotals. The subtotal values would be formulas, not simple values. The same program could be used for data files that are produced by queries. The resulting worksheet could then be edited as needed. You can even edit, add, or delete lines in the worksheet. The subtotals will automatically be updated. Most simple reports could be reformatted to use the proposed program. It might be difficult or even impossible to generate some complex AdDept output using this approach.
4. Insertion order clearinghouse: We have long thought that the methods used for reserving newspaper space leave too much room for error and are overly labor-intensive, both for the advertiser and for the newspaper. The purpose of this project is to make the ordering process easier and to minimize the potential for miscommunication.
Instead of faxing the orders, the AS/400 would send them electronically to TSI. We would post them on a website. When the newspaper reps sign on, they would see all orders for them from all advertisers who are using this service. They would be able to add comments or questions and confirm them electronically with or without reservation numbers. They could also print the orders and, eventually, download them directly into their reservation systems. When you sign on, you would see all of your orders. It will be immediately obvious which ones have been confirmed, which have been read but not confirmed, and which have not been read yet.
What do you think of these ideas? Do you have any ideas of your own? We would greatly appreciate it if you would communicate your feedback to us at your earliest convenience. The last thing that we want to do is invest a lot of time and money in something that is of little or no perceived value to our clients.
I don’t recall receiving any substantive responses to this, but around this time Steve VeZain sent me a rather lengthy email that explained some of the priorities for Saks Inc. Our dealings with him and his company are detailed here.
Net.Data: At some point I became acquainted with an online forum called IGNITe/4007. This was a website where AS/400 developers could pose questions about using the AS/400 for applications for the web. Although some IBM experts participated, the forum was not run by IBM, but by a former IBMer named Bob Cancilla8, who worked for a company in Rochester, MN, the home of the AS/400.
Bob also wrote the book shown at left that explained how to use the AS/400 as an Internet server. IBM disdained the approach of its customers using a book written by someone who had actually gotten the AS/400 to function as an Internet server. Big Blue preferred that its customers spend hundreds of dollars on classes or thousands of dollars on consultants rather than $15 or $20 for a book. They also championed something called WebSphere to manage applications written in Java. During February and March of 2000 I had puzzled over the Redbook that documented this product. I was nearly ready to give up on the idea of using the AS/400 for anything related to the Internet until I found Bob’s book and website in April of 2000.
I purchased this excellent tome and followed most of Bob’s advice. I successfully configured TSI’s model 150 as an HTTP server to serve web pages to browsers and as an FTP server for exchanging data files. It was possible to use the AS/400 as an email server, but Bob advised against it. We elected to use AT&T for sending and receiving emails for our employees. We later configured our AS/400 to send outgoing emails through the SMTP (simple mail transfer protocol) server. Eventually IBM decided that it was a bad idea to have its own proprietary HTTP server and supported a version of the Apache server used by almost everyone else.
At that time the most popular scripting language for web-based applications was PERL. IBM never supported it on the AS/4009. Instead it provided its own language, which was called Net.Data (pronounced “Net Dot Data”). This was the only web language that could be used on the AS/400, and no other system in the history of the world ever used it. We obtained a copy of IBM’s handbook on Net.Data (posted online here), and I determined that we could probably use the language for what we wanted to do. Here is what I wrote about it at the time.
I signed on to the IGNITe400 website and registered as a member. It’s free. You can ask questions there. I looked at a few of them. Bob Cancilla himself answered some of the questions! I also looked at IBM’s Net.Data website. It is full of information.
I printed out a lot of documentation. I am now convinced that we can do what we want to do with HTTP server and Net.Data. This is exciting. Buying that book was a great idea. The links alone are worth the price. The biggest difficulty that I see will be working out the process of getting the orders from our customers and then from others.
… I have more than doubled my knowledge about the AS/400 and the internet in the last two days. Moreover, I think I could do it! I think that we should try it some time this coming week.
Net.Data was an interpreted language, just as BASIC was on the Datamaster and the System/36. The programs (which in web parlance were called scripts or macros) were not compiled into executable machine code. Changes to the scrips took effect as soon as the programmer made them. So, a developmental environment was a necessity. The time it took the processor to interpret the code and generate the HTML code that the browser could understand made all of the programs considerably slower than the compiled BASIC programs on the same machine. However, they were lightning fast compared to Java, the approach blessed by IBM.
So, I taught myself how to use Net.Data to deliver interactive scripts for a browser (at the time the main choices were Netscape Navigator, Internet Explorer, and whatever Apple called its browser before Safari). The language itself was relatively easy to understand, but programming for numerous constantly changing browsers was much different from programming for a very stable AS/400 and its 5250 user interface.
I also had to learn the Common Gateway Interface (CGI), which was the method of reading from and writing to files on the AS/400. This was totally different from what we were accustomed to. Our programs had always read the files a record at a time even after we switched to the AS/400’s relational database. With Net.Data it was necessary to execute an SQL statement that returned a set of data—rows (records) and columns (fields)—that was stored in an array (called a table in Net.Data). It was then necessary to loop through the rows of the array. I was already somewhat familiar with SQL, but I needed to learn how to use “joins” to do complicated selections.
These two volumes got a workout. The binding on the HTML book split in two years ago.
I also needed to buy books on HTML and JavaScript. If I had realized before I started that I needed to learn all of this, I might have deemed that the project would require more time and effort than I could afford. However, by the time that I realized what I was up against, I had invested so much time that I was not about to abandon the project.
There was no syntax-checking of Net.Data macros, and, at first, there was no editor to help by color-coding the statements. So, when I ran into a problem, which happened quite frequently, I had to search elsewhere for help.
Life got a lot easier when IBM put its Redbooks on CDs.
In researching for this blog, I found a pdf online for a Redbook (technical manual) that IBM published for people like me in 1997. It is posted here. Even a quick glance will make it clear that writing applications for the AS/400’s HTTP server would be a daunting task. For example, it contained this statement: “Net.Data Web macros combine things you already know such as HTML, SQL, and REXX with a simple macro language.” I did not know HTML at all, I knew only a little SQL, and to this day I have no idea what REXX was. Also, the Redbook neglected to mention that it was not really possible to write interactive programs without JavaScript.
I hung in there. Here is one of my last messages: “I feel a lot of pressure to work harder. I want this new project operational yesterday. It is going to be difficult at first. I want to get over the hump.”
I spent a lot of time in the IGNITe/400 forum. My best source of information was a guy from (I think) New Zealand, of all places. I never met him in person or even spoke with him on the phone. His name was Peter Connell, and he helped me through every difficult coding problem that I encountered. Not once was he stumped. By the time that I was well into the project, I was able to provide solutions to coding problems that others described.
TSI’s Internet Project: Even before Denise and I attended PartnerWorld, we had pretty much decided that our best shot at developing a successful Internet product would involve insertion orders, which is what newspapers and magazine call reservations that they receive from advertisers for ROP (display ads), inserts, polybags, or any other kind of advertising. TSI’s AdDept customers sent their reps at newspapers a schedule that listed all of the ads that they wanted to place for a specified period—usually a week. Most of them faxed this information to the papers. The rep at the paper examined the schedule. Sometimes questions required phone calls. Sometimes requests (such as designated positioning in the paper) could not be accommodated. Even after final approval the schedule was often changed by the advertiser before the ads ran, sometimes with very little advance notification.
Newspaper ads were expensive … and valuable.
Errors on both sides were not rare, and they could be quite costly. The newspaper often gave the retailer free ads to make up for the mistake. The advertiser’s loss might be much greater. In the nineties and early twenty-first century ads in newspapers were the primary vehicle for communicating with customers. Mistakes in the ads could cost the retailer thousands in sales, and they were embarrassing to the advertising department. Occasionally heads rolled.
In 2000 most retail advertisers faxed their schedules to the newspapers. If the line was not busy, the phones were rather reliable. However, what happened to the schedule after the fax machine received it? Was the printout legible? Did the rep ever get it, and, if so, what did he/she do with it. What assurance was there that the fax that the newspaper used to compose the paper was the final version?
We thought that the Internet might provide an opportunity to speed up this process and to improve its reliability. My first idea was to replace faxing with email. If the AS/400’s (free) SMTP server were installed, AdDept could compose and send to the newspaper an email that contained the schedule. Wouldn’t the newspaper rep immediately print the schedule? If so, how was this better than faxing? Doesn’t it just add another step? Besides, email is demonstrably less reliable than faxing. The worst that usually happens with faxing is that the output is blurry or even unreadable. Emails, in contrast, can be held up by any Internet Service Provider (ISP) that handles the message, and there could be dozens. So, the schedule might never make it to the rep’s inbox.
Eventually Denise and I settled on using FTP to send the schedule from the client’s AdDept system to TSI. Thereafter TSI’s AS/400 managed the whole process using a combination of BASIC programs and Net.Data macros. Details of the actual design are posted here.
After Denise and I agreed on the design, several details still needed to be settled:
Who will do the coding at TSI?
Who will pay for the service, the advertiser or the newspaper?
How much will we charge?
How will we market the product to our clients and their newspapers?
How can we entice advertisers that did not use AdDept to use this method for insertion orders?
Can we take advantage of the link established between TSI, the papers, and AdDept for other modules?
What will the product be named?
Will the project be part of TSI or a new financial entity?
The answer to #1 turned out to be Mike Wavada. I expected that I would eventually train Denise or one of the programmers so that they could at least support the existing code, but it never happened. It astounds me to report that this was a one-man coding job from day one, and no one else at TSI ever learned Net.Data. Hundreds of papers and most of the AdDept clients relied on it starting in 2002 and continuing through early 2014. Think about this: Between 2003 and 2012 I took six vacations in Europe and one cruise in the Caribbean. There were no serious incidents!
Questions 2-5 are addressed in the entry about marketing of AxN, which is posted here.
From the outset I was hoping that the nexus connecting newspapers and the retailers through TSI’s website could be used for other communications as well. The most obvious one was for the delivery of the files that contained the layouts of the ads. Nevertheless, I was reluctant to pursue this for several very good reasons. The first was that the Associated Press already had a huge head start with its very popular product called AdSEND10. There were also several other companies that offered similar services.
The other thing that gave me pause was the potential legal liability. It seemed to me that if we failed to deliver an ad correctly and/or promptly, we could easily be sued. A fundamental tenet of TSI’s operation had been to avoid any activity that might occasion a lawsuit. Throughout the first two decades of its operation, TSI had successfully avoided litigation. Also, we knew nothing about the process of sending ads electronically, and the AP already owned satellites that it used for this purpose. I also learned later that AdSEND had twelve dedicated T-1 lines, and one of TSI’s clients told me that that was not nearly enough. TSI eventually installed one T-1 line that easily handled the insertion order traffic generated by AxN.
An idea that I liked better was for the newspapers to transmit their invoices electronically through TSI’s servers to AdDept users. I even came up with a cool name for this: e-I-e-IO, which stood for electronic invoices and electronic insertion orders. My idea was to provide a program to feed the newspaper’s billing system with the information from the insertion order, and to feed the retailer’s AdDept system with the same information. I did a little research to see if one software system for billing or accounting was dominant in the newspaper industry and discovered that this was decidedly not the case. So, we would face the prospect of persuading one paper at a time, or, at best, one chain of papers at a time. Furthermore, someone else had already claimed the URL that I really wanted: eieio.com.
The name that I picked for the new product would still work if we came up with other ways for TSI to serve as a nexus between advertisers (A) and newspapers (N). It was AxN, which was pronounced “A cross N”. The A and the N were always portrayed in dark blue Times New Roman. The x was always in red Arial.
That leaves question #8. Denise was always in favor of making AxN a separate financial entity. However, we never found a way to extricate it from the rest of the business. We looked at the revenues separately, but we never even did a separate P&L for it.
1. René Conrad was TSI’s liaison with Kaufmann’s, the May Company’s division based in Pittsburgh. Both Denise and I had a very high opinion of her. When Doug Pease left TSI in 1999, we tried to hire René. Details of the AdDept installation at Kaufman’s are posted here. The unsuccessful pursuit of René is documented here.
2. Ken Owen is a friend and was a client. The latter role is explained here. By 1999 Ken’s business had drifted away from creating and placing ads for clients to software for the Internet. He gave us a little free advice, but the role for him that I envisioned did not materialize. I communicate via email with Ken every year on March 4, the holiday that we celebrate together—Exelauno Day.
3. Tom Caputo and Chris Pease were our key contacts at Lord & Taylor in Manhattan in those days. The history of the installation at L&T is recorded here.
4. I did contact the NNA, but nothing came of it. The person with whom I spoke was nice enough, but it became evident that trying to work with this organization would be extremely time-consuming and not the kind of thing that I was good at or enjoyed. Eventually I discovered that there were almost as many administrative systems for newspapers as there were newspapers. It appeared that there were no accepted standards.
5. The American Association of Advertising Agencies (AAAA—universally pronounced “four A’s”) published an annual list of software for ad agencies. For years TSI’s GrandAd system was on the list. I am not sure what I had in mind as an additional relationship. Perhaps I envisioned ad agencies that specialized in retailers might want to use AxN for insertion orders and would work with us to create an interface. Perhaps I thought that other software companies might add the interface to their products for ad agencies. Nothing like any of these things ever happened.
6. EDI is short for Electronic Data Interchange. It refers to an orderly setup that enables participant to exchange information electronically. When there are only two participants, it is usually just called an interface. “Specs”, which is short for specifications, refers to the documentation published and delivered to the participants and prospective participants.
7. I have no idea what the name of this group meant. At the time IBM was busy promoting the idea of e-business. IBM’s marketing director proclaimed at PartnerWorld that IBM “owned” the concept. So, that may explain why the e is not capitalized. I was surprised to find an article in Enterprise Systems Journal about IGNITe/400. It is posted here.
8. Bob Cancilla went back to IBM for a while and then became a consultant. His LinkedIn page is here. In 2018 he wrote about the thirtieth anniversary of the AS/400. It is posted here. The article explains some of the reasons why IBM treated the AS/400 division and its customers so shabbily almost from day one.
9. For some reason IBM repeatedly changed the name of the AS/400 to a bunch of things with the letter i appended. The operating system remained the same. Everyone at TSI, like most users, still called it the AS/400 even after the name changes.
10. In 2007 Vio Worldwide acquired “the assets” of AdSEND. The deal is described here. In 2010 Dubsat acquired Vio Worldwide. This transaction was reported here.
The term insertion order was used in advertising to describe a list of detailed information about ads that advertisers provided to newspapers or magazines so that the publication could reserve the space. The design of AxN, TSI’s clearinghouse on the Internet for insertion orders, only really congealed when I had finished reading Bob Cancilla’s outstanding book about using the AS/400 for e-business, IBM’s word for commercial transactions that used the Internet. The process of determining what TSI wanted to do and how we learned how to do it has been described here.
The Internet servers on the AS/400 in TSI’s office were used in the project. The FTP (File Transfer Protocol) server was used to receive transmissions of data files containing insertion orders generated by the AS/400’s at our client. The SMTP (Simple Mail Transfer Protocol) server sent computer-generated emails to both advertisers and newspapers. The HTTP (Hypertext Transfer Protocol) server allowed the posting of web pages on TSI’s website, TSI-TSI.com.
TSI’s AS/400 was connected to the Internet through a T-1 line leased from AT&T. The backup line was a cable connection to Cox. It was seldom, if ever, needed. I can recall no problems with the connection.
AdDept changes: AdDept, TSI’s administrative system for the advertising departments of large retailers, included programs for producing the original insertion orders used to schedule advertising at newspapers and for producing change orders and cancellations. The users at each installation had slightly different methods of selecting the items from the media schedule to be ordered (usually once per week for ROP and once per month for inserts) and different formats for printing or faxing the orders. However, all installations used the same programs for updating the data files with the ordering information.
Newspapers were ordinarily designated on AdDept’s pub table with two “variations”—one for ROP (“run of press”—the pages printed by the newspaper) and one for inserts (the preprinted flyers and coupons inserted with the pages printed by the newspaper). Some needed additional variations for things like the Sunday supplement or the television guide. The pub table contained a field that designated how insertion orders would be delivered. The choices—as designated by a one-character field on the pub table—were faxing or just printing. A new option was added for delivery through TSI’s website on the Internet using AxN. When a paper agreed to a trial subscription for AxN, the field was changed for each of its versions. If the paper stopped using AxN, it was set back to its previous value.
The configuration on each client’s AS/400 was modified so that the FTP server was automatically started every time the system initiated the Initial Program Load (IPL). “IPL” was IBM-speak for booting or rebooting. Most of TSI’s AdDept clients IPLed once a week.
The sections of the insertion programs that updated the data files were augmented. If the pub was using the Internet for insertion orders, new code was executed for each order as a whole and for each item on the order. This code created a file for the order and wrote records on the file for the header (AxN‘s code for the pub, range of dates, type of order, whether it was a new order, revision, or cancellation, and a few additional items), detail (individual ads), and special instructions that could be for individual ads or the whole order. As records were written, they were logged on a file.
When the user closed the insertion order program, a routine was called to use FTP to send a copy of the file to a designated library1 on TSI’s server. The original files remained on the advertiser’s system for a while until the system administrator ran the cleanup program.
FTP clients can actually do a lot more than send and receive files, but the configuration of TSI’s server prohibited most of those features.
Processing the orders: The configuration for TSI’s AS/400 was also changed so that the FTP, SMTP, and HTTP servers started during each IPL. Another program that we wrote to monitor the library containing orders also was started at IPL. In the twelve years that this process was active we had zero failures.
The monitoring program examined the contents of the library designated to receive the files. If the library was empty, the program went to sleep for a minute or two. If it found anything in the library, It copied the files to a separate library. For each file that it found it started a batch job to process the file. It then deleted the files from the receiving library and went back to sleep.
The processing programs evaluated each file to make sure that it could read all the records and that none of the fields in any contained invalid information. Since all of this information had been generated by AdDept programs run on the advertising departments’ AS/400s2, problems almost never occurred. If any anomalies were discovered, an email was sent to me, Denise Bessette, and a programmer.
After validating the data the program created database files for new orders or updated the records of existing orders. Time-stamped log entries were written for all of these operations.
After the permanent database files were updated, an email was sent to the rep at the newspaper and the coordinator at the advertising department. It simply told them that the insertion order had been posted on TSI-TSI.com and provided a link to the website.
The processing programs were written in BASIC and IBM’s Control Language (CL). The former were used to validate the received file and to update the data files. The latter were used for system-oriented tasks such as sending emails and copying files.
I don’t remember the details of how it worked, but I think that there was also a program that monitored the number of FTP transactions in a period of time. Two of three times the system was the target of half-hearted attacks on the FTP server. We were easily able to repel them.
Setup for the interactive programs: The reps at the newspapers and the coordinators at the advertisers were expected to be able to access TSI’s AS/400 through the Internet using a browser. Therefore, it was necessary to change the system’s configuration on our AS/400 so that the HTTP3 server for the website was always started as part of the IPL. At the same time a second local HTTP server for development and testing by TSI programmers (primarily me) was also configured.
Not tsetse, TSI-TSI.com.
Security was provided by the AS/400’s HTTP server. The scripts for all AxN pages on TSI’s website (TSI-TSI.com) were placed in a library that was password-protected. The pages that described the company and its products and services were open to the public. Static pages were written in HTML, the language of the web. The scripts for interactive pages were written in Net.Data, the only scripting language that IBM supported on the AS/400 at the time.
The AS/400 had the ability to set up interactive sessions for users who logged in to the HTTP server. If we had implemented this feature, the system could have timed-out users who had entered their credentials and left the connection open. Implementing this would have complicated the development enormously. We decided not to do it until it became necessary. Like all other developers in that era, we were in a hurry to launch the product on the Internet. Since we never encountered any security issues, we never did.
I take it back. Actually there was one security issue. The reps and coordinators tended to store their credentials in their browsers so that they would be filled in automatically on the security screen. When there was turnover, or someone got a new computer or software update, the passwords and user ID’s were sometimes lost. The support people at TSI did not have the capability of retrieving passwords, but they could assign new ones. After each new one was assigned, it was given over the phone to the user. To insure that this solved the problem, the TSI employee stayed on the line while the user signed on. The user was then advised to change the password and, if necessary, talked through that process.
I am sure that both the newspapers and advertisers were happy that we did not automate this process. We only needed to deal with it a handful of times per month. If we had succeeded at convincing more advertisers to use AxN, we might have needed to automate it.
The interactive programs for newspapers: In the course of research for this entry I discovered the pdf file for the very comprehensive AxN: Handbook for Newspaper Users and posted it here. I had created this twenty-two-page document using PageMaker software in the early 2000’s before we had the first live implementation of the product/service.
The handbook included samples of all the screens and reports. This document was sent to every newspaper when it agreed to participate in the trial period. We provided no training, but no one had much trouble learning to use the system. I must say that I think that I did a superb job. TSI received amazingly few support calls.
The document is more or less self-explanatory. There are just a few things that are worth noting.
The AxN programs used “frames”4. Every interactive screen had three sections that consistently take up the same amount of space on the screen. The “Display” section was always the top area with the light blue background. The “Buttons” area was at the bottom and had a steel blue background. The third frame was “Empty”; that is, it had no space on the screen reserved for it. For each page there was a master script that loads the scripts for the three frames.
When a user clicked on a button, the empty frame was loaded with the appropriate script and executed. So, for example, if the “Confirm” button was clicked on after an order had been selected, the script in the empty frame would check to see if anything was in the “Confirmed by” box. If not it would highlight that field and display an error message without reloading the page. If the field contained characters, the script called a sequence of CL and BASIC programs to mark the order as confirmed and send an email to the coordinator at the advertiser.
The buttons available varied by page. However the Buttons section always contained a Home button (the one that looks like a house) and a Help button (question mark). The former returned the user to the site’s home page. The latter produced a page that explained all of the fields and buttons on the original page.
The interactive programs for advertisers: I also found the pdf file for the twenty-eight page AxN: Handbook for AdDept Users: It explained how to use both the AdDept programs to send new orders, changes, and cancellations and the AxN web pages to make sure that all newspaper reps have confirmed the orders. I posted the handbook here.
Advertisers who made changes to the schedule after an order was sent were expected to make the changes in AdDept and to send revision orders.
Daily tasks: Every morning a program searched for unconfirmed orders. Lists were prepared for both newspapers and advertisers. Each newspaper rep and advertising coordinator was emailed a list of the orders that pertained to them. A master list was also printed at TSI. An employee made a “courtesy” telephone call to warn reps each newspaper with unconfirmed orders that they were within a few days of publication.
Billing: In theory both the advertisers and the newspapers were billed for the use of the AxN service. In almost all cases the advertisers had been using the AS/400 to fax orders to the papers. They had been paying TSI a monthly fee to maintain this software. When they started using AxN we charged the same amount for support and dropped the faxing charge. So, there was a net-zero effect for the advertisers.
TSI’s computer programs required changes to accommodate the newspapers as clients. The main change was to convert the three-digit5 client number field from numeric to character. The existing clients maintained their numbers, but the newspaper clients were assigned alphabetical designations sorted by state.
A separate billing program was written to create invoices for the newspapers. Most were billed quarterly; a few preferred to be billed monthly.
AxN was extremely reliable and was very popular with both newspapers and advertisers. Support calls were rare. I vaguely recollect one instance in which a newspaper failed to run an ad or ran it incorrectly. I was able to document exactly what the system had done with timestamps, and neither side thought that AxN had contributed to the problem.
I definitely wrote all of the Net.Data scripts. Someone else at TSI may have written a few of the BASIC and CL programs used for AxN, but I did the bulk of that coding as well.
1. A “library” in the AS/400’s “native environment” was roughly equivalent to a “folder” or “directory” on a PC. However, libraries on the AS/400 could not be nested. That is, there was no such thing as a sub-library. More details about the AS/400’s design principles can be read here. The AS/400 also supported being used as a server for some other operating systems, but TSI did not use that feature.
2. The header record for the order contained a field that identified the format used for the files. Since no one except AdDept users was ever convinced to use AxN, no code for processing orders in a different format was ever written.
3. HTTP stands for Hypertext Transfer Protocol. HTTP servers were able to serve pages to a browser using the Hypertext Markup Language (HTML) and a few other formats.
4. I really liked the use of frames, but for some reason it was disparaged by supposedly sophisticated developers, and eventually frames were no longer supported by browsers. Instead a complicated use of Cascading Style Sheets (CSS) was necessary to produce a similar effect. AxN was still using frames when TSI closed in 2014. I have never been able to duplicate the effect of the empty frame with CSS.
5. The worst design mistake that I ever made was using a three-digit number for clients. None of our agency clients ever needed a larger field, and the client file on TSI’s system still had many unused client numbers when we began marketing AxN. I decided that it would require less effort to change the type of the client number field from numbers to characters than to expand the size of the field.
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.
This may have been the last time that I actually jumped.
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.
The train brought us to Penn Station, only a block or so from Macy’s.
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.
Camex was located at 75 Kneeland St. in Boston.
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.
590 Madison Ave., then known as the IBM Building.
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.
This is the only photo that I could find of a magazine. The diskettes are inserted in and removed from the opposite side.
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.
My dog could not juggle six balls.
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.
TSI could not even afford J. Cheever Loophole.
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.
The luxurious Windsor Locks Amtrak stop. This is the view looking north. From the parking lot the engine’s light could be seen under the bridge.
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.
The word you did not want to see was “DELAYED”.
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.
Time to go home.
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.
Gary Beberman.
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.
Merchandise that was afraid of the traffic could have just as easily taken the train.
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.
Denise Jordaens.
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.
