What did order processing on a teletype look like?

Question

The earliest business data processing systems were based on batch processing of punchcards. Prepare cards off-line, feed a batch of them through the computer. (Why does one so often hear of payroll, specifically, being an early application of such systems? It seems to me this is partly because the payroll of a big company involved a lot of repetitive calculation, but also because it's particularly amenable to that sort of processing: multiply hours worked by hourly wage, output pay due that worker for this week or month. The core of the job can be done without the sort of table lookup that would need a large random access data store that would only be available a little later with the invention of drum memories, then disk drives.)

When video terminals came in, during the late sixties and early seventies, business data processing user interfaces were able to become essentially as they are today: two-dimensional forms, type data into captioned fields, look up lists of records. I have not been able to find any screenshots of business software from before MS-DOS – closest I could find was someone editing a Pascal program on an IBM terminal – but I predict business data processing systems essentially similar to modern ones, must have been developed for the 3270, VT50 etc.

But in between those, there was an era of 'interactivity, but not as we know it', when computers supported interactive work by teletype. This is when Basic was invented; many of the classic Basic games were actually written on teletype systems.

It seems to me there must have been business data processing systems designed for teletypes, which would provide user interfaces not as good as video terminals, but much better than punchcard batch processing. But now there is the tantalizing gap between deducing the necessary existence of something, and finding actual evidence of it; I have not so far been able to find any documentation on interactive business data processing by teletype, other than SABRE, which was something of a special case.

Take for example the hundreds of thousands of PDP-11s, many of which were connected to ASR-33 and similar teletypes. Many of those must've been used for order processing and other everyday business tasks. What did the workflow look like? Are the names and provenance of any relevant software packages still remembered? Are there any surviving photographs or transcripts of what was printed, or any recorded memoirs of what it was like to use them?

Answer 1

But in between those [Batch vs. Terminal], there was an era of 'interactivity, but not as we know it', when computers supported interactive work by teletype.

Not really.

To start with, these were complete different usage scenarios. Batch didn't turn into terminal use - or got replaced by it. Batch is like mass production on industrial scale. It still happened the same way when terminals became widespread, as it's purpose didn't change.

In relation, terminal based processing did only replace parts of batch processing by improving data entry, replacing key punches. This evolved soon into form based (block mode) operation.

Teletypes were only for a very short time as generic devices, and soon replaced by terminals known as glas-TTY, terminals that operated like a TTY, just without the paper part. Real TTY were only kept in areas where there was a need for a paper protocol (like on system consoles) or simply as printers.

Finally glass.TTY are essentially what micro computers presented their interface on - from early CP/M all the way to Windows command line.

So, user interfaces for teletype looked much like the ones for later microcomputers in line mode. From BASIC to dBase. There is no principal difference.

Important here is to remember that the time of 'pure' TTY use was a quite short one, as glas-TTY and their ability to do 'full screen' by rewriting the screen emerged soon.

With glass-TTY emerging in the late 1960s (Datapoint 3300 1969, VT05 1970 and a whole armada of microprocessor based systems since ca. 1973) everything that is known from later microcomputers was ready available to their users.

Take for example the hundreds of thousands of PDP-11s, many of which were connected to ASR-33 and similar teletypes.

Not really. The PDP-11 was introduced in 1970, when glas-TTY were already a thing. More important it took quite a while until it reached sales that big. I'd say late 70s to mid 80s was the high time of PDP-11type computers, right when VDU terminals were usually the only kind attached.

Sure, our picture of that time are nice photographs of a huge PDP-11 wall with some TTY, maybe topped by a nice young lady in a lab coat - the computer equivalent of some youngster holding a soldering iron at the tip. It's a tainted view.

TTY were only a thing very early on and after that only relevant for cheapniks barely able to afford the computer with no money left to acquire contemporary terminals. That an image from hobbyist computing, not business applications.

---

Now lets take a look at the titular question:

What did order processing on a teletype look like?

It didn't exist. It was all about optimizing the existing process of a customer filling an order form and some (back) office turning it into a data set.

Just imagine what company would need and thus have a computer system for order handling in like 1970? For sure not a small one doing a dozend orders a day. And any company/department larger then this would already have a punch card based system.

If large enough to have subsidiaries, like distribution centers and/or agents, the next logical step is not to replace the working system by some less capable system with cumbersome teletypes, but improve data entry. A large enough company may already turn the forms a customer fills out into punch card orders as a local site and send a days stack to the central (or next) order processing site, getting back print outs with the stuff ordered whenever the delivery truck comes.

Improvement here is the next logical step, but not by adding extreme costly online communication (for what benefit?), but improve and speed up data entry. This is were systems like the Cogar 4 or Datapoint 2200 came into play around 1970. Local data entry with support for forms, basic referencing and validation, collecting entries and transferring them as batch into the existing mainframe environment. That these system as well could be used as low end data processing was a welcome side effect.

Not to mention that none of this replaces the existing (more or less) central data entry department, like for customers sending in a request letter with a sub from some newspaper add or alike. Similar customers calling in.

While this may of course differ between sectors of business, the basic situation is the same, no matter if auto parts, model railways or corn flakes. For smaller companies, growing into sufficient size, the solution is not siting down and envision a minimalist system, but buying a working solution - as shown.

So, in the end, (almost) no use case for a tty user interface.

Answer 2

For a relatively late example which you could run today under an emulator, I would suggest dBase II, a database program for 8-bit microcomputers. As the Wikipedia article goes into, it was based on an earlier program for mainframe computers. The CP/M version worked with dumb terminals, and I bet at least some early users had printing terminals.

This website has a brief transcript of installing dBase II under emulation. The part I've copied here starts the program and creates a new database table:

D>dbase

ENTER TODAYS DATE  OR RETURN FOR NONE
 (DD/MM/YY) :2/11/17

Copyright (C) 1982 RSP Inc.

***  dBASE II     Ver 2.4  1 April, 1983

 Type 'HELP', 'HELP dBASE', or a command

. create addo
ENTER RECORD STRUCTURE AS FOLLOWS:
 FIELD   NAME,TYPE,WIDTH,DECIMAL PLACES
 001     name,c,20
 002     surname,c,20
 003     street,c,20
 004     city,c,15
 005     state,c,3
 006     phone,c,15
 007
INPUT DATA NOW? N
. use addo
. disp struc
STRUCTURE FOR FILE:  D:ADDO    .DBF
NUMBER OF RECORDS:   00000
DATE OF LAST UPDATE: 02/11/17
PRIMARY USE DATABASE
FLD       NAME      TYPE WIDTH   DEC
001     NAME         C    020
002     SURNAME      C    020
003     STREET       C    020
004     CITY         C    015
005     STATE        C    003
006     PHONE        C    015
** TOTAL **             00094
.

Answer 3

A few pieces:

Why does one so often hear of payroll, specifically, being an early application of such systems? It seems to me this is partly because the payroll of a big company involved a lot of repetitive calculation, but also because it's particularly amenable to that sort of processing: multiply hours worked by hourly wage, output pay due that worker for this week or month. The core of the job can be done without the sort of table lookup that would need a large random access data store that would only be available a little later with the invention of drum memories, then disk drives.

Actually, payroll continues to be a "big deal" type of program because it is not just some simple multiplication. Federal taxes. State taxes. Local taxes. Health insurance and other deductions. Sick and vacation pay (both accrual and payment). Overtime. Not a simple thing. Plus, payroll for a big company, that could afford to rent a mainframe in the 1950s or 1960s, made even more sense: A nationwide (US) company might have to handle 50 different state tax tables/calculations, many different county/city/local taxes, people moving mid-year between jurisdictions, etc. Plus, payroll is a perfect batch mode application. Data entry was via punch cards (sometimes even doubling as physical time cards) and later interactive, but the actual calculations, review, printing checks and reports are all great batch mode activities, even today.

not been able to find any screenshots of business software from before MS-DOS

I find that hard to believe. CP/M gets from 1974 (first release) to 1981 (MS-DOS release). That's not counting any mini or mainframe applications. From a history of Sage:

Peachtree Software is most likely the earliest entry-level accounting systems in the world tracing its roots to 1976 as part of The Computer SystemCenter, an early Altair 8800 microcomputer dealer.

So just need to find some old Peachtree pictures... Or dBase II (as noted in another answer). Or plenty of other programs.

And now to the core question:

Many of those must've been used for order processing and other everyday business tasks. What did the workflow look like? Are the names and provenance of any relevant software packages still remembered? Are there any surviving photographs or transcripts of what was printed, or any recorded memoirs of what it was like to use them?

At all levels - mainframe, mini and early micro, a lot of software was custom-made. You didn't have application packages selling in the thousands for mainframes - because there just weren't that many mainframes. Even minicomputers, not so much. It really wasn't until CP/M (and more on the consumer side but used for plenty of businesses too, Apple ][, TRS-80, etc.) that you actually had "packages" where you would then see pictures, documented workflow, etc. Things were largely proprietary, or at least heavily customized. Mass-market business (and other) software started to show up in the mid-to-late 1970s, so it wasn't long before MS-DOS took over, and the bulk of that software (CP/M on up) was designed for video terminals. Many programs had configuration procedures (from a file read in at startup to bytes patched in an executable to recompilation) to handle different types of terminals.

The end result is that even though teletypes were quite common through the 1980s (as terminals on mainframes, minis and micros, then later transitioning to "just printers" - as was the case with many DECwriters in particular), the software they were used varied tremendously and the documentation of workflow, if there ever was any documentation, is largely lost in the sands of time.

I wrote some programs of that sort (mini, later moved to micro, 1980s) myself, as I am sure many others here have done. In some respects, workflow hasn't changed - just the details - prompt line-by-line vs. fill in the fields hit "send" vs. fill in the fields and click "submit". In fact, if you go to Costco or many other big stores you'll see PCs running essentially a 3270-ish emulation for item lookup and similar applications. That isn't quite back to teletype, but it does show, in a slightly different way, that software hasn't changed so much in 50 years.

Answer 4

First, Payroll is really apt for batch processing. It runs once a week or twice a month in general, and it tends to be all done at once on "payday". So each week the operators key in the time cards, then they process them, they run and audit the reports, then they cut the checks. Big, meaty processing tasks done in bulk, vs high density transaction processing demanding instant feedback. Mind, at the same time, this is where computer reliability has to be top drawer. There're few things less fun than the payroll system not working when payday comes around. The operators have a short window to key it all in, run it all, and print it all out.

Operationally, adding a teletype did not change much. It would be some time before a terminal was actually more efficient than a card punch and a card reader. Data entry need not be an "interactive" process. In many cases it's just flat faster to key the data in twice and look for exceptions than it is to have each operator check everything. We're talking heads down, 10 key data entry, streaming numbers in.

So, the interactivity of a teletype wasn't really necessary. The slow (110, 300 baud) data rates weren't worth waiting for. It was much more an operators terminal interacting with the machine. Plus, the teletype keyboards were honestly quite awful compared to a good card punch.

It wasn't until the terminals started showing up, with better response rates, that data entry moved toward these devices. More complicated forms, better error validation, easier navigation. But, still, the entry operators are looking at the input material, not the screen.

We did one system where the operator would enter the line twice, and we'd alert them if they made a mistake. You have to appreciate that it says 3, 4, 5, or more BEEPs from the terminal to get the operators attention that they have an error. Then they stop, try to pick up the context, and the error, and redo it. The operators tend to be ahead of the computer cognitively, it's very important for the machine to keep up. It's also very mechanical for the operators. They honestly don't consciously know what they're keying. They're simply a conduit for data.

We had one lady that was adept at both the main keyboard and the top row. Hers was mixed data entry, not just numeric, and during that time she did not use the ten key. She just shifted her hands and danced on the digits.

We learned a lot about errors that operators can do. I wrote a entry program that let her do the entry on her local PC, then we'd upload the file to the VAX. Problem was my program had some gaps in the entry department, notably one of the characters it was able to capture was ^C. Since we were just copying the console to a file (vs an actual transfer program), this data would just abort half way through. We went through several rounds of validation to get it all clean. Her name was Evy, and so we coined it "Evy proof". Delightful lady.

So.

The teletype did not drastically change the workflow for data entry at the time, it and the systems just were ready for it, and there were much more efficient technique and workflows available.

Answer 5

I was a student pilot in the late 60's and teletypes were used as terminals to the weather services. I would consider that an end user interactive system. As I remember, it was line command driven and the speeds were slow enough that there were lots of abbreviations used to cut down on the characters transmitted. This was confusing and could easily lead to misunderstandings. Even when weather stations moved to pc's abbreviations were used and seemed silly.

It is very interesting to me how ascii codes developed and even today carriage return, line feed, bell, horizontal tab codes are still embedded into files and cause confusion if not understood.

I also used teletypes with paper tape readers on an interactive Hp minicomputer to program basic in college.

Answer 6

As Raffzahn had mentioned, there was no real "teletype era"

Yes, teletypes were used, but not as end-user terminals - they were system consoles. So there were no business people doing order processing on them. The era of terminals did not come until time-shared OS became common (mid-1960s), and by 1970 there were CRT terminals around.

Computer terminal Wiki