History of Ctrl-S and Ctrl-Q for flow control

Question

Which OS was the first to use Ctrl-S and Ctrl-Q on the console for pause and continue?

I first discovered Ctrl-S in IBM PC DOS 1.1.

Answer 1

Which OS was the first to use Ctrl-S and Ctrl-Q on the console for pause and continue?

TL;DR;

It's been developed independently of anything one might call an OS (*1). It's (nowadays) called Software Flow Control and has been around since the early days of computers using ASCII I/O, as the Model 33 Teletype used the device control codes DC1/DC3 (CTRL-Q/CTRL-S) to make a sender stop or resume transmission.

---

Long Read:

Today it's defined in the ITU-T V.43 standard as 'Flow control by use of DC3/DC1 characters', but has been around since even before the definition of ASCII. The oldest origins I know are the FIELDATA alphabet definitions starting in 1956. While itself based on the 5 bit International Alphabet No.2 (ITA2), FIELDATA used 7 bit words (*2). Here for the first time two characters were officially (*3) defined to control transmission:

RTR - Ready to Receive     (Code 49) 
NRR - Not Ready to Receive (Code 50) 

These characters were to be used by receiving equipment to signal non-ready conditions and make the sender stop (with a delay of up to two characters). This functionality was incorporated by Teletype in what they delivered for military use.

FIELDATA also defined many more control characters, and while most made it into ASCII (*3), these didn't. Instead a set of four general-purpose device control codes got added. When Teletype defined the Model 32/33, they decided to use two (*4) of these four codes for their start/stop feature. The result was:

DC1 - XON  (Code 17)
DC3 - XOFF (Code 19)

The Model 33 not only became much used with early computers, especially minis, it also gave the template for early terminals, AKA glass TTYs. Application and later device drivers learned to obey these commands codes to avoid overrunning slow equipment.

As usual it was fast discovered by users, that it's possible to issue DC1/3 by pressing CTRL-Q/S, thus handy control of fast scrolling text output. Neat, isn't it? The rest, I guess, is history.

---

More History

Already the Teletype Model 28, originally designed for military use, had an optional way to use a received . (or #) to stop the (printing) motor. Thus sneaking in control function. This was part of the so called 'Stunt Box' where a character or a character sequence could be detected and a switch could be flipped. This not only meant closing an electric contact, but literally pushing a rod that could flip a switch or whatsoever needed.

The Beginning

This brings us to the introduction of the very first control characters with ITA2 of 1924 as:

CR   - Carriage Return
LF   - Line Feed
BELL - Ring a Bell
WRU  - Who aRe You (*5)

Before that, teletype text didn't have any structure of lines and even with ITA2, the page was still not 'invented'.

---

Addendum:

A point has been made by Tofro, that the concept of control characters is older, as Morse Code already uses prosigns ('Procedural Signs') for special messages, including flow control. For one, these are later additions grown out of custom, but more importantly, they are not separate control characters, but reuse of existing combinations which may or may not be understood by the context the receiver works in.

For example 'Wait' uses the same code as ampersand & which in itself is a digraph of Aand S (Both letters sent consecutively without a letter space; (*6). Similar the signal used for 'Continue' is the letter 'K' officially called 'Over'. There is no hint in the encoding what meaning this letters are supposed to have.

In a more general view it's a problem with in-band signalling. Here, protocol information needs to be transmitted together with a payload. To handle this on code layer, separate and unique codes for protocol handling are needed. Otherwise an additional encoding layer (escape sequences) atop the character encoding but before protocol must be added.

Bottom line, ITA-2 was the first to go that route, and FIELDATA the first to incorporate flow control - with Teletype bringing that into applied ASCII.

---

*1 - Well, then again, assuming that an OS is after all nothing more than a set of rules followed up by its components, then even handling such rules may qualify. No-one says an OS needs to have memory protection or a GUI at all ;)

*2 - Or Start-Stop Seven-Unit Code as they called it.

*3 - Like blocking, (not) acknowledgement, field separators or the 'Special Character'.

*4 - The other two where used by the sender to control the paper tape punch. DC2 as RION, DC4 as RIOFF

*5 - Looks like Leetspeak or sounding letters as words aren't really a new invention after all, does it?

*6 - Digraphs are a constant issue of problems in morse, as it's often hard to decide if a sequence is meant to be a digraph letter or two single letters. Usually it takes knowledge of the language to be safe here. More complicating it for native English speakers, as the rest of the world uses a huge number of digraphs for their language special characters. Even more, the simple joining of two letters in Morse may lead to various valid interpretations, so again, human knowledge is the only way to pick the most plausible interpretation

Answer 2

First OS is hard to say. The codes go back to the 1960s with the Teletype Model 33. I have a hunch the original usage was not part of an operating system but at a lower level. In later times, certainly by the 1980s, there were plenty of devices that functioned with software flow control at the hardware level.

Microcomputer operating systems that supported Ctrl-S/Ctrl-Q included CP/M 2.2. I found plenty of versions of the CP/M 2.2 manual with multiple copyright dates from 1976 through 1984 that included clear references to this feature, but it is not clear at what time it was actually added. I suspect it was very early on (closer to 1976), but I'm not sure.

Answer 3

It was nothing to do with an OS as such. Ctrl-S and Ctrl-Q are simply XON and XOFF in ASCII.

These codes are used in serial communications to pause and resume sending.

With hardware handshake on RS232 and similar communications standards used the RTS (RequestTo Send) & CTS (Clear To Send) handshake lines.
Many comms links were, and still are, three wire - send, receive and earth. On these, you use Software handshake. The receiving end will send XOFF to tell the sender that its input buffers were nearly full and then XON to tell the sender to resume once the buffer had emptied a bit.

These codes go back to the dawn of RS-232 in 1960. A standard that was deliberately OS-agnostic.

Answer 4

As a user of teletypes and serial communications back in the 1970s - this is my understanding as well. There were hardware signals for "flow control".

Was thinking you set bits on UART which then converted to voltages on communications cable.

For example if Device A was sending to Device B - Device B needed a way to slow down the sending of data from Device A - so that Device A did not overrun the receive buffer of Device B. There were hardware signals that Device B could set to tell Device A to stop sending.

It was considered a huge improvement when they could embed software flow control like Ctrl-Q and Ctrl-S in the data and you no longer needed to set hardware flow control signals on the UART.