2013 Bridge: Webmaster for District 25

Posted on June 17, 2023 by Mike

Webmaster, database, email, comm comm, bulletin. Continue reading →

2012 was long before “ACBL Live Results”¹ made it easy for bridge players to find out within an hour or so the results of tournaments.Late in that year I saw a notice on the NEBridge.org² home page that District 25 was looking for someone to post on the website the results from its tournaments. It asked interested players to contact the president of the New England Bridge Conference (NEBC), Ausra Geaski. I did, and after a short training session from Bob Bertoni, who owned and operated Megaherz Computer, the company that designed and implemented the website, I took over the job.

On the evening of each day of the 2013 Knockout Regional in Cromwell I posted the results. The tournament director sent me on text file for each event. I amalgamated them into one large file text file. I made an HTML file that had an index at the top with one line linked to the anchor for each event that I had inserted at the top of the appropriate text. It was HTML 101, not rocket science.

Bob thought that I had done a good job in getting the results posted promptly. He told me that someone who was webmaster at one of the other units had tried to do it at a previous tournament and had made a big mess.

I subsequently told Ausra, whom I occasionally saw at the Hartford Bridge Club³ (HBC). that I was willing and able to do more. Shortly thereafter another notice was posted on NEBridge.org. This one said that the district needed a webmaster. Bill Braucher was resigning from the post that he had held for seven years. I let Ausra know that I thought that I could do it. I also told her about my own website, Wavada.org (which was introduced here), but I don’t think that anyone ever checked it out.

One evening at a tournament Bob spent about an hour with me explaining how the district’s website was structured and how the built-in page editor worked. During this session he discovered that I already knew HTML, JavaScript, and CSS.⁴ He exclaimed, “Oh, you can code! You won’t have any trouble with this.”

A little later we realized that we had something else in common. Bob had attended Boston College on a debate scholarship.⁵ His coach was Tuna Snider, whom I knew fairly well. In the end Bob offered me the webmaster job at the same salary that Bill had earned.⁶ I countered with a demand for a 75% raise, and we settled on 50%.

The bridge world was very different then. The district’s website was its primary method of communicating with its members. It did not publish a newsletter, and it had no program for using email. For the most part postcards and flyers were snail-mailed to the clubs. The district relied on their owner/managers to pass the information on to the players. The method was fairly expensive and totally unreliable.

Furthermore, the webmaster was not allowed to post any material unless the website editor, Allan Clamage⁷, had checked it for style and errors. Allan also taught me about standards that the district had established to govern the decisions. For example, the website never published an obituary or promoted any unit’s tournaments or other events.

The Website Committee (Allan, Bob, District Director Rich DeMartino, and myself) had a strategy meeting during one of the lunch breaks at every tournament. I don’t remember much that transpired at these meeting, but the other members mostly endorsed my ideas for improving the website. After three or four of these meetings Rich declared that we seemed to know what we were doing and disbanded the committee. At about the same time Allan began to review what I posted only after the fact. I considered that show of trust as a great compliment. I only embarrassed him a few times, and he never got angry at me.

My main goal was to attract more eyeballs to the site. Expert players Harold Feldheim and Jay Stiefel allowed me to post articles that they had written for The Kibitzer, the newsletter of the Connecticut Bridge Association (CBA). I also received material from Frank Hacker, Steve Rzewski, Bill Braucher, and a few others. I began writing The View from B-Low under my nom de plume, Single Session Swiss⁸. After each tournament the webpage for The View whimsically recounted my own completely inexpert experiences. Most were true; a few were fish stories. Most of those articles still exist. The index to them is available here.

Database Manager: I remember that during one of my conversations with Allan, I exclaimed, “We don’t know who our players are!” He disagreed. He then showed me how he downloaded csv⁹ files of the entire ACBL roster every month, and he arranged for the ACBL to allow me to do the same. Allan used spreadsheets, but I undertook the major task of designing a MySQL database for use by the district and myself. At the time I wasn’t quite sure what I would do with the information, but I knew that we needed it.

I maintained two copies of the database, one on my local hard drive and one on the Wavada.org website that I had purchased from iPower so that I could share my travel journals with friends, family, and fellow travelers.

