>>> 2020-12-27 mainframe pos (PDF)

One of the most entertaining acronyms in the world of specialty computing equipment is POS. Let's all get the chuckle out of the way now, in this discussion we will be talking about Point of Sale.

For those not familiar with the term, POS refers to the equipment which is used "at the point of sale" in retail and other businesses to track sales, handle payment, and other business functions. In essence, a POS computer is a more entitled cash register, and there is a very direct line of evolution from the mechanical cash registers of days past (that made that pleasant cha-ching sound) to the multi-iPad abominations of today.

I would like to talk a bit about how we got from there to here, and, in my opinion, just how bad here is.

As with most things I discuss, IBM is an important component of POS history. However, I will start by introducing yet another three-letter acronym into the fray. We'll start with a company that is somewhat, but not radically, older than IBM, and was focused on POS while IBM was busy tabulating census cards: NCR.

NCR is one of those companies where the acronym officially no longer stands for anything, but before they tried to modernize their branding it stood for National Cash Register. As the name implies, NCR was an early giant in the world of POS, and many of the old-timey mechanical cash registers you might think of were actually manufactured by NCR or its predecessors, going back to the late 19th century.

NCR entered the computing business around the same time as IBM, but with a decidedly cash-register twist. Many of their computer products were systems intended for banks and other large cash-handling institutions that handled totally transactions, since computers of the day were largely too expensive to be placed in retail stores. They did, however, make general-purpose computers as well, mostly as a result of an acquisition of a computer builder.

NCR's early machines like the Post-Tronic are actually interesting in that they were basically overbuilt electromechanical calculators designed to allow a banker to post transactions to accounts very quickly, by keying in transactions and getting a report of the account's new state. This sped up the end-of-day process for banks appreciably. I like these kinds of machines since they take me back to my youthful education in double-entry accounting, but unfortunately it's not that easy to find detailed information about them since their lifespan was generally fairly short.

I hope to one day write about the posting machines used by hotels, electromechanical calculators that at the late stage read punched cards reflecting various charges to a person's account (room, restaurant, etc) and updated the room folio so that, when the customer checked out, a report of all of their charges was ready. This greatly accelerated the work of the hotel clerks and the night auditor who checked their work; in fact, it accelerated the work of the night auditor so much that I understand that in many hotels today the title "night auditor" is almost purely historic, and that staff member simply runs the front desk at night and has no particular accounting duties. The problem is that these wondrous hospitality calculators were niche and had a short lifespan so there's not really a lot out there about them.

Anyway, back to the point of this whole thing. NCR racked up a number of interesting achievements and firsts in computing, including being a key developer of OCR and barcode reading and inventing the ATM. More relevant to my point though, NCR was also an early innovator in electronic cash registers.

It is also difficult to find especially detailed information about the very early generation of electronic cash registers, but they were essentially the same as the late-model mechanical cash registers but intended to be cheaper and more reliable. For an early electronic cash register, there was usually no networking of any sort. If central reporting was desired (as it very much was in larger businesses for accounting), it was common for the cash register to output a punched paper or magnetic tape which was later taken to a mainframe or midcomputer to be read. That computer would then totalize the numbers from all of the cash registers to produce a day-end closing report. This was an improvement on having to read and key in the totals from the cash registers by hand, but was not quite a revolutionary change to computer technology yet.

The situation becomes quite a bit more interesting with the introduction of networking. Now, what we tend to think of as computer networking today is quite a bit different from computer networking in the '80s when electronic cash registers really became predominant. In this era, "network" usually meant the connection between a terminal and a mainframe. Cash registers were not a whole lot different.

Reading patent 4068213 covering some very early plastic payment technology in the mid-'70s, we get some details. An NCR 255 cash register connected to an NCR 726 controller. Even within the patent text, the term cash register is somewhat flexibly interchanged with terminal. Indeed, the architecture of the system was terminal-and-mainframe: to a large extent, the actual POS system at the cashier's station was merely a thin terminal which had all of its functions remotely operated by the NCR 726, a minicomputer, which would be placed in the back office of the store. The POS terminals were connected to the minicomputer via a daisy-chained serial bus, and because the cash registers didn't really do any accounting locally, all of the store-wide totals were continuously available at the minicomputer.

As time passed, this made it possible to add extensive inventory control, lookup, and real-time accounting functions to the POS, which were really all performed at the central computer. This included things like looking up item prices based on barcodes, handling charge cards, and validating returns and exchanges.

