Monthly Archives: May 2021

1988-2014 TSI: The IBM AS/400 and its Follow-ons

Posted on by
6

An amazing system. Continue reading →

In the eighties IBM sold two mini-computers1, the System/36 and the System/38. It was hard to understand why. They both supported the same programming languages (RPG, COBOL, and BASIC), cabling, and peripherals. They both were aimed at small businesses that used them for traditional “business” applications—as opposed to graphics or calculation-intensive jobs. There was a large overlap in the targeted customers for each system. Both systems were even designed at the same IBM facility in Rochester, MN.

For several months rumors abounded in the trade magazines for these products that IBM would soon announce a new computer to replace both of them. The code name was Silverlake.

The announcement was made on June 21, 1988. I attended a briefing at the IBM office in Hartford. The name of the new system was AS/400. The “A” stood for “application” because every program ever written for either the S/36 or the S/38 would run on the new system. Neither the S/36 nor the S/38 could be upgraded to an AS/400, but the new system accepted all of the software and most of the peripherals. The thrust of the pitch was that IBM was providing the “best of both worlds.”

A System/38.

This claim was possible because the “native” environment of the new operating system was based on the System/38. The new system also supported a “System/36 environment” that allowed programs written for that system to run with no changes. Since the native environment was much more efficient than the S/36 environment, software developers were expected to migrate their code to the native environment as soon as they could.

My immediate interest was in the price of the low-end systems. I was bitterly disappointed. The least expensive model, the B10, cost much more than the 5363, which was a perfect fit for most of our target market. Once again, IBM just refused to address the millions of small businesses that could be served very well by an economical system that could handle a handful of simultaneous users. In 1987 IBM had finally introduced such a system. With this announcement just one year later a perfectly good solution was replaced by a much more expensive and unproven one.

So, from the perspective of selling to local advertising agencies and other small businesses, the announcement was a nightmare. However, as is described here, Macy’s gave TSI no choice but to embrace the AS/400. They wanted to hire us to develop a system for them, but they had no interest in purchasing obsolete hardware.

IBM’s approach eventually worked out in our favor. The AS/400 had many outstanding features that were not available on the System/36.

The B10 was the size of a two-drawer file cabinet. The B60 required four racks. All were announced in 1988.
  • The new system’s operating system was built over a relational database. I am not sure that most people in the S/36 community knew this at the time because IBM did not even mention it at the announcement meeting, and the database was not even given a name (DB2/400) until much later. All anyone knew was that it sure had fast file access.
  • The defining feature of the operating system was inherited from the System/38: Single-Level Store. I never have understood this completely, but the effect was that the main processor did not care whether programs or “pages” of data were already in memory. The task of managing storage was managed by other processors. So, the problem that occurred on the System/36 when too many jobs were running simultaneously would not occur on the AS/400. Moreover, the compiler on the AS/400 took advantage of this setup to make the programs run much more efficiently under normal conditions as well.
  • For our purposes the big advantage of the AS/400 was that BASIC programs on the AS/400 were compiled, not interpreted. This meant that we could externalize routines that were performed by many programs, and one program could call several other programs that could run simultaneously as “batch” jobs without tying up any terminals. These were huge advantages.
  • The BASIC interpreter that was invaluable for debugging was NOT eliminated.
  • The AS/400 operating system was designed to be able to take advantage of future hardware advances. Because potential customers were more concerned about solving their immediate problems, this was not a great selling feature. However, it was definitely a great “keeping” feature. Ever program that we wrote in 1988 still works on hardware marketed by IBM thirty-one years later!
  • The first announcement did not require this, but eventually every AS/400 came with a 1/4” cartridge tape drive. This eliminated the nightmare of having to convert repeatedly from one storage means to another.
  • Priority could easily be assigned to certain jobs.
  • A modem could be attached for faxing. Our AdDept customers used these for insertion orders until we devised a better way of handling them.
  • The system could be attached to an Ethernet or Token Ring network.
  • IBM’s query tool was a big improvement. We insisted that all of our clients licensed it, and I personally trained at least one employee in its use. That worked fine unless the person who had been trained left the company or was reassigned. We also offered support for designing and helping with queries, but we charged a monthly fee for this service.
  • Printing was much more flexible. Even laser printers attached to PC’s could be used for printing reports. I learned PCL, Hewlett-Packard’s printer language, so that I could design customized reports with fonts and simple graphics (borders and the like could be generated on HP printers. This was very popular with our customers.

Although some things continued to frustrate me about the AS/400, I grew to appreciate it more and more. It was not designed for tiny developers like TSI, but it allowed us to produce software with features that went way beyond the capacity of any model of the System/36. By the time that the E models of the AS/400 were released in 1992, the low-end systems represented very good investments for the companies who were interested in TSI’s products and services.

On the other hand, IBM’s approach meant that independent developers who marketed to the end users directly rather than to IT departments—and there were a lot of us—had to devised a way to survive until IBM provided us with a reasonably priced product. Those four years were very difficult for TSI. The company survived, but the grim reaper’s shadow was on our door quite a few times.

TSI’s B10 had a diskette drive and a QIC tape drive.

Over the course of twenty-six years, TSI had at least four AS/400’s (or follow-ons. named iSeries or System i) All of them worked spectacularly well. We hardly ever called IBM for either hardware of software support. We purchased or leased all of them at big discounts because we were developers. On the first one, a B10, I prudently scraped together enough cash2 to order the maximum amount of memory and disk. It was adequate for development purposes, but if one of our clients had tried to run its business on it, it would have been embarrassing. For one thing the operating system itself required almost half of the unit’s disk space! Subsequent releases of the OS required much more disk.

Still, we lived with it, and we came through on the other end.

How well did the strategy work for IBM? In 1988 IBM was one of many competitors in the mini-computer market. The others were DEC, Hewlett-Packard, Data General, Wang, and a host of other companies. By the mid-nineties all of the competitors had conceded the entire market for reasonably priced multi-user computers to IBM. All of them except HP went out of business, and even HP (after several mergers) now makes and sells only PC’s and printers. This stunning event went almost unnoticed by most so-called experts. They blamed poor management by these companies for their demise. Were they all stupid? No, the AS/400’s were demonstrably superior.

Lou Gerstner.

The mini-computer market still exists, but almost no one talks about it, because IBM has hidden its premier product inside hardware with other brands. The only thing that IBM left for the AS/400’s legions of devotees to cling to was the letter i. When Lou Gerstner took over the reins of IBM in 1993, he put a heavy emphasis on services, which were very profitable, over hardware and software, which evidently were not. So, Gerstner never liked the AS/400 approach because the IT departments that used it had little demand for IBM services. For example, at some point in the twenty-first century I visited Macy’s IT department in a suburb of Atlanta. Dozens of IBM employees went to work there every day. One extremely large office contained desks for them and no one else. Macy’s had several AS/400’s or i series systems there. One person managed them all, and he worked for Macy’s, not IBM.

Users of TSI’s software systems loved their AS/400 computers, and they never purchased any services from IBM beyond maintenance contracts.

The AS/400’s operating system (OS/400) employed strict typing of objects. Every object had one and only one type, and it was unchangeable. On a PC a developer—or even an end user—can change the type (as designated by the three-digit “extension” after the period). For example a text file named sample.txt can easily be changed to a comma-separated-values file sample.csv. Users could even make up their own extensions.The operating system might warn the person that changing the extension might make the file unusable by certain applications, but it would still allow it.

The AS/400’s native environment, in contrast, had a limited number of well-defined object types, many of which had equally rigorous subtypes:

  • Database files could be physical or logical. A logical file is equivalent to what is called a “view” in SQL.
  • Programs had subtypes for each supported language. A new language called CL3 was added.
  • Menus were lists of options displayed on the screen, usually with a command line at the bottom. Each option had a number.
  • Commands were routines that could be invoked on any command line. A command was essentially a shortcut for calling a CL program.
    • The names of the commands supplied by the operating system. were consistent throughout: VVVAAANNN, where VVV was a three-character abbreviation of a verb, AAA was an optional three-character abbreviation of an adjective, and NNN was a three-character noun. For example, DSPSYSVAL was the command for Display (DSP) System (SYS) Value (VAL).
    • Most commands had parameters. For example, the GO command required the name of a menu object as a parameter. GO BACKUP caused the system to display and execute the menu object named BACKUP. Pressing F4 after keying in the command displayed a data entry screen for all of the parameters.
    • TSI created a large number of commands in
  • Several other object types, such as line descriptions and spool queues, were used by the system software. Most system objects of all types (except commands) began with the letter Q.
  • BLOBs were objects that did not fit any of the other types. They included all types of images, video, sound, etc. They were added in later releases.

Users could not create new object types or subtypes, but new ones often appeared in new releases of the operating system.

Every object had a name, which was limited to only ten characters. A letter was required for the first character. The other characters could be letters or numbers. A few special characters were also allowed. The names were NOT case-sensitive.

Every object resided in a library, which was itself and object with a ten-character name. This was a departure from the S/36, where data files were not assigned to libraries. On the AS/400 two objects in the same library could not have the same name.

On the S/36 and for a short time in the S/36 environment on the AS/400 TSI used periods in the names files that were associated. For example, files that began with “M.” in the GrandAd system were media files. In the native environment of the AS/400 such files caused a problem for some third-party programs that users might wish to employ to create customized reports. So, TSI changed the names so that the first one or two characters served to group files.

Third-party programs and programs written in other languages also had difficulty with integers that were left-padded with blanks4, as BASIC programs have always done. TSI changed all of its programs to pad integers with zeroes instead of blanks. So, when the value of a three-digit number was 15, it was written on the AS/400 database as 015, not (blank)15.

1. The terms mini-computer and midrange computer referred to multi-user systems that were not powerful enough to run the business applications of major corporations. The System/36 and System/38 were certainly mini-computers. At its introduction so was the AS/400. The twenty-first century models, however, were more powerful than the mainframes of the eighties.

2. I suspect that TSI actually leased it.

3. CL stood for Control Language. CL was the easiest language ever. It was simply a list of commands to be executed in order. Since CL programs were compiled, they could be called from other programs written in any language.

4. I considered this an intolerable bug in the software developed and marketed by the other company. I encouraged the person trying to use the software to complain to whomever claimed that the product would work on AS/400 files. Eventually, we changed our files and programs to forestall a brouhaha.

1985-1988 TSI: GrandAd: The System/36 Conversion

Posted on by
1

TSI’s first big conversion. Continue reading →

A fairly detailed description of the design of the GrandAd System can be found here. More information about IBM’s System/36 (S/36) is posted here.

The purchase of the GrandAd software system in early 1985 by Keiler Advertising (KA) was definitely a milestone for TSI. The agency was one of the two largest in the Hartford area, and its founder and president, Dick Keiler1, was highly respected in the local advertising community.

Although I had recommended to Sandy Procko3, KA’s finance manager and our liaison on the installation, that they buy two Datamasters and a hard drive, IBM had talked her into ordering the recently announced S/36 model 5362. They made the right decision.2 The Datamaster was on its way out, and the S/36 gave them better peripherals and room for growth. It also had many more subtle advantages.

Her decision was a great break for us. We would have needed to convert the system anyway. The sooner that we got started on it the better.

The only problem was that no one at TSI had ever worked on a System/36. We knew that the system had a BASIC interpreter, but we were uncertain about the compatibility of the two versions. IBM provided KA with a huge stack of documentation. I read the BASIC manual thoroughly and was relieved to find that it was very similar to what we were accustomed to. I read enough of the other manuals to get an idea about how to set up their system.

I also had to write the file definitions for each file. We had versions of these created in the Datamaster’s word processing program, but on the S/36 it was important that they be stored as Data Definition Specifications (DDS). The final preliminary step was to write a procedure for creating all of the empty data files from the DDS.

IBM’s office had a 5360, the “washer-dryer” model.

IBM allowed us to work on the S/36 in its downtown Hartford office before KA’s system was delivered. I saved our programs onto 8″ disks. I created a library for them on IBM’s 5360. Then I restored them as text files. I edited them to conform with the S/36 syntax and changed the names of all of the files to use the dot format that SSP required. I then tried to load them in the interpreter. If any lines were rejected, I fixed them and kept trying until the program loaded. Then I went on to the next program, of which there were several hundred.

When I was done with the programs and procedures, I saved the library onto diskettes, brought the diskettes to KA, and restored them. Then I executed the procedures to create all of the files. It never occurred to us that there might some day be a way of populating the data files from files that they had stored on their PC’s. I think that it was possible to save the specs table, which was a fixed-record-length file.

For nearly all of its forty-two years of its existence KA was located in a large house in Farmington, CT. It is portrayed in the photo at the right. During the period in which I was regularly vising the agency, the trees and the bushes were much smaller, and they were surrounded by wood chips. Sandy called Dick “the mulch king” of Farmington.

From the beginning, or shortly thereafter, Sandy was assisted by a younger woman named Shelly. I don’t remember her last name

Getting the code to work on the S/36 caused us fewer problems than one might imagine. By this time we understood how IBM thought about things. The fact that all of our programs followed strict procedures also made it easier to adjust to the differences. I don’t remember encountering any problems that necessitated consulting IBM or anyone else.

Here are my most vivid recollections of the installation.

KA’s 5224 printer was much faster than anything available on a Datamaster.
  • KA not only had a kitchen. It had a chef who prepared meals for clients and prospects and a dining room as well. I was never invited to one of these occasions.
  • The parking lot at KA, which was in the back of the house, had a few narrow grass covered areas with skinny trees in them. I parked my Celica to the left of one of them once. When I exited I turned the wheel too soon. The mirror on the right side of the car got caught on the tree and broke off. Thenceforward there was no mirror on the Celica’s right side. Changing lanes to the right required extreme caution.
  • The first few monthly closings at KA were, as always, difficult. Query/36 sometimes helped the reconciliation process. Nevertheless, on one occasion we had a discrepancy of ten cents in the accounts payable account. Sandy told me not to worry about it, but we had the tools to find it, and so I persisted. I eventually discovered that no vendor was off by a dime. Instead, three invoices were off; all three had discrepancies of more than $100, but they almost perfectly balanced one another.
  • Sandy taught me that if a discrepancy was divisible by nine, it was probably a transposition error.
  • On one occasion guys from the Australian national swimming team were in the office for some reason. Sandy and most of the other female staff members thought that they were very hot.
  • Sandy liked the system’s reports a lot. I am pretty sure that she asked for a couple of revisions, but I do not remember the details. I do remember that, despite the fact that we spent a lot of time making sure that the results of the cost accounting system agreed with the cost accounting system, she never showed any client profitability reports to Dick. She said that that would open a can of worms.
  • I went to KA once during the period in which I was weak from cat scratch fever (as described here). It happened to be on the day that KA was moving its accounting department from the ground floor to the second floor. I carried a printer or something, but the effort totally exhausted me.
  • At some point in 1988, I think, Sandy fell out of Dick’s favor. She was reassigned to take charge of the scheduling of production jobs, a clear demotion. I never learned why all of this happened.
  • Dick hired a woman with experience from a New York agency to replace Sandy. I tried to explain to her why the system’s method of calculating work in process (WIP) was superior to the method advocated by the AAAA, but I don’t think that she bought it.
  • The last time that I went to KA Shelly was in charge of the finance department, and the New Yorker was gone. On that occasion Michael Symolon, our salesman at the time, accompanied me. Evidently he had gone on a date with Shelly once and was embarrassed about it. He stayed in the background. That was the only time that I ever remember him being shy.

When the system had been working successfully for a few months, Dick Keiler arranged to be interviewed by AdWeek New England about our system. It was a very nice article that heaped praise upon our system. It started on the front page, and it continued for several paragraphs in the middle. I had only one minor quibble: THEY NEVER MENTIONED THE NAME OF THE SOFTWARE OR THE COMPANY THAT DEVELOPED IT!!!

TSI had, for the first and only time in its existence purchased an ad. It appeared somewhat close to the article’s continuation page. However the ad was not precisely the same size as the hole that the magazine needed to fill. The way that they floated it in made it look really unprofessional.

I was quite upset about this. I wrote a letter to the editor complaining about both of these things. He called me. He did not apologize. He said that he did not think that it would have been proper to identify TSI. I reminded him that the article clearly identified the hardware vendor as IBM. What was the difference? He repeated that it just did not seem proper. He also thought that our ad looked fine. I hung up on him.

I made lemonade out of this by writing to all the prospects in the northeast about the article, providing “what AdWeek neglected to mention.” It generated a few inquiries.

1. Dick Keiler founded the agency in 1972. He started his retirement process in 1999 and left the company five years later. In 2021 he lives in Tucson Arizona. The agency went out of business in 2015. The last few years are described here.

2. I am pretty sure that in 2021 Sandy Procko resides in Westbrook, CT.

3. I was slow to come to the realization that when trying to sell systems that generated no revenue for the purchaser, it was best to strike when the iron was hot. One of our clients later told me “Christmas only comes once.” The person recommending the purchase always dreaded making a mistake. He/she most feared the prospect of telling the boss a little later that the company needed to purchase more hardware. I always thought that IBM proposed systems that were bigger and more experience than necessary, but they were more experienced at this process than I was.

4. The S/36 operating system, called SSP, used the term “procedure” for a list of commands that were to be executed sequentially. In addition, BASIC used the same term for a sequential list of BASIC commands that could be executed inside the interpreter. On the Datamaster the user was always in the interpreter, and so there was no confusion.

1983-1988 The IBM System/36

Posted on by
2

A true multi-user system. Continue reading →

A 5360. The box on the top left is the diskette magazine drive.

IBM’s introduction of the System/36 (S/36) in May of 1983 was not a monumental event for TSI. From our perspective the new system seemed more like a marginal upgrade of the System/34, which had always been much too pricey for anyone who would talk to us. The new system had only one basic model, the 5360. The starting price for one of these was still $140,000. It was also gigantic and had special electrical requirements. It was clearly designed for a small data processing department, not a small business without one.

The biggest advantage of the System/36 over any system that we had worked with was that it supported a fairly large number of terminals and printers. This was because it could run a number of jobs at the same time. It also supported batch processing, which meant that time-consuming jobs need not tie up any workstations.

We appreciated these benefits. In fact, we drooled over them. However, no prospective customer of ours ever had a six-figure budget for hardware.

The 5250 screen showed one color, green.

The peripherals were also rather expensive. IBM in those days ignored standards used in the rest of the industry. It set its own standards, and they were all proprietary. So, cheaper hardware from other vendors would not work with IBM systems.

Although the price went down through the years, a 5250 terminal cost around $2,000 when the 5360 was introduced. The cheapest printers, which used dot-matrix technology, were in the $5,000 range.

Both ends of twinax cables were male. A device with two female ends was needed to connect two together

The cabling was also not cheap. The system used twinaxial cables for direct attachment of these devices. Most competing systems used serial or parallel connections. Twinax was decidedly better, but it was also more expensive.

The local devices were connected in a serial fashion to a controller. Up to seven devices could be connected on one twinax line. Each device had two female twinax connections on the back, either in one T-shaped unit or with two short cables. One was called the “gozinda”; the other was the “gozouta”.

The T-shaped connector.

So, if the S/36 had four devices named A, B, C, and D. A would be connected to the controller by a twinax cable, B would be attached to A by a twinax cable, C would be attached to B, and D would be attached to C.

A switch on device A, B, and C needed to be set to allow pass-through to the next device on the line. On device D that switch needed to be set to denote that it was the last device on the line.

For device D to communicate with the S/36, all of the connections must be functional, and all of the switches set correctly. It reminded me of Christmas tree lights in the old days.

The S/36 also came with a serial port. Since a modem could be attached to this device, it would be possible for support people at IBM or the software vendor (or anyone else, for that matter) to sign on from a remote location. This was, of course, our dream; it would make support so much easier. The announcement brought it a little closer to reality.

The 8809 tape drive.

The hard drive capacity varied from 30 MB to 400 MB. In the twenty-first century, of course, those quantities would only hold a handful of photos. However, to most software vendors in the eighties this meant that total storage was no longer a big concern. However, the default backup device was a magazine that held only ten 8″ diskettes. Each diskette had a capacity of only 1MB each. This was a rather obvious limitation on the practical storage.

It was possible to attach an 8809 1/2″ reel-to-reel tape unit to address this. I could not find a price for these monsters. It may well have been the case that if you had to ask the price, you could not afford it.

The System/36 had two processors. The main processor (MSP) executed the code; the control processor (CSP) managed the work for the main processor. The CSP was four times as fast as the MSP, and they worked perfectly in tandem. The S/36 could perform an amazing amount of work at very fast speeds with embarrassingly puny processors. It was also extremely reliable.

Some actions, such as IPL1 and backing up files, needed to be initiated from the system console. The system console on the 5360 was built in to the top of the box. Your system operator needed a wheelchair? Life was rough all over.

I missed out on this fun stuff.

The System/36 supported five programming languages: RPG II2, COBOL, FORTRAN, BASIC, and Assembler. RPG II, a simplistic column-based language, was the most popular. Wikipedia says that this was because it was the least expensive3. The BASIC language was similar to the one used on the Datamaster. I never heard of anyone who programmed in FORTRAN or Assembler on a S/36.

BASIC programs could not be compiled. Therefore, a copy of the BASIC interpreter needed to be loaded into memory for each program that was running. Nevertheless, because the CSP was so efficient, TSI’s benchmarks showed that there was no noticeable difference in the speed of interpreted BASIC programs and compiled RPG II programs performing the same tasks. So, we never considered converting our program to anything besides S/36 BASIC.

IBM also positioned the System/36 with its DisplayWrite/36 software as a word processing server. We found it to be inferior to the Datamaster product in most ways.

The file structure of the S/36 was somewhat different from the Datamaster’s. Programs and other executable items such as BASIC procedures and system procedures were stored in “libraries”. Libraries were somewhat like directories or folders on a PC. However, there was no such thing as a sub-library.

No directory trees on the S/36.

Data files needed to have unique names. They did not reside in libraries. In order to identify which files belonged to which application, the names were preceded by a short identifier and a period. In GrandAd all the media files started with “M.”, and the other files started with “T.”.

The S/36 did not have a relational database4. However, the fields in each file were defined in the system using field names, positions, and length/type designations. These data definition specifications were called DDS. Programs could access files using the same ISAM techniques with which we were already familiar. However, IBM also offered a product named Query/36 that allowed someone who know how the files were named and structured to write queries in a manner that was similar to SQL. These queries could then be saved and executed on demand.

Query/36 was a valuable debugging tool. TSI required all of our clients to buy it.

IBM announced the 5362 in 1984. It was much smaller than the 5360—only about as large as a two-drawer file cabinets. It also had no special electricity requirements. It used the same operating system as the 5360, which was called SSP. It came with one diskette drive and up to 120MB of hard drives. A QIC (1/4″ cartridge) external tape drive was available. A 5250-type terminal plugged into the first twinax spot served as the system console. Fewer devices could be attached, but none of our clients ever reached the limit. Best of all, the starting price was only $20,000, about the same as two Datamasters and a hard drive.

Many advertising agencies in the northeast could afford this level of investment. It took some time for TSI to convert the ad agency programs. I remember spending many days at IBM’s office in Hartford working on this. After tat we needed to change the focus of our marketing efforts to larger ad agencies. At this point IBM had no system to offer to the many whose needs would be satisfied with one Datamaster with diskette drives.

We were happy with this announcement, but it was a disappointment that IBM had totally abandoned the market that had produced the majority of TSI’s sales.

The 5364 (or System/36 PC), which was announced in June of 1985, was IBM’s belated attempt to recapture that market. The starting price of $5,995 was quite attractive. For some reason the system console had to be an IBM PC, XT, or AT with a special card inside. The S/36 part was the same size and shape as an AT. It contained a 5 1/4″ diskette drive that was compatible with neither the attached PC nor any previous model of the S/36. Compatibility was not a high priority for IBM.

This is what the system console looked like with the PC on top of the 5364. Manute Bol found it very convenient.

This bizarre arrangement was very difficult to explain to a prospect. Why would a super-reliable S/36 be coupled to the least reliable hardware ever to wear the IBM logo? It did guarantee that at least one IBM PC was installed at each location, I guess. However, most installations probably did what we did—attach the oldest, slowest machine available as the system console, and then use it only when necessary.

The 5364 had two severe limitations. In the first place, only four devices (counting the system console and the printer) could be attached. So, the S/36 customer could really only attach two more displays or one display and a printer. Still, that would suffice at most small ad agencies and at TSI. We immediately ordered one.

The other limitation was, in some ways, worse. The 5364 came with only 256K of RAM. Each session could use up to 64K. However, batch jobs counted as sessions. If one person started some lengthy reports or other process, the system could possibly reach the point where jobs needed to be swapped between memory and disk. This could severely impair the system’s performance.

The announcement of the 5364 created a good deal of business for a company named Black Box. They sold a box with slots for one 8″ and one 5 1/4″ diskette and software to make image copies from one to another. We bought one, and I used it a lot.

This is a 5363 with both a diskette drive and a QIC tape drive.

In 1987 IBM finally fixed all of the problems, at least the ones that most concerned us. The 5363 was a reasonably priced machine that was suitable for almost any small business. If it had been announced two years earlier instead of the 5364, we could have sold a lot of them.

I could not find anything either on the Internet or in our basement that listed the price of one. I don’t remember that anyone balked at the cost. I also could not discover how much memory it had, but I remember distinctly that it was plenty. It could handle at least seven devices, too, and you could get one with a built-in QIC tape drive.

We enthusiastically ordered one for TSI’s office and tried to get our Datamaster customers excited about it.

By the middle of the eighties most office workers had some kind of personal computer on their desks. They did not want someone to install a terminal next to it as well. But how could they gain access to the S/36 without a terminal? There were no networks worth mentioning in the eighties, and there was nothing like USB. The only way to reach the server was through a twinax line, and IBM did not share its knowledge of how the display and printer connections worked. IBM considered anything that it produced was proprietary.

IBM and many third party companies brought 5250 terminal-emulation packages to market. The idea was to be able transform the PC into a terminal on demand and then change it back. Although the other vendors had to reverse-engineer the 5250 interface, they still were able to produce competitive products that were cheaper and had more features than what IBM offered. They generally consisted of a three pieces:

  1. A hardware card that fit into an expansion slot on the motherboard of the PC. That’s right. You had to take the cover off of the machine and add a card that had the brains needed to make the PC act like a 5250 card. You might also need to physically flip switches on the care to configure it. Then you had put the PC back together again. What could possibly go wrong?
  2. A dongle (sometimes lovingly referred to as a “pigtail”) that screwed into the interface on the part of the card that stuck out the back of the PC. It provided a gozinda and a gozouta for the twinax cable(s).
  3. Software to run on the PC.

When they first appeared, the cost of these packages was well over $1,000, nearly as much or more than a PC or terminal. However, the emulators had one very substantial advantage. The inexpensive printer attached to the PC could also be configured as a S/36 printer. This not only saved money and office space; it was also much more convenient.

For a few years the companies selling these packages did a land-office business.

1. IPL stands for Initial Program Load. It just means the starting process for the system. IBM had three-letter abbreviations of everything, including a three-letter abbreviations (TLA).

2. RPG is short for Report Program Generator. I could never understand why anyone used it.

3. IBM required separate licenses for each programming language that was used.

4. Two IBMers, Donald D. Chamberlin and Raymond F. Boyce, codified the Structured Query Language (SQL) used in relational databases in the seventies. IBM rejected it because the Indexed-Sequential ISAM structure that it used in its computers had much better performance. About three decades later the company changed its mind.

1983-1985 TSI: GrandAd: The Datamaster Clients

Posted on by
2

A good fit for several agencies. Continue reading →

IBM’s Datamaster was widely disparaged in the technical press. PC’s and Macs were the rage. The reasons for this evaluation were persuasive, if a little superficial.

  • A Datamaster cost a lot more than a PC.
  • The Datamaster’s programs only ran on Datamasters. Many hardware vendors were offering PC’s that were “IBM compatible”.
  • The Datamaster could in no way run PC programs.
  • The Datamaster’s peripherals—displays, printers, keyboards, and hard drive—were very limited.
  • The Datamaster’s specs were inferior. The processor looked very slow.

Nevertheless, the Datamaster was a very good computer for TSI. It was extremely easy to program, and it was very good at the two tasks for which it was designed—data processing and word processing. It was also quite reliable. PC’s crashed all the time. Some of our clients used their Datamaster’s for years without ever making a service call to IBM. Those who did were uniformly satisfied with the attention that they received.

For the ad agency application there was one other overriding advantage. Up to four Datamasters could use the same hard drive. This allowed the media department and the accounting department to have access to the same data. In the early eighties personal computers were totally personal. Reliable networks were many years away.

Yes, the Datamaster was horrible at other tasks such as spreadsheet, and it had absolutely no capacity for graphics. However, most of the people who owned and ran small businesses in the early eighties were interested in addressing business problems. They did not care much about system specs, and the fact that IBM sold and supported the system was of paramount importance to them.

I am almost positive that our third ad agency client was Communication & Design (C&D)1 in Latham, NY, just north of Albany. The principals were Fran (a guy) and Theresa Lipari2. The agency purchased two Datamasters and a hard drive. I am pretty sure that by this time TSI was in IBM’s Business Partner program as a Value-added Remarketer (VAR), and C&D bought the hardware through us. We only needed to make minor adjustments to the software system that we installed at Potter Hazlehurst, Inc. (PHI).

It was a long drive, but unless there was snow on the highway, it was never stressful. Best of all, the sun was never in my eyes.

Nevertheless, I made the drive to Albany quite a few times. There was no avoiding personal involvement at several stages in these installations. The transition from manual ledgers to computerized accounting systems was never trivial. The first few monthly closing processes never went completely smoothly.

For several years I worked very closely with the woman most involved with C&D’s system. She was definitely the bookkeeper. She might have also been the office manager. I found her to be intelligent and very easy to work with. I am therefore embarrassed that I cannot remember her name. I recall clearly, however, that she was a big fan of the New York Giants football team. She had even bought vanity license plates for her car that said “NYGIANTS”.

When she left the agency, she was replaced by a woman who was as tall as I was. I don’t remember her name either, but I think that it was French, maybe Bissonet.

I also dealt with the media director when they implemented the media system. I don’t remember her name either, but she was, I am pretty sure, also a principal in the business. She explained to me about inserts3—the advertising pieces that were stuffed into the middle of a newspaper, usually on Sundays and Thursdays. From a database perspective they had pages like direct mail pieces but schedules (lists of newspapers and dates) like newspaper ads. Since we were already using the same set of files for direct mail and newspaper ads, it was not too difficult to set up ad types for inserts.

I remember meeting with Fran after the whole system had been in place for a while. He told me that the media director had started her own agency, and she had taken some of his best clients with her. I never encountered any business that was as “dog-eat-dog” as the ad agency business.

I generally drove up to C&D early in the morning and back at night. I sometimes stopped for supper at a restaurant in East Greenbush. I generally listened to WAMC, the powerful NPR station in Albany. Once I heard—for the first time—the entire recording of The Phantom of the Opera. On another occasion I listened to Lt. Col. Oliver North defending his actions in the Iran-Contra hearing.

A couple of times I stayed overnight. A Howard Johnson’s hotel was right across the street.

Perhaps our easiest installation ever was at The Edward Owen Co. in Canton, CT. The owner was Ken Owen, who was a few years younger than I was. We had (and still have) similar interests. He majored in the classics at Harvard, which prepared him well both to teach Latin and/or Greek somewhere or to take over the family business after he graduated. He chose the road more taken.

The company was named after Ken’s grandfather, who had built the business up to be one of the most successful in the Hartford area. Ken’s father had apparently undone most of that. When we worked with the company Ken had only a part-time assistant and a resident artist who was not on the payroll. His father, who taught Latin at Avon Old Farms school, stopped by occasionally.

It was an easy installation because Ken was the ideal client. He understood and could explain exactly what he wanted. Furthermore, no one else had their fingers in the pie.

Ken and I initiated a lifelong habit of greeting each other on Exelauno Day4 (March 4). Sue and I also went to visit him, his wife Patti, and their two sons a few times. He drove to our house for one of our Murder Mystery parties, too.

This requirement alone would leave me out.

Ken was a serious runner. The advertising agencies in New England sponsored a mile run for CEO’s every year. He easily won whenever he entered. I often asked him for advice about running, although what I did he would probably call strolling. I was never close to being in his league.

I don’t remember the name of the artist who worked there, but I vividly recall the nice drawing that he executed for us. It showed three people in choir robes singing from three different hymnbooks labeled “accounting hymns”, “media hymns”, and “production hymns”.

We also asked Ken to help us with the one and only advertisement that we ran. It appeared in one issue of AdWeek New England. That experience is described here.

We created one new module for Yellow Pages advertising. The unique thing about Yellow Page advertising was that the agency only ordered it once. It then ran year after year until someone canceled or revised the ad. Ken’s father said that it was the best kind of advertising. All you had to do was open the envelope every year and endorse the check. Unfortunately, none of our other clients ever had a used for this module.

Ken’s business near Route 44 was next to a strip mall that contained a Marshall’s. We did not have stores like that east of the river. I often popped in there to see if they had anything cheap in my size.

Ken’s company is still in business. He moved the company to Sheffield, MA, which is south of Great Barrington. He also changed the focus of his efforts to, of all things, custom programming. The company’s web page is here.

As you can probably guess, Group 4 Design, which had offices on Route 10 in Avon, CT, was not a full-service advertising agency. They did not place any ads, and, in order to avoid charging sales tax, they were careful not to deliver anything tangible to their clients.

In other ways, however, they were like an ad agency. They billed the time spent by employees, and they could use the job costing and accounting functions designed for ad agencies. So, we treated them as an advertising agency without a media department, an approach that seemed to work well.

This was Group 4’s headquarters. Google says it was permanently closed, but Frank still lists himself as president..

I am not sure who the other three members of the “Group” were, but when we worked with them the firm was definitely run by Frank von Holhausen5. Once the system was up and running he seemed satisfied with it. The only thing that I can remember about him is that he was in a dispute with the state because his company had not been charging its clients tax on Group 4’s services. At the time the state had a tax on services6 and the only services exempted from the tax were legal and accounting. Frank complained, “They want to tax my brain!”

I worked almost exclusively with Joan Healey, the bookkeeper. She had difficulty with the first few monthly closings, but after she understood the process, Group 4 was a good reference account for TSI.

Adams, Rickard & Mason (ARM), an ad agency in Glastonbury, CT, used the GrandAd system until it merged with another agency in 1988. I never met any of the principals. In the negotiations and the initial installation we dealt with the head of finance for the agency. His name was Dave Garaventa7.

We met at the house in Rockville. Debbie Priola and Denise Bessette were in the office working. Sue and David and I sat around a table in the office. We were going over some reports that he wanted included in the system. Four of the five people in the room were smoking. After about an hour of this I felt horrible. I excused myself and walked outside to get some air.

At the time of the installation ARM was in the process of moving into offices that someone at the agency had designed specifically for them. Visually, they were quite striking. However, half of the building was on stilts. the area beneath it was used for parking, However, in the winter that half of the building was always cold because it was surrounded by cold air on all sides.

All of the employees were forced asked to take a pencil-and-paper multiple-choice test to determine whether they were “left-brained” or “right-brained”. The results were interpreted as a multi-colored strip that was displayed beneath names on offices and desks. I am not sure why the agency did this. I researched hemispheric specialization pretty thoroughly in college. This was bogus.

Our software maintenance contract with ARM was the same one that we had with every other client. We offered free telephone support during business hours, which were clearly explicated in the contract.

My fingertips were on the keyboard, not each other.

Weekends were sacred to me. I had virtually no time available during the week to program. I spent those days driving around to clients and prospects, training Denise, setting up her work, and writing proposals and documentation. On Saturdays and Sundays I worked on the custom programming that I had promised our clients from before dawn until I got very sleepy in the evening.

On one Sunday morning the phone rang. It was Dot Kurachik (or something like that), the bookkeeper at ARM. I worked with her for almost an hour and solved her problem. I sent her a bill for $75, our minimum charge at the time. She refused to pay. I talked with her boss, and he overruled her.

Cronin and Company of Glastonbury, CT, might be TSI’s only Datamaster client that is still functioning as an ad agency in 2021. Our primary contact was Mike Wheeler, who was, I think, the head of finance. He seemed very level-headed. We did only a little custom work for them.

Cronin did not have this door when I spent time there.

The main computer operator’s name was Jeannine Bradley8. After using the GrandAd system for several years, Cronin was persuaded to convert to a different software system. We did not get an opportunity to bid on this. We would have proposed a System/36 or an AS/400.

Jeannine called our office about something (I don’t remember what), and she confided to me that they now thought that they had made a mistake when they bought the new system.

I don’t recall any strange or funny stories about this account. The employees always seemed straightforward and competent to me.

The strangest of all of our installations was at Donahue, Inc., an ad agency in Hartford. We did not sell them a Datamaster. They somehow obtained one that had been purchased by Harland-Tine back in the early eighties. The installation at Donahue began in the first months of 1988. It was TSI’s last Datamaster installation.

You could say that Donahue Inc. was “old school”.

Donahue’s building did not look like it housed an ad agency or any other business. It looked like an old school, which is close to what it was originally used for. It was the custom-built home of the Cathedral Lyceum9. That designation was clearly etched above the front door.

I don’t remember ever talking to a principal there about what they hoped to accomplish with their system. Their goals, which were explained to me by a woman whom I hardly saw again, were relatively modest. They just wanted to automate their billing and accounting.

The only person whom I dealt with after that was the bookkeeper, a young inexperienced guy. He knew nothing about computers and very little about either bookkeeping or advertising. He and the Datamaster and the printer shared office space with the agency’s kitchen, which was on the ground floor of the building. The first few monthly closings were a nightmare.

Did I mention that there was no heat in the kitchen? The two of us sat there wearing overcoats and stocking caps. The person not operating the Datamaster wore gloves. People wandered in, got a cup of coffee, and quickly retreated to the area of the building that was heated.

The young man who did their books and operated their Datamaster confided to me that his goal in life was to become a real estate agent for Century 21. He really thought that their trademark blazers were cool.

Darby O’Brien.

Darby O’Brien Advertising (DOB), a full-service ad agency in downtown Springfield, MA, was not actually a Datamaster client, but I included them is this blog because they used the version of the software designed for the Datamaster. Darby10 insisted on using a Wang PC sold by one of his clients, a store that sold and repaired computers. We grumbled about this plan, but supporting their system this way turned out not to be too difficult for us.

A Wang PC.

They needed to purchase a license to use Work Station Basic11, a DOS-based product that supported all of the syntax used by the Datamaster’s version of BASIC. We also charged them for converting our code to a format that the Wang12 PC could use, but that took less than a day. In the end they probably paid more for a demonstrably inferior product. Unlike the Datamaster, a Wang PC could run other applications such as Lotus 123, but to my knowledge it was never used for that purpose.

When we installed the system, the accounting person was Caroline Harrington. For some reason Caroline resigned her position at DOB and came to work for us. Sue must have arranged this. I certainly did not recruit her.

In the eighties DOB’s offices were behind one of these two doors.

The agency’s building was in a rough part of town. It was less than a block away from the stripper bars. I was still relatively bullet-proof then, but I did not like to be there after dark. We did go there at night once, and we had a great time. The agency threw a party, and they invited all of their clients and vendors.

A very good live band played oldies from the fifties and sixties. The highlight of the evening was when they played the Isley Brothers’ hit, “Shout!” Everybody (except for me and my monkey) knew when to get down low, when to raise up, and when to shout. I hate rituals, but this one sort of made me wish that I had gone to at least one mixer.

The restrooms in the DOB offices were easy to find. The door to the men’s room was decorated with a three-foot high picture of Elvis Presley. The ladies’ room had a similarly sized portrait of Marilyn Monroe.

1. The ampersand was important. It was emphasized strongly in the agency’s logo.

2 .The Liparis’ last name was pronounced Lih PAIR ee, unlike the island just off the coast of Sicily, which is pronounced LEE pah ree with a trilled r. I am pretty sure that Fran and Theresa reside in Plymouth, MA, in 2021.

3. I later toyed with the idea of using inserts as the basis of a new business for TSI. Details are here.

4. Ken told me that “Exelauno!” is the Greek word for “March forth!” Google translate does not agree. I sold my ancient Greek dictionary at the end of my senior year. So, I can’t look it up. The origin of this custom is documented here.

5. Frank von Holhausen is now listed as the founder and Chief Design Officer at Forge Design & Engineering of Oxford, CT. His LinkedIn page is here.

6. Frank’s lament and the difficulty that TSI confronted in determining how much of what we did was service and how much was product acted as a key plot element in the short story that I wrote in 1988. The details are here.

7. Dave Garaventa died a year or so after we installed the system.

8. In 2021 Jeannine Bradley lives in Cromwell. She might still work at Cronin. She was promoted to accounting manager in 2012.

9. The Lyceum was built in 1895. You can read about it here.

10. Darby’s agency is still in business, but it has changed locations a few times. The latest headquarters is in South Hadley. He tells his own story here. I can’t believe he let them photograph him wearing a Yankees hat in Massachusetts.

11. Workstation Basic is described in some detail here.

12. Wang filed for bankruptcy protection in 1996.