The database’s primary table had one record per player. Every table in any database should have a “key”—a field that uniquely identifies the record and cannot be changed. On the player table the key was the seven-digit ACBL number. Using it as the key would be a small problem if I wished to add records for non-ACBL members. Fortunately, if that ever happened, I could assign them a bogus number less than 1000000. The ACBL never used those numbers.

When a new roster was released I updated both the local and remote copies of the players table using scripts that I wrote in php. At first I did this only for currently active players in New England, but after a few months I decided to expand it to cover all of North America. The script that updated the players table also wrote records on a history table that contained each player’s point total at the time that the roster was posted.

One of my jobs as webmaster was to post a list every month of the New England players who had advanced in rank during the month. I decided to maintain a sub-table for these advancements using the file that was sent to me by the ACBL.

I soon realized that what I really wanted to know was who was attending the tournaments in New England. I knew that the results posted on the district’s website as well as on the websites of the units listed all players in attendance. There were two major difficulties: 1) the ACBL numbers were not on the lists; 2) the formats were not consistent. It was a big pain, but I eventually came up with scripts that could handle nearly all of the entries on all of the lists.It wasn’t close to perfect, but it was much better than nothing. I was convinced that it was worth the effort.

I created two sub-tables for attendance: one for players whose ACBL numbers I was able to deduce from the name and town on the list and one for the others. The biggest problem was people with more than one address. The second-biggest problem was people who changed their names. I figured out ways to handle these problems, but they were labor-intensive and introduced the possibility of mistakes.

I also went through the same process for the three NABC tournaments that were run every year. Those files were much larger. It took me a day or more to process each one. It was very important to do them promptly. If even a month elapsed, a lot of addresses changed.

Sending emails: Eventually, I wanted to use the database to send emails promoting the district’s tournaments. The first problem was that the emails on the ACBL’s database were incomplete. I reached out to my acquaintances throughout the district and came up with correct email addresses for at least half of the ones that were missing. I also went through the wooden box containing index cards with member data at the HBC and found a few there. To make sure that my good addresses were not overridden by the ACBL’s blank, confidential, or wrong addresses, I added a field to the player’s table for the source of the email and changed the php script so that it only used the email address on the roster if the previous source was “ACBL”.

The second problem was that I had no authority and no budget for anything like this. At the time District 25’s president, Mark Aquino, had created a “B’s Needs Committee” to address the problems that lower-level players (like myself) confronted when their masterpoints exceeded the 750-point maximum for the “Gold Rush” games. Mark attended some of the meetings. I told the committee about the database that I had created, and I mentioned that I would like to send emails to promote the events sponsored by District 25. I was very pleased when Mark said, “Go for it!”

The great thing about php was that it was—even in those days—thoroughly documented on the Internet. I discovered a way of sending emails through php. My first project was to promote the 2014 Senior Regional/Cape Cod Sectional in Hyannis, MA. The chairperson was one of my partners, Ginny Farber (then Ginny Iannini), who was introduced here.

I sent the emails to all members of District 25 and to anyone who, according to the attendance table on the database, had attended a recent tournament in New England or a national tournament. I knew that I had to be careful about being considered a spammer, and so I stated quite clearly in the email that anyone who wished to be removed from the list should reply to the email with that indication, and I would take care of it. The players table had an “OK to email?” field. I never mailed to anyone who had asked to be removed, and I was scrupulous about keeping this designation up to date..

The emails were very well received, and the attendance at the tournament exceeded expectations. The chairperson of the next event, the Summer Regional in Nashua, NH, was Sarah Widhu. She asked me to promote that event, and I did so. It was also well received, and the attendance was quite good. I was definitely on to something.

Email problems: The php script that I executed on my Wavada.org account was not completely fool-proof. Every so often it would send up to fifteen copies of the email to one person. This was, to put it mildly, quite annoying. I contacted iPower about it. Because I was unable to reproduce the problem for them, they could not solve it.

This problem was completely dwarfed by another issue that raised its ugly head shortly thereafter. None of the emails went out! Once again I contacted iPower. It took several weeks, and they never told me what they did, but the support team somehow fixed this.

However, after a few successful executions, the problem appeared again. After several weeks of interchanges with iPower support, I was finally informed that my account had been black-listed as a spammer by someone. Therefore, the iPower email server did not send out my emails.

