Part 6 of 10 of the COMTRAN Language Definition.

6. Input/output and report-generation facilities

Input/output in COMTRAN is a record-processing system built on four program verbs (OPEN, GET, FILE, CLOSE) plus the low-volume DISPLAY verb and the (deferred) LOAD/OVERLAP segmentation pair. F chapter 3 gives the 1960 language vision (F pp. 38–41, 54–56); J section 02.07 ("Input/Output Facilities of the 709/7090 Commercial Translator") is the definitive implemented behavior, and J explicitly corrects F's description of GET (J 02.07.04). All I/O operations "are handled within the Commercial Translator system by the 709/7090 Input/Output Control System" (IOCS) (J 02.07.01). File characteristics are declared on Environment Description FILE and SPECIF cards (J 02.06.02); the full card-by-card field detail belongs to §7 (Environment description); this section covers only what is needed to understand I/O semantics.

The programmer initiates "the movement of data into buffers or internal storage, the checking of the validity of the file itself, the checking of the validity of the input or output operation … and finally, the making available or filing away of data"; the I/O control system provides data-flow control and, where feasible, a "look ahead" (F p. 38). The system is "a record processing system": the unit made available each cycle is the record; if more than one record of a file must be available at once, the programmer must provide working storage and MOVE additional records there (F p. 38), but see the HOLD option (§6.3) for the implemented alternative. The initial version handles tape and card files; error detection is implicit, and correction "where feasible, is handled automatically" (F p. 38).

6.1 The file model: record, file, block, buffer

J's definitions (J 02.07.01):

F defines the same three data terms operationally: OPEN and CLOSE "can operate only on files"; GET and FILE "can operate only on records"; fields are the subordinate units operated on by arithmetic and data-movement verbs (F pp. 63–64). A file "is a body of data stored in some external medium which can be made accessible to the system by the use of the verb OPEN"; there may be more than one file on a tape, and a file may extend over a number of tapes (F p. 63). A record "is a portion of a file which can be made accessible to the system by the verb GET"; a file, as such, is never actually brought into storage (F p. 64). Records in a file are usually, but not necessarily, similar in content, size and format; when differing records are grouped in one file "the programmer must make provisions for distinguishing among them" (F pp. 63–64).

Blocking guidance: the greater the block length, the better the tape utilization, but large blocks need large storage allocations; "Blocks of 200 to 500 words will probably provide for the optimum processing of master records" (J 02.07.02).

Buffer allocation may be steered by POOL cards (files sharing a common buffer area) and GROUP cards (buffer sharing within a pool); absent these, "files will be grouped automatically by IOCS", and absent GROUP specifications "the compiler will attempt to assign at least 2 buffers to each file" (J 02.06.13, 02.06.14). Pool BLOCKSIZE should be at least the largest file BLOCKSIZE in the pool (defaulting to it when omitted); GROUP BUFFERCOUNT ≥ OPENCOUNT (maximum concurrently open files in the group) (J 02.06.13, 02.06.14). Full card detail: see §7.

Numeric limits touching the file model:

F's "Storage Areas" discussion (F pp. 84–85) establishes that the programmer does not manage input areas, working storage, or output areas explicitly: "Storage areas are automatically reserved when the data description is written, regardless of how the area is to be used. Certain special provisions, especially those governing input and output, are built into the processor for each system" (F pp. 84–85). See §3 (Data description and storage model).

6.2 Locate and Transmit modes

Records of an input file may be processed in the buffers ("locate" mode) or in an area reserved outside the buffer area ("transmit" mode); "all records in a file must be processed in the same manner" (J 02.07.02).

• Locate mode: GET "'locates' the next record in the file, i.e., determines the position of the record within the buffer area, and … adjusts all program references to data within the record to reflect the new base reference address of the record within the buffer area" (J 02.07.02).
• Transmit mode: GET locates the next record and "'transmits' the record to its assigned area. As the area assignment is fixed no adjustment of references to data within the record is necessary" (J 02.07.02).

Mode selection: "The 'transmit' mode is triggered by the selection of the SPANS, HOLD or CARD options on the Environment FILE card. 'Locate' is assumed when none of these options have been selected" (J 02.07.03). On the FILE card, HOLD/SPANS force transmit; "The compiler does not differentiate between the words HOLD and SPANS. They produce the same effect and are both included in the vocabulary for mnemonic convenience" (J 02.06.05). SPANS is the mnemonic for records that may span block boundaries; HOLD for the requirement "that each named record of the file be available until another of the same name is input" (J 02.06.05, 02.07.05). For an output file, HOLD/SPANS mean records are written in blocks of the specified length, permitting partial records in blocks for compactness; "Files written in this manner must be processed in the transmit mode when input" (J 02.06.05). If neither is selected, an input file is processed in locate mode and an output file is created with all records complete within blocks (J 02.06.05).

