Tag Archives: AdDept

1992-2014 TSI: AdDept Client: Neiman Marcus

Posted on by
2

The store with only two sales per year. Continue reading →

My recollection is that the first inquiry from Neiman Marcus came in early 1992 On the other end of the phone line was the manager of the advertising business office. Although I worked with her pretty closely for a fairly extensive period of time, I don’t remember her name.

She must have responded to a mass mailing that I sent after the installation at Hecht’s was under control. I addressed those letters to advertising directors. So, the advertising director must have given it to her. In our telephone conversation she explained to me how they did things at Neiman’s. I told her that I thought that our system could help her with some of their problems. I then sent her materials about how AdDept worked and tried to relate aspects of AdDept to Neiman’s situation.

She asked us to pay them a visit. I arranged for Sue Comparetto and me fly to Dallas to meet with the potential users and to do a demonstration for them at IBM’s local office. The business office of Neiman’s advertising department was on one of the upper floors of the company’s flagship store on Main Street.

When we arrived there I was surprised to find that the rest of the advertising department would not be involved in the discussion. Although Neiman Marcus was still using the system in 2014, I never spoke with anyone from the rest of the department. They used an advertising agency for most of their advertising, including newspaper ads. In fact, the lady that we were dealing with did not even want the rest of the department to have access to the system. She really just wanted a system to keep track of expenses and co-op.

The stores only had two sales per year— First Call in February and Last Call in August, or maybe the other way around. They used the traditional 4-5-4 retail calendar (described here) with which we were already familiar, but Neiman’s first month was August, not February.

My AdDept demo needed a major change of emphasis. I usually emphasized that the main reason for a centralized database was for everyone to take advantage of work done by others. She did not want the others involved at all. Also, the most impressive part of the demo was how quickly a newspaper ad could be scheduled. She had little interest in that task, which was the agency’s responsibility. Nevertheless, the reaction to what I showed was quite positive.

After the demo Sue and I rented a car and drove to Austin for a little R&R with Marlene Soul, one of her friends from high school. She was, if you can believe it, a consultant in feng shui, which she claimed was mostly about being organized.

Marlene took us to a comedy club in downtown Austin, which was definitely a swinging place. I also remember sitting around at her house while she tortured her cat with a long flexible semi-rigid wire that ended with a feather. The slightest twitch made the feather jump and fly.

I made a note to myself to buy one of these when I arrived back in New England so that I could use it to drive my cantankerous cat Woodrow crazy. I did, and it did. He had to hide under the couch so that he could not see it.

The following morning we went birding with Marlene and a group that met every Saturday morning. I was exceptionally bad at it. I have had poor vision since the third grate, and I have always been notoriously bad at finding things anywhere. However, this gathering did spark enough interest in me to become a little more knowledgeable in ornithology.

Upon returning to the office I spent a couple of days putting together a detailed proposal for Neiman Marcus. It did not include as much custom programming as usual. The main objective was for the AS/400 to be able to generate a file to be used by the expense payable system on the mainframe.

The business office manager accepted the proposal a short time after receiving it. I sent her a software contract, which she signed. I then ordered the hardware and system software from IBM and we received an installation date. I knew that we would not have the interface done by then, but we would need some data to test the interface anyway, and there would be no data on day one.

From our perspective this was by far the easiest sale that we had ever had, and the installation, which took place in August of 1992, also went rather smoothly. I had to spend quite a bit of time fine-tuning the coding for the incredibly complicated interface with their corporate financial system. I did not care. I loved to do that kind of work because, once it was in place, the chances of them scrapping the system were minuscule1.

People in the IT department2, however, were furious that the lady from the advertising business office had signed a contract with TSI without consulting them. They were nice enough to me, and they were quite cooperative about establishing the interface between the two systems. However, her career at Neiman Marcus did not last long after AdDept was installed and working smoothly.

The key to the success of the installation was effecting the financial interface. It involved a considerable amount of two-way communication between AdDept and the corporate mainframe. Gary Beberman, who had been TSI’s liaison for the first AdDept installation at Macy’s East (described here), was extremely effective as the go-between for TSI and the mainframe programmers.

I found this list of the steps involved in a document written in 2000:

1. A list of general ledger accounts is downloaded. AdDept’s general ledger account table is updated.
2.A list of departments with the accompanying hierarchy is downloaded. The department table and the rest of the hierarchy is updated.
3. Expenses are uploaded to the accounts payable system. The accounts payable system feeds the general ledger.
4. Co-op transactions are also uploaded to the accounts payable system. The accounts payable system feeds the general ledger.
5. General ledger transactions in the advertising accounts are downloaded at the end of the month. An AdDept program compares the downloaded transactions with the uploaded transactions. A list of exceptions is printed. Additional transactions are placed in a batch file, which can be converted to real AdDept transactions.

The walk down to Dealey Plaza is an easy one.

I made a fairly large number of visits to Dallas during the installation period. Thereafter, a few years would sometime go by between requests for visits. Here are a few memories that I have maintained of those trips.

Neiman’s flagship store at Christmas time.
  • In the nineties I spent a lot of time in the American Airlines section of the DFW airport. My favorite restaurant there was a Mexican cantina.
  • I also spent a lot of in autos driving between the airport and either Dallas or Fort Worth, where TSI had several clients. Sometimes I took a cab; usually I rented a car from Avis.
  • On my first solo trip to Neiman’s I was a little late and a little lost. I crossed Main Street in the middle of the street. A cop stopped me with every intention of giving me a ticket for jaywalking. I was polite, however, and he let me go with only a warning.
  • One of my early visits was in December during the running of the Dallas Marathon. I went out for a jog and watched some of the real runners near the finish line. This must have been on a Saturday or a Sunday.
  • The temperature on that day was around 30. I was wearing stretch leggings, shorts, a tee shirt, and a nylon jacket. Most of the real runners were wearing shorts and singlets. At Neiman’s on Monday the business manager, who was a originally from Pittsburgh, confided to me that she and her husband were concerned about whether the cold weather might harm their child if they let her play outside. She admitted that no one in Pittsburgh would have thought twice about their kids being out for hours in such weather.
  • On another occasion I walked to the State Fair grounds on a Friday evening. I was surprised to discover thousands of people celebrating Juneteenth. I had never heard of this event before.
  • One summer evening after working at Neiman’s I took a stroll down to Dealey Plaza, which is the the location of the ramp to I-35. I wanted to conduct a personal investigation of the interchange, the “grassy knoll”, the Texas Book Depository (which had been converted into a museum), and the other locations associated with the assassination. A few minutes earlier the fatal presidential motorcade had passed right by Neiman’s flagship store, which is .6 miles from the plaza.
  • One day after the system was operational the business office manager drove me to lunch for some authentic Texas barbecue. I cannot say that I was very impressed. I have never understood the idea of cooking all of the flavor out of meat just so it could be coated with barbecue sauce.
  • Neiman’s made a big deal out of Christmas. Not only did they publish their famous catalog with one outrageous gift idea, but they also sponsored an evening in which their VIP clients could shop without dealing with the riffraff. The store open that evening only to those who were sent an invitation. Each was assigned an employee to tour the store with them. I am not sure what the employees were expected to do. I looked for members of the Ewing family, but I did not see any.
  • On my visit on September 9, 2000, the temperature reached 109°. It was also the thirty-fifth day in a row with no rain. That was the day that I understood why the streets in Texas are almost all concrete, as opposed to asphalt. Anything that was paved with asphalt turned gooey when the temperature got that high.