I used the one phone call that I was allowed to tell Bob Bertoni that I was in email jail, and I asked if he could bail me out. He did some research and eventually negotiated a contract with MailChimp, a company that specialized in sending mass emails for businesses and non-profits, for the purchase of two million “credits” for emails for only $2500. The Executive Committee approved the appropriation. From that point on I never tried to send emails directly from iPower.

MailChimp: I set up an account on MailChimp with a user ID of Guastafeste, which is the Italian term for party-pooper. I taught myself how to use the software to create the lists and the emails themselves. For the first few years the account was allowed to create as many lists and emails as we wanted. I created a new list for each email until MailChimp prohibited me from creating any additional lists.

I generally sent out the first set of emails five weeks before the event. A second set would be sent two weeks later. Each set would be devoted to a group based on geography, masterpoints, and/or tournament attendance. The content sent to each group would differ, at least a little.

Because I was accustomed to composing my emails in HTML, I always used the “Code your own” template. I always wrote the code for the emails in UltraEdit on my PC and pasted the HTML code into the editing window on MailChimp. Te program would immediately display the way that the email would look in the window on the left side of the screen. This method allowed me to position and size images exactly. It also allowed for the use of tables and almost anything else that could be done on a webpage. An unanticipated benefit was that if someone who needed to promote something had sent me an email that was already formatted, I could extract the HTML code, tweak it a little, and then paste it into the HTML editing window.

I reported one bug that I found in this process. If I tried to change the color (or anything else) for part of a word, MailChimp inserted a space between the two parts. The example was GOLDmother, which MailChimp changed to GOLD mother. MailChimp refused to fix this obvious problem. By the way, it was not easy to get WordPress. which is the product used for these blogs, to produce this effect either.

The oldest HTML file that I found in the MailChimp folder on my PC was dated July of 2015. I suspect that the first tournament promoted on MailChimp was the Individual Regional in 2015. From that time through 2021 I composed, tested, and sent almost all of the emails promoting District 25’s events. They were amazingly successful, and I became known in New England bridge as “the email guy” rather than “the webmaster”. All told, I sent over one million emails.

Other projects: The database also allowed me to undertake posting on NEBridge.org photos of winners of events or strats at regionals (Winners Boards). The first tournament for which I implemented this feature was in the Knockout Regional in Cromwell in 2014. My plan was to ask winners to come to a spot where I could take their pictures with my point-and-shoot Canon. Only one or two complied.

There were several other problems. My friend Bob Derrah volunteered to help me chase winners down, but he could not figure out how to use the camera. Eventually I discovered that the best time was either right after the round or the next day before the start of play. Still, I was lucky if I got photos of half of the winners.

I usually spent the better part of every week assembling the five or six webpages of winners’ photos. I sent emails to every winner whose photo I lacked. A very high percentage of them responded, especially among the newer players. For the others I either pieced together substitutes from photos that I previously took or just put up an empty spot for them. The HTML code for the pages themselves was generated by a php script that ran off of a set of tables that was itself generated from a spreadsheet on my PC.

Was it worth the effort? I don’t know. I strongly believe that the regionals should be special, and the winners boards—and a lot of other things—contributed to making them feel that way to a lot of people. Most of those things disappeared during the pandemic. To me the post-pandemic regional tournaments seemed vacuous whereas before they always excited me.

The ACBL had two annual contests that rewarded the players in each rank that accumulated the most points. One exclusively counted points won at clubs. The other included all points. I decided in 2017 to create an award for each rank for points won in the events sponsored by District 25. That included the NAP and GNT qualifiers as well as the four regional tournaments and the two hybrid events—the Rainbow Weekend and the Senior Regional/Cape Cod Sectional.

My ability to do this without a great deal of effort was due to the access that I had to LZH files from the ACBL. An ACBL employee named Keith Wells provided me with these files that had all the information on the “masterpoint winners” lists that I had been using to populate the attendance files, plus they had both the ACBL numbers and the total number of masterpoints that the players had at the time of the event. They also included players who attended but earned no points.

