Tag Archives: TSI Tailored System

2024-2025 Membership Software System for the Hartford Bridge Club

Posted on by
Reply

Web-based membership/transaction database. Continue reading →

Still in progress.

Since I had not really described in much derail any of the software projects that I designed and implemented over my long career as a cowboy coder, it seemed appropriate to provide quite a few details about my approach to this one, the first that I had attempted after the pandemic. My apologies if the entry became a little wonky at times.

The Hartford Bridge Club (HBC) has been recognized as the oldest such group in the American Contract Bridge League (ACBL), the governing agency for competitive bridge in North America. The club boasted more than five hundred members before the pandemic. Unlike most bridge clubs, it was owned by its members, who paid dues every year for the privilege of playing there. The club had a manager, but her contract specified no salary.1 The decision makers consisted of the usual four officers—president, vice-president, secretary, and treasurer—and six “trustees” who usually served three-year terms. Nominees for both officers and trustees were selected by a committee and elected at the club’s annual meeting in the fall. Additional nominations were possible, but usually the entire slate was elected.

In practice, of course, a lot of the responsibility was handed off by the Board of Trustees to the club manager.

In the fall of 2021 I was asked to serve on the HBC’s board. My three years on that board have been chronicled here. One of the most frustrating experiences for me and for many others else was the fact that the club seemed to have no definite notion of which people were actually members. The count done by the treasurer, Trevor Reeves, was significantly less than the “official” number reported by the club’s manager, Donna Feir. Both were well short of the pre-pandemic standard of over five hundred. No one seemed able to reconcile the two in a systematic manner.

Donna kept track of membership using the ACBLscore program provided by IBM. Its primary purposes were to set up different types of games and tabulate results, but it also kept track of who had played at the club. The software was written decades earlier in dBase or something similar that ran in DOS or windows. It did not employ a relational database. The files were in a proprietary format. The screens were antiquated. It performed many functions admirably, but there were limitations.

The discrepancies between membership lists persisted throughout the next two years. Near the end of 2023 I decided to try to address this situation. I interviewed most of the major players. I did not interview Donna because my experience was that she seemed very nervous about anything that might upset the club’s day-to-day activities. I learned that the club had several lists of members. No automated method connected them:

  • The ACBLscore list that Donna maintained could be used to print phone lists and masterpoint lists if those fields were kept up to date. Other reports were also feasible. Files with comma-separated values3 (csv) could be created for exporting to software. Many programs, including spreadsheets, could read these files
  • The club’s gmail account had a contact file associated with it.
  • The club used its MailChimp account for mailings to all members. Names and email addresses of members were stored in an “audience” from which files could be imported and exported.
  • The financial people on or associated with the board had at least one list.
  • Other ad hoc lists sometimes were created.
The member table.
Transaction layout.

I determined that a relatively risk-free system composed of a membership file and a transaction file stored on relational database that everyone who needed it could access would probably address many of these issues without requiring a great deal of work. In addition to the main files, I envisioned three background tables:

  • A very small table to discriminate between memberships, contributions, and any other basic type of transaction. There were not many of the latter, but better to plan than neglect.
  • The table for transaction types contained the a description, fiscal year2, and a code designating the main type.The last two were required fields.
  • A user table for security.

I envisioned only one very flexible output program that could simply count of the number of items selected, produce a list on the screen, or create a csv file to be downloaded. If that proved insufficient, I felt confident of being able to add more options later without a great deal of difficulty..

I also saw an opportunity to integrate data from the players table that I downloaded monthly from the ACBL roster. So, users could easily compare what was on the new system’s members table with what the ACBL had: address, phone numbers, email address, masterpoints, etc.