Consequences and hazards a compiler writer must reproduce:

1. Base-address adjustment / aliasing. In locate mode every reference to the record's fields is relative to a base locator updated by GET. "If the locate mode is being used, no references can be made to the record or its fields until after execution of a GET command for that record. All references to fields of a located record initially specify location zero. Upon a GET these references are adjusted to reflect the location of the data within the buffer area. If references are made to located fields prior to the first automatic GET adjustment the low order portions of memory (the monitor) will be irreparably damaged" (J 02.07.05). (The base-locator mechanism and the generated LAC/TXL/CLA reference sequence appear at J 02.08.03 and J 90.02.04; see the generated-code section of this reference.)
2. Efficiency rule. "The locate mode allows for more efficient utilization of memory … In general, a record should be transmitted if the number of words in the record is less than three times the total number of arithmetic and MOVE references to fields of the record" (J 02.07.05).
3. REDEF forces transmit. "When through use of the type code REDEF a record is specified to share an area with data other than records within the same file, all records of the file are automatically 'transmitted'. If the records of the file were originally to be located a message is printed indicating this change" (J 02.07.05). Field-test restriction: "Records from different files which have been REDEF'd together will not be automatically transmitted by the field test processor … SPANS or HOLD must be used" (J 90.01.01).
4. REDEF joint availability. "All records of a file (whether located or transmitted) which are related through use of the Data Description type code REDEF are made available for processing when any one of the records is requested with the GET command" (J 02.07.05).
5. Arrays force transmit (field test). "All input records containing arrays will be processed in the transmit mode by the field test processor. This is true for both fixed and variable length records" (J 90.01.01).
6. Constants may not be defined "as a part of a located input area" (J 02.05.06; cross-ref §3).

6.3 Record types and variable-length record options

"There are two record types, fixed length and variable length" (J 02.07.03).

• Fixed length: "A fixed length record cannot vary from the length specified by the data description. When it is read or written, a fixed number or words are always made available or output from the buffer" (J 02.07.03; "or words" is a preserved source typo for "of words").
• Variable length: length is defined at object time via the QUANTITY IN option; "the current value of the data.name(s) specified by the QUANTITY IN option(s) defines the number of words to be processed. Storage, if the record is transmitted, is always allocated on the basis of the maximum size of the record. The QUANTITY IN clause, by designating that the length of a field within a record is variable in length, identifies the record as being a variable length record" (J 02.07.03). (QUANTITY IN mechanics: see §3. Note also: variable-length fields may not be compared (J 02.04.07), figurative constants may not be moved to variable-length arrays (J 02.04.01, 90.01.02), and fields may not be defined following a variable-length array in the same hierarchy (J 90.01.04).)

Standard variable-length record format. On tape or in a buffer the record "is always immediately preceded by a control word containing the record length. Although this control word is not described as part of the record in the Data Description and may not be addressed by the programmer, it must be considered in specifying block size for a file." It is automatically supplied for records generated by the system, and must be supplied for records generated outside the system (J 02.07.03). The binary form is quoted:

IOCTN 0,,length.of.record.in.words.

(J 02.07.03; the conversion notes flag that the mnemonic "IOCTN" is clear in the scan but unverified against other IBM documentation.) "Standard variable length BCD records must be immediately preceded by six (6) BCD characters specifying the length of the record in words" (J 02.07.03).

Expansion caution: "if a variable length record is to be processed in the buffer area (located) it cannot be expanded unless each record in the file begins a new block. No check is made for violation of this rule either at compile time or at execute time" (J 02.07.03).

Options (declared per record on the Environment FILE card): "They may be elected selectively when only the GET record.name form of the GET command is used to obtain records in the file; the options must be specified for all records if the GET RECORD FROM file.name form is used" (J 02.07.08).

If neither BLOCK CONTROL nor FIND LENGTH IN is selected for a variable-length input record, "it is assumed that the variable length record is preceded on tape by the standard control word" (J 02.06.05). "For special purposes, the programmer may employ in connection with a fixed length record any of the variable length record options explained above. NO CONTROL WORD will produce no effect" (J 02.07.09).