It was pretty easy to keep the fifteen totals in the database. The only real difficulty I had was when a foreign player was awarded masterpoints for the purpose of eligibility. After each event I sent out emails to everyone in each of the fifteen masterpoint categories that listed the top fifteen players in that category. At the end of the year I created certificates honoring the winners.

I doubt that this effort by itself induced more than a few people to play, but like the Winners’ Boards, they helped to contribute to the special atmosphere of regional events.

Another project from BridgeFinesse.com involved sending of emails to players who had achieved a new rank in the previous month. The emails, which were signed by the appropriate district director encouraged the recipients to respond to the emails with their own ideas. Rich DeMartino was D25’s District Director (DD) when this process began. He asked me to post each comment that he received and to ask each player for whom I did not already have a suitable photo to send one. I did this for Rich and for his successor, Mark Aquino.

When Bob Bertoni became DD, he posted the comments he received on his own website. When he died in 2021, his temporary successor ignored the comments, but when the position was eliminated in favor of a Regional Director, the first one, Mark Aquino, asked me to post the new comments. I retrieved the ones from Bob’s website and posted them on NEBridge.org. I also posted the ones that Mark received.

The disaster: In October 2015 the system that hosted NEBridge.org suffered a catastrophic hardware failure. In the 30+ years that I had spent in the business I occasionally had to face some really bad situations, but I never had to deal with anything like Bob was facing with this one. I told him that if I were he, I would be looking for a tall tree and a short rope.

NEBridge.org was the least of his problems. We were trying to get people to play our favorite card game with us. His other customers’ livelihood depended on their websites.

Nevertheless, Bob got the district’s website back up and running pretty quickly, but most of what I had posted in the first few years was not recoverable, including all of the articles by Frank and Steve. I could have gone back to original sources and salvaged some of it, but all of the new projects that I had started left me no time to attempt more than I did.

Bob temporarily allowed me to use FTP to send files from my PC to the server. That saved me a lot of time. The new version of the website had a slightly different editing editor for the pages. I liked it in some ways and hated it in others.

The Communications Committee: At the last meeting of the B’s Needs Committee Bob, who at that point was president of the NEBC, announced that he wanted to form a marketing committee. He then asked me to be its chairman. I wanted to be on the committee, but I had never been the chairman of a committee. I suggested Allan, but Bob was rather insistent. I eventually agreed, but I wanted it to be called the Communications Committee or, better yet, Comm Comm.

Beginning in 2016 a group of us met at tournaments for several years to talk about all aspects of communication—website, emails, tournament Bulletin, posting of results, guest lecturers at tournaments, signage, microphones, etc. I found the meetings useful, but a subsequent president, Jack Mahoney, decided that they were no longer necessary. I think that the biggest problem was that almost everyone on the committee was also on other committees.

Bulletins: In 2018 I was asked by Lois DeBlois, NEBC president, to begin editing the Bulletin for tournaments. Previously it had been published every day, but Lois wanted to reduce it to one publication that covered the entire tournament. The results that had been printed in the daily editions were by then available online. So, it was not necessary to provide a daily edition. I took on the responsibility of creating it in the new format as well as the setup for online bulletins that were provided by the same service that provided Live Results.

After the pandemic the Executive Committee considered the cost of both bulletins to be excessive. I wrote one last Bulletin for the Optical Regional in Southbridge, MA, in November of 2022.

In November of 2021 I informed the Executive Committee that I intended to resign as webmaster and all of the other things that I had done at the end of 2022. I feared that it would be difficult to find people who were willing and able to keep going many of the things that I started. The story of that process has been recorded here.

1. ACBL stands for American Contract Bridge League, the governing body for competitive bridge in North America. The Live Results program was run by BridgeFinesse.com, a private company in Florida.

2. NEBridge.org is the website of the New England Bridge Conference, the governing body of competitive bridge for District 25 of the ACBL, the New England states.

3. At the time I was still working at TSI and playing bridge only on Tuesday evenings and weekends. Ausra also played in some of those games, but my skill level was far beneath hers.

4. HTML (hypertext markup language) is the language of browsers. JavaScript is an object-oriented language used for screen design. CSS (cascading style sheets) allow for organization of styles.