This basic architecture for POS has persisted almost to the present day, although I would like to return somewhat to my comfort zone and transition from discussing NCR to IBM. In the mid-'80s, at perhaps peak computer POS, IBM introduced an operating system creatively named 4680. 4680 was a microcomputer operating system (based on a DOS written for the 286) that was specialized to run on a relatively "thick" POS computer, such that much of the computation and control was done locally. However, 4680 POS systems were intended to be in constant communication with a mini- or mid-computer which ran an application like IBM Supermarket Application to perform data lookup, accounting, and all of the POS functions which required access to external data and communications.

4680 was replaced by the even more creatively named 4690, and 4690 is perhaps one of the most influential POS systems ever designed. 4690 and its newer versions was massively successful, and is probably still in use in some places today. In a typical installation, a set of 4690 POS systems (running on hardware also provided by IBM) would be connected to an AS/400 or similar IBM midcomputer running in the back office. The AS/400 would often have a telephone or internet connection which allowed it to regularly report data up another level to a corporate mainframe, and retrieve updated stock information.

The architecture of 4690 systems is highly typical of POS in large retail environments to this day. A 4690 POS would be connected by multidrop serial bus (one of the various IBM pseudo-standard network protocols) to the store controller midcomputer. It would be connected via RS-232 serial to a thermal receipt printer. In an add twist, this RS-232 bus was also essentially multidrop, as the printer would have a passthrough connection to the pole display and the pole display was basically controlled by special-case messages to the printer. The printer also, incidentally, had a simple electrical connection to the cash drawer and triggered it opening. Details vary, but the credit card terminal was typically also connected to the 4690 by serial.

All of this is basically how conventional POS are cabled today, except ethernet is usually used for the back-office connection and sometimes also for the credit card terminal (which might also be USB). Serial is still dominant for the printer and pole display in conventional systems.

IBM sold off their retail division to Toshiba, and Toshiba continues to develop derivatives of the 4690 platform, although the POS side has essentially been rewritten as a Linux application. Whenever you go to WalMart or Kroger or another major retailer, check a look at the system the cashier operates. Not many IBM branded devices are still out there although you might catch one, more likely you will see a Toshiba microcomputer (usually under the desk) connected to an unusual peripheral that consists of a set of pleasantly clicky mechanical keys and a two-line matrix LCD display (although full on LCD touchscreens are becoming increasingly common at WalMart, and universal at for example Trader Joes. Note that these touchscreen LCD systems maintain the physical keys for numeric entry and common functions).

This whole system is, essentially, a modern 4690, using direct descendants of the original hardware. That said, many of these systems today either run more modern software from Toshiba (I believe still SuSE based although I am far from certain) or, in larger retailers, a custom application developed internally by the retailer. In fact, for large retailers, it is very common for nearly the entire POS stack to be running custom software, from the actual computer to the credit card terminal and even the printer. The vendors of this kind of hardware offer an SDK for developing custom applications, and this is the reason why physically identical credit card terminals made by Verifone or Ingenico often offer a frustratingly inconsistent user experience[1]. It doesn't help that some of the terminal vendors have decided that their products are nearly iPad-ish enough and introduced touchscreens of a size once reserved for televisions, that retailers clearly have no idea what to do with.

I am told that some major retails continue to use either an AS/400, a more modern System i, or an AS/400 emulator on x86 to run the back-office system. That said, there are now UNIX-based options (I mean all-caps UNIX, we are often talking HP UX or similar) that are presumably taking over.

So we've talked a bit about the technical history, which is likely striking you as painfully arcane... and it is. We live in the era of ubiquitous microcomputers and flexible, fast network protocols. These enable all kinds of simpler and yet more capable architectures for these devices. And yet... let's focus on the usability.

One thing you will likely have noticed is that retail POS are typically either very fast (in the case of an experienced cashier) or very slow (in the case of a new one)[3]. Interaction with a 4690-style POS is primarily through a barcode reading weighscale and a set of relegendable buttons. While large color screens are becoming more common, lots of retailers still stick to only a two-line text display. The learning curve to operate these systems, especially in less common cases, is fairly substantial.

And yet, they are very fast. For barcoded items any kind of interaction with the user interface is seldom necessary. For non-barcoded items like produce, once a lookup table is memorized it is a matter of keying in an item number and weighing. Often there are one-press functions provided for operations like repeating an item. There are few distractors, as there are little to no "system notifications" or other software to interfere with the POS operation.

The POS has the property of being built for purpose. It contains the features necessary for efficient POS operations, and no other features. It uses a physical keyboard for entry because these can be operated quickly and by feel. It expects the user to learn how to operate it, but pays out the benefit of seldom ever providing any kind of prompt the operator needs to read or context the operator needs to determine, allowing operation to become muscle-memory.

These are traits which are, today, thought of as archaic, obsolete, and perhaps worst of all, unfashionable.

Compare to the "modern" POS, which consists of an iPad in a chunky mount. If you are lucky, there is a customer-facing iPad Mini or even iPod touch, but more often it is necessary to physically rotate the iPad around to face the customer for customer interactions.

