2001-2006 TSI: Weekly Partners’ Meetings

Posted on May 4, 2023 by Mike

Agendas for meetings. Continue reading →

Between January of 2001 and November of 2006 I met pretty often with Denise Bessette (introduced here), who was by then my partner and VP of Application Development. I found a folder of Microsoft Word files for the agendas that I wrote up for these strategy meetings. Starting in 2003 the meetings became more regular. They occurred on many if not most Wednesdays, the day that I was most likely not to be at a client’s.

We generally ate lunch together at an order-at-the-bar restaurant on the west side of the river. It had picnic tables near a small stream. I can’t remember the name of the place. I took a drive in the area that my memory associated with its location, but I could find no trace of it. I suspect that it closed, and the land was bought by a developer who put it to another use, perhaps condominiums.

The following summaries are mostly in chronological order. Almost every AdDept client is mentioned at some point. Separate blog entries with much more details have been posted for each of them. They can easily be found using the 1948 Project’s master index program, which is available here.

Many items on the agendas are repeated on subsequent agendas. A few of them persist over years. These were issues for which we never found solutions. The most obvious examples were the efforts to find additional uses for A^xN that would benefit newspapers and/or advertisers.

By 2001 the nature of and name for A^xN¹ had been decided. Our focus was on how to roll it out to the AdDept clients and what we could do to make it more attractive both to the advertisers and the newspapers. We also discussed potential support issues and how the new model 170 that TSI had recently purchased could handle the load of handling the traffic from AdDept clients and newspapers. Occasionally we talked about personnel and other business-related matters.

By 2002 the business environment for large department stores had changed dramatically. Before listing the agenda for one of the meetings I wrote, “We need to change our attitude 180 degrees. Previously we had excess demand and were struggling to increase our capacity to meet it. Now we have excess capacity, and our customers are frugal.”

I had used Net.Data² extensively for A^xN. At the time it was the only thing available on the AS/400 that could interact with the database. By 2002, however, IBM was telling people not to use it. However, it was several years before IBM provided an equivalent tool. Java³, which I had studied extensively and had concluded was not suitable for what we wanted to do, was IBM’s solution to everything.

I was surprised to read how uncertain we were about the willingness o AdDept clients to use A^xN. The meeting in March mentioned the need for a second installation. Before reading this I was pretty sure that Belk⁴ was the first, but maybe someone else had used it on a limited basis.

In 2003 Denise and talked a lot about what kind of programming was marketable to our clients. We investigated quite a few products that claimed to make it easier to make native AS/400 programs web-based . We also talked about what features could be added to A^xN so that it would be more valuable to advertisers or newspapers. Usually one of the last items on the list was whether we should spend time converting our code from BASIC to RPG or something else.

In May Sue and I took our first vacation in Italy. I wrote a journal about that adventure and posted it here.

The meeting of November 5 was the first mention of Bob Wroblewski, who has been introduced here. The next few agendas mostly consisted of the same items.

In January of 2004 Bob and I flew to California to visit Robinsons-May and Gottschalks. Bob then started enrolling Rob-May’s papers. After that the process of getting newspapers to subscribe to A^xN snowballed for several years. At about the same time our long courtship of Dick’s Sporting Goods finally paid off with a contract for AdDept. So, in only two years the outlook for TSI had improved greatly.

In February it occurred to me that there might be one dominant software company for the newspaper business. If we could create an interface with their system, it could advance the A^xN project tremendously. However, I later discovered that each paper, if it had anything at all, had developed its own software or paid someone to do it. There was no uniformity. Fortunately I discovered that this was a blind alley before I wasted a lot of time, money, and energy on it.

The agenda for the February 18 meeting made it clear that the A^xN project was about to take off. Most of the long-time AdDept users had at least been contacted. Stage Stores was enthusiastic, and they had just acquired another chain named Peebles. Finally, Dick’s Sporting Goods had finally signed the contract to purchase AdDept. To deal with the expected increase in use of the Internet by the newly subscribing newspapers Denise was arranging for installation of a T-1 line from AT&T with the Cox Cable connection as backup.

The March 3 agenda closed with a mention of the NAA, which was the abbreviation for the Newspaper Association of America (changed to News/Media Alliance in 2016). I eventually talked with someone at its headquarters, but I foresaw that it would take a lot of time and effort to build a productive relationship with the organization. It might have been a good project for Doug Pease (introduced here) or Jim Lowe (introduced here), but at that point they were in the rear-view mirror. I never thought that this would have been a good fit for Bob. Besides, he was busy talking to newspapers, or at least soon would be.

It took me a few minutes to decode this entry on the entry for March 24: “Robinsons: Lower price for LANG?” LANG was the Los Angeles Newspaper Group,^.5 a company that printed and distributed tabloids in Los Angeles and its suburbs. Advertising for all those papers was managed from one central location. TSI agreed to send them one bill. We treated them like one large paper with several editions.

In April we were waiting for Dick’s to begin the solicitation for A^xN before we approached Macy’s West and RadioShack. The April 21 entry contained positive news about Filene’s use of AdDept for accounting, including the monthly closing process. The next week Denise and I discussed the proposed trip to talk with Hecht’s main paper, the Washington Post. I ended up visiting them on May 14. It gave me quite a thrill, but I don’t think that they ever agreed to use A^xN. Apparently we also considered a press release about being in business for twenty-five years, but I am pretty sure that we never did it.

The agenda for May 26 poses this question about Filene’s: “Have they made a big mess?” Bon Ton agreed to send letters to its newspapers about A^xN.

In June we discussed various methods of emailing claims. I don’t recall that we ever took any action on this. There was ominous news from Federated that they put all quotes on hold. The total number of orders in A^xN exceeded 100,000. The June 30 agenda announced that Dick’s was moving into its new building over the subsequent weekend.

The first item on the July 21 agenda was “Denise’s three issues”. I wonder what they were. Item #10C talks about a follow-up meeting with the Washington Post that never happened. The next week’s agenda explained that they did not respond to my email. A second e-mail was sent on August 4. On August 25 (my dad’s eightieth birthday) I called the Director of Advertising Services.

Something distressing was evidently going on at Parisian, but I don’t remember what it was. That disclosure was somewhat offset by the following good news: “RadioShack: 34 active; 39 testing; 22 Macy’s West; 15 L&T; 4 Parisian; 56 other.” RadioShack did one of its four geographic divisions at a time. The last two entries brought up new subjects: “How can we make better use of my time and Lucia’s⁶?” and “5-year plan”.