5. Bob was eight years younger than I was. He probably graduated from BC in or arround 1978. Therefore, he was probably at the party that Don Huprich, Stewart Mandel, and I attended at BC in 1977. That hair-raising adventure was described here. Bob died in 2021. His obituary can be read here.

6. I hate to explain the jokes, but it may not be obvious that neither Bill Braucher nor I was paid anything as webmaster. I did get $100 for each Bulletin. They were always around twenty pages.

7. I later learned that Allan was also a Wolverine, but he was nineteen years older than I was. He was shocked to learn that I had been a math major. He died in 2018. His obituary can be found here.

8. Every tournament that held knockouts also scheduled Single-Session Swiss events. They were team events held in the afternoon for players who were eliminated in the morning session of the knockout. The event was commonly called “Loser Swiss”.

9. A csv (comma-separated values) file was a text file in which each piece of data in a record was separated from the others by commas or other delineators.

2005-? Wavada.org

Posted on June 17, 2023 by Mike

My very own website. Continue reading →

In 2003 Sue and I took the “Best of Italy” tour sponsored by Rick Steves. I then wrote a journal compiled from the notes that I had recorded every day. After I was satisfied with the results I assembled them into a pdf file called “How I spent my Italian vacation” that I shared with other tour members and a few other people. That document is posted here.

The programming tools: During this same period IBM discontinued support for the Net.Data product that I had used to write the software for A^xN (introduced here), TSI’s online clearinghouse for insertion orders from advertisers to newspapers. Instead, IBM had agreed to offer the php environment that had been developed by Zend¹. I had previously learned about php from Ken Owen (Introduced here). He had told me that I could create and run php programs on my Windows computer for free by downloading WAMP, which stands for Windows (operating system) Apache (HTTP server) MySQL (database) php (scripting language). I downloaded it to my PC, set it up, and used it to write a little problem management system for TSI that was actually used for several years.

I had already learned that in order to do programming for the Internet that accessed a database you really need to know five languages: HTML, JavaScript, Cascading Style Sheets (CSS), SQL, and a scripting language to fit all the pieces together. I had books that documented the first three. I soon discovered that books on php and MySQL were not necessary. The syntax of each was thoroughly documented online, and answers to every question that I had were easily found using google. I never had to ask anyone for help.

The first project: Sue and I had planned for another trip to Italy in 2005. This time we invited our long-time friends Tom and Patti Corcoran to accompany us on another Rick Steves tour, “Village Italy”². I intended to take notes and assemble them into another journal. This time, however, I wanted to do it a little more professionally. I purchased a Cascio point-and-shoot digital camera, mostly using points from one of my credit cards. Since I wanted to allow others in our tour group to be able to enjoy the journal, I needed to build a website. I knew how to do that on an AS/400, but I wanted projects like this to be independent of the business, and I was not about to buy an AS/400 and try to run it from my house. I wanted someone else to manage the site for me.

I did a little research on the Internet. A company named iPower seemed to offer everything that I needed at a fairly reasonable price. Its tools seemed to be well documented, and, especially for the first few years, the technical support was excellent. My first contract with them was signed in July of 2005. I might have had a free month or two before that.

I decided to name the website Wavada.org. Wavada.com was available, but I had no intention of using the website to make money. I wanted to a place to noodle around with Internet programming (my personal computer, which at the time was a laptop) and a separate place where I could show some of the things that I had developed to the world.

I needed some tools on my PC to let me edit the text and images. I had previously downloaded TextPad, a “shareware” (free but with requests for donations) product that was better at editing text than the program that came with Windows. I purchased a copy of UltraEdit, which could be tailored for use with the color-coded and spaced text of php scripts, and Paint Shop Pro, an inexpensive program for editing image files. My plan was to do all of the development on my PC and, once everything was working, upload everything to Wavada.org using either File Transfer Protocol (FTP) or the File Manager program that iPower provided.

The first journal: My first big project used php to create one web page for each day of the 2005 trip. I created a folder named Images and inside of that folder a folder the trip (VI). Inside the trip folders were folders for each day (VI01, VI02, etc.) and one each for the full-page version of the photos³ and the page (VI00) describing the preparations and the travel day. I later wrote a php script that was included at the top of the code for each trip that. This contained all the common scripts for handling layout and navigation as well as the unique elements such as character sets for foreign words.