In my heyday I could have designed and coded this sort of project on an AS/400 in less than a week4. However, I had done almost no programming at all since the beginning of the pandemic and precious little in the previous four or five years. Furthermore, I would be working in a less forgiving environment than what I had been accustomed to at the turn of the century. I would not have the AS/400’s tools and IBM’s support. This project required an Internet-based system for others to use that ran on php scripts, a MySQL database, and an Apache server on a computer on which I rented space. I had only designed one web-based project, and it did not use the php programming environment. It also did not help that I was in my mid-seventies and becoming more senile every day.

In early 2022 I had undertaken a project to provide Ben Bishop, the president of the HBC, with breakdowns of the number of active club members in various masterpoint ranges. I had asked for a csv file that contained one record for each active5 member of the club. Someone extracted the data from the ACBLscore program that the club used, and I received it in early February. I then used MySQL to populate the “HBC?” field on the players table in the database that I had created for District 25. This information allowed me to provide the club with accurate and timely data.

After I had decided on the fields in the files and tables6 for the membership database project and used MySQL to create empty versions of each table, I wrote sets of php scripts for recording, updating, and deleting main types and transaction types. Since I modeled these scripts on ones that I had written previously, I was able to produce them relatively quickly. It was at this time that I decided to save all of the scripts in the same folder as the other php work that I had already done. This allowed me to have easy access to dozens of scripts that I had used repeatedly.

I wrote and tested the scripts on Asus, my local desktop system. I planned to copy it to my wavada.org account on the iPower system when enough had been completed that I could demonstrate its functionality to others at the HBC.

I then entered two main types and several transaction types for the 2022 and 2023 fiscal years.

The csv file from ACBLscore had columns for first name, last name, ACBL number, and email address. I loaded it into a spreadsheet. Nine records had no ACBL number. I assigned numbers 1-9 to them. This was safe because the lowest number used by the ACBL was 9999999. I also changed the first character for the Life Masters to the numerical equivalent. I imported the file to my local MySQL database and created one record in the members file and one transaction record for membership in 2022 and another one for 2023..

Next came the script for maintaining the member table. There was nothing remarkable about this program except for the fact that it showed a history of all of the transactions for the selected member and extracted and displayed pertinent information from the players table in the database that I created for District 25.

All of the fields from the original ACBLscore file—first name, last name, email address—as well as five fields that I added in anticipation of future needs—phone number, photo link, emergency contact name and phone, and concatenated name and town—could be changed.

I deliberately made no provision for deleting a member. I could not foresee any reason for deletion, and if someone did it accidentally, it could cause significant problems.

Coding the main program that users would use for data entry was the next target. Entering a transaction would probably be perceived as an extra step. Therefore, its design must emphasize speed and simplicity so that it did not seem onerous. Here is a screenshot:

Transaction types were ordered in the selection window so that those for the latest fiscal year were on top. Members were selected from an alphabetical (by last name) list. The current date appeared as the default for both the Transaction Date and the Deposit Date. The Deposit Reference # and the Note were optional. It should be possible to record any transaction in under a minute.

When the transaction entry program was finished, I was familiar enough with the way that the system flowed that I could design the security. This was new for me. IBM provided security on the midrange programs that I had worked, and I had been the only user for my previous work for the district on wavada.org. I created a table of authorized users that had only two fields, user ID and password. I created a few records using MySQL. I then wrote scripts for a routine to check whether the user has provided the user ID and password or not. If not, it forced them to select the former from a list and enter the latter. The script was inserted at the beginning of every program on the menu.

I did not provide a way for anyone the HBC to maintain the user table. I figured that I might need to do that at some point, but I felt that I should control creation of user IDs at least during the installation and testing phase.

Before I coded the scripts for producing the output I designed and executed a very simple menu. It contained three sets of buttons.

The buttons on the left were for maintenance of the three tables. The middle group originally contained only the program to record transactions. The one on the right was for output.

I used the <BUTTON> HTML tag for the buttons. I had never used it before, but I had little difficulty in adapting to its syntax.