The August 4 agenda was the first to mention SQL⁷. I used SQL for all of the A^xN programs, but the AdDept programs mostly created temporary indexed output files that were populated by one program and read by another using IBM’s recommended approach, ISAM (Indexed Sequential Access Method).

Marshall Field’s (introduced here), the last big installation of the May Co. version of the AdDept system, was first mentioned in the agenda for September 8. We were very excited about the meeting scheduled for September 16 at Hecht’s advertising department in Arlington VA. By this time the work for the Peebles installation at Stage Stores was operational enough that we were ready to solicit their newspapers for A^xN.

I was serious enough about contacting companies that sold software for ad agencies that I spent $35 to buy the booklet from the AAAA. I questioned whether we should write to each of them to propose an interface with their system and A^xN. I don’t remember ever doing so.

The agenda for November 1 mentioned that Field’s used an ad agency for both broadcast and newspaper. My recollection was that they started using A^xN almost immediately and dropped Haworth, the agency that bought newspaper space. However, later entries seem to contradict this. The same agenda mentions that TSI was carrying $55,000 in questionable receivables in the last month of its fiscal year.

I never had to make an onsite visit to our A^xN client in Guam.

The November 10 agenda mentioned that—after months of foot-dragging—Federated Systems Group was finally going to “cut over” to their new AS/400 system. During this period we were worried about providing support for A^xN for Macy’s West’s newspapers in Hawaii and Guam. This was needless. The papers subscribed for years without any problems. This was also the last agenda that included a mention of a press release about TSI’s twenty-fifth anniversary.

A major issue early in the year was how to handle the process for installing changes that Dick’s had forced upon us. There were other issues, too. The first agenda of the year ends with the question: “How can we get this installation on the right track?”

Two minor enhancements to A^xN for the advertisers had been completed: custom emails and downloading of email addresses. However, I had apparently given up on the possibility of interfacing with computer systems used by the newspapers. There was also a process for reconciling the orders on A^xN with the schedule on AdDept.

By March 10 we had a big programming backlog because of the large number of difficult jobs for Marshall Field’s. Denise controlled this process. I simply asked, “How can I help?” In the same meeting we discussed for the first time what, if any thing, we should do to forestall Macy’s from replacing AdDept with the system known then known as FedAd that had been developed by Burdines. Our contact at Macy’s West stated that “it did not exist”.

At the March 25 meeting we talked about Macy’s East for the first time in many months. For the April 28 and May 4 meetings there is separate agenda for A^xN. For some reason I seemed worried about using it at Foley’s and Stage Stores.

The first item on the regular May 4 agenda was one word: “Lucia”. Lucia was able to handle much more challenging projects than our other administrative employees. The problem was trying to come up with things for her to do. Another issue on the same agenda posed some interesting questions:

We never mastered the trick of Cloud Computing.

How could we set ourselves up to manage systems for our small clients? Bon Ton, Gottschalks, Neiman Marcus
1. IBM (like Federated)?
2. TSI
  1. Dedicated high-speed line for each user?
  2. On the net?
    1. Telnet? How would they print? Pdf?
    2. VPN: AS/400 to AS/400?
    3. VPN: PC to AS/400?
  3. High availability?
  4. Disaster recovery?
3. A third party?

We did not spend a great deal of effort on trying to provide “cloud” computing for our customers. It would have involved a great deal of expense and risk. Just seeing that term “disaster recovery?” item gives me the chills.

Later in May Sue and I took our second Italian vacation with our friends Tom and Patti Corcoran. I wrote a journal again, but this time I had a camera. The results are posted here.

The agenda for June 2 began with the surprising news that Chuck Hansen at Marshall Field’s had asked me to back off on A^xN. It also mentioned the agenda for a meeting with Macy’s Marketing on 5/17. It probably intended to say “6/17”. The next agenda, dated July 8, only stated, “Follow up with …” I must have forgotten the name (Robin Creen) of the lady with whom I met at Macy’s Corporate Marketing. There is also a reference to Bloomingdale’s. I suspect that this was in response to information from Tom Caputo, who worked with AdDept at both Lord & Taylor and Saks Fifth Avenue, that Bloomies had never taken the FedAd software out of the box.

The July 11 agenda has some detailed information about a proposed newsletter publicizing how AdDept handled inserts. Some of these enhancements were done for Dick’s.

The August 26 agenda has a new and somewhat mysterious major topic called “AdDept ideas”. The two subtopics are “SpooliT⁸ ($9K) or other Excel” and “Service Bureau”. I think that SpooliT made .csv files out of spooled output files. It may have had a few other features.

Throughout this period there were references to The Oregonian, the major paper in the Portland area that stopped paying invoices for A^xN without canceling and never responded to attempts to find out why.

The agenda for September 14 mentions the long letter that I sent to Robin Creen. Its contents are posted here.

The agenda for October 12 had several tantalizing references. It began by stating that IBM’s VPN⁹ product, which TSI used for communicating through the Internet, with clients’ AS/400s would be activated on the following Saturday. It also reported that a newsletter had been sent out.

Robin Creen topped the October 24 agenda, but there were no details. The second item referred to renewal of iSeries News, a magazine.that catered to the AS/400 community. It had undergone many name changes, and the content had also evolved. We kept all of the back copies in the shelves that in 2023 are in my office. When we closed down the company (details here), I threw all of them away.

The third item was “SBC Contract”. I don’t remember SBC, but I suspect that it was an IBM Business Partner that had sold more systems than we had or had somehow managed to deal directly with IBM. During this period TSI was not allowed to quote or sell any IBM products. We had to go through a Super-VAR.

The fourth item was “Lucia” with no details. The fifth was “AT&T Global: do we need it?”. I am pretty sure that this product allowed me to get my email when I was on the road. In the days before Wi-Fi I had an AT&T product installed on my laptop that allowed me to use a phone line in my hotel room to sign on to AT&T and look at my email.

We must have received an inquiry from Sport Chalet¹⁰ a chain of stores in California that was similar to Dick’s. Until I saw this entry again I had completely forgotten about them. Evidently I wrote them a letter and sent them a newsletter, but nothing came of it.

The last agenda for 2005 was dated December 6. The #1 item was the blitz to get an AdDept system for Macy’s South up and running in time for the season that started at the beginning of February. The second item was an inquiry from Circuit City¹¹. This was another dead end.

The “My disk recovery” entry brought back some really bad memories. I think that I recovered everything on my computer’s hard drive, but it was costly and painful. The best part was that I got an external hard drive¹² that made it very easy to back everything up.

