Part 2 of 10 of the COMTRAN Language Definition.

2. Overall program structure and procedure organisation

This section defines what a complete COMTRAN (Commercial Translator) program is: its three descriptions (divisions), the physical source-deck structure that delivers them to the processor, the expression → clause → sentence → section hierarchy of the procedure text, procedure-names and sectioning, the default flow of control, and the full verb inventory divided into program verbs and processor verbs. F28-8043 (June 1960) gives the language design; J28-6169-1 (Jan 1962) is authoritative for the implemented 709/7090 language. Divergences are flagged inline.

2.1 The three descriptions (divisions) of a complete program

"All Commercial Translator programs are composed of three divisions, the Procedure Description, the Data Description, and the Environment Description. The first of these contains the procedure statements of which the program is composed. The second provides the processor with information about the data to be used in the object program. The third is used to make certain technical connections between the program and the machine system on which it will be run" (F p. 26). Informally, "A Commercial Translator program consists primarily of procedure description and data description" (F p. 16); the environment description is machine-dependent and in 1960 was deferred to the individual processor publications (F p. 26). For the 709/7090, the compiler "analyzes Commercial Translator Data, Procedure and Environment Descriptions and CRYPT symbolic machine language instructions and produces a relative binary object program deck" (J 02.00).

Division roles, in brief:

Key architectural principles the manuals state explicitly:

• The procedure description is machine-independent; the data description "is not entirely machine independent" (F p. 3). The environment description exists precisely so that machine-dependent factors "may usually be changed without affecting the logical description of the problem, as contained in the Procedure and Data Description parts" (J 02.06.01.01).
• Separation of procedure and data descriptions is deliberate: either may be changed without modifying the other (F p. 3).
• Every data-name and condition-name used in the procedure description "must be properly accounted for in the data description" (F p. 16). J restates and hardens this: "The name of each data field referenced in Procedure statements or Environment Descriptions must appear in the name field of a Data Description entry. Neither storage allocation nor assignment of data characteristics is made for data fields not so named" (J 02.05.01).

Division headers and interleaving

"It is not necessary that these three divisions appear as separate entities. If appropriate, the programmer may write a portion of one, then a portion of another, and so on. However, each such portion must be properly labeled with a division header. Each header consists of the name of the division, preceded by an asterisk" (F p. 27). The three headers are, verbatim:

*PROCEDURE
*DATA
*ENVIRONMENT

(F p. 27)

• Headers are written "in the 'name margin' of the form used for the procedure description ... or in the name columns of the form used for the data description. In other words, the asterisk always appears in the left-most name column, followed immediately by the remainder of the header" (F p. 27). Division headers must begin with single asterisks (F p. 28, punctuation rule 12).
• "All entries following a division header are assumed to be a part of the specified division" (F p. 27).
• "The procedure header, *PROCEDURE, is a special name that must appear on a separate line preceding each procedural portion of a source program to distinguish it from data description or environment description" (F p. 37).

F/J divergence / confirmation: J never restates the interleaving rule, but its diagnostic list presupposes it: compiler message 87,00 reads PROBABLE PROGRAM CONTINUITY ERROR. PROGRAM FLOWS INTO *DATA. (J 90.04.01), which can only arise if a *DATA portion may physically follow procedure text. The compiled sample program uses one portion of each division in the order *DATA, *ENVIRONMENT, *PROCEDURE (J 90.05, listing PDF pp. 192–197); treat that as the canonical ordering, with interleaving permitted (see Ambiguity register). Within the environment division, "The SPECIF card(s) may appear anywhere within the environment division" (J 02.06.07).

CRYPT (709/7090 symbolic machine language) portions may additionally be embedded "at any logical point in his program" via ENTER CRYPT, terminated by ENTER COMMERCIAL TRANSLATOR (J 02.08.01, 02.08.03); see §2.7 under ENTER.

2.2 Source deck structure: how a program reaches the compiler

Source programs are read "in the form of a deck of punched cards or their equivalent on tape; each line of the programming form becomes one card in the source program deck" (F p. 37).

