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