There are no entries for 2006 until June. I remember being under extreme pressure to bring the two huge AdDept installations at Macy’s South and Marshal Field’s up to speed. Meanwhile we received the crushing news that Macy’s and the May Co. had merged, and Macy’s would be the dominant player.

The agenda for June 13 began with the word Corum. I am pretty sure that it referred to broadcast buying software. Based on the date it was probably associated with Macy’s South.

That agenda also contained a major item that simply stated “Modernizing and marketing AdDept”. We never did find a feasible way to transform the AdDept screens into something that looked modern. We made more marketing attempts after this, but they did not amount to much. This was the peak period for A^xN. More than four hundred papers had subscribed. TSI’s administrative person spent a good deal of time printing and mailing invoices and depositing checks from newspapers.

The agenda for October 11 was startlingly different. It mentioned two AS/400 models, a 170 and a 270. My recollection is that we did development and ran the business on the 170, and the 270 was devoted to A^xN. It also mentions recruitment. I am not sure whether that referred to the administrative position or programming. The agendas have gotten shorter and shorter.

This agenda also mentioned the C compiler for the 270. Denise was upset at me for even investigating the possibility of converting TSI’s code to C, which was widely used in the Unix world.

In the agenda for October 18 the scary term “Macy’s North” appeared several times. It referred to the company that was formerly called Marshall Field’s. Evidently the marketing (never called “advertising”) department there had never bought into using A^xN for insertion orders. They may have still been using Haworth.

“Maintenance” was often mentioned in the agenda for November 1. We probably never charged as much as we could have for the kind of service that we provided our clients. I was evidently still spending quite a bit of time at Belk.

I was surprised to see Circuit City mentioned again on the agenda for November 8. We must have received another phone call. The term “Foley’s project” also appeared. I am pretty sure that that was the code name for the long and frustrating effort that Denise and I undertook to sell the company.

The last agenda that I have was dated July 10, 2007. It contained only four items:

Trip to Macy’s West
515
Dick’s quotes
Foley’s

Denise and I continued to meet, but not on a formal basis. By then I had almost given up on selling more AdDept systems. There had been so much consolidation in retail that the number of good prospects for the system had shrunk to almost nothing. Nordstrom and Dillard’s would have looked nice on our client list, but it was hard to think of anyone else that was worth pursuing.

We still did quite a bit of custom programming during the next five or six years, but managing the list of open jobs did not require the juggling act that had characterized the previous decade.

The A^xN business decreased for a few reasons. The big stores no longer trusted newspaper ads to bring in customers as they once did. Newspaper readership was way down. Some of the AdDept clients outsourced their buying to agencies or media services. That always meant a drop in the number of papers.

I enjoyed those meetings immensely, and I miss them.

1. The history of the development of A^xN is posted here. The system design is outlined here. The description of the process by which it was brought to market begins here.

2. Net.Data was a scripting language written by IBM for the AS/400. It was quite popular, but IBM for some reason decided to drop it in favor of the open source scripting language php, which required implementation of the Zend php engine.

3. Java is an object-oriented language that was developed by people at Sun Microsystems. The company released an open-source version. Java was almost the only thing that IBM talked about at the PartnerWorld convention that Denise and I attended in 2000. It is described here. On the AS/400 applications written in Java required a lot more resources than programs written in the native languages. If run on the same box the Java programs were slower, a lot slower.

4. The history of the AdDept installation at Belk is posted here.

5. In 2016 LANG merged with the Orange County Register and a few other papers. The new organization was called the Southern California Newspaper Group. The third item under the Federated topic was “AxN letter to four divisions”. Since “Bloomingdale’s” was the second item it mus refer to Macy’s East, West, South, and Florida (Burdines).

6. Lucia Hagan was TSI’s administrative person during this period. She was introduced here.

7. SQL stands for Structured Query Language. It was invented by IBM, but the company did not endorse its use on the AS/400 until 2004.

8. SpooliT is still on the market in 2023! Its website is here.

9. VPN stands for Virtual Private Network. The Wikipedia entry is here.

10. Sport Chalet was sold to Vestis Retail Group in 2014 and was liquidated in 2016.

11. The sad story of Circuit City ended with its liquidation in 2009.

12. I still have that hard drive in 2023. However, I recently discovered that I no longer can find the cable that was used to attach it to a computer, and the company that made it was no longer in business.

1999-2002 TSI: The Million Dollar Idea

Posted on August 30, 2021 by Mike

The genesis of AxN. Continue reading →

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.

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é² 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 Owen³ 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?⁴
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)⁵, the AAAA⁶, 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 spec⁷, 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/400⁷. 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 Cancilla⁸, 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/400⁹. 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 A^xN, 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 AdSEND¹⁰. 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 A^xN.

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 A^xN, 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 A^xN 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 A^xN 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.

1988-2014 TSI: The IBM AS/400 and its Follow-ons

Posted on May 10, 2021 by Mike

An amazing system. Continue reading →

In the eighties IBM sold two mini-computers¹, 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.”

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 cash² 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.

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 CL³ 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 blanks⁴, 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.

1983-1988 The IBM System/36

Posted on May 8, 2021 by Mike

A true multi-user system. Continue reading →

A 5360. The box on the top left is the diskette magazine drive.

IBM’s introduction of the System/36 (S/36) in May of 1983 was not a monumental event for TSI. From our perspective the new system seemed more like a marginal upgrade of the System/34, which had always been much too pricey for anyone who would talk to us. The new system had only one basic model, the 5360. The starting price for one of these was still $140,000. It was also gigantic and had special electrical requirements. It was clearly designed for a small data processing department, not a small business without one.

The biggest advantage of the System/36 over any system that we had worked with was that it supported a fairly large number of terminals and printers. This was because it could run a number of jobs at the same time. It also supported batch processing, which meant that time-consuming jobs need not tie up any workstations.

We appreciated these benefits. In fact, we drooled over them. However, no prospective customer of ours ever had a six-figure budget for hardware.

The 5250 screen showed one color, green.

The peripherals were also rather expensive. IBM in those days ignored standards used in the rest of the industry. It set its own standards, and they were all proprietary. So, cheaper hardware from other vendors would not work with IBM systems.

Although the price went down through the years, a 5250 terminal cost around $2,000 when the 5360 was introduced. The cheapest printers, which used dot-matrix technology, were in the $5,000 range.

Both ends of twinax cables were male. A device with two female ends was needed to connect two together

The cabling was also not cheap. The system used twinaxial cables for direct attachment of these devices. Most competing systems used serial or parallel connections. Twinax was decidedly better, but it was also more expensive.