I decided that I needed two more sets of scripts for transactions. I had decided not to let users delete or edit them, but they certainly required a method of correcting mistakes. I decided to let them reverse the erroneous transactions and enter new ones. They also might need a way to edit fields that did not affect auditing such as the notes. If so, I will provide a way to do that.

The other item in the second column of the menu, “Change Member Numbers”, was designed to handle the situation in which a person who was not an ACBL member joined the club and was assigned a low number. If that person later became an ACBL member, it was important that everything associated with the low number be changed to reflect the new number. After that the old number could be reused.

When TSI was writing programs for its customers we would usually provide the output in the same format that the users were accustomed to or what they wished that they could have. Then we would design the selection screen so that they could get that output rapidly.

The HBC directors occasionally got reports or exports from ACBLscore. They first selected the format of the output. The next steps involved a very flexible method of selecting. It began with the window at the right that allowed them to specify which fields that they wanted to use for selections. This was a fairly sophisticated approach7, but most of the users were terrified by it.

The space bar key was used for selection. Depending on which field was selected, a new set of windows allowed them to specify the details of the “restriction”. A user who designated two or three restrictions might need to navigate six to ten additional windows to get to the next step. If “Cancel” was selected anywhere in the process, control reverted to the format selection window that preceded the one displayed here. When all restrictions had been specified, a new window to list the columns on the report appeared.

Once again the space bar key was used to indicate the fields. In this case the indicated fields would appear as columns on the report or the file exported.

There was no way to designate a set of fields that was commonly used. The user either needed to start with a blank slate and select the needed columns or select all first and then designate the columns that were not needed.

There was a lot to like in this approach. Virtually anything could be extracted from the master files. However, the process was quite involved and was subject to time-consuming mistakes and corrections.

When I had to use the field screen for a project to upload tournament results to the District 25 database that I designed, I had to memorize the selection routine, which was something like “Press the space bar key eleven times, press the down arrow six times, one space bar, five down arrows, one space bar, four down arrows, one space bar, OK.”

I had the advantage of not needing to provide a method as comprehensive as what the users struggled with. For example, close to 100 percent of the people in the club’s database resided in District 25. In any case the unit or district in which they resided was seldom useful to the directors or anyone else in the club’s administration. Many of the other fields were of no use at all to directors or anyone else at the club.

I decided to try to provide sufficient selection and reporting flexibility on only one screen. Here is what I eventually came up with8:

The screen had four sections. The upper left section was used for determining which transactions would be selected.

Starting and ending values could be specified for the first five fields. The Masterpoints and YTD Masterpoints fields were the values at the time that the program was run, not the time of the transactions.

Only valid Type Codes and Main Types were allowed. The Fiscal Year was a two-digit number. Only transactions with a type code for which that year had been specified were selected.

If the User ID, which referred to the person who entered the transactions, was specified, it was validated against the user table.

Ordinarily reversed transaction and transactions for deceased members were excluded. A user who wanted to include either of them could check the appropriate box.

If all of the defaults in the fields for the selection criteria were accepted, all living individuals who were members for the specified fiscal year would be selected.

The upper right section was for determining which columns should appear on the report. The member’s name and town always appeared. The two columns for masterpoints came from the roster file and reflected the most recent ACBL roster, not the one at the time of the transaction. The phone number came from the member record.

Up to three sort fields could be selected by clicking on the appropriate radio button. The same field could not be selected twice.

There were three possible kinds of output—the number of records selected, the number selected plus a list of the transactions, or a csv file downloaded to the user’s computer. This iappeared when the transaction type was set to M14, and otherwise the defaults were selected:

It is hard to see, but a slide bar was on the right so that the rest of the list could easily be viewed.

When I showed the system to Ben Bishop for the first time during the late summer of 2024 the screen listed all three types of reports, but the one to produce and download the csv file did not work.

