The 5110 and 5120 were essentially the same computer. The 5120, which was introduced in 1980, provided a larger display area. It also eliminated the quarter-inch tape device and added a second 8″ diskette drive. Both of these changes were important. The 5110’s display was so small that some people could not use it. Designing a system that could work with only one diskette drive was extremely difficult. If the software required more than one drive, the 5110 customer needed to purchase a stand-alone unit that could house two diskette drives. It was the size of a two-drawer file cabinet.

Both systems came with random-access memory (RAM) ranging from 16K to 48K. It had two different operating systems. One used APL and one used BASIC. A switch on the front of the console controlled which one was active. Practically all of the customers used BASIC.

IBM marketed at least one application for the system, a construction payroll system. Most of TSI’s customers had licensed that system.

Strengths: The hardware was reliable and durable. IBM supported the hardware with a maintenance agreement. If the software was licensed from IBM, telephone support was also available. In that era this was an enormous advantage. IBM’s systems engineer (hardware support guy) once spent an entire day working on TSI’s 5120 He finally got it to function correctly. If he had not been able to get it to work right, we would have expected a new unit the next day. Systems from other vendors did not offer anything comparable. 5110/5120 customers expected the system to work every day.

Data files were stored in EBCDIC format and were read by programs using IBM’s Indexed Sequential Access Method (ISAM). If the keys to the files were sorted, access to the individual records was relatively fast. Of course, it was important to keep the keys sorted. The standard practice was to sort the keys at the end of any program that added new records. The operators knew to do something else during this process until the beep sounded that meant if was finished (or something had gone wrong).

BASIC was easy to learn, and everything was well documented.

Limitations: Although the system had a fairly fast 16-bit PALM processor, the paucity of the memory made the applications excruciatingly slow.

Only one model of dot matrix printer was available. Its interface was, like all IBM interfaces of this period, not standard. So, it was difficult and expensive for third-party manufacturers to provide an alternative.

There was no hard drive available except the one offered by a third-party vendor named CORE. By the time that this product was released, the 5110/5120 was nearing obsolescence.

It was possible to connect two computers to the external floppy disk unit, but it was difficult to write software that would overcome the inherent disadvantages of two users fighting for the same diskette drives.

The 5120 console weighed ninety-nine pounds!

The only interfaces were for the printer and the external diskette unit. It was not possible to connect it to phone lines or anything else to the system. If a bug was found in a program at a remote location, the developers had to talk the users through the process of changing the code. This was, of course, both dangerous and frustrating.

If more than a few lines of code was added or changed, someone often needed to visit the customer to install the changes. The alternative was to use an overnight delivery service to send a new diskette.

The BASIC interpreter used line numbers, not statement labels. The highest line number available was 9999. TSI circumvented the lack of statement labels by always using the same sets of line numbers for standard routines. The end of program routine always started at line 6000. The page heading subroutine always started at 9000. Individual lines on reports always started at at 9200. Date functions always used the same numbers.

BASIC had some limitations. One program could “chain” another, but it was not possible to have two programs in the RAM at the same time.

It was easy to write a BASIC program with an infinite loop. Here is one:
10 GOTO 20
20 GOTO 10

Discipline was therefore required. Some programmers avoided the GOTO statement altogether, but we found it useful in specific instances.

The most annoying problem with BASIC was that the variable names were restricted to one letter followed by nothing or a single digit. Thus, the employee number field could be called E in a program or E4, but it could not be called EENUM. This restriction made it absolutely necessary to maintain a list—either in comments in the program or on a separate sheet of paper—as to what every variable stood for in every program. It was also difficult, if not impossible, to keep the variable names consistent among all programs.

I just assumed that the absurdly short variable names were an inherent limitation of the BASIC language, and so I learned to live with it. Fortunately, I only developed one fairly elaborate system on the 5120, and so this did not cause any great problems for me. Sue maintained the systems that were written by IBM or AIS. I don’t know how much it bothered her.

This problem was corrected in subsequent hardware systems, and I had almost forgotten about it when I wrote this.

The 5110/5120 was designed for accounting and other administrative applications. It had absolutely no capacity for graphics. Furthermore, spreadsheets had not yet been invented. What do you want for $18,000?

I seem to recall that a utilities diskette included a game that involved shooting down enemy spacecraft. There definitely was a pseudo-random number generator. There was also a program for printing biorhythm charts.

Unique feature: When a BASIC program was running, the line number that was being executed was displayed in the lower right corner of the display. This provided a little entertainment for the operator when a lengthy process (such as updating a large batch of transactions) was being performed.