The local devices were connected in a serial fashion to a controller. Up to seven devices could be connected on one twinax line. Each device had two female twinax connections on the back, either in one T-shaped unit or with two short cables. One was called the “gozinda”; the other was the “gozouta”.

So, if the S/36 had four devices named A, B, C, and D. A would be connected to the controller by a twinax cable, B would be attached to A by a twinax cable, C would be attached to B, and D would be attached to C.

A switch on device A, B, and C needed to be set to allow pass-through to the next device on the line. On device D that switch needed to be set to denote that it was the last device on the line.

For device D to communicate with the S/36, all of the connections must be functional, and all of the switches set correctly. It reminded me of Christmas tree lights in the old days.

The S/36 also came with a serial port. Since a modem could be attached to this device, it would be possible for support people at IBM or the software vendor (or anyone else, for that matter) to sign on from a remote location. This was, of course, our dream; it would make support so much easier. The announcement brought it a little closer to reality.

The hard drive capacity varied from 30 MB to 400 MB. In the twenty-first century, of course, those quantities would only hold a handful of photos. However, to most software vendors in the eighties this meant that total storage was no longer a big concern. However, the default backup device was a magazine that held only ten 8″ diskettes. Each diskette had a capacity of only 1MB each. This was a rather obvious limitation on the practical storage.

It was possible to attach an 8809 1/2″ reel-to-reel tape unit to address this. I could not find a price for these monsters. It may well have been the case that if you had to ask the price, you could not afford it.

The System/36 had two processors. The main processor (MSP) executed the code; the control processor (CSP) managed the work for the main processor. The CSP was four times as fast as the MSP, and they worked perfectly in tandem. The S/36 could perform an amazing amount of work at very fast speeds with embarrassingly puny processors. It was also extremely reliable.

Some actions, such as IPL¹ and backing up files, needed to be initiated from the system console. The system console on the 5360 was built in to the top of the box. Your system operator needed a wheelchair? Life was rough all over.

The System/36 supported five programming languages: RPG II², COBOL, FORTRAN, BASIC, and Assembler. RPG II, a simplistic column-based language, was the most popular. Wikipedia says that this was because it was the least expensive³. The BASIC language was similar to the one used on the Datamaster. I never heard of anyone who programmed in FORTRAN or Assembler on a S/36.

BASIC programs could not be compiled. Therefore, a copy of the BASIC interpreter needed to be loaded into memory for each program that was running. Nevertheless, because the CSP was so efficient, TSI’s benchmarks showed that there was no noticeable difference in the speed of interpreted BASIC programs and compiled RPG II programs performing the same tasks. So, we never considered converting our program to anything besides S/36 BASIC.

IBM also positioned the System/36 with its DisplayWrite/36 software as a word processing server. We found it to be inferior to the Datamaster product in most ways.

The file structure of the S/36 was somewhat different from the Datamaster’s. Programs and other executable items such as BASIC procedures and system procedures were stored in “libraries”. Libraries were somewhat like directories or folders on a PC. However, there was no such thing as a sub-library.

Data files needed to have unique names. They did not reside in libraries. In order to identify which files belonged to which application, the names were preceded by a short identifier and a period. In GrandAd all the media files started with “M.”, and the other files started with “T.”.

The S/36 did not have a relational database⁴. However, the fields in each file were defined in the system using field names, positions, and length/type designations. These data definition specifications were called DDS. Programs could access files using the same ISAM techniques with which we were already familiar. However, IBM also offered a product named Query/36 that allowed someone who know how the files were named and structured to write queries in a manner that was similar to SQL. These queries could then be saved and executed on demand.

Query/36 was a valuable debugging tool. TSI required all of our clients to buy it.

IBM announced the 5362 in 1984. It was much smaller than the 5360—only about as large as a two-drawer file cabinets. It also had no special electricity requirements. It used the same operating system as the 5360, which was called SSP. It came with one diskette drive and up to 120MB of hard drives. A QIC (1/4″ cartridge) external tape drive was available. A 5250-type terminal plugged into the first twinax spot served as the system console. Fewer devices could be attached, but none of our clients ever reached the limit. Best of all, the starting price was only $20,000, about the same as two Datamasters and a hard drive.

Many advertising agencies in the northeast could afford this level of investment. It took some time for TSI to convert the ad agency programs. I remember spending many days at IBM’s office in Hartford working on this. After tat we needed to change the focus of our marketing efforts to larger ad agencies. At this point IBM had no system to offer to the many whose needs would be satisfied with one Datamaster with diskette drives.

We were happy with this announcement, but it was a disappointment that IBM had totally abandoned the market that had produced the majority of TSI’s sales.

The 5364 (or System/36 PC), which was announced in June of 1985, was IBM’s belated attempt to recapture that market. The starting price of $5,995 was quite attractive. For some reason the system console had to be an IBM PC, XT, or AT with a special card inside. The S/36 part was the same size and shape as an AT. It contained a 5 1/4″ diskette drive that was compatible with neither the attached PC nor any previous model of the S/36. Compatibility was not a high priority for IBM.

This is what the system console looked like with the PC on top of the 5364. Manute Bol found it very convenient.

This bizarre arrangement was very difficult to explain to a prospect. Why would a super-reliable S/36 be coupled to the least reliable hardware ever to wear the IBM logo? It did guarantee that at least one IBM PC was installed at each location, I guess. However, most installations probably did what we did—attach the oldest, slowest machine available as the system console, and then use it only when necessary.

The 5364 had two severe limitations. In the first place, only four devices (counting the system console and the printer) could be attached. So, the S/36 customer could really only attach two more displays or one display and a printer. Still, that would suffice at most small ad agencies and at TSI. We immediately ordered one.

The other limitation was, in some ways, worse. The 5364 came with only 256K of RAM. Each session could use up to 64K. However, batch jobs counted as sessions. If one person started some lengthy reports or other process, the system could possibly reach the point where jobs needed to be swapped between memory and disk. This could severely impair the system’s performance.

The announcement of the 5364 created a good deal of business for a company named Black Box. They sold a box with slots for one 8″ and one 5 1/4″ diskette and software to make image copies from one to another. We bought one, and I used it a lot.

This is a 5363 with both a diskette drive and a QIC tape drive.

In 1987 IBM finally fixed all of the problems, at least the ones that most concerned us. The 5363 was a reasonably priced machine that was suitable for almost any small business. If it had been announced two years earlier instead of the 5364, we could have sold a lot of them.

I could not find anything either on the Internet or in our basement that listed the price of one. I don’t remember that anyone balked at the cost. I also could not discover how much memory it had, but I remember distinctly that it was plenty. It could handle at least seven devices, too, and you could get one with a built-in QIC tape drive.