6.4 The OPEN command

General forms (F p. 39):

OPEN file.name.1, file.name.2, ... file.name.n
OPEN ALL FILES

The first form opens only the named file(s); the second opens all files specified in the environment description. "A given file must be opened, of course, before it can be addressed by a GET or FILE command" (F p. 39). J does not restate OPEN semantics; it refers the reader back to the General Information manual for OPEN and CLOSE (J 02.07.01), so F's object-time description stands, as modified by the SPECIF options below.

Implementation attested. The field-test processor compiled OPEN ALL FILES (statement 188 of the sample) into TSX SYS)175,4 / PZE IOC)1, the routine that "opens all files in the file list located by IOC)1", and it carries a companion SYS)174 that "opens the file designated FILENAME" for the named form, whose parser is attested by diagnostic 139,00 "FILE NAME SHOULD FOLLOW -OPEN-." (J 90.02.13–14; J 90.04.01; J 90.05 listing, PDF pp. 195, 200)

Opening an input file (F p. 39):

1. "The label record, if any, is read into storage and checked for validity according to the standard label-handling conventions."
2. Subsequent records are brought into the storage governed by the I/O control system, filling the area allocated to the file.
3. "Checking is performed, and a record count is initiated."

Opening an output file (F p. 39):

1. "If specified by the programmer, a label record is created and written."
2. Preparation is made to file data records as they become available.
3. Checking is performed and a record count is initiated.

Implemented modifiers (SPECIF card; full detail in §7):

• The file is rewound before opening unless OPENW is specified (J 02.06.10).
• OPENF searches forward on a multi-file reel for a standard-labeled file; without OPENW the tape is rewound before searching; with both, the programmer must ensure the tape is positioned before a header label and the sought file lies further down the tape (J 02.06.10).
• DEFER exempts a file from the requirement of being mounted before processing commences (J 02.06.10).
• Label checking occurs only if LABELS (standard, checked/written automatically by IOCS) or LABELN (non-standard, ≤ 14 words, checked by the programmer through the FOR LABEL linkage) is stated; "If neither option is exercised the file is considered to be unlabeled" (J 02.06.11). Standard input labels are checked against SERIAL 'ser.no' (≤ 5 characters, if non-blank) and the reel sequence number from REEL 'reel.no' (≤ 4 numeric characters, assumed 1 if absent, adjusted at object time on reel switch) (J 02.06.12). RETAIN days (≤ 3 numeric characters) protects a written tape: "An attempt to write a labeled file on this tape before the end of the period has expired will result in an on-line error message from IOCS" (J 02.06.12).
• The FOR LABEL statement.name option on the FILE card "provides transfer of control to statement.name.2 whenever a file is opened or closed or whenever a reel switch occurs" (J 02.06.05). See §6.8.

Failure interactions: a GET against a file that is not open takes the end-of-file exit with no error message (J 02.07.04); a FILE against a file not OPENed acts as a NOP with no error message (J 02.07.08).

6.5 The GET command

General forms (J 02.07.04; identically F p. 39):

GET RECORD FROM file.name
GET record.name

with the optional end-of-file phrase appended to either form (F p. 40):

..., AT END any imperative clause

"The GET command makes available for processing the next record of an open file. If the file is not open and a GET command is given, the end of file exit is taken. No error message is given" (J 02.07.04).

F/J divergence: meaning of the two forms. J states: "The verb is described incorrectly in the Commercial Translator General Information manual and the definition given in the last paragraph on page 39 of the manual should be replaced with:

"The first form of the command assumes that the system has at its disposal sufficient information to obtain the next record. When using a GET of the second form the programmer supplies the system with the name of the next record in the file. Regardless of what record is next in the file, it will be obtained by the GET in accordance with the characteristics associated with the specified 'record.name'. The 'record.name' must be associated with only one input file in the Environment Description."

(J 02.07.04). F's superseded reading was that the first form is for multi-record-type files (programmer must identify the type) and the second form "implies an input file containing only one type of data record" (F p. 39). Under J, GET record.name is an assertion by the programmer about what is next: no identity check is performed, and a wrong assertion silently misinterprets the data.

Preconditions for GET RECORD FROM file.name: at least one of the following must hold (J 02.07.04):

