I have never been in a Golf Galaxy store (or experience or whatever it is considered). I know only three things about the chain: 1) The first store opened in 1997. 2) The entire chain was purchased by Dick’s Sporting Goods in 2006, but the administrative functions remained in Eden Prairie, MN. 3) In 2008 the offices in Minnesota were closed, and all the administrative functions—including the scheduling, purchasing, and financial aspects of advertising—were assumed by the employees in Coraopolis, PA.

TSI was asked by our contacts at Dick’s to create an environment on the AdDept installation¹ that had been installed for a few years at Dick’s headquarters.

It appears that I made at least two trips to Dick’s headquarters. The first was in August of 2008; the second was a three-day trip in November. I assume that I gathered the specs for the project on the first trip and implemented the second installation of the AdDept programs and files in in the test environment (Aeolus) in November.

Unfortunately the two sets of notes that I found are the same. I must have opened the file containing the first set of notes (in order to replicate the format), made all the changes to reflect what happened in November, and then mistakenly saved them under the old name. So, I will need to deduce what I learned at the first meeting.

Two instances of AdDept required three data libraries:one for tables that were needed by employees whether they were working on either Dick’s or Golf Galaxy, one for files that were strictly for Dick’s, and a library that was only for Golf Galaxy. The first thing that needed to be determined was which tables needed to be in the common library. For example, if the same calendar was used by both Dick’s and Golf Galaxy the season² table should reside in the common library. If the same vendors were used, only one vendor table must be moved to the common library. A decision needed to be made for each table.

When that determination had been made, library lists had to be constructed for the two installations. The common library needed to be on the list for each store. The data library for Dick’s was already called TSIDATA. The common library was named TSIDATACOM. The library for Golf Galaxy was TSIDATAG.

If the two stores had been completely independent, it might have been feasible for them to be on separate partitions or separate machines. This was not the case. So, both Aeolus (the testing system) and Boreas (the production system) needed to contain all three libraries.

Before I did anything I needed assurance on the first day that my work would not accidentally get wiped out overnight by the automatic “refresh” that deleted program and data libraries on Aeolus and replaced them with copies of their counterparts on Boreas.

I asked Bob Pecina to make certain that the automatic refresh was turned off this week. He said that that had been taken care of, and if it was not, he would kill someone.

The next step was to create the new libraries in Aeolus and to move the tables that were needed for working on both stores to TSIDATACOM. Duplicates of all of the other tables and data files needed to be created in TSIDATAG.

The tool that is used for most of the programming tasks on the AS/400 was called the Program Development Manager or PDM. I needed to change several things that could only be done there.

I created a shortcut in the PDM named L9 to run CRTLFS on a physical file. I edited my library list to replace TSIDATA with TSIDATAG. I then used L9 to create logical files for all the files in TSIDATACOM and TSIDATAG.

I created a shortcut in the PDM named PA to grant *ALL object authority to *PUBLIC for all objects in TSIDATACOM and TSIDATAG.

I created a command named CHGTSIFT4L and changed the CH shortcut to use it. The old CH is now C7. I tested it on DIITEM (individual) and DADEPT (TSIDATACOM). Both seemed to work.

The PDM allowed selection of a large number of objects (programs, files, libraries, etc.) of the same type. Two-character shortcuts could be created to run a command on one of the objects. A function key in the PDM allowed the shortcut to be copied to all of the selected objects in a trice. So the new L9 command described above was used to create logical files (now commonly called “views”) for all of the physical files in the two new libraries. I only pressed Enter once. The shortcut PA was then used in the same way to allow all of the selected files to be used by anyone. The shortcut CH was used to make all the changes necessary when the description of a file had been changed, usually to add new fields.

A few programs (and all of the menus) needed to know whether the user was working on Dick’s or Golf Galaxy. I created a file in TSIDATAG that contained only one blank character and named it GOLFG. The programs and menus could determine in an instant whether this file existed in the library list. The screens would then know which name to display, and programs could determine which set of rules applied.

I expected that there might be a problem in calculating rates. My notes reported that “If they run the exact same size code on the same day on inserts in both TSIDATA and TSIDATAG, the quantities should be added together to get the CPM.” CPM stands for cost per thousand, which is the way rates were expressed for newspapers. So, every time that an insert was added, deleted, or changed in one library, the rate calculation had to check the other library to see if they were running an insert with the same size code there. The combined rate had to be used in both instances, and change records needed to be created in both libraries.

The AS/400 had a very handy object type called a data queue, which was indispensable to the functioning of A^xN. The Golf Galaxy environment needed access to it, but it was not possible to copy or move a data queue. However, it was possible to save the data queue into a “save file” and then restore the save file in TSIDATACOM. I did that for the data queue used by A^xN and then deleted the one in Dick’s library, TSIDATA.

Some other complicated changes were necessary to allow both Golf Galaxy and Dick’s to send insertion orders. In addition to the data queue described above the notes mentioned the following:

I changed the User field on the AXNFTP job description, which is now in TSIDATACOM, to TSIDICKS. This should be set to ADGRP before the final cutover.

I had to change the AXNFTP job description so that all of the items point to TSIDATACOM. The library list must be initialized with ADDEPT, TSIDATACOM, and TSIDATA (for DASPECS) in that order. We planned to move the fields needed from ASPECS to another specs file, but this has not been done yet. It gets the advertiser code from the item in the data queue.

I was eventually able to fax test insertion orders to TSI and to send them via A^xN without any difficulty.

I don’t have any record of subsequent trips. In fact, I spent much of the third day on the November trip addressing issues in the Dick’s environment.

Evidently we were able to implement the “cutover” remotely. I don’t recall much about the event. The split environment setup worked well for at least five or six years.

---

1. The details of the first AdDept installation at Dick’s headquarters is chronicled here.

2. Many retailers divided their calendar into two seasons called spring and fall. The spring season began in February; the fall season began in August. Dick’s and Golf Galaxy did not do this. They both used a standard calendar, and their common “season” table reflected this.