We enthusiastically ordered one for TSI’s office and tried to get our Datamaster customers excited about it.

By the middle of the eighties most office workers had some kind of personal computer on their desks. They did not want someone to install a terminal next to it as well. But how could they gain access to the S/36 without a terminal? There were no networks worth mentioning in the eighties, and there was nothing like USB. The only way to reach the server was through a twinax line, and IBM did not share its knowledge of how the display and printer connections worked. IBM considered anything that it produced was proprietary.

IBM and many third party companies brought 5250 terminal-emulation packages to market. The idea was to be able transform the PC into a terminal on demand and then change it back. Although the other vendors had to reverse-engineer the 5250 interface, they still were able to produce competitive products that were cheaper and had more features than what IBM offered. They generally consisted of a three pieces:

A hardware card that fit into an expansion slot on the motherboard of the PC. That’s right. You had to take the cover off of the machine and add a card that had the brains needed to make the PC act like a 5250 card. You might also need to physically flip switches on the care to configure it. Then you had put the PC back together again. What could possibly go wrong?
A dongle (sometimes lovingly referred to as a “pigtail”) that screwed into the interface on the part of the card that stuck out the back of the PC. It provided a gozinda and a gozouta for the twinax cable(s).
Software to run on the PC.

When they first appeared, the cost of these packages was well over $1,000, nearly as much or more than a PC or terminal. However, the emulators had one very substantial advantage. The inexpensive printer attached to the PC could also be configured as a S/36 printer. This not only saved money and office space; it was also much more convenient.

For a few years the companies selling these packages did a land-office business.

1. IPL stands for Initial Program Load. It just means the starting process for the system. IBM had three-letter abbreviations of everything, including a three-letter abbreviations (TLA).

2. RPG is short for Report Program Generator. I could never understand why anyone used it.

3. IBM required separate licenses for each programming language that was used.

4. Two IBMers, Donald D. Chamberlin and Raymond F. Boyce, codified the Structured Query Language (SQL) used in relational databases in the seventies. IBM rejected it because the Indexed-Sequential ISAM structure that it used in its computers had much better performance. About three decades later the company changed its mind.

1988-2004 TSI: AdDept: The Macy’s Installation

Posted on April 15, 2021 by Mike

The first AdDept client. Continue reading →

In early 1988 Sue Comparetto, who had handled the GrandAd accounts in New York City, received a call at TSI from IBM’s Manhattan office. One of our contacts, Quique (KEY kay) Rodriguez¹ wanted to talk with us about Macy’s New York. Its advertising department had been using software programs on an obsolete System/34 to keep track of its advertising expenses and income. The system had been developed internally by people who no longer worked for Macy’s. Documentation was minimal.

Macy’s New York had recently merged with Macy’s New Jersey. The new entity was called Macy’s Northeast, and its offices were on an upper floor of the “world’s largest store” on 34^th St. in Manhattan. The advertising department’s existing system had already been stretched to the limits and would never be able to handle the increased load. Moreover, the users were not happy with some aspects of the code. Alan Spett², one of a very large number of vice-presidents at Macy’s, had been provided by corporate with a budget for replacing or updating the existing system.

This may have been the last time that I actually jumped.

I jumped for joy and clicked my heels when I heard about this opportunity. For some time I thought that companies that produced and/or scheduled their own advertising represented a attractive untapped market for the skills and knowledge that we had acquired from our seven years works with advertising agencies. Evidently I was right. We had never approached any of these departments because I had absolutely no idea how we could even identify which companies created and placed their own ads.

Coincidentally, IBM had just announced a new mini-computer, the AS/400, to replace the System/36 (which had replaced the System/34 in 1983). This announcement and its implications for TSI are described in considerable detail here.

The train brought us to Penn Station, only a block or so from Macy’s.

I made several trips by Amtrak train to the city to document the requirements for the new system. Sometimes I was accompanied by Michael Symolon, TSI’s marketing director at the time, and sometimes by Sue. We soon learned that Macy’s advertising department did everything that an ad agency did except keep track of the amount of time spent on individual production jobs. In fact, they had an advertising agency name that they used when ordering media. In addition, the department had many other needs that regular ad agencies lacked. Specifically, they were required to allocate both production and media expenses to the selling departments. These departments were identified by three-digit numbers. Each was assigned to an administrative group that also had a number. In turn there were three levels of vice-presidents who “owned” administrative groups³.

Macy’s also billed the merchandise vendors (Clinique, Ralph Lauren, Levi’s, etc.) a portion of the expense for ads that featured their products. The cost to the merchandise department was net of these “co-op” billings. The contract could be for a percentage of the media cost or it could be a fixed amount.

The first phase of this job entailed providing Macy’s with everything that they needed to get the ads in all media scheduled—printed schedules in the format that they liked, “insertion orders” (called “delivery tickets” by other retailers) to accompany the materials sent to the media vendors, and so on—in every media. It also included keeping track of expenses and co-op for each level of the merchant hierarchy. There were several different formats that they used for reporting these breakdowns.

I envisioned that the creation of any ad would consist of five steps:

An ad number within the season and a version code that was usually blank would be entered, or ad numbers could be assigned by the system by pressing a function key.
A new ads screen allowed selection of the ad type (e.g., black-and-white ROP) and entry of the primary run date, which must fall with the season.
The other information that applied to all of the media for the ad would be entered on a header screen. This varied by type of ad, but each screen included selection of a pub group—a list of newspapers, markets, or stations.
A media selection screen showed one line for each pub in the pub group with dates, quantities, rates, and other costs or discounts. Any line could be edited or deleted. Additional pubs could be specified.
A participants screen to provide the list of departments or groups for the ad with the expected cost percentages and co-op amounts for each.

Storewide ads could be entered rather quickly. Ads with many departments or groups might take a few minutes. This approach was warmly received. The employees were accustomed to specifying the participants for each pub in the ad.

After the schedule was created, any aspect of an ad could be changed, or the ad could be killed, (in exceptional cases), deleted, or moved to a different date. New ads could be defined. Once the ad was run, the actual participants and the actual co-op could be provided. History records with dates, times, and user ID’s were kept for all changes.

How did Macy’s determine the percentage of the actual cost of each ad that was to be allocated to each department or administrative group? The process astounded me. In one room⁴ were seated from three to five clerks. Each was provided with a stack of newspapers and a list of ads that were scheduled to be run as well as lists of department numbers and the numbers of administrative groups. They looked through the newspapers to find the ads that Macy’s had run. They then measured—with a ruler!—each of the “blocks” in the ad to see how many columns wide (six columns to a page) and how many inches deep (i.e., vertically) the block was. They then entered the column inches for each block. For blocks that were not specific to a department or group, a special “storewide” department #999 was created. The total of the measurements must exactly equal the total size of the ad.

