r

/ / /

C O M M A N D (JOB CONTROL) L A N G U A G E S F O B G E N E R A L

P U R P O S E

C O M P U T I N G

D o n a l d W.

S Y S T E M S

Boettner

U n i v e r s i t y of M i c h i g a n Computing C e n t e r

June

1969

TABLE OF CONTENTS Introduction Basic Definitions Categories of Commands Notation BNF IBM Iverson Categorization of Systems Scope Second versus Third Generation Batch ana Terminal Systems BASIC CP-67/CMS CTSS GECOS IBSYS MTS MULTICS OS PDP-10 SCOPE 3DS940 TSS USES Criteria ror Command Languages Simplicity Symmetry and Uniformity Conciseness and Brevity Ease of Reading Error Detection and Prevention Extensibility and Flexibility Reassurance Reconciliation of Criteria System Design Command Names Abbreviations Parameter Types Universalities

1 3 5 11 12 13 14 15 15 15 16 18 19 20 21 22 23 24 25 27 29 30 31 32 33 34 34 35 35 36 36 38 39 40 40 41 41 42 43

References

44

1

COMMAND (JOB CONTROL) LANGUAGES FOR GENERAL PURPOSE COMPUTING SYSTEMS

The following expresses the thought manufacturer*s manuals for users:

underlying

so

many

11

'Just the place for a Snarkl' the Bellman cried, As he landed his crew with care; Supporting each man on the top of the tide By a finger entwined in his hair. •Just the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What I tell you three times is true.'" [Car 76] INTRODUCTION People using computing systems to solve their problems have always been aware of, complained about, and fought for and against the languages they had available to solve their problems in. In the beginning was raw machine language. Then came along the assemblers, whose purpose was to remove the annoyance (by doing part of the work - the clerical part) of machine language. These were followed by the socaliad "higner-level" procedure-oriented languages: Fortran, PL/I, etc., where tne exact code produced was not important as long as it implemented the procedure (algorithm) expressed in the language. And finally, most removed from the machine, are the problem-oriented languages, such as MIDAS, COGO, et.al. where basic rules and data are expressed, but basic algorithms (such as what method to use in performing a specified integration) are not. In contrast to this, people have by and large been unaware of the command language with which they address the system as a whole. In fact, only recently have people started calling it a language. In the beginning, there were no executive systems, and so, of course, no command languages. But as soon as the first batch processing monitors came along, a user had to have a way of specifying whetner he wanted the assembler or Fortran loaded from the master tape, and the first command languages came into being. However, most command languages did not enjoy thougntful design or orderly growth. As Rosin [Hos 69] says "In many cases the command languages "just happened".'• It must be remembered that the command language is the one language that all users of a system use. It is their view of the system, and most affects their opinions of it. There are many criteria, often contradictory, which may be

2

applied when designing a command language. designed.

But it

must

be

It is to this end that these notes have been written. Several criteria are presented and the effects of these are discussed. The presentation is deliberately informal and opinionated. Most, if not all, of these criteria are obvious, but it is about time to say the obvious, and hope someone finally listens. As it has been said, "Science is the business of majcing the self-evident obvious" [Anon; reported in Cam 69]. In what follows, examples will be drawn primarily from those systems the author is or has been most familiar with, systems on the IBM 7090 and 360/67: IBSYS, UMES, OS, TSS, dTS. Other systems acguainted with by written description, demonstration, (and some usage) and conversation: CTSS, CP/CMS, SDS940, BASIC, MULTICS (to some extent). Known only by product literature: PDP-10, GLCOS. The systems selected are not meant to be exhaustive, but to cover the spectrum. The emphasis will be on general purpose systems, by which is meant systems that offer both batch and terminal activity. Contrast will be made to batch-only and terminal-only systems.

3

BASIC DEFINITIONS Some of the terms defined below are used in these notes; the others are implied and will probably come up in any discussion. These definitions are deliberately more restrictive than many other definitions for the same terms. BATCH and TERMINAL activities are both very important concepts. The detailed discussion of their differences will be left to a later section on "Categorization of Systems". For the present, the "traditional" viewpoints will be presented: Batch activities, usually called jobs, are those in which a user preplans and constructs a complete sequence of things to be done (for example, he punches up a card deck), and then submits this entity for computer processing. He tnen has no connection with it until he gets back his output. Terminal activities, usually called sessions, involve a person at a terminal (such as a teletype) which is connected to a computer. Hdoes something and gets back a response before he goes on to decide what to do next. The Key nere is the interaction of the user and the computer. A COMMAND...LANGUAGE is the language, both syntax and semantics, by which a user addresses the system and indicates the tasks he wishes performed. For the purposes of discussion here, define the syntax of the language as specifying what it is legal to say in the language, and the semantics as specifying what it means (i.e., what will happen) when something is said. Since the term "Command Language" with no context often brings to mind various command and control systems developed by and for the military, the term "Job Control Language" is sometimes used (whence the parenthetical phrase in the title of this paper). Since "Job Control Language" brings to mind even more readily the command language for OS, which has the same name, it is considered less desirable as a generic label. COMMAND SYSTEM is a term which has recently come into vogue. For discussion here, we will use "command system" to refer to the entire interface between the user and the operating system. This includes not only the command language, but also such things as the control characters a terminal user uses to delete a character or a line, and so on. It should be noted tnat these notes are actually discussing command systems, not command languages, according to these definitions. MULTIPROGRAMMING. MULTIPROCESSING, TIME-SHARING. Time^ sharing describes the external appearance of a system: it means that two or more users are each at the same time getting the effect of continuous service. As it is often (and somewhat more intuitively) stated, to each user it appears as if he has a computer all to himself. However, this "computer" is in general slower and more restricted than the actual computer all the users are running on.

4

(Applying a principle that says the whole is usually not much larger than the sum of the parts.) Multiprocessing and multiprogramming^ on the other hand, describe an internal appearance of a system. Multiprocessing means that there is more than one processing unit (more than one computer, if you wish) in operation at a time. Multiprogramming means that there is more than one user's program in memory at once.

5

CATEGORIES OF COMMANDS In programming languages, such as PL/I, MAD or Fortran, statements can be nicely categorized. First, statements are dichotomized according to whether they are declarative or executable. A declarative statement only gives information to the compiler; it does not cause object code to be produced. An executable statement causes object code to be produced which will do when executed what the statement saia. Declarative statements can then be further categorized into storage assignment statements, variabletyping statements, etc. Likewise, executable statements can be further categorized into conditional statements, I/O statements, iteration statements, control statements, etc. If we try to extend this type of taxonomy to command languages, however, we run into some difficulties. Consider first the dichotomy of declarative versus executable. Remember that the command language is the user's view of the Therefore, we system. It is an external specification. define a declarative command as one which just gives information to the system, but causes nothing to "happen". Which means that an executable command is one that causes something to "happen". For example the JOB command in OS, the SSIGNON command in MTS, login, logon, or what have you in other systems, are ail examples of a declarative command which declares the user to the system. The command that couples (causes an association, or attachment) the name of an actual data item and the generic (or canonical) name used by a program is a declarative command. This function is provided by the DD card in OS and the DDEF card in TSS. Thus, in OS, //FT06F001