• a) "All records in the file are of a fixed and equal length."
• b) "The beginning of each record in the file corresponds with the beginning of a tape block (indicated by the BEGIN option of the Environment Description FILE card)."
• c) "All records in the file are in the standard variable length form."
• d) "Each tape block in the file consists of one complete record whose length is equal to the length of the block (signalled by the Environment BLOCK CONTROL)."
• e) "All records in the file which will be obtained by this form of the command are included in a PATTERN in the Environment Description."

(On PATTERN, see the ambiguity note in §6.14: the option is invoked here and policed by compiler diagnostics: "NO RECORDS SPECIFIED IN -PATTERN- ON -FILE- CARD FOR 'NAME.1'.", "SINGLE RECORD IN THE -PATTERN- … INEFFICIENT PROGRAM PRODUCED", "NUMBER OF RECORDS IN -PATTERN- CANNOT EXCEED 16" (J 90.04.01), but no PATTERN syntax appears in the 02.06.C FILE-card general forms.)

Object-time behavior. Either form makes the next record available so the entire record or any part may be used; "the previous record of the file is no longer addressable after the execution of a GET command" (F p. 40; subject to the HOLD option, under which each named record remains available until another of the same name is input — J 02.06.05, demonstrated in Example 4, §6.11). Automatically provided auxiliary input operations: unblocking, tape alternation, tape identification, error checking, reading ahead (F p. 39). At end of tape, "the end-of-tape label is read, and checks are made. The input tape is rewound, and provision is made for an alternate tape unit to be substituted" (F p. 40); the secondary unit comes from the SPECIF UNIT2 assignment (J 02.06.08).

End-of-file processing. "The AT END clause which may be used with the GET command may consist of a single imperative statement only. The clause is used to specify the action to be taken when the end of a file is reached" (J 02.07.05–02.07.06). F/J divergence: F allows "any imperative clause" and says the clause is performed "after the last record of a file has been made available for processing and a subsequent GET command has been encountered" (F p. 40); J restricts the clause to a single imperative statement. If the clause is omitted and an end condition is discovered in attempting to GET a record, the result is "immediate termination of execution of the object program; an error message is printed on-line indicating the cause" (J 02.07.06). F's advice: "The programmer should always use the AT END option if the possibility exists of reaching end of file upon execution of the GET" (F p. 40).

Input-error processing (J 02.07.06–02.07.07). "IOCS automatically attempts to correct most input errors discovered in processing." Errors uncorrectable by IOCS:

For the first three classes, the ON ERROR statement.name option of the Environment FILE card "provides for communication between IOCS and the programmer" (J 02.07.07; card syntax J 02.06.03, described J 02.06.04). "In certain simple error situations such as an unrecoverable redundancy error discovered in a file whose records are complete within the block, the programmer may elect to return directly to the GET command ignoring the error(s) in the unreadable record. This is accomplished by specifying in the ON ERROR clause of the FILE card the procedure.name associated with the GET command" (J 02.07.07). More complex recovery requires obtaining and analyzing the error via IOCS facilities ("primarily pages 17 and 18" of the IOCS manual) (J 02.07.07). If no ON ERROR provision exists and an IOCS-unrecoverable error occurs, "the system prints an on-line message describing the type of error and the name and certain characteristics of the offending file. Control is then returned to the Commercial Translator Supervisor for processing the next job" (J 02.07.07).

Field-test GET restrictions (J 90.01.01): "Card files processed on-line may only be in BCD and fixed length for field test." Records containing arrays are transmitted; REDEF'd records from different files are not auto-transmitted (SPANS/HOLD required).

F examples (F p. 40):

GET RECORD FROM INVOICE.FILE.
GET MASTER, AT END GO TO END.OF.MASTERS.

6.6 The FILE command

General forms (F p. 40; J 02.07.07–02.07.08):

FILE record.name
FILE record.name IN file.name