I researched on the web how to execute the download of the csv file in php. I found several articles with useful samples. I had expected that I could do it by defining a function that was invoked when the user specified the radio button for “Download a csv file” and then clicked on the Submit button. I was wrong. It worked when the URL for the script with SQL statement embedded in the code was executed directly in the browser, but it did not work when the SQL statement was passed to the same script through an argument for a function arguments. It just displayed the contents of the csv file on the screen.

I beat my head against this wall for an embarrassingly long time. I eventually realized that the problem was that nothing could be displayed on the screen when the csv script began. Everything must be initialized as it was when the URL was executed directly in the browser. I considered creating a file in the database that was only used to hold the SQL statement, but if two people were downloading at the same time, confusion might result. I finally figured out that I needed a JavaScript routine that passed the variables. The key statement was f.action = \”$Bin\” + \”HBC_CSV.php?sq=$sq\”.

  • The backslashes before the quotation marks indicated that the quotation marks were to be preserved. They did not indicate the beginning or end of a string constant.
  • The $Bin php variable delineated whether the script was running on the local server or iPower. HBC_CSV.php was the name of the script that executed the SQL statement, put it in csv format, and downloaded it.
  • The question mark after php indicated that a list of variables and values followed.
  • The $sq variable contained the MySQL statement.

I was quite excited when I finally got this to work.

The members table that I showed to Ben did not have a way of flagging records for deceased members. I added a field for that and a checkbox to the output selection screen to allow inclusion or exclusion.

At the first presentation the output screen did not have the list of columns to be included. Providing this flexibility proved to be much more time-consuming than I expected. It was difficult enough to put conditions in front of every statement that referenced any of the fields. It was very easy to get the syntax slightly wrong or to leave out a brace, bracket, parenthesis, or semicolon. When that happened, the syntax error that was thrown returned a message that something was “unexpected” in line 123 (or whatever the line number was). The cause of the error was usually something missing either before or after that line. My seventy-six year old eyes—never that good since the third grade—tired of looking for likely suspects quite easily.

The worst was the use of a dollar sign as the first character in every variable name. I had spent three decades placing dollar signs as the last character in names of string variables. I discovered that I had not broken myself of that habit. The very last syntax errors that I corrected were two occasions when I overcorrected for my BASIC programming habits and placed two dollar signs at the beginning of a variable name in the csv script.

On January 18 I went into the club an hour before the Saturday afternoon game. I seated myself at the “old” directors’ computer in the back room. A search program that I had never seen was in the middle of the screen. I closed it down and deleted the “run-time” messages. I then was able to see the icon on the desktop for ACBLscore. It was a little different from what I was used to, but I was able to find the program to create a csv file.

I had brought a flash drive with me. I tried to insert it into one of the USB ports on the box on the floor next to me. I had difficulty fitting it in. I had to turn it around so that it was going in with the logo facing to the right.

I ran the exporting program. When I went to select a group I was surprised to find over a hundred choices. I first looked at the ones that started with D. None of them looked like they might stand for deceased.

In the H’s I discovered what I was looking for. H00 had only one record for Marsha Futterman. It must have been a test. H01 through H26 had hundreds of records. There were also mysterious groups for H, H2, and H35.

I selected H01 and specified six fields: first and last names, ACBL numbers, the two phone numbers, and the email addresses. I saved the file onto my flash drive as H01.csv. I then repeated the process for H02 and so on.

At about H05 a group of novices from the beginner class took seats in the back room and peppered Bob Hughes with questions. I tried to ignore them, and I wished that I had brought my earplugs, but I forgot them. The only thing that required much concentration was choosing a name for the file that matched the group selected. I made a few mistakes that I noticed almost immediately, but I feared that I may have saved the same group under two different names at least once or twice. I finished with H25 at about 12:45, fifteen minutes before game time.

After the game, in which I played pretty well, I drove home and immediately downloaded the twenty-six files onto Asus. I loaded them one-by-one so that I could count the records. I found the following anomalies: H09 was missing. H11 had only 306 records with no Wavadas. H15, H16, and H17 all had 508 records. H22 and H23 both had 430 record.