I did not actually work with most of the subsequent Neiman’s employees enough to burn in lasting memories. I did find some notes that provided me with some information on some of them;

Jeff Netzer.
  • I was surprised to discover that many of the successors to the female business office manager mentioned above were Aggies, that is, graduates of Texas A&M. The first was Jeff Netzer3, who worked at Neiman’s from 1996-1999. He called TSI a few years later when he was employed at Sewell Automotive Company. I saw Jeff there when they invited me to assess the possibility of us designing a system for this company. This experience is described here.
  • The second Aggie was named Brian Harvey4. He worked in the advertising department from 1998-2000. I met him in 2000, but I don’t remember him.
  • After Brian’s departure the advertising business office was run by Alea Montez. I remember that she called the office for support several times. I don’t think that I ever met her.
  • The last Aggie was Brian Davis5, whose title at Neiman’s was Media Analyst. I don’t remember him at all. I don’t think that I ever met him in person.
  • A striking omission in this list is everyone in any other area of advertising. I never succeeded in interesting anyone in even considering what TSI had done for so many others in similar positions.
  • I had quite a bit of contact with a number of IT people at Neiman’s. I met a few in person, but I don’t remember any names.
  • In the 2000’s Neiman’s hired an AS/400 consultant to help them with connectivity and to upgrade their system. We had a good relationship with him, but I don’t remember his name.

1. In fact, the AdDept installation at Neiman’s lasted longer than that of any other client. Part of the explanation for that was that Neiman’s was one of the few AdDept clients that was not bought out by another company. When we closed TSI’s doors for the last time in 2014, Neiman’s was still using AdDept. For all that I know, it may have continued after that.

2 The IT people worked in a building in Las Colinas, a few miles from the flagship store in downtown Dallas. I went there a couple of times and met a few people there.

3. Jeff Netzer’s LinkedIn page is here.

4. Brian Harvey’s LinkedIn page is here.

5. Brian Davis’s LinkedIn page is here.

1993-1996 TSI: AdDept-Burdines Interface

Posted on by
2

The proverbial brass ring? Continue reading →

Even before I became a professional software developer, my friends and acquaintances often approached me with their ideas for computer programs. It started in the Army with Doc Malloy’s idea for a tennis game, continued through graduate school, and was nearly ever-present in my business life. It seemed peculiar to me that so many people seemed to imagine that I had a skill that they lacked but no idea how best to employ it.

I have a great idea for a software project!

In point of fact, the limiting factor in software development was almost always money. A new software system required a substantial investment to cover development and testing costs, as well as marketing expenses. Very seldom did the people who propose these project give any thought to helping to finance them. At least they never volunteered information about having a secret source of funds. They evidently thought that they should share in the imaginary profits because they provided the original idea. I sometimes told them, “ideas are a dime a dozen. Implementation is everything, and marketing brings it home.”

I had plenty of ideas of my own. A few of them, such as the idea of running several simultaneous “threads” for the cost accounting programs generated a bit of revenue for TSI. One of my ideas, the use of a butterfly-shaped website for insertion orders and emails for notifications, resulted in a very profitable product for TSI, AxN. The genesis of its design and the marketing concept that turned it into a financial winner is described here.

TSI’s clients also had a large number of ideas for programming, but they seldom expected us to work pro bono. I spent many hours researching and writing quotes for changes to our systems requested by our clients. I doubt that a month went by in which I failed to produce produce ten or twenty of them. I considered my most important responsibility at TSI to be providing a clear description of each requested project and assigning an appropriate cost figure.

Gilbert’s LinkedIn Photo.

Very seldom did someone approach me with a project that included funding. I can think of three times in forty years. Only one of these concerned software that we had already designed and coded. The person making the proposal was Gilbert Lorenzo1, who was one of the top bosses in the advertising department at Burdines, the Florida division of Federated Department Stores.

Gilbert telephoned TSI’s office in the early nineties. He had received one of our first mailings about AdDept, our administrative system for large retail advertising departments. He said that he would be in New England to meet with some people at Camex2, the company based in Boston that marketed a system for digitally producing page layouts for newspapers and large advertisers. He requested us to show him a demonstration of the AdDept system.

Most of this huge structure served IBM’s business partners.

We reserved some time in a demonstration room at the elegant IBM office in Waltham, MA. We had a relationship with this office, but we had never done an AdDept demo there before. I arrived there as early as I could to get the system set up for my presentation. It was a very nice facility that always impressed potential clients.

The AdDept system in those days was fundamentally sound, but many “bells and whistles” were added on in the subsequent decade. In almost every case they were suggested by and paid for by one AdDept client or another.

The most impressive thing about the demos in the early years was the speed with which the programs moved from one screen to the next. Once the tables were set up, a user could define all aspects of a new ad to run in dozens of papers in just a minute or so. This always generated the biggest “Wow!”

In our discussion after the meeting Gilbert said that he liked what he saw. He might have even said that he wanted to buy the system. However, I did not hear from him again for several years. This was consistent with what always seemed to happen with Federated’s divisions, a phenomenon that is explored in more detail here.

Meanwhile Burdines was—unbeknownst to me—experiencing explosive growth. In 1991 alone the number of stores increased from twenty-seven to fifty-eight through the assimilation of two Federated divisions— the Maas Brothers and Jordan Marsh stores in Florida. More stores were added throughout the rest of the nineties. By the end of the decade Burdines dominated the department store market throughout the entire state.

The purpose of Gilbert’s second contact with TSI was to invite me to Huntsville, AL, the home of a software company with which he was working at the time. I don’t remember the name of the company. I do recall that two of the team assigned to this project formerly worked as software developers at Camex before DuPont purchased the company and changed its focus. One of them was Mike Rafferty3, whom I had met at Camex’s headquarters when our common customers had requested that an interface should be constructed between the two systems, a project that was described here.

The software company in Huntsville had a very impressive headquarters. As I understood it, the company’s primary customers were NASA and companies that worked with NASA. That was de rigueur in Huntsville.