"The FILE command transmits a record from a reserved memory area or an input buffer to an output buffer area for automatic processing onto tape or cards" (J 02.07.07). (F additionally lists "the printer" as a FILE target: "The FILE command is used to place records on tape (for subsequent on-line or off-line processing), on cards, or on the printer" (F p. 40); J's 02.07 text mentions only tape and cards, though the SPECIF unit assignments include 'PRX' printer and 'OU' system-output designations (J 02.06.09, 02.06.10). See ambiguity note.)

Semantics:

1. FILE record.name "causes a record to be filed in the output file(s) with which it has been associated through the Environment Description. A record so filed is still available for further processing. However, if the record carries the option PRIMARY in one or more of the output files to which it is associated with in the Environment Description, it is only filed in those files wherein it is so classified" (J 02.07.07). The PRIMARY option: "The 'FILE record.name' command will file records belonging to more than one output file only in those files where PRIMARY has been specified for that record.name. If PRIMARY is not used with the record.name in any file, the record will be filed in all output files with which it is associated" (J 02.06.07).
2. FILE record.name IN file.name "provides a means of filing a record in a specific file when the record.name is associated with several output files" (J 02.07.08). F's motivating case: "Creating new records in working storage and then merging them into a master file" (F p. 40).
3. "In using either form of the FILE command the record.name must be associated in the Environment Description with the name(s) of the file(s) into which it is to be filed" (J 02.07.08); i.e., even the IN file.name form requires prior Environment association (F/J divergence: F said the second form files the record "even though that record may not have been hitherto associated with that file", F p. 40).
4. "If a file has not been OPENed or has been CLOSEd when a FILE command is encountered at execution time, the command acts as a NOP. No error message is given" (J 02.07.08).
5. A filed record remains available; "It is entirely possible … to file a record in each of several files by means of a succession of FILE commands" (F p. 41).

Automatically provided operations: blocking, tape alternation, file identification, error checking, setting checkpoints (F p. 40). Object-time events (F pp. 40–41): the record is added to the list awaiting write-out and written when "the proper number of records has been accumulated"; at physical end of reel "the end-of-reel label is prepared and written, arrangements are made for alternation of tape units, and the tape is rewound"; a count of records written is maintained. Checkpoints on reel switch are controlled by the SPECIF options CHECKC (checkpoint written on the checkpoint file upon reel switch of this file) and CHECKF (written on this file; the file must be a labeled output file); "No check point will be written if neither option is exercised" (J 02.06.11). A checkpoint file is declared file.name FILE CHECKPOINT and "may have no other usage" (J 02.06.04).

F examples (F p. 41):

FILE MASTER.
FILE PAY.RECORD.
FILE DETAIL IN ERROR.FILE.

6.7 The CLOSE command and CLOSE ALL FILES

General forms (F p. 41):

CLOSE file.name.1, file.name.2, ... file.name.n
CLOSE ALL FILES

"Each file which has been opened must ultimately be closed" (F p. 41). F's object-time description (J defers to it for the named-file form, J 02.07.01):

Input file (F p. 41):

1. "The record count is compared with the count in the end-of-file label if label records are present and if end of file has been reached. If the count does not agree, notification is given through external display. If the tape is not at end of file the record count is ignored."
2. If on tape, a rewind is initiated.
3. "The storage area allocated to the file is released for the use of other files."

Output file (F p. 41):

1. "Any remaining information belonging to that file is written."
2. If specified, an end-of-file label containing the record count is written.
3. The tape is rewound (if on tape).
4. The storage area is released.

CLOSE ALL FILES (implemented behavior). "This command causes each open file to be closed in accordance with the close options exercised on the Loader *SPEC card. Section 03.02 describes the options as they appear on the *SPEC card which may be supplied by the programmer or generated by the Compiler from an Environment SPECIF card (Section 02.07). In the absence of specification, closing includes a rewind and unload of the unit. Files closed by this form of the CLOSE command may not be subsequently reopened by the program" (J 02.04.06; the parenthetical "(Section 02.07)" is as printed — the SPECIF card is actually described in 02.06.D). The *SPEC open/close option codes (J 03.02.05):

On the SPECIF card the corresponding programmer choices are CLOSER ("the file is only to be rewound upon closing") and CLOSEW ("the file is not to be rewound upon closing"); either avoids the default rewind-and-unload (J 02.06.10).

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).

F examples (F p. 41):

CLOSE INVENTORY.FILE, STATISTICS.
CLOSE ALL FILES.

6.8 Labels and non-standard label processing

F background: labels are special records identifying a file and its contents, normally one at the beginning and one at the end; "Many of the details of labeling are handled automatically by the 'input-output package'" and most labeling procedures are prescribed per machine system (F p. 63). The programmer "has the option of prescribing certain details of a label by the use of the LABEL type code" (F p. 64); F's LABEL type code "identifies a data description as that of a label record. This will cause a redefinition of the label area in the input-output control system", with actual use deferred to the processor publications (F p. 77).

