Part 8 of 10 of the COMTRAN Language Definition.

8. Known ambiguities, underspecified behaviour, and plausible resolutions

This section is the compiler writer's risk register. It collects (§8.2) the complete digest of J Appendix 90.01 (the master list of features deferred, removed, or restricted between the 1960 language and the 1962 processor); (§8.3) the direct contradictions between F28-8043 and J28-6169; (§8.4) the severity-code system and the language rules that can only be recovered from the compiler's error messages; and (§8.5) the consolidated catalog of genuine ambiguities and underspecified behaviour, each with the most historically plausible resolution. Questions the manuals cannot answer at all are listed at the end of the document under Open questions.

Contents of this section

• 8.1 Status of the sources
• 8.2 The F→J delta: complete digest of J Appendix 90.01 (deferred features, restrictions, limitations)
  • A.1 Procedure-language restrictions (J 90.01.01–90.01.03)
  • A.2 Data Description restrictions (J 90.01.03–90.01.04)
  • A.3 Environment Description restrictions (J 90.01.04)
  • A.4 Internal table size limitations (J 90.01.05)
  • A.5 Loader restrictions (J 90.01.05, part B)
  • A.6 Deferrals and removals recorded outside Appendix 90.01
• 8.3 F28-8043 vs J28-6169: contradictions and divergences
• 8.4 The severity-code system and rules implied by the diagnostics (J Appendix 90.04)
  • B.1 The severity-code system
  • B.2 Implied language rules, message by message
• 8.5 Consolidated ambiguity catalog, with plausible resolutions
  • 8.5.1 Lexical
  • 8.5.2 Program structure
  • 8.5.3 Data description
  • 8.5.4 Arithmetic and data manipulation
  • 8.5.5 Control flow
  • 8.5.6 Input/output
  • 8.5.7 Environment, control cards, and processor surface
  • 8.5.8 Transcription and printing artifacts (conversion-level cautions)

8.1 Status of the sources

F28-8043's Preface states that environment-description rules and processor operation are deferred to "separate publications" (F Preface, PDF p. 6), so for the Environment Description, J is not merely authoritative but the only source. J28-6169-1 documents the field test version of the 709/7090 processor: several restrictions in its Appendix 90.01 are explicitly scoped "for field test" / "by the field test processor" (J 90.01.01), its promised Appendix 90.07 (Sample Non Standard Label Processing) is marked "(Not Currently Available)" in its own contents (J 00.00), and its sample listing was produced by an October 1961 system whose control card (*COMPILE) differs from the documented $CMPLE (see §8.5). Both manuals therefore describe moving targets; J is the later and operationally definitive snapshot.

F Appendix 3 (Glossary, F pp. 111–116) was swept for this definition. It is definitional and largely redundant, with these normative exceptions folded in where relevant: ROUND and TRUNCATED (F pp. 115–116 — the rounding rule, see §8.5.4), ALPHAMERIC (F p. 111 — "an alphameric literal may not contain a quotation mark"), OPEN SUBROUTINE / CLOSED SUBROUTINE (F pp. 112, 114 — the terminology §5.5.5 relies on), SUBSCRIPT (F p. 115 — the three legal subscript forms), and FLOATING POINT (F p. 113).

8.2 The F→J delta: complete digest of J Appendix 90.01 (deferred features, restrictions, limitations)

Everything below is from J Appendix 90.01 unless another citation is given. Section 90.01 is organized as: A. Compiler (1. Language: Procedure / Data Description / Environment Description; 2. Internal table sizes) and B. Loader.

A.1 Procedure-language restrictions (J 90.01.01–90.01.03)

Statements / verbs

A.2 Data Description restrictions (J 90.01.03–90.01.04)

A.3 Environment Description restrictions (J 90.01.04)

A.4 Internal table size limitations (J 90.01.05)

Reproduced from the 90.01.05 table (header reads "Appox-Max Size", sic; note these are stated as approximate maxima):

(Item k's -CP)+NN is printed exactly so; scan check 2026-08-01 resolves it: the mark is a plain hyphen, a dash introducing the notation CP)+NN, the manual's own generated-name form ("SYM)NNN", J 90.02.03), which has no opening parenthesis. See §8.5.8.) (J 90.01.05)

Overflow of these tables is reported at compile time by diagnostics 148, 149, 172, 177, 183, 184, 200–205 (see §8.4).

A.5 Loader restrictions (J 90.01.05, part B)

1. The control break table is not processed by the loader: multiple program loading with cross references by means of control breaks is not available. (J 90.01.05)
2. 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)
3. "No debugging facilities are currently available." (J 90.01.05)
4. 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)
5. Trap for the compiler writer: "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." (Contrast the $CMPLE rule that deck.name "must not include imbedded blanks", J 02.01.01.) (J 90.01.05)

A.6 Deferrals and removals recorded outside Appendix 90.01

These belong in the same master delta list but appear elsewhere in J:

8.3 F28-8043 vs J28-6169: contradictions and divergences

Each item gives both readings. J is authoritative for the implemented language.

1. PARAM and FUNCT type codes removed. F defines FUNCT and PARAM as required Data Description type codes for the GIVING/USING names of a BEGIN SECTION command (F pp. 72–73; type-code list F p. 71 area; word list marks them † restricted, F p. 110). J: "These two type codes described in the General Information Manual are no longer in the language." (J 02.05.03). Functions themselves survive: J diagnostics 30 and 68 still police function-argument counts (J 90.04.01) and DO USING/GIVING parameter matching is checked (msgs 72–75); only the special data-description marking is gone.

2. GET verb definition corrected by J. J states outright: "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:" followed by replacement text: GET record.name obtains the next record in the file regardless of what record is actually next, in accordance with the characteristics of the named record; the record.name must be associated with only one input file (J 02.07.04, correcting F p. 39). J also adds the five preconditions (a–e) for using GET RECORD FROM file.name (fixed equal lengths / BEGIN / standard variable-length / BLOCK CONTROL / PATTERN) (J 02.07.04).

3. STOP RUN. F documents only STOP n: halt displaying n, resumable by restart (F p. 54; command list F p. 109 area shows "STOP n"). RUN is absent from F's word list (F p. 110). J requires a STOP RUN in every program to return control to the CT Supervisor, closing all open files as if CLOSE ALL FILES had been given (J 02.04.06 #9), enforces it with diagnostic 175 (J 90.04.01), and reserves RUN (key-word list 2, J 02.03.02; diagnostic 2). J's operator documentation shows both forms: "STOP nnnnnn where nnnnnn is any number 6 digits or less" and STOP RUN (J 05, systems operation).

4. DISPLAY comma semantics. F: "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.": a bare comma terminates the displayed material (F p. 54). J: within DISPLAY, "Data names not intended to be used as qualifiers must be separated by commas; otherwise all but the last will be disregarded": the comma is an operand separator (J 90.01.01). Also, J fixes the display device as the on-line 716 printer and caps the quoted material at a 50-character alphameric literal complete on a single line (J 02.04.02.01), where F speaks generally of "an appropriate output device or display medium" (F p. 54).

5. Pictorial characters A vs X. F distinguishes them: A = "Any non-numeric character, including the blank"; X = "Alphameric character (any character in the machine's character set)" (F p. 80). J collapses the distinction: "The pictorial characters A and X are considered to be synonymous by the 7090 CT Compiler." (J 02.05.04).

6. Sign-overpunch position. F allows the +/− overpunch "with either of the format characters 8 or 9, in either the units or high-order position of a field" (F p. 80). J restricts external decimal fields to "an overpunched + or - in the rightmost position of the field. A + and - may not appear in the character by itself." (J 02.05.05, note 1; the field-type chart allows the overpunch only in the rightmost character).

7. Continuation of Data Description literals across lines. F's rule: a constant carried onto a new line must have the portion on each line "treated as a complete constant (i.e., enclosed in quotation marks)"; no continuation indication, no assumed blanks (F p. 83, General Note). J: "Literals in this section which are continued on multiple lines in violation of the rules given on page 83 of the General Information Manual are handled correctly. Use of this characteristic of the 7090 processor should not be made if compatibility with other processors is desired." (J 02.03.01 A.2.c). I.e., the 7090 processor tolerates plain continuation of literals that F declares illegal.

8. Mixed alphameric/numeric pictorials. F's format-character table and examples never address a pictorial mixing A's and 9's (F pp. 80–81, silent). J explicitly forbids it and defines the fallback: the field is treated as alphameric (J 90.01.03).