Gilbert explained that he was working with Mike and the others to develop a comprehensive software system for the advertising department at Burdines, and he hoped and expected that the other Federated divisions would also use it. He wanted TSI (or at least me) to participate in the project, and he insisted that he had the funding for it.

Mike described their approach to the project. They intended to use a home-grown database that resided on a server, but most of the programs would reside on the individual “clients”—PC’s or Macs. When I told him that TSI’s programs were written in BASIC, he suggested that we consider converting them to use Microsoft’s Visual Basic.

Most of the discussion concerned the scope of the project. They were interested in integrating something like AdDept into the unitary structure that they envisioned. No one addressed how TSI would be integrated into the development process. Maybe they expected me to fill in some of the details or to volunteer to research how difficult it would be. Maybe they knew that we seldom backed down from a project just because it was difficult.

The atmosphere was cordial and positive. I remember that we all went out to lunch together, and I ordered a Monte Cristo sandwich. Nevertheless, this meeting made me very uncomfortable. On the one hand, the prospect of installing a version of the AdDept system into all the remaining Federated divisions was way beyond tantalizing. It would be a dream come true. What they suggested would undoubtedly a big job, but TSI had a talented group of programmers who were quite familiar with both the subject matter, and the way that I liked to approach big challenges.

On the other hand, from my perspective the way that this project was described was adorned with “red flags”.

  • I had already researched the possibility of using Visual Basic. It might have been possible to convert some of the programs, but there were no tools designed to help. It would certainly have taken TSI several years to produce a workable system. We would be discarding all of the tools that we used in favor or ones that we had never used and, to my knowledge, had never been used by anyone in a data-intensive situation. TSI’s programmers would certainly need a lot of training. We would probably need to hire skilled employees or at least consultants to achieve any degree of efficiency.
  • Their whole architecture was different from what we used. In the AdDept system the data and all the programs resided on the AS/400 server. The “client-server” approach that they proposed located the data on a server, but the program were all distributed to the PC and Mac clients. To me this sounded like an administrative nightmare. All changes—including emergency fixes—must be installed on all of the clients.
  • I considered the AS/400 integral to AdDept’s success, and so did our customers. The operating system code was built on the database rather than the other way around. That meant that the system itself could never be used for programs with the the huge requirements for memory, disk, and processing speed that design and creation of advertising layouts required. The AS/400 was definitely not designed for that. However, it was ideal for administrative systems like AdDept. It competently handled so many problems with which all-purpose operating systems constantly struggled.
  • I trusted IBM and the AS/400’s database. I knew how to get the latter to function efficiently, and IBM’s support was unmatched in the industry. The idea of converting to a home-grown database seemed just preposterous.
  • By the time of the meeting in Huntsville TSI had finally turned the corner. The AdDept product had a solid client base and a good number of prospects outside of Federated. How could we continue to pursue AdDept development for those companies—which was relatively certain to generate revenue and good will—while devoting a great deal of time and attention to the massive Federated project? It did not seem possible to me.
  • Gilbert had said that he had funding, but he never provided any details about who, how, or how much.

Something about the project sounded fishy to me. They were interested in my participation, but they never specified how. Did they want to buy TSI? No one mentioned anything like that. Did they want to hire some or all of us? Did they just want me to consult with them as to the system design? Or was there something else?

At the end of the meeting, Mike asked me what format TSI preferred for exchange of information. Both of the programmers were very surprised when I told them that our offices were connected to all of the clients’ AS/400s via phone lines. We used the AS/400’s built-in messaging and word processing. No one had ever asked us to communicate outside of that.4 I told them that TSI’s employees had PC’s, and the company had a few modems, but we mostly used the PC’s as terminals to the AS/400.

The group did not come to any agreement about how the project was to proceed. I had an impression that they thought that I (who was well into my fifth decade on the planet) was a fossil. I, on the other hand, thought that they, who had dealt almost exclusively with production of ads for newspapers, dramatically underestimated the difficulty of designing a single multi-user database that was capable of handling all aspects of scheduling and managing the financial aspects of all media. The planning and cost accounting modules were even more challenging.

After the meeting I had a little bit of private time with one of the principals of the software company. He asked me what I thought about the project. I told him that it was interesting, but I did not see the ROI (return on investment) for combining the two systems. I remember his exact words. “ROI. Oh, yeah, where’s the ROI?”

I did not hear from any of them again, and I did not press for inclusion in their project. In all honesty I had too many other things demanding my attention. After a year or two I sometimes wondered whether Gilbert had abandoned the project or had gone ahead with it. The answer, it turned out, was somewhere in between. I spent no time searching for information about the project, but little hints turned up occasionally.

Our liaison at Lord & Taylor, Tom Caputo, described to me his experience interviewing for a job in the advertising department at Bloomingdale’s, a Federated division in New York City. He asked the people there about their computer system. They showed him boxes that contained the software for the FedAd system, which Federated had sent them and told them to use. The people at Bloomies had never unsealed the boxes.

When I installed the AdDept system at Macy’s South5 in December of 2005, TSI’s liaison there was Amy Diehl. Her official title was “FedAd Coordinator.” By then I knew that FedAd was the culmination of the project begun by Gilbert Lorenzo more than a decade earlier.

I soon learned that the advertising department at Macy’s South was not actually using the FedAd system at all because the programmers had admitted that it could not handle the department’s planning process. Instead they had been using parts of a previous version called Assets for a few tasks. I was astounded to learn that the Assets system used a Microsoft Access database. They had sent a boy to do a man’s job! Federated Systems Group no longer supported it.

Later we heard that Macy’s East was using the FedAd system, which by then had been given a different name. At the time its advertising department was still using the Loan Room system that TSI had written and implemented for them in the early nineties. That meant that for years the details of every ad were being entered into at least two separate systems.

I even quoted a bizarre request from Macy’s systems people to write an interface between their system and AxN. I provided them with a quote, but nothing came of it.

In all of that time—more than two decades—I never heard anyone say anything good about FedAd. As far as I know it generated a great deal of expense and not a penny of revenue for the company. I only knew of one department that used it. TSI, in contrast, sold and installed thirty-five AdDept systems, each of which was customized to the needs of the individual departments.

On the other hand, I might have been able to carve out a career as the guru for Macy’s concerning administrative software for advertising. That would have certainly been something to crow about. After all, when the game was finally ended, Macy’s had all the marbles.

I doubt that they would have let me—and whatever portion of TSI was involved—participate from Enfield or East Windsor, and I doubt that they would have let us continue to perform or oversee work for their competitors. They might have allowed me to program for the AS/400—I saw several of them at the FSG data center in the Atlanta area. However, it was more likely the Gilbert would have required everyone in the process to use the same database. He seemed to be calling all the shots.