DD

SYSOUT=A

sets things up (albeit in a breathtakingly unlucid manner) so that when a Fortran program issues a WRITE statement on unit 6, what is written will appear in the user's printed output (SYSOUT class A) . For executable statements, most command languages have a command which says "get this program and execute it". Examples are the EXEC command in OS, RUN and iRUN in TSS and MTS, respectively. Likewise, terminal systems have a command that lets a user list part or all of a file (or data set, or whatever you want to call it) . In MTS, if you say J5LIST QQSV it begins listing the file QQSV en your from line 1). Likewise, in TSS LINE?

QQSV

terminal

(starting

6

causes the file QQSV to be listed (starting from line) .

the

first

So far so good. The examples thus far have been carefully chosen so that they are• obviously either declarative or executable. Now let us pose a few objections. First, a careful look at "declarative" statements reveals a significant difference from the declarative statements of programming languages. In programming languages the declarations are truly static. In many languages, their order and placement doesn't matter. For example, in MAD/7090 a statement to declare the default mode for undeclared variables to be integer NORMAL MODE IS INTEGER can go anywhere before the END OF EROGRAH statement, and it applies to the whole program, regardless of where it is placed. (The fact that the equivalent in Fortran IV, IMPLICIT INTEGER (A-$) must be the first statement in a program has nothing to do with this subject. That was done merely to simplify writing Fortran compilers (that's the polite assumption).) In command languages, however, "declarations" are dynamic. They take effect when they occur and may (usually) be reset later. For example, in MTS $SET

IC=OFF

turns off implicit concatenation of files and a later $SET

when

it

occurs,

IC=ON

will turn it back on at that point. This dynamic quality of command language "declarations" unfortunately tends to make them sort of executable. The second problem with calling some commands declarative and others executable is that then some commands are both. For example, combining a few of the examples given earlier, in OS, the following // EXEC PGM=QQSV SYSOUT=A //FT06F001 DD says (close enough for our purposes) "find and execute the program in the file named QQSV and put the output from unit 6 in the printed output." In TSS, the following DDEF

FT06F001,VS,DSNAHE=vAARDVARK

7

RUN

QQSV

does the same except that it puts the output from unit 6 into the file named AARDVARK (Due to a curious blind spot in the TSS design, there is no way notationally to mention the terminal, and hence you cannot explicitly say to put the output from 6 on the terminal. It can happen only by default.) However, in MTS these are both part of the RUN statement, and $RUN

QQSV

6=*SINK*

does the same as the first example and $RUN

QQSV

6=AARDVARK

is the same as the second example. How does one categorize commands then? Well, in spite of the gloom of the preceding section, the declarative/executable classification can be used if used carefully. But beyond that? And how about other methods of division? One way to proceed is to see how various systems themselves classify their own commands. Looking at these for common factors, and applying much arm-waving, the following set of command categories is proposed. The terminology is heavily borrowed from the TSS categories, since it seemed to have the most elegant structure of categories. 1.

Task (or Job) Management (a) Identification - Identifies user to the system. Examples: LOGON (TSS) , LOGIN (Multics, PDP10) , SIGNON (MTS) . (b) Exiting - Telling the system "goodybe" politely. Often not an explicit command in batch usage. Examples: LOGOFF (TSS), LOGOUT (Multics), KJOB(PDPIO), SIGNOFF (MTS) .

2.

Program Management (a) Language processing - If separate commands are used to cause execution of the language processor as opposed to user programs. Examples: ASM and FTN (TSS). (b) Program loading and execution Examples: BUN and LOAD (MTS,TSS), EXEC (OS). (c) Debugging aids DISPLAY and ALTER (MTS,TSS), Examples: DUMP (MIS) .

8

3.

Data Management (a) Data Set Management Creation and destruction of files, coupling,... Examples: CREATE, DESTROY, EMPTY (MTS), DDEF, PERMIT, SHARE (TSS), DD(OS) . (b) Text Editing - Context manupulation of files. Examples: CONTEXT, CORRECT (TSS). (c) Data Editing - Manipulation of files on a byline number basis. (MTS), DATA, Examples: LIST, COPY LINE? (TSS) . from (d) Bulk Output - Obtaining print and punch a terminal session. Examples: PRINT (TSS).

4.

Resource Allocation - Obtaining (for a duration) a non-sharable resource like a tape drive. (TSS), ASSIGN Examples: SECURE (PDP10) .

5.

Assistance - Obtaining information on what or whats wrong from the system. Examples: HELP (SDS940, EXPLAIN (TSS) .

to

do

PDP10),

6.

User Information Management - Maintenance of information about a user's preferences, options, profile (or whatever you wish to call the information) . (TSS), Examples: DEFAULT, PROFILE OPTION (Multics) , SET (MTS) .

7.

Miscellaneous - There will always have to of these categories.

be

one

Now going back over the commands of the systems illustrated (and still other systems) would get the information in a state where it could more readily be compared. There are, however, several major problems to watch out for. First, it must be remembered that each of these systems differs in functional capabiliites. So some things have no equivalent in other systems because they can't be done in the other systems. For example, in MTS, wherever the name of a file can be used, it is also legal to refer to a subset of a file. Thus $COPY

A

TO

B

refers to the complete file A (Actually, that's a lie, it does refer to the complete "commonly used" part of L whereas

but ),

9

$COPY A(20,30) TO B copies only lines that have line numbers between 20 and 30 inclusive. This same idea, that the concept "file name" includes subfile in its definition, does not exist in TSS or OS, so there is no notational way to refer to part of a file. Second, in some systems the translators are special cases, and so there are special commands for invoking them. Thus UMES had a SASSEMBLE command. In other systems the translators are just programs which are run like any other program. Thus in OS, to run Fortran H one says //

EXEC

PGM=IEKAA00

(this being another breathtaking IBM mnemonic) and to run Fortran G one says

in MTS,

$hUN *FCfiTRAN where *FORTRAN is the name of the library file (* as first character of a file-name means it is a library, or public, file) containing the object deck of the translator. Yet in other systems the translators are run just like any other program, but a special command is provided as a notational convenience to the user because it is a frequently used item. Thus one could postulate a $F0RTRAN command for MTS, if one wanted to follow the last approach. Third, systems differ in philosophy about what is to be a command and what is a program to be run. Thus OS takes the extreme approach that there are no other commands but the ones to run a program, hence everything is done in a program rather than the command language. TSS and MTS differ in degree; TSS has many more commands and a great number of the things that are commands in TSS are programs in MTS. Thus there is a PERMIT command in TSS (to allow a user to permit someone else to access one of his files) and an *PERMIT program in MTS. Multics, on the other hand, very elegantly defines the problem out of existence. Every "command" the user enters is interpreted as a procedure call upon the procedure whose name is the first item entered and the rest of the line is taken as parameters to the procedures. However, there are -certain "system procedures" that are called commands, that do commonly-wanted things for the user. Fourth, and perhaps most important, some systems use commands for purposes that other systems use control characters and other notational devices for. That is, an item can be an explicit command in one system and in implicit command in another. For example, in both MTS and

