Tag Archives: PageMaker

2005-2009 TSI: AdDept Client: Macy’s South

Posted on by
2

The last AdDept client. Continue reading →

By the time contract had been signed. and we had started the installation, Macy’s Inc. had officially renamed its division based in Atlanta from Macy’s South (MSO) to Macy’s Central. This was done to reflect the fact that that division was scheduled to absorb most of the stores from Hecht’s and Foley’s after the big acquisition of stores from the May Co. However, I never heard anyone at TSI or at Macy’s refer to the people in Atlanta as Macy’s Central. Only New Yorkers could think of Atlanta as being central.

I cannot prove it, but I am pretty sure that TSI won the MSO account because of the efforts of Beverly Ingraham and the other other employees in Foley’s advertising department (introduced here). I know for a fact that people from the advertising department at MSO had made a trip to Houston to investigate the AdDept system there. They came away very impressed with what the system had allowed them to accomplished. The strong relationship between the department’s employees and TSI over a period for more than a dozen years was a point of emphasis.

The advertising people at MSO had been struggling to use an outdated version of FedAd named Assets.1 It was no longer supported by the development team, and no one thought that it could handle the increased load of two new divisions. The FedAd developers also had warned the seven (!) advertising planners that they would not be able to produce software that would allow them to plan in the way that they did. Several areas of MSO’s advertising department had developed PC systems to handle their tasks. The one used for direct mail was quite sophisticated, but it was also unsupported and undocumented.

Aurore Murphy.

I learned about MSO’s interest in a phone call from Aurore Murphy2, the Advertising Director, in November of 2005. She told me that the decision to use AdDept had already been made and that the hardware was being arranged. She asked me to come to Atlanta to talk with them about what changes would be needed to make AdDept work for them.

I could hardly believe my ears. No sale was ever this easy, and this was a division of Federated/Macy’s! I asked Eileen Sheehan-Willett (introduced here), TSI’s administrative person, to book me on a Delta flight to Atlanta for November 29. Aurore advised me to take a MARTA train from the airport to the Buckhead area. She insisted that I stay at the Marriott Courtyard that was near their office. For three days I met with people in every area of the department. It was probably the most productive trip of my entire career. Everyone was prepared to talk with me.

Note: This blog entry contains much more detailed information about the installation than the entries for most other clients. I discovered a large number of very detailed and complete notes as well as many other documents. I thought that it would be a good idea to give a feel for the scope and difficulty of the work that TSI did for its clients during the installation of the AdDept system to assure that it performed to the client’s satisfaction.

The first trip: Here are excerpts from my notes:

Some things are done in a system named Aims. ROP (and maybe something else) is done in Assets. Many things are done on spreadsheets. They use one six-digit system of “ad numbers” for ROP. They use a different system of job numbers for other media. The latter start with a three digit event code. They said that they would not mind changing numbering systems.

The reassignment of stores will take place on a staggered basis over the next nine months. This will be very confusing.

The Home Division does not place any ads. However, they do handle the co-op and production of the pages for home merchandise. They then transfer these transactions to the retail divisions. The people at Macy’s South seemed to think that this is a mistake.

Federated determines their merchandise department numbers. All divisions use the same numbers.

My first meeting was with Cliff Webber3 and Beth Lane4, the pair who ran the Advertising Business Office. It lasted almost four hours. I reported that “They gave me every report that they use for closing. Nothing seemed insuperably difficult.” The list of issues that I brought back to Connecticut was too long to include here.

Steve Weinbaum.

My second stop was in planning:

Miriam Pechar.

I met with Steve Weinbaum5 for a couple of hours. He now works in another area, but he was the planning manager for years, and he is the one who knows how their system works. The person who does this job now is named Miriam Pechar6.

It is hard to believe, but they primarily use seven different spreadsheets, one for each GMM. Each ad is on each spreadsheet!

They want output files for all of their reports.

I think that they will work with status P ads. When the plan is approved, the ads will be changed to A and handed over to the appropriate media manager.

They supply data for database marketing. Lots of new fields.

I then spent a half hour with Laurie Stenwall7, the Database Marketing Manager. She said that she would like to be able to get the information that they need to schedule a piece from AdDept. Most of that information is from the ad planners.

Karla Schottle.

I likewise spent thirty minutes with Karla Schottle8, Advertising Effectiveness Manager. She and her group analyze the costs by event, merchant, and market. She would probably love it if she had access to DAPANDL, DACOMMD, DAACTST, and DACOMMST, the files created by the cost accounting programs. One troublesome issue popped up:

I think that we may finally have to address the polybag problem, namely how do we handle it when the project involves a polybag that contains a book with stitch-ins and blow-ins and several other pieces.

Jeanna Corley.

I met with Jeanna Corley9, the Production Manager, for about an hour. Nothing that she showed me seemed that difficult.

My meeting with Andrea Harrison10, the Traffic Manager, was a short one. She was not on the original schedule. She showed me how she kept track of the progress of production jobs. Nothing was out of the ordinary. Only two issues emerged:

They would like a project list for each team. Do we still have a way of specifying the creative/production team for each ad?

They sometimes have swing pages for merchandise, but it does not seem to be necessary to keep track of this in AdDept.

Karen Martin.

The two-hour meeting about newspaper advertising involved Karen Martin11, Vice President of Advertising, Annemarie Poterba12, the ROP Manager, and Bill McFadden13, a Media Planner. It lasted for a couple of hours. Here is what I wrote:

They are very backward in this area. They do not even send insertion orders; they just print a schedule and send it to all of the papers! They were overwhelmed by what we could do for them, especially with AXN. The only slightly challenging thing will be in the area of competitive lineage, which they enter in as a summary number for each competitor-newspaper combination.

Karen, Annemarie, and Bill.

Here were some of the issues in the newspaper area:

They need to show what markets the ads run in. Their schedules use a mishmash of methods – lists of market groups like Stage’s, checkmarks, and names of individual papers. I think that they might like something like Foley’s schedule.

They would like a method of getting a list of the papers that have actually received the inserts from their printers. Maybe we could give them a checkbox field in AXN so that they could confirm each one when it arrives. Then the unchecked ones could be reminded with the nightly update program.

We may need to do some work to provide them with a change report that is as easy to read as the one that they currently use.

They have a This Year-Last Year report by day that might be a little challenging. We will have to provide them with a substitute for the shading that they use to flag the sections for last year.

They use one ad per page for sections. Is this our recommended method?

They said that they might be interested in entering completed dates for ROP. They said that Foley’s told them that their creative people enter completion dates in ROP.

They have a separate ad number for each version, but they were amenable to using version codes instead.

“Stage’s” refers to Stage Stores, a large chain of stores that was also based in Houston. The AdDept installation there has been described here.

Gretchen Watkins.

My last major meeting, with Gretchen Watkins14, the Direct Mail Manager, was different from the others:

This was the only disconcerting part of the trip. She uses a very sophisticated FileMaker Pro system that was developed by her predecessor. It has an unbelievable number of functions in it. The guy who developed it used it for every single aspect of his job, including calculating postage and approving invoices. However, I don’t think that replacing this system needs to be part of phase 1 of this project.

Of course the developer mentioned above no longer supported the program that he used, and there was no documentation.

I flew back to Connecticut with a spiral notebook full of notes, a briefcase full of sample reports, and a list of telephone numbers of everyone in the department. It was late on Friday evening when I arrived, but I was back in the office on Saturday morning to work on the Design Document.

I found a copy of the original Design Document and a supplement that covered new planning projects. Unfortunately, they are in PageMaker format, and I no longer have any software that can open them.

December 12-14, 2005: Within two weeks I was back in Atlanta. This time—and on all subsequent trips—I stayed at a Hampton Inn in Buckhead. It was about a mile south of the MSO headquarters, but I was still in good shape in those days, and I did not mind the walk. The weather was much more pleasant than it would have been in New England.

What I did mind was the inconvenience when nature called while I was in the advertising department. The bathrooms in the building were in the elevator area. To get from the elevator area to the offices you needed a badge. I didn’t have one.

By this time the department was connected to an AS/400 owned by Federated that was located at an IBM installation in Raleigh, NC. It was managed by IBM employees in Raleigh. The first thing on my agenda was to give a data entry class to about ten people in a small theater set up for training classes. I gave each of them the book that explained how the screens worked, and the conventions used in AdDept.

I spent most of the rest of the day setting up the AdDept system for them. For the most part I used the settings from Macy’s West’s version, which was on the same box. Using data files that MSO provided I was able to populate a few of the tables in the MSO AdDept system: regions, pubs, rates, vendors, and G/L accounts.

The PC that I used was very slow, and every so often it would go into an interminable stall while a program on the company’s intranet scanned it for malware.

On Tuesday James Jordan, the network guy in MSO’s advertising department, and I sat in on a conference call with Dan Stackhouse from Macy’s West (introduced here) and several people from IBM. Fran Ponder managed Federated’s account. Harry Burnett was in charge of things from a sales angle. Anthony Berry was in charge of security. Steve Tesch and Richard Antle are the technical support people. I never met any of them, but at least the mystery of where the AS/400 resided was cleared up.

Amy Diehl. For the first time I had a tiny point-and-shoot digital camera made by Cascio. I had only a vague idea how to use it.

Amy Diehl, whose title is FedAd Manager and who was the liaison with TSI, told me that she planned to enter ads the following week. She would be on vacation the week between Christmas and New Year’s.

Amy could not believe how fast ads can be entered in AdDept. She told me that entry of one ad in Assets required 172 mouse clicks.

When I left to return to Connecticut the AdDept system was usable, but there were still major glitches that I could not address. For example, neither user profiles nor output queues had been created. So, one employee could use the training user ID to sign on, but there was no way even to print.

I am pretty sure that this is Aurore.

It was still unclear as to when they would be allowed them to create these. As always, there was a freeze on programming at this time of year. They were reluctant to do anything. Aurore said that she would address this.

I noticed that Macy’s West’s DAPANDL file had an enormous number of deleted records. I wrote to Denise that itshould be changed to reuse deleted records. The deleted records should be removed to recover disk space. Since there is a freeze on changes, we need to get the project of removing the deleted records approved by the change committee. I sent myself a reminder message to work with Dan on this when I got home.

A few small problems were discovered, but so far so good.

January 10-12, 2006 trip: I wanted to get the ROP portion of the system working. It was always important to show positive results quickly, and I could usually accomplish that in ROP. My notes reported that I addressed many little things, including some problems with the way that IBM had set up the system:

I had to start the batch subsystem.

We created a pub group with the first four pubs. We then ran the ROP schedule for the one day that Amy had entered.

We created day-of-the-week rates for the Atlanta Journal-Constitution for Thursday, Friday, and Saturday.

I conducted a short query class with Amy and Jeanna.

I created three libraries for them: S_QRY, S_OUTFILE, and S_UPLOAD.

Bernice Bailey16, who works with Cliff, sent me the layouts for the upload to expense payables and to the general ledger.

There are two output queues, MCAP0314 and MCAP0315. They seem to work. However, Amy’s user profile was associated with an output queue in California. James got Fran Ponder from IBM to fix the existing profiles.

They have negotiated with several papers that a limited number of full color full page ads get a special rate. I showed Amy how to set up special rate codes for these, D/xx, S/xx, etc. I also showed the ROP people, but the planning people, whom I have yet to talk with, are the ones who actually do this.

Bernice Bailey sent me a file with the entire hierarchy. I wrote a program to create the five hierarchy file and the department file. They are using descriptions, not people’s names. I also created a 999 entry in all five files for Storewide, which is the default department.

I turned off the feature of change management for positions.

I set up their stores using codes that were identical to their market codes.

I ran contract reports using Macy’s West data, and I showed it to Annemarie and Bill. They thought that the reports would really be useful.

I showed the insertion order process to Annemarie and Bill. I also showed them how to create boilerplate for the special instructions.

I showed the AXN letter to Annemarie and Bill. I told them what we needed from them to get the process going. They were very interested, but it is nearly impossible to get them to commit to anything.

When I returned to Connecticut there were still a number of things that IBM had not addressed:

Only two user profiles have been created.

Someone needs to change the startup program to restart the S_BATCH and S_INTER subsystems.

They do not have their own job description, but I don’t know whether they actually need one.

Of course, there were also eleven action items for TSI, and the most stressful period was yet to come. January was the last month of the fiscal year, and I had been challenged to match their closing numbers for January in order to feel comfortable closing February, the first fiscal month.

February 13-16, 2006, Trip: Things were still rather shaky in Buckhead:

Cliff did not know his password for the AS/400. I reset it for him. I had to do this for one other user as well.

It took a long time, but we finally figured out the ROP accrual for January. They underaccrued by a staggering amount. I put all the ROP discrepancies in ad #052-1. They will probably need to split the items on this ad. I doubt that they will want to take all of this expense in one month.

I had a Vietnam flashback on Tuesday. The PC that I was using suddenly turned into a Mac. Seriously. Evidently the monitor and keyboard were connected to some kind of switching device which was connected to a Mac as well as the PC. If you pressed the right Ctrl key twice, you toggled over to the Mac.

Thursday afternoon was rushed, but I did manage to show Cliff and Amy how to record purchase orders both ways and how to record both media and production invoices. I thought that it would be easy to record the first media invoice from the Cincinnati Enquirer, but the ads for the first week in February had not been checked. So we had to bail out of it.

Jackie Foulds.

I need to explain the “underaccrued” paragraph above. I worked with Jackie Foulds17 to find the problem.

The “ROP accrual” was for ads that had run but for which no invoice had yet been received. Since nearly all newspapers billed by the month, the list included nearly all ads for January. Accrual accounting demanded that the expenses be incurred in January. On this occasion the list included all of the correct numbers for each newspaper, but it was in Excel, and the total as defined on the spreadsheet somehow did not include the Atlanta Journal-Inquirer, MSO’s largest paper. So, their accrual entry had been off by over $600,000, and no one had noticed! It took Jackie and me nearly an entire day to find this error because I expected the devil to be in the details.

I was gobsmacked when I found this. The fiscal year had been closed, at least in theory. The department had reported far less expenses than it had actually incurred. That meant that the expense would hit in the wrong fiscal year, which could be disastrous for the department’s budgeting. Since no one seemed to be too upset about this, there must have been a way to correct the accrual.

Only eight items were on the to-do list that I brought back to Connecticut.

March 13-16, 2006, trip: This trip focused on insertion orders, claims (charging co-op vendors), and reconciling the February closing. Here are notes:

Don Detelj.

I had to give Cliff a new password. He forgot the one that I gave him the last time that I was there. I had to do this for several other people, too.

Amy and I met with Bill and Marie. They have a sour attitude about the whole project. I am not sure why they are so in love with the system that they have. It is not very good.

I created a program DM220RMSX for them based on Foley’s insertion order program. I expanded the headline to 30 characters and made a few other small changes. I ran a sample to show Bill and Marie from the newspaper area. I can’t say that they were very impressed. They do not seem to be able to imagine how this will work.

I gave a class on entering claims. The ladies entered all of the claims for February. I ran one of the programs on SSIMONTH so that they could have a list of what they keyed in. If there is a better program for this, we should put it on the MSABO menu.

We reconciled the accruals for almost all of the papers. There were a lot of mistakes, but the discrepancy was not as large as last month. When Jackie ran the reports, she accidentally ran them from January 30 through February 26. February 26 is in March. Someone also keyed in 255 instead of 225, so they over-accrued in Pittsburgh by $30K. The business office is very eager to use AdDept for accruals.

I need to call Don Detelj18 to find out what he needs to replace the “data dump” from Aims.

Can AdDept generate the next claim number? They want to use the numbers generated by Aims for now, but they would like AdDept to assume this role in the near future.

The IBM people assigned an output queue from Macy’s West to all of the new users from Macy’s South. I talked with James Jordan about this, and he said that he would bring it up with Fran Ponder.

Annemarie is insistent that they get faxing capability for their insertion orders. Aurore says that they are trying to get them to do this. They will have to get a modem and a phone line. This could be a hassle.

It was unclear who “them” was in the last paragraph. Aurore presumably knew. It might be some combination of IBM, FSG, and someone in accounting to approve it.

The list of action items for TSI was much longer this month. That was, in some ways, a good sign. It meant that the department had enough confidence in the system that they were using it in different areas.

April 10-13, 2006 trip: Another large new wrinkle had been added to the installation: getting historical data from Foley’s and Hecht’s (introduced here).

Kristal Brown.

New players: Wendy Ellis works in the newspaper area. She will probably be maintaining the newspaper ads once they have been activated. Andrea Harrison also works in the newspaper area. Kristal Brown19 is the planner for the home division. Linda Ashe20 is the planner for storewide, cosmetics, and ready-to-wear.

They want to include Foley’s ads in AdDept for 052 and 061. Since people at Foley’s are available for data entry, I recommended that people from Foley’s key them in. They will set up a series of ad numbers for Foley’s to use. Someone is going to have to translate the ad types, pub codes, and cost codes. There may be other things involved, too.

I was able to sign on to Foley’s with no trouble.

The machine in Raleigh will soon have faxing capability.

The business office did their March accruals in AdDept by themselves without any evident difficulty.

Amy held a class to show people how to sign on to Foley’s and Hecht’s. I don’t agree with the way that she did it, but it would have been overreaching for me to criticize her. I suspect that she does not realize how dangerous that iSeries Navigator is. I would never tell any user about it if I were she.

I set up a menu named MACYREPTS on the Macy’s South, Foley’s, and Hecht’s systems so that they can sign on to the Foley’s system to run reports. It is currently identical to the SRADV menu. I later had to change the one on Macy’s South so that the Foley’s options did not show up.

I told Jackie and Cliff about the reports which I added to the MSABO menu. I had previously e-mailed them about this, but evidently they needed to hear it personally.

I created an output file for Cliff.

I had to reset quite a few passwords.

Cliff’s user ID was set up with the wrong library for the output queue. I fixed it.

I uploaded about 1,000 vendor addresses. There were actually more than this, but they did not have usable vendor ID’s on their records, so I had to program in some guesswork into the program that wrote out the records.

Jackie does not want to use multi-part forms for claims. They want to dump the impact printer. She prefers that we print three copies. The first should have the word “Original” on it somewhere. The second should say “Vendor Copy.” The third should say “Merchant Copy.”

They like the latest version of the newspaper calendar!

I don’t think that Cliff ever used AdDept except when I was there forcing him to do it. He was a weird guy.

Amy must have learned about iSeries Navigator in classes at IBM. It was (and is under its new name of Navigator for i) an incredibly powerful tool. I was definitely right to feel nervous about her talking about it with users. I probably should have at least warned her about it after the class that she taught.

The list of open items that I brought back to TSI contained one for the Roadmap produced by the planners. That one item contained at least a dozen sub-items.

Randy Reeves.

June 6-8, 2006, trip: Amy had several meetings lined up for me: The first meeting was scheduled for 8:30 on Monday. Randy Reeves21, the new Divisional VP, was in a meeting and could not attend. Here are my notes.

We started with the ROP people. They now have three coordinators – Bill, Andrea, and April Dunn. Each is in charge of groups of markets. We signed on to the web site. I walked them through setting up their own contact information using the Default Contacts page and claiming their own pubs using the Individual Contacts page. We went through the entire process of ordering ads several times to make sure that everyone had it.

Bill was worried about the Lima, OH, newspaper. I called Eileen at TSI and asked her to call them to make sure that they were with the program.

They told me that they did not want to show costs. I had Eileen suppress costs for advertiser M055. I created a printer file named IO and associated it with M220 and M230 (insertion orders for ROP and inserts, respectively). I had to make some changes in DM220RSX. The pagination did not work right, and it did not show the header comments. I had to make some changes in DM220RSX. The pagination did not work right, and it did not show the header comments. I copied DM230RBTX to DM230RMSX. I made some changes to suppress the costs and to show blank lines of header comments. I also removed the “Authorized by” line.

We ran the insertion orders on Wednesday. They all went to AXN without error. We discovered that there was a problem with the special instructions. I had to add a statement to line 72000 to initialize the SI$ variable each time. This problem was inherited from Foley’s. Faxing is not yet in place.

The second meeting was with the people who record expense invoices. My notes stated:

We went through the entire process of creating an invoice upload file. It all seemed to work smoothly. They know that they have to key in the addresses if they want them to appear on the aprons. If they have a kickback, they will fix it on the .csv file and then fix it on AdDept. They do not plan to upload invoices a second time.

I also met with the people from the Business Office.

Cliff and Jackie attended a training class on co-op commitments. The only problem that they saw with the way that we did it was in regards to leased departments.

We talked about how they will enter leased.22 I was given a copy of the roadmap for Leased. It is not that different from the others. They will enter the actual media costs and, for books, the non-home cost from Gretchen. They will enter the marked-up amount as co-op with contra type LD.

The meeting with the people in direct mail did not go as well:

I showed them how to paginate books. They were extremely discouraged. I tried to convince them that the work that they had done in option 4 (number of pages by merchant) was not wasted, but I am not sure that I succeeded.

I set the default for the GRFLAG to G. I could swear that I did this the last time that I was here. They never enter departments except for co-op.

A fair number of new problems were encountered, but most of the system was operating smoothly by the time that I left Atlanta.

One of the MSO meeting rooms. I carried my oversized laptop and business materials in the large bag. The little one was for my camera.

July 9-13, 2006 trip: This was an important visit. July is the last month of the spring season. I wrote a lot of notes.

New players: Brigitte Billingslea23 processes expense invoices in the business office; Deonne (Dee) Wolters also works in the business office; Kristyn Page24 from Foley’s works on multi-cultural ads in the planning area.

We had a meeting to set up a strategy for the soft closing. Cliff, Jackie, Beth, Aurore, Amy, and Randy attended. Most newspaper invoices for June were keyed in. However, no other invoices and no purchase orders were entered. Active ads were created for ads from Foley’s and Hecht’s. We needed to come up with a way of excluding them from all financials.

The notes listed eight steps that were taken to isolate the ads from Foley’s and Hecht’s. Note was then made of an unexpected and unwanted situation:

Aaaaarrrgh! The transition from Foley’s occurs in the middle of July between week 2 and week 3. This will make closing July extremely difficult. So the above process applied only to ads running in weeks 1-24. The last two weeks of the season must use a different process.

I included at this point an outline of a comprehensive plan to close June and then July. It took up most of a page single-spaced. Most of it concerned how to get all the data entered for June, but the short items for July and August were interesting.

Mary Wiseman.

Mary Wiseman25 will accrue Foley’s expenses and send them to Cliff, who will enter them as a manual journal entry. Aims will be used for Macy’s South expenses. We will go through this whole process again next month. For August they will use AdDept somehow. There is no choice.

Then I listed what had been done on this trip to implement the plan:

I found three ads that had illegal values for the “Ad Type for Pages.” I fixed these and made sure that there were no others.

I twice scheduled the cost accounting to run in the evening, and I ran the actual version of the roadmap. It seemed OK to me, but there was nothing to compare it with.

For the purpose of catching up on entering expense invoices I recommended that they enter them in batches that were sorted by the month that the items were paid. Their natural inclination is to enter them by the month in which they were expensed. The business office people keyed in production invoices all week.

Cliff wanted a way to be able to see an audit trail of all of his manual journal entries. So, I planned to show him DA201, but I never got around to it.

The TSI user ID’s for both Dee and Brigitte had been set up so that they could not upload invoices. I changed both of them.

Amy told me that they do not exclude discounts when calculating percentage leased charges. I therefore changed that value in the specs. I also took out the default markup. She adds the markup to the percentage. I did not change the setting for co-op calculations. Amy was not in the office on Thursday. She had an emergency with her daughter.

I showed Cliff and Dee (who handles them) how to key in broadcast invoices. [Specific instructions for six tricky steps were listed.] I had to fix all of their existing broadcast invoices: All the DAMEDVD and DATRNSD records were off by 11.11%. I divided the amounts by .9. They pay gross at the market level! I created indirect sub-accounts AGCF5 (television) and AGCF6 (radio) to hold the credit for 10% of the gross. I added the credits to the invoices using DA282. When I fixed the broadcast invoices, it left the transactions out of balance. I needed to fix the OFFST entries.

Amy said that she thought that the process that I wrote up (suggested by Miriam) is too complicated. However, she did not have an alternative.

I brought back a list of problems. It was not overwhelming, but several items were gnarly.

This was the training room. It is also where they often let me work.

July 24-25, 2006 trip: There was a lot of tension. We were running out of time, and the game plan was to no one’s liking.

Amy, Beth, Cliff, and I spent Monday reconciling expenses for June. The newspaper accrual that they submitted included expenses for the last four days of May. This was a mistake. I wrote a query named MAY3DAYS in S_QRY to isolate these expenses for them. They eventually were able to tie it out. The broadcast accrual that I manipulated two weeks ago tied out. The P.O. accruals eventually tied out, too.

Beth got me a file of the invoices paid in June (except for prepaids). I made a database file name MSGL/AP0606 out of it. I then wrote a query named ALLAP in S_QRY to try to match it with invoices in AdDept. I created a second query named APTRNSMO to list the invoices with transaction month of June to try to get these to match up. By comparing the two we were able to find invoices with a posting month of June that were actually paid in earlier months. Amy moved them to the proper months using DA282. There were still unmatched invoices on the list of invoices for June, but they were for jobs in future months.

While we were doing all of this, the people in the business office were working on July.

On Tuesday Amy came in late because she had a flat tire. Beth worked on the ROF for July in the morning and had to leave about noon. We only got a few minutes of her time. I ran the open co-op report. It was much shorter than I expected. I soon learned that none o the co-op commitments for direct mail or preprints had been entered. I ran the Co-op Status by FOB report for June. I was able to match up the ROP pretty well. However, I could not use this to match up the actual co-op because the report from Aims included claims from July.

I created a few purchase orders for accruals that Cliff made in June.

I think they have given up on reconciling AdDept with Aims and the G/L for June and July. They just can’t seem to get the data entry done. However, they must use AdDept in August. That is now the highest priority. They will call me on Friday with their decision about when next I should come to Atlanta.

I explained to Amy how to key in the fax numbers for newspapers that do not subscribe to AXN. Amy asked me for the umpteenth time about faxing, and I gave her the same answer as before. She called IBM in Raleigh. They said that there was no need for a prefix in dialing out. They also said that everything was configured, but I could see no fax jobs running.

A lot had been accomplished, but many difficult items still needed to be addressed.

August 21-24 trip: I wrote a very long report about this trip.

Cliff showed me an invoice upload that did not work. There were no DUNS numbers on the vendor records. I wrote a query named NODUNS in S_QRY to find these for them.

They finally balanced their gross expense for June.

I wrote a process for Cliff to check the expenses in the G/L against AdDept. It consists of a program named RMV40, a command with the same name, and four queries: GLSUM, GLMATCH, GLNOMATCH1, and GLNOMATCH2. The queries are all in S_QRY. I documented the process in the document named GLMATCH, which I will put in the Macy’s South client folder. GLSUM must be run after the program and before the other queries. Later we discovered that the invoice upload process was stripping off starting 0’s and converting to upper case. I wrote a program to replicate this. I ran it after GLSUM.

They had had trouble faxing to Hampton. I added some more delays before the 4, and it seemed to work. Later April got a new fax number from Hampton. The faxing works with the new number. I don’t understand how Hecht’s was able to use the old number.

They had a pep rally at the Ravinia Crown Plaza on Tuesday. No kidding.

They decided that they want to use real PO’s with real vendors for Spring 2007. They will create blanket PO’s for accrual purposes for the fall. Randy said that they want to use 061 actual costs for direct mail for Hecht’s, Foley’s, and Macy’s South. I ran the DM647 to get actual costs for each direct mail book on Hecht’s system and Foley’s system. I ran DM489 for each book in the month for February for Hecht’s to see if that was what he wanted.

I gave a little P.O. class to Amy – DP260 and DP261 – so that she could help the other people learn about P.O.’s. I deleted USEDP271. This was a vestige from Macy’s West.

We discovered on Tuesday that no estimates had been entered for preprints. Then we discovered that all changes to estimates had been entered in Aims rather than AdDept. Evidently the people in that area did not understand that Aims was no longer being used.

I wrote off all open purchase orders. They did not close July in AdDept, so all of the P.O.’s were left over from June or earlier. That meant that somehow we needed to get the P.O. accrual for July into AdDept in order for the cost accounting not to consider 100% of the late invoices as August expense.

I entered the radio, television, direct mail, and insert accruals for July. Cliff decided that he did not want to reaccrue any of these. I therefore entered two zero invoices to write them off in August. I ran the accrual for July. The items showed up. I ran it for August. They were not there. Cliff has been carrying a short-rate accrual for ROP. I entered it as an indirect P.O. that hit the ROP account. He wanted to continue carrying it in August.

I wrote a process for Cliff to check the prepaid invoices in the G/L against AdDept. It consists of a program named RMV40PPD, a command with the same name, and four queries: PPDSUM, PPDMATCH, PPDNO1, and PPDNO2. The queries are all in S_QRY. I documented the process in the document named PPDMATCH, which I will put in the Macy’s South client folder. PPDSUM must be run after the program and before the other queries. Later we discovered that the invoice upload process was stripping off starting 0’s and converting to upper case. I wrote a program to replicate this. I ran it after PPDSUM.

I do not think that the programs to strip zeroes (STRIPGL and STRIPPPD) will be needed in September. The invoice upload will have been changed so that the 0’s do not get stripped off, and they no longer can use lower case.

I created TSIFAXOUTQ in QGPL. I then associate this output queue with TSIFAXPRTF and TSIFAXPRTI in TSIDATAS.

I checked the results of the ROF worksheet (which Cliff said is now obsolete because of management changes) against the accounting. It seemed to balance for everything except for ROP and magazines.

I set the earliest month for co-op accruals to be 062-1. If there were accruals from 061, they are not compatible with the way that we do it. I then ran the report and gave it to Cliff.

They asked me to change the specs so that they could pay any ad, no matter the status.

Needless to say, I did not attend the pep rally.

I brought back nine issues. Most of them were problems, not requests for new programming.

November 9-13, 2006 trip: Things had settled down a bit according to my report;

I put together makeshift processes for them to use to print the detail of their non-media expense by G/L account. I documented both of these processes. Basically they create output files from their accruals. Then they do a query for their actuals. Then they combine the results into one file and query that file.

Their accrued co-op was way off because they had not relieved any commitments for ad load. I showed them how to do this with claims for $0.

I wrote a query S_QRY/ACTVBYFOB for Jackie to get a list of actual co-op by FOB. She will use this until DB522 is fixed. This query creates an output file. I also gave one to Cliff named ACTVBYFOBP that prints. There were some authority problems, but they were both working when I quit.

I wrote a query S_QRY/INDIRECTS to get actual expenses for indirects for a season. They need this for the “Macy’s West Report.” The directs will come from DD #27.

I wrote a query named S_QRY/LINATLBU to provide a backup for the contract status report (DM767). The query S_QRY/INVADJ06 must be run first.

I changed the definition of the FILTER condition in the SLSXFR menu so that the filter program would appear.

Cliff gave me a file of sales by department for a month. A separate tab shows the sales by store for a month. Unfortunately the stores in DASTORE are actually markets. We tried to determine whether there actually is a requirement for either sales by store by month or sales by market by month. Cliff did not think so. Karla does not need the sales by month, but she would definitely like the sales by day. Miriam was not available.

I went over the prerequisites for running the store cost accounting with Amy. Basically she needs to run the BOOKQ query and option 7 on menu DAYEND.

I changed the default printing for DA102 so that the default is to put the printout on hold.

A few problems were discovered, and a few requests were made.

January 2-4, 2007: Both the notes and the list of issues were shorter than usual.

I had previously provided them with a query to find the amounts to charge their leased departments. They had three problems with it: One department was overcharged for an ad that was only 50% leased. I gave them a query named NOT100LEAS in S_QRY to find these. On two ads the amount that she charged them did not match the query. Cliff thought that the query was wrong, but he was off by one ad when he tried to match up a report with a query.

Cliff uses DB653 to do his journal entries for “accrued co-op.” He “accrues” the difference between season-to-date actuals and season-to-date committed. He and I have a different idea about what accruing means.

I had to increase the record length of DASLSTSI from 30 to 35.

I made a couple of changes to DA168U to make it match the file that Cliff can easily deliver. It also multiplies the amounts by 1,000. I checked individual entries and the totals for the November file that Cliff provided me. Everything seemed to work.

I wrote up instructions on the sales upload process. I e-mailed the instructions to Cliff and Amy.

I met with Gretchen Watkins and the two ladies who work for her in production. I showed them how to create purchase orders using option 26 of WRKADS.

They wanted to split freight between printer freight and mailer freight. I created a new sub-account FRML3 based on FRGT3 and a new cost code 705. They also wanted to split the computer charges to estimate the cost for “tracking and tracing” separately. I created a new sub-account TR&T3 for tracing and tracing based on COMP3. I also created a new cost category 515. I checked a direct mail ad. The new cost categories both showed up in option 28.

They are in the process of installing a new workflow system called Work Horse. Amy wanted to know if we could create a .csv file to feed it. She said that she would have to find out what would be in the file.

This was the last trip to Macy’s South. Since it occurred in the last month of the fiscal year, I suspect that the department’s budget for the next year included no provision for paying for my presence.

My life in Buckhead: I never rented a car in Atlanta. I always took MARTA from the airport to Bulkhead. On the first trip the hotel was within walking distance from the train station. On subsequent trips I took taxis from the train station to the Hampton Inn. I usually walked to Macy’s headquarters. One time when it was raining I asked the hotel to call a cab for me. They got me a ride, but it was not in a licensed cab. I did not complain.

I remember a lot about working at Macy’s, but little about anything else. The MARTA rides to Buckhead were usually late at night. The airport is south of the city, and Buckhead is far to the north. Sometimes it was a little creepy. The route went through downtown Atlanta. Often groups of young people who had been clubbing boarded there. At one point my car was occupied by myself, a group of young black women, and a group of young white men. The women were talking, and the guys overheard them. A discussion about the wisdom of the invasion of Iraq ensued. I was happy when that trip ended.

I cannot remember ever socializing with anyone from Macy’s. I ate lunch by myself in the cafeteria. I sometimes ate supper in the food court at a neighboring mall. Most of the time, however, I stopped at Arby’s on the walk back to the hotel and picked up a Reuben or a roast beef sandwich and ate in my hotel room.

I have quite a few memories of the Atlanta airport. My flights usually departed from Terminal F, but after I cleared security I usually took the tram to Terminal E. The elevator ended in a food court that contained a pretty large Chili’s restaurant. I would usually eat supper there, and, if I did, I would order the Baby Back Ribs with broccoli instead of French fries.

That restaurant was the only part of the airport that I liked. It always seemed very loud to me, even though I almost always spent the waiting time listening to operas or Italian tapes on my Bose headphones.

Epilogue: TSI maintained a good productive relationship with Macy’s Central until 2009, when the headquarters in Buckhead was closed, and all advertising was scheduled, produced, and ordered from New York.

1. FedAd and Assets were software systems written by a group that had been organized by Gilbert Lorenzo of the Burdines division. The system was supposed to be one integrated system that covered all aspects of advertising. It was used by Burdines and Bon Marché. After the integration of all of the divisions into New York some version of it was used in the advertising department there. The attempts to entice me to involve TSI in this multi-milllion dollar undertaking are described here and here.

2. Like almost everyone in the department, Aurore worked at Macy’s until 2009, when the advertising operations were consolidated in Manhattan. Her LinkedIn page is here.

3. Cliff looked like Santa Claus. I spent quite a bit of time with him over the course of the years. He revealed to me that he had a fairly substantial business on the side selling things on eBay. On one of my trips he told me about his plan to sell programs from some sort of Martin Luther King event being held in Atlanta. He also told me that some of his goods came from dumpsters. His LinkedIn page is posted here.

4. Beth Lane was a CPA who worked part-time in the Business Office. I remember very little about her. Her LinkedIn page is here.

5. Steve Weinbaum was astounded that I was willing to try to replicate the MSO planning process. I explained that I had done a lot of AdDept installations. No one had anything like this process, but several of them had other aspects that were equally challenging. His attitude impressed me. I wished that I had been able to work with him more. His LinkedIn page can be found here.

6. Miriam Pechar’s LinkedIn page is here.

7. Laurie Stenwall’s LinkedIn page is here.

8. Karla Schottle’s LinkedIn page can be viewed here.

9. Jeanna Corley’s LinkedIn page is here.

10. Andrea Harrison later moved to newspaper scheduling. Her LinkedIn page is here.

11. Karen Martin’s LinkedIn page is posted here.

12. Annemarie Poterba’s LinkedIn page is located here.

13. Bill McFadden’s LinkedIn page can be seen here.

14. Gretchen Watkins’s LinkedIn page is here.

15. Steve Tesch’s LinkedIn page is here. I could not find a page for any of the other IBM people or James Jordan.

16. Bernice Bailey’s LinkedIn page is posted here.

17. Jackie Fould’s LinkedIn page is posted here.

18 Don Detelj (silent j) was always sort of a mysterious figure lurking on the outskirts of the installation. His LinkedIn page is here.

19. Kristal Brown’s LinkedIn page can be seen here.

20. Linda Ashe’s LinkedIn page is here.

21. The LinkedIn page for Randy Reeves can be found here.

22. Most department stores have at least one department that is operated by another company that leases the space. Those companies must pay for the advertising that is run for them.

23. Brigitte Billingslea’s LinkedIn page is located here.

24. Kristyn Page’s LinkedIn page can be viewed here.

25. Mary Wiseman’s LinkedIn page is here.

1988-2014 TSI: AdDept: System Structure

Posted on by
2

A complicated system. Continue reading →

People who have not worked in retail advertising will probably have trouble understanding this entry. Nevertheless, because the AdDept system was the focus of my life for so many years, I feel obliged to document as much of its structure as I can remember. It did not occur to me that I might want to undertake such a task until very recently. Consequently, when I closed down TSI in 2014 I discarded almost all of the system’s documentation. The few computer files that I have subsequently found are mostly PageMaker documents. I don’t have that software on my computer, and the files are too large for the services that will convert them to pdf files online. So, I must rely on my memory, which is not as reliable as it once was.

AdDept was designed for and implemented in OS/400, the operating system of the AS/400 and its follow-on hardware. Some of the important and unique features of this operating system are described here. Every line of code that we wrote in 1988 still worked in 2014, and I have no reason to expect the code to stop working any time soon.

All programs were originally written in BASIC. Around the turn of the century IBM stopped supporting BASIC, but TSI was authorized to install the product (a compiler, and interpreters of both BASIC commands and BASIC procedures) on any system that use our software. This only caused one major problem, which is documented here. However, Denise Bessette did not like this arrangement and undertook to convert the programs to ILE RPG. I never appreciated the value of that idea, and I never took the time to learn that language, which is supported on no other system.

All data tables and the major programs in AdDept began with the letter D, which stood for department. This was for TSI’s benefit. The ad agency system used a similar structure, but no files or programs began with D. The second letter in AdDept tables was usually A, I, M, or P, which stood for accounting, (loan room) inventory, media, and production. Programs that were used for cleanup, copying, and other miscellaneous tasks began with DX.

All AdDept programs were stored in the same library1. It was usually named TSIPROG. The data was in a library named TSIDATA. A few clients had additional data libraries for additional companies. At these installations we created a separate library called COMMON or TSIDATACOM to hold the tables that were used for both companies. For example, both companies probably used the same ad types and expense classes (major media). The tables used by both were moved from TSIDATA to the common library. A new data library was created for the data files for the second company. In the beginning it contained empty copies of all of the remaining files in TSIDATA.

No two instances of AdDept were the same, but each had the same TSIPROG library. The settings for each installation were designated in two ways: 1) A set of empty one-byte files, the existence of which activated certain features; 2) a file called DASPECS that contained a very large number of switches, descriptions, and system values. The program to maintain the system values was not on a menu, and users were not allowed to run it.

Everyone needed a user ID to sign on to the system. Those connecting through a network could have any number of simultaneous sessions open.

AdDept’s user table, which was also on no menu and could be run only by the AdDept liaison, limited the programs to which the user had access. If the same employee worked with two different data libraries, a second user ID was required. The two user ID’s would have different library lists.This arrangement may sound cumbersome to people who are used to managing hundreds or even thousands of nested folders, but it did not seem strange to the users of a multi-user system. Furthermore, it was absolutely critical that changes not be made on files in the wrong library. All TSI menus displayed the name of the data library to help eliminate confusion.

The retail calendar was accommodated by the season table. The key was a three-digit number. The first two digits were the fiscal year. The third digit was 0, 1, or 2. 0 meant that a standard twelve-month calendar was used. 1 and 2 were used for 4-5-4 retail calendars, which are described here. This table contained the name of the season, the starting date, and the number of weeks in the season.

Ads were classified by three separate codes:

  1. The one-digit insertion code determined which set of screens was used for data entry. This was a fixed set, but more codes could be added for additional media.
  2. The one-digit expense class identified how the ads were categorized for accounting purposes. Later a sub-class code (blank default) was added for one client.
  3. The two-digit ad type was specified when an ad was created. This table held the insertion code and expense class. It also had a binary field to identify whether color charges were applicable.

Media vehicles, such as newspapers, magazines, and broadcast stations and networks (called pubs in AdDept), were identified by a five character codes combined with a two-digit number (usually 0). For newspapers at least one number was reserved for inserts (usually 10). The users specified the days on which the paper published, whether it was AM, PM, or a combo2 and the paper’s depth (maximum number of inches vertically on a page). For direct mail the pubs were usually geographic markets.

Stores could be identified by a five-digit number.

Every pub had a list of stores that were associated with it. There was also a date-sensitive pub-store allocation table that contained the percentages allocated to each store associated with the pub. The key to this table included an effective date. Less than half the AdDept retailers allocated costs to stores, but the ability to do so was very important to those that did.

AdDept users almost never paid the published rates.

Rates for ROP and inserts were date-sensitive. For ROP separate rates could be entered for black-and-white and several different color choices. There were also tables for linage-based discounts and premiums for things like special positioning such as “back of main”—the last page on the first section of a paper. For inserts a table of usual quantities (thousands of copies) could be created, with rates for each.

The system needed to be able to find the right rate to apply whenever an ad was changed or moved. Costs could also be recalculated en masse when a new contract had been negotiated. These were attractive features.

Probably the best idea that I had when designing the system was to allow the definition of pub groups (identified by five-character codes) to specify sets of pubs in which the same ads often ran. Clients could have hundreds of these or none. When a new ad was created, one pub group could be specified. A schedule could automatically be created with all the pubs in the group.

The hierarchy of participating merchants had five levels in AdDept. The lowest (most detailed) was the department. The system called the other four ADMGP, GRPVP, SENVP, and GRSEN to match Macy’s East’s designations. Most retailers had only two: DMM’s and GMM’s. The May company used “CCN numbers” to group related departments. For each level each client determined the descriptions used on screens and reports.

Employees were identified by three-character codes. Employees could be assigned to production jobs. So, an employee could see a list of all of his open assignments.

The traffic system allowed specification of a code for each production job that determined the job’s production schedule. So, black-and-white ROP ads might have a three-week production schedule with eight steps. The number of days for each step could be specified. Then the system would count backwards from the release date to build a schedule of due dates that accounted for weekends and holidays. The completion dates of each could also be entered (an X meant “today”).

This seemed important to several clients, and we built it precisely the way it was described to us. However, the production employees did not like it. For one thing, most of them used Macs for working on the ads, and they found a text-based system clumsy. I don’t honestly think that they would have liked it much better with a GUI (graphical user interface) as the front end.

The accounting tables were similar to those in the GrandAd System (described here) or any other system. They were designed to be consistent with whatever system was used by the accounting department, but AdDept users did not need to memorize the very long codes that were common in those systems. In AdDept the main entity was the sub-account, which was identified by a five-character code. One corporate G/L account was specified for each sub-account.

The vendor table also had a five-character key. The corporate vendor number was specified there. This table was used for merchandise, media, production, and other vendors.

Categories of production costs were identified by three-digit codes, just as in the GrandAd system.

The Ad Files

The system had one major header file for ads of all types and a number of lists that were associated with it. The ads file3 was identified by the season, a five-digit ad number (usually generated by the system using client-specific rules), and a one character version code (usually blank). The ad number could either be entered or generated by the system. Data entry began with the specification of the run date and ad type. A large amount of information was deduced from those two values. The headline and size4 of the ad were then entered on the header screen, which also contained many other fields.

The second step for ads of all types was the media schedule. If the pub group was accurate, nothing had to be entered here for ROP and inserts. For direct mail the quantities by market were entered.

The third step was the list of participants with percentages and co-op commitments.

Expected production costs could either be entered as one lump sum or detailed by category.

Audit Trails

History records were created for any activity that affected planned, committed, or actual costs or income. Reports and screens were written for viewing them. A few custom reports were also written for clients.

Planning

New ads were ordinarily assigned a status of P, which stood for “planned”. When the plan was completely approved, a program could be run to change the status of all status P ads to A (active). At the same time records of the detail of the costs of those ads at that time were recorded in separate files named DAPLAN (by department or group) and DAPLANST (by store).

Changes could still be made to any aspect of any ad, of course. Those values were considered “committed”. The actual costs were based on the measurements and the invoices from the media and production vendors. Actual co-op was based on the “claims” that had been processed.

In subsequent years several AdDept users let the system build the entire schedule based on the previous year. Thus season 951 could be built based on the ads run in 941. This process was called “anniversarying”.

Cost Accounting

What I called “cost accounting” was commonly called BI later.

Most advertising departments were keenly interested in comparing planned, committed, and actual costs by merchant or by store. AdDept had programs that would create detailed records every night by store and/or merchant for all ads in the current season. The merchant records were stored in DACOMMD (committed) and DAPANDL (actual). The records by store were in DACMDST and DAACTST.

Numerous reports were written to allow comparison of planned, committed, and actual costs and income (from co-op). Some users also queried these files on a regular basis using IBM’s Query/400 product.

Interfaces

Broadcast ads could be fed into the system from Doner, the May Company’s ad agency, and from Media Management + files created either internally or by an agency. There may have been one or two others of these.

A couple of clients used ad agencies for their newspaper ads. TSI constructed interfaces to receive the ad schedules from the papers.

Several interfaces were created to send files to feed corporate Accounts Payable and General Ledger systems.

Sales at the department level could be downloaded from the mainframe. Customized reports helped gauge the effectiveness of ads in comparison with the costs.

Backup

It was easy to schedule a backup nightly and to schedule the cost accounting programs to start when the backup was done. The backup would not save files that had record locks. Any time that a record was read from a program that could update that file (as often occurred), the record was locked to prevent one user from accidentally overwriting the work of another. It was sometimes difficult to persuade users either to make sure that everyone had signed off every night or to shut down the interactive subsystem before backing up and restarting it later.

TSI recognized this problem and warned the users about the possibility of lost data if files were not backed up routinely and correctly. We even offered (for a modest fee) to check their backups every day and notify them by telephone if the backup for the previous nights did not complete correctly. Only one client took advantage of this service.

The failure to check backups resulted in one ugly mess that was described here.

Cleanup

By the standards of the day the cost accounting and history files often became extremely large. A menu of programs that permanently deleted records from old seasons was provided.

Other Modules

The Loan Room inventory system was successfully used by Macy’s East for approximately twenty years.

A Photo Shoots system was also designed for Macy’s East, but it was never implemented. I don’t remember why they lost interest in managing the activities of their studio. The location of the studio in Newark may have been a factor.

Many modules were developed for Belk. One that I remember calculated the store’s use tax liability for direct mail pieces for each jurisdiction.

Saks Inc. in 1999 wanted TSI to design a very complicated system for collecting data from the systems of each of its divisions and, eventually, to produce reports that compared divisions. I was very happy that nothing came of this idea.

A special module was created for Radio Shack to manage its advertisements in magazines.

I suspect that there must have been a dozen more of these modules that I cannot recall. We delivered hundreds of custom programs over the years and quoted a similar number that were never approved.

AdDept was a fabulous system. Because it contained so many features, it was somewhat difficult to demo. The screens and most of the reports were ugly. Nevertheless, as soon as prospective clients understood its potential, it was easy to sell to anyone with a budget.

Unfortunately by the time of the Bush-era Great Recession in 2008, Tarot card readings for most major retailers—especially the ones that did a lot of advertising—began with the thirteenth trump card: Death.

1. “Libraries” were a type of object on the AS/400. They were places to store other objects in the same way that folders or directories are used on PC’s. However, it was not possible to build a “tree” of libraries. All other libraries resided in the QUSR library.

2. Yes, a few papers still published two editions per day in the nineties.

3. As far as the OS/400 was concerned, DMADS, the ads file, and the files that contained all of the lists were equivalent to the tables. However, TSI’s organization and documentation drew a useful distinction between the relatively stable tables that were defined at the beginning of the installation and the much more volatile ad files and transaction files.

4. The size for ROP ads was entered in columns and inches. A full-page broadsheet ad was entered as 6×21. The program knew to adjust the inches to match the paper’s depth. The size for inserts was entered in terms of thousands of copies. The size for broadcast ads was the length of the spot in seconds, usually 15 or 30.

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.