So, I probably would have had to sell my soul to Macy’s. I might have made a lot of money, but I think that I would have been miserable. Almost everyone in my acquaintance who had worked for one of our clients and then worked for Macy’s or a Federated division quit in the first few years and was openly bitter about the experience.

Finally, I must add that I suspect that there was a good possibility that the invitation to Huntsville was just a ruse to get me to expose the totality of the AdDept system to people who might be able to replicate it.

Epilogue: While researching the blog entry for TSI’s relationship with Federated Department Stores (posted here), I discovered that Val Walser’s LinkedIn page prominently features how she “directed development of a sophisticated, integrated software product” in the division run from Seattle. It must be referring to the system that Gilbert and Mike envisioned so many years earlier. I never heard anyone mention any other such system.

1. For some reason Gilbert Lorenzo has two LinkedIn pages. They are available here and here.

2. The Camex system was used by both of the first two AdDept users, Macy’s East, and the P.A. Bergner Co.

3. Mike Rafferty’s LinkedIn page is here. It did not provide much information about him when I discovered it in 2022.

4. Keep in mind that the Internet was in its infancy. At that time Microsoft had not yet completed its domination of the word processing and spreadsheet markets. Technical people used “message boards”, not email, for communication. AOL did not hit the web until 1997.

5. The installation at Macy’s South is described in detail here.

1989-1993 TSI: AdDept-Camex Interface

Posted on by
1

An exciting new feature. Continue reading →

The first time that I ever heard the word “Camex” was when I was researching the requirements for the first installation of TSI’s AdDept system1 at Macy’s East2. One of the job titles that Macy’s used for employees assigned to production of a newspaper ad was “Camex operator”. I asked Alan Spett, a vice president at Macy’s who was our principal contact during this period, what a Camex was. Alan told me that Camex was a company in Boston that had designed and implemented software and networking for workstations from Sun Microsystems. The workstations were used by many newspapers and some of the largest newspaper advertisers to help with the design of pages to appear in newspapers.

I later did a little research on the company. It was founded in 1974 by George White and a partner whose name I never discovered. The first customer was the Boston Globe. Once that installation stabilized, the company grew dramatically by selling expensive systems (roughly $2 million each) to newspapers around the country and then to large retailers.

In 1989 the company was sold to DuPont, the chemical giant. George White stayed with the company until 1993.

Camex had a booth near TSI’s at the Retail Advertising Conference in Chicago that Tom Moran3 and I attended in 1991 or 1992. Our booth was the smallest allowed. Camex’s booth, which was near ours, was perhaps ten times larger. They must have brought twenty salesmen and lots of workstations and network servers.

Alan may have voiced an interest in creating an interface between AdDept and Camex in those early days. However, it was included in neither the original installation nor the first set of enhancements.

Dan Stroman, TSI’s contact for the AdDept installation at P.A. Bergner & Co.4, told me that Bergner’s wanted to implement an interface between AdDept and Burgner’s Camex computers. I told Dan that Macy’s might also be interested in such an interface, and I gave him Alan’s telephone number. The two of them agreed to make a joint project of the interface.

My recollection of the details is fuzzy. I think that AdDept was supposed to create a file that contained all relevant production job information for jobs in specified ad types that had not yet been released. Camex would create files for AdDept that indicated job steps had been completed on those jobs.

There were many issues to resolve.

  • What was the naming convention for jobs on Camex? That field would need to be added to the AdDept database.
  • Should AdDept require that each Camex job name be unique? If not, will uniqueness be enforced at the time of the interface? If not, how will Camex handle two jobs with the same name?
  • Should the source for the interface file from AdDept be the live database or the history records?
  • Are history records for the interface itself necessary?
  • How should AdDept tell Camex about jobs that have been killed?
  • What if the size or shape of the ad had changed?
  • And so on.

There were also technical details about the nature of the interface files. IBM’s PC Support program for the AS/400 could be used to transfer data to and from a PC, but it probably would not work with a Sun workstation. So, a PC would probably be necessary between the Sun Workstation and the AS/400.

My recollection is that two meetings were held at Camex’s headquarters at 75 Kneeland St. in Boston. The first was mostly just to get acquainted and set an agenda. I have no notes from these meetings, and I don’t remember anyone’s name. I seem to remember that Alan may have attended. Sue Comparetto and I drove up to Boston. Camex’s office was very close to Chinatown, and the Camex people treated us to lunch at one of the nearby Chinese restaurants. My other vivid recollection is of my wonder at what Camex had accomplished in a fairly short time.

I am pretty sure that Dan attended the second meeting. Sue and I definitely drove up from Enfield. This meeting was disrupted by a fire alarm. Everyone was asked to abandon the building and stand around in a nearby parking lot. It does not take much for me to be cold, and I was absolutely freezing. I am sure that we were outside for at least an hour. We finally did get to go inside for an hour or two. My recollection is that we made a little progress, but at the end I still did not know what data Camex was planning to send to AdDept. This was because the people with whom we were talking knew very little about the database portion of their system, and the database programmer was not available.

I wrote up a programming quotation for the portion of the interface that AdDept would initiate. I submitted the quote to Dan and Alan. They both approved it. I even started work on it.

Then a very strange thing happened. The person who served as the client liaison at Camex called Dan and told him that Camex had decided not to participate in the interface. They also volunteered to refund deposits that Bergner’s had made for additional equipment.

We got paid for the work that we did—luckily avoiding the bankruptcies of both Macy’s and Bergner’s. Shortly thereafter DuPont split Camex up into pieces and spun them off as separate companies. Camex did not last long after that.

I cannot remember where this happened, but I overheard someone at a large retailer talking with their rep from Camex. The rep said that Camex no longer recommended the Sun workstations. Instead they recommended that advertisers just buy Macintoshes and off-the-shelf software. I was both dumbstruck and disappointed. I had envisioned our relationship with Camex as a possible entrée to many excellent AdDept prospects. Sic transit gloria mundi.

The episode has an epilogue. A few years later I had a meeting in in Mobile AL with some programmers who previously worked at Camex and Gilbert Lorenzo, the advertising director at Burdines department store. That meeting is described here.

1. The design of the AdDept system is described in some detail here.

2. The AdDept installation at Macy’s East is described here.

3. Tom’s time at TSI, including our time at the RAC, is described here.

4. The ups and downs of the AdDept installation at Bergner’s are detailed here.

1988-2014 TSI: AdDept: System Structure

Posted on by
2

A complicated system. Continue reading →

People who have not worked in retail advertising will probably have trouble understanding this entry. Nevertheless, because the AdDept system was the focus of my life for so many years, I feel obliged to document as much of its structure as I can remember. It did not occur to me that I might want to undertake such a task until very recently. Consequently, when I closed down TSI in 2014 I discarded almost all of the system’s documentation. The few computer files that I have subsequently found are mostly PageMaker documents. I don’t have that software on my computer, and the files are too large for the services that will convert them to pdf files online. So, I must rely on my memory, which is not as reliable as it once was.

