Parisian, based in Birmingham, AL, was a little different from the other divisions of Proffitt’s Inc.1 (later renamed Saks Inc.). Its stores were somewhat upscale, but they seldom went head-to-head with Saks or Neiman Marcus in major markets. Parisian was acquired by Proffitt’s Inc. in 1996, and the corporate headquarters was immediately moved to the beautiful Parisian building at 750 Lakeshore Parkway on the north side of Birmingham. By that time Proffitt’s Marketing Group (PMG) had already decided to implement the AdDept system at all divisions. Therefore, I never made a presentation or demo for Parisian.
I flew to Birmingham and installed the AdDept system in January of 1999. After that day I never laid eyes on the AS/400 or the system console. They were kept in a closet somewhere in the headquarters building. Parisian’s advertising department was located, if memory serves, on the second floor. PMG was on the ground floor. The AdDept users signed on through the network. TSI had nothing to do with the connectivity.
This was a very strange installation. The personnel in the advertising department were not like those that I encountered anywhere else. Aside from the Senior VP, almost everyone else at every level was female. Moreover, every time that I went there, there seemed to be a large number of new people who needed to learn how to use AdDept. Finally, a very high percentage of these women were strikingly good-looking and blonde, and almost all of them dressed much more stylishly than I had seen at any other location, including Saks Fifth Avenue and Neiman Marcus.2 At those two locations the executives and the people who dealt with customers dressed to kill, but those standards were not imposed on clerical workers.
From left: Kimberly Weld, Sally Carter and Cheryl Sides. Josh Hill from PMG is behind them.
I have found quite a few photos of the people at Parisian, and the names of the employees are indicated on some of them. I also have some notes beginning in 1999 that included more names. I have very clear memories of only two people, Cheryl Sides1, who was the official liaison for the AdDept system, and Sally Carter, the manager of the business office. Cheryl was there from the time of the installation up to the demise of the chain. Sally was replaced by Barry Cleavelin in 2001.
For the first year or so the Divisional VP was Alan Seitel5. The Senior VP for most of the period in question was Bob Ferguson, who came over from Younkers6. He was succeeded by Gary Yiatchos7.
Renita Lewis on the left with her back to the camera. Next, in order, are Diane Vogel, Cheryl Side, Kim Wolff, Regaye Fulcher, Annissa Kennedy, Kimberly Weld, Josh Hill, and Angela Dawkins.
David Dollar.
The people: I could hardly believe how many names were recorded in my notes or beside my photographs. I have almost no memories of any of these people. If my notes included a description of their role at the Parisian, I have included it in their entry in this list:
Diane (Vogel) Worthington’s LinkedIn photo.
It seems incredible that I remember nothing about Diane Vogel, who was the Advertising Director at Parisian from 1996 on. I must have had several meetings with her. Her LinkedIn page can be found here.
Kimberly Weld would have won the national title if there had been a Miss ROP Coordinator contest. Her LinkedIn page is here.
David Dollar was the Co-op Coordinator. I seem to remember that he kept a lot of food in his desk.
I think that Dottie Collins might have handled Co-op advertising before David Dollar. Her LinkedIn page is here, but it contains no useful information.
I mostly remember Kim Woolf as the other Kim. She might have been involved with direct mail I found her LinkedIn page here.
Regaye Fulcher sat next to Kim Woolf in one photo. She may have worked with or for her. Her LinkedIn page is posted here
Ginger Brown worked in direct mail.
Colin Mitchell (a woman) was in charge of insertion orders for the newspapers.
Karen Kennedy worked in the production side of direct mail.
In 2000 Kelley Carter was in charge of co-op.
The next year it was taken over by Mollie Donohue. Her LinkedIn page is here.
I met two new people on my last trip to Parisian in 2005. The first was named Justin Walker. I wrote, “Justin Walker, whose title is director of eBusiness, is, I think, the resident techy for the Parisian division.” His LinkedIn page is here.
The other newcomer in 2005 was Luann Carter who came from Proffitt’s I think that she was in charge of trafficking production jobs. Her LinkedIn page is here.
I remember nothing about any of the following people whose name I recorded at some point: Annissa Kennedy, Angela Dawkins, Renita Lewis, and Kelly Denney.
I am completely stumped as to why I do not remember Mollie.
The installation: This was one of TSI’s most frustrating installations. The only difficult thing that they asked for was Bob Ferguson’s calendar. They printed it on a Canon color copier that used Postscript rather than a version of PCL, the Hewlett-Packer language. I said that I would look into it, but I don’t think that we ever even quoted doing it.
This should have been an easy installation, but it wasn’t. They seemed to have difficulty getting even basic programs to work for them. Some of the problems were just bizarre. In 2000 I reported, “CHKFAXSTS doesn’t work on Colin’s Mac. No matter what option you put in, the program interprets it as a 4. This is one of the more bizarre problems that I have encountered.” CHKFAXSTS is an IBM program; no other AdDept user ever had any problem with it.
Renita and Sally.
In April of 2000 I described some of the other difficulties.
Saks Inc. is putting pressure on Sally Carter to use AdDept to do closings. She told Sandy that she doesn’t want to use it because she doesn’t think that it works. We helped her through some problems today with the P.O. accrual program. I should have gone over the closing programs with her in more detail when I was there, but there was just no time. Wednesday I found a bug that threw off the journal entry by $1 million. I fixed it easily, but we looked bad.
This is another face of our usual problem. I have spent an inordinate amount of time at Parisian providing basic 5250 training to people that do not use the system at all and never will. I have also spent a lot of time writing custom programs (mostly their funky advertising schedule) and more than a little time twiddling my thumbs. I have spent no time with Sally to speak of before the last trip. Most of that was spent getting the store allocations to work.
I also reported that in November of 2000 I was asked to train a whole new group of employees in a classroom setting. It did not go well at all:
Barry Cleavelin.
The people in my class on Friday – who seemed reasonably intelligent to me – retained absolutely nothing. Either I am a much worse teacher than I think that I am or people in this type of setting do not think that they are expected to remember anything.
When Barry replaced Sally, I needed to spend several days with him to help him get up to speed on the AdDept processes. During that period we discovered several things that had been handled incorrectly in the past.
Life in Birmingham: I did not hate Birmingham as much as I hated Jackson, MS, the home of McRae’s. Jackson made me feel angry and frustrated. In Birmingham I just felt uncomfortable.
My records indicated that I ate a lot of lunches at Cia’s, which was inside the Parisian building. I have no vivid recollections of any of them
Most evenings I picked up a sandwich at Schlotzsky’s Deli. I remember that I ordered the same thing every time. It might have been a Reuben; that was my most common order at a deli.
I distinctly remember eating at a small Italian restaurant inside a mall. Ordering was done at the counter. I asked for spaghetti and meat sauce. The man at the counter mumbled something that I could not understand. I asked him to say it again. He did, but I still had no idea what he was asking me. I just said, “Yes.” Twenty years later I still have no idea what I agreed to.
At least once Steve VeZain of PMG took me out to his favorite restaurant, Joe’s Crab Shack.
La Quinta.
For most of my visits I stayed in the nearby La Quinta. It seemed to cater mostly to golfers who came to play the courses on the Robert Trent Jones Golf Trail. The thing that I noted the most about them was that many of them wore leather shoes with no socks. I had never seen this before, and it struck me as being both uncomfortable and unsanitary.
After work I usually jogged five or six miles on paths up and down the highway that ran between the hotel and Parisian. It was not the greatest place to run. Not only was it a little dangerous, but the noise was also disturbing. I had to wear my Bose headphones while I listened to operatic music or instructional tape.
The La Quinta had a pool and a small hot tub. Both of them were outdoors. The first time that I stayed I was able to use the hot tub after my run undisturbed. On all subsequent occasions the hot tub was occupied by golfers. On my last visit I gave up on La Quinta and stayed at a Hampton Inn.
I wrote the following on November 9, 2000:
When I was in Portland early in the year I had enough time to change my clothes before taking the red-eye back to the east. I changed in an extremely cramped stall in the men’s room. When I got home I realized that I was missing one of my wing-tips. I must have left it in the stall. I never threw the remaining shoe away because I thought that I might be able to find the missing one somewhere. After a while I forgot about it.
I went to the store to buy a new pair of dress shoes. I did not want another pair of wing-tips, but the only reasonable ones I could find were wing-tips, so that is what I bought.
This morning I was congratulating myself on forgetting nothing more important than a t-shirt to wear running. I started to put on my shoes. Both of them were right shoes. I evidently picked up the extra shoe by mistake.
I had to make an emergency run to Walmart. It was an unpleasant experience, but I managed to find one pair of shoes that are reasonably dressy (i.e., not hiking boots) in my size. They were on sale for $12.97.
They would not take my new American Express card at Walmart for some reason. I have used it twice.
This store in Pensacola was formerly a Parisian.
Epilogue: In August of 2006 Belk8 purchased the Parisian stores. The management of the advertising was immediately moved to Belk’s headquarters in Charlotte, NC. The five northern stores were sold by Belk to Bon Ton. Some southern stores were closed immediately. The signage on the remaining ones was changed to the Belk nameplate in 2007. Three northern stores continued to operate under their original name until 2013.
1. My experiences working with Proffitt’s Inc. and PMG are detailed here.
2. Most of my trips to Parisian were after the holding company had changed its name to Saks Inc. in 1998. My theory is that the women who applied for jobs in that building, which was the corporate headquarters for Saks Inc., thought that they were applying for a job at Saks Fifth Avenue. Thus, many of those attracted might have envisioned a career at the famous luxury store. After they learned about the other divisions and the pedestrian jobs involved in managing retail, they moved on. This is all just speculation, but I know that the guys in PMG spent as much time upstairs as they could.
3. Cheryl’s last name was, according to the designations on the photos, Sides. However, I also found Sipes and Sykes in the notes. I am not sure what Cheryl did at Parisian beside act as liaison with TSI; she definitely was good at that. I searched the Internet using all three last names but found nothing.
4. I found nothing on the Internet about Sally Carter, Barry Cleavelin’s LinkedIn page can be found here.
6. The history of the AdDept installation at Younkers is posted here.
7. I met Gary Yiatchos when I flew to Seattle for the presentation of the AdDept system to the advertising department of the Bon Marché. That adventure is described here.
8. The history of the AdDept installation at Belk is posted here.
In large measure this entry is based on and inspired by a set of recently discovered messages that I sent to my partner, Denise Bessette, about new projects that we were researching or working on. The first email was dated in late 1999. The last was in early 2001. The messages portrayed an exciting but scary time for both of us.
By the middle of the nineties it was evident to us that the way that TSI had been programming in the past fifteen years was becoming obsolete or was at least losing popularity. In 1992 Microsoft left IBM at the starting gate when it released Windows 3.1, the first version of its operating system that featured a graphical user interface (GUI) and was also stable enough that large corporations took it seriously. One could still make the argument that text-based software systems like the ones that we had developed were appropriate for many business tasks—in fact, most of the most important ones. However, if you did, you were probably dooming yourself to the fate of typewriter salesmen.
Great if you have just 2 fingers.
In fact, systems like AdDept and TSI’s other systems were branded by many of the magazines of the day as “legacy systems”. The emphasis of the new approach centered around the appearance of the screens, which now featured colors, images, text boxes, radio buttons, and varied fonts. They were certainly more interesting to look at than anything that we had produced. The mouse was the thing! The keyboard was only used when absolutely necessary. Whether they were as efficient or as easy to use was debatable, but, as I already noted, we were well aware of what had happened to the typewriter salesmen.
Another thing that happened during the middle of the nineties was the explosive growth of the Internet. All software developers wanted to be a part of it, but few were exactly sure how to approach it. I knew that we needed to figure out what aspect we should concentrate on, but it was not an easy decision to make. A few early participants made a lot of money, but an awful lot of ideas were catastrophic failures.
The Search for a GUI: I spent countless hours researching ways that we could provide a GUI for the AdDept system that did not involve a complete rewriting of the hundreds (and growing daily) of screens that we had already implemented. Every developer who worked on IBM midrange or mainframe systems must have been faced with the same problem. We all wanted a way to provide a system that looked modern but also took advantage of the thousands of lines of functioning code that had already been written.
I don’t know why, but IBM was not much help in this endeavor. Instead, in the late nineties IBM became a strong proponent of an object-oriented programming language developed by Sun Microsystems called Java. This was a startlingly new language. The first version was released in 1996.
I bought and read ten separate books that purported to teach Java programming. The structure of the language was consistent with the first principle of its design: “It must be simple, object-oriented, and familiar.” Well at least it was simple and object-oriented. The structure of the code was nothing like what I was accustomed to. Its main orientation was to a computer display, which it considered a set of objects, each with a set of properties and methods. That approached worked well enough for a screen, but how would it work for other things? After downloading the software development kit to my laptop and spending hundreds of hours mulling the contents of those books, I could do all of the exercises in every book, but I had not the slightest clue how to begin to code a system to manage any aspect of retail advertising. In fact I could not replicate even one screen of the AdDept system.
I did not completely discard the notion of using Java somehow, but if we did, we would definitely need some help. As I look back on this, maybe this is the reason why IBM was so crazy for Java.
The Spreadout Project: Users of TSI’s systems seldom complained about the look or feel of our data entry screens. Those screens would never have won any design awards, but the formats were completely consistent throughout the application, and everyone knew that they got the job done efficiently. Furthermore, they knew that TSI could implement requested changes rapidly and at moderate costs.
What they did not like much was the look of the reports, which was limited to one non-proportional font—Courier—with no images or even styles like italics or bolding. Many, if not most, of the people who used AdDept were quite good at making and manipulating spreadsheets. They were used to controlling the format of the output, and they liked the flexibility. For example, if they wanted someone to concentrate on one column or row, they could easily change the font, color, or style for just those cells.
Several clients asked us if it would be possible for us to produce an Excel spreadsheet as the output from designated programs in AdDept instead of or in addition to printed reports. I did not know if it would be possible, but I said that I would look into it. I dubbed this project “Spreadout”.
It was rather easy to produce an output file that contained the same rows and columns as the report, and we implemented that option in a large number of AdDept reports. The user could then download that file to their PC. That file could then be loaded into Excel with the rows and columns intact. However, the fields (or cells) in the file contained only text or numbers. It was not possible to download formulas for totaling or designate any kind of formatting. Furthermore, the process of downloading the file was not exactly speedy.
I tried to figure out what it would take to produce code that could provide files that could be opened in Excel with predetermined formulas and formatting. I found some documentation from Microsoft of the Excel files, but I never could concoct a way to provide what our customers asked for. Furthermore I never heard of anyone else who had accomplished this, and —believe me—I searched..
I did, however, managed to provide an alternative that proved popular to some clients. Almost all the AdDept customers used Hewlett-Packard printers that were accessible by the AS/400. HP sold books that documented the format for files in HP’s printer command languages, PCL 4, PCL 5, and PCL 6. I could then write code to produce spooled files that contained the output in exactly the format that the client specified. The downside was the considerable amount of coding required for each report, many times as much as it took to produce it in the Courier-only. It also required an extra step to send the output directly to the printer without being reformatted.
However, a few clients were so insistent about the need for a precise format that they were willing to pay the price. These reports were almost always the ones that they distributed to other departments or to higher-ups.
If anyone else ever did a project like this for the AS/400, I never heard of it. Unfortunately, I never figured out how it could be marketed as a stand-alone product usable with other AS/400 software.
As the new millennium approached, we—that is, Denise Bessette and I—felt that we needed to expand TSI’s horizons. In January of 2000 we flew to San Diego for IBM’s PartnerWorld conference in the hope of making contact with people who could advise us how to adapt to the need for modernization and the Internet. That enjoyable but frustrating experience has been described here.
On February 25, 2000, I took the time to write up in a fairly detailed manner how, given the inherent limitations of a small business like ours, TSI should to proceed in trying to develop a second line of business. Here is a portion of that memo:
General principles:
1. We should get the best people available to help us.
2. We should maintain AdDept as a dependable source of income. Whether we should invest a lot of time and/or money in enhancing and marketing AdDept is still to be determined.
3. We should try to leverage our assets better. Our income is too heavily dependent upon the number of hours put in by Mike and Denise.
4. We should assume that the economy will remain strong for another two years. On the other hand, we should avoid debt or at least large amounts of debt in case this assumption turns out to be false.
5. We should add new skills that are more marketable. That means learning some subset of Windows, object-oriented programming, and the internet. We should be thinking past the next project to the one after that if we can.
6. We should look for partners with skills and assets that complement ours.
7. We should not be deterred by the fact that some of these principles seem incompatible.
8. We need to act fast. Pursuing René2 cost us seven months. On the other hand we might have gone down some less profitable paths if she had been on board.
I think we should take the following steps as soon as possible.
1. Find out what it takes to get our existing clients to use AdDept for insertion orders. The following clients are not using AdDept for IO’s: Macy’s East, Neiman Marcus, Filene’s, Saks Fifth Avenue, and Hecht’s. I checked Herberger’s. They have ads through March 29, 2000, at least. Macy’s West is apparently starting. Gottschalks ran insertion orders yesterday. I don’t know about Meier & Frank, but I can take care of that on my trip.
2. Find out which advertising departments have access to the internet and would be willing to use it to check on insertion orders. I don’t think that this would be a problem with most of them. Unfortunately, we don’t really have anyone in the office who can do this for us.
3. Make an appointment with Ken Owen3 to run the idea of a clearinghouse for insertion orders by him. He may be very interested in working with us on it. I have quite a bit of respect for him. At the very least, he is smart and completely honest.
4. Run the clearinghouse idea by at least one of our clients. Why not schedule our trip to New York and run it by Tom, Chris, and whoever their ROP person is?4
5. Run the clearinghouse idea by at least one newspaper or someone who knows how newspapers think about these things today.
6. Start trying to package and market AdDept and/or AS/400 products and services. We need to maintain or enhance our cash position over the next six months.
7. We should find out what, if anything, the National Newspaper Association (NNA)5, the AAAA6, and AP AdSEND have done in this regard. The AP is a potential partner in this venture. I once had a copy of the NNA’s EDI spec7, but I seem to have thrown it out when we moved. I will see what I can find on the Internet.
Requirements for hiring a marketing/client services person:
1. He/she must be able to get along with Mike and Denise. This includes having a good work ethic. I think Doug barely met these qualifications.
2. Must be able to get along with the clients.
3. Must be willing to spend a lot of time on the phone.
4. Must be able to talk to decision-makers and occasionally presidents of corporations without looking foolish. Doug could do this, but his ability to identify the real decision-maker was just so-so. He was also almost always overly optimistic, but this might be necessary to offset my tendency to see the negative side of everything.
5. Must be able to refrain from overselling.
Pluses:
1. Intelligence. Determination can go a long way to overcome deficiencies in this categories, but I don’t think I want to try to explain things to someone any duller than Doug.
2. Retail experience.
3. Newspaper experience.
4. Other advertising experience.
5. Good business sense.
6. Sales experience.
7. Computer experience.
How to proceed.
1. We can run an ad in the Courant. There are almost as many classified ads for sales and marketing people there as for programmers. The only major retailer in the immediate area now is Ames, and they run no ROP. Therefore the chances of finding someone in Hartford who understands retail advertising are slim.
2. We can contact a headhunter. We don’t have to pay unless we find someone, but we will have to pay plenty if we do. It might be worth it if it speeds up the process.
3. We can advertise on the Internet. Does that cost money? If so, how much?
4. In interviews I think that we should consider dangling a carrot of a spinoff of a .com company for the insertion order clearinghouse. I am not exactly sure how to present this idea to someone. Maybe we could offer them a percentage of the new company with the understanding that we would try to sell it once it has become established.
In retrospective I find it impressive that I was able to earmark in advance so many important issues that TSI would face over the next few years. We made some mistakes, but we made a lot of good decisions.
A month later, on March 25, 2000, I mailed a letter to our contacts at all of the companies that used AdDept. I solicited their opinions on what TSI’s priorities should be in the new millennium. Here is a copy:
TSI is in the process of evaluating how best to allocate its resources over the course of the next year or so. Our highest priorities will remain providing excellent support for existing installations and responding to requests for custom programming from existing clients. However, there are a few additional projects that we are considering. We are very interested in learning what our existing clients think about them.
1. Menu maker: This is a fairly simple idea both in concept and in implementation. You would be provided with either a PC/Mac program or an AS/400 program that would allow you to create your own menus. The menus would reside in a separate library so that they would never get mixed up with the standard AdDept menus. You would provide the name for the menu and the heading text. For each option you that want to add, you would be allowed to select from a list of AdDept programs and menus. You could also enter your own command or an IBM command (e.g., WRKQRY). If you selected an AdDept menu or program, the description and the online help would be filled in for you, but you could override the text to make it say what you wanted.
2. GUI front end: Most software companies that market systems of a size comparable to AdDept have budgeted more than $1 million to “modernizing” their data entry screens to use a “graphical user interface” that is consistent with the methods used by Windows and Mac programs. It is now technically feasible to create a fairly nice GUI front end for AdDept for much less than that using products available from third party vendors. However, there is still a considerable capital outlay involved. We also estimate that it would take at least half of a man-year of labor. Furthermore, the PC or Mac would have to meet certain minimum requirements. Terminals would still use the green screens. TSI’s support regimen would be more difficult. The interactive programs would probably run slower on older AS/400’s. They may actually run faster on newer boxes.
3. Output to Excel: We believe that it is technically feasible (albeit difficult) to create a file from the AS/400 that is usable by Microsoft Excel with no intervening steps. It is a relatively straightforward task to download data files (or even spooled files) to spreadsheets today, but many intervening steps are required to get something presentable. TSI’s proposed method would allow you for each report that is eligible for this kind of treatment to designate (and permanently store) the formatting of the worksheet—report titles, column headings, “fit to page”, and most of the other values in “File, Page Setup.” You would also be allowed to designate fonts and sizes for the report title, the column headings, the body text, and each level of subtotals. The subtotal values would be formulas, not simple values. The same program could be used for data files that are produced by queries. The resulting worksheet could then be edited as needed. You can even edit, add, or delete lines in the worksheet. The subtotals will automatically be updated. Most simple reports could be reformatted to use the proposed program. It might be difficult or even impossible to generate some complex AdDept output using this approach.
4. Insertion order clearinghouse: We have long thought that the methods used for reserving newspaper space leave too much room for error and are overly labor-intensive, both for the advertiser and for the newspaper. The purpose of this project is to make the ordering process easier and to minimize the potential for miscommunication.
Instead of faxing the orders, the AS/400 would send them electronically to TSI. We would post them on a website. When the newspaper reps sign on, they would see all orders for them from all advertisers who are using this service. They would be able to add comments or questions and confirm them electronically with or without reservation numbers. They could also print the orders and, eventually, download them directly into their reservation systems. When you sign on, you would see all of your orders. It will be immediately obvious which ones have been confirmed, which have been read but not confirmed, and which have not been read yet.
What do you think of these ideas? Do you have any ideas of your own? We would greatly appreciate it if you would communicate your feedback to us at your earliest convenience. The last thing that we want to do is invest a lot of time and money in something that is of little or no perceived value to our clients.
I don’t recall receiving any substantive responses to this, but around this time Steve VeZain sent me a rather lengthy email that explained some of the priorities for Saks Inc. Our dealings with him and his company are detailed here.
Net.Data: At some point I became acquainted with an online forum called IGNITe/4007. This was a website where AS/400 developers could pose questions about using the AS/400 for applications for the web. Although some IBM experts participated, the forum was not run by IBM, but by a former IBMer named Bob Cancilla8, who worked for a company in Rochester, MN, the home of the AS/400.
Bob also wrote the book shown at left that explained how to use the AS/400 as an Internet server. IBM disdained the approach of its customers using a book written by someone who had actually gotten the AS/400 to function as an Internet server. Big Blue preferred that its customers spend hundreds of dollars on classes or thousands of dollars on consultants rather than $15 or $20 for a book. They also championed something called WebSphere to manage applications written in Java. During February and March of 2000 I had puzzled over the Redbook that documented this product. I was nearly ready to give up on the idea of using the AS/400 for anything related to the Internet until I found Bob’s book and website in April of 2000.
I purchased this excellent tome and followed most of Bob’s advice. I successfully configured TSI’s model 150 as an HTTP server to serve web pages to browsers and as an FTP server for exchanging data files. It was possible to use the AS/400 as an email server, but Bob advised against it. We elected to use AT&T for sending and receiving emails for our employees. We later configured our AS/400 to send outgoing emails through the SMTP (simple mail transfer protocol) server. Eventually IBM decided that it was a bad idea to have its own proprietary HTTP server and supported a version of the Apache server used by almost everyone else.
At that time the most popular scripting language for web-based applications was PERL. IBM never supported it on the AS/4009. Instead it provided its own language, which was called Net.Data (pronounced “Net Dot Data”). This was the only web language that could be used on the AS/400, and no other system in the history of the world ever used it. We obtained a copy of IBM’s handbook on Net.Data (posted online here), and I determined that we could probably use the language for what we wanted to do. Here is what I wrote about it at the time.
I signed on to the IGNITe400 website and registered as a member. It’s free. You can ask questions there. I looked at a few of them. Bob Cancilla himself answered some of the questions! I also looked at IBM’s Net.Data website. It is full of information.
I printed out a lot of documentation. I am now convinced that we can do what we want to do with HTTP server and Net.Data. This is exciting. Buying that book was a great idea. The links alone are worth the price. The biggest difficulty that I see will be working out the process of getting the orders from our customers and then from others.
… I have more than doubled my knowledge about the AS/400 and the internet in the last two days. Moreover, I think I could do it! I think that we should try it some time this coming week.
Net.Data was an interpreted language, just as BASIC was on the Datamaster and the System/36. The programs (which in web parlance were called scripts or macros) were not compiled into executable machine code. Changes to the scrips took effect as soon as the programmer made them. So, a developmental environment was a necessity. The time it took the processor to interpret the code and generate the HTML code that the browser could understand made all of the programs considerably slower than the compiled BASIC programs on the same machine. However, they were lightning fast compared to Java, the approach blessed by IBM.
So, I taught myself how to use Net.Data to deliver interactive scripts for a browser (at the time the main choices were Netscape Navigator, Internet Explorer, and whatever Apple called its browser before Safari). The language itself was relatively easy to understand, but programming for numerous constantly changing browsers was much different from programming for a very stable AS/400 and its 5250 user interface.
I also had to learn the Common Gateway Interface (CGI), which was the method of reading from and writing to files on the AS/400. This was totally different from what we were accustomed to. Our programs had always read the files a record at a time even after we switched to the AS/400’s relational database. With Net.Data it was necessary to execute an SQL statement that returned a set of data—rows (records) and columns (fields)—that was stored in an array (called a table in Net.Data). It was then necessary to loop through the rows of the array. I was already somewhat familiar with SQL, but I needed to learn how to use “joins” to do complicated selections.
These two volumes got a workout. The binding on the HTML book split in two years ago.
I also needed to buy books on HTML and JavaScript. If I had realized before I started that I needed to learn all of this, I might have deemed that the project would require more time and effort than I could afford. However, by the time that I realized what I was up against, I had invested so much time that I was not about to abandon the project.
There was no syntax-checking of Net.Data macros, and, at first, there was no editor to help by color-coding the statements. So, when I ran into a problem, which happened quite frequently, I had to search elsewhere for help.
Life got a lot easier when IBM put its Redbooks on CDs.
In researching for this blog, I found a pdf online for a Redbook (technical manual) that IBM published for people like me in 1997. It is posted here. Even a quick glance will make it clear that writing applications for the AS/400’s HTTP server would be a daunting task. For example, it contained this statement: “Net.Data Web macros combine things you already know such as HTML, SQL, and REXX with a simple macro language.” I did not know HTML at all, I knew only a little SQL, and to this day I have no idea what REXX was. Also, the Redbook neglected to mention that it was not really possible to write interactive programs without JavaScript.
I hung in there. Here is one of my last messages: “I feel a lot of pressure to work harder. I want this new project operational yesterday. It is going to be difficult at first. I want to get over the hump.”
I spent a lot of time in the IGNITe/400 forum. My best source of information was a guy from (I think) New Zealand, of all places. I never met him in person or even spoke with him on the phone. His name was Peter Connell, and he helped me through every difficult coding problem that I encountered. Not once was he stumped. By the time that I was well into the project, I was able to provide solutions to coding problems that others described.
TSI’s Internet Project: Even before Denise and I attended PartnerWorld, we had pretty much decided that our best shot at developing a successful Internet product would involve insertion orders, which is what newspapers and magazine call reservations that they receive from advertisers for ROP (display ads), inserts, polybags, or any other kind of advertising. TSI’s AdDept customers sent their reps at newspapers a schedule that listed all of the ads that they wanted to place for a specified period—usually a week. Most of them faxed this information to the papers. The rep at the paper examined the schedule. Sometimes questions required phone calls. Sometimes requests (such as designated positioning in the paper) could not be accommodated. Even after final approval the schedule was often changed by the advertiser before the ads ran, sometimes with very little advance notification.
Newspaper ads were expensive … and valuable.
Errors on both sides were not rare, and they could be quite costly. The newspaper often gave the retailer free ads to make up for the mistake. The advertiser’s loss might be much greater. In the nineties and early twenty-first century ads in newspapers were the primary vehicle for communicating with customers. Mistakes in the ads could cost the retailer thousands in sales, and they were embarrassing to the advertising department. Occasionally heads rolled.
In 2000 most retail advertisers faxed their schedules to the newspapers. If the line was not busy, the phones were rather reliable. However, what happened to the schedule after the fax machine received it? Was the printout legible? Did the rep ever get it, and, if so, what did he/she do with it. What assurance was there that the fax that the newspaper used to compose the paper was the final version?
We thought that the Internet might provide an opportunity to speed up this process and to improve its reliability. My first idea was to replace faxing with email. If the AS/400’s (free) SMTP server were installed, AdDept could compose and send to the newspaper an email that contained the schedule. Wouldn’t the newspaper rep immediately print the schedule? If so, how was this better than faxing? Doesn’t it just add another step? Besides, email is demonstrably less reliable than faxing. The worst that usually happens with faxing is that the output is blurry or even unreadable. Emails, in contrast, can be held up by any Internet Service Provider (ISP) that handles the message, and there could be dozens. So, the schedule might never make it to the rep’s inbox.
Eventually Denise and I settled on using FTP to send the schedule from the client’s AdDept system to TSI. Thereafter TSI’s AS/400 managed the whole process using a combination of BASIC programs and Net.Data macros. Details of the actual design are posted here.
After Denise and I agreed on the design, several details still needed to be settled:
Who will do the coding at TSI?
Who will pay for the service, the advertiser or the newspaper?
How much will we charge?
How will we market the product to our clients and their newspapers?
How can we entice advertisers that did not use AdDept to use this method for insertion orders?
Can we take advantage of the link established between TSI, the papers, and AdDept for other modules?
What will the product be named?
Will the project be part of TSI or a new financial entity?
The answer to #1 turned out to be Mike Wavada. I expected that I would eventually train Denise or one of the programmers so that they could at least support the existing code, but it never happened. It astounds me to report that this was a one-man coding job from day one, and no one else at TSI ever learned Net.Data. Hundreds of papers and most of the AdDept clients relied on it starting in 2002 and continuing through early 2014. Think about this: Between 2003 and 2012 I took six vacations in Europe and one cruise in the Caribbean. There were no serious incidents!
Questions 2-5 are addressed in the entry about marketing of AxN, which is posted here.
From the outset I was hoping that the nexus connecting newspapers and the retailers through TSI’s website could be used for other communications as well. The most obvious one was for the delivery of the files that contained the layouts of the ads. Nevertheless, I was reluctant to pursue this for several very good reasons. The first was that the Associated Press already had a huge head start with its very popular product called AdSEND10. There were also several other companies that offered similar services.
The other thing that gave me pause was the potential legal liability. It seemed to me that if we failed to deliver an ad correctly and/or promptly, we could easily be sued. A fundamental tenet of TSI’s operation had been to avoid any activity that might occasion a lawsuit. Throughout the first two decades of its operation, TSI had successfully avoided litigation. Also, we knew nothing about the process of sending ads electronically, and the AP already owned satellites that it used for this purpose. I also learned later that AdSEND had twelve dedicated T-1 lines, and one of TSI’s clients told me that that was not nearly enough. TSI eventually installed one T-1 line that easily handled the insertion order traffic generated by AxN.
An idea that I liked better was for the newspapers to transmit their invoices electronically through TSI’s servers to AdDept users. I even came up with a cool name for this: e-I-e-IO, which stood for electronic invoices and electronic insertion orders. My idea was to provide a program to feed the newspaper’s billing system with the information from the insertion order, and to feed the retailer’s AdDept system with the same information. I did a little research to see if one software system for billing or accounting was dominant in the newspaper industry and discovered that this was decidedly not the case. So, we would face the prospect of persuading one paper at a time, or, at best, one chain of papers at a time. Furthermore, someone else had already claimed the URL that I really wanted: eieio.com.
The name that I picked for the new product would still work if we came up with other ways for TSI to serve as a nexus between advertisers (A) and newspapers (N). It was AxN, which was pronounced “A cross N”. The A and the N were always portrayed in dark blue Times New Roman. The x was always in red Arial.
That leaves question #8. Denise was always in favor of making AxN a separate financial entity. However, we never found a way to extricate it from the rest of the business. We looked at the revenues separately, but we never even did a separate P&L for it.
1. René Conrad was TSI’s liaison with Kaufmann’s, the May Company’s division based in Pittsburgh. Both Denise and I had a very high opinion of her. When Doug Pease left TSI in 1999, we tried to hire René. Details of the AdDept installation at Kaufman’s are posted here. The unsuccessful pursuit of René is documented here.
2. Ken Owen is a friend and was a client. The latter role is explained here. By 1999 Ken’s business had drifted away from creating and placing ads for clients to software for the Internet. He gave us a little free advice, but the role for him that I envisioned did not materialize. I communicate via email with Ken every year on March 4, the holiday that we celebrate together—Exelauno Day.
3. Tom Caputo and Chris Pease were our key contacts at Lord & Taylor in Manhattan in those days. The history of the installation at L&T is recorded here.
4. I did contact the NNA, but nothing came of it. The person with whom I spoke was nice enough, but it became evident that trying to work with this organization would be extremely time-consuming and not the kind of thing that I was good at or enjoyed. Eventually I discovered that there were almost as many administrative systems for newspapers as there were newspapers. It appeared that there were no accepted standards.
5. The American Association of Advertising Agencies (AAAA—universally pronounced “four A’s”) published an annual list of software for ad agencies. For years TSI’s GrandAd system was on the list. I am not sure what I had in mind as an additional relationship. Perhaps I envisioned ad agencies that specialized in retailers might want to use AxN for insertion orders and would work with us to create an interface. Perhaps I thought that other software companies might add the interface to their products for ad agencies. Nothing like any of these things ever happened.
6. EDI is short for Electronic Data Interchange. It refers to an orderly setup that enables participant to exchange information electronically. When there are only two participants, it is usually just called an interface. “Specs”, which is short for specifications, refers to the documentation published and delivered to the participants and prospective participants.
7. I have no idea what the name of this group meant. At the time IBM was busy promoting the idea of e-business. IBM’s marketing director proclaimed at PartnerWorld that IBM “owned” the concept. So, that may explain why the e is not capitalized. I was surprised to find an article in Enterprise Systems Journal about IGNITe/400. It is posted here.
8. Bob Cancilla went back to IBM for a while and then became a consultant. His LinkedIn page is here. In 2018 he wrote about the thirtieth anniversary of the AS/400. It is posted here. The article explains some of the reasons why IBM treated the AS/400 division and its customers so shabbily almost from day one.
9. For some reason IBM repeatedly changed the name of the AS/400 to a bunch of things with the letter i appended. The operating system remained the same. Everyone at TSI, like most users, still called it the AS/400 even after the name changes.
10. In 2007 Vio Worldwide acquired “the assets” of AdSEND. The deal is described here. In 2010 Dubsat acquired Vio Worldwide. This transaction was reported here.
Department store division of the May Co. with headquarters in Portland, OR. Continue reading →
Since 1932 M&F’s flagship store had occupied an entire block in downtown Portland.
Meier & Frank was a chain of departments stores owned by the May Company. Its headquarters was in Portland, OR. TSI never pitched the AdDept system to the store’s advertising department. In 1998 the May Company decided to order AdDept systems for the three department store divisions that were not already using it—Robinsons-May, Meier & Frank, and Filene’s.
M&F was by far the smallest of the May Company’s department store divisions. At the time of the installation it had only seven stores, which made it barely a quarter the size of the next smallest division.
These installations were quite different from the other systems that TSI had installed at May Co. divisions. They began with three days of rather intense sessions in TSI’s office in Enfield. We were teaching them about the system design of AdDept, and they were informing us about their policies and expectations for the system.
The previous May Co. installations began with a site visit in which I had learned about each department’s business procedures and priorities. TSI then presented a formal proposal for the base system and any custom code that I thought was needed. Only after the system had been delivered and installed did we provide training, and it took place at the company’s location.
At some point in 1996 a group of people from M&F visited TSI’s office for orientation and training. Those sessions were also attended by people who would be involved with the installation at Rob-May. Robert Myers, with whom we worked in the AdDept installation in the advertising department of the Foley’s division (described here), also was there to provide the perspective of a user of the system.
I found several photos that I took on the occasion of their visit as well as photos that I took in Portland. Since I was still using disposable cameras in those days, the quality of the prints is not great. I was lucky to have this much. On one trip I left a camera that was full of photos in my rental car. I called Avis on my next visit and learned that they had found the camera. They later mailed it to me.
The people: The photo at the left was taken after one of the training days in Enfield. On the last evening we all went to the Mill on the River restaurant, but I think that this photo might have been taken at a different place.
Robert Myers was seated next to me. In the photo he is on the far right. Three representatives of M&F are on the left. I am pretty sure that the guy with glasses was Brent Stapleton1, who managed the departmental network and was our liaison for the first part of the project. I do not remember the name of the fellow on his left, but I am pretty sure that his hobby was making root beer at home. He might have been Steve Mulligan, the Co-op Coordinator who moved to Ireland the following summer. I don’t remember the woman’s name or function, and I don’t recognize the next fellow. He might have been from Robinsons-May. None of these people appear in any of the photos that I took on my trips to Portland.
The last person on the left side of the table was definitely Doug Pease, TSI’s Marketing Director, who sat in on some of the training sessions. The other two people were from Rob-May and are described here.
The system was not actually installed at M&F until March of 2000. I think that they postponed it because Kaufmann’s and Rob-May were higher priorities.
The next five photos were taken at the department’s office on the thirteenth floor of the flagship store in Portland. The building had fifteen floors.
In the photo on the right, the seated woman was Dori Tierney2, who was responsible for scheduling M&F’s ads in the newspapers. She also produced the weekly calendar that was the primary document that was used by many people inside the department and out. The other woman was her boss, Sheila Wilson3, the Newspaper Manager. She formerly had worked at Hecht’s.
In the first year of the installation I worked with Dori more than anyone else because producing that calendar was the department’s first objective for the AdDept system.
I am almost certain that the woman surrounded by papers in the photo on the left was Kathy Reed, the Business Office Manager. One of her primary responsibilities was to produce at the end of the month the report of expenses and co-op income by CCN in the May Company’s required format, the so-called 790. AdDept produced this at all of the other divisions. We never succeeded at completely automating that process at M&F for reasons that are explained in the section about AdDept projects below.
I have no recollection of the people in the photo at right. Maybe I took this shot because they were both so photogenic.
Many of the people in the advertising department at M&F did their work on clunky old IBM PC’s. They complained that all of their machines were hand-me-downs from their counterparts at Robinsons-May in California.
I took the two photos shown above at the M&F office in Portland, OR. I do not remember the name or function of the woman on the left. The guy on the right was Bryan Kipp, the Planning Manager.
From searches on LinkedIn I discovered that the Broadcast Manager at the time was Shauna Thompson, and the Direct Mail Manager was Linda Farrington. I probably worked with both of them.
The first visit: A month or so after the training session in Enfield Doug Pease and I flew out to Portland so that I could install the TSI software on the AS/400 that IBM had delivered. We also met with several executives to make sure that we understood and could address the department’s priorities.
I was surprised to see that the entirety of eastern Oregon was essentially desolate, and the coast was so rugged as to be almost uninhabitable. The majority of Oregonians were concentrated in the cities along the Willamette River.
Multnomah falls is about 30 miles east of Portland on the Columbia River.
In those days it was much cheaper to fly on Saturday than on Sunday, and Doug and I did that on the first trip. I found among my M&F photos several of Mt. Hood and Multnomah Falls. On Sunday we took our rental car on a spin around the very scenic areas east of Portland. Kate Behart and I had also visited these sites on a sales trip to Fred Meyer4, another retailer based in Portland, a few years earlier.
Emily.
The Senior Vice-president of Marketing at M&F was Emily White5, whom Doug knew from when they both worked in the advertising department of the G. Fox department store chain in Hartford. She knew about TSI’s capabilities from her time at Macy’s West. The Advertising Director was Laura Rutenis6. I think that she had previously worked at Hecht’s.
On the first visit Doug and I spent quite a bit of time talking with Emily and Laura. They explained their difficulty as the smallest of the May Co. divisions. They had far fewer employees than the other divisions, but their stores had just as many selling departments, and they ran just as many ads (in fewer newspapers, of course), and they were expected to produce the same reports as all the other divisions.
The primary objective of the AdDept system would be to get the module for newspaper ads up and running as quickly as possible and to produce their weekly calendar in the format that they currently used. At the same time the quantitative and qualitative information for ads for all of the other media needed to be entered into the system so that all the expenses could be entered in AdDept (or imported from PC systems) and uploaded to the corporate accounting system. So, the remainder of the time on the first visit was spent familiarizing the employees with the programs for entering the data and showing them how to check their work.
The projects: I don’t remember much about most projects that we did for M&F. I am sure that the May Company wanted them to produce the 790 report using the AdDept system’s cost accounting programs. That would require them to enter (or upload from another source) all the expenses from every media. I am pretty sure that we reached the point at which all of the necessary data was in the system.
Nevertheless, AdDept never produced the 790 report at M&F because the department’s Business Office Manager had been fudging some of the allocations required by the May Co. The corporation’s internal auditor surely knew about this, but she had no assistants to help her in the Business Office, and it would not have been practical for her to implement all the required steps within the strict time restraints. I thought that it would be feasible for her to do it in AdDept, but I could understand why she did not want to commit to a process that she could never verify produced results that were consistent with her existing methods. Also, she was more confident that she could meet the deadline every month without using AdDept.
I definitely remember spending many hours working on the weekly advertising calendar, which was designed to be printed on a special Hewlett-Packard laser printer that the advertising department had purchased. It could handle very large forms. Printing from the AS/400 was ordinarily limited to text of at most 198 characters per line and a single non-proportional font, Courier New. So, it would not be easy to replicate what they were doing.
Every advertising department that we worked with produced a calendar that was the basis of communication with other departments and the brass. In every other case we had been able to convince them that what the AS/400 could produce in the usual way—with whatever changes they needed—would suffice. The alternative was for us to produce output files that could be downloaded to a PC and formatted for printing in Word, Excel, or other software, and a few chose that method. The people at M&F insisted that that was not good enough. They needed the calendar the way it currently looked and they did not want to take extra steps to provide it.
In order to produce the calendar that they required I decided to make use of research and coding involving PCL, the language that Hewlett-Packard’s printers used. Instead of creating “spooled files” that the AS/400 translated into PCL using its printer drivers, the program that I wrote for M&F created files of instructions that were sent directly to the printer. They bypassed the AS/400’s drivers because the files were already in the language that the printer understood.
This approach had the advantage of allowing the use of proportional fonts such as Ariel or Times Roman. It also allowed the use of simple graphics such as boxes, variable font weights and sizes, italics, bolding, etc. The end result was definitely more attractive, but the big advantage was that the format was already familiar to the executives from other departments to whom it was delivered. It could all fit on one page that included attractive fonts, boxes, and other things that no one ever saw on a computerized report in the nineties.
From TSI’s perspective there were, however, serious disadvantages to this kind of approach. None of the other people at TSI were even slightly familiar with PCL. On this project I wrote all of the code myself.
By 1998 I was generating only a fairly small percentage of the new code at TSI’s office. I spent the bulk of my time traveling to clients, installing new systems, training, writing up proposals for new systems, modules, and requests for custom programming. I also had important administrative obligations, including locating more appropriate offices for TSI.
I suppose that I could have asked Denise Bessette, TSI’s VP of Product Development to learn PCL 5 from the handbook that I had found somewhere, but there was no guarantee that we would ever use this technique again. Besides, time was of the essence, and she already had a lot on her plate. By far the fastest way to deliver the code was for me to do it. There definitely was too little time for me to teach her in a formal setting how it worked.
Also, as will become obvious, the logistics would not have worked if the programming “team” had more than one member. Denise did not want to travel more than necessary.
Another big disadvantage was that it took much longer to write code for the printer than to write reports that could be sent to the printer driver for translation. We had been using the AS/400 long enough that we had that process down pat.
Furthermore, because TSI did not have a printer that could handle the oversized form, there was no way to test the finished product in the office in Enfield. I had to write little programs that produced segments of the calendar, test them on an HP printer that we did have, and then write the code that stitched them together. Also, I could not even look at the output on the screen. I ended up delivering the code to M&F in person and testing it at their site with real data.
I should mention that Denise did not like this kind of cowboy coding at all. She thought that everything should go through the tried-and-true process.
Finally, if M&F had run into problems with the calendar when I was on the road—which I often was during that period—Denise and the programmers might have trouble isolating the cause.
In retrospect it might have made sense for me to decline this project. Someone from the May Company would probably have stepped in to help them find a reasonable substitute. However, I wanted a happy client, and I was quite sure that the people at M&F would not have been happy with anything less than what I did.
I did get the calendar program to work, and I do not remember them reporting problems with it after the first few days. I might have needed to make small changes to handle situations that they forgot to tell me about. That almost always happened.
According to my notes by February 25, 2000, things were going reasonably well:
So far I have not picked up specs for a lot of custom programming. I spent much of yesterday working on the calendar and the insertion orders. I finally got the calendar so that it is exactly the way they wanted it. The first faxed insertion order cut off the top ten lines of the page. I fixed it by rotating 270 degrees instead of 90. I can’t understand why that would make a difference. We also had a query class for the people who have some experience in working with AdDept.
Life in the M&F advertising department: In general the people in the department, like nearly everyone that I met from the May Co., were hard-working and enthusiastic about their jobs. They did feel that they were the parent company’s ugly step-child, and there were many things besides the outdated electronic equipment to bolster that feeling. For example, there were no restrooms on the thirteenth floor that the department occupied. The store’s selling floors certainly had very nice restrooms, and the employees were allowed to use them. However, that involved taking an elevator down from the thirteenth floor and back, which could add several minutes to the project.
The alternative was to climb the stairs up to the fourteenth floor. That floor must have had a purpose at one time, but by 1998 it was just a relatively empty area with plumbing. I found it sort of exciting to go up there. It was like being in someone else’s attic. You never could predict what had been put up there just to be out of the way.
I used the men’s room up there whenever I felt adventurous. It was quicker, and I had very low standards in those days. The picture on the right is surely worth a thousand words. There was only one stall in the men’s room, but it was almost never occupied even though, as you can see, the one urinal was permanently out of order. The sign on it helpfully advised “DON’T PEE HERE.” Someone had added a “K” to the verb.
I seem to recall that there was also a ladies’ room up there, but it did not get used much. At any rate I did not try to persuade anyone of the fair sex to take photos for me.
This was not the only unusual sight at M&F. Here is what I wrote on February 25, 2000:
Meier& Frank is a strange place. They have by far the worst facilities of any department store I have been in. I will try to take some photos today. One guy’s office is so small he can easily touch both walls at the same time. Several people are sitting in a former conference room. There is a pile of discarded computers in one hallway. Many places are dirty. One corner in the main part of the office had huge dust bunnies. It could not have been cleaned in months. Nevertheless, everyone seems in good spirits.
Most of my time in the the first few trips was spent with Dori. She had a small desk in a fairly large office that also held a lot of records and that big printer. Dori had one very peculiar trait, that she did not try to hide. She would verbally accompany her work with a softly spoken play-by-play: “I am walking over to the printer to get the schedule. Now I am getting last week’s schedule out of the file. Now I am taking them to …”
At the time I found it incredible that they would put up with this annoying behavior. In retrospect I think that I was too judgmental. She did her job, and they kept her isolated enough that she did not drive anyone else crazy.
I remember that for one visit they assigned me to work in a very small two-person office. I swear that it was so narrow that I could touch two parallel walls at the same time. I was put there because one of the occupants was on vacation. I found my temporary officemate quite funny. I remember that he had posted on the wall a cartoon of Beavis and Butthead talking about the newly elected team of Bush and Cheney. The balloons read “He said ‘Bush’, heh heh,” and “He said ‘Dick’, hee hee.”
In those days I drank a lot of Diet Coke and Diet Pepsi. I couldn’t tell the difference, but I could definitely tell if someone served me an off-brand. I happened to mention that I once tried to mix them. The guy with the cartoon solemnly warned me that that might not be legal.
I had completely forgotten about the following until I read it in my notes from February 23, 2000:
Brent got a call from someone from the May Company. Evidently they are considering getting new AS/400’s for both Meier & Frank and Filene’s because Dave Ostendorf told them that IBM is withdrawing support for the CISC systems.
Robinsons-May and Filene’s definitely got much faster systems, but I don’t think that M&F ever got an upgrade.
Life in and around Portland: I think that on our first visit Doug and I stayed in a Holiday Inn on the other side of the Willamette River. On later visits I think that I must have stayed somewhere closer to downtown. I ran nearly every day in those years, and I have a vivid recollection of running both through the streets of downtown Portland and in a large park along the Willamette River. I considered it very cool that the city allowed its citizens easy access to the riverfront. By contrast it was almost impossible to get from downtown Hartford to the banks of the Connecticut River on foot.
My memories of running in Portland are vivid and diverse, but I cannot remember being in a single restaurant or any other kind of store there. I think that I might have purchased lunch from a food truck or from a kiosk in the beautiful Pioneer Square, which was right across the street from M&F. I often saw a human statue there—a guy with silver clothes and makeup who posed in the square. In the above photo he is taking a break. I could not imagine a worse job than his.
Here are some tidbits that I wrote on June 12, 2000:
I often see strange things on the streets of Portland. Tuesday a pit bull was chained to a parking meter. It had a stick in its mouth. A guy was playing the “Lone Ranger” part of the overture from Rossini’s Guillaume Tell on a mandolin.
Someone from Salem Oregon stole over 300 lawn ornaments and decorated her lawn with them. She had hit houses in five counties.
I could park my rental car all day at a surface parking lot near the M&F store for a reasonable price if I arrived before the stores opened, which I always did. I also remember a building that had a huge octopus atop its front door, but I do not remember what was inside.
On the last few trips to M&F I stayed at a Homewood Suites hotel in Vancouver, WA. I selected it because it served free breakfasts and because it was fun to run along the mighty Columbia River.
The drive from the Homewood Suites to the M&F building, which was less than ten miles, was mostly on I5 and ordinarily took me only about fifteen minutes. If there was heavy traffic or an accident it might take twenty minutes, but I am pretty certain that I never spent as much as a half hour on the trip.
I remember that one of those evening runs was shortly after my tendinitis of the IT band had been diagnosed, and I had begun the prescribed exercise regimen. This outing was the first time that I had really tested how my knee had responded to the therapy.
I had to stop a couple of times because of the pain, but a thirty-second stretch allowed me to resume running. This was very encouraging to me because it indicated that the doctor’s diagnosis was accurate.
Homewood Suites.
My jogging path.
Sailboats on the Columbia.
Epilogue: The M&F advertising department used AdDept up until 2002, at which time the division was folded into the Robinsons-May division of the May Co. The stores still carried the M&F logo until 2006.
The flagship store in Portland, which at the time carried the Macy’s logo, was closed in 2017. The structure is still relatively intact in 2022. The developers have posted a web page that describes its current state. You can view it here.
The principal occupant is a luxury hotel called The Nines, but several other businesses are located.there including a Japanese store called Muji.
2. Dori Tierney’s Facebook page is here. When I looked she had three times as many friends as I had.
3. Sheila Wilson returned to Hecht’s after M&F was folded into Rob-May and then worked at Marshall Fields/Macy’s in Minneapolis. Her LinkedIn page is here.
In the eighties IBM sold two mini-computers1, the System/36 and the System/38. It was hard to understand why. They both supported the same programming languages (RPG, COBOL, and BASIC), cabling, and peripherals. They both were aimed at small businesses that used them for traditional “business” applications—as opposed to graphics or calculation-intensive jobs. There was a large overlap in the targeted customers for each system. Both systems were even designed at the same IBM facility in Rochester, MN.
For several months rumors abounded in the trade magazines for these products that IBM would soon announce a new computer to replace both of them. The code name was Silverlake.
The announcement was made on June 21, 1988. I attended a briefing at the IBM office in Hartford. The name of the new system was AS/400. The “A” stood for “application” because every program ever written for either the S/36 or the S/38 would run on the new system. Neither the S/36 nor the S/38 could be upgraded to an AS/400, but the new system accepted all of the software and most of the peripherals. The thrust of the pitch was that IBM was providing the “best of both worlds.”
A System/38.
This claim was possible because the “native” environment of the new operating system was based on the System/38. The new system also supported a “System/36 environment” that allowed programs written for that system to run with no changes. Since the native environment was much more efficient than the S/36 environment, software developers were expected to migrate their code to the native environment as soon as they could.
My immediate interest was in the price of the low-end systems. I was bitterly disappointed. The least expensive model, the B10, cost much more than the 5363, which was a perfect fit for most of our target market. Once again, IBM just refused to address the millions of small businesses that could be served very well by an economical system that could handle a handful of simultaneous users. In 1987 IBM had finally introduced such a system. With this announcement just one year later a perfectly good solution was replaced by a much more expensive and unproven one.
So, from the perspective of selling to local advertising agencies and other small businesses, the announcement was a nightmare. However, as is described here, Macy’s gave TSI no choice but to embrace the AS/400. They wanted to hire us to develop a system for them, but they had no interest in purchasing obsolete hardware.
IBM’s approach eventually worked out in our favor. The AS/400 had many outstanding features that were not available on the System/36.
The B10 was the size of a two-drawer file cabinet. The B60 required four racks. All were announced in 1988.
The new system’s operating system was built over a relational database. I am not sure that most people in the S/36 community knew this at the time because IBM did not even mention it at the announcement meeting, and the database was not even given a name (DB2/400) until much later. All anyone knew was that it sure had fast file access.
The defining feature of the operating system was inherited from the System/38: Single-Level Store. I never have understood this completely, but the effect was that the main processor did not care whether programs or “pages” of data were already in memory. The task of managing storage was managed by other processors. So, the problem that occurred on the System/36 when too many jobs were running simultaneously would not occur on the AS/400. Moreover, the compiler on the AS/400 took advantage of this setup to make the programs run much more efficiently under normal conditions as well.
For our purposes the big advantage of the AS/400 was that BASIC programs on the AS/400 were compiled, not interpreted. This meant that we could externalize routines that were performed by many programs, and one program could call several other programs that could run simultaneously as “batch” jobs without tying up any terminals. These were huge advantages.
The BASIC interpreter that was invaluable for debugging was NOT eliminated.
The AS/400 operating system was designed to be able to take advantage of future hardware advances. Because potential customers were more concerned about solving their immediate problems, this was not a great selling feature. However, it was definitely a great “keeping” feature. Ever program that we wrote in 1988 still works on hardware marketed by IBM thirty-one years later!
The first announcement did not require this, but eventually every AS/400 came with a 1/4” cartridge tape drive. This eliminated the nightmare of having to convert repeatedly from one storage means to another.
Priority could easily be assigned to certain jobs.
A modem could be attached for faxing. Our AdDept customers used these for insertion orders until we devised a better way of handling them.
The system could be attached to an Ethernet or Token Ring network.
IBM’s query tool was a big improvement. We insisted that all of our clients licensed it, and I personally trained at least one employee in its use. That worked fine unless the person who had been trained left the company or was reassigned. We also offered support for designing and helping with queries, but we charged a monthly fee for this service.
Printing was much more flexible. Even laser printers attached to PC’s could be used for printing reports. I learned PCL, Hewlett-Packard’s printer language, so that I could design customized reports with fonts and simple graphics (borders and the like could be generated on HP printers. This was very popular with our customers.
Although some things continued to frustrate me about the AS/400, I grew to appreciate it more and more. It was not designed for tiny developers like TSI, but it allowed us to produce software with features that went way beyond the capacity of any model of the System/36. By the time that the E models of the AS/400 were released in 1992, the low-end systems represented very good investments for the companies who were interested in TSI’s products and services.
On the other hand, IBM’s approach meant that independent developers who marketed to the end users directly rather than to IT departments—and there were a lot of us—had to devised a way to survive until IBM provided us with a reasonably priced product. Those four years were very difficult for TSI. The company survived, but the grim reaper’s shadow was on our door quite a few times.
TSI’s B10 had a diskette drive and a QIC tape drive.
Over the course of twenty-six years, TSI had at least four AS/400’s (or follow-ons. named iSeries or System i) All of them worked spectacularly well. We hardly ever called IBM for either hardware of software support. We purchased or leased all of them at big discounts because we were developers. On the first one, a B10, I prudently scraped together enough cash2 to order the maximum amount of memory and disk. It was adequate for development purposes, but if one of our clients had tried to run its business on it, it would have been embarrassing. For one thing the operating system itself required almost half of the unit’s disk space! Subsequent releases of the OS required much more disk.
Still, we lived with it, and we came through on the other end.
How well did the strategy work for IBM? In 1988 IBM was one of many competitors in the mini-computer market. The others were DEC, Hewlett-Packard, Data General, Wang, and a host of other companies. By the mid-nineties all of the competitors had conceded the entire market for reasonably priced multi-user computers to IBM. All of them except HP went out of business, and even HP (after several mergers) now makes and sells only PC’s and printers. This stunning event went almost unnoticed by most so-called experts. They blamed poor management by these companies for their demise. Were they all stupid? No, the AS/400’s were demonstrably superior.
Lou Gerstner.
The mini-computer market still exists, but almost no one talks about it, because IBM has hidden its premier product inside hardware with other brands. The only thing that IBM left for the AS/400’s legions of devotees to cling to was the letter i. When Lou Gerstner took over the reins of IBM in 1993, he put a heavy emphasis on services, which were very profitable, over hardware and software, which evidently were not. So, Gerstner never liked the AS/400 approach because the IT departments that used it had little demand for IBM services. For example, at some point in the twenty-first century I visited Macy’s IT department in a suburb of Atlanta. Dozens of IBM employees went to work there every day. One extremely large office contained desks for them and no one else. Macy’s had several AS/400’s or i series systems there. One person managed them all, and he worked for Macy’s, not IBM.
Users of TSI’s software systems loved their AS/400 computers, and they never purchased any services from IBM beyond maintenance contracts.
The AS/400’s operating system (OS/400) employed strict typing of objects. Every object had one and only one type, and it was unchangeable. On a PC a developer—or even an end user—can change the type (as designated by the three-digit “extension” after the period). For example a text file named sample.txt can easily be changed to a comma-separated-values file sample.csv. Users could even make up their own extensions.The operating system might warn the person that changing the extension might make the file unusable by certain applications, but it would still allow it.
The AS/400’s native environment, in contrast, had a limited number of well-defined object types, many of which had equally rigorous subtypes:
Database files could be physical or logical. A logical file is equivalent to what is called a “view” in SQL.
Programs had subtypes for each supported language. A new language called CL3 was added.
Menus were lists of options displayed on the screen, usually with a command line at the bottom. Each option had a number.
Commands were routines that could be invoked on any command line. A command was essentially a shortcut for calling a CL program.
The names of the commands supplied by the operating system. were consistent throughout: VVVAAANNN, where VVV was a three-character abbreviation of a verb, AAA was an optional three-character abbreviation of an adjective, and NNN was a three-character noun. For example, DSPSYSVAL was the command for Display (DSP) System (SYS) Value (VAL).
Most commands had parameters. For example, the GO command required the name of a menu object as a parameter. GO BACKUP caused the system to display and execute the menu object named BACKUP. Pressing F4 after keying in the command displayed a data entry screen for all of the parameters.
TSI created a large number of commands in
Several other object types, such as line descriptions and spool queues, were used by the system software. Most system objects of all types (except commands) began with the letter Q.
BLOBs were objects that did not fit any of the other types. They included all types of images, video, sound, etc. They were added in later releases.
Users could not create new object types or subtypes, but new ones often appeared in new releases of the operating system.
Every object had a name, which was limited to only ten characters. A letter was required for the first character. The other characters could be letters or numbers. A few special characters were also allowed. The names were NOT case-sensitive.
Every object resided in a library, which was itself and object with a ten-character name. This was a departure from the S/36, where data files were not assigned to libraries. On the AS/400 two objects in the same library could not have the same name.
On the S/36 and for a short time in the S/36 environment on the AS/400 TSI used periods in the names files that were associated. For example, files that began with “M.” in the GrandAd system were media files. In the native environment of the AS/400 such files caused a problem for some third-party programs that users might wish to employ to create customized reports. So, TSI changed the names so that the first one or two characters served to group files.
Third-party programs and programs written in other languages also had difficulty with integers that were left-padded with blanks4, as BASIC programs have always done. TSI changed all of its programs to pad integers with zeroes instead of blanks. So, when the value of a three-digit number was 15, it was written on the AS/400 database as 015, not (blank)15.
1. The terms mini-computer and midrange computer referred to multi-user systems that were not powerful enough to run the business applications of major corporations. The System/36 and System/38 were certainly mini-computers. At its introduction so was the AS/400. The twenty-first century models, however, were more powerful than the mainframes of the eighties.
2. I suspect that TSI actually leased it.
3. CL stood for Control Language. CL was the easiest language ever. It was simply a list of commands to be executed in order. Since CL programs were compiled, they could be called from other programs written in any language.
4. I considered this an intolerable bug in the software developed and marketed by the other company. I encouraged the person trying to use the software to complain to whomever claimed that the product would work on AS/400 files. Eventually, we changed our files and programs to forestall a brouhaha.