2.2.1 The $CMPLE card

"A $CMPLE card must precede each source language program. It is recognized by the Commercial Translator Monitor (CTM) for purposes of operational control and interpreted by the Commercial Translator compiler to initiate processing of source language statements" (J 02.01.01). Its general form, verbatim:

1  -  6      8  -  13       16
$CMPLE       deck.name      [NODECK]        [,LIST]         [,DICT]
                            [,LOAD]         [,LOGIC]        [,FILES]
                            [,MAP]          [,NOGO]

             55        -        72
             [secondary.identifier]

(J 02.01.01)

Rules a compiler writer needs:

• deck.name is "the primary deck identifier composed of six or less characters chosen from the set appropriate for use in CT names. The name may begin in any of the positions but must not include imbedded blanks. Leading blanks are ignored by the compiler" (J 02.01.01). The complete deck.name is punched in columns 1-6 of all Loader symbolic control cards in the object deck (J 02.01.01). Caution: "The Compiler accepts without comment a deck.name containing imbedded blanks and punches it in Loader symbolic control cards. A deck.name of this form is not acceptable to the Loader and will prevent execution of the object program" (J 90.01.05).
• "The options used must not be separated by blanks as the first blank terminates the list of options. The options must be separated only by commas" (J 02.01.01).
• Option meanings (compile-time behaviour, summarized): NODECK: omit punching the object deck (a deck is also suppressed automatically when a severity-5 error occurs); LIST: symbolic listing of generated instructions; DICT: list the dictionary of relative locations of all names; LOAD: write object program on a utility tape and pass control to the Loader (execution suppressed if NOGO taken, or a source error of severity code greater than 1, or an undefined generated symbol); LOGIC: Loader lists origin/extent of "all program sections", system subroutines and buffer assignments (implies LOAD); FILES: list I/O unit assignments; MAP: "an option yet to be specified"; NOGO: load but do not execute (J 02.01.01–02.01.02).
• secondary.identifier (cols 55–72, any characters) is printed in the output-listing heading and punched into the *CTEND Loader card (J 02.01.02).

2.2.2 The *FINISH card and end-of-file

"The *FINISH card delimits the extent of the source language statements to be compiled. The form of the card is:"

7
*FINISH