AdDept was designed for and implemented in OS/400, the operating system of the AS/400 and its follow-on hardware. Some of the important and unique features of this operating system are described here. Every line of code that we wrote in 1988 still worked in 2014, and I have no reason to expect the code to stop working any time soon.

All programs were originally written in BASIC. Around the turn of the century IBM stopped supporting BASIC, but TSI was authorized to install the product (a compiler, and interpreters of both BASIC commands and BASIC procedures) on any system that use our software. This only caused one major problem, which is documented here. However, Denise Bessette did not like this arrangement and undertook to convert the programs to ILE RPG. I never appreciated the value of that idea, and I never took the time to learn that language, which is supported on no other system.

All data tables and the major programs in AdDept began with the letter D, which stood for department. This was for TSI’s benefit. The ad agency system used a similar structure, but no files or programs began with D. The second letter in AdDept tables was usually A, I, M, or P, which stood for accounting, (loan room) inventory, media, and production. Programs that were used for cleanup, copying, and other miscellaneous tasks began with DX.

All AdDept programs were stored in the same library1. It was usually named TSIPROG. The data was in a library named TSIDATA. A few clients had additional data libraries for additional companies. At these installations we created a separate library called COMMON or TSIDATACOM to hold the tables that were used for both companies. For example, both companies probably used the same ad types and expense classes (major media). The tables used by both were moved from TSIDATA to the common library. A new data library was created for the data files for the second company. In the beginning it contained empty copies of all of the remaining files in TSIDATA.

No two instances of AdDept were the same, but each had the same TSIPROG library. The settings for each installation were designated in two ways: 1) A set of empty one-byte files, the existence of which activated certain features; 2) a file called DASPECS that contained a very large number of switches, descriptions, and system values. The program to maintain the system values was not on a menu, and users were not allowed to run it.

Everyone needed a user ID to sign on to the system. Those connecting through a network could have any number of simultaneous sessions open.

AdDept’s user table, which was also on no menu and could be run only by the AdDept liaison, limited the programs to which the user had access. If the same employee worked with two different data libraries, a second user ID was required. The two user ID’s would have different library lists.This arrangement may sound cumbersome to people who are used to managing hundreds or even thousands of nested folders, but it did not seem strange to the users of a multi-user system. Furthermore, it was absolutely critical that changes not be made on files in the wrong library. All TSI menus displayed the name of the data library to help eliminate confusion.

The retail calendar was accommodated by the season table. The key was a three-digit number. The first two digits were the fiscal year. The third digit was 0, 1, or 2. 0 meant that a standard twelve-month calendar was used. 1 and 2 were used for 4-5-4 retail calendars, which are described here. This table contained the name of the season, the starting date, and the number of weeks in the season.

Ads were classified by three separate codes:

  1. The one-digit insertion code determined which set of screens was used for data entry. This was a fixed set, but more codes could be added for additional media.
  2. The one-digit expense class identified how the ads were categorized for accounting purposes. Later a sub-class code (blank default) was added for one client.
  3. The two-digit ad type was specified when an ad was created. This table held the insertion code and expense class. It also had a binary field to identify whether color charges were applicable.

Media vehicles, such as newspapers, magazines, and broadcast stations and networks (called pubs in AdDept), were identified by a five character codes combined with a two-digit number (usually 0). For newspapers at least one number was reserved for inserts (usually 10). The users specified the days on which the paper published, whether it was AM, PM, or a combo2 and the paper’s depth (maximum number of inches vertically on a page). For direct mail the pubs were usually geographic markets.

Stores could be identified by a five-digit number.

Every pub had a list of stores that were associated with it. There was also a date-sensitive pub-store allocation table that contained the percentages allocated to each store associated with the pub. The key to this table included an effective date. Less than half the AdDept retailers allocated costs to stores, but the ability to do so was very important to those that did.

AdDept users almost never paid the published rates.

Rates for ROP and inserts were date-sensitive. For ROP separate rates could be entered for black-and-white and several different color choices. There were also tables for linage-based discounts and premiums for things like special positioning such as “back of main”—the last page on the first section of a paper. For inserts a table of usual quantities (thousands of copies) could be created, with rates for each.

The system needed to be able to find the right rate to apply whenever an ad was changed or moved. Costs could also be recalculated en masse when a new contract had been negotiated. These were attractive features.

Probably the best idea that I had when designing the system was to allow the definition of pub groups (identified by five-character codes) to specify sets of pubs in which the same ads often ran. Clients could have hundreds of these or none. When a new ad was created, one pub group could be specified. A schedule could automatically be created with all the pubs in the group.

The hierarchy of participating merchants had five levels in AdDept. The lowest (most detailed) was the department. The system called the other four ADMGP, GRPVP, SENVP, and GRSEN to match Macy’s East’s designations. Most retailers had only two: DMM’s and GMM’s. The May company used “CCN numbers” to group related departments. For each level each client determined the descriptions used on screens and reports.

Employees were identified by three-character codes. Employees could be assigned to production jobs. So, an employee could see a list of all of his open assignments.

The traffic system allowed specification of a code for each production job that determined the job’s production schedule. So, black-and-white ROP ads might have a three-week production schedule with eight steps. The number of days for each step could be specified. Then the system would count backwards from the release date to build a schedule of due dates that accounted for weekends and holidays. The completion dates of each could also be entered (an X meant “today”).

This seemed important to several clients, and we built it precisely the way it was described to us. However, the production employees did not like it. For one thing, most of them used Macs for working on the ads, and they found a text-based system clumsy. I don’t honestly think that they would have liked it much better with a GUI (graphical user interface) as the front end.

The accounting tables were similar to those in the GrandAd System (described here) or any other system. They were designed to be consistent with whatever system was used by the accounting department, but AdDept users did not need to memorize the very long codes that were common in those systems. In AdDept the main entity was the sub-account, which was identified by a five-character code. One corporate G/L account was specified for each sub-account.

The vendor table also had a five-character key. The corporate vendor number was specified there. This table was used for merchandise, media, production, and other vendors.

Categories of production costs were identified by three-digit codes, just as in the GrandAd system.

The Ad Files

The system had one major header file for ads of all types and a number of lists that were associated with it. The ads file3 was identified by the season, a five-digit ad number (usually generated by the system using client-specific rules), and a one character version code (usually blank). The ad number could either be entered or generated by the system. Data entry began with the specification of the run date and ad type. A large amount of information was deduced from those two values. The headline and size4 of the ad were then entered on the header screen, which also contained many other fields.