10 BASIC there is no "delete" ccmmand to delete a line in a file. If a line that is typed in has the same line number as a line already in the file, the new line replaces the old one. And if the new line is of zero length (i.e., cnly the line number was typed) then the line is deleted. As another example, in TSS there is a SHARE command, which a user oust issue in order to refer to another person's file (assuming the other person has PEBMITted it). In MTS one just specifies the other person's userid followed by a colon (:) followed by the name of the file - eg: $RUN N978:PB0GRAM To sum up, the gist of this section has been that while it is possible to try and categorize command names, there is more to a command language than the commands' names.

11

NOTATION This section considers possible notations for the syntax of a command language. That is, when describing a command in a writeup ror users, how do you describe all possible ways of writing a command? If there is only one way, you just show it. But it is very rare for a command language to have any command with only one way to write them. At the very least, the command usually has an abbreviation, and so there are two ways of writing it. It would be possible then to list all possible ways of writing a command, but every option added doubles the number of lines this takes. Since for many commands the number of lines was already infinite (due to a variable-length parameter list), this method is patently infeasible. Besides, it must be remembered that this is for the user, and what he wants to see is a prototype command (a canonical form if you like) which shows by means of various notation devices where options may be inserted. This reasoning leads to what I have called the "IBM" form of notation (described below). This should not be taken to imply that IBM invented this notation; it merely means they use it in their manuals. Other people use a similar notation, but the reader should oe careful when looking at descriptions in this form to always read the definitions of the "notational devices", because often people will use one notational device (e.g. Brackets) to mean the exact opposite of what someone else means by this notational device. The other major notational form, which is used more for programming language description, is called "BNF" notation. BNF stands for Backus Normal Form ( or Backus-Naur Form, according to some), and first appeared as the means of describing ALGOL 60 in the now-notorious original ALGOL 60 Report [Nau 63]. It is named after John Backus (and Peter Naur) of the group that produced the language definition. This type cf notational form is beloved by academicians and theorists because it is equivalent to productions specifying a context-free grammar, and parsers, recognizers and theorems spring directly therefrom. However, in this notational form, one cannot look at the description of a statement and see immediately what its general form is. One must sit down with paper and pencil and (painfully) deduce that it is, for example, a keyword followed by a list of expressions. Because this kind of description is unobvious and bacause most command languages have a rather simple form that does not require this notational mechanism, this type of notation is not recommended for describing command languages.

12

BNF 1.

Terminal constructs - are things that will in actual commands.

appear

Non-Terminal constructs - are names of things that are not in an actual command. Non-terminal constructs are indicated by surrounding their names with less-than (<) and greater-than (>) signs. For example, . Everything not inside these delimiters (<->) and not specifically mentioned as a special construct (below) is a terminal construct. 2.

Special Constructs The sequence ::= means "is defined by". The symbol | means exclusive or. Juxtaposition means concatenation. Note that there are no grouping symbols. Parentheses are terminal symbols. Thus to define an JJa" as a 'JbH followed by either "Q^j" cr "SV", one cannot write ::= (QQ | SV) but must either write it expanded: ::= QQ | SV or else define a new non-terminal "al": ::= QQ | SV ::=

Example: Consider a simple signoff command in which the command name is either "SIGNOFF" of "SIG". Separated from this by at least one blank may be either "SHORT" or "SHORT,HOLD". A blank will be notated by a b^ ::= b |b ::= SHORT ::= HOLD ::= | , SIGNCFF | SIG ::= ::= | This

is of course not the only way to write this.

13

IBM The following rules govern this type prototype is given wherein:

of

notation. must

A

1.

Anything in upper case alphanumerics repeated verbatim. E.g., TO

be

2.

Anything in lower case alphanumerics is a generic name that must be filed in by the user. E.g., filename

3.

Items stacked inside curly brackets {} indicate that exactly one of the choices must made. E.g.,

4.

Items inside square brackets [ ] indicate optional parameters. E.g., [TO]. When there are choices specified inside the brackets, underlining of one of these may be used to represent the default case-i.e., what is assumed if the user does not specify this parameter. E.g. !• t [CASE=J •

1] Q

if the user does not specify, it is as if written CASE=LC

he

had

5.

A vertical bar is used to denote exclusive or. This allows the options inside brackets to be written out rather than stacked. E.g. {A|B|C} is equivalent to the example in (3).

6.

Any special characters other than curly brackets, square brackets and vertical bars must be repeated verbatim. E.g., =*()-+/<>•"? !*_' ,.:;

7.

If it is necessary to specify that a curly bracket, square bracket or vertical bar appear in a command verbatim, it should be underlined to indicate its literal occurrence as opposed to its normal use as a meta-sjmbol. Note that since curly brackets, square brackets and vertical bars are not usually in most command languages (and often are not in the character set provided by the manufacturer), this rule is rarely used. It is necessary to provide it as an "escape hatch", however.

8.

For command languge descriptions, juxtaposition of

14

items usually mean that one or more blanks separates them. This should always be stated with general "rules of the game" preceding the command descriptions, however. Example: Consider the same example used in the preceding BNF descriptions. Using IBM notation, the prototype of this command becomes: (SIGNOFF) / i

[SHORT[,HOLD]]

IVERSON We cannot let a discussion of notation go by without mentioning Iverson. The author has been impressed by the mathematical elegance and symmetry of his work, not only in the original description [Ive 62] but even more impressively (considering what usually happens when something is implemented) in its implementation as the language APL [Ber, 69 and others]. There should be some exciting application of it to ccmmand languages. The reader is invited to explore this side-trail and see where it leads him.

15

CATEGORIZATIQN.OF SYSTEMS Before briefly looking at several systems, it is necessary to categorize them. This categorization is along the lines of functional capabilities, and consists of three different and independent ways of classifying systems. These are classifications by scope (or generality), by second versus third generation, and by batch, terminal, or both. Scope This classification is described by Arden [Ard 67]. We consider four categories: 1.

Special Purpose. Users may not write programs, but only enter data and ask questions. Examples are reservations systems, inquiry systems. No systems of this type are considered in this paper.

2.

Limited Programming. Users may write programs, but they are limited in languages, size, form, etc. Often these are one-language systems. Example: EASIC, QUIKTRAN, JOSS.

3.

General Programming. User's programs and data are generally unrestricted, but developing, checking out, and installing system components (e.g. translators) cannot be done "on-line".

4.

General Programming and System Development. Unrestricted execution-time programs and data, and in addition, system components can be worked on at the same time as everything else.

