4

Most of the ASCII character codes make sense in the context of data transmission, e.g. ␄, ␗, ␖ (end of transmission, end of transmission block, synchronisation). However, there are also codes such as ␜, ␝, ␞, ␟, ␙ (file separator, group separator, record separator, unit separator, end of medium) which make less sense in the context of data transmission and more in the context of low-level file management on tape or disk.

As pointed out by Mauri Markowitz, the character codes do make sense in the contexts of storing read cards from a card reader, to separate the data from cards. Was this taken to its logical extreme?

Was ASCII used as the basis of any file systems / encapsulation formats? If so, which?

  • I'm not very good at making tags. Are any more necessary? – wizzwizz4 Jul 19 '17 at 19:37
  • 1
    The separator control codes just act at a conceptual level above the transmission control codes you mentioned. When transmitting a series of files or records you might separate them with file or record separator control codes respectively. There's really nothing to base a file system on. I don't know if any of the ASCII control codes you mentioned ever got much usage. (Although EOT is used for the default end-of-file character on Unix terminals.) – Ross Ridge Jul 19 '17 at 19:59
  • 3
    0x1a, SUB, is a de facto part of the filing system in CP/M as files must all be a multiple of 128 bytes, so an inline SUB (Ctrl-Z) is usually used to indicate a file that ends anywhere within its final 128 bytes. – Tommy Jul 19 '17 at 20:30
  • 2
    The ASCII separators are the conceptual equivalent of what batch systems like IBM's JCL did with punchcards: You had one big stack of cards, which contained several input files, and each file could have a number of records. That has nothing to do with file systems. Also see e.g. here. – dirkt Jul 19 '17 at 21:43
  • 1
    And DOS inherited some of that Ctrl-Z behavior from CP/M. Early/ported apps often ignored anything past a Ctrl-Z in a text file. And a Ctrl-Z on the command line (synonym key: F6) signals the end of input from the console when it is being redirected (to a pipe or file). That's still true today in Windows. – Euro Micelli Jul 20 '17 at 4:20
6

The codes in question were normally used to simulate special interrupts and/or control cards. The idea is that you could take a stack of 80-column punch cards (for instance) and translate them as a series of 80-column lines in a single ASCII file. To indicate a separator card, you'd put in a RS.

  • 1
    ASCII was used to exchange news-wire stories before it was used with "computers" as such. If an ASR-33 teletype receives a control-Q, it will start sending data from its tape reader to the remote end; when it receives a control-S, it will stop. If it receives control-R, it will advance the tape as it punches data received from the remote end; control-T would stop the tape advance (interestingly, the punch itself will still operate, but it will simply punch the same holes over and over again). I suspect other characters were probably used to operate more complex routing equipment. – supercat Jul 21 '17 at 19:13
  • 1
    Open up a terminal on a modern Mac or many Linux variants, start something that produces a lot of output, and type ctrl-S. Though unlike on traditional systems, any key will get it unstuck, you don't have to explicitly use ctrl-Q. – Chris Stratton Jul 22 '17 at 13:05
0

Data transmission and text file handling are not truly separate aspects in many operating systems. This is very evident in DOS and unix systems, where special files that map to character communications channels exist, and where redirection means that programs can be made to accept either a text file, or terminal input (which traditionally was from a serial line, and is often mapped to device files that behave not entirely unlike one); also, a common way to print from programs that generated plain text, to printers that accept plain text, is to redirect the output to a parallel or serial device file that happens to have a printer connected to the corresponding port.

While the specific control characters mentioned in the question rarely are relevant to printers, they are relevant to both actual serial and emulated terminals - many linux terminal emulators will react to flow control characters etc, often to the confusion of users, eg when CTRL+S/CTRL+Q are accidentally entered (the former will give the appearance of a hung terminal)....

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.