"Note that this card must be followed by an end of file" (J 02.01.02, referring to J 04.02 and 05.03). "Each Commercial Translator job must be followed by an end-of-file" (J 04.02.01). The end-of-file card "should be thought of as an integral part of every job deck" (J 05.03.01, which gives its physical punch format — operator-procedure detail outside this definition's scope). A missing *FINISH is diagnosed: 132,00 END OF FILE ON JOB TAPE WITHOUT *FINISH CARD. (J 90.04.01).

A complete compile job deck on the system input, from the manual's own stacked-input example (J 05.03.02):

$ID            JOB1                Accounting card is optional
$CMPLE
                BCD
                Source
                Program
                Cards
        *FINISH                    This card precedes end-of-file on COMPILE jobs.
End-of-file-card

(J 05.03.02; $ID is optional. The "Source Program Cards" are the division portions of §2.1, each introduced by its division header.)

If the object program itself reads SYSIN, "the input cards must be placed in a separate file immediately following the job to be run" (J 05.03.01).

2.2.3 Compiler output (as it reveals source structure)

Normal output is a relocatable column-binary deck: Symbolic Control cards, *CTEXT, Relative Binary Program Deck (Control Break Table, File Check Table, Text), *CTEND (J 02.02; deck format in Appendix 90.03 — see the object-deck section of this reference). Note the 90.01 deferrals: no control break table and no file check table are actually punched (J 90.01.04). The list tape carries the source listing with, per line: (a) source card sequence number; (b) "statement number assigned by the Compiler to the Procedure sentence, Data Description entry or Environment card. It is of the form xxxxx,00"; (c) card body, columns 7–72, in which "In some cases, names generated by the Compiler, i.e., GN)nnn, are shown in the name field of Procedure statements or Data entries unnamed by the programmer" (J 02.02). Statement numbers have three to six digits; "The last two are separated from the preceding digit(s) by a comma and they tell which clause is being referenced. The digit(s) preceding the comma tell which line is being referenced. The statement number 9999,99 is an exception. It is used to reference errors which are not confined to a single source statement" (J 02.02). This confirms that the compiler tracks structure to the granularity of individual clauses within a sentence.

2.2.4 The procedure coding form (card columns)

The procedure description is written "in 'free-form' text on a programming form ... it has just four fields" (F p. 37):

F/J divergence (sequence checking): F states the Ctl./Serial information "will be sequence-checked by the processor" (F p. 37); J states flatly "Card serial numbers in columns 1-6 of source decks are not sequence checked by the compiler" (J 02.03.01). J governs.

Line-placement rules for text (F p. 37, verbatim in substance):

1. "A named sentence follows its name. That is, it begins to the right of the name margin, on the same line as its name."
2. "An unnamed sentence must begin on a separate line and to the right of the name margin."
3. "Succeeding lines of a sentence must begin to the right of the name margin. (If desired, they may be indented to facilitate reading the text.)"
4. "When a section of procedure is begun, only the BEGIN SECTION command may appear on the same line as the name of the section."
5. "To end a section, the command 'END section.name' is written as a sentence, i.e., on a separate line."

Continuation and break-point rules (J 02.03.01):

• Data and Environment entries needing more than one card put "a non-blank character in column 72" to signal continuation; "Continuation of Procedure text on successive lines is determined by the nature of the text; no continuation character is used."
• "In all sections each word or literal must be complete upon a line since the processor assumes a blank following column 72 of Procedure lines and replaces the contents of column 72 with a blank in Data and Environment lines." (F states the equivalent rule: "a blank is assumed to follow Column 72 of the procedure description form and Column 71 of the data description form", F p. 28; the same behaviour, not a divergence: the data form's text ends at column 71 because column 72 is its continuation-indication column (F p. 66), so F's "blank after column 71" and J's "column 72 replaced with a blank" describe the same rule.) The 7090 processor tolerates Data Description literals continued across lines in violation of the F rules, but "Use of this characteristic of the 7090 processor should not be made if compatibility with other processors is desired" (J 02.03.01).
• Only the name and description fields of Data Description entries may be continued; "All other specifications to be made for an entry must be made on the first card of that entry since these fields are not scanned on continuation cards" (J 02.03.01). Imbedded and leading blanks in continued name fields are eliminated and the characters compressed into a single name (J 02.03.01).

Statement/entry termination (J 02.03.01–02.03.02):

• "Procedure statements are terminated by the first period (.) followed by a blank. Any information following this period blank is considered to be commentary." (No diagnostic is issued for such commentary: J 90.01.03.)
• "Data and Environment entries are considered complete when column 72 is blank. The period (.) must not be used to signal completion. In these sections, a period is considered part of the previous word, thus creating an undefined name." The same applies to Environment specifications: "A period (.) must not be used to signal the end of a specification" (J 02.06.02).

For files read from the on-line card reader, "only columns 1 through 72 are read" (J 02.06.04), relevant to object-time data, not source decks, but stated on the Environment FILE card.

2.3 The structural hierarchy: expressions → clauses → sentences → sections → divisions

The language "may be helpful to think of ... as existing on two different levels": the elements (characters, fixed words, punctuation, names, literals; see the language-elements section of this reference) and the syntax, "how to fit elements together properly" (F p. 7).

Expressions

"[O]ne basic structural building block is an expression; this is defined as any grouping of elements which always establishes a unique value. An arithmetic expression can take on any numeric value whereas a conditional expression may only be true or false" (F p. 7). Expressions are components of clauses; their formation rules (operators, relations, AND/OR/NOT, truth functions, subscripts, functions) are covered in the expressions section of this reference (F pp. 20–24; operator hierarchy J 02.04.05.01).

Clauses

"Sentences ... are composed of one or more shorter units, known as clauses. There are two kinds of clauses: imperative and conditional" (F p. 24).

• Imperative clause: "a group of words that expresses a complete command. ... It always begins with a verb and may contain one or more operands of the verb" (F p. 25). Operands may be data-names, procedure-names, condition-names, literals, figurative constants, and arithmetic expressions (F p. 25). "Commands are independent clauses which may stand alone" (F p. 7). A command "normally consists of a verb followed by one or more operands and may be written as an imperative clause or as a sentence" (F p. 35).
• Conditional clause: "consists of a conditional expression introduced by the word IF and terminated by the word THEN. ... The word THEN defines the limit of the conditional expression to be tested; it will always be followed by an imperative clause" (F p. 25). "Conditional clauses are dependent clauses and must always be followed by at least one command" (F p. 8).

Sentences

"A Commercial Translator sentence ... expresses a complete and independent thought. It must contain at least one imperative clause and may contain, in addition, one conditional clause and one or more additional imperative clauses. It is terminated by a period, which must be followed by a blank ... Imperative clauses within the same sentence must be separated by commas" (F p. 25).

Structural/punctuation semantics of the sentence:

• "When a conditional clause is used in a sentence, it must begin the sentence, and it must be followed by one or more imperative clauses to be executed if the prescribed condition is met" (F p. 25). At most one conditional clause per sentence (F p. 25).
• Alternative action: the word OTHERWISE (written "without intervening punctuation") followed by one or more imperative clauses; "If the conditional expression should prove false, and if the sentence does not contain the word OTHERWISE, the conditional sentence will cause no action and the system will proceed to the next sentence in the program" (F p. 25; also F p. 7).
• The terminating period must be followed by a blank "to distinguish it from the 'imbedded period' used in names and from the decimal point used in numeric literals" (F p. 25). "Should the blank be omitted, the period will be treated as an 'imbedded period,' except where the period is found in Column 72 of the procedure description form" (F p. 27, rule 3 — because a blank is assumed after column 72, F p. 28 rule 14).
• The imbedded period (a period surrounded by non-blank characters) is a decimal point in an all-numeral word or floating point number, and otherwise (outside literals) "the equivalent of a hyphen" joining parts of a simple name (F p. 27, rule 4).
• "Successive imperative clauses in a sentence must be separated by single commas"; extra blanks are permitted but ignored (F p. 27, rule 5). Multiple blanks are treated as single blanks except inside alphameric literals (F p. 12, p. 27 rule 2). All words are separated by blanks or by any character that cannot legally appear in a word (F p. 27, rule 1).
• J diagnostics enforce sentence structure: an unterminated card yields 62,00 PREVIOUS CARD NOT PROPERLY TERMINATED. PERIOD ASSUMED.; a statement without a proper verb, or with more than one verb where one is expected, is deleted from text (125,00; 126,00); an incomplete statement is deleted (122,00) (J 90.04.01).

Sample sentences (F p. 25):

ADD 1 TO COUNTER.
GO TO TAX.CALCULATION.
STOP.
IF MARRIED THEN MOVE NAME TO MAILING.LIST.M,
    ADD 1 TO COUNTER.
IF GROSS.PAY LT NET.PAY THEN GO TO ERROR.ROUTINE.
IF OUT.OF.ZONE THEN DO BILLING.ROUTINE.A OTHERWISE
    DO BILLING.ROUTINE.B.

Sections and divisions

Sections group successive sentences under one name (§2.5); divisions are the three descriptions (§2.1). "Sentences are not grouped into sections for the purpose of clarifying the logic or the structure of the program for the benefit of the system ... Sectioning, in the Commercial Translator, is used for the purpose of naming portions of procedure" (F p. 26).

2.4 Procedure-names: how statements are labeled

"Procedure-names are names assigned to individual portions of the program so that one procedure can refer to another" (F p. 14). "Procedure-names may be assigned to any sentence or section of the program. (A section consists of one or more successive sentences.) ... Procedure-names may also be referred to as sentence-names or section-names, as appropriate" (F p. 14). "A procedure-name identifies a fixed set of procedure statements", unlike a data-name, which identifies a storage area with varying contents (F p. 16). Assignment "consists merely of writing the procedure-name before the statement or statements to which it refers" (F p. 16).

Formation and placement rules:

1. General name-formation rules apply (letters, digits, imbedded periods; begin with a letter; no blanks; see the names/elements section of this reference, F p. 15).
2. "Procedure-names, like data-names, may contain up to thirty characters. Unlike data-names, however, they must be followed by a period and a blank" (F p. 37).
3. "Procedure-names are written left-justified in the name margin and, if longer than six characters, extend into the 'Text' area" (F p. 37).
4. A named sentence begins on the same line as its name; see the line rules in §2.2.4 (F p. 37).

F/J divergence (the trailing period): J notes "Procedure.names not followed by a period (.) and blank are handled properly; no diagnostic message is given" (J 90.01.03). The period-blank is thus mandatory in the language definition but not enforced by the 7090 compiler.

J-side behaviours:

• Unnamed procedure statements (and unnamed data entries) are assigned compiler-generated names of the form GN)nnn, which appear in the name field of the listing (J 02.02). The sample program shows an unnamed CALL sentence listed as GN)000 and unnamed END sentences as GN)077, GN)078, GN)083 (J 90.05, listing PDF pp. 195–197).
• Names must be resolvable: a transfer to something that is not a statement or section name is bypassed with a diagnostic (127,00), as is a transfer into a DO-addressed procedure (128,00) (J 90.04.01).
• Sections interact with name uniqueness: message 166,00 'NAME.1' IS NOT UNIQUE IN THIS SECTION. (J 90.04.01); "Where necessary, the names of sections can be used as parts of compound names" (F p. 26); but "If the record is defined within a section the section.name may not be used as a qualifier of the record.name" (J 90.01.03). See Ambiguity register on section scoping.
• Qualified (compound) names are legal in procedure statements but "may not be used in the Environment Description or in CRYPT instructions. Data and Procedure names used in these sections must be of one word only. The verb CALL enables the programmer to reduce a qualified name to a one-word name to fulfill this requirement" (J 02.03.03).