Second vs. Thirdegeneration It is generally agreed there is a difference between the systems available on "second-generation" machines like the IBM 7090 and "third-generation" machines like the IBM System/360. It is not at all clear exactly what comprises this difference, other than a difference of complexity and sophistication due to the fact that one appeared after the other. It is mostly independent of hardware; there are second-generation systems running on third generation hardware and third generation systems running on second generation hardware. The following guidelines are what the author thinks he uses to "arbitrarily" classify a system as either second or third generation. One major item is that of short-term and long-term memory. In second generation systems, the only thing remembered between "job-steps" was whether the translation suceeded or not. And, in general, nothing was remembered between jobs of the same user. Thus the system could not

16

keep track of the user's resource uses, his options or defaults, and the user could not (except by writing a tape or punching a deck of cards) save information from one job to the next. In third generation systems an important part is the file system, whereby users can save arbitrary information between jobs on various direct-access devices. Another item is data management. There was often one way at best to do I/O in second-generation systems and only tapes (usually) to do it on. Kith third-generation systems came the proliferation of devices and "access methods" for doing I/O on (or to) them. Second generation A third item is task managment. systems ran cne job at a time, one after the other. With third generation systems came multi-programmingand multitasking within jobs. A batch job in a second-generation system consisted of several (optional) translations followed by the execution of all that had been submitted. The translation's output went on something magical called the "execution tape" over which the user had nc control. With third-generation systems there is more the concept that a translator is just a program, and the user must specify when he runs it where it gets its source statements, where it should put the listing, and where it should put the object deck it produces. It is up to the user to specify when and if he wants it executed. Batch and Terminal Batch operations are usually associated with the idea of someone handing in a card deck to be run, going home, and coming back later when it is done. Terminal operations bring to mind the picture cf someone seated at a teletype (one often views him as sitting there waiting for something to happen, but one should consider this an j,implementation viewpoint). The key difference, however, is that of interaction between the user and the computer. Once the batch user has submitted his job he no longer has control over it, whereas the terminal user has continuous control over his "job". A interesting definition is that provided by iiULTICS, which has what they call an "Absentee User Process". They define "An Absentee User Process is one which has attached to it no I/O device operated by a person". [MSPM-section BX] It should be noted that terminal systems that do no have batch facilities will often have a "foreground-initiated-background" facility by which a user can stack up a set of commands to be executed in his absence (i.e., asynchronously from him). Also note that "Remote Job Entry" facilities, by which users may submit card decks from remote stations for batch execution, and "Conversational Remot Job Entry" facilities, by which a user can type a batch job in from a terminal and

17

then submit it for batch execution, are to be classified as batch operations, rather than terminal operations. This is because the user has no way to interact with his program. Interaction is lacking. Some systems that have both batch and terminal facilities have a different set of commands and a different command format for batch usage than what is used from terminals. The PDP-10 system is an example of this. Most systems consider a batch job to be a "ham-strung" terminal job, and make no distinction between the two until a batch job gets to a point where it would require interaction (for example, a parameter has been omitted and the user must be prompted for it), at which point an error condition is flagged.

18

SYSTEMS A variety of systems are mentioned in this section. The selection of systems is primarily due to the availability of documentation to the author, and also due to whether it was felt germane to the points to be discussed. This is not meant to be a complete survey of the subject; it is strongly doubted that things would stand still long enough to do such a survey. It should also be noted that the comments in this section are meant to reflect the author's biases (this should really be apparent already). The capabilities and features of the systems mentioned are not of concern here except when they influence the command language. Hence not mentioning a feature should not be taken to imply that a system does not have that feature. The order in which the systems are presented is alphabetical.

19

BASIC

(Beginners All purpose Symbolic Instruction Code)

Developed by Dartmouth College for a GE235 and 30 combination. Categorization: Reference:

Datanet

Limited Programming, terminal.

BASIC , Dartmouth College June 1965.

This describes the "original" versions of the same name.

BASIC,

Computation not

later

Center, escalated

Command Structure: As befits the name, the command language was very simple. There were on the order of a aozen commands. If the user entered a line beginning with a number, this was taken as the line number of a program line for the current program the user was entering. Otherwise, it was a command. Many of the commands had no parameters (E.g., RUN,STOP,SAVE,CATALOG) and those that did usually prompted for them (if you said NEW, then it asked you for the name of the new program).

20

CP-67/CMS

CP-67 (Control Program for the IBM 360/67)

CMS (Cambridge Monitor System) running under CP-67 Developed by IBM's Cambridge Scientific Center. Categorization: General Programming, terminal. Reference: Basic documentation supplied with program 360D05.2.005 (CP/CMS is a Type III program available from IBM) Command Structure: The command structure of CMS greatly resembles that of CTSS, since it is (from an external appearance) merely CTSS with improvments and the rough spots smoothed over. This system takes the approach of making a command out of everything, rather than making a program out of everything like OS does. The reference above lists 48 commands; a later summary, prepared for 1969 SJCC by the IBM Cambridge Scientific Center, lists 62 commands. A command line has the command name first, followed by parameters separated by blanks. A notable point anout this command language is the complete lack keyword parameters. All parameters are positional, and to indicate the "absence" of a parameter an asterisk is used.

21

CTSS

(Compatible Time-Sharing System)

Developed by Project MAC at Mil. The granddaddy of all general purpose time-sharing systems. Of historical importance. Categorization: Reference:

Command

General Programming, terminal.

"The Compatible Time-Sharing System. Second Edition, Programmer's Guide", Computation Center, MIT Press, 1965.

A MIT

Structure: There were an immense number of commands, rather than a library of programs, to perform various services. The first item in a line was the name of the command, the rest were parameters. Parameters were delimited by blanks.

22

GECOS