Since I was also playing on Sunday, I resolved to come in a little early and redo those files.

1. An annual “honorarium” was voted annually to the manager and other officials.

2. The club’s fiscal year began on November 1. Thus fiscal 2025 ran from 11/01/24 to 10/31/25.

3. A file with the extension “.csv” contains rows that are formatted identically. Fields (columns) are separated by a comma or another delimiter. Spreadsheet programs such as Excel can read these files.

4. I could code extremely rapidly in the native environment on the AS/400, but the resulting data entry screens, although equally functional, would have been much less attractive. When the company closed in 2014 there was no way to export a csv file on a user’s computer. That would take several steps using third-party software. The AS/400 could serve as a file server for php programs, but if that method were used for a project like this, development would be much more tedious and time-consuming.

5. Some club members were not required to pay the prescribed annual dues in order to participate as members. I assumed that every person on the file had paid the dues, but there 6ere doubtless some who were not required to.

6. There is no fundamental difference between a table and a file. I have always used the word “table” to delineate files that are established at the beginning have a relatively small number of records, and are primarily used to maintain consistency. The other two files in this system can be maintained at will and are much larger.

7. Why “unit” and “gender” were capitalized on this window remainder a mystery throughout my investigation.

2004-2014 TSI: AdDept Client: Dick’s

Posted on by
3

Chain of sporting goods stores in Pittsburgh. Continue reading →

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, CPA, MBA
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.

12. John Nelko’s LinkedIn 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.

18. Bob Pecina’s LinkedIn page is here.

19. Mike Krall left Dick’s in 2011. His LinkedIn page is here.

1996-2006 TSI: AdDept Clients: May Company

Posted on by
3

As soon as the AdDept system at Macy’s in New York (described here) was running reasonably well, the May Department Stores Company became the most attractive marketing target for the system. The largest advertiser (at least in newspapers) in central … Continue reading →

The G. Fox & Co. store in downtown Hartford.

As soon as the AdDept system at Macy’s in New York (described here) was running reasonably well, the May Department Stores Company became the most attractive marketing target for the system. The largest advertiser (at least in newspapers) in central Connecticut was—by far—G. Fox, a traditional department store similar to Macy’s that was based in Hartford. They even had a store that was within walking distance of our new house in Enfield.1 I was well aware that G.Fox was part of the May Company and that the May Company was largely responsible for the development of the mall.

I had purchased a book from somewhere that contained marketing information on large retailers. In it I learned that the May Company, which had been in business since 1877, operated the following divisions in 1989:

  • G. Fox & Co. based in Hartford.
  • The Hecht Company with headquarters in Arlington, VA.
  • Filene’s, a former Federated division based in Boston.
  • Foley’s, a former Federated division based in Houston.
  • Kaufmann’s in Pittsburgh.
  • Famous-Barr in St. Louis
  • J. W. Robinson Co. in Los Angeles.
  • May California in Los Angeles.
  • May D&F in Denver.
  • May Ohio in Cleveland.
  • Lord & Taylor in New York.
  • Meier & Frank in Portland, OR.
  • Venture, a chain of discount stores based in O’Fallon, MO.
  • Payless, a chain of shoe stores based in Miami.

That’s fourteen independently run divisions that were, except for maybe the last one or two, good prospects for the AdDept system. I figured that if we could persuade the parent company to commit to using AdDept in all of its divisions, TSI would be set for life. Maybe they would even buy us! That was the way that small software companies thought (and dreamed) in the late eighties.

