Tag Archives: CSS

2013 Bridge: Webmaster for District 25

Posted on by
1

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

Ausra Geaski.

2012 was long before “ACBL Live Results”1 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.org2 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.

Bill Braucher.

I subsequently told Ausra, whom I occasionally saw at the Hartford Bridge Club3 (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.4 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.5 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.6 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.

Allan Clamage.

Furthermore, the webmaster was not allowed to post any material unless the website editor, Allan Clamage7, 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.

Rich DeMartino

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.

Harold Feldheim.

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 Swiss8. 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 csv9 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”.

<Mrk Aquino.

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!”

Ginny Farber.

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

Sarah Widhu.

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.

Bob Bertoni.

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.

The front page of the last Bulletin.

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.

2000 TSI: AxN: System Design

Posted on by
11

TSI as a nexus between advertisers and newspapers. Continue reading →

The term insertion order was used in advertising to describe a list of detailed information about ads that advertisers provided to newspapers or magazines so that the publication could reserve the space. The design of AxN, TSI’s clearinghouse on the Internet for insertion orders, only really congealed when I had finished reading Bob Cancilla’s outstanding book about using the AS/400 for e-business, IBM’s word for commercial transactions that used the Internet. The process of determining what TSI wanted to do and how we learned how to do it has been described here.

The Internet servers on the AS/400 in TSI’s office were used in the project. The FTP (File Transfer Protocol) server was used to receive transmissions of data files containing insertion orders generated by the AS/400’s at our client. The SMTP (Simple Mail Transfer Protocol) server sent computer-generated emails to both advertisers and newspapers. The HTTP (Hypertext Transfer Protocol) server allowed the posting of web pages on TSI’s website, TSI-TSI.com.

TSI’s AS/400 was connected to the Internet through a T-1 line leased from AT&T. The backup line was a cable connection to Cox. It was seldom, if ever, needed. I can recall no problems with the connection.

AdDept changes: AdDept, TSI’s administrative system for the advertising departments of large retailers, included programs for producing the original insertion orders used to schedule advertising at newspapers and for producing change orders and cancellations. The users at each installation had slightly different methods of selecting the items from the media schedule to be ordered (usually once per week for ROP and once per month for inserts) and different formats for printing or faxing the orders. However, all installations used the same programs for updating the data files with the ordering information.

Newspapers were ordinarily designated on AdDept’s pub table with two “variations”—one for ROP (“run of press”—the pages printed by the newspaper) and one for inserts (the preprinted flyers and coupons inserted with the pages printed by the newspaper). Some needed additional variations for things like the Sunday supplement or the television guide. The pub table contained a field that designated how insertion orders would be delivered. The choices—as designated by a one-character field on the pub table—were faxing or just printing. A new option was added for delivery through TSI’s website on the Internet using AxN. When a paper agreed to a trial subscription for AxN, the field was changed for each of its versions. If the paper stopped using AxN, it was set back to its previous value.

The configuration on each client’s AS/400 was modified so that the FTP server was automatically started every time the system initiated the Initial Program Load (IPL). “IPL” was IBM-speak for booting or rebooting. Most of TSI’s AdDept clients IPLed once a week.

The sections of the insertion programs that updated the data files were augmented. If the pub was using the Internet for insertion orders, new code was executed for each order as a whole and for each item on the order. This code created a file for the order and wrote records on the file for the header (AxN‘s code for the pub, range of dates, type of order, whether it was a new order, revision, or cancellation, and a few additional items), detail (individual ads), and special instructions that could be for individual ads or the whole order. As records were written, they were logged on a file.

When the user closed the insertion order program, a routine was called to use FTP to send a copy of the file to a designated library1 on TSI’s server. The original files remained on the advertiser’s system for a while until the system administrator ran the cleanup program.

FTP clients can actually do a lot more than send and receive files, but the configuration of TSI’s server prohibited most of those features.

Processing the orders: The configuration for TSI’s AS/400 was also changed so that the FTP, SMTP, and HTTP servers started during each IPL. Another program that we wrote to monitor the library containing orders also was started at IPL. In the twelve years that this process was active we had zero failures.

The monitoring program examined the contents of the library designated to receive the files. If the library was empty, the program went to sleep for a minute or two. If it found anything in the library, It copied the files to a separate library. For each file that it found it started a batch job to process the file. It then deleted the files from the receiving library and went back to sleep.

The processing programs evaluated each file to make sure that it could read all the records and that none of the fields in any contained invalid information. Since all of this information had been generated by AdDept programs run on the advertising departments’ AS/400s2, problems almost never occurred. If any anomalies were discovered, an email was sent to me, Denise Bessette, and a programmer.

After validating the data the program created database files for new orders or updated the records of existing orders. Time-stamped log entries were written for all of these operations.

After the permanent database files were updated, an email was sent to the rep at the newspaper and the coordinator at the advertising department. It simply told them that the insertion order had been posted on TSI-TSI.com and provided a link to the website.

The processing programs were written in BASIC and IBM’s Control Language (CL). The former were used to validate the received file and to update the data files. The latter were used for system-oriented tasks such as sending emails and copying files.

I don’t remember the details of how it worked, but I think that there was also a program that monitored the number of FTP transactions in a period of time. Two of three times the system was the target of half-hearted attacks on the FTP server. We were easily able to repel them.

Setup for the interactive programs: The reps at the newspapers and the coordinators at the advertisers were expected to be able to access TSI’s AS/400 through the Internet using a browser. Therefore, it was necessary to change the system’s configuration on our AS/400 so that the HTTP3 server for the website was always started as part of the IPL. At the same time a second local HTTP server for development and testing by TSI programmers (primarily me) was also configured.

Not tsetse, TSI-TSI.com.

Security was provided by the AS/400’s HTTP server. The scripts for all AxN pages on TSI’s website (TSI-TSI.com) were placed in a library that was password-protected. The pages that described the company and its products and services were open to the public. Static pages were written in HTML, the language of the web. The scripts for interactive pages were written in Net.Data, the only scripting language that IBM supported on the AS/400 at the time.

The AS/400 had the ability to set up interactive sessions for users who logged in to the HTTP server. If we had implemented this feature, the system could have timed-out users who had entered their credentials and left the connection open. Implementing this would have complicated the development enormously. We decided not to do it until it became necessary. Like all other developers in that era, we were in a hurry to launch the product on the Internet. Since we never encountered any security issues, we never did.

I take it back. Actually there was one security issue. The reps and coordinators tended to store their credentials in their browsers so that they would be filled in automatically on the security screen. When there was turnover, or someone got a new computer or software update, the passwords and user ID’s were sometimes lost. The support people at TSI did not have the capability of retrieving passwords, but they could assign new ones. After each new one was assigned, it was given over the phone to the user. To insure that this solved the problem, the TSI employee stayed on the line while the user signed on. The user was then advised to change the password and, if necessary, talked through that process.

I am sure that both the newspapers and advertisers were happy that we did not automate this process. We only needed to deal with it a handful of times per month. If we had succeeded at convincing more advertisers to use AxN, we might have needed to automate it.

The interactive programs for newspapers: In the course of research for this entry I discovered the pdf file for the very comprehensive AxN: Handbook for Newspaper Users and posted it here. I had created this twenty-two-page document using PageMaker software in the early 2000’s before we had the first live implementation of the product/service.

The handbook included samples of all the screens and reports. This document was sent to every newspaper when it agreed to participate in the trial period. We provided no training, but no one had much trouble learning to use the system. I must say that I think that I did a superb job. TSI received amazingly few support calls.

The document is more or less self-explanatory. There are just a few things that are worth noting.

The AxN programs used “frames”4. Every interactive screen had three sections that consistently take up the same amount of space on the screen. The “Display” section was always the top area with the light blue background. The “Buttons” area was at the bottom and had a steel blue background. The third frame was “Empty”; that is, it had no space on the screen reserved for it. For each page there was a master script that loads the scripts for the three frames.

When a user clicked on a button, the empty frame was loaded with the appropriate script and executed. So, for example, if the “Confirm” button was clicked on after an order had been selected, the script in the empty frame would check to see if anything was in the “Confirmed by” box. If not it would highlight that field and display an error message without reloading the page. If the field contained characters, the script called a sequence of CL and BASIC programs to mark the order as confirmed and send an email to the coordinator at the advertiser.

The buttons available varied by page. However the Buttons section always contained a Home button (the one that looks like a house) and a Help button (question mark). The former returned the user to the site’s home page. The latter produced a page that explained all of the fields and buttons on the original page.

The interactive programs for advertisers: I also found the pdf file for the twenty-eight page AxN: Handbook for AdDept Users: It explained how to use both the AdDept programs to send new orders, changes, and cancellations and the AxN web pages to make sure that all newspaper reps have confirmed the orders. I posted the handbook here.

Advertisers who made changes to the schedule after an order was sent were expected to make the changes in AdDept and to send revision orders.

Daily tasks: Every morning a program searched for unconfirmed orders. Lists were prepared for both newspapers and advertisers. Each newspaper rep and advertising coordinator was emailed a list of the orders that pertained to them. A master list was also printed at TSI. An employee made a “courtesy” telephone call to warn reps each newspaper with unconfirmed orders that they were within a few days of publication.

Billing: In theory both the advertisers and the newspapers were billed for the use of the AxN service. In almost all cases the advertisers had been using the AS/400 to fax orders to the papers. They had been paying TSI a monthly fee to maintain this software. When they started using AxN we charged the same amount for support and dropped the faxing charge. So, there was a net-zero effect for the advertisers.

TSI’s computer programs required changes to accommodate the newspapers as clients. The main change was to convert the three-digit5 client number field from numeric to character. The existing clients maintained their numbers, but the newspaper clients were assigned alphabetical designations sorted by state.

A separate billing program was written to create invoices for the newspapers. Most were billed quarterly; a few preferred to be billed monthly.

AxN was extremely reliable and was very popular with both newspapers and advertisers. Support calls were rare. I vaguely recollect one instance in which a newspaper failed to run an ad or ran it incorrectly. I was able to document exactly what the system had done with timestamps, and neither side thought that AxN had contributed to the problem.

I definitely wrote all of the Net.Data scripts. Someone else at TSI may have written a few of the BASIC and CL programs used for AxN, but I did the bulk of that coding as well.

1. A “library” in the AS/400’s “native environment” was roughly equivalent to a “folder” or “directory” on a PC. However, libraries on the AS/400 could not be nested. That is, there was no such thing as a sub-library. More details about the AS/400’s design principles can be read here. The AS/400 also supported being used as a server for some other operating systems, but TSI did not use that feature.

2. The header record for the order contained a field that identified the format used for the files. Since no one except AdDept users was ever convinced to use AxN, no code for processing orders in a different format was ever written.

3. HTTP stands for Hypertext Transfer Protocol. HTTP servers were able to serve pages to a browser using the Hypertext Markup Language (HTML) and a few other formats.

4. I really liked the use of frames, but for some reason it was disparaged by supposedly sophisticated developers, and eventually frames were no longer supported by browsers. Instead a complicated use of Cascading Style Sheets (CSS) was necessary to produce a similar effect. AxN was still using frames when TSI closed in 2014. I have never been able to duplicate the effect of the empty frame with CSS.

5. The worst design mistake that I ever made was using a three-digit number for clients. None of our agency clients ever needed a larger field, and the client file on TSI’s system still had many unused client numbers when we began marketing AxN. I decided that it would require less effort to change the type of the client number field from numbers to characters than to expand the size of the field.