This is a system which is not built-for-purpose. It is based on commodity hardware not intended for POS or even business use. It has few or no physical peripherals, making even functionality as core as producing a printed receipt something that many businesses with "modern" technology are not able to do. Interaction with the system is physically clunky, with the iPad being spun around, finger-tip signatures, and a touchscreen which is not conducive to operation by touch or high-speed operation in general due to lack of a positive tactile response. The user interface is full of pop-ups, dialogs, and other modal situations which are confusingly not always directly triggered by the user, making it difficult to operate by rote sequence of interactions. Even worse, some of these distractors and confusers come from the operating system, outside the control of the POS software.

All of this because Square either cannot afford to or has made a strategic decision not to develop any meaningful hardware. It does keep prices down.

In many regards these iPad-based POS are inferior to the computer POS technology of the 1980s. At the same time, though, they are radically less expensive and more accessible to small businesses. Buying an iPad and using the largely free Square POS app is radically easier to reach than buying an AS/400 and a 4690 and hiring an expensive integration consultant to get any of it to work---not to mention the licensing on the back-office software.

I make a point of this whole thing because it is an example of this philosophy I have been harping on: the advancing of technology has lead to computers becoming highly commodified. This has the advantage of making computing less expensive, more accessible, and more flexible. The downside is that, in general, it also makes computers less fit for purpose, because more and more applications of computers consist of commodity, consumer hardware (specifically iPads) running applications on top of a general-purpose operating system.

The funny thing is that the user experience of these newer solutions is often viewed as being better, because they are far more discoverable and easier to learn. There is obviously some subjectivity here, but I would strongly argue that any system which a person interacts with continuously as a part of their job (e.g. POS) should be designed first for speed and efficiency, and second for learnability. Or at least this is what I repeat to myself every time the nice lady at the bakery struggles to enter a purchase of three items, and then I have to sign the screen with my finger.

I'm not necessarily saying that any of this has gotten worse. No, it's always been bad. But the landscape of business and special-purpose computing is slowly transforming from highly optimized, purpose-built devices (that cost a fortune and require training to use) to low-cost, consumer devices running rapidly developed software (that is slower to operate and lacks features that were formerly considered core).

This change is especially painful in the POS space, because key POS features like a cash drawer, printer, barcode reader, weighscale, and customer-facing display are difficult to implement by taping iPads to things and so are often absent from "modern" POS configurations, which has a significant deleterious impact on efficiency and customer assurance. Amusingly, many of these peripherals are completely available for iPad-based systems, but seldom used, I suspect in part due to uneven reliability considering the iPad's limited peripheral interface options.

There is technical progress occurring in the conventional POS space, with far more retailers adopting full-color LCD interfaces and taking advantage of the programmability of peripherals to offer features like emailed receipts. But as much as parts of silicon valley feel that they are disrupting the POS space... 4690's creaky decedents are likely to persist well into the future.

Postscript: I am trying out not eschewing all social media again, and I am using the new Pleroma instance at my janky computer operation waffle.tech. Topics will be diverse but usually obscure. If you're a fediperson, take a look: https://pub.waffle.tech/jesse.

[1] It is also usually painfully clear which retailers have invested in developing good UX for their payment terminals (McDonalds), vs made a half-assed effort (Walgreens), vs throwing their hands in the air and just adding a lot of red circles to an otherwise "my first Qt app" experience (Target).

[2] Receipt printers are only supported by Square on iOS for some reason, and Square is cagey about whether receipt printers not on their special list will work. It obviously does support the industry-standard ESC/POS protocol but I think the core issue is the lack of flexible USB support in iOS. Bluetooth devices frequently have reliability issues and are too often battery-based. IP-based peripherals are excessively expensive and can be painful to configure. Somehow, POS peripherals have gone from eccentric daisy-chained RS-232 to a worse situation.

[3] This also reflects a related shift in the computing industry I hope to focus on in the future, which is that often modern UX practices do not really do well with users being good at anything. Many modern user interfaces prioritize discoverability, ease of learning, and white space to such a degree that they are downright painful once you have more than two hours of experience with the product. I'm not very old at all and I remember using text-based interfaces that were extremely fast once you learned to use them... that were later replaced with webapps that make you want to pull your hair out by guiding you and hiding functions in menus. This is all part of the "consumerization" of business computing and increasing expectations that all software feel like an iOS app made for first-launch engagement, even if it's software that you will spend eight hours a day operating for the foreseeable future. A lot of software people really get this because they prefer the power and speed of command-line interfaces, but then assume professional users of their product to be idiots who cannot handle having more than four options at a time. But now I'm just ranting, aren't I? I'll talk about examples later.