In fact, the May Company during that period was busy acquiring other department stores, and that attitude put a lot of stress on the advertising departments of the divisions that acquired the new stores. There is no doubt that the May Company’s acquisition of thirteen Thalhimer’s stores in 1992 was the impetus for Hecht’s to purchase the AdDept system that year.2 Hecht’s advertising department had been using a PC-based system for producing corporate reports. It was completely incapable of handling the extra load. Similarly, when May D&F was folded into Foley’s in 1993, the Houston division suddenly was facing a greatly increased workload. That caused them to call TSI for help, and we installed an AdDept system for them.3 Capacity was never an issue for AdDept; we always proposed hardware near the lowest end of the available AS/400 models. If a client outgrew its hardware, it could migrate to a more powerful model.

Filene’s store in Boston.

In 1993 G. Fox was absorbed by the Filene’s division. Having a pretty good idea of the problems that this would cause for the advertising department of Filene’s, we tried to interest them in using AdDept. However, for reasons that I have never completely understood, we were unable to get our foot in that door for many years. Filene’s advertising department never took advantage of a significant portion of the system productively enough that we were able to use them as a reference.4

Instead, our third May Company installation was at Lord & Taylor5, where I learned that L&T did not play by the same rules as the other divisions. In some ways that caused headaches; in other ways it was delightful.

Doug Pease: In 1993 Sue and I hired Doug Pease to handle our marketing. One of the primary reasons that we selected him was because he had formerly worked in G. Fox’s advertising department in Hartford. He was looking for a job because the G. Fox stores had been converted to the Filene’s logo, and the advertising for those stores was planned and purchased from the office in Boston. Doug was quite familiar with the work flow of an advertising department that was similar to the ones that TSI was targeting, and he also had some contacts in the industry. Our hope was that he could grab the brass ring of the May Company for us while I was busy trying to get the systems for the three divisions—and a few other retailers—that we had sold up and running.

This was a very important time for TSI. My image of those days resembles a hockey stick. Until that time TSI had experienced rather flat earnings. We were basically just getting by. By contrast, in the last seven years of the twentieth century we had as much work as we could handle, and our financial statements were much better.

Unfortunately, I have almost no notes for that entire period. I talked with Doug on a regular basis, but my focus was on the current installations. I depended on him to establish a relationship with prospective customers. As soon as we hired him we did a mailing to prospective customers, and Doug took to the phones. He talked with several people at the May Company.

The main liaison person between the May Company and the advertising departments of its divisions was named Fred Christen. I never heard anyone say a bad word about him. He had, of course, heard about our work at our three installations, and he seemed to be impressed.

I am pretty sure that we had another “guardian angel” at the corporate headquarters. I often seemed to be at an advertising department at a division at the same time as a corporate auditor whose first name was Linus. His job was to assess the way that divisions were reporting their advertising expenses and income from co-op programs for their vendors. He seemed to be impressed with the way that AdDept handled these things.

May D&F store in Denver.

Fred Christen left the May Company shortly after Doug arrived at TSI. I heard that Fred left to manage his family’s business. Doug established a relationship with Fred’s successor, Dennis Wallace. I am pretty sure that Doug made at least one trip to St. Louis, but I don’t remember the details. At any rate, at some point the May Company decided that AdDept should be installed in all of the department store divisions. At that point Robinsons and May California had merged, May D&F had been folded into Foley’s, Kaufmann’s had taken over the May Ohio stores6, and the May Company had divested the Venture stores. So, we learned about five new clients in one swell foop: Famous-Barr7, Filene’s, Meier & Frank, Robinsons-May, and Kaufmann’s.

In retrospect I find it rather incredible that I have so little recollection of the details of how or when this decision came about. It was definitely a momentous occasion for TSI, but I remember no fanfare or celebration at all. I don’t think that the deal was finalized until 1996 or 1997. In the interim I installed quite a few AdDept systems at other retailers.

Employees at the May Company treated us fairly from day one right up until the time that the company was purchased by Federated in 2006. Most of TSI’s dealings with the May Company were at the division level. The following is a summary of my notes of our dealings with the corporate entity after all of the systems had been installed.