My approach changed this process so that the clerks measured ads, not insertions (the ad in a specific paper). If the ad was already measured, the clerk could see what had been entered, who did it, and when.

A similar process was also required for each page of each direct mail piece and newspaper insert. The ads for other media were not measured, but actual percentage breakdowns were recorded.

Similarly, the actual co-op dollars received from the selling departments (a process called “turning in”) could be recorded. Lists of missing co-op could be printed.

The most important financial reports for Macy’s compared the committed co-op and costs with the actual measured costs and actual co-op. They could be run for any or all merchants (the vice presidents who owned the departments) and any or all media.

Camex was located at 75 Kneeland St. in Boston.

In addition to all of this, Alan had ideas for other modules such as an inventory system for the merchandise used for photo shoots in the studio in Newark and a system to manage the shoots themselves. He also wanted us eventually to work on an interface with the Camex system that Macy’s used to create the images for the ROP⁶ ads and books. Thank goodness these ideas were not included in the original contract.

TSI’s GrandAd system for ad agencies had been built around a file for ads, the key to which was a three-digit client number and a five-digit job number. So, each client could have up to 99,999 jobs. For the departmental system, which I decided to call AdDept, I designed a similar structure, but, since Macy’s itself was the only client, I made the three-digit code stand for the season. 891 meant spring of 1989. 892 was fall of 1989. Eventually, a one-digit code for the century was added as well, but otherwise this proved to be a very feasible approach.

Many other structural changes were necessary. The most significant one was the designation of a one-character version code as part of the unique identifier (key) to the main media file. This could be used to make distinctions that varied by pub (media vehicle). For example, one item in an ad might be “swapped out” for a different item in another ad. The catalogs sent to some markets might not include some pages.

The new table for the pub groups mentioned above allowed Macy’s to identifying papers in which they often ran the same ad, e.g., the tabloids. There was no limit on the number of pub groups, and pubs could be in any number of pub groups.

I did not mention this to anyone at the time, but while I was gathering requirements, I noticed a very serious flaw in the design of Macy’s existing software for the S/34. The same ad was run in a few papers, but each insertion in each paper was given a separate ad number. The clerks doing the measuring were each assigned one or more newspapers. They measured and then entered into the computer the amount of space for each department in each ad. The person next to them might have already measured the same ad in a different paper, but there was no way for them to use that information; they had to key it all in again. So, with the S/34 design the increase in the number of papers added by the merger would more than double the work in allocating costs. My approach would decrease the work even with more papers. They would only measure the ad in one paper.

How great was this? The ROI for this feature alone would easily surpass the cost of the entire system in the first year!

How was such a colossal blunder possible? Well, the S/34 programs were designed for Macy’s New York, which advertised almost exclusively in only three papers: The New York Times (a broadsheet), the Daily News (a tabloid), and Newsday, a Long Island newspaper with a unique shape. Each of these would require separate versions and therefore separate measurements. However, all of the new papers were either tabloids or broadsheets. There was no need for separate measurements.

At some point in mid-summer TSI needed to do a presentation for Macy’s at IBM’s office on Madison Avenue in New York. There was no competition; no other software developer wanted anything to do with this project. The alternative for Macy’s was to enlist their IT department to do something. No one mentioned this, but I was quite certain that the IT department would not be able to deliver a functioning system that met all the requirements within the required time frame. Of course, I was not certain that we could do it either. However, we had delivered several large projects on schedule, and I was willing to put in the hours⁵ to make this one a success.

590 Madison Ave., then known as the IBM Building.

I wanted to demo the GrandAd system and explain how we would adjust the database to fit Macy’s. I made arrangements to use a S/36 in IBM’s office at 590 Madison Avenue to show how our advertising agency system currently worked and how it could be adapted. I considered–and still do–this to be the most important presentation that I ever gave. It was my only chance to persuade Macy’s Advertising Director, Howard Adler, that TSI should be contracted to do the project. I figured that if we got Macy’s, and we did a good job, a whole new market would be opened to us. At that point I was still naive enough to assume that other retailers would surely be much less difficult because we had already done the programming for the largest retail advertiser in the country.

I needed to transport our GrandAd programs and our demo data to New York. Not only was it not possible in 1988 to send them there electronically using something like FTP. We did not even have access to a compatible medium. The I/O device on IBM’s S/36 in NYC read 8” diskettes. Our system in CT used 5¼” diskettes. So, I saved our programs and our data onto nine 5¼” diskettes. Then I used a machine that I had purchased for just this purpose to copy the 5¼” diskettes onto previously blank 8” diskettes. I then loaded the 8″ diskettes into a “magazine” that I had obtained somewhere. The S/36 in New York included a device for reading diskettes from such a magazine.

This is the only photo that I could find of a magazine. The diskettes are inserted in and removed from the opposite side.

You say that you are not familiar with the concept of diskette magazines? For over a decade IBM used them on the S/34 and the S/36. As far as I know, no other system from any manufacturer followed suit.

They were almost completely plastic. Their width was about an inch and a half. The other dimensions were just large enough for 8” diskettes. One side was open to allow insertion and removal of diskettes. Small plastic rails on the top and bottom of the open side kept the diskettes separate from one another. The only thing on the magazine that was not plastic was a small metallic bar near the top of the open space that held the diskettes in. The bar could be lifted up on a hinge to allow access to diskettes. The machine that read the diskettes could also do this (like a juke box), and it was smart enough to read them sequentially.

The process of saving and converting the programs and data, which I probably did over a weekend, took several hours. I then inserted the 8” diskettes into the magazine, put it in my sample case with my other materials, and then stowed the sample case in the trunk of my Celica. I do not remember why, but I must have left the car in the sun for several hours. When Michael and I reached New York and took out the magazine, we could see that the little iron bar that restrained the diskettes had apparently become hot enough to melt little notches into all the diskettes. The magazine drive on IBM’s system refused to read them. O tempora, o mores!

Michael had a brilliant idea. He used a sharp knife to slit the edge of each damaged diskette and nine new diskettes that we borrowed from IBM. The actual data was not, of course on the plasticized paper that one could handle (and therefore slit). It was on a very thin circle of magnetized film inside. For each new diskette Michael replaced the blank film disk inside with the one that he had retrieved from a diskette that I had made. Then he carefully inserted the nine new diskettes that hopefully contained our programs and data into the magazine. I then loaded the magazine into the S/36’s magazine drive again and entered the command to restore the files. The machine successfully read six diskettes. However, at that point it made an awful noise and totally mangled the seventh diskette including, because we had no way to reseal the side that Michael had slit, the precious film inside.