9. Reserved-word lists restructured. F gives one flat list of "Commercial Translator Words" to avoid, with † marking words restricted only in data description (COND, COPY, FUNCT, LABEL, LIBRARY, PARAM, QUANTITY, REDEF) (F p. 110). J replaces this with a three-tier key-word system: (1) thirteen words never usable as programmer names in any division (BEGIN, FILE, FOR, HIGH.VALUE, HIGH.VALUES, IN, LOW.VALUE, LOW.VALUES, ON, RECORD, WHEN, ZERO, ZEROS); (2) words not usable as Data or Procedure names (56 words incl. RUN and CRYPT, neither in F's list); (3) words usable as Procedure/Data names if not referenced in the Environment Division (ACTIVITY, BCD, BINARY, BLOCKSIZE, … 49 words, 48 of them absent from F; LABEL is the one F carries) (J 02.03.02–02.03.03). Compiler writers need both lists; J governs.

10. LOAD / OVERLAP presented as available in F, deferred in J. F describes the LOAD command (F p. 54) and OVERLAP processor command with object-program overlay organization (F pp. 55–56). J defers both verbs (J 90.01.03) and notes the loader consequence: no segmentation into separate memory loads (J 90.01.05 B.2).

11. INCLUDE / library facilities. F describes the INCLUDE command with name substitution from library procedures (F p. 58; cross-referenced at F p. 52, cf. p. 12) and the LIBRARY description-field code for copying stored data descriptions (F p. 81). J defers INCLUDE entirely: "no library facilities are currently available" (J 90.01.02); and diagnostic 110 rejects both COPY and LIBRARY (J 90.04.01).

12. COPY type code. Defined in F (type list F p. 71 area; description-field usage F p. 81). Deferred in J (J 90.01.03; diagnostic 110).

13. HIGH.VALUE / LOW.VALUE made concrete. F defines them abstractly as the highest and lowest characters in the collating sequence of the target system (F p. 20). J instantiates: HIGH.VALUE is the left parenthesis "(" and LOW.VALUE the zero "0" under the native 709/7090 sequence; under COLLATE COM (Commercial/705 sequence) HIGH.VALUE is 9 and LOW.VALUE is blank (J 02.04.01; collating sequences displayed at J 02.06.16). J also adds comparison restrictions (ZERO vs numeric or alphameric; HIGH.VALUE/LOW.VALUE/BLANK vs alphameric only) and the MOVE/SET target-field legality chart with "Illegal" cells (J 02.04.01–02.04.02), none of which appear in F.

14. DO loop semantics: agreement, with a shared gap. F's expansion of DO rtn FOR i = p(q)r executes the body before the test (SET i = p. / START. DO rtn. / IF i = r THEN GO TO NEXT. / ADD q TO i. / GO TO START.) (F pp. 50–51); J confirms "A DO section will always be performed at least once regardless of the values of the loop control variables" (J 90.01.02). Note both manuals terminate on equality with r, not on exceeding it; see the catalog in §8.5.

15. Figurative-constant MOVE limits added by J. F places no length limits on figurative-constant moves (F pp. 19–20). J forbids moves to variable-length arrays and to fields longer than 2^15 − 1 characters (J 02.04.01; J 90.01.02; diagnostics 180/181).

16. Environment Description documented only in J. F's Preface expressly omits environment-description rules, deferring them to processor publications (F Preface, PDF p. 6). J 02.06 is therefore the sole source for FILE / SPECIF / POOL / GROUP / CONTRL / OPTION / COND card rules; there is no F baseline to diverge from. (J 02.06.01–02.06.17)

17. Period as terminator differs by division. F's punctuation rules (F p. 27 area) describe the period sentence-terminator generally. J sharpens: in Procedure, the first period-followed-by-blank terminates the statement, remainder is commentary (J 02.03.01 A.3.a; J 90.01.03 — no diagnostic given); in Data and Environment, entries end when column 72 is blank and "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." (J 02.03.02 A.3.b; restated for Environment at J 02.06.02).

8.4 The severity-code system and rules implied by the diagnostics (J Appendix 90.04)

B.1 The severity-code system

• Severity codes (values) run 1 through 5; 1 least severe, 5 most severe; 2, 3, 4 indicate intermediate degrees. (J 90.04.02)
• "An error severity code of 1 does not prevent the running of the object program immediately after compilation. Any code above 1 does prevent running of the object program immediately after compilation. That is, the compiler will not compile and go." (J 90.04.02)
• "An error severity code of 5 causes the compiler to stop compiling. It then proceeds to the next job." (J 90.04.02)
• Object-deck production: an output deck is produced "except when a severe error has been encountered during compilation. The severity value (code) is used to determine whether a deck will be produced when NODECK is not specified. If the severity code is 5, a deck will not be produced." (So severities 2–4: deck punched, but no automatic execution.) (J 02.01.01)
• Under the LOAD option, "The program will be executed unless the NOGO option has been taken, or the Compiler has encountered a source program error with a severity code greater than 1 or an undefined symbol in the code which it has generated." (J 02.01.02)
• The assembly listing is produced only "if LIST was selected and no severe error was encountered during compilation." (J 02.02.01)
• Message-listing mechanics: in the Appendix 90.04 listing the CODE column shows 0 because "the value may vary. One of the severity values 1 through 5 will actually be printed with the error message." The per-message severity assignment is nowhere tabulated (see the catalog in §8.5). (J 90.04.01)
• Error messages are cross-referenced to the source through compiler-assigned statement numbers of the form xxxxx,yy: three to six digits; the last two digits (after the comma) reference the clause, the digits before the comma reference the line. Statement number 9999,99 references errors "not confined to a single source statement." (J 02.02.01)
• The sample listing ends with the trailer line SEVERITY LIMIT WAS NOT REACHED, evidence of a settable severity limit whose control is not documented in 02.01 (see open questions). (J 90.04.01)

B.2 Implied language rules, message by message

All message texts below are from the compiler error-message listing (J 90.04.01, messages 0–209); abbreviated where marked "…", and with intra-message spacing normalized (the listing prints e.g. "( E A(2) )" with double spaces and occasional space-before-period). 'NAME.1'/'NAME.2' are compiler substitution placeholders; numeric values inside message texts (24, 12, 999, 16, etc.) are representative sample values from the fixed text, not variables (per transcriber note at J 90.04.01). The citation for every row is (J 90.04.01); the msg number is given so the row can be traced.

Numeric limits revealed by diagnostics

Lexical / card-format / statement-structure rules

Name rules

Section structure and control flow

DO / functions / subscripting

Conditionals / comparisons

MOVE / ADD / SET / arithmetic

Data Description rules

Environment Description rules

CRYPT / assembly-level rules

DISPLAY

Capacity-overflow diagnostics (enforce the A.4 table)

Compiler self-diagnostics (no language rule implied; listed for completeness)

8.5 Consolidated ambiguity catalog, with plausible resolutions

Every genuine ambiguity, contradiction, or underspecification flagged anywhere in §§1–7 and §9, deduplicated and grouped by language area. Items that are plain F/J divergences with a clear J-side answer live in §8.3 and are not repeated here. Format: the problem, then Resolution: the most historically plausible reading and why. Transcription-level doubts (where the uncertainty is in the scan/conversion, not the language) are separated into §8.5.8.

8.5.1 Lexical

• Quotation mark inside a quoted constant. F says named constants "may include any of the characters in the machine's character set, including the quotation mark and the blank", yet constants are delimited by quotation marks and neither manual defines an escape or doubling convention; J's scanner diagnostic "SECOND QUOTE MARK MISSING." implies a plain scan-to-next-quote. Resolution: in the implemented language the quotation mark is unrepresentable inside a quoted constant; read F's sentence as describing the abstract machine repertoire, not a punching convention. A compiler should scan to the next 4-8 punch and diagnose a missing closer. (F p. 19; F p. 28 rule 7; F p. 111, ALPHAMERIC: "an alphameric literal may not contain a quotation mark"; J 90.04.01 msg 167)
• Maximum numeric constant/literal length under J. F gives 50 characters overall and 20 digits for anything operated on arithmetically; J's msg 52 ("MAXIMUM NUMERIC LENGTH EXCEEDED FOR CONSTANT OR LITERAL.") names no number and J never restates the 20-digit rule. Resolution: adopt F's limits (50 / 20) as still in force: J 02.05.06 ties double-precision fixed point to formats of more than 10 digits, consistent with a 20-digit two-word ceiling, and J reaffirms the 50-character literal limit elsewhere. (F p. 18; J 90.04.01 msgs 52, 150; J 02.05.06 d; J 02.04.02)
• Procedure-name terminating period. F requires every procedure-name to be followed by a period and a blank; J states that names not so punctuated "are handled properly; no diagnostic message is given", without saying how the name/text boundary is then found (names longer than 6 characters overflow the columns 7–12 name margin into the text area). Resolution: period+blank is the defined syntax (F); the 7090 compiler additionally accepts its omission, most plausibly taking the boundary at the first blank after the name token that begins in the name margin (simple names cannot contain blanks). A faithful compiler accepts both; one enforcing the written language warns. (F p. 37 rule 2; J 90.01.03 A.1.a.ix; F p. 15 rule 1)
• "Alphabetic" vs "alphameric" literal. F distinguishes the two but gives identical formation rules; J's diagnostics say "ALPHABETIC LITERAL" (msgs 150, 168) while J 02.04.02.01 calls the same object an "alphameric literal". Resolution: one lexical class (quote-delimited non-numeric literal); the split is a content classification, not a lexical one. Scan them identically. (F p. 19; J 02.04.02.01 B.2; J 90.04.01 msgs 150, 168)
• Reserved word EQUALS. J's key-word list reserves both EQUAL and EQUALS, but no relational form spelled EQUALS is documented anywhere; F lists only EQUAL. Resolution: reserve EQUALS in the word list (as J requires) but implement no EQUALS relational spelling (most plausibly a defensive reservation). The documented equality forms are IS EQUAL TO and =. (J 02.03.02; F pp. 21, 110)

8.5.2 Program structure

• PROGRAM.START: an undocumented entry-point facility. Three diagnostics govern a name -PROGRAM.START- (msg 141 "MORE THAN ONE -PROGRAM.START-. FIRST USED."; 142 must be a statement or section name; 143 cannot be DO-addressed), and J 90.02 mentions the first object word is "not necessarily PROGRAM.START", but no language section defines the facility. F is silent; the sample program's first labeled sentence is plain START.. Resolution: PROGRAM.START is a reserved procedure-name: labeling a statement or section with it designates the object-program entry point; absent it, execution begins at the physically first procedure statement (consistent with the Loader "normally" using "the starting point of the first program", and with the sample). At most one per program; not DO-addressable. (J 90.04.01 msgs 141–143; J 90.02.01–02; J 03.02.08; J 90.05 listing PDF p. 195)
• Division ordering and interleaving. F explicitly allows portions of the three divisions to be interleaved, each introduced by its header; J never restates the rule or requires an order; the sample deck runs *DATA, *ENVIRONMENT, *PROCEDURE once each. Resolution: accept interleaved portions (the F rule) (J's diagnostic 87 "PROGRAM FLOWS INTO *DATA." only makes sense if a *DATA portion can follow procedure text) and treat DATA → ENVIRONMENT → PROCEDURE as the canonical demonstrated order. (F p. 27; J 90.04.01 msg 87; J 90.05 listing PDF pp. 192–197)
• Cards before the first division header. F: "All entries following a division header are assumed to be a part of the specified division", but nothing says what governs source cards preceding the first header. Resolution: require a division header as the first non-control source card; every exhibited deck begins with one immediately after $CMPLE, and no text supplies a default division. (F p. 27; J 02.01.01; J 90.05 listing PDF p. 192)
• Serial-number sequence checking. F says the Ctl./Serial field "will be sequence-checked by the processor"; J says serial numbers "are not sequence checked by the compiler." Resolution: J governs: no sequence checking; F describes intended behaviour of eventual processors generally. (F p. 37; J 02.03.01)
• Extent of section-scoped name uniqueness. F says section names "can be used as parts of compound names" where necessary; diagnostic 166 ("'NAME.1' IS NOT UNIQUE IN THIS SECTION.") implies sections scope uniqueness for at least some names; yet J 90.01.03 forbids qualifying a RECORD defined inside a section by the section.name. Resolution: sections provide qualification context and a uniqueness scope for procedure-side names (per F p. 26), while RECORD names must be program-unique and never section-qualified (per J 90.01.03), the only reading consistent with both texts, though it rests on inference from a diagnostic. (F p. 26; J 90.04.01 msg 166; J 90.01.03)
• Column 72 vs column 71 blank assumption on the data form. F (rule 14) assumes a blank after column 72 of the procedure form and column 71 of the data form; J says the processor "replaces the contents of column 72 with a blank in Data and Environment lines" (column 72 being the continuation column). Resolution: use J's mechanism for the 7090: Data/Environment text ends at column 71, column 72 is the continuation flag and is blanked before scanning (functionally F's rule, stated operationally). (F p. 28; J 02.03.01; J 02.06.01–02)
• STOP n, bare STOP., and STOP RUN. F defines only STOP n (halt, display n, resume on restart) yet shows a bare STOP. in a Chapter-2 illustration; J requires a STOP RUN in every program (msg 175) without saying whether STOP n survives, and its operator documentation shows both STOP nnnnnn (n ≤ 6 digits) and STOP RUN. Resolution: both forms exist in the implemented language: STOP n for resumable operator halts, STOP RUN (mandatory, once-reachable) as program terminator; treat the operand as required (the bare STOP. is an informal illustration predating the general form). (F pp. 25, 54; J 02.04.06 #9; J 90.04.01 msgs 2, 175; J 90.02.14; J 05.06.04)

8.5.3 Data description

• Subscript / quantity-nesting depth under J. F caps quantity nesting at three levels per nested group and three subscripts per reference; J restates no per-array cap, giving only program-wide table limits (≈85 array dimensions, ≈90 positional indicators) and the 23-level hierarchy limit. Resolution: retain F's three-level/three-subscript limit for the implemented language: J defers to F for the base language and no J example exceeds two subscripts. (F p. 30, p. 77; J 90.01.05; J 02.04.07)
• Written form of BLANK WHEN ZERO. J introduces the clause and says it characterizes an edited field, but neither manual shows where or how it is written on the data description card. Resolution: Description-column (38–71) content after any pictorial, blank-separated, by analogy with the other Description-field clauses (QUANTITY IN, LIBRARY, REDEF/COPY names) in F's ordered list of Description contents; J 02.05.06(e)'s rule that non-format text in the pictorial columns is scanned as names supports free-text clauses there. (J 02.05.05, 02.05.07; F p. 79)
• "Non-format field". J 02.04.07 rule 4 compares "all non-format fields (see 02.05 for definition)" alphamerically, but 02.05 never uses the term. Resolution: non-format field = a field with no pictorial (a group field), which J 02.05.06(c) says is "treated as alphameric with length equal to the length of its subfields", the only 02.05 definition matching the comparison rule. (J 02.04.07; J 02.05.06)
• The REDEF line: name and layout. F allows the REDEF entry to be given a name; J says the type code "should appear on a line with no additional coding except a serial number and the name of the item being redefined", and requires the first following entry to match the redefined item's level. The F sample writes 1REDEF TABLE at level 1 with TABLE.ITEM at level 2; the J sample writes a bare REDEF TABLE then TABLE.ITEM at level 1. Resolution: follow the J convention for the implemented language (bare REDEF line; first following entry at the redefined item's level): J restructured the identical program to comply. J's "should" makes lenient acceptance (warn, don't reject) defensible, but the storage-assignment semantics J gives never use a name on the REDEF line. (F p. 75, pp. 100, 104; J 02.05.02; J 90.01.03 b.iii; J 90.05 listing PDF p. 195)
• "Highest level" in the justification default. J 02.05.01: fields "of level equal to the highest level in a source program will be left justified": highest number (deepest) or highest rank (smallest number)? Resolution: the numerically smallest level number: J's own example (levels 05 and 10) states the level-05 fields are the left-justified ones "since 05 is the highest level used in the program". (J 02.05.01)
• Does the constants-then-REDEF table technique survive? J forbids constants "as part or all of the redefinition of an area", while F's canonical table-building places constants in an area and REDEFs structure over them. Resolution: the F technique remains legal: the constants belong to the original definition, not the redefinition; J's restriction bars constants among the entries following a REDEF. The constants-first ordering also matches J 90.01.03's advice that a record containing an array precede the REDEF. (F pp. 74–75; J 02.05.06; J 90.01.03)