Notes: The first note that I have is dated October 18, 1999. It makes reference to a “sales tax fiasco”. I think that this must be about whether it was necessary to charge sales tax on our software and services. Because all of our AdDept clients were in other states, we were generally able to avoid doing so. However, there is an Excel file with a similar date that lists three invoices for Robinsons-May, which was in California, and three for Filene’s, which was in Massachusetts. Massachusetts and Connecticut had an agreement by which each collected taxes for the other. So, we definitely needed to charge Filene’s tax.

We also had a problem with California. TSI’s second accountant, whose name I do not remember, was hired in the early days of the AdDept system. She advised us to register with every state in which we had clients. This was poor advice, and we changed accountants shortly after that. However, there is no way to take back a company’s registration.

I vaguely remember an issue from several years earlier that involved an arrangement that my partner (and later wife) Sue Comparetto had made with Gottschalks, another store in California. In this case, the invoices were probably sent to St. Louis and paid by the May Company. We had never registered in Missouri, and we never paid sales tax there.

On January 2 of 2000 I wrote the following email to my other partner, Denise Bessette:

I think that we need to get something established as soon as possible with the May Co. to get compensated for your time and mine. Do you have any suggestions? I also think that it might be time for one or both of us of us to go to St. Louis and talk turkey with them. I am serious about this. I really am tired of not knowing where we stand.

I found a six-page document dated February 7, 2001. It concerned the specs for a Planning System Interface. Evidently they had an application called WD that they wanted to feed. They provided me with a document describing the system that had at least sixty-seven pages. Evidently we had been talking about this for at least two years. The document lists my questions and their incredibly vague responses. No one could conceivably quote an interface based on the responses that we received. I only vaguely remember this whole process. “WD” sounds familiar, but I am pretty certain that we never quoted it, much less coded it.

Denise and I went to visit the May Company together, but I think that it was in 2002. I went to St. Louis in 2001 to install AdDept for use by Filene’s on an AS/400 in the Midwest Data Center. I stayed in the Adam’s Mark Hotel. I did not like where they told me to stay. This is what I wrote to Denise.

My hotel room in St. Louis is absurd. It is a huge suite. I located a microwave and refrigerator inside what looked like a chest of some kind. For some reason it is much easier to find these two features in places where it is impossible to buy food (because I am downtown). The bathroom is right by the door, about a quarter mile from the bed. There are two TV sets, but no Jacuzzi, at least not in the room. The thermostat is out of whack. You have to set it to nearly 80 to keep the room from being frigid. I fear that they may not offer free breakfast here. They did not mention anything when I checked in.

It is supposed to rain all day here. There may even be thunderstorms. I was too lazy to run on Sunday. I will probably regret it today.

I hope that the May Co. has a comfortable nap room. I have become quite accustomed to the two-hour post-breakfast naps.

I think that the guy on the phone is Dennis Wallace. I don’t recognize the other two.

I remember that room and the rain much better than I remember what I did at the May Company. On subsequent visits I stayed at a nearby Hampton Inn. Incidentally, more than two decades later I still take lots of naps.