(GE's Comprehensive Operating System) The General Electric Company's Computer Division.

The operating system computer. Categorization: Reference:

supplied

by

General Programming, generation.

GE

for

the

batch,

GE-635 Comprehensive Operating General Electric Computer publication CPB-1002, July 1964.

GE635

second-

Supervisor, Department,

The GE635 is essentially an improved IBM 7090, and therefore it is not surprising that GECOS looks a great deal like IBSYS. Due to unavailability of current literature, not much will be said. Command

Structure: Commands are fixed-form, with $ in column 1, command name in column 8, and optional parameters starting in column 16.

23

IBSYS The operating system supplied 7094, 7040, 7044 Computers. Categorization:

by

General Programming, generation

IBM

for

the

batch,

7090,

second-

References: "IBM 7090/7094 IBYS Operating System, Version 13, System Monitor (IBSYS)", Form C28-6248-3, December 1964 "IBM 7090/7094 IBSYS Operating System, Version 13, IBJOB Processor", Form C28-6389-1, July 1965. This was probably the most sophisticated, although not necessarily easiest to use, operating system available for the IBM 7000 series machines. It was subsystem-oriented: IBSYS was the general monitor and recognized control cards for job recognition, I/O assignment, tape positioning, and an EXECUTE card used to call in a subsystem. The most common subsystem used was IBJOB, which contained a macroassembler, a Fortran IV compiler, a Cobol compiler, and a very fancy five-phase loader. This subsystem approach allowed embedding other systems—the only requirement (from a command language viewpoint) was that every subsystem had to recognize three control cards (4JOB, $ST0P, $IBSYS) and return control to IBSYS if they found these. Command Structure: Commands were fixed format, beginning with a $ in column 1 immediately followed by the command, and the parameters (if any) starting in column 16 with no imbedded blanks - the first blank terminated the parameter field. Note The processors in IBJOB also often required parameters in column 8. For example, to call in the Fortran IV Compiler, $IBFTC in column 1, deckname in column 8, and options in column 16. [The 1-8-16 format arises probably because this was the form used for punching assembler input, and therefore, changing drum cards on a keypunch to punch control cards was not necessary.] It is the only system th author has seen I/O associations (coupling) were where established by twc commands, which had to appear one after the other in the correct order. For example, SATTACH $AS established physical tape utility device 1.

A4 SYSUT1 drive

A4

as

system

24

MTS

(Michigan Terminal System)

Developed by Computing Center. Categorization:

Reference:

staff

of

the

University

of

Michigan

General Programming with some system development, batch and terminal, thirdgeneration.

MTS Manual second edition. Volumes I and II, University of Michigan Computing Center, December 1967; supplemented by about one hundred (each) CCNews items and CCMemos. [New edition of the manual currently under construction].

Runs on an IBM 360/67 one to four processor system. [The University of Michigan currently has a dual processor system ]. Command Structure: When in command mode, the user is either entering lines into a file or entering commands. If a line begins with a number, it is interpreted as a line number followed by a data line. If a line begins with a $, it is interpreted as a command. Otherwise it is interpreted as a command, unless automatic numbering mode is on, in which case it is assumed a data line. [The user may request (using a SNUMBER command) that instead of he having to put line numbers on the front of lines, the system should supply them. If this is on, the system prints the line number at the front of a line. This is called automatic numbering mode.] The user knows he's in command mode because he gets a pound sign (#) prefix character printed at the front of every line he inputs. In addition, output from the command interpreter (such as error comments) is also prefixed with a # so the user knows "who" is talking to him. Other prefix characters are used in other contexts. (the user can also turn the prefix character off if he's bothered by it). Command parameters are separated by blanks. Positional parameters are used for required parameters and when the command has less than three parameters. Keyword parameters are usually used for optional parameters. A command may be continued onto a following line by typing a hyphen (-) as the last character. The command may be broken anywhere; the first character of the next line is assumed to start where the hyphen was.

25

MULTICS Designed by Project MAC of MIT, General Electric, and (whilom) Bell Telephone Laboratories (Murray Hill). Runs on a GE645, which is a time-sharing version of the 635. GE645:GE635::IBM360/67:IBM360/65, approximately. Reference:

Multics System Programmers Manual, dating 1965 through 1966.

Categorization:

General Programming development, batch and generation.

section

BX,

with system terminal, third-

[Note - from documentation the author has it is not possible to tell if a batch, as opposed to foreground-initiatedbackground, facility is indeed there. ] Command Structure: A command is a sequence of elements separated by one or more blanks. The first element specifies the name of a procedure to be called. The values of the remaining elements are arguments to this procedure. A number of commands separated by semi-colons and terminated by a "new line" signal forms a command sequence. The elements of a command are either strings, literal strings, lists, or immediate value commands. A string is a sequence of characters excluding command delimiters. The value of a string is the string itself. For example, in DELETE NAYME1 NAYME1 is a string. A literal string is a sequence of characters inside left and right single guotes. Its value is the string excluding the two delimiting quotes. For example, % DELETE FILE ONE / A list is a sequence of elements (separated by blanks) inside parentheses. For example, ALPHA (NAME1 NAME2) Unlike most command languages, each "command" (being really a procedure call) returns a value. The value of one command may be used as one of the elements in another command. In this case the first is called "immediate value command", and is delimited by curly brackets. For example, A {B C} says to call B with C as an argument, and then use the result as the argument of a call on A. Commands may have labels, which are identifiers followed by a colon (:). Comments may appear before or after any element. They begin with a

26

double quote (") and end with a ", new line, or semi-colon. The escape character is the percent sign (%). It causes syntactic interpretation of the following character to be suppressed. There also exists a construct, called an interjected command, which is delimited by square brackets ([ ]) . This is similar to the immediate-value command, except that the pertinent data bases are not pushed and popped around its evaluation. There exists a macros facility which allows for storing away a set of commands under one name, and then invoking them by that name with substitution of parameters. (Further detail was not available).

27

OS IBM's Operating System for Sytem/360. Reference:

"IBM System/360 Operating System, Job Control Language", Form C28-6539-7, May 1968. [Reflects release 15/16 of OS]

Categorization:

General Programming, batch, third generationCommand Structure: The command structure of this system is the simplest of all the systems mentioned here. To the user there appear but three different commands and a delimiter. The commands are distinguished by having "//" appear in columns 1 and 2. A label field (optional usually) must begin in column 3. The command name is separated from the label by at least one blank. The operand field is separated from the command field by at least one blank, and is terminated by the first blank, after which comments may follow. The delimiter card, which acts as an "end of file" (end of data) indication in the source stream, has "/*" in the first two column and is otherwise blank. The three commands are JOB,EXEC, and DD. The JOB command signals the beginning of a job and, if it is not the first job in the input stream, the end of the preceding job. It contains identification and accounting information and may set some global quantities. The EXECute command signals the beginning of a job step and identifies the program to be executed or the cataloged procedure (a limited form of a command macro) to be used. It may also give conditions for bypassing or executing the job step, and pass control information to the invoked program. The DD (Data Definition) command describes a data set and requests the allocation of I/O resources. Various parameters identify the data set, give vclume and unit information and disposition, and describe the data set's labels and physical attributes. In addition, a card with "//*" in the first three columns is recognized as a comment card. With a few notable

exceptions,

all

parameters

28 are keyword parameters (a fixed name, followed by an equal sign, followed by a value. Eg: LRECL=80) so they may appear in any order. A statement may be continued from one card to the next by stopping on the first card just after a comma, optionally putting a non-blank character in column 72, and then continuing in column 16 of the following card, which must have // in columns 1 and 2.

29

PDP-10

Time-Sharing Monitors

The biggest monitor systems provided Equipment Corporation for their PDP-10. References:

by

Digital

"Time-Sharing Monitors: Multiprogramming Monitor (10/40), Swapping Monitor (10/50); Programmer's Reference Manual", DLC-10-MTE0-D, November 1968. "Batch Processor, Programmer's Reference Manual", DEC-10-MBAA-D, November 1967.

Categorization:

General Purpose, batch and terminal, second generation.

(Categorized as second generation in spite of its late date because of no adeguate file system and because its batch jobs are "second generation type" jobs as described earlier) [Caveat - the only contact with this system the had is the manufacturer's literature]

author

has

Command Strucure: This is the only system discussed here which has a different command structure for batch jobs than for terminal jobs. Terminal usage: Command names are alphabetic, and may have parameters, separated from the name by any non-alphanumeric chacter. A line from a terminal beginning with a semicolon (;) is ignored. In "monitor" mode, the system responds to a command with a carriage return, line feed, period; i.e., it responds with a period prefix character. Batch usage: When a job is run under control of the batch monitor, the programmer controls things through control "cards", which have a $ in column 1 immediately followed by the command. Parameters are separated from each other and the command name by blanks. The first card must be $J0B; the last one $EOJ (end of job). There are commands to run the assembler and Fortran Compiler: $MAC $CREF $F4. Upon hitting the end cf job ($E0J) or a $EOF card, all programs that have been loaded into core or have been compiled or assembled but still need to be loaded are loaded if necessary and execution is begun. There is, also, an explicit $RUN command. There is no explicit conditional structure to allow controlled conditional execution.

30

SCOPE Monitor systems provided by Control Data Corporation for their large machines. Drum Scope for the 3x00 series machines and Scope 3 for the 6x00 series machines. References: "Drum Scope Manual", number 60 05920 0 "Scope 3 Reference Manual", number December 1968

60189400,

Categorization: General Purpose, batch, third generation (Scope 3) [Actually, Scope 3 probably fits at about a 2.7 generation system] Command Structure: Although presented under one heading, there is a difference in the command languages of the two Scope systems. Drum Scope for 3x00 machines: This system resembles IBSYS a great deal. It is subsystem oriented. Control cards are distinguished by having a 7-9 punch in column 1. Scope 3 for 6x00 machines: The first card must be a JOB card. From there to the first card with 7-8-9 punches in column 1 is the first segment and contains all control cards for the job. Other segments may follow, each terminated by a 7-8-9 card. These contain programs, data, etc., that the control cards work on. A 6-7-8-9 card terminates the job. Control cards start with the command name. Separated from that with any non-alphanumeric (except *) is an optional second field. The command must be terminated with a period (sometimes a right parenthesis). There is a very limited conditional structure: normally, when an "EXIT." command is hit, the job terminates. If an error occurs during a job, control cards are skipped up to the first card following an "EXIT." card (if there is one) .

31

SDS 940 Time-sharing system produced by the University of California at Berkeley for a modified SDS930, which became the SDS940. Maintenance and expansion of the original system has been taken over by CCM-SHARE. References:

Various documents issued by contract SD-185, ARPA, 1965.

Project

Genie,

Categorization: General Purpose, terminal, third generation. Command Structure: This system was built to use full-duplex teletypes, and the original command language was oriented around character-by-character interaction between the user and the computer. The user had to type only the minimum number of characters to specify the command. At this point the system would take over and finish printing the full command name, and then wait for the user to enter a period to say "do it". A description of the fancy context editor is given in Deu 67. The system consisted of a number of subsystems. Each subsystem was assigned a "prefix character" which it printed at the front of every line sent to or from the terminal, in order to identify the subsystem.

32

TSS IBM's official system for the System/360 model 67. Reference: "IBM System/360 Time Sharing System, Command System User's Guide", form C28-2001-3, November 1968. [Reflects version 4 modification 0 of TSS] Categorization:

General Programming development, batch generation.

This describes Command command language.

System

with some system and terminal, third II, not

the

original

Command Structure: A command consists of a command name and an optional operand field separated from the command name by at least one blank. The operand field consists of one or more operands, delimited by commas. For any given command, each operand has both a position and a name, and may be specified as a positional parameter or, using the name, as a keyword parameter. More than one command may be written on a line by separating them with semi-colons. Command macros (which produce combinations of commands) may be set up using the PROCDEF command. A new command can be created from assembly language object code using the BUILTIN ccmmand.

33

UMES System produced by the University of Michigan Computing Center for the IBM 7090 computer. Of historical interest. Reference:

"University of Michigan Executive volumes I and II, September 1966.

Categorization:

System",

Gerneral Purpose, batch, second generation.

This system was designed to provide high-speed processing of short jobs, and to be easy to use.

batch

Command Structure: A command started with a $ in column 1. Ccmmand "items" could be placed on separate cards, or grouped more than one to a card, separated by commas. Blanks were ignored. Every group of control cards had to have exactly one item that was the "verb" - specified what was to be done. (e.g., COMPILE MAD)

34

CRITERIA FOR COMMAND LANGUAGES This section mentions a number of criteria that should be used in in constructing command languages. The order they are presented in is not supposed to reflect en their importance.

SIMPLICITY The criterion of simplicity means that the average job should require the minimum of command language. This is particularly true when the envisioned usage is by "users" rather than "programmers". That is, the main usage will be by people whose profession is not computing. Such usage occurs, for example, at university computing centers. This lack of simplicity is one of the problems that plagues OS. If what is to be done is simple and there is a "cataloged procedure" (a prepackaged set of commands similar to a macro) available for this task, it is not too bad. For example, a minimum Fortran job to compile and execute a program might be //JNAME JOB XXXX,'A. USER',MSGLEVEL=1 // EXEC FORTGCLG //FORT.SYSIN DD * { Fortran program goes here } /*

//GO.SYSIN DD * { data goes here } /*

But when one wishes to do something slightly different - use a tape for example - the number of commands proliferates, since it is generally not feasible to use a cataloged procedure. The size of each command increases also. The following example of a command to create a cataloged data set is quoted directly from an example in the "Fortran IV (G) Programmer's Guide", form C28-6639-0 (p.40) without comment. //FT31F001 DD DSNAME=MATRIX,EISF=(NEW,CATLG) , // LABEL=(,SL,EXPDT=67031),UNIT=DACLASS, // V0LUME=(PRIVATE,RETAIN,SER=AA69), // SPACE=(300, (100,100) , ,CONTIG,ROUND) , // DCB=(RECFM=VB,IRECL=604,BLKSIZE=1212) In MTS, the same minimum fortran job would be $SIGNON USER $RUN *F0RTRAN { Fortran program ]

35

$ENDFILE $RUN -LOAD# ( data }

SYMMETRY AND UNIFORMITY In the first There are a number of aspects of this. place, the syntax of the command language should be uniform for all commands. For example, a command could be an alphanumeric command name followed by parameters, all separated from each ether by one or more blanks. Note, however, that in many cases it is desirable to supplement this with alternative notation which appears "more natural". For example, in MTS, to number lines by 10 starting by 100, the "official" syntax requires $NUM 100 10 but it is also acceptable to with a comma.

separate

the

two

parameters

The second point is really the concern of the system underneath the command language, rather than the command language itself. It is that the semantics should be symmetric also. If a system has several data types, and there is a copy command, then the command should work on all the data types, for example.

CONCISENESS AND BREVITY This is perhaps one of the most important criteria. It is certainly one that has created a lot of argument. There are really two facets: what the user has to say to the system, and what the system has to say to the user. Considering input from the user to the system, it is generally very annoying to have to type a large number of characters, especially since the more that has to be typed, the more likely the user will make a typographical mistake. This is less annoying to batch users than terminal users, since a batch user is more likely to make up a set of control cards and reuse them several times - hence he need get them right only once - whereas the terminal user will type them afresh each time he needs them. Considering output from the system to the user, the batch user in general does not care how verbose the system is. The terminal user, however, who has to watch it typing across his paper at ten characters a second is very touchy about the system printing more than he wants. The beginning

36

user, or even an experienced user using something he hasn't The used before, wants full, detailed error comments. experienced user, however, "knows" the error comments, and he just needs a brief indication of which error it was, or in some cases, just an indication that an error occurred. Various systems have chosen various solutions to this In CPS (Conversational Programming System - see dilemma. [ CPS ]) , if the system detects an error it just prints an exclamation point. If, when the user tries a second time, he makes the same mistake, then an error comment is printed. In another system (TSS), the user can set dynamically the brevity level he wishes for error messages. (he can also set an acceptance level to determine if he gets any message at all). If he sets it to "short" and then doesn't understand a later cryptic comment, he can use the "explain" command to get a full description of the error.

EASE OF READING In contrast to the preceding criterion, it should be noted that as what the user types in gets shorter and shorter, it usually gets more and more cryptic. It is necessary, however, to have a "readable" command language so that when a user looks at a ccmmand he has just typed he can catch mistakes he might have made, and so that when he looks at it in the future he can understand what he was doing. Unfortunately, in order to increase readability and error detection, it is necessary to increase redundancy, and hence the number of characters that have to be typed increases. For example, keyword parameters are better in this respect than positional parameters, since each parameter has a name on the front of it, but this name takes up space: "LRECL=80" versus just "60", for example. There are some things that can be done without increasing ccmmand length. The names of commands and library programs can be chosen to be mnemonic (FORTRANH is more understandable than IEKAA00). In addition, the names should not sound too much alike. For example, the TSS context editor has the commands CONTEXT, CORRECT, REVISE, UPDATE, EXCERPT, all of which sound as though they do the same sort of thing, and unless one is using them all constantly, it is very difficult to remember which does what.

ERROR DETECTION AND PREVENTION The command language, and hence the computer, of course does exactly what it is told. But since the user of a command language is usually human, he has a tendancy to say

37

something other than what he meant. One of the most important aspects of a command language is that it provide tne user protection from himself - that is, the command language should be so constructed as to minimize the user accidently doing damage to himself. Part of this protection can be achieved by giving the user information about what is happening. One of the more valuable pieces of information is what "environment" he's in, so he knows when he inputs a line how it will be interpreted and so he knows when a line is output to him "who is talking". This is done by printing a prefix character at the front of every line sent to or from the terminal. A different character is used for each environment. This feature was first seen by the author in the SDS940 system. That system is heavily sub-system oriented, and a different prefix character is used for ' each subsystem. Since then, a number of systems has used this idea to varying degrees. TSS, for example, uses only one: an underscore to indicate command mode. MTS, on the other nand, uses several: # ? > blank

command mode Response to prompting copy mode dynamic loader user's program

A user's program can call a subroutine to set a prefix character if it wishes. Several system programs do this: + : %

symbolic debugging system context editor - command mode context editor - input mode

It should be noted that before the context editor started using two separate prefix characters, a very ccmmon mistake was to enter "high-speed input" mode to insert a few lines, and then begin entering commands, forgetting that this was input mode and that these "commands" were just going into the file. Another aspect of protection is that "drastic" things should be done by the system only on explicit command from the user, not implicitly because ofsomething else he has done. Such things as creating, emptying, and destroying files all fit in this category. Seme systems create a file for a user if he uses a name that doesn't already exist. This is sometimes nice, but often when someone uses a name as though it exists, it means he misspelled the name of one that does exist. In this case, the error comment that a file of that name does not exist is what is wanted. In MTS, a compromise is made. Permanent files! must be explicitly created by the user, whereas temporary! files that exist only for the life of this session are created when they are first

38

referred to. [ A temporary file is denoted by the first character of its name being a minus sign ] Emptying and destroying files are "drastic" steps that the user should not be able to cause inadvertently. As an example of bad design, in CMS the user must explicitly create a file with a command (that's ok) . But if a file by that name already exists, the original one is automatically destroyed. In MTS, on the other hand, the system is more protectionistic than most. When a user issues a 5DESTR0Y (or $EMPTY) command, the system responds with: FILE "ABCDE" IS TO BE DESTROYED.

PLEASE CONFIRM

and requires that the user give positive confirmation before doing it. Again, since this procedure is somewhat annoying, it is done only for permanent files. Temporary files are emptied and destroyed upon command without requiring confirmation. An interesting design exists in the SCOPE 3 (for CDC 6x00 machines) system. In that system a file is created whenever it is first mentioned - i.e., implicitly - but what is created is a temporary file that will be destroyed at the end of the job. If the user wishes to keep the file, he must convert it into a permanent file with an explicit command: COMMON ABCD. If in a later job he wishes to destroy the file, he says RELEASE ABCD. This changes it back into a temporary file, and it will be destroyed at the end of the job. Note that if the system was a terminal system, then this method of "destroying" a file is retractable, up to the time of signoff.

EXTENSIBILITY AND FLEXIBILITY A command language cannot and should not provide everything that a user might want, but it should provide him with the ability to put together things to do what he wants. To this end various tools are provided by various systems. Several systems provide a macro facility by which a set of commands are grouped together under one name. When the name is used as a "command" name to invoke the expansion of the commands, parameters may be supplied which are substituted in the commands being expanded. The PROCDEF facility in TSS is an example of this, jand the cataloged procedure in OS is a limited form of this. |

39

Many systems provide a means for a user to set what he wants for default options. For instance, whether he wants "warning" messages, or just "error" messages at his terminal. These defaults may either be set just for the duration of the session or else may be made "permanent" which means they will also be active for future sessions until reset. These facilities are exemplified by the OPTION command in Multics, and the DEFAULT and PROFILE commands in TSS. In addition, at least one system (TSS) allows users to specify synonyms for ccmmand names, so the user can effectively rename and abbreviate commands as he wishes.

REASSURANCE This criterion is not as important as it was in earlier days when hardware was very flaky and software very slow. But it is still good to let the user know he was heard when he enters a command. This means that every command should have some response. If there is nothing to tell the user and the system has prefix characters, then the prefix character for the following command is enough. If the command is something that may take a while to accomplish, such as a command to run (i.e., load and begin execution) a user's program, then some immediate response is a good idea. In MTS, the message "EXECUTION BEGINS" is printed in response to a $RUN command, at the point when loading is complete and just before execution is beginning. This also tells him that any abnormal termination message (such as PROGRAM INTERRUPT) between that point and the point the "EXECUTION TERMINATED" message appears is due to his program, and is not a malfunction in the system.

40

RECONCILIATION CF_ CRITERIA, It has teen clear in the previous discussion of criteria that they were often contradictory. What should, then, a command language look like? The base language, that a beginning user gets when he first communicates with the system, should he slanted toward the novice. This means that it should appear simple, and that defaults for all The system cases should be chosen for beginner's jobs. should be very extensible and flexible, however, so that as the user gets more experienced, he can set defaults for himself to be the way he wants then. Note that what he wants will certainly vary over time as he gains experience. In the beginning, the system should be very protective. But this should be overrideable, so that as the user becomes more aware of "how things happen" he can do what he wants. As an example of a similar philosophy, the following quotation from the epilogue of McKeehan's paper on the TSS Command System II [McK 68] is offered: "The entire thrust of the foregoing schemes has been to provide a well-defined structure for the user while allowing him to control his environment. There have been no assumptions made about the kinds of useful work the user may wish to accomplish. Such assumptions are dangerous and narrowing. There is every indication that, as in all preceding systems, the pattern of usage will grow and change as users begin to really investigate the interactive system. Since this is the case, the system must be prepared to adapt to the new applications. "Yet the system must not be so loosely defined that simple tilings cannot be done simply. It is imperative that the system be able to make inferences about the user's wishes. The system must never be at a loss as to what to do next. There should be no action that is barred to the user or that leads the system into omphaloskepsis. "Many systems in the past have exhibited a high degree of overprotection. The user was forbidden to do things on the basis that 'he had no need to do that' or that he might damage his environment. This kindergarten approach must be a part of the past, and users must be presumed to be willing to accept the consequences of their own actions."

SYSTEM DESIGN It should be noted in passing that since the command language is the user's "window" to the system, it cannot be really independent of the system. It does no good to produce a beautiful command language if the system behind it

41 i

I is no good. This is essentially a plea to system designers and implementcrs tc provide something, that a decent command \language can be produced for.

COMMAND NAMES Names of commands should be chosen to be relatively mnemonic. That is, they should be a description of what the command does. Perhaps even more important, the commands should be distinguishable. Unfortunately, the more commands a language has, the more important it is to be able to keep then separate, and the harder it is. For example, in file editing, if you said CORRECT when you should have said REVISE all sorts of strange things might happen to the file that was being edited. Or even worse, by misspelling or misstating a command you might invoke another command you didn't even know existed. This is one of the problems Multics has, since whaterver name is given, it will try to load a program cf that name.

ABBREVIATIONS Following the criterion of brevity, most terminal command systems allow abbreviation cf commands. Several schemes are in use. Some systems require only the first few letters of a command name. BASIC, for example, requires only the first three letters, although as many more as wished may be given. (i.e., the first three letters of a command name are unique, and serve to identify the the command.) This was also the method of abbreviation in MTS until a month ago. The following method (also used in CMS) is now used: The user needs to specify only the number of characters of command name which serve to uniquely identify that command. In the case of commands with the same leading characters, the more commonly used command is assigned the shorter abbreviation. Thus "L" means "LIST" and "LO" means "LOAD". Note that this method is compatible with the previous method. If the user does not remember which of the commands beginning with a given letter has which minimum abbreviation, he can always give the first three (as he used to) and be safe. In Multics, the abbreviation for a command is a three letter abbreviation formed from the first letter, the next consonant, and the last consonant of the descriptive name [MSPM BX.0.01]. In TSS, there are no built-in abbreviations, but the user may establish any abbreviation he wants using the SYNONYM command.

42

PARAMETER TYPES There are two types of parameters used in command languages: positional parameters and keyword parameters. A positional parameter is specified by giving only the value of the parameter. It is called "positional" because its position in a command is used to determine which parameter Thus, if copy command requires two file is being given. names as positional parameters, then COPY ALPHA BETA specifies that EETA is the file to be copied into by means of its position in the command line (i.e., it's the second name). A keyword parameter, on the other hand, is specified by giving the name of the parameter, an equal sign, and then the value of the parameter. Since the name is always attached, the order of the parameters does not matter. If the copy command used keyword parameters, then the two following would be equivalent: COPY j?ROMFILE=ALPHA TOFILE=BETA COPY TOFILE=BETA FROMFILE=ALPHA In general, positional parameters are used when there are one or two parameters on a command, because there is less to type. If there are many parameters, keyword parameters are usually used because it is difficult to remember what order positional parameters come in. The old command language for TSS suffered from this difficulty; the command to run Fortran had about a dozen positional parameters. One had to type things like PROGA,N,,,,,,,,,Y more or less, and the problem was that it was usually either more or less that one should have typed. If there are many optional parameters on a command, and only a few are usually used on any given command, keyword parameters are almost always used. Most command systems use keyword parameters in some spots, and positional parameters in others, according to the above criteria. Other systems stick to one or the other. OS, for example, uses all keyword parameters (with the exception of twc mandatory fields on the JOB card and a few CMS uses all positional constructs on the DD card). parameters, separated by blanks, and uses an asterisk (*) to indicate an "omitted" positional parameter. TSS, on the other hand, allows the the user to use either. Every command parameter has both a name and a position, and the user may use either positional or keyword as he prefers.

44

i

REFERENCES

These are the references for the bracketed reference items. References given in the section
Arden, B. W., "Time-Sharing Systems: A Review", 1967 IEEE International Convention Record, volume 15, part 10: "Computers, Education, Information Retrieval", pp.23-35

[Ber 69]

Berry, Paul, APL.N 360 form C20-1702

[Cam 69]

[Car 76] [CPS

Primer,.

IBM

Campbell, John W, Jr., "The (editorial), ANALCGX LXXXIII 1969 Carroll, Lewis, The Hunting Agony, in Eight Fits

of

publication Simple Way" no. 4, June

the

Snark;

An

]

Conversational Programming System, program number 360D-03.4.016 (Type III), available from IBM.

[Deu 67]

Deutsch, L. Peter and Butler W. Lampson, "An Online Editor", Communications of the ACM, 10, December 1967, p.793

[ Ive 62]

Iverson, Kenneth Wiley, 1962

[McK 68]

McKeehan, J. B., "An Analysis of the TSS/360 Command System II", SDD Technical Report TR53.0002, October 28, 1968, IBM Systems Development Division, Time Sharing Department, Mohansic Laboratory, Yorktown Heights, New York.

[MSPM

Multics System Programmer's Manual. date from 1965 through 1968.

]

E., A

Programming

Language,

Sections

[Nau 63]

Naur, P., editor, "Revised Report on the Algorithmic Language ALGOL 60", Communications of the ACM 6 (1963), pp.1-17.

[Ros 69]

Rosin, Robert F., "Supervisory and Monitor Systems", Computing Surveys (ACM), 1, no. 1, March 1969.

\

43

UNIVERSALITIES Being unable to resist opening his mouth whenever he sees his foot approaching, the author would like to terminate this discussion by supplying the following "universal truths" of computing that apply to this topic. The name in parentheses is the person the author associates it with. Bind your variables as late as possible. (Galler) Defaults should not be built into the system, they should be changable at system load time. Defaults should not be fixed at system load time, they should be changeable anytime. One man's constant is another man's variable. (Perlis) There should net be one default for all users, but each user should have his own independent and independently settable one. The Law of Least Astonishment. A command should do what you would logically expect it to.