A separate php script for each page contained the code necessary to display the page. Most of the necessary functions were stored in a file named JournalFunctions.php. A file named JournalSetup.php contained other settings. These were all “required” on every page. Styles were stored in JournalStyle.css and JournalMenuStyle.css.

For the most part the original design worked fairly well. One difficulty that I had no way to anticipate was that the Unix version on the iPower servers was more sensitive to capitalization than the Windows version. I had to be careful with the file names assigned to images.

Twenty years later I find it astounding to report that I completed all of this within a few months. To each member of the tour group I sent an email that invited them to view the finished product on Wavada.org. Quite a few of them looked at a good portion of the journal and responded that they really liked it.

Other projects: I needed to design a home page. I knew that I wanted to have a huge wave as the background so that people would know how to pronounce the name Wavada. I found a photo of with very high density that depicted a monstrous wave better than I could have even imagined. It was on the Internet, but I don’t remember the location.

iPower offered an incredible array of free features that were associated with the website. The two that I made the heaviest use of were email and WordPress. I only needed to create three or four email accounts, but I made good use of them. I made Mike@Wavada.org my primary email account. Much later I created another account called Yoga (the name of my laptop at the time). Email sent to the Mike account was automatically downloaded to Outlook on my desktop. The Yoga account was not. So, I could send or forward emails from Mike to Yoga for activities (such as ZOOM meetings) that required the laptop.

I also set up an account for Sue, but I don’t think that she ever used it.

The other free feature that I employed a lot was WordPress, the software that I used to make this and hundreds of other blog entries. The oldest object in the WordPress section of Wavada.org is from 2010. However, I don’t think that I made much use of the product until March of 2012. That is the date of the oldest images that I uploaded. I might have written a few earlier blog entries that contained no images. An incredible number of these images—and a few other files—were uploaded during the pandemic and the subsequent months.

At first the home page for Wavada.org simply contained links to the few items that I wanted to allow the public to see. I changed the format dramatically when I discovered a widget that was available in google’s jQuery library. This allowed me to present the table of contents in an attractive tabbed manner.

I wrote a large number of programs concerning the game of bridge (introduced here) for my own use. For a while I maintained a complicated set of programs that I wrote to keep a detailed record of the bidding agreements with my partners. Eventually I decided that this was too much work (as of 2023 I had played with 141 different partners). I also created online programs for displaying an article index for topics covered in the Bridge Bulletin (posted here) and for providing game plans for challenging declarer problems (posted here).

I figured out how to parse the pdf files for hand records from bridge games. I created a database of these hands so that I could establish probabilities to associate with certain bridge situations. For example, I determined that Losing Trick Count⁴ was more accurate at predicting the number of available tricks at game level or lower than point count that has been modified as suggested by Marty Bergen in his Slam Bidding Made Easier book. However, the opposite was true for higher contracts.

I started to attend Wednesday evening games at the Simsbury Bridge Club in 2004. At some point I created a webpage for the club. It was still in use in 2023. The link is here.

As an adjunct to my job as webmaster I created a database of bridge players throughout North America on Wavada.org for District 25 of the American Contract Bridge League (ACBL). That story has been chronicled here.

I adapted the code for the travel journals to create online pages for each chapter of the book that I wrote on papal history entitled Stupid Pope Tricks. The book is posted here. The story of the Papacy Project that led to its creation is chronicled here. I also posted in the same format Ben 9, my historical first-person novel about Pope Benedict IX, here.

1. In 2023 this product is still offered for the i5 operating system. Zend has been purchased by other companies a few times.

2. The journal for the 2005 tour is posted here.

3. I used the same file names that Cascio provided with the letter b at the end. For later journals I dispensed with the uploading of the smaller versions of the photos and instead uploaded a full-page version of each image and used HTML to specify the size displayed in the journal. I also changed the naming of the images in the daily folder to be meaningful.

4. Losing Trick Count is explained here and elsewhere on the Internet and in print.

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.

Wavablog

Memoirs, bridge, popes, travel, and other stuff

Tag Archives: JavaScript

2013 Bridge: Webmaster for District 25

2005-? Wavada.org

1999-2002 TSI: The Million Dollar Idea