8.5.4 Arithmetic and data manipulation

• Rounding: threshold stated, edge cases not. F says SET results are "rounded to the number of places indicated by the format description of the result field" unless TRUNCATED (F p. 44), and F's glossary states the rule: the least significant remaining digit "is increased by 1 when the part removed is greater than or equal to one-half" (F p. 115, ROUND, with worked examples; TRUNCATED contrasts 2063.78 → 2063.7 vs 2063.8, F p. 116). What remains unstated: behaviour for negative values, and whether rounding itself can raise overflow. Resolution: half-adjust applied to the absolute value with sign restored, matching the glossary rule and contemporaneous IBM practice; J 90.02's packages show per-character "Round current character" subroutine steps, i.e. rounding happens character-serially at store/convert time. (F pp. 44, 115–116; J 90.02.16–17) Narrowed (90.02 + 90.05 mining, 2026-08-01; adversarially verified 2026-08-02): the full appendix yields the inventory: rounding is a per-position step, invoked by a bare TRA carrying no count, in exactly the five MOVPAK packages that are built from a step list: SYS)219 (with SYS)183, external to external decimal), SYS)220 (with SYS)185, external decimal to edited), SYS)221 (with SYS)189, edited to external decimal), SYS)222 (with SYS)190, edited to edited) and SYS)274 (with SYS)268, edited to internal decimal) (J 90.02.16–19, 90.02.23, 90.02.30–31). The packages called with a fixed one-to-three-word sequence (SYS)184, 186–188, 246–247, 267) have no steps at all, so their lack of a round step proves nothing about those paths; and no text in J 90.02 states the algorithm or mentions sign or carry. The compiled sample emits no MOVPAK round step but does round the SET path inline: XCA / ACL CP)+34 / LRS 35 / DVP CP)+31 / STQ 4)FICA for "SET WORKING FICA = .03 * WORKING GROSS," and the same tail at three further sites, with the added constant tracking the divisor and TRUNCATED never written in the program (J 90.05 listing, PDF pp. 196, 206, 210–211). Inference (7090 architecture, external to both manuals): ACL adds into the magnitude with the sign untouched, so the half-adjust is applied to the absolute value and the carry runs in binary into the integer part before the scaling divide, which is what the Resolution above asserted from period practice, now at least corroborated by emitted code, though the constant-pool values are not printed and no negative case is exercised. On overflow, nothing links rounding to SYS)130: the cell's definition is scoped to "any one of the numeric move or convert subroutines of MOVPAK", it occurs exactly once in the whole manual, no subroutine is described as testing or clearing it, and on the sample's SET path the rounded result is stored by a bare STQ with no MOVPAK call at all. (J 90.02.10, 90.02.16–19, 90.02.23, 90.02.30–32; J 90.05 listing, PDF pp. 196, 203, 206, 209–211; images/page-148.png, page-157.png, page-162.png, page-169.png, page-206.png, page-210.png)
• Overflow with no ON OVERFLOW clause. F defines overflow and the ON OVERFLOW reaction (erroneous result not stored), but is silent on what happens without the clause, and MOVE has no ON OVERFLOW at all. Resolution: the truncated result is stored and execution continues; the processor records the event in communication cell SYS)130 ("truncation of significant high order values (i.e. overflow)") with no program-visible transfer. F's MOVE editing rules already make high-order dropping defined, silent behaviour. (F p. 42, p. 44; J 90.02.10) Amended (90.02 re-mining + 90.05 listing evidence, 2026-08-01; adversarially verified 2026-08-02): the "recorded in SYS)130" half of this resolution needs narrowing. No routine is individually documented to set the cell; SYS)130's entry names a class, "any one of the numeric move or convert subroutines of MOVPAK" (J 90.02.10), and the only routines carrying an explicit NUMBER-OF-CHARACTERS-TO-TEST-FOR-OVERFLOW step are the five character-source families SYS)183, 185, 189, 190 and 268 (J 90.02.15–21, 90.02.30–32). Nothing outside MOVPAK can arm it at all: the fixed-point scaling and arithmetic routines SYS)163–171 are never called MOVPAK subroutines and are never said to set any cell (J 90.02.12–13). On the store side, an arithmetic result held in the AC/AC-MQ reaches its target either by a bare STQ/STO (internal decimal right justified: SET WORKING FICA = .03 * WORKING GROSS into an IR9(4)V99 field compiles as LDQ CP)+9 / MPY 4)GROSS / XCA / ACL CP)+34 / LRS 35 / DVP CP)+31 / STQ 4)FICA, J 90.05 listing, PDF p. 210, verified on images/page-210.png; likewise STQ 4)GROSS at PDF p. 206) or by a MOVPAK convert that carries no test step: SYS)186–188 for external decimal (J 90.02.18), SYS)267 for edited fields (J 90.02.30, exhibited at PDF p. 203 as CLA 6)GROSS / TSX SYS)180,4 / PZE 2)GROSS,,1 / TXI SYS)267,1,4), SYS)246 for internal decimal not justified (J 90.02.26). The behaviour is unchanged (the truncated result is stored and execution continues), but whether the flag cell records it on the store at all is undetermined: for an internal-decimal target no MOVPAK routine runs, and for the other targets the routine that runs is a MOVPAK numeric convert with no documented test. (J 90.02.10, 90.02.12–13, 90.02.15–21, 90.02.26, 90.02.30; J 90.05 listing, PDF pp. 203, 206, 210; images/page-210.png)
• Invalid characters in a numeric field at object time. Neither manual defines any program-level reaction, and no verb option can request one. Resolution: there is none: the MOVPAK numeric move/convert subroutines set communication cell SYS)131 non-zero when they detect "an improper data condition" (J 90.02.10) and carry on; nothing in the generated-code appendix reads, prints from, or clears that cell, the only condition options in the language are ON OVERFLOW (SET/ADD, single result field) and the FILE-card ON ERROR (unrecoverable redundancy, block checksum, block sequence only, J 02.07.07), and the field-test sample converts a card-punched external-decimal field (DETAIL HOURS, 99V9) straight into pay arithmetic through SYS)184 with no check, while emitting two base-locator traps on the same twelve words (J 90.05 listing, PDF pp. 192, 196, 205). The compile-time diagnostics (msgs 25, 67, 111, 112, 120, 182) and the fatal GET-path conversion check SYS)261/263, which validates a variable-length record's length control word and exits to the CT Monitor, are separate mechanisms and must not be read as the MOVE/arithmetic reaction. (F p. 44, p. 47, p. 109; J 02.07.07; J 90.01.02; J 90.02.07, 90.02.10, 90.02.16, 90.02.29; J 90.04.01–02; J 90.05.02; J 90.05 listing, PDF pp. 192, 196, 205)
• Negation vs exponentiation. J's operator hierarchy places negation in the top group (with TR and ABS), honored before **, so -A**2 = (-A)**2, contrary to modern convention; F never states negation's precedence. Resolution: follow J literally: negation binds tightest. F corroborates: "all operators act on the next named item, or the next parenthetical expression, following the operator", and its symbol-pair table only admits negation at expression/parenthesis start. (J 02.04.05.01; F p. 28, p. 106)
• Parameter/function declaration after the removal of PARAM and FUNCT. F requires parameter- and function-names to carry the PARAM/FUNCT type codes; J removes both codes ("no longer in the language") yet still processes BEGIN SECTION USING…GIVING, DO USING…GIVING, and function references (msgs 30, 68, 72–75). How to declare them in J is never restated. Resolution: parameters and function results are declared as ordinary data fields; only the special type codes were dropped, and the USING/GIVING machinery of F carries over unchanged. Msg 30 implies all function arguments must be explicitly specified. (F p. 34, pp. 52–53, 57–58, p. 73; J 02.05.03; J 90.04.01 msgs 30, 68, 72–75)
• Figurative-constant target maximum: 32766 vs 2¹⁵−1. J 02.04.01 forbids moving figurative constants to fields "longer than 2^15 - 1 characters" (32767); msg 181 says "…FIELD LONGER THAN 32766 CHARACTERS NOT YET HANDLED…". Resolution: an off-by-one in the prose; the message most plausibly reflects the coded check, so the safe implemented maximum is 32766 characters. (J 02.04.01 c.ii; J 90.04.01 msg 181)
• "Report field" (F) = "edited field" (J). F's MOVE legality rule permits numeric moves "to report fields" but never defines the term; J defines the Edited Field type (pictorial containing 8 * . , $ + - or BLANK WHEN ZERO). Resolution: the identification is effectively certain: F's editing characters are exactly J's edited-field format characters. Use J's term. (F p. 42, p. 80; J 02.05.05)
• Multi-result SET. For SET A, B, C = expression neither manual says whether each target receives the full-precision expression value or a value chained through an earlier (already edited/rounded) target, nor the store order, nor whether TRUNCATED is per-target. Resolution: the expression is evaluated once to an intermediate value; each target is stored from that intermediate independently, edited/aligned to its own pictorial; TRUNCATED governs every store in the command. Store order is most plausibly left-to-right, observable only if targets overlap. (F p. 44, p. 109)
• Edited source moved to an alphameric target. J allows every type to move into alphameric fields, but its conversion chart routes edited fields through external decimal, and nothing states whether edited→alphameric transmits the edited character image ($ , . etc.) or the converted numeric form. Resolution: the converted (unedited) numeric form, matching the least-intermediate-steps routing used for comparisons ("edited fields... are converted to pure numeric fields"), and the chart (images/page-020.png) shows arrows into alphameric only from external and scientific decimal. (J 02.04.03, 02.04.04, 02.04.07)
• A**B**C. F forbids the unparenthesized form outright; J states a general left-to-right rule for equal-hierarchy operators and never repeats the prohibition. Resolution: treat the form as illegal per F: J is a "clarification and amplification" document that overrides F only where it says so. If accepted anyway, left-to-right grouping (A**B)**C is the only reading consistent with J. (F p. 107; J 02.04.05.01)
• MOVE BLANKS into edited/external fields: "doubtful" yet compiles clean. J's figurative-constant chart stars BLANK→external-decimal and BLANK→edited with the note "An error message is given for each doubtful or illegal usage", yet the J sample blanks edited and external fields and ends "NO ERRORS WERE DETECTED DURING COMPILATION." Resolution: the note applies literally only to the "Illegal*" entries, or such messages carried severities too low to count as errors in the closing summary. Accept BLANK into edited/external fields, produce blanks, at most warn. (J 02.04.02 chart; J 90.05 listing PDF pp. 196–197)
• CORRESPONDING matching: F name-only vs J qualifier-chain. F defines correspondence as "a field having the same name" in the receiving area, and the F payroll sample depends on that loose rule; J requires all qualifiers below the moved roots to be present and identical, under which several F-sample moves match nothing. The J sample renames fields and adds explicit MOVEs to compensate. Resolution: J 02.04.04 is authoritative: implement the qualifier-chain rule with lowest-level matching and group-as-alphameric fallback; read the F sample's unreachable moves as latent defects of 1960 code written against the looser definition. (F p. 43, p. 93; J 02.04.03–05; J 90.05 listing PDF pp. 195–196)
• CALL: non-unique old.name and qualified synonyms. The F sample CALLs a five-way homonym (EMPLOYEE.NUMBER) EMPLOYNO and later qualifies the synonym (DETAIL EMPLOYNO); J requires the (old.name) to be unique and its sample never qualifies a synonym. Resolution: implement J: reject CALL of a non-unique old.name; each synonym is a new unique simple name for one field, never needing qualification; diagnose F-style shared renaming. (F p. 59, pp. 91–94; J 02.04.04–05; J 90.01.01 i; J 90.05 listing PDF p. 195)
• "Integer" against a trailing-S scaled field. A trailing-S pictorial (999SSS) holds only whole values but stores a thousandth of them (F p. 80). Three rules demand an integer: the subscript variable (msg 31), the assigned GO TO index (F p. 49; msg 130), and FIND/PLACE LENGTH IN (msgs 111/112, "IMPROPER DATA FORMAT"); and no field in either manual is declared with S, so the case is unattested. Resolution: the word carries two senses. The subscript sense is mechanical: the attested lookup indexes by the raw stored digits with no scaling step (LDQ POS / MPY CP)+13, J 90.05 listing PDF p. 213, LOC 01421–01432), and F p. 75 has the subscript "used within the system to count individual items", so the stored digits must equal the value: fraction and scale positions alike disqualify. LENGTH IN is a format rule by its own message text, and a scaled field cannot represent an arbitrary length. The assigned GO TO rule speaks only of the index's value ("the value of the index will always be an integer in the range 1 to n", F p. 49), which a scaled field satisfies; msg 130's recovery clause ("INTEGRAL PART TAKEN AS VALUE") has nothing to truncate there. (F p. 31, p. 49, p. 75, p. 80; J 90.04.01 msgs 31, 111, 112, 129, 130; J 90.05 listing PDF p. 213)

