Back in the old days, when computers were called "Mainframes", had the size of a cupboard, and only "operators" were allowed to do anything to them, all "users" had on their desks were terminals. A terminal looks almost like an iMac (but much uglier), it would have a keyboard and possibly a printer attached to it, but no disk drive etc., and it would not run programs - that would be left to the mainframe. It would usually display only letters, no graphics, and windows were (almost) unheard of.
The terminal and the mainframe had to be connected, of course; either by a very long cable (if they were in the same building) or by modems and a phone connection. The user would type something, the terminal would send it to the mainframe, the program on the mainframe would process it and send the results back to the terminal for display.
(If you're following latest trends, this would work a lot like the much-touted web applications, only the mainframe is a cupboard-sized server rack, the cable is an internet connection, and the terminal is your computer running a web browser).

These terminals had a lot more keys that made no sense to the uninitiated, so it's really a boon that IBM reduced their number when selling the PC as a new kind of terminal to its customers (yes, an IBM 3270 terminal emulation would probably make use of all those keys - I've never used one, so I wouldn't know). For example, it would be useful to have the printer that was attached to the terminal print out a screenshot of the screen (PrtScrn), or have it simply print everything that the mainframe sent; it would be useful to pause the text scrolling down the screen to read it at leisure while keeping the program on the mainframe running and sending more output over the slow connection (Scroll Lock), and resume scrolling when done reading; it would be useful to pause the program running on the remote computer (Pause) and resume it, or to stop it altogether (Break). Also, it might be useful to tell the computer "here I am" without sending input to the program that was running, to prevent the system from doing the equivalent of a modern-day screensaver and close the connection (SysReq, or System Request). Very handy would also be a key that could be used to configure the terminal (e.g. to set colors, brightness in some cases, and other options), again without disturbing any running program on the mainframe that might expect input, and that's what the Esc (Escape) key was for - to tell the terminal: this and the following keystrokes are meant for you!

Now obviously since the new PC had to be able to double as a mainframe terminal through the use of a terminal emulation program, its keyboard had to have all these keys as well.
And by golly, since they were there to work with, the DOS designers found a way to put them to use, approximating their original use pretty well. (Btw, my DOS 6.2 handbook doesn't list them, I had to look in a 3.2 handbook to find them explained). PrtScrn would do a Screendump = send a screenshot to the printer (modern printers that take only graphics input can't handle that); Ctrl-P would turn printer logging on and off (= any text appearing on the screen gets send to the printer until logging is turned off again - you could use your computer without a screen at all that way, but most usefulyl have a record of what you did); Scroll Lock would pause scrolling (and in most cases, the program as well); Pause would pause a program (which would stop it producing output as well, of course); Break would stop a program altogether, and Esc would be used in editors etc. to enter commands instead of text.

Not all these choices of words were all that lucky (after all, a break and a pause are pretty much the same, unless you think about breaking out of something) and derive from those mainframe days - this applies to quite a few of the DOS commands as well, e.g. "echo" would refer to text sent to the mainframe over the long cable and the mainframe sending it back - quite a similarity to a real echo there.

Because the connections between the mainframe and the terminal were very slow in these days (300 baud or less, which is 20 times slower than your internet connection today), you could save time by keeping commands short, at the cost of keeping them understandable - thus "cd" for "change directory" etc. This may also have contributed to the use of cryptic (but short) error messages, up to the complete lack of "success" messages (as is the case with most UNIX tools).

So you see, all those mysteries of computing have roots in ancient times and were the practised rituals of a few initiates.

Michael "mendel" Mendelsohn
rinkforum@mendelsohn.de