J's implemented mechanism (J 02.05.03): "The type code LABEL allows the programmer to redefine with the indicated data description entries, the single 14 word label area in the Input/Output Control System from which all labels for output files are written and into which all input labels are read. This area may only be processed by the Commercial Translator programmer by using the FOR LABEL option on the Environment FILE cards. Use of the FOR LABEL option with a file causes IOCS to transfer control to the procedure.name specified with the option when the file is opened or closed, or when a reel switch occurs." The LABEL type code plus FOR LABEL "provide the programmer with an IOCS oriented method of checking and forming non-standard labels. The restrictions limiting the length of labels processed in this manner to 14 words and dictating that portions of the FOR LABEL coding must be done in CRYPT may make an alternate method desireable; i.e., defining labels as records and processing with the GET and FILE verbs" (J 02.05.03). The 14-word label area corresponds to IOC)29, "a 14 word area within IOCS which is used to process all labels" (J 90.02.08).

Both J 02.05.03 and J 02.06.12 refer to Appendix 90.07 for implementation of FOR LABEL processing, but the table of contents lists "APPENDIX 90.07: SAMPLE NON STANDARD LABEL PROCESSING (Not Currently Available)" (J contents page); the appendix does not exist in this edition. J's own note: "careful study of the IOCS manual and Appendix 90.07 of this bulletin is essential for understanding standard and non-standard labels" (J 02.06.12).

Label-related SPECIF facts needed for I/O semantics (detail in §7): LABELS = standard labels checked/written automatically by IOCS; LABELN = non-standard label of 14 words or less checked by the programmer via the FOR LABEL linkage; neither ⇒ unlabeled file (J 02.06.11). SERIAL/REEL/RETAIN information "is kept in the IOCS file block and is printed on-line in certain error situations. It is used by IOCS in checking and preparing standard labels (but not non-standard labels) and may be used by the programmer in checking and preparing non-standard labels" (J 02.06.12). Standard output labels take their serial number from the label already on the first reel unless REEL specifies a 'reel.no' greater than 1 (J 02.06.12). Label density defaults to the file's density; a trailing HIGH/LOW after LABELS/LABELN overrides it ("Label dinsity", typo preserved) (J 02.06.12). Which IOCS module is loaded depends on these features: "Normally the MINIMUM module of IOCS is used with the object program. If checkpoints are desired or specified BASIC IOCS is used. If labeling exists the LABELS version of IOCS is necessary" (J 90.01.05).

6.9 The DISPLAY command

General form (F p. 54):

DISPLAY 'any message' data.name 'any message'

"The DISPLAY command causes the object program to present such low-volume information on an appropriate output device or display medium" (F p. 54). "The DISPLAY command displays all the information that follows the word DISPLAY up to, but not including, a comma or period not enclosed in quotation marks" (F p. 54). Material inside quotation marks is displayed exactly; a data-name written outside quotation marks is replaced by its current value (F pp. 54–55). "The name of the variable outside the parentheses may be subscripted. It must represent a defined field, however, and not an arithmetic combination of fields" (F p. 55; "parentheses" is as printed and evidently means the quotation marks).

Implemented specifics (J 02.04.02.01):

• "The display device for the 709/7090 processor is the on-line 716 printer."
• "the portion of the material to be displayed which is written enclosed in quotation marks actually is an alphameric literal, which may not exceed fifty characters in length and must be complete upon a single line."
• "A check is made to determine whether the internal form of the sentence to be displayed is more than 255 words of storage. If it is, the entire literal will be printed but it will be printed as more than one physical record."

Field-test restriction (J 90.01.01): "Data names not intended to be used as qualifiers must be separated by commas; otherwise all but the last will be disregarded." F/J divergence: under F's rule an unquoted comma terminates the displayed material, while J's field-test rule requires commas between successive data-names (adjacent unseparated names are treated as one qualified name and "all but the last will be disregarded"). See ambiguity note.

F worked example (F p. 55): DISPLAY 'VALUE OF WAGES LESS DEDUCTIONS IS' NET.PAY. prints VALUE OF WAGES LESS DEDUCTIONS IS $67.75 when NET.PAY's edited value is $67.75.

The alphabetized command list also records the general shape (F p. 108):