The second step for ads of all types was the media schedule. If the pub group was accurate, nothing had to be entered here for ROP and inserts. For direct mail the quantities by market were entered.

The third step was the list of participants with percentages and co-op commitments.

Expected production costs could either be entered as one lump sum or detailed by category.

Audit Trails

History records were created for any activity that affected planned, committed, or actual costs or income. Reports and screens were written for viewing them. A few custom reports were also written for clients.

Planning

New ads were ordinarily assigned a status of P, which stood for “planned”. When the plan was completely approved, a program could be run to change the status of all status P ads to A (active). At the same time records of the detail of the costs of those ads at that time were recorded in separate files named DAPLAN (by department or group) and DAPLANST (by store).

Changes could still be made to any aspect of any ad, of course. Those values were considered “committed”. The actual costs were based on the measurements and the invoices from the media and production vendors. Actual co-op was based on the “claims” that had been processed.

In subsequent years several AdDept users let the system build the entire schedule based on the previous year. Thus season 951 could be built based on the ads run in 941. This process was called “anniversarying”.

Cost Accounting

What I called “cost accounting” was commonly called BI later.

Most advertising departments were keenly interested in comparing planned, committed, and actual costs by merchant or by store. AdDept had programs that would create detailed records every night by store and/or merchant for all ads in the current season. The merchant records were stored in DACOMMD (committed) and DAPANDL (actual). The records by store were in DACMDST and DAACTST.

Numerous reports were written to allow comparison of planned, committed, and actual costs and income (from co-op). Some users also queried these files on a regular basis using IBM’s Query/400 product.

Interfaces

Broadcast ads could be fed into the system from Doner, the May Company’s ad agency, and from Media Management + files created either internally or by an agency. There may have been one or two others of these.

A couple of clients used ad agencies for their newspaper ads. TSI constructed interfaces to receive the ad schedules from the papers.

Several interfaces were created to send files to feed corporate Accounts Payable and General Ledger systems.

Sales at the department level could be downloaded from the mainframe. Customized reports helped gauge the effectiveness of ads in comparison with the costs.

Backup

It was easy to schedule a backup nightly and to schedule the cost accounting programs to start when the backup was done. The backup would not save files that had record locks. Any time that a record was read from a program that could update that file (as often occurred), the record was locked to prevent one user from accidentally overwriting the work of another. It was sometimes difficult to persuade users either to make sure that everyone had signed off every night or to shut down the interactive subsystem before backing up and restarting it later.

TSI recognized this problem and warned the users about the possibility of lost data if files were not backed up routinely and correctly. We even offered (for a modest fee) to check their backups every day and notify them by telephone if the backup for the previous nights did not complete correctly. Only one client took advantage of this service.

The failure to check backups resulted in one ugly mess that was described here.

Cleanup

By the standards of the day the cost accounting and history files often became extremely large. A menu of programs that permanently deleted records from old seasons was provided.

Other Modules

The Loan Room inventory system was successfully used by Macy’s East for approximately twenty years.

A Photo Shoots system was also designed for Macy’s East, but it was never implemented. I don’t remember why they lost interest in managing the activities of their studio. The location of the studio in Newark may have been a factor.

Many modules were developed for Belk. One that I remember calculated the store’s use tax liability for direct mail pieces for each jurisdiction.

Saks Inc. in 1999 wanted TSI to design a very complicated system for collecting data from the systems of each of its divisions and, eventually, to produce reports that compared divisions. I was very happy that nothing came of this idea.

A special module was created for Radio Shack to manage its advertisements in magazines.

I suspect that there must have been a dozen more of these modules that I cannot recall. We delivered hundreds of custom programs over the years and quoted a similar number that were never approved.

AdDept was a fabulous system. Because it contained so many features, it was somewhat difficult to demo. The screens and most of the reports were ugly. Nevertheless, as soon as prospective clients understood its potential, it was easy to sell to anyone with a budget.

Unfortunately by the time of the Bush-era Great Recession in 2008, Tarot card readings for most major retailers—especially the ones that did a lot of advertising—began with the thirteenth trump card: Death.

1. “Libraries” were a type of object on the AS/400. They were places to store other objects in the same way that folders or directories are used on PC’s. However, it was not possible to build a “tree” of libraries. All other libraries resided in the QUSR library.

2. Yes, a few papers still published two editions per day in the nineties.

3. As far as the OS/400 was concerned, DMADS, the ads file, and the files that contained all of the lists were equivalent to the tables. However, TSI’s organization and documentation drew a useful distinction between the relatively stable tables that were defined at the beginning of the installation and the much more volatile ad files and transaction files.

4. The size for ROP ads was entered in columns and inches. A full-page broadsheet ad was entered as 6×21. The program knew to adjust the inches to match the paper’s depth. The size for inserts was entered in terms of thousands of copies. The size for broadcast ads was the length of the spot in seconds, usually 15 or 30.

1994-2014 TSI: AdDept Client: Gottschalks

Posted on by
1

Independent chain of department stores in Fresno CA. Continue reading →

In the Model T days the name still had the apostrophe.

Doug Pease, TSI’s Marketing Director who was introduced here, took the phone call from someone in the IT department at Gottschalks (never an apostrophe) in 1994. Gottschalks was an independent chain of department stores based in Fresno, CA. I am not sure how the people in the IT department had heard about TSI. We had previously had only incidental contact with the Advertising Director there. Since they seemed like an ideal candidate for the AdDept system, I quickly agreed to talk with them in person.

The only reasonable way to get to Fresno was by way of LAX. Sometimes I drove (3+ hours). Sometimes I took the short flight.

Doug and I flew out to Fresno on a Saturday to make a presentation and gather specs about their requirements. On Sunday we decided to drive up to Carmel by the Bay and then drive down Highway 1 along the coast. This was a very pleasant trip for me, but, as I described here, Doug enjoyed it a lot less than I did.

The presentation and demo in Fresno seemed to go well, but almost no one from advertising except Robert Guinn1, the manager of the Advertising Business Office, attended. At some point during that first visit Doug and I were also introduced to the president of Gottschalks. He made the startling claim that he would make sure that the other members of the Frederick Atkins2 group would also purchase AdDept3.

Shortly thereafter a contract was signed, and a small AS/400 was ordered.

In December of 1994 I flew back to Fresno and installed AdDept on an AS/400 that the company had purchased from IBM. The machine was kept in the data center. That room had tight security, and it was always very cold, at least from my perspective. Because it was December, I had my overcoat with me. The only place that I wore it was in the data center.

Gottschalks’ headquarters was several miles north of downtown Fresno.

Gottschalks recommended that I stay at the DoubleTree hotel in downtown Fresno. It was right next to the casino4. The entire downtown area, aside from the casino, was pretty much dead by the mid-nineties. I did not like staying at that hotel. Fortunately, it was easy to persuade Gottschalks to let me stay somewhere on the north side of town that was both cheaper and closer to the company’s headquarters at 7 River Park Place East.

The primary purpose of the installation was not to improve or make more efficient Gottschalks’ advertising. Its main use was to keep better track of the money spent by the department. Here is what I wrote in 2000:

The liaison is now and always has been an accountant. The advertising department has shown very little interest in using the system. Their opinion is that the system was forced down their throats. This opinion is accurate. The accounting department and the IS department purchased the system in order to hold the advertising people’s feet to the fire.

On the other hand, there may be an opportunity here. Most of the people involved at the time of the installation have moved on. If contact is made with the new people, we may be able to sell them on efficiencies to be derived from using AdDept for scheduling.

Shortly after I wrote this evaluation Ernie Escobedo5, who succeeded Robert as TSI’s primary contact, arranged for an upgrade to the painfully slow AS/400 that they had been using. The new Model 170 was sitting next to the old one in the frigid data center when I arrived on August 19, 2000, to migrate the AdDept programs, the data, and everything else.

The fiasco: Writing about this episode is one of the most painful things in the entire 1948 Project. It was certainly the low point of my career as a cowboy coder.

The new system used RISC processors; the previous system used CISC. The compiled versions of the hundreds or maybe thousands of programs in the AdDept system needed to be converted. I had already done this a few times, including on a system used in TSI’s office. In fact, we used precisely the same model of AS/400 that Gottschalks had just purchased, and I was very familiar with the CISC model that they had been using. I knew that it would take most of the weekend to effect the changes, but I was quite confident of my ability to pull it off. I was so certain that I had scheduled time at Robinsons-May in North Hollywood for Tuesday and Wednesday. I planned to drive to Santa Clarita on Sunday evening and commute from the Hampton Inn there to Rob-May

The trip started very well. Here is what I wrote:

Yes, I often wore a suit, too.

I managed to get upgraded to first class for both legs today. Nadine told me that when she called three weeks ago they told her that there were no first class seats available on the Cincinnati to LA leg. It was indeed full, but I got one of the seats.

In first class they give you a hot wet towel before dinner. I have never quite understood what this was for. I guess that maybe they are afraid that the common people might have touched something on their way through our section. We wouldn’t want their common germs to mix with ours. I had delicious food on both flights. The food in first class on Delta is really excellent.

A guy across the aisle from me who was at least my age had a short haircut which had been dyed blonde on top. The only thing I can think of to explain this is that he must be the manager of a supermarket who did it to identify with his employees.

Wow! We just passed over Albuquerque. I could easily pick out the base that I was stationed on, the airport, and the two golf courses I played. The last was easy. They were the only green spots to be seen. The southwest is really desolate.

The drive to Fresno wasn’t too bad. Well, the first 22 miles were horrible, but the last 200 were easy. The car has a CD player. I played the duet CD through twice. I changed cars at Avis. When I got to Fresno, I realized that I still had the key to my first car. Whoops.

I am pretty certain that I stayed at a Holiday Inn Express on that occasion. I must have arrived late. The only room that they had was handicapped-accessible. There was a tub, but no shower. I had to sit down and spray myself with one of those handheld devices that are so common in Europe.

Both a football (soccer) and volleyball team are known as the Fresno Heat.

Although it was August, and Fresno had a reputation for very hot summers, I brought a jacket because I knew that I would be cold in the data center. If I had not, I would have been even more miserable than I was. David Seeto, our technical contact in the IT department, was there during the following process:

The new system came with the operating system and licensed programs already loaded. We had to call IBM to find out what to do. Unfortunately Gottschalks’ software contract did not cover weekends. Nevertheless we finally got IBM to tell us how to remove the licensed programs. When we did so, we got a processor check on the new machine. We called IBM again. They told us first that we probably had a bad disk drive, but we should try to IPL from the tape again. We did. This time the system said that it could not find one of the disks, but it completed the task. A second IBMer told us how to reconfigure the disks to find the second disk drive. By now it was 4 PM.

A “processor check” is a fatal error. The system is not usable without extraordinary intervention.

I then began the process of bringing over the data (trivial but time-consuming) and programs (much more complicated). The most important programs were in the library named AdDept. I successfully brought that entire library over to the new system. Then I deleted all the objects in the AdDept library on the old system. I don’t know why I decided to do that. It was certainly unnecessary, but I could not see how it could cause a problem. That system with all of its contents was surely headed for the junk heap anyway.

The process of converting all of the programs was still running when I left on Saturday evening. I came in on Sunday morning and was delighted to discover that the conversion had completed without any problem. I then put the system through some simple tests to make sure that everything was OK. I soon discovered that, while some programs performed correctly, a few of the most important ones did not. The most commonly used program in the system, WRKADS (work with ads), produced erroneous results.

I tried recompiling the programs that were producing erroneous results. That did not help. This was intolerable. I had no choice. I had to make the CISC system usable again. Here is what I wrote to my partner, Denise Bessette (introduced here), about the process.

David Seeto.

Well, I think that clearing that AdDept library was the stupidest thing that I have ever done. My recovery technique did not work. The 3/5 tape was missing everything changed from their previous install through that date. I had no way of knowing what the previous install date was. Therefore, I selected everything on the RISC box with a change date from 1/1 through 4/30. I think that this is a fairly good approximation since there was definitely an install here on 4/20. However, I did not discover this until 7 PM. I left Gottschalks at 11:15. The files were finished, but the compiles were still running. Could someone sign on tomorrow morning to test the WRKADS programs? Send me a message with the results.

I canceled my hotel reservation in Santa Clarita. I am staying at the Holiday Inn near Gottschalks. I plan to go into Gottschalks to make sure that things are running reasonably well.

Could you tell Mary Ng that I will try to be in early in the afternoon?

If I had to work with David Seeto every day I would have to take a header off of a bridge.

I only punched one wall today. The wall is fine, but one of my knuckles is very sore.

Gottschalks’ IT department placed a service call with IBM. A customer engineer appeared and ran diagnostics on the new hardware. He testified that it was all in order. As far as IBM was concerned, since the hardware was functioning correctly, the problem must lie in either its BASIC program product, for which IBM had withdrawn support, or our AdDept code. In either case it was not IBM’s problem. End of story. The fact that exactly the same model in Connecticut produced results that were different from those of the one in California did not affect the judgment of the IBM people in Fresno.

I tried to explain this to the people in the IT department at Gottschalks. I promised that I would continue working on the problem remotely. They were not a bit happy with a resolution that left them with an unusable computer that they had already paid for and a very slow one. However, they agreed to keep the new system on, as well as the communications setup that allowed people in TSI’s office to sign on to it. So, at least I would be able to gather data from afar.

I returned to New England with my tail between my legs. Two important clients were angry at me, and I could not blame either of them.

I had plenty to keep me busy for the next few months. At some point I flew to California to make up for the visit to Rob-May that I had canceled. A week or two later I flew to Bradenton, FL, to do a demo for Beall’s. After that trip I needed a few days to cobble together a detailed Design Document and a proposal.

During the periods in which I was at TSI’s office I devoted as much time as possible to trying to isolate the problem with Gottschalks’ new system and to find someone at IBM who would listen to my argument. I remember more about the former than the latter. I do, however, remember the moment when I asked an IBMer to look at an example that contained almost no programming code at all. While working in the BASIC interpreter at Gottschalks I displayed on the screen the erroneous result from a simple sum of two constants. I then performed the same task on TSI’s system and got the right answer.

The IBMer was forced to admit, “This must be a hardware problem.” A day or two later he got the customer engineer to return to Gottschalks and replace the “floating-point processor,” which I did not even know existed. Evidently it was used by BASIC and almost nothing else. I signed on and put the new system through its paces. Everything seemed to work perfectly. I called Gottschalks and scheduled another trip in November to effect the migration.

The flight out to California was not as pleasant as the one before the disastrous August trip. Upon arrival in Fresno I wrote back to Denise,”I was nearly overcome with sadness in the airport in Chicago. If this trip goes well, I will probably feel better. The last one made me rethink my whole approach to life.”

Gottschalks went from a grey box to a black one.

The November migration also occurred over a weekend. It went much more smoothly than the first one, but there were still quite a few hiccoughs.

I cleared out the TSIDATA library on the new machine. I then restored the data from the CISC box. It took six hours.

I keyed in all of the user profiles. I checked the system variables, the backup and cleanup schedules, and the automatic reply list entries. I set it up so that QSNADS was started with QBATCH. I keyed in all of the scheduled jobs. I scheduled jobs to stop and start fax support.

Todd Burke5 from IBM came in the afternoon. He had installed the operating system in August. However, he had failed to install the extended help, the previous compiler support, Advanced Function Printing (needed for faxing), and the Communications Utilities (needed for RJE6). He set up a console in the operator’s area so that it receives break messages from the QSYSOPR message queue.

DATEINFO7 was not in TSIDATA. I discovered this last time, but I forgot. I had to restore it from the old system.

I installed all changes from our system from 8/17 through 11/3. I didn’t leave on Sunday until 8 PM. I was the first to go. I was so tired that I missed my exit going back to the hotel.

I changed TOSHA_B’s user ID to TOSHA_A8 and STEPH_K’s to STEPH_M. If they are going to use ID’s like those, they should prevent the women from getting married.

Todd set up the faxing incorrectly. I don’t know what he did wrong, but the software support person had me delete everything he did and key it in again. She also had me fudge one of their files using DFU9!

When I left everything was working. David Seeto said that he felt as if a huge weight had been lifted from his back.

I’ve spent considerable time in the L.A. airport three times this year. No movie producer has yet to approach me with a multi-picture deal.

That was not the end of the story. I submitted two invoices to Ernie Escobedo for my time at Gottschalks in August and November. I did not ask for reimbursement for the dozens of hours that I had spent researching the problem and trying to get IBM to take a second look When TSI had not received payment more than a month later, I asked Ernie about them. He said that he was “not inclined to pay them.”

I wrote him a long letter in which I described the efforts that I had undertaken to get that defective new system to work. I also said that I understood why Gottschalks was still upset about the situation, but the villain in this case was IBM. The company had installed equipment that did not work and refused to recognize that fact just because the diagnostics that someone at IBM had designed did not allow the customer engineer to detect the problem. Ernie promptly approved the payment of both invoices.

Stephanie Medlock.

AxN: In 2003 Bob Wroblewski and I made a trip to California to show TSI’s online insertion order system to Rob-May and Gottschalks. That trip and Bob’s involvement with the project has been described here.

The reception to the presentation seemed quite positive, bur Stephanie never agreed to try AxN. She stuck with faxing her orders until the end.

Life in Fresno: During most visits to Fresno I stayed at a Hampton Inn that was a short drive from Gottschalks’ headquarters. I always rented a car; public transportation was not a viable option in Fresno. I found no restaurant in which I felt comfortable dining alone. For most suppers I got takeout. There was no shortage of establishments that specialized in fast Mexican food.

My only recreation was running. I was able to map out a course through the suburban streets near the hotel. Traffic was a problem at only a few intersections.

The weather always seemed good. The most peculiar thing that I remember about Fresno was the tule fog. Occasionally a fog bank would abruptly drop the visibility to zero for a short period of time. This happened once while I was there. On Highway 41, the major north-south road in the San Joaquin Valley, it caused a collision that involved a large number of vehicles. The phenomenon has its own Wikipedia page.

Epilogue: In 2000 Gottschalks acquired the Lamonts department store chain. The acquisition gave Gottschalks a presence in the Pacific northwest and Alaska. In retrospect this must have been the impetus for the upgrade to the AS/400. However, the results did not meet expectations. In 2008 the company was delisted from the New York Stock Exchange. In the next year it declared Chapter 11 bankruptcy. By July of 2009 all the remaining stores had been closed.

Robert Guinn.

1. Robert Guinn’s career after Gottschalks led him back to his alma mater, Fresno State, as is described on this webpage.

2. Frederick Atkins Inc. was a non-profit company that bought merchandise for the companies in the Frederick Atkins Group. In the late nineties quite a few independent chains of department stores still belonged to the group. A description of the concept is posted here. The company went out of business in 2015. At that point the number of independent department store chains could be counted on one hand.

3. As far as I remember, he persuaded no other company to buy the system. Of course, I did not expect him to. However, he did arrange for me to make a presentation to members of the group at a convention in Naples, FL. That adventure has been described here.

4. The Club One Casino, which was really just a card room, moved away from downtown during the pandemic.

5. I do not remember Todd Burke, but I found his LinkedIn page here. For some reason his list of experiences skips over his time in Fresno, as well as everything else in 1999 through 2018.

6. RJE is one of the hundreds of TLAs (three-letter abbreviations) employed by IBM in those days. It stands for Remote Job Entry. I don’t remember precisely how it worked.

7. I don’t remember what DATEINFO was used for or why it was not in TSIDATA, the library that contained all information that pertained to the client.

8. According to LinkedIn Tosha’s user ID would be TOSHA_G if she was still working at Gottschalks. For some reason I was not allowed to see her LinkedIn page, but I did find a reference to her here.

9. DFU was shorthand for Data File Utility. We never told any of our clients that it existed, and we never used it. It allowed the user to go in and change any field on any record of any data file. There was no audit trail whatever. This violates sacred principles of database design.