I found an agenda for a meeting with the May Company dated August of 2002. This must be the trip that Denise and I took together. Here it is:

  1. TSI
    1. People
    2. History
      1. Founded in 1979.
      2. Advertising in 1981
      3. Retail in 1988.
      4. First May division (Hecht’s) in 1991
    3. Custom programming
      1. Good at diagnosis.
      2. Incredibly efficient system of delivering custom code using BASIC.
      3. Two principles:
        1. There should be one version of the truth;
        2. Everyone should be able to take advantage of work done by others.
      4. People capable of completing difficult projects within parameters.
  2. AdDept
    1. Intent
      1. All administrative aspects.
      2. All media.
      3. Easily customizable.
      4. Require a minimum of local support — AS/400.
    2. Retail advertising is difficult.
      1. All the difficulties of retail — stores, merchants, accounting, A/P, and co-op
      2. All the difficulties of advertising
        1. Multiple media, each with almost completely different structure
        2. Media scheduling, production scheduling, estimating, loan room, etc.
    3. System design
      1. Scheduling:
        1. Every media represented in the ad file.
        2. Open on-line database works best when each person updates the system with information as soon as it is available.
        3. One main program, many well-normalized files.
        4. History of significant changes:
          • Production.
          • Financial.
      2. Financial:
        1. One main set of files (header and detail).
        2. Many front ends with supporting detail files.
        3. Two months, three amounts.
        4. Interfaces
      3. Cost accounting (data warehouse)
        1. Detail at the department level using May Company rules.
        2. Can also be used for other purposes:
          • Planning
          • Store-level analysis
      4. Add-ons
        1. Productivity
        2. Competitors
        3. Loan room inventory and transactions
        4. Photo studio
  3. May future plans
    1. Filene’s
    2. Uniformity
    3. Best practices
  4. Technology
    1. Explain CFINT
    2. Explain performance of 5250 v. browser-based
    3. Why “web-facing” doesn’t help
    4. Explain V5
      1. BASIC compiler.
        1. Should we convert to C?
        2. Should we convert to Net.Data?
        3. Should we convert to WAS/Java?
        4. Should we look to Wintel?
      2. Can’t save back very far.
      3. InfoPrint server allows output as .pdf files.
    5. Browser-based programming requires VPN or the equivalent for support.
  5. Other things
    1. AxN.
    2. Peggy Southworth labels.
  6. What else?

Some of this has fled my memory. I do remember that CFINT was a program that regulated performance. Prior to version 5 of the operating system the users could allocate priorities for jobs between “interactive” jobs (5250 sessions on terminals or PCs) and “batch” jobs (everything else, including jobs that relied on something between themselves and the operating system, such as a Java server). IBM wanted to show that the Java jobs had good performance. To do so it slowed down all jobs that were running as interactive. Nothing that IBM had previously done was as hated as this tactic.

I also remember the Peggy Southworth labels. Every division was required to create these labels for each print media job in a precisely specified format. We wrote a program for one of the divisions to do this for them.

The notes indicate that Denise and I met with Rob Cole and Mike Henry. I only vaguely remember them. I have a more vivid memory of Lew Allder, who was a Vice President in the IT department. He showed us around the machine room and assured us that the small size of our organization was not an issue with him or anyone else at the May Company. Everyone with whom we talked was very supportive of what we had done and what we were planning for the future.

Don’t take the bridge across the river.

I also remember one incident that occurred when we were driving either from or to Lambert, the St. Louis airport. I made a wrong turn, and we found ourselves on the bridge that goes across the river to East St. Louis, IL. I had no interest in taking a tour of that town. When there was a break in the traffic I jerked the rental car’s steering wheel to the left, made a clean U-turn and headed back to St. Louis. I think that this maneuver shocked Denise, at least a little.

I tried to find information on what became of the May Company employees mentioned in this entry. However, I was not able to find any information on the Internet about most of them. After a good bit of digging I found Dennis Wallace’s LinkedIn page, which is here. In 2022 he appeared to be working for a company in Houston that provides technical assistance to the hospitality industry.

1. All right, I never actually walked to G. Fox’s store in Enfield Square mall, but I could have.

2. The Hecht’s installation is described here.

3. The account of the installation for Foley’s is provided here.

4. The troubled AdDept installation at Filene’s has been documented here.

5. The Lord & Taylor installation is described here.

6. Doug and I made a strong pitch to Debra Edwards at May Ohio, but the division was eliminated before we could close the deal. That “whiff” is described here.

7. I think that Famous-Barr may have already committed to getting AdDept before Doug arrived on the scene, but their decision was probably made because of the May Company’s commitment to the project. The installation at Famous-Barr is described here.