So, I was faced with the prospect of making the most important presentation of my life with absolutely no software to demonstrate. The pony in my “dog and pony show” was a stick-figure drawing. Would anyone notice?

Fortunately, my many years of experience in debate at adjusting a presentation at the last minute kept me from panicking. I began the presentation by apologizing for the technical problem. I then illustrated the approach that we proposed to take using the whiteboard that IBM provided, and I answered questions as well as I could.

It was enough. Macy’s agreed to put in motion the process of contracting with TSI. As Alan later said, “You were definitely the only game in town.”

The plan was to install the system in the “System/36 environment” of a B30 model of an AS/400. The I/O devices were a single 8” diskette drive and a ½” tape drive. TSI had no system that had either of these drives, and so our only choice was to execute the cumbersome conversion process every time that we needed to make changes.

TSI could not even afford J. Cheever Loophole.

I sent Alan our usual two-page contract. He sent it to their legal department and returned one with about twenty-five pages. I should mention that the TSI was dirt poor at this time. Sue and I had been low on funds before, but this was the first situation that rose to a crisis level. Details are posted here. We certainly could not afford a lawyer. I had to read the contract very carefully and assume the worst. After a few changes, we agreed, signed it, and started work. I did almost 100 percent of the coding. The other programmers were busy with work for our other clients, and I did not trust Sue to do the work.

I was not able to use a single program from the GrandAd system. I thought that at least one of the many insertion order programs that we had written for ad agencies would be usable without much modification, but I was wrong. The people in retail advertising just do not think like the people in advertising agencies. Every single program was written from scratch.

We had no time to produce a detailed design document describing the project. Our drop-dead deadline was the end of the season in late January. All programs must be totally functional. The process was:

Write the code.
Get it to the point where there was something to show to Macy’s.
Save the changes to 5¼” diskettes.
Copy the 5¼” diskettes to 8” diskettes.
Take the train to New York.
Install the new software from the 8″ diskettes. This could take up to an hour.
If changes had been made to the database definitions, make them on Macy’s system.
Make changes on the fly as necessary.
Show Macy’s how the new code works.
Save the changes to 8” diskettes.
Bring the 8″ diskettes on the train ride to TSI.
Copy the 8” diskettes to 5¼” diskettes.
Install the changes on TSI’s system.

The luxurious Windsor Locks Amtrak stop. This is the view looking north. From the parking lot the engine’s light could be seen under the bridge.

This was, to be sure, a terrible way to do things. It required me to make at least one trip to New York every week for several months. Usually it was up and back on the same day. I stayed overnight at a hotel a couple of times. Often I made two up-and-back trips in a week. Each trip required a twenty-five minute drive to the train platform. I boarded the train at 6:00 AM in Windsor Locks. There is only a platform there. I therefore sat in my car with the heat on until I saw the light of the train approaching.

The word you did not want to see was “DELAYED”.

If everything went well, I arrived back at the train platform at 9:30PM. The trains in the evening, however, were almost never on time. Those trains originated in Miami, FL. There were plenty of opportunities for delay as each one crawled its way north. A report on my most memorable Amtrak experiences is posted here.

During this process Alan would quite often come up with new thoughts as to what should be in the “base system” covered by the contract. I grumbled, but I almost always did what he asked. One morning I saw a Daily News in Penn Station with the headline “Macy’s Computer System is Driving Me Crazy!” I bought a paper, cut out the headline, and taped it to the inside of my sample case.

Meanwhile, TSI had received only a deposit from Macy’s. However, we were desperate to receive that final check. I saw no alternative to this nightmarish schedule.

The scope of the project was enormous, and almost nothing from the GrandAd code was usable for this project. In addition to everything else, the emphasis at Macy’s was on newspaper ads. In my experience ad agencies used the term “print”, which for them referred to direct mail and magazines. Most agencies treated newspapers as magazines that published more often on cheaper paper to a geographically limited audience. The ingrates who ran the papers did not even offer discounts to ad agencies. Macy’s, on the other hand, could run a dozen or more ads in one issue of a newspaper.

Mirabile dictu! By February, 1989, the system was stable enough that Macy’s paid us most of the balance. This did not end the crisis at TSI, but it allow us to meet the payroll for a few months. In retrospect, I cannot imagine how we pulled it off. I remember working seven days a week. I was always at work by 6AM, and I seldom left before 7PM⁷. I admit that I always went home for lunch, and I usually took a short nap.

What enabled the completion of this seemingly impossible task in that amount of time was the fact that Alan somehow got Gary Beberman⁸ to serve as the project manager. He could speak advertising to the workers at Macy’s and geek to us. I only trained one person; Gary trained the others. I am not sure where Alan found Gary or how he got assigned to the project, but he was a godsend. He saved us a huge amount of time and frustration, and he was also quite adept on pouring oil on troubled waters during the frustrating periods in which I was working feverishly on the code.

The next two projects for Macy’s were an inventory system for the “loan room” (usually called “merch room” at other retailers) and a more sophisticated system of entering and reporting actual costs, what Macy’s called “financials”. I gathered the specs for these projects on trips to Macy’s and produced detailed design documents, which Alan quickly approved.

Denise Bessette did almost all of the programming on these two large requests, and she did an outstanding job. I installed the code and showed the people at Macy’s how to use the programs.

Merchandise that was afraid of the traffic could have just as easily taken the train.

The loan room gathered merchandise needed for photo shoots and sent it to the photo studio in Newark or to some other location. Part of the automation of this process was the printing of tags for each item. Almost as soon as this was implemented, the amount of pilferage reportedly decreased dramatically. The merch room manager told me that previously a lot of merchandise had trouble remembering the way back to Manhattan from Newark. She was extremely happy with the new system.

Denise also completed the other project according to the approved design document, and I delivered it. The finance manager then produced a bevy of changes that she wanted. I offered to quote the changes at TSI’s usual fee of $75 per quote. Alan said that Macy’s was under the impression that these programs fell under the terms of the original contract. It clearly did not include them. He was also surprised that I insisted on charging for my time at Macy’s after the warranty period. I would not give in on these matters, and this caused some bitterness.

At some point in this process TSI leased an AS/400 model B10 from IBM. We hooked everyone up to it, and we converted all of Macy’s programs to run in the native environment instead of the System/36 environment. This project went fairly smoothly. I don’t remember any great headaches, and the programs were considerably faster.