2.5 Sections: BEGIN SECTION … END

"A section consists of one sentence, or a group of successive sentences, which has been given a name for reference purposes" (F p. 26). BEGIN SECTION and END "are used to delimit sections of procedure and thus extend the range of a procedure-name. ... Unless BEGIN SECTION and END are used, a procedure-name applies only to the sentence which follows it" (F p. 56). "If a procedure consists of more than one sentence, it must be defined as a section in order to be named" (F p. 49).

General form, verbatim:

procedure.name.  BEGIN SECTION.
     any sentence.
     .
     .
     .
     any sentence.
END procedure.name.

(F p. 57)

Rules:

• "The beginning of a section must be identified by a procedure-name, followed by a period. The name must then be followed by the words BEGIN SECTION" (F p. 26). Only BEGIN SECTION may share the line with the section name; END section.name is written as a sentence on a separate line (F p. 37).
• The name appears at both ends; "The second occurrence is required because sections of procedure may be 'nested,' i.e., one section may be contained within a larger one" (F p. 57). "Sections may be 'nested' ... but each such section must be wholly contained—it cannot overlap another section" (F p. 26). J enforces proper nesting and closure: 64,00 CANNOT -END- SECTION WHEN NONE ARE OPEN., 65,00 CANNOT -END- SECTION 'NAME.1' BEFORE SECTION 'NAME.2'., 66,00 ONE OR MORE SECTIONS NOT CLOSED. (J 90.04.01).
• The END sentence must stand alone: 179,00 -END- SECTION MUST BE THE ONLY CLAUSE IN THE SENTENCE. (J 90.04.01).
• "Normally the terminating sentence, 'END procedure.name,' is not itself named. There is one exception to this rule: The END sentence in a procedure associated with a DO command may be named in order to provide a reference point at the end of the procedure" (F p. 57; mechanism explained at F p. 53 — a conditional early exit does GO TO EXIT. where EXIT. END procedure.name. preserves the DO's loop-control linkage). The sample program uses exactly this (BOND.END. END BOND.ROUTINE., SEARCH.END. END SEARCH., J 90.05 listing PDF p. 197).
• A section addressed by a DO "becomes a closed subroutine; it can be entered only through the use of one or more DO commands" (F p. 57; also F p. 50: entry "not by any other means such as transfer of control to a sentence within the procedure or through the normal passage of control to the first sentence of the procedure"; multiple DOs addressing one procedure are allowed). J diagnoses violation of the fall-through half of the rule: 99,00 PROBABLE PROGRAM CONTINUITY ERROR. PROGRAM FLOWS INTO STATEMENT OR SECTION 'NAME.1' ADDRESSED BY A -DO-. (J 90.04.01), and refuses a GO TO whose target is a DO-addressed name (128,00; the analogous entry-point rule is 143,00: PROGRAM.START may not be DO-addressed).
• Data substitution form: sections used as parameterised procedures are opened with

BEGIN SECTION USING parameter.1, parameter.2, ...
     parameter.n GIVING function.1, function.2, ... function.n

(F p. 57). The parameters are replaced at object time by the data of the DO command's USING phrase; the functions are results delivered to the DO's GIVING phrase; function-names may also be invoked directly in arithmetic expressions with arguments in double parentheses (F pp. 57–58; details in the DO/functions coverage of the verbs section of this reference). F/J divergence: the Data Description type codes PARAM and FUNCT that F requires for these names (F p. 34) "are no longer in the language" (J 02.05.03); the J compiler still processes USING/GIVING and function references (diagnostics 30,00; 68,00; 72,00–75,00, J 90.04.01); see Ambiguity register.

Significance of sections beyond naming (things a compiler writer must support):

• DO, LOAD and OVERLAP operate on sections: "The usefulness of these commands would be seriously impaired if they could not operate on pieces of procedure larger than sentences" (F p. 57). (LOAD/OVERLAP are deferred in J; §2.7.)
• Environment OPTION cards can scope compilation modes to a section: [IN section.name] "enables the programmer to limit the modal specification [COLLATE COM or CONSERVE SPACE/TIME] to a particular section. ... the mode of generation reverts to the normal mode at the end of the specified section. There is no restriction on the number of times these modes may be altered" (J 02.06.17).
• Environment CONTRL cards may define common areas by section.name or sentence.name.1 TO sentence.name.2 (exclusive of sentence.name.2) for merging separately compiled programs (J 02.06.15); mechanization deferred (J 90.01.04).
• The Loader's LOGIC option lists "the origin and extent of all program sections" (J 02.01.02).

Numeric limits on sections (approximate maxima, J 90.01.05): number of SECTIONS 35; depth of nested sections 18. Exceeding the section table gives 149,00 NUMBER OF SECTIONS IN PROGRAM EXCEEDS INTERNAL TABLE CAPACITY. (J 90.04.01).

2.6 Default flow of control and program termination

• "During the execution of the object program the procedure is normally executed in the order in which it appears in the source program. The control commands are used primarily to specify a departure from this sequence" (F p. 48). Object code position is determined "by the relative position of items in the source deck" (Location Counter 0, J 90.02.01).
• A false conditional sentence with no OTHERWISE proceeds to the next sentence (F p. 25). A conditional GO TO whose conditions are all false, and an assigned GO TO whose index is outside 1…n, both pass control "to the next clause or sentence in sequence" (F pp. 48–49).
• DO transfers to the named sentence/section and returns control to the clause or sentence following the DO (F pp. 49–50). J caveat: "A DO section will always be performed at least once regardless of the values of the loop control variables" (J 90.01.02).
• Sequential flow must never run into a DO-addressed procedure (message 99,00) nor into a *DATA portion (message 87,00) (J 90.04.01); the programmer must route around both with GO TO.
• STOP: "The STOP command is used to specify a halt in the object program. ... STOP n ... Restarting the machine causes execution of the object program to be resumed beginning with the next command in sequence" (F p. 54). A dead-end halt is made by following STOP with an unconditional GO TO back to it (F p. 54).
• J requirement (STOP RUN): "A STOP RUN instruction must be included in each program to provide for transfer of control to the CT Supervisor at conclusion of execution of the object program. All open files are closed prior to this transfer of control as if a CLOSE ALL FILES had been supplied" (J 02.04.06). Its absence is diagnosed: 175,00 NO -STOP RUN- IN PROGRAM. (J 90.04.01). The sample program ends its main line CLOSE ALL FILES, STOP RUN. (J 90.05, listing PDF p. 196).
• Entry point: the manuals never define it in the language sections. The J error messages imply a distinguished name PROGRAM.START ("MORE THAN ONE -PROGRAM.START-. FIRST USED."; "-PROGRAM.START- MUST BE A STATEMENT OR SECTION NAME."; "-PROGRAM.START- CANNOT BE A STATEMENT OR SECTION NAME ADDRESSED BY A -DO-.", J 90.04.01), and J 90.02.01 notes the first word of the object program is "not necessarily PROGRAM.START". At load time "The Loader will normally use the starting point of the first program of combined segments as the starting point for the combined deck", modifiable by the *START Loader card (J 03.02). See Ambiguity register.
• Memory model: "An object program produced by the Commercial Translator system is organized as one loading of storage unless the programmer specifies otherwise by means of the OVERLAP command" (F p. 55). In J, OVERLAP/LOAD are deferred, so "programs may not be segmented into separate memory loads at this time" (J 90.01.05); the whole object program must fit one core load.

2.7 Verbs: program verbs vs processor verbs, and the complete inventory

"In the Commercial Translator language, a verb is a word that prescribes an action. Verbs are not used in a declarative sense" (F p. 12). Two categories:

• Program verbs: "Verbs which act at object time" (F p. 13); commands built on them "state the data processing steps to be carried out by the object program" (F p. 8).
• Processor verbs: "Verbs which act on the processor when the source program is translated" (F p. 12). "The processor commands ... tell the processor how to organize the object program rather than what the object program is to do" (F p. 8). "In general, the processor commands do not generate instructions in the object program" (F p. 55).

Verbs are distinct from operators (IF, THEN, arithmetic symbols, relations, etc.), which also cause operations but are not verbs (F p. 13). "Commercial Translator verbs may be easily recognized by the fact that all of them are words which serve also as verbs in the English language" (F p. 13). The system is "open-ended": "the list of verbs and associated commands is never closed" (F p. 35).

The complete F verb inventory, verbatim (F p. 35):

OPEN     \
GET       |  Input/Output
FILE      |
CLOSE    /

MOVE        Data Transmission

SET      \
ADD      /  Arithmetic

GO TO    \
DO        |  Control
STOP     /

LOAD      \
DISPLAY   /  Miscellaneous

OVERLAP
BEGIN SECTION
END
INCLUDE
CALL
NOTE
ENTER

Program verbs

Processor verbs

Relationship between program and processor commands

"they cannot be intermixed in source program sentences. For example, it is meaningless to write sentences such as: IF A = B THEN GO TO C OTHERWISE OVERLAP SECTION.1, SECTION.2." (F p. 60). "Processor commands, with the exception of BEGIN SECTION and END, should be written as unnamed sentences. This rule makes it impossible for a program command to transfer control to a processor command. ... This is not to say, however, that the two types of commands cannot appear in sequence in a source program" (F p. 60). The sample program's first *PROCEDURE statement is an unnamed CALL sentence, listed under generated name GN)000 (J 90.05, listing PDF p. 195).

Presentation convention used throughout both manuals (and this reference): each command has a "general form" in which fixed words are boldface capitals and programmer-supplied items lower-case; "except for imbedded periods within italicized words, any punctuation shown in the general form of a command is a fixed and necessary part of the command" (F p. 38). The concise collected forms are in F Appendix 2. In J, [ ] denotes an option, { } a choice, upper case must appear as shown, lower case is generic, and "The order in which options are exercised on the various cards is not critical unless otherwise specified" (J 01.01.01).

2.8 How procedures connect to the data and environment descriptions

• Names: every data-name and condition-name used in a procedure statement must have a Data Description entry (F p. 16; J 02.05.01). Procedure-names, by contrast, are defined by their position in the procedure description itself (F p. 16).
• Condition-names are defined in the Data Description (type code COND) as named values of a conditional variable; they are usable both in conditional expressions and as the object of SET (F pp. 21–22, p. 46; see §3). The Environment COND card separately defines console-entry-key settings testable as condition-names in procedure statements: "Note that Data Description condition.names are tested differently, i.e., for absolute equivalence to the specified value" (J 02.06.17).
• Files and records: files exist only via Environment FILE cards; "All records associated with the file must be named on the FILE card" (J 02.06.05), and each record so named must be a RECORD-type Data Description entry (diagnostics 8,00–17,00, J 90.04.01). OPEN/GET/FILE/CLOSE reference these names (F pp. 39–41).
• Environment → procedure references: the FILE card options ON ERROR statement.name.1 and FOR LABEL statement.name.2 name procedure statements to receive control on unrecoverable input errors and on open/close/reel-switch label processing respectively (J 02.06.04–02.06.05); enforcement via messages 92,00 and 93,00 (J 90.04.01). GET's AT END likewise requires a statement or section name where a transfer is implied (message 106,00, J 90.04.01).
• One-word-name rule: qualified names are banned in the Environment Description and CRYPT; use CALL to create one-word synonyms (J 02.03.03, J 90.01.01).
• Reserved words: the F reserved-word list is F Appendix 2; J refines it into three classes: words never usable as programmer names in any division; words unusable as Data or Procedure names; and words usable as Procedure/Data names only if never referenced in the Environment Division (J 02.03.02–02.03.03; full lists in the elements section of this reference). "it is strongly recommended that the entire group be avoided altogether" (J 02.03.02).

2.9 Program size and structural limits (7090 implementation)

Internal table size limitations, "Appox-Max Size" (J 90.01.05, reproduced in full):

Other structural limits and constraints:

• "A maximum of 63 files may be described" (J 90.01.04).
• One core load: no OVERLAP segmentation (J 90.01.05; §2.6).
• deck.name: six or fewer characters, no imbedded blanks (J 02.01.01, 90.01.05).
• Names (data-, procedure-, condition-): 1–30 characters (F p. 15, p. 37); pictorials limited to 30 characters (J 90.04.01, message 100,00); literals 50 characters, complete on one line (F p. 18; J 90.04.01 message 150,00); alphabetic constants exceeding internal table capacity must be subdivided (message 148,00).
• A single sentence has a bounded (unquantified) internal size: 177,00 THIS SENTENCE EXCEEDS INTERNAL TABLE CAPACITY. SENTENCE DELETED FROM TEXT. (J 90.04.01). DISPLAY sentences are checked against an internal form of 255 words of storage (printing then splits across physical records; J 02.04.02.01).
• Severity codes 1–5 attach to every diagnostic; severity 5 suppresses the object deck, severity >1 suppresses immediate execution under the LOAD option (J 02.01.01–02.01.02; the full message/severity list is J Appendix 90.04 — see the diagnostics section of this reference).

2.10 Ambiguities affecting this section (summary)

Recorded in detail in the ambiguity register accompanying this reference: (1) the undefined PROGRAM.START entry-point mechanism; (2) division ordering/interleaving under the J compiler; (3) treatment of cards preceding the first division header; (4) the F-vs-J sequence-checking contradiction; (5) GO TO out of a DO-addressed section (used by IBM's own sample program despite the closed-subroutine rule); (6) parameter/function declaration after removal of PARAM/FUNCT; (7) survival of the STOP n form alongside J's mandatory STOP RUN; (8) section-scoped name uniqueness.