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
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.
(Job Control) Languages for General Purpose Computing Systems
There was a problem previewing this document. Retrying... Download. Connect more ... Command (Job Control) Languages for General Purpose ... puting Systems - Donald W. Boettner - June 1969.pdf. Command (Job Control) Languages for ...
Nov 20, 2003 - maintaining the data needed, and completing and reviewing the collection of .... Time Dependence of Spore Kill. N. 0 ... Retention time (min). 1.
Oct 2, 2012 - The disclosed system provides a functional programming. Gâ 0;' F /44 ... shop on Implementation and Application of Functional Languages.
Oct 2, 2012 - The only data types supported are Booleans, reals, pairs, and procedures. ..... the ?ow-analysis techniques used in our compiler. Section.
systems, has negative implications for an entire class of security mechanisms: those that seek to prevent malicious ... understood that WâX is not foolproof [Solar Designer 1997; Krahmer 2005; McDonald. 1999], it was thought to be a ..... The remai
Electrical Characteristics TA = 25°C unless otherwise noted. 2001 Fairchild ... R. S. E. C. U. R. R. EN. T ( A. ) T = 25 C. º. J. T = 150 C. º. J. T = 100 C. º. J. µµµµ ...
What is the programming level for achieving ... High performance at the cost of programming effort and portability ... design automation techniques enable.
authors, functional programs with collection data is a rich source ... ventional garbage collection (GC) methods, which are inherently .... for big data processing.
Oct 11, 2004 - No liability will be accepted by the publisher for any consequence of its use. Publication thereof does not convey nor imply any license under patent- or other industrial or intellectual property rights. Philips Semiconductors â a wo
Because the number of possible ways to map ... been developed in the fields of record linkage [Fellegi and .... ifies a mapping from argument tuples to values.
We then briefly review the BLOG language of [Milch et al., 2005a]. Sec. .... 24 then ~ AuthJoinModel. 25. (NthAuthorText(c, n),. 26. AuthListSuffix(c, Succ(n))). 27.
Maximum Full Load Reverse Current, Full Cycle. TA = 75°C. 30. µA. C ... systems which, (a) are intended for surgical implant into the body, or (b) support or ...
implementation of a real-time H.264 decoder on general-purpose processors with ... single-instruction-multiple-data (SIMD) execution model was introduced in Intel ... and yield a much better perceptual quality for the decoded video stream.
IJRIT International Journal of Research in Information Technology, Volume 1, Issue .... And based upon these three things that is, IP (Intended purpose/purpose ...
Page 3 of 4. Control Systems Lab.pdf. Control Systems Lab.pdf. Open. Extract. Open with. Sign In. Main menu. Displaying Control Systems Lab.pdf. Page 1 of 4.