In other respects the installation also proceeded rather smoothly as long as Gary was there, but when he and his wife moved to the West Coast, things started to get a little testy. Alan hired Satish Rahi⁹ (accent on the second syllable in both names) to manage the installation. Satish must have presented himself as an alternative to paying TSI to program reports. He thought that he could produce any desired output using a third-party query product from a company called Gupta Technologies. Their Wikipedia page is here.

Satish was shocked that the product did not work on most of our tables. I told him that there was nothing in our contract that said or implied that third-party products (of which even then there were quite a few) would work with tables that we designed and implemented. IBM’s Query/400 product had no trouble with any of our tables. After considerable digging I determined that the source of the problem was that we wrote records in BASIC, not in SQL¹⁰, which was not even available on the AS/400 yet. The designers of Gupta’s product evidently did not take this into account when they began marketing to AS/400 customers.

Satish started lecturing me about industry standards for databases. I explained that the industry standard for writing x-digit positive integers in BASIC was N x, which left-pads these numbers (such as the ad number) with blanks, as opposed to ZD x, which left-pads with zeroes. In fact, most versions of BASIC did not even have a way to write “zoned decimals” without writing extraneous code to do it¹¹. One day I got so upset while arguing with Satish about this that I seriously considered driving down to the Amtrak stop so that, after sitting on a train for over three hours, I could ride the elevator up to his floor at Macy’s and punch him in the nose.

Not long after this conversation Alan fired Satish, and eventually we changed all the programs to “zone” all the integers. Of course, we got paid for neither this project nor the conversion to the native environment, but we felt that we had to do them to hope to stay in IBM’s and Macy’s good graces.

From that point on we dealt with Denise Jordaens¹² and Lee Glickman¹³ at Macy’s. Things stabilized, but the department did not get nearly as much out of the system as it could have.

Over these years Macy’s went through a lot of changes. In January of 1992 the company declared bankruptcy, thereby leaving TSI with a stack of unpaid invoices. In 1994 Macy’s was absorbed into Federated Department Stores, which had itself just emerged from bankruptcy. This gave them a new set of standards to abide by. Eventually other acquisitions gave Macy’s in New York a large number of new stores to manage on the east coast. They continued to use the loan room system and to pay our maintenance bills. They never asked about any of the enhancements that were installed at Macy’s South and Macy’s West.

There were other complications as well. On one occasion Macy’s asked for someone from TSI to visit so they could explain their problems with and aspirations for the system. My schedule was totally booked for weeks in advance. I asked Sue to take the trip. She did. I don’t know what transpired, but Denise Jordaens later told me that they made a voodoo doll of Sue and stuck pins in it.

I may have made some bad decisions about Macy’s. I did not yet understand how decisions about products and services like those offered by TSI were made in a large retail advertising department. This issue is discussed in more detail here.

TSI probably should have charged more for the original installation and used the money to hire another full-time programmer. Maybe we should have tried to borrow money from somewhere. I was unwilling to put all of our eggs in the Macy’s basket. Macy’s declaration of bankruptcy was a devastating blow to TSI. When Macy’s was acquired by Federated Department Stores¹⁴, it appeared to me that the decision to concentrate our efforts elsewhere had been a sound one.

As it turned out, however, Macy’s eventually gobbled up nearly all of the regional department stores in the entire country. The strategy that I chose helped TSI succeed for more than twenty years, but if I had gambled on Macy’s, we might still be in business in 2021. On the other hand, we would have been working almost exclusively for Macy’s for most of that time. Such an experience might have really driven me crazy.

The story of the Macy’s installation had a bizarre final chapter. It is recorded here.

1. According to his LinkedIn page (which is here), in 2021 Quique Rodriguez is retired and enjoying family time. I suppose that it is possible.

2. Alan Spett lives in Atlanta in 2021. His LinkedIn page can be found here.

3. So, I designed the database with five levels of participants. The lowest level was always called a department, but the names of the other four levels to be used on reports and screens could be specified by each AdDept client. At all Macy’s divisions they were called Administrative Groups, Group VP’s, Senior VP’s, and Group Senior VP’s.

4. This same room housed the AS/400, at least for a while. I sat at an empty desk when I was there. When the first phase of the installation was completed, some of the measurement clerks were reassigned to other tasks.

5. Unfortunately, I don’t think that I was careful enough to account for the large number of unproductive hours that I would spend on trains, in meetings at Macy’s, and in converting files. The round-trip train ride alone accounted for six or seven hours and a drive of nearly an hour, So, each full day at Macy’s was matched by another full work day getting there and back!

6. ROP stands for “run of press”. All display ads (as opposed to preprinted inserts) that are run in a newspaper are called ROP. It is not an acronym; all three letters are pronounced.

7. I am a “morning person”. Any work that I did after 7PM was likely to be counterproductive. Moreover, I needed a few caffeine-free hours so that I could fall asleep at 10PM and stay asleep.

8. I have kept in touch with Gary Beberman. He moved to California to work as a consultant and then was employed by Macys.com. Macy’s West and Neiman Marcus hired him as a consultant during their AdDept installations. He was the only consultant whom I ever respected. He has lived in Marin County for the last five years. He and his wife are hoping to retire to Italy.

9. Satish Rahi’s LinkedIn page is here.

10. SQL (structured query language) was invented in the seventies by two IBM researchers, but at the time of the debut of the AS/400 no IBM computers used it much. The reason, we were told, was that it was much less efficient than the ISAM methods that IBM endorsed. Later IBM computers, including the AS/400, were designed to maximize the efficiencies of SQL queries.

11. What I said to Satish was correct from my perspective, but perhaps I should have asked him what made Gupta Technologies think that the AS/400’s relational database conformed to these “industry standards” that he cited. After all, SQL had been invented by IBM, and IBM was not yet positioning its AS/400 as an alternative to the “standard” databases such as Oracle, Sybase, or Informix.

12. According to her LinkedIn page (here) Denise Jordaens still works as coordinator of media systems for Macy’s.

13. I think that this might be Lee Glickman’s LinkedIn page.

14. A more detailed discussion of TSI’s long and torturous relationships with Federated Department Stores can be found here.

Wavablog

Memoirs, bridge, popes, travel, and other stuff

Tag Archives: SQL

2001-2006 TSI: Weekly Partners’ Meetings

1999-2002 TSI: The Million Dollar Idea

1988-2014 TSI: The IBM AS/400 and its Follow-ons

1983-1988 The IBM System/36

1988-2004 TSI: AdDept: The Macy’s Installation