8.5.5 Control flow

• DO … FOR termination is an equality test. F's expansion of DO rtn FOR i = p(q)r tests IF i = r after the body; J confirms at-least-once execution "regardless of the values of the loop control variables". Nothing addresses overshoot (steps that skip r), non-positive steps, or p > r. Resolution: take the expansion literally: body first, strict equality exit, index equals r at normal exit; an unreachable r is an unterminating programmer error. 1960 practice defined loops by their macro-expansion, not by a range invariant. (F pp. 50–51; J 90.01.02) Annotated 2026-08-05 (M4 decision walk): D5.1's pre-committed decode is done: the compiled increment block of statement 206,00 forms r − i after the increment and branches on sign (CLA CP)+8 / SUB INDEX / TPL GN)085, J 90.05 listing, PDF pp. 206–207), so the object program's exit is a magnitude test: the loop exits on the first i > r, the body runs for i = r, and normal exit leaves the index at the first value past r (r + q when the step divides r − p exactly). F's printed expansion stays the manuals' text; the compiled behavior governs the implementation under D0.3, and D5.1 (docs/design/decisions.md) carries the dated amendment. Overshoot and p > r terminate under the compiled reading; a zero or wrong-signed step with p ≤ r still does not.
• Two-index DO: "index.name.1 is set to p.1 + q.1". Read literally, the outer index would be assigned p.1+q.1 on every inner-loop completion, freezing after the second outer pass. Resolution: the phrase describes only the first increment: the outer index is incremented by q.1 each time the inner loop completes, consistent with the single-index expansion (ADD q TO i) and with F's worked HOURS/MINUTES/SECONDS example requiring 60×60×12 executions. (F p. 51)
• "Tests for NOT greater or less conditions" (unequal-length comparison). J 02.04.07 rule 2.b.ii: "In tests for NOT greater or less conditions the lengths are made equal by right truncation of the longer field." Grammatically this could mean only the negated operators. Resolution: read it as "tests for conditions other than = or NOT =", i.e. all four magnitude operators: rule 2.b.i disposes of =/NOT= explicitly, and truncating only for negated operators would leave plain GT/LT undefined. (J 02.04.07)
• GO TO out of a DO-addressed (closed) procedure. F requires DO'd procedures to be closed subroutines entered only via DO; J diagnoses flowing or transferring into one (msgs 99, 128), but neither manual addresses transferring out, and both flagship samples do it (GO TO NET. from inside DO'd SEARCH; GO TO END.OF.RUN from DO'd END.OF.MASTERS), compiling clean. Resolution: the closed-subroutine rule constrains entry only; a GO TO out abandons the pending return linkage, which is simply never resumed. A compiler must ensure a later DO of the same procedure re-establishes linkage correctly. (F pp. 50, 53, 57; J 90.04.01 msgs 99, 128; J 90.05 listing PDF pp. 195–197)
• Assigned GO TO: object-time range behaviour. F: if the index is not an integer in 1..n, "no transfer will occur; instead, control will pass to the next clause or sentence", implying a generated range check. J documents only compile-time index diagnostics (msgs 129, 130) and elsewhere adopts a no-object-time-checks policy for subscripts. Resolution: F's fall-through semantics stand as the language definition (J nowhere contradicts them), but note the real possibility that the field-test compiler omitted the check. (F p. 49; J 90.04.01 msgs 129–130; J 90.01.02)
• SET condition.name under J. J's SET write-up covers only the arithmetic form and never mentions F's SET condition.name; 90.01 does not defer it, and conditional variables remain fully supported. Resolution: implemented per F (setting a condition-name stores the associated value into the conditional variable): J 02.04 is explicitly "Clarification and Amplification", deferring features only via 90.01, and the COND machinery (format checks, subscriptable conditional variables) is intact. (F p. 46; J 02.04.05; J 02.05.02; J 90.01.03; J 90.04.01 msgs 37, 38)
• Nested and recursive DO. Neither manual says whether a DO'd procedure may itself issue DOs, or what recursion does; the samples DO only from the main body. Resolution: nested non-recursive DO is legal (nothing forbids it; sections nest to depth 18); recursion is unsupported: 1962-era linkage stored a return address per procedure, which re-entry would overwrite. Treat recursion as undefined/erroneous. (F pp. 50, 53; J 90.01.05 f) Corroboration (90.02 mining, 2026-08-01; adversarially verified 2026-08-02): the generated-code appendix supports the non-reentrancy premise independently of the object listing. It contains no stack, save area or activation record of any kind: all generated storage is fixed blocks (RS) BSS N, with "N is the sum of maximum Result Storage used in each section"; TS) BSS N, "not section-qualified"; PI) BSS N; and a Constant Pool block) laid down under three static location counters (J 90.02.01–06), so a section's working cells are shared by every activation of that section. And index register 4, in which a TSX name,4 call leaves the return (the convention used even for the compiler's own generated labels, TSX GN)019,4 / GN)019 CLA PI)3 (J 90.02.06)) is simultaneously the data-addressing register of generated code (LAC BL)2,4 / CAL DATANAME,4, J 90.02.04) and in-line scratch (PDX 0,4 / TXL *2,4,5, J 90.02.11); J states the consequence explicitly of the code it generates for a locate-mode reference, "Note that the contents of index register 4 are destroyed" (J 02.08.03). No return can therefore survive a procedure body in a register. 90.02 itself never mentions DO (it documents no control-flow code templates at all, only the IOC)/SYS) runtime library), so it constrains the mechanism without attesting the DO sequence itself. (J 90.02.01–06, 90.02.11; J 02.08.03)

8.5.6 Input/output

• The PATTERN option: used but never defined. J 02.07.04 makes GET RECORD FROM file.name legal when the file's records "are included in a PATTERN in the Environment Description", and msgs 48–50 police "-PATTERN- ON -FILE- CARD" (max 16 records; single-record patterns "INEFFICIENT"), yet the FILE-card general forms and option text in J 02.06 contain no PATTERN keyword. Resolution: PATTERN is a real but undocumented FILE-card option declaring the repeating sequence of record.names on the file (2–16 of them), letting the compiler know each record's successor without control words; the 02.06 write-up evidently lagged the implementation. The exact keyword syntax is unrecoverable from the manuals. (J 02.07.04; J 90.04.01 msgs 48–50; J 02.06.03–07)
• FOR LABEL / LABELN linkage documented only by a missing appendix. The non-standard-label mechanism (FILE-card FOR LABEL exit, LABEL type code redefining the 14-word IOCS label area, portions of the FOR LABEL coding "must be done in CRYPT") defers repeatedly to Appendix 90.07, which J's own contents mark "(Not Currently Available)". The IOCS calling convention (how open/close/reel-switch is distinguished, how control returns) is therefore nowhere specified. Resolution: take the language surface as defined (FOR LABEL statement.name + SPECIF LABELN + LABEL type code over area IOC)29) and treat the runtime linkage as IOCS-defined (manual C28-6100-2); J itself recommends the safer alternative of defining labels as records processed with GET/FILE. (J 02.05.03; J 02.06.05, 02.06.12; J 00.00 contents; J 90.02.08; J publications p. PDF 221)
• Reopening a file after a named CLOSE. J forbids reopening only after CLOSE ALL FILES; for CLOSE file.name it is silent, while F says CLOSE releases the file's storage area, and FILE after CLOSE is a defined NOP. Resolution: reopening after any CLOSE is at best undefined: the named CLOSE runs the same IOCS close path, and the only J statement on the subject is the ALL FILES prohibition. Do not rely on reopen. (J 02.04.06; F p. 41; J 02.07.08, 02.07.01)
• The printer as a direct FILE target. F says FILE places records on tape, cards, "or on the printer"; J 02.07.07 says tape or cards only, yet J's unit vocabulary includes PRX (printer, channel X) and OU ("for a printed output file"), and the sample routes all report files to BCD tape for off-line listing with RCDMRK carriage control. Resolution: the implemented, demonstrated path is print-image BCD records FILE'd to tape or the system output unit, listed off-line; direct on-line printing existed at the unit-assignment level but J defines no COMTRAN-level semantics (carriage control, line length) for it. Implement FILE to tape/card/system-output and treat printer files as print-image files per unit assignment. (F p. 40; J 02.07.07; J 02.06.09–10; J 90.05.03; J 02.05.03)
• GET on an unopened file: silent exit vs terminate-with-message. J 02.07.04: if the file is not open, "the end of file exit is taken. No error message is given." J 02.07.06: with no AT END clause, an end condition on GET terminates the program with an on-line message. Resolution: "the end of file exit" means whatever that GET's end-of-file disposition is: the AT END statement if present (silently), otherwise the standard no-AT-END termination; the "No error message" sentence denies a specific unopened-file diagnostic, not the generic termination message. (J 02.07.04; J 02.07.06)
• AT END: "any imperative clause" (F) vs "a single imperative statement only" (J). Resolution: J governs the parse: exactly one imperative statement after AT END (msg 106 further suggests the field-test compiler wanted a statement or section name there; the sample uses both AT END DO x and AT END GO TO x). F's timing rule (the clause fires on the GET after the last record was delivered) is the only timing statement in either manual and carries over. (F p. 40; J 02.07.05–06; J 90.04.01 msg 106) Amended 2026-08-01; adversarially verified 2026-08-02: the generated code settles the mechanism. J's GET calling sequence carries the end-of-file exit in the address of its third word (PZE END-OF-FILE-PROCEDURE,,ERROR-PROCEDURE, filled with SYS)265, the no-AT-END terminator, only "whenever the 'AT END' option is not used with the GET verb" (J 90.02.04, 90.02.29)) and a coded clause is compiled as an ordinary out-of-line block placed after the calling sequence, its label planted in that word, the block jumped over by a normal-return transfer to the code of the following sentence (J 90.05 listing, PDF pp. 201–202). AT END DO x compiles the same three-instruction DO linkage an in-line DO uses (compare statement 199's plain DO DEPARTMENT.END at END.OF.RUN, J 90.05 listing, PDF pp. 196, 203) and therefore resumes at the sentence after the GET; AT END GO TO x compiles a one-instruction block. Both attested forms designate a procedure, and msg 106,00 "STATEMENT OR SECTION NAME MUST FOLLOW -AT END-. CHECK 'NAME.1'." (distinct from the transfer diagnostics 127,00 and 128,00 and from the DO-operand diagnostic 188,00 "'NAME.1', ADDRESSED BY A -DO-, IS NEITHER A STATEMENT NOR A SECTION NAME.") suggests (inference) that the field-test parser wanted a designated procedure in that slot; a non-transfer imperative is nowhere attested. F's timing rule stands as before. (F p. 40, p. 109; J 02.07.05–06; J 90.02.04, 90.02.29; J 90.04.01 msgs 106, 127, 128, 188; J 90.05 listing, PDF pp. 195–196, 201–203)
• Short-record blocking and the BEGIN threshold. J 90.05.04 says the 20-word-blocked PAYFILE's shorter DEPARTMENT.TOTAL records "will always begin a new buffer", but a 10-word short record would need BEGIN "to avoid grouping", a threshold no 02.06 rule states. Resolution: pure arithmetic, not a special rule: records pack into BLOCKSIZE-word blocks, complete within a block; a record longer than half the blocksize can never share one, while shorter records group unless BEGIN forbids it. (J 90.05.04; J 02.06.03–04; J 02.07.01)

8.5.7 Environment, control cards, and processor surface

• *SPEC blocksize "(0-999)" vs Environment maximum 9999. The Environment FILE card allows BLOCKSIZE up to 9999 words; the Loader *SPEC card the compiler generates from it is described as "normally a number (0-999)", in a four-column field (17–20). Resolution: a typographical slip for (0-9999): the field is four columns and the compiler must punch Environment blocksizes up to 9999 into it. Honor 9999. (J 03.02.05; J 02.06.04)
• "SPECIF CHKS" in Appendix 90.08. The *FILE-card table sources checkpoint code C from "FILE CHECKPOINT AND SPECIF CHKS"; no SPECIF option CHKS exists. Scan check (2026-08-01): the printed token is certainly the four glyphs C-H-K-S (not CHECKC, CKSUMS, or CHKPT, and not truncated (the line ends at the normal right margin with clean paper beyond)), so the error is in the original text, not the transcription. Resolution: read CHKS as CHECKC (checkpoint at reel switch on the checkpoint file), which exactly matches code C's meaning; CKSUMS (block checksums) already feeds a different column. (J 90.08.01; J 02.06.11; J 02.06.04; images/page-219.png)
• Who assigns the default BUFFERCOUNT. The POOL text says an unspecified BUFFERCOUNT "will be assigned automatically by the compiler"; the GROUP text says "the loader will attempt to assign at least twice the OPENCOUNT number of buffers to the GROUP"; 02.06.13/02.07.02 credit IOCS/the Loader (02.06.02 says "the processor"). Resolution: agency shorthand, not a conflict: the compiler computes and punches default counts into the generated Loader control cards; the loader/IOCS performs the actual allocation. (J 02.06.13–14; J 02.06.02; J 90.08.01–02)
• INCLUDE placement "at the end of the present program". F never anchors "end of program" (relative to STOP RUN, later divisions, or other INCLUDEs). Resolution: moot for the implemented language (INCLUDE deferred); for an F-faithful implementation, append in encounter order after the last procedure sentence, consistent with its stated use for closed subroutines "set off from the main flow". (F p. 58; J 90.01.02)
• Per-message severity codes are nowhere specified. The 90.04 listing prints CODE 0 for every message "because the value may vary", and no table assigns the 210 messages their actual severities 1–5, though severity determines deck production, compile-and-go, and abort. Resolution: severities must be assigned by consequence stated in each message's text: auto-repair warnings ("PERIOD ASSUMED", "ZERO COUNT… REPLACED BY ONE") plausibly 1; deletions/"NOTHING DONE" 2–4; unrecoverable conditions (internal errors, table overflow, read errors) 5. "May vary" may even mean one message carries different severities in different contexts. (J 90.04.01–02; J 02.01.01)
• "SEVERITY LIMIT WAS NOT REACHED". The sample error listing's trailer implies a severity threshold governing something, but no control card sets one. Resolution: most plausibly the fixed built-in threshold (severity 5 stops compilation); the trailer reports that no severity-5 error occurred (not a user-settable knob). (J 90.04.01–02; J 02.01.01–02)
• Internal-table limits are approximate. The 90.01.05 table is headed "Appox-Max Size" (sic), so exact enforcement thresholds are unspecified. Resolution: take the printed numbers as guaranteed-safe capacities, with overflow diagnosed (msgs 148, 149, 172, 177, 183, 184, 200–205) at whatever the true internal capacity is. (J 90.01.05; J 90.04.01)
• Which environment types msg 90 covers. "THIS ENVIRONMENT TYPE NOT YET PROCESSED BY COMPILER." confirms unimplemented types, but only CONTRL's ineffectiveness is documented. Resolution: CONTRL is the documented case; POOL/GROUP/OPTION/COND/SPECIF each have dedicated format diagnostics and so were at least parsed. Read msg 90 as covering CONTRL-like deferred types. (J 90.04.01 msg 90; J 90.01.04; J 02.06.02)
• Maximum alphabetic-constant length. Msg 148 says an alphabetic constant exceeding "INTERNAL TABLE CAPACITY… SHOULD BE SUBDIVIDED", but unlike literals (50 chars) no numeric limit for Data Description alphabetic constants is stated. Resolution: constants live in the constant pool, whose capacity is ≈500 generated constants (J 90.01.05 k), so the practical cap is a share of that 500-entry table; impose a documented generous limit and diagnose overflow as msg 148 does. (J 90.04.01 msgs 148, 150; J 90.01.05; F p. 18)
• File Check Table: listed in the deck format, never produced. J 02.02.01 lists a File Check Table in the object deck; 90.01.04 says none is produced (likewise the control break table). Resolution: 02.02/90.03 describe the designed deck format; 90.01 records field-test reality: the slots exist, empty. (J 02.02.01; J 90.01.04–05)
• Deck.name with imbedded blanks. J 02.01.01 forbids them; J 90.01.05 B.5 says the compiler "accepts without comment" such a name and punches it into Loader cards, where it "will prevent execution". Resolution: the language rule is that imbedded blanks are illegal; the field-test compiler simply failed to diagnose it. At minimum warn. (J 02.01.01; J 90.01.05)
• *COMPILE vs $CMPLE. The October 1961 sample listing echoes *COMPILE LIST as the compilation-initiating card; the manual documents only $CMPLE. Resolution: *COMPILE is the earlier spelling of the same card (its LIST option behaves identically); implement per $CMPLE, optionally accepting *COMPILE as a historical synonym. (J 02.01.01; J 90.05 listing PDF p. 192)
• Statement-number placement. J 02.02 says statement numbers (xxxxx,00) attach per Procedure sentence / Data entry / Environment card, yet also says the digits before the comma reference a line; the sample listing shows a number appearing mid-sentence and two sentences sharing one number. Resolution: the number identifies the source card the compiler's scan stood on (clause digits after the comma subdivide for diagnostics); the per-sentence phrasing is loose. (J 02.02.01; J 90.05 listing PDF pp. 196–197) Refuted (2026-08-03; conversion corrected 2026-08-05). The premise was a transcription artifact, not a listing fact: on PDF p. 197 a printer half-line stagger dropped the numbers 218,00–221,00 and 228,00 one line each. On the scan every number heads exactly one Procedure sentence, Data entry, or Environment specification, so the per-sentence phrasing is exact and needs no loosening. The conversion carried the stagger until 2026-08-05, when Jack authorized the correction. docs/design/m1-front-end.md M1-14 records the grouping and the M1 tests assert it.

8.5.8 Transcription and printing artifacts (conversion-level cautions)

These are uncertainties in the scans or the printed originals, not in the language. A scan-resolution pass was run on 2026-08-01 (the disputed pages were re-read at 400–600 dpi from the source PDF, with the two most load-bearing results independently verified), and each entry below records its outcome. Following that pass, and under a one-time authorization, the affected conversion notes in comtran-manuals/ were corrected on the same date and the nj mark added verbatim to the transcribed Input FILE form; entries below that quote a conversion note describe it as originally written. A second authorized pass ran on 2026-08-05 and applied five further corrections to 90.05-sample-program.md; only one of the five, entry (j), is catalogued here, because the other four are print facts of the listing and their evidence lives in the design records that measured them.

• Collating-sequence special characters: resolved by scan (2026-08-01). The page-050 displays were re-read at 600 dpi and independently verified; the full sequences and glyph legend are now in §1.1. The conversion's 0̅ stood for two distinct glyphs (the 12-0 "plus zero" and 11-0 "minus zero" zone specials); its × for the IBM lozenge (a hollow ring with corner spurs, not a multiplication sign); and the commercial line's first ‡ for a three-bar group mark, distinct from the two-bar record mark. Glyph shapes are certain; only the BCDIC names are inference. Confirmed: ( highest and 0 lowest natively; blank lowest and 9 highest under COM. The specials cannot appear in legal source text outside literals/constants. (J 02.06.16; images/page-050.png) Resolved in part (external sources, 2026-08-02): Three period IBM sources settle four of the five names and, between them, print card codes for all five glyphs. The IBM 705 Reference Manual's Figure 2, "IBM 705 Character Code Chart," prints the English names "Plus Zero" (705 code 0 11 1010), "Minus Zero" (1 10 1010), "Record Mark" (1 01 1010) and "Group Mark" (0 11 1111), and leaves one further character, 0 11 1100, inside a block bracketed only "SPECIAL CHAR" with no name of its own (external: A22-6506-0, © 1959, PDF p. 8 / printed p. 8). Note that this chart gives 705 internal codes only (its columns are CHAR. | C | BA | 8421), so card codes must come from elsewhere; the zone table on the same page equates BA = 11/10/01/00 with the 12/11/0/no zone. The undated IBM pocket card "TYPE 705 EDPM—CODE CHART" supplies the missing card-code column, and its Ch.-column glyphs are COMTRAN's exactly: zero-with-plus-above = 0 11 1010 = card 12-0; zero-with-overbar = 1 10 1010 = 11-0; two-bar double dagger = 1 01 1010 = 0-2-8; hollow ring with four corner spurs = 0 11 1100 = 12-4-8; three-bar mark = 0 11 1111 = 12-5-8 (external: Form 22-6642-0, undated, front panel). Its back panel also prints "Group mark prints □ … Record mark prints Blank / ‡" for the 717 printer and the typewriter respectively. Pen annotations on the front panel reading "Record Storage Mark" and "GROUP" are a prior owner's hand, not IBM print, and carry no evidential weight. The IBM 1401 Reference Manual's Figure 267, "IBM 1401 Character Code Chart in Collating Sequence," independently names "(Plus Zero)" at card 12-0, "(Minus Zero)" at 11-0, "Record Mark" at 0-2-8 and "Group Mark" at 12-7-8 (the record mark a two-bar and the group mark a three-bar glyph, as in COMTRAN) and likewise leaves 12-4-8 with only a bare □ in both its "PRINTS AS" and "DEFINED CHARACTER" columns. Its Note 1 reads: "If specified, this code can be made compatible with 705 Group Mark Code (12-5-8)." (external: A24-1403-5, Apr 1962, printed p. 170 / PDF p. 184.) Outcome for §1.1's legend: ⟨+0⟩ = Plus Zero, card 12-0; ⟨−0⟩ = Minus Zero, card 11-0; ⟨rm⟩ = Record Mark, card 0-2-8 (the card prints the punches as "0-2-8"): name and code both confirmed, no longer inference. ⟨gm⟩ = Group Mark is confirmed by name, but its 705 card code is 12-5-8, not the 12-7-8 that the bit pattern 1111 would naively suggest; 12-7-8 is the 1401's group-mark code, and IBM's own Note 1 distinguishes the two, so any card code for ⟨gm⟩ in COMTRAN's 705 context must be 12-5-8. ⟨loz⟩ is confirmed as the character at 705 code 0 11 1100 / card 12-4-8 by code and by glyph shape (the pocket card prints it as a hollow ring with four corner spurs, matching the shape read from J's scan), but no period IBM source found names it; "lozenge" therefore remains inference. One divergence worth recording: the pocket card's own printed COLLATING SEQUENCE reads "Blank & . □ ≡ … − $ * … / , % # @ ⁺0 A through I ō J through R ‡ S through Z 0 through 9" (two pen blots obscure one position each). It places the three zone specials exactly where COMTRAN's Commercial (705) line does (⟨+0⟩ before A–I, ⟨−0⟩ between A–I and J–R, ⟨rm⟩ between J–R and S–Z) and ends identically, but it orders the leading specials differently from COMTRAN's Blank . ⟨loz⟩ ⟨gm⟩ & $ * − (J 02.06.16): '&' precedes the period on the card, and '−' stands where COMTRAN has '&'. Same character set, different order. Inference: this is a genuine difference between the machine chart's ordering and the COM sequence as printed in J, not a transcription error in J: the COMTRAN reading was independently scan-verified on 2026-08-01 and the divergent positions on the card are unblotted and legible.
• External Decimal row of the J field-type chart. The transcribed "Legitimate Format Characters" cell reads 9 (n) SV9̅ or 9̅ in rightmost character, a run-together reading of a ruled chart. Read as: characters 9, (n), S, V, with "9̅ or 9̅" being the minus- and plus-overpunched 9 (distinct glyphs in the scan, both rendered 9̅ under the conversion's overline convention), permitted only in the rightmost character, consistent with chart note 1 and the parallel Edited-field cell. (J 02.05.05 and conversion note; images/page-031.png) Corrected (2026-08-04, authorized): two corrections landed together. (1) The parallel Edited-field cell had a real transcription defect: the scan lists four marked glyphs (minus-8, minus-9, then plus-8 and plus-9 with a plus above), but the transcription printed the first pair unmarked (8 or 9 or 8̅ or 9̅). (2) The rendering convention was amended to differentiate by zone (minus as 9̅, plus as 9⁺, the form the 90.02 transcription already used), which retires this entry's "both rendered 9̅" reading. The cells now read 8̅ or 9̅ or 8⁺ or 9⁺ (Edited) and 9̅ or 9⁺ (External), and the 02.05.07 worked example 999⁺/123⁺: its raised marks are plus signs on the scan (images/page-033.png). Re-read at 10x and verified 2026-08-04.
• The "IR999" mode example: resolved by scan. The disputed first character is the letter I, settled visually: in this face (proportional, not typewriter) the digit 1 carries a top-left flag and runs 11–13 px wide at 400 dpi, while the letter I is a bare 9-px stem; the disputed glyph is a bare 9-px stem, and the reserved word UNIT1 on the same page shows both forms side by side as an internal control. The conversion note's premise that the face renders 1 and I identically is false for this page. The internal-mode semantics (I = internal, R = right justify, pictorial 999; cf. "converted to internal form right justified", J 02.04.05, and "converted to this internal right justified", J 02.05.04) are corroboration, not the basis. (J 02.03.03; J 02.04.05; J 02.05.04; images/page-015.png)
• Stray "nj." in the Input FILE general form: resolved by scan. Not bleed-through: the mark is two full-strength, right-reading, baseline-locked lowercase letters nj, really typed on the page (show-through and set-off print mirrored, and the 1-bit scan cannot carry faint ghosts); the transcribed trailing "." is an 8-pixel dust speck, a fraction of the ink of a real period on the same line. Why "nj" was typed is unrecoverable (stray keystroke, abandoned annotation, or erasure remnant); it corresponds to no syntax element and is ignored for syntax. (J 02.06.03; images/page-037.png)
• Missing comma before record.name.2 in the Input FILE form: print confirmed by scan. The asymmetry is exactly as transcribed: the Input form's bracket contains no comma (nothing of comma size inside it at 400 dpi), while the Output form's [ ,record.name.2 . . . ] comma is full-size. Treat the comma as required (or at least accepted) in both: every other 02.06 option is comma-separated; almost certainly a layout accident of the printed box. (J 02.06.03–04; images/page-037.png)
• 90.08 density table sources both H and L from "HIGH": print confirmed by scan. The two source cells are geometrically identical impressions of HIGH (0.87 pixel overlap after 1-px alignment; the correctly printed LOW elsewhere on the page is visibly narrower and differently shaped), excluding a faint or damaged LOW: a genuine original printing error. L derives from SPECIF LOW (default HIGH). (J 90.08.01; J 02.06.10; images/page-219.png)
• Message 187's garbled tail, resolved by scan: a defect of the original 1962 listing, not the conversion. Message 187 spans two print lines; its continuation is one unbroken 95-character line on a continuous character grid (REWRITE AS TWO OR MORE SEPARATE EXPRESSIONS, EACH WITH ILLEGAL SENTENCE STRUCTURE NOTHING DONE.) with a normal single-space word gap at the "WITH|ILLEGAL" junction (no splice, no overprint). 187's own wording truncates mid-phrase after "EACH WITH", and the appended 40 characters are byte-identical to message 196's text; evidently the message-print routine ran on into 196's stored text. The implied rule stands: conditional expressions have bounded test capacity and oversized ones must be split. (J 90.04.01 msgs 187, 196; images/page-185.png)
• 90.01.05 item k -CP)+NN: prior conjecture refuted by scan (independently verified). The mark before CP is a plain hyphen (23×8 px at 400 dpi, metrically identical to the "Appox-Max" hyphen; every parenthesis on the page runs ~14–16×49–56 px), and (CP)+NN is not a form this manual uses anywhere: the compiler-generated-name form is "SYM)NNN" with a bare right parenthesis ("In the case of constants (CP references), the designation CP)+NN is used" (J 90.02.03)), used throughout the 90.05 listing. Read item k as "Number of generated constants in the constant pool — CP)+NN", the dash introducing the notation. Same scan check: the closing ")" the transcription prints at the end of item h is editorial: the original never closes the parenthesis opened at "(each unique combination". (J 90.01.05; J 90.02.03; images/page-137.png)
• Cross-reference errata. J 02.04.06 refers to the SPECIF card as "(Section 02.07)"; read 02.06. (J 02.04.06; J 02.06.07)
• *The CTEND card's date field: transcription artifact, resolved by scan (2026-08-02). The 90.05 transcription prints *CTEND ... DATE 10/18/61 at PDF p. 216, but the card image on the page prints the date unpunctuated, DATE 101861, exactly as the sibling *CTEXT card does at PDF p. 198, which the transcription renders correctly, so the file contradicts itself. The slashed form belongs only to the listing's running page head (DATE 10/18/61 TIME 2.45 ACCOUNT ... ID. CT PUBLICATIONS PAGE nn), which the conversion notes record as retained; the *CTEND line was silently normalized to it, which also pushed that line's DATE from card column 26 to 29. Read the compiler-punched date.and.time field (J 03.02.09, cols 26-54) as unpunctuated 101861 on both cards. (J 90.05 listing PDF pp. 198, 216; J 03.02.09; images/page-198.png, page-216.png) Corrected (2026-08-05, authorized): the *CTEND line now prints DATE 101861 on its sibling's field grid. Both pages were re-measured at a deskewed 9.26-px character pitch, and the two cards' field offsets agree within one pixel at every field, so the print is one grid. The re-measurement also found the transcribed spacing wrong from the TIME value rightward on both cards: the print reads TIME 2.45 CT PUBLICATIONS nn, putting the time value, CT and the sequence number 38, 48 and 72 character cells right of the card-name asterisk. Counted as card columns, where the asterisk is column 7, that is columns 45, 55 and 79. The manual corroborates the middle one: it gives these two cards the field layout 1-6 deck.name, 7-12 *CTEXT, 26-54 date.and.time, 55-72 secondary.identifier (J 03.02.09), and CT PUBLICATIONS is the secondary identifier, so column 55 is where the print puts it and the transcription did not. Jack authorized that second correction after reviewing the measurement, and both card lines now carry the print's spacing.