DISPLAY  { 'any message'
         { data.name
         { any combination of the above

6.10 The LOAD command (and OVERLAP) — deferred

General form (F p. 54):

LOAD procedure.name

LOAD, used with the processor command OVERLAP (OVERLAP procedure.name.1, procedure.name.2, ... procedure.name.n, F p. 55), brings a unit of procedure waiting in external storage into the storage area shared by the procedures named in the associated OVERLAP; the displaced portion "can be retrieved later by another LOAD command"; "Any unit of procedure addressed by a LOAD command must be named in an OVERLAP command" (F p. 54). Object-program organization under OVERLAP: initial loading includes everything not mentioned in any OVERLAP plus the first procedure named in each OVERLAP command; loading does not execute the procedure (a GO TO or DO must follow); overlapped procedures should end with an unconditional GO TO because a shorter procedure loaded over a longer one does not erase all of it; a LOAD must not appear within the procedure it obliterates (F pp. 55–56).

Not implemented: "Implementation of these verbs has been deferred" (J 90.01.03), and on the Loader side, "Deferred implementation of the LOAD-OVERLAP verbs implies that programs may not be segmented into separate memory loads at this time" (J 90.01.05).

6.11 The worked examples of J 02.07.F

J closes its I/O section with four examples; a compiler writer should treat them as acceptance tests for blocking/mode logic.

6.12 Report generation: what exists and what does not

Finding: neither manual contains a report-writer facility. There is no report-writer verb, no report section or division, and no report-description entry in either F or J. F's verb list (F p. 35) and command list (F pp. 108–109) contain no report verb; J's deferred-features appendix (J 90.01) lists no deferred report writer; it is simply absent from the language. Confirming context: the J manual's own Publications list refers readers to a separate, non-COMTRAN product for report generation: "J28-6168 | SHARE 7090 9PAC: Part 3 - The Reports Generator" (J Publications page, PDF p. 221).

What "report generation" amounts to in the implemented language:

1. Edited MOVEs/SETs into output records. "Editing of the data in the sending area to conform to the format of the receiving area is a feature of the MOVE command", driven by field pictorials in the data description (F p. 42); MOVE rule 1 permits numeric data to be moved "to report fields" (F p. 42), F's term for what J calls edited fields, characterized by the pictorial characters 8 * ., $ + - or the BLANK WHEN ZERO clause (J 02.05.05; see §3 for the full pictorial/editing rules, e.g. $888,888.99, F pp. 80–81). SET results are likewise edited to the result field's format: "if a result represents an amount of money, editing appropriate to the defined format of the money field will be performed" (F p. 44).
2. FILE-ing edited records to output files. Print-image records are assembled (constants, blanks, edited fields) and FILE'd to BCD output files: on tape for off-line listing, on cards, or (per F) on the printer (F p. 40). The sample program's "Output Report Files" (CHECKFILE, BONDORDERFILE, PAYFILE, ERRORFILE) are exactly this: e.g. the CHECKFILE record is "a 2-line check to be printed under carriage control on a 720 printer", the two print lines grouped in one record "separated by a record mark (signalled by type RCDMRK) for printer control", with carriage-control characters occupying the first character position of each line (J 90.05.03). "In output report records blanks may be specified as a constant. If the format specification indicates the length of the field, it is unnecessary to provide the proper number of blanks between quote marks" (J 90.05.04). The RCDMRK type code inserts "a single character record mark constant in the indicated position", automatically given a single-A pictorial, freely movable into/out of (J 02.05.03; see §3). The actual printed output of these files appears as "REPORT OUTPUT FOR SAMPLE PROBLEM" (J 90.05, PDF p. 217).
3. Control-break logic written by hand. Department totals and grand totals in the sample program are accumulated by ordinary ADD/ADD CORRESPONDING into internally-formatted working areas and moved out as "external edited versions" on a change in department number (J 90.05.04); F's ADD CORRESPONDING example is exactly the accumulation of department and grand totals (F p. 47).
4. DISPLAY for low-volume output to the on-line 716 printer (J 02.04.02.01; F p. 54): operator messages and debugging values, not reports.

F's payroll example likewise treats reporting as an output file: among its four output tape files is "(2) A payroll report file, which will be used to produce a printed report" (F p. 87).

6.13 Environment-card summary for I/O (cross-reference to §7)

The FILE card "must be included to describe the file characteristics which affect compilation" and "must be made for each file processed by the program" (J 02.06.02); the general forms are quoted verbatim below because every option named in this section appears in them. Full field-by-field treatment (columns, continuation rules, SPECIF/POOL/GROUP/CONTRL/OPTION/COND cards, unit-assignment notation): see §7.

Input files (J 02.06.03):

Name        Type    Description

file.name   FILE    INPUT    [ ,{BCD}    ]    [ ,{CARD} ]
                              [  {BINARY} ]    [  {TAPE} ]

                     ,BLOCKSIZE nn

                     [ ,ON ERROR statement.name.1 ]
                     [ ,FOR LABEL statement.name.2 ]
                     [ ,{HOLD}  ]    [ ,BEGIN ]
                        {SPANS}

                     ,record.name.1

                     [ ,{BLOCK CONTROL}               ]
                     [  {FIND LENGTH IN data.name.1}  ]
                     [ ,PLACE LENGTH IN data.name.2   ]

                     [ record.name.2 . . . ]

Output files (J 02.06.03):

Name        Type    Description

file.name   FILE    OUTPUT   [ ,{BCD}    ]    [ ,{CARD} ]
                              [  {BINARY} ]    [  {TAPE} ]

                     ,BLOCKSIZE nn

                     [ ,FOR LABEL statement.name.2 ]

                     [ ,BEGIN ]    [ ,SPANS ]

                     ,record.name.1

                     [ ,FIND LENGTH IN data.name.1  ]
                     [ ,PLACE LENGTH IN data.name.2 ]
                     [ ,PRIMARY ]    [ ,NO CONTROL WORD ]

                     [ ,record.name.2 . . . ]

Checkpoint files (J 02.06.04):

Name        Type    Description

file.name   FILE    CHECKPOINT

Rules and defaults with direct I/O consequences:

• One of INPUT/OUTPUT/CHECKPOINT is mandatory; a CHECKPOINT file "may have no other usage" (J 02.06.04).
• Mode defaults to BCD; medium defaults to TAPE (J 02.06.04).
• CARD: on-line card reader/punch; "When CARD is specified BEGIN is assumed"; only columns 1–72 are read; "For the most efficient handling of card input a GROUP card should be used when more than two cards constitute a record" (J 02.06.04). CARD also triggers transmit mode (J 02.07.03).
• BLOCKSIZE nn is mandatory: "the size of the largest block to be output or the maximum number of words to be input from an input block"; note the input reading truncates larger physical blocks (exploited in Example 3, and by the sample program's DETAILFILE: BLOCKSIZE 3 against 14-word blocks, J 90.05.03). Card input files ≥ 24 words; maximum 9999 (J 02.06.04).
• All records associated with the file "must be" named on the FILE card (J 02.06.05); "The order in which options are exercised on the FILE card is critical only in that the options exercised for a particular record must be listed following the record.name and prior to the introduction of another record.name" (J 02.06.04).
• BEGIN: "each record to be read or written by the program starts at the beginning of a physical block" (J 02.06.05).
• Per-record options: BLOCK CONTROL / FIND LENGTH IN / PLACE LENGTH IN (input); FIND LENGTH IN / PLACE LENGTH IN / PRIMARY / NO CONTROL WORD (output). Semantics in §6.3, §6.6.
• A period must not terminate an Environment specification ("it will be treated as part of the previous word thus creating an undefined symbol", J 02.06.02); qualified names may not be used in the Environment Description (J 90.01.04).
• SPECIF cards are optional (load-time *SPEC/*FILE cards may be hand-punched instead) and may appear anywhere within the environment division (J 02.06.07).
• Deferred/restricted: maximum 63 FILE cards; "No file check table is produced in the object deck"; absolute tape assignment cannot be made (symbolic/relative only) (J 90.01.04).

6.14 Ambiguities flagged in this section

(Recorded in full in §8.5; summarized here so the reader of this document sees them in place.)

• The PATTERN Environment option is required reading for GET RECORD FROM (J 02.07.04 e) and enforced by diagnostics 48–50 (J 90.04.01) but its card syntax is nowhere given.
• Appendix 90.07 (non-standard label processing) is cited normatively (J 02.05.03, 02.06.12) but marked "Not Currently Available" in the contents.
• Whether a file closed by the named-file CLOSE form may be reopened is unstated (J prohibits reopening only after CLOSE ALL FILES, J 02.04.06).
• DISPLAY's comma is both a terminator (F p. 54) and a required separator between data-names (J 90.01.01).
• On-line printer as a FILE target: F p. 40 lists the printer; J's 02.07 lists only tape and cards, while 'PRX'/'OU' unit assignments exist (J 02.06.09, 02.06.10) and the sample program prints via off-line listing of BCD tapes (J 90.05.03).
• *SPEC 'blocksize' "(0-999)" (J 03.02.05) vs Environment maximum 9999 (J 02.06.04).
• GET against an unopened file ("the end of file exit is taken. No error message is given", J 02.07.04) vs termination-with-message when no AT END clause exists (J 02.07.06).