COMTRAN Reconstruction

The language reference is this project’s reading of the two manuals, not IBM’s text. Every claim in it cites a page, and each citation opens that page beside its scan.

Part 10 of 10 of the COMTRAN Language Definition.

Open questions

Questions that remain after studying both manuals end to end: things neither manual answers and §8's plausible resolutions cannot fully settle. Grouped by area. Where a question grew out of a §8.5 catalog entry, the entry holds the working assumption; the question records what would confirm or refute it.

Lexical

  1. How does the compiler treat entirely blank cards in each division? Both manuals are silent; the only adjacent rules are the blank-column-72 entry terminator (J 02.03.02) and the assumed blank after column 72 (F p. 28 rule 14).
  2. What happens when text erroneously begins in the procedure-name margin (columns 7–12) of a continuation card: diagnosed, read as a name, or read as text? (F p. 37 states the layout; no failure behaviour is defined.)
  3. Is the word AS still reserved in J? F reserves it for INCLUDE … AS; INCLUDE is deferred and AS appears in none of J's three key-word lists. (F p. 110; J 02.03.02; J 90.01.02)
  4. What is the exact numeric ceiling behind msg 52 ("MAXIMUM NUMERIC LENGTH EXCEEDED FOR CONSTANT OR LITERAL."): is F's 20-digit arithmetic-literal rule enforced verbatim? (J 90.04.01; F p. 18)
  5. Does the series-of-blanks-equals-one-blank rule (F p. 27, rule 2; restated for the data form at F p. 83: "Multiple blanks, however, are treated as single blanks.") hold specifically between a pictorial and a constant in the Description columns under J, which never restates it?
  6. When a named constant is continued across lines (each line a complete quoted constant, no assumed blanks), how are the parts laid out in storage: any padding or alignment between them? (F p. 83; J 02.03.01 A.2.c says rule-violating continuations are "handled correctly" without defining the layout.)
  7. May procedure-names be qualified by section names in ordinary procedure text (F p. 26 allows section names "as parts of compound names"; J 90.01.04 restricts qualified names only in Environment/CRYPT contexts), and how would a reference like DO A B be resolved?

Program structure and control cards

  1. What follows "END OF FILE ON JOB TAPE WITHOUT *FINISH CARD." (msg 132): what severity, and is the partial compilation completed or abandoned? (J 90.04.01)

  2. What quantitative limit triggers "THIS SENTENCE EXCEEDS INTERNAL TABLE CAPACITY." (msg 177); no maximum sentence length in cards, clauses, or internal words is stated anywhere.

  3. Are multiple *PROCEDURE portions concatenated strictly in source-deck order into one contiguous stream (implied by J 90.02.01), and may a section be split across two portions separated by *DATA/*ENVIRONMENT material?

  4. May a division header card carry serial numbers, identification, or continuation, and is the number of repeated headers of one division unlimited? (F p. 27; J is silent.)

  5. When no PROGRAM.START appears, what transfer address does the compiler punch for the Loader: mechanically, what does *CTEND carry? (J 90.02.01–02; J 90.03; J 03.02.08)

    Resolved (90.05 listing evidence, 2026-08-01; scan-verified 2026-08-02): the compiler defaults the transfer address to the first sentence of the Procedure Division. The sample (which has no PROGRAM.START) ends its text deck with the end-of-text special entry 00165 500000000165 01111 START GN)000; control group 01111 means "end of text; the address of the corresponding data word contains the relative program entry point" (J 90.03.04), and the Text deck "corresponds exactly" to the listing's OCTAL/CNTRL columns (J 90.03.03), so the punched entry point is 00165. In that record the tag column is blank: START prints in the operation column (column-aligned with the PZE above it) and GN)000 in the variable field, so the punched transfer symbol is GN)000, the compiler-generated name of statement 187,00, the first *PROCEDURE sentence (an unnamed CALL, which generates no code) and hence resolving to the same LOC as the source procedure-name START of statement 188,00 (written START. in the source name field). On PDF p. 200 both symbols do label LOC 00165, the TSX SYS)175,4 / PZE IOC)1 open-all-files sequence (J 90.02.14) that is the object program's first instruction. The listing then prints "THE LAST LOADER CONTROL CARD PUNCHED IS" (no period) and the *CTEND card image, which carries no transfer address: only *CTEND (cols 7-12), date.and.time (DATE 101861 TIME 2.45, cols 26-54) and secondary.identifier (CT PUBLICATIONS, cols 55-72) per J 03.02.09, plus an undocumented sequence number (67; 15 on the matching *CTEXT) in the cols 73-80 region. deck.name (cols 1-6) prints blank on the sample's *CTEXT, *CTEND and every *FILE/*SPEC card, although J 02.01.01 says the complete deck.name is punched in cols 1-6 of all Loader symbolic control cards; cf. the CTC token at cols ~1-3 under the *COMPILE card (Q70). The Loader's own default start point (first program of combined segments, variable by *START card) is J 03.02.08. (J 90.05 listing, PDF pp. 195, 198, 200, 216; J 90.03.03-04; J 90.02.14; J 03.02.08-09; J 02.01.01; J 90.04.01 msg 142; images/page-195.png, page-198.png, page-200.png, page-216.png)

  6. Is the F rule that processor commands "should be written as unnamed sentences" enforced or merely advisory in J? (F p. 60; no corresponding diagnostic in J 90.04.)

  7. Are the "Appox-Max" internal table sizes hard failures or soft limits; most have matching diagnostics, but nested-section depth (18) and the internal dictionary (3500) have no visible message. (J 90.01.05; J 90.04.01)

  8. May external code GO TO an interior label of a non-DO'd section? Entry restrictions are stated only for DO-addressed procedures. (F p. 50; J 90.04.01 msgs 99, 128)

  9. What does the compiler do after "SENTENCE DELETED FROM TEXT" recoveries: is program continuity (fall-through into the next sentence) re-checked after deletions? (J 90.04.01)

Data description and storage model

  1. The machine word size (36 bits / 6 BCD characters) is never stated in the language sections; it must be imported from 709/7090 architecture knowledge. Confirm every place the definition relies on it. (J 02.05.04; J 02.07.03)
  2. Is assigning a Quantity to an unnamed item without named subordinates an error, a warning, or silently accepted? Both manuals say only that it "should not" be done. (F p. 77; J 02.05.04) Decided as design (M3-15, docs/design/m3-data.md, 2026-08-04): accepted silently, matching the advisory "should not"; --pedantic notes it. No new manual evidence.
  3. What are the absolute maximum field and record lengths for external decimal, internal decimal, and alphameric data? J defines the 10-digit single/double fixed-point boundary and a 16-digit scientific-decimal fraction cap, but no absolute maxima. (J 02.05.05–06)
  4. What does Justify = L or R on a group (non-format-level) entry do: honored, ignored, or applied to the group as an alphameric whole? (J 02.05.04 D.3; msg 39) Decided as design (R half by D3.5, docs/design/decisions.md; L half by M3-15, docs/design/m3-data.md, 2026-08-04): L is honored: J 02.05.04 states "Left justification is always effective"; R on a format-less entry is ineffective (D3.5). F's sample form carries an L on the format-less group TABLE (F p. 100), consistent but nonprobative: TABLE sits at the highest level, where L is the default anyway.
  5. May V and the true decimal point . coexist in one pictorial, and how do S, V, and . interact in edited output? Each character is defined separately; no combination rules are given. (F p. 80; J 02.05.05)
  6. How are COND values other than quoted one-character constants handled (figurative constants, unquoted values)? All examples show quoted single characters. (F p. 72; J 02.05.02)
  7. What collating sequence governs alphameric comparison of data under the native option; F gives only blank-then-digits for serial checking and defers alphabetics to "the particular machine system" (F p. 67). Resolved (scan check, 2026-08-01): the native J 02.06.16 display, now fully read (§1.1), governs on the 7090: digits lowest (0 = LOW.VALUE) rising through the letters to ( (HIGH.VALUE) highest; only the BCDIC names of the zone specials remain inferred. (F p. 67; J 02.06.16; images/page-050.png)
  8. What happens at object time when a QUANTITY IN value exceeds the compile-time Quantity reservation? J says no execute-time check is made against the Quantity value, implying silent overrun, nowhere confirmed for this case. (J 02.05.04) Decided as design (M4-21, docs/design/m4-codegen.md, 2026-08-05): the emulated runtime reproduces the silent overrun: no object-time check is generated, matching J 90.01.02's no-checks policy for subscripts. No new manual evidence.
  9. Do editing characters (8 $ * , …) have any meaning on input-describing pictorials, or only when the field is a target of MOVE/SET editing? (F p. 80; J 02.05.05; J 02.04.06–07)

Arithmetic and data manipulation

  1. How does rounding treat negative values and carry into the integer part (the round-half-up threshold itself is stated at F p. 115), and can rounding raise the overflow condition recorded in SYS)130? (F p. 115; J 90.02.16–17; J 90.02.10)

    Narrowed (90.02 + 90.05 mining, 2026-08-01; adversarially verified 2026-08-02): mining the generated-code appendix together with the compiled sample fixes exactly where rounding happens, and shows that the only rounding either manual ever exhibits is object code that neither manual explains.

    In MOVPAK. Rounding appears as five step-subroutines, one in each of the five (and only five) MOVPAK packages that are built from a step list ("two or more of the following instructions"): SYS)219 with SYS)183 (external decimal 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 in the AC-MQ) (J 90.02.16–19, 90.02.23, 90.02.30–31). Each is invoked by a bare transfer carrying no count ("TRA SYS)219 Round current character", "TRA SYS)221 Round current characters" (plural, as printed at 90.02.18), "TRA SYS)274 Round Current Character"), alone among the step instructions, every one of which is otherwise a TXI SYS)nnn,1,<count>; and each standalone entry says nothing beyond which package it serves ("This MOVPAK subroutine is used in conjunction with SYS)183 to move external decimal fields to external decimal fields."). No line in J 90.02.00–90.02.33 describes what the round routine does, mentions sign, or mentions carry. The remaining numeric packages, SYS)184 (external to internal decimal), SYS)186/187/188 (internal decimal to external decimal: unsigned, overpunch minus, overpunch plus), SYS)246–247 (internal decimal to and from unjustified internal decimal) and SYS)267 (internal decimal to edited), are called with a fixed one-to-three-word sequence and have no step list at all, so their lack of a round step shows only that they have no step vocabulary; it is not evidence that those paths do not round. The appendix labels the operation as acting on the "current character" and gives it no repetition count, but whether its effect is confined to that position is not stated; and the plural "Round current characters" at 90.02.18 is the one place the manual hints otherwise.

    In the compiled sample. The sample emits no MOVPAK round step (its system references are 132, 133, 175, 177, 178, 180, 182, 184, 185, 190, 193, 198, 212, 214, 225, 226, 239–241, 243–245, 260, 267–269, 275, 283 and 294, none of them 219–222 or 274), but it does emit rounding, inline, on the SET path, and it never writes TRUNCATED anywhere. All four of its multiply-then-store SET sequences end with the same tail; for "SET WORKING FICA = .03 * WORKING GROSS," (statement 211,00, J 90.05 listing PDF p. 196) the generated code is 01166 LDQ CP)+9 01167 MPY 4)GROSS 01170 XCA 01171 ACL CP)+34 01172 LRS 35 01173 DVP CP)+31 01174 STQ 4)FICA (J 90.05 listing, PDF p. 210), and the identical XCA / ACL / LRS 35 / DVP / STQ tail closes both GROSS branches of statement 203,00 at LOC 00632–00635 and 00644–00647 (PDF p. 206) and the withholding computation of 215,00 at LOC 01234–01237 (PDF pp. 210–211). The added constant tracks the divisor, not the statement: CP)+34 is added wherever the divide is by CP)+31, CP)+32 wherever it is by CP)+33.

    Inference (not stated in either manual; requires 709/7090 architecture knowledge): that ACL (Add and Carry Logical, which adds into the accumulator's magnitude with the sign position untouched) is the half-adjust that F p. 44 makes the SET default, added to the scaled product before the truncating DVP by the scale factor. On that reading two thirds of this question answer themselves for the arithmetic path: the carry propagates in binary through the whole accumulator before the divide, so carry into the integer part needs no separate mechanism; and because the addend goes into the magnitude with the sign untouched, the adjustment is away from zero, which is exactly the "half-adjust applied to the absolute value with sign restored" that §8.5.4 had inferred from period practice alone. Two caveats keep this short of proof: the constant pool's contents are not printed in the listing, so "CP)+34 is half of CP)+31" is an inference from the code's shape (nothing else explains a constant added immediately before the scaling divide in a program that never writes TRUNCATED), and every value in the sample is non-negative, so no negative case is actually exercised. Corrected 2026-08-04: the first caveat is void: the pool is printed. The pool words run from LOC 01674 to 01771 on J 90.05 listing, PDF pp. 215–216 (images/page-216.png), where CP)+31 = 100 and CP)+34 = 50 are read directly. What stays inference is the half-adjust reading of the ACL itself; the negative-value caveat stands.

    Overflow. Nothing connects rounding to SYS)130. "SYS)130" occurs exactly once in the whole manual, in its own definition: "This cell is set non-zero whenever any one of the numeric move or convert subroutines of MOVPAK detects the truncation of significant high order values (i.e. overflow)." (J 90.02.10), which is scoped by subroutine rather than by cause, so a rounding carry out of the high-order position is neither asserted nor excluded; no subroutine anywhere in the appendix is described as testing or clearing the cell; and overflow detection is a separately counted step acting at the other end of the field ("TXI SYS)199, 1, NUMBER-OF-CHARACTERS-TO-TEST-FOR-OVERFLOW", with siblings SYS)195, 196, 201, 203, 204, 270, 277, 281).

    Inference: on the sample's SET path the question cannot arise at all: the rounded quotient is stored by a bare STQ with no MOVPAK call anywhere in the sequence, so no rounding carry there can reach SYS)130; the cell is only at stake when a result is stored through a move/convert package. F. F's own rule stays a bare threshold: the least significant remaining digit "is increased by 1 when the part removed is greater than or equal to one-half", with 126.5027 rounding to 127, to 126.503 for a 6-position field and to 13 "which would be understood to be 130" for a 2-position field (F p. 115), and 2063.78 giving 2063.7 truncated against 2063.8 rounded (F p. 116). Every example is positive, none carries past the rounded position, and none produces a result that outgrows its field.

    Still open:
    (1) whether the MOVPAK round steps use the same half-adjust as the inline arithmetic path, and what they do with the sign: nothing in J says, and their internals are entered by a bare TRA;
    (2) whether a rounding carry out of the high-order digit of a MOVPAK target sets SYS)130 or is dropped silently;
    (3) whether plain MOVE rounds at all: F promises only that alignment "may involve the dropping of leading digits or low-order digits" (F p. 42) and none of its p. 43 examples discriminates rounding from truncation (99V99 1234 to 99V9 gives 123 either way; 99999 01234 to 999V9 gives 2340, a pure high-order drop), yet the four MOVE-serving packages are precisely the ones carrying round steps. Annotated 2026-08-04: "MOVE-serving" is a label, not a finding; the step-list families serve any character-route transfer: the sample enters SYS)268 for an ADD operand fetch (statement 221,00), and a copy-shaped SET between character-numeric fields would enter the same families. (The copy-shaped SET is a real statement form; J 02.04.05 shows its alphameric case, SET alpha.field.1 = alpha.field.2, which routes through the alphabetic movers SYS)239–243 and cannot round.) The 2026-08-04 pass verified J's silence both ways: the appendix writes inclusion conditions where it has them (SYS)265 "appears … whenever the 'AT END' option is not used with the GET verb", J 90.02.29; SYS)283 uses the same construction for ON ERROR, J 90.02.32) and writes none for the five round steps. Decided as design (D4.1 part (d), docs/design/decisions.md, Jack's call, 2026-08-04): a SET store through a step-list package rounds; a MOVE store truncates; amendable, with the round-everything reading as the recorded amendment. The language question itself stays open.

    Inference on (3): the sample's three scale-changing MOVE stores (CLA 5)NETPAY / LRS 35 / DVP CP)+24 feeding TSX SYS)180,4 and TXI SYS)267,1,4, at LOC 00423–00425, 01112–01114 and 01141–01143 (PDF pp. 203, 209)) carry no ACL, i.e. they drop low-order digits with no half-adjust, in contrast with the four SET stores; that contrast is the strongest indication either manual offers that MOVE truncates where SET rounds, but the statements those sequences belong to are identified from the record/field names, since the object listing prints no statement numbers. Refuted 2026-08-04 (re-derived from the octal address fields, scan-checked): the three stores are not scale-changing and drop no low-order digit. The sources (WORKING NETPAY twice, GRAND.TOTALS NETPAY once, each IR9(5)V99, seven digits at scale 2) feed six-digit edited targets that also carry scale 2, so the pictorials force the dropped digit to be the high-order seventh, whatever the register layout; on Open Question 28's inferred register split (quotient to the MQ, remainder to the AC, the edit converting the low six) each store keeps value mod 10⁶ (images/page-203.png, page-216.png). Rounding cannot apply to a high-order drop, so the missing ACL attests nothing about MOVE and low-order digits. What is newly settled is the inventory and the division of labour: rounding is a step-subroutine of the five step-list MOVPAK packages and an inline binary half-adjust before the scaling divide on the arithmetic path, and neither manual states the algorithm of either. (F pp. 42–44, 115–116; J 90.02.10, 90.02.16–19, 90.02.23–24, 90.02.30–32; J 90.05 listing, PDF pp. 196, 203, 206, 209–211; images/page-148.png, page-155.png, page-157.png, page-162.png, page-169.png, page-170.png, page-203.png, page-206.png, page-210.png; F images/page-120.png) ---

  2. Does SET's ON OVERFLOW trigger only on the final store (F: "in the process of storing the final result") or also on intermediate upscale/downscale truncation, which the compiler separately warns about (msgs 27, 199)? (F p. 44; J 90.04.01)

    Narrowed further (90.02 re-mining + 90.05 listing evidence, scan-verified, 2026-08-01; adversarially verified 2026-08-02): Reading the generated-code appendix entry by entry confirms the object-time mechanism, hardens the ground it stands on, and widens one gap. (i) SYS)130 is the processor's only documented object-time overflow indicator (its siblings are SYS)131 for "an improper data condition" and SYS)134 for floating point underflow), and it is armed from a single package: "This cell is set non-zero whenever any one of the numeric move or convert subroutines of MOVPAK detects the truncation of significant high order values (i.e. overflow)" (J 90.02.10, verified on images/page-148.png), MOVPAK being the packaged object-time field-moving subroutines: "Many of the SYS Reference numbers are concerned with subroutines to move fields at object time. The interaction of various of these 'MOVE' subroutine made it desirable to package several of them together into one subroutine (called MOVPAK)." Note the wording names a class, not a list: no individual SYS) entry in J 90.02.00–90.02.33 is said to set the cell. (ii) Where MOVPAK's detection is made explicit, it is a compile-time-planned, character-counted step of a move/convert call: "TXI SYS)199, 1, NUMBER-OF-CHARACTERS-TO-TEST-FOR-OVERFLOW" (J 90.02.16, verified on images/page-155.png), and every such step (SYS)195, 196, 199, 201, 203, 204, 270, 277, 281) is documented only as "used in conjunction with" one of five families whose source is a character field: SYS)183 external→external decimal, SYS)185 external decimal→edited, SYS)189 edited→external decimal, SYS)190 edited→edited, SYS)268 edited→internal decimal (J 90.02.15–21, 90.02.30–32). (iii) The fixed-point scaling and arithmetic routines SYS)163–166 (upscale), SYS)167–168 (downscale), SYS)169 (divide) and SYS)170–171 (multiply with product downscale) are never called MOVPAK subroutines, are never said to set SYS)130 or any other cell, and are each invoked by a bare TSX SYS)nnn,4 plus at most one PZE CP)+NN parameter word with a single normal return: none of the alternate or error exits the appendix does spell out where they exist ("HIGH RETURN from comparison / EQUAL RETURN from comparison / LOW RETURN from comparison" for SYS)162; "If an error is detected during conversion, return is 1,4 to routine SYS)263 which prints an error message." for SYS)261) (J 90.02.12–13, 90.02.29; verified on images/page-151.png and page-152.png). (iv) No entry in J 90.02.00–90.02.33 tests, branches on, or clears SYS)130, and the compiled sample never references it.

    Inference (not stated in either manual): the overflow condition belongs to the move/convert path alone, matching F's "In the process of storing the final result of a SET command" (F p. 44, verified on F28-8043 images/page-050.png), and intermediate upscale/downscale/multiply/divide truncation cannot raise it. This rests on SYS)163–171 lying outside MOVPAK altogether, not merely on their lacking a test step, and it is exactly why the compiler diagnoses the scaling losses statically, where they are computable from the declared pictorials: "DOWNSCALE GENERATED WHICH LOSES ALL SIGNIFICANT FIGURES." (27,00) and "UPSCALE MAY CAUSE HIGH ORDER TRUNCATION FOR STORE INTO 'NAME.1'" (199,00), the latter itself attributing the loss to the store, both under the heading "THE FOLLOWING ERRORS WERE DETECTED DURING COMPILATION-" (J 90.04.01).

    Added qualification (new, from the compiled sample and the ID-source converts): no store of an arithmetic result emits a documented overflow test, whatever the target format: the gap is universal, not peculiar to internal-decimal targets. A SET's result reaches the store as internal decimal in the AC/AC-MQ, and each of the four store paths open to it is testless.

    Internal decimal right justified: no MOVPAK call at all. SET WORKING GROSS = (WORKING HOURS * 1.5 -20) * MASTER RATE (statement 203,00) into a field declared IR9(5)V99 compiles to inline machine arithmetic ending MPY 1)RATE,2 / XCA / ACL CP)+32 / LRS 35 / DVP CP)+33 / STQ 4)GROSS, and SET WORKING FICA = .03 * WORKING GROSS (211,00) into IR9(4)V99 compiles as LDQ CP)+9 / MPY 4)GROSS / XCA / ACL CP)+34 / LRS 35 / DVP CP)+31 / STQ 4)FICA: multiplication, inline downscaling by LRS 35 and DVP, and a bare store, with no MOVPAK call, no SYS)163–171 call and no overflow test anywhere (J 90.05 listing, PDF pp. 206, 210; verified on images/page-210.png; the AXT 0 word preceding the FICA sequence is the BEGIN SECTION linkage cell for statement 210,00, loaded by SXA FICA.ROUTINE,4 on PDF p. 206, not part of the SET).

    External decimal: SYS)186/187/188, "a MOVPAK subroutine which converts from internal decimal in the AC or AC-MQ to unsigned external decimal" (and the two overpunch-sign variants): a single TXI SYS)18n,1,NUMBER-OF-CHARACTERS-TO-DEVELOP word with no follow-on instruction list and so no test step (J 90.02.18).

    Edited: SYS)267, "This MOVPAK subroutine converts from internal decimal in the AC-MQ to form an edited field": three words (TXI / OCT TARGET-CONTROL-WORD-BITS / AXT NUMBER-OF-DIGITS-TO-CONVERT, 1), again no test step (J 90.02.30); the sample exhibits it, MOVE CORRESPONDING GRAND.TOTALS TO PAYRECORD (statement 199,00) storing internal-decimal totals into the 88889.99 print fields as CLA 6)GROSS / TSX SYS)180,4 / PZE 2)GROSS,,1 / TXI SYS)267,1,4 / OCT 000005000004 (J 90.05 listing, PDF p. 203).

    Internal decimal not justified: SYS)246, one word, no test step (J 90.02.26). The five families that do carry a TEST-FOR-OVERFLOW step are all character-source routines: the no-arithmetic case (SET alpha.field.1 = alpha.field.2 and field-to-field moves) and operand-side conversions.

    Inference: two readings survive and the manuals decide between them nowhere. Either
    (a) detection is intrinsic to MOVPAK's numeric converts, which is what SYS)130's class-wide wording most naturally says, the explicit TXI steps then being required only by the character-scripted families that need an instruction per character group; or (b) ON OVERFLOW compiles inline code the appendix never exhibits. Reading
    (b) is not architecturally implausible: the compiler demonstrably implements SET's other store-time option inline in the fixed-point path: MOVPAK rounds with a scripted step ("TRA SYS)219 Round current character", J 90.02.16, 90.02.23) whereas the fixed-point sequences round by the ACL CP)+nn that precedes LRS 35 / DVP CP)+nn (absent from the plain rescale at CLA 5)NETPAY / LRS 35 / DVP CP)+24 on PDF p. 203; corrected 2026-08-04: that sequence is no rescale: it is Open Question 28's digit-capacity split, equal scale, high-order drop, where no half-adjust could apply), though that reading of the ACL constant is inference from the object code, not stated anywhere. Three residuals keep this short of resolved. First, the generated ON OVERFLOW sequence is nowhere shown: J's own SET write-up never mentions the clause (J 02.04.05), OVERFLOW survives only in the key-word list (J 02.03.02), the deferred-features appendix does not defer it (J 90.01), and the compiled sample uses no ON OVERFLOW, so how the object program suppresses the store, as F promises ("instead of storing the erroneous result"), is unrecoverable, and MOVPAK detecting overflow while moving characters sits awkwardly with a store that never happens. Second, and consequently, it is unknown whether an arithmetic SET could raise the condition at all under any target format, since none of its four store paths is documented to test. Third, the same MOVPAK families also run on the operand side of a statement: the sample converts a 5-character edited field to internal decimal with TSX SYS)182,4 / TXI SYS)268,1,1 / TXI SYS)269,1,5 / TXI SYS)275,1,5 before accumulating it, for ADD BONDORDER BONDENOMINATION TO INTERNAL.TOTALS BONDPURCHASES (statement 221,00; J 90.05 listing, PDF p. 212), and

    inference: since SYS)130 is described as one cell set by any MOVPAK numeric move or convert, it must be a statement-wide flag rather than a store-only one, even though only stores are documented as raising the language-level condition; "final store only" is therefore established against the arithmetic scaling routines SYS)163–171, not against every MOVPAK call the statement makes. Also unresolved: whether the 7090's own AC-overflow indicator plays any role in the inline fixed-point arithmetic (the manuals never mention it, nor any divide check). (Not counted among the overflow-test steps above: SYS)231–234 occupy that slot in the family calling-sequence lists at J 90.02.16–19 but their own entries print "NUMBER-OF-CHARACTERS-TO-TEST-FOR-OVERPUNCH", verified on images/page-163.png: a genuine printed inconsistency, preserved.) (F p. 44; J 02.03.02; J 02.04.05; J 90.01; J 90.02.10, 90.02.12–13, 90.02.15–21, 90.02.24, 90.02.26, 90.02.29–32; J 90.04.01 msgs 27, 199; J 90.05 listing, PDF pp. 203, 206, 210, 212; images/page-148.png, page-151.png, page-152.png, page-155.png, page-163.png, page-210.png; F28-8043 images/page-050.png)

    Implementation disposition (M4-10, docs/design/m4-codegen.md, 2026-08-05): the design adopts reading (b): a written ON OVERFLOW compiles an inline pre-store magnitude test against the target's digit capacity, ours and non-historical; without the clause no test is emitted, the attested silence. SYS)130 stays a sticky cell nothing reads or clears. The language question stays open.

  3. What is the intermediate working precision of fixed-point expression evaluation: how many decimal digits are carried, and when does downscaling occur mid-expression? (J 90.02 shows double-precision work registers and 10¹⁰ scaling steps; no language-level rule.)

    Narrowed (90.02 mining + 90.05 listing evidence, 2026-08-01; adversarially re-verified against the page scans, 2026-08-02): No prose rule exists anywhere: neither manual states a working digit count for intermediates or says where scaling steps fall, and F's only precision language is expressly about the endpoint: "Ordinarily the result of the SET operation will be rounded to the number of places indicated by the format description of the result field or fields" and "In the process of storing the final result of a SET command it is possible for a loss of significant high-order digits to occur" (F p. 44); the word "precision" does not occur in F at all. The appendix and the compiled sample together nevertheless fix the machine model. Working width. Fixed point is "a binary integer arithmetic with decimal scaling" (J 02.04.05) whose unit is the machine word: a right-justified internal numeric field "appears by itself in the low order positions of a full word (two if double precision) with the sign value in the sign bit of the word" (J 02.05.04), and "Fixed point double precision numbers are denoted in the Data Description by formats representing more than 10 digits" (J 02.05.06 d). 90.02 carries that one-word/two-word split into the registers, and (contrary to a first reading of the appendix, and to the present §4.2.2 wording) the fixed-point routines are not uniformly double precision: SYS)163 "upscales the single precision AC by 10**10", SYS)164 "upscales the number in the MQ by 10**10", while SYS)165–171 work on the AC-MQ pair and SYS)160 is "a subroutine for sign adjustment for double precision fixed point numbers … entered with the number in the AC-MQ", the second multi-precision operand living in two dedicated cells: "SYS)128, SYS)129 These two cells serve as storage for multi precision arithmetic operations" (J 90.02.10–13, 90.02.11.01; verified on images/page-148.png, page-151.png, page-152.png). So the attested working width is one 35-bit word for single precision and the AC-MQ pair for double: a register statement, not a digit count. Inference (not manual text): a 709/7090 word is a sign bit plus 35 magnitude bits and 2³⁵−1 = 34,359,738,367, so one word holds every 10-digit decimal integer and not every 11-digit one, which is why the declared field boundary is 10 digits, and why 10¹⁰ is the largest power of ten a one-word constant-pool scale factor can hold.

    The double-precision digit capacity is nowhere stated and must not be guessed: "more than 10 digits" is all J says; 20 would follow only if the pair is a decimal split at 10¹⁰, whereas 70 magnitude bits would carry about 21. The recurring 10**10 step is best read the same way rather than as a promotion quantum. SYS)163 and SYS)164 each "upscale … by 10**10 and then upscale by the constant located at CP)+NN"; SYS)168 "downscales the double precision AC-MQ by 10**10 and then downscales by the constant located at CP)+NN leaving the result in the MQ"; SYS)171 multiplies AC-MQ by SYS)128 SYS)129 and "scales the product down by 10**10, and then downscales by the constant located at CP)+NN"; but their partners do the same jobs without it: SYS)165 and SYS)166 "upscale … by the constant located at CP)+NN", SYS)167 "downscales … by the constant located at CP)+NN and leaves the result in the AC-MQ", SYS)170 "scales the product down by the constant located at CP)+NN" (J 90.02.12–13). Inference, and the correction of this question's own premise: the 10**10 is not the mode-promotion step (promotion is triggered by an operand's declared format (J 02.05.06 d) under the rule of J 02.04.05.01) but the two-step form of a scale change whose factor exceeds one word's largest power of ten; its coincidence with the 10-digit boundary is the same word-size fact seen twice. Consistently, the routine that sheds ten digits delivers one register: SYS)168 leaves "the result in the MQ". Two double-precision layouts are documented, distinguished only by which half is high: SYS)165 takes the AC-MQ plain, SYS)166 takes it "On entry to the routine, the high order part of the number is in the MQ and the low order in the AC"; inference: respectively what an MPY leaves and what a DVP leaves, the machine placing a double-length product high-half-in-AC but a quotient in the MQ with the remainder in the AC. Division stages its operands the opposite way from multiplication: SYS)169 "divides the double precision fixed point number in SYS)128 and SYS)129 by the AC-MQ. The result is left in the AC-MQ": dividend in the cells, divisor in the registers (J 90.02.13). Where the scaling falls. Scale is a compile-time attribute computed from the pictorials before any code is emitted: hence the compile-time diagnostics "DOWNSCALE GENERATED WHICH LOSES ALL SIGNIFICANT FIGURES." (27,00) and "UPSCALE MAY CAUSE HIGH ORDER TRUNCATION FOR STORE INTO 'NAME.1'" (199,00), the latter itself attributing the loss to a store (J 90.04.01), and hence the compiler's own conversion parameter block, whose fields are "Address — = Scale applied to internal decimal value", "Prefix — is the sign of the scale" and "Decrement — = Numeric length of value": scale and digit count carried as an explicit pair (J 90.02.27, CONTROL-WORD-TYPE-ID; the scientific-decimal CONTROL-WORD-TYPE-SD likewise pairs "Scale applied to mantissa in pictorial" with "Total length in characters, of the field", J 90.02.26). The compiled sample exhibits the placement directly. It carries no OPTION card (its ENVIRONMENT division holds only FILE and SPECIF cards (J 90.05 listing, PDF p. 195)), so it was compiled in the default mode: "The compiler normally generates comparison type instructions based on the 709/7090 collating sequence and an object program which is conservative of time rather than space" (J 02.06.16), i.e. "CONSERVE TIME requests an object program which will be executed in a minimum amount of time; this is achieved by the generation of in-line instructions to perform the operations. This is the normal mode of operation" (J 02.06.17), as against CONSERVE SPACE, in which "subroutines are generated once for operations such as scaling, double precision arithmetic, etc., in-line calling sequences to the subroutines are used to perform the operations" (J 02.06.16). Caution against a tempting inference: the sample calls none of SYS)163–171, but that is not evidence about the mode: no routine in that range performs an ordinary single-precision scale by a constant (each involves either the 10**10 step or the AC-MQ pair), so the set cannot be the whole CONSERVE SPACE scaling package, and the sample needs none of them, its largest scale factor being 10⁶ and its widest field IR9(5)V99. Statement 203,00, IF WORKING HOURS GT 40.0 THEN SET WORKING GROSS = (WORKING HOURS * 1.5 -20) * MASTER RATE OTHERWISE SET WORKING GROSS = WORKING HOURS * MASTER RATE (J 90.05 listing, PDF p. 196), over 3)HOURS IR99V9 and 4)GROSS IR9(5)V99 (PDF p. 194) and 1)RATE IR99V999 (PDF p. 192) (scales 10¹, 10², 10³) compiles to LDQ CP)+6 / MPY 3)HOURS / STQ RS)1+0 / LDQ CP)+7 / MPY CP)+31 / STQ RS)0 / CLA RS)1 / SUB RS)0 / XCA / MPY 1)RATE,2 / XCA / ACL CP)+32 / LRS 35 / DVP CP)+33 / STQ 4)GROSS, the constants being CP)+6 = 15 (the literal 1.5 as a scaled integer), CP)+7 = 20, CP)+31 = 100, CP)+32 = 500, CP)+33 = 1000 (J 90.05 listing, PDF pp. 206, 215–216; images/page-206.png, page-216.png). Three rules read straight off it and off the other two SETs: (i) additive operands are brought to a common scale by upscaling the lesser-scaled one mid-expression: the literal 20 is multiplied by 100 before the subtract, and emitted as a runtime LDQ CP)+7 / MPY CP)+31 rather than folded to the constant 2000, i.e. as a generic alignment step; likewise in SET WORKING WHT = 0.18 * (WORKING GROSS - 13 * MASTER EXEMPTIONS) (215,00) the integer product MPY EXEMPTIONS,1 is followed immediately by MPY CP)+31 to reach GROSS's two decimal places before the SUB (J 90.05 listing, PDF pp. 196, 210–211; images/page-210.png); (ii) products merely accumulate scale and are never downscaled mid-expression: LDQ CP)+6 / MPY 3)HOURS / STQ RS)1+0 parks 1.5×HOURS in a Result Storage cell at its full accumulated scale, and the expression reaches 10⁵ before its single scaling step even though every operand and the result have at most three decimal places; (iii) the one downscale is generated at the store, as a single DVP by the accumulated excess power of ten immediately preceding the STQ into the result field: by 1000 for statement 203,00's overtime branch, by 100 for its straight-time branch, for SET WORKING FICA = .03 * WORKING GROSS (211,00) and for statement 215,00. Rounding is folded into that same divide as an ACL of exactly half the divisor beforehand (CP)+32 = 500 against divisor 1000, CP)+34 = 50 against divisor 100), the machine form of F's rule that the retained digit "is increased by 1 when the part removed is greater than or equal to one-half" (F p. 115, ROUND), applied where F says it is applied, at the store and not to intermediates. Two inferences from 7090 instruction semantics, not manual text: the STQ of a product keeps only the MQ, discarding the AC half, and a chained MPY re-multiplies the MQ, so a single-precision intermediate really is one 35-bit word and the high half of every single-precision product is dropped; and LRS 35 / DVP is the idiom for a divide with a properly positioned double-length dividend, the ACL carry surviving across the shift. Result Storage is nevertheless sized for the wider case: 90.02.03 says only that RS cells "temporarily store the results of a CT statement" and that "N is the sum of maximum Result Storage used in each section", but in the sample RS)0 and RS)1 lie two words apart (01621 and 01623) and each section's block begins at an even offset from RS) BSS 30 (01621, 01627, 01633, and 3.RS)1 at 01643); inference from the listing's LOC values: two words per cell, i.e. every expression intermediate is allocated storage able to hold a double-precision value even where the code stores one word into it.

    Still open: the rule is reconstructed from one compiled program plus routine descriptions and is nowhere stated. The sample exercises no source-level division (every DVP in it is compiler-generated scaling), no TRUNCATED clause, and no field wider than 10 digits (its widest is IR9(5)V99), so double precision (SYS)128–129, SYS)160, SYS)165–171) is attested only by the 90.02 prose and never seen in generated code; nothing shows the circumstances in which the compiler would prefer a mid-expression downscale to an upscale, although msg 27,00 proves it generates them; whether TRUNCATED merely suppresses the ACL half-divisor or changes the scaling plan is unattested; and the ceiling behind "MAXIMUM NUMERIC LENGTH EXCEEDED. 'NAME.1' FORMAT USED." (35,00), and behind msg 52,00's "MAXIMUM NUMERIC LENGTH EXCEEDED FOR CONSTANT OR LITERAL.", is never given. One further store-side mechanism observed but not explained by any text: when the value stored has more digits than the target pictorial can hold, the compiler splits it with a divide by 10 raised to the target's digit count before the edit: CLA 3)NETPAY / LRS 35 / DVP CP)+24 (CP)+24 = 1,000,000) preceding TSX SYS)180,4 / PZE 1)NETPAY,,4 / TXI SYS)267,1,4 / OCT 000004000003 / AXT 6,1, where the source WORKING NETPAY IR9(5)V99 has seven digits and the target edited pictorial 8889.99 six, while the seven-digit-to-seven-digit moves on the same listing page (4)GROSS → 2)GROSS 88889.99, OCT 000005000004, AXT 7,1) carry no divide at all (J 90.05 listing, PDF pp. 193, 203, 209; J 90.02.15, 90.02.17, 90.02.30); inference: since SYS)267 "converts from internal decimal in the AC-MQ to form an edited field", the divide isolates the digits that fit as the remainder in the AC and the excess as the quotient in the MQ, matching the MQ-high/AC-low layout SYS)166 documents; but neither the purpose nor the overflow consequence is stated. (F pp. 44, 115; J 02.04.05, 02.04.05.01; J 02.05.04, 02.05.06 d; J 02.06.16–17; J 90.02.03, 90.02.10–13, 90.02.11.01, 90.02.15, 90.02.17, 90.02.26–27, 90.02.30; J 90.04.01 msgs 27, 35, 52, 199; J 90.05 listing, PDF pp. 192–196, 203, 206, 209–211, 215–216; images/page-148.png, page-151.png, page-152.png, page-206.png, page-210.png, page-216.png)

    Implementation disposition (M4-10, docs/design/m4-codegen.md, 2026-08-05): the three scale rules and the store-side digit split are adopted as the generated model, and the double-precision shapes follow the 90.02 calling sequences as labeled reconstructions. The language question stays open.

  4. How is one element of a subscripted conditional variable set, given SET condition.name is the only setting form and condition-names may not be subscripted? (F p. 46; J 90.01.03)

  5. What is the mode/precision of a truth function's 1-or-0 value, and can a TR term trigger mode promotion? (F p. 24; J 02.04.05)

  6. What happens at object time when a numeric field contains invalid characters during MOVE or arithmetic; SYS)131 records "an improper data condition", but no program-level reaction or verb option is defined. (J 90.02.10)

    Narrowed (90.02 mining, 2026-08-01; scan-verified 2026-08-02): SYS)131 is a flag cell, not a mechanism. J defines it in one sentence: "This cell is set non-zero whenever any one of the numeric move or convert subroutines of MOVPAK detects an improper data condition." (J 90.02.10, verified on images/page-148.png), and gives it no calling sequence, unlike the SYS) routines and unlike the pointer cells SYS)132/133, which are shown with a PZE LOC,,BYTE format word; its siblings SYS)130 (overflow) and SYS)134 (floating-point underflow from a Move) are bare cells in the same way (J 90.02.10–11; images/page-148.png, page-149.png). It is a Type 2 entry, "Type 2 entries received a number greater than 127" and Type 2 communication cells being "those communication cells which are a part of a particular object program"; J states CT-Loader placement of Type 2 subroutines and says the cells are "categorized in the same manner", so loader placement of the cell follows by that categorization rather than being stated of cells (J 90.02.07). The setting side is bounded though not pinpointed: MOVPAK is entered at SYS)179–182 and its members run SYS)183–258 and SYS)267–282 (no SYS)259 exists; each member is identified in its own entry as a MOVPAK subroutine), and the cell's own wording confines it to the numeric members: SYS)183–238 (character-serial external-decimal and edited-field moves), SYS)246–258 (internal-decimal / scientific-decimal / floating-point converts) and SYS)267–282 (internal-decimal↔edited converts), excluding the alphabetic and figurative-constant movers SYS)239–245 (J 90.02.14–16, 90.02.25–28, 90.02.30–32). Within a generated MOVPAK call the only step kinds the appendix names are move, convert, develop, bypass, insert leading/trailing zeros, develop decimal zeros, test for overflow, test for overpunch, scan for sign, "Round current character", and the terminating target-numeric-length word ("This type of MOVPAK call is always terminated by the instruction TXI SYS)223, 1, TARGET-NUMERIC-LENGTH", J 90.02.16); none is a validity test.

    Inference (not stated in either manual): improper-data detection is therefore internal to the subroutines' own character loop rather than a separately generated step, which is why no compiled listing can display it. The appendix is itself inconsistent about the four character-examining steps SYS)231–234: the collected step lists print them as OVERFLOW: "TXI SYS)231, 1, NUMBER-OF-CHARACTERS-TO-TEST-FOR-OVERFLOW" under SYS)183, and SYS)232, SYS)233, SYS)234 identically under SYS)185, SYS)189 and SYS)190, each flagged with the note "The last character processed under control of this instruction is examined for source field sign." (J 90.02.16–19; images/page-155.png), whereas the four standalone entries for the same subroutines all print "NUMBER-OF-CHARACTERS-TO-TEST-FOR-OVERPUNCH" (J 90.02.24; images/page-163.png). Both readings verified on the scans: a genuine print inconsistency in the 1962 manual, not an OCR artifact. Nothing reads it. Across the whole of J 90.02.00–90.02.33 no SYS) or IOC) entry is documented as testing, branching on, printing from, initialising or clearing SYS)131 or its two siblings; the three cells occur exactly three times in the appendix, in their own definitions. The field-test sample's object listing never names them either: its complete set of SYS references is 132, 133, 175, 177, 178, 180, 182, 184, 185, 190, 193, 198, 212, 214, 225, 226, 239, 240, 241, 243, 244, 245, 260, 267, 268, 269, 275, 283 and 294 (J 90.05 listing, PDF pp. 198–216). The decisive demonstration is statement 202,00, "COMPUTE.PAY. MOVE DETAIL DATE TO MASTER DATE, MOVE DETAIL HOURS TO WORKING HOURS, PAYRECORD HRS." (J 90.05 listing, PDF p. 196; printed across two lines). DETAIL HOURS is declared 99V9, three characters, external decimal (J 90.05 listing, PDF p. 192), in a record the sample's own narrative describes as punched: "Data Description entries specify that all fields of the detail records are in external mode since they are generated on a card punch. HOURS is the only field upon which arithmetic operations are performed, and consequently, is the only field specified as numeric (9's in description)." (J 90.05.02). It is thus precisely the field most exposed to a blank or a stray punch. Its generated code (symbolic columns of the listing; the octal location and instruction-word columns are elided here) is COMPUTE.PAY LAC BL)3,1 / TXL SYS)294,1,0 / CAL 2)DATE,1 / LAC BL)2,2 / TXL SYS)294,2,0 / SLW 1)DATE,2 / CAL BL)3 / ACL CP)+52 / SLW SYS)132 / TSX SYS)182,4 / TXI SYS)184,1,3 / STO 3)HOURS, followed by the same source field's second move TSX SYS)182,4 / TXI SYS)185,1,4 into the edited PAYRECORD HRS (8889.9), and then at +23 straight into statement 203's arithmetic, CLA 3)HOURS / CAS CP)+5 (J 90.05 listing, PDF p. 205), SYS)184 being the MOVPAK routine that "converts from external decimal to internal decimal leaving results in the AC or AC-MQ. The sign is assumed over the low order digit." (J 90.02.16), and WORKING HOURS being IR99V9, internal (J 90.05 listing, PDF p. 194). The converted value goes straight to store and thence into the pay arithmetic with nothing tested, while those same twelve words carry two instances of the one inline object-time trap the compiler does emit, TXL SYS)294,n,0, which "prints an error message whenever a reference is made to a Base Locator before the locator has been loaded, and exits back to the CT Monitor" (J 90.02.33), so the absence of a data check is a design decision, not a gap in the listing. The pattern repeats at the edited-to-internal-decimal convert TSX SYS)182,4 / TXI SYS)268,1,1 / TXI SYS)269,1,5 / TXI SYS)275,1,5 / STO 3.RS)1, which runs straight into CLA 2)BONDPURCHASES / ADD 3.RS)1 (J 90.05 listing, PDF p. 212). Nor can a program name the condition. The only condition options in the language are ON OVERFLOW, restricted to SET and ADD with a single result field (F p. 44, p. 47) (F's complete verb-format summary gives MOVE no option whatever, "MOVE [CORRESPONDING] data.name.1 TO data.name.2, data.name.3, ... data.name.n" (F p. 109, in the command list of F pp. 108–109)) and the Environment FILE-card ON ERROR, which J confines to three I/O conditions: "IOCS cannot continue processing after discovering an unrecoverable redundancy error, a block checksum error or a block sequence error without direction from the programmer. The ON ERROR option of the Environment FILE card provides for communication between IOCS and the programmer in these three error situations." (J 02.07.07). J's key-word lists hold OVERFLOW and ERROR (the two conditions that do have options) and no word naming an improper-data condition (J 02.03.02–03). CRYPT cannot even write the symbol: "The characters, 'Quotation Mark,' 'Left Parenthesis,' 'Right Parentheis,' 'Dollar Sign' may not be used as part of a symbol" (J 02.08.01; "Parentheis" sic), and "No debugging facilities are currently available." (J 90.01.05 B.3).

    Reading (inference from the stated facts): the move or arithmetic runs to completion, MOVPAK stores whatever its character loop produced, execution continues silently, and the event survives only as a non-zero cell that no documented code reads, prints from, or resets, of a piece with J's stated policy elsewhere, "No object time check is made to insure that subscript references conform to the limits specified by the array dimensions in the Data Description." (J 90.01.02). This is a different mechanism from the GET-path conversion check it is easily confused with. SYS)261 is not a MOVPAK subroutine and does not operate on programmer data: "Subroutine SYS)261 converts the logical accumulator from a BCD number to binary, checking for non-numeric characters and/or imbedded or trailing blanks; and leaves the result in the decrement of the AC. This routine is used in conjunction with getting a variable length BCD record from tape where the first word of the record gives the remaining length of the record. If an error is detected during conversion, return is 1,4 to routine SYS)263 which prints an error message." (J 90.02.29, verified on images/page-168.png). Four differences: its subject is the record's own length control word, not a described data field; its calling sequence is TSX SYS)261,4 / TSX SYS)263,6 / (Normal Return), i.e. an explicit alternate error exit, which no MOVPAK numeric call has; its reaction is fatal, SYS)263 being the routine that "prints an error message in conjunction with SYS)261 upon GET error condition (see SYS)261) and exits to the CT monitor" (J 90.02.29); and it sets no cell. Inference: since the appendix does spell out alternate exits where the design has them (SYS)162's "HIGH RETURN / EQUAL RETURN / LOW RETURN from comparison" (J 90.02.12) and SYS)292's "(Partial Conversion Exit)" and "(Total Conversion Exit)" (J 90.02.33)), the single-exit MOVPAK sequence, always closed by its target-numeric-length word, is most likely a real fact about the interface rather than an abbreviation. Every object-time error printer in 90.02 (SYS)260 record length, 263 GET conversion, 264 record exceeding BLOCKSIZE, 265 unexpected end-of-file, 283 GET error, 291 FILE to card equipment in locating mode, 294 base locator not loaded) is I/O- or addressing-related and terminates the run, matching J's own inventory of object-time on-line messages: "Object program error messages, usually concerning I/O errors. Object-time processing will terminate and control will revert back to the CT Monitor." (J 05.06.04). None concerns numeric data validity. The compiler's improper-data diagnostics are not object-time reactions either: messages 25,00 "OPERATION IGNORED BECAUSE 'NAME.1' HAS IMPROPER DATA FORMAT ( E A(2) ) FOR THIS USE.", 67,00 "THERE IS AN ILLEGAL NON-NUMERIC CHARACTER IN THE NUMERIC FIELD.", 111,00, 112,00, 120,00 and 182,00 all stand under the heading "THE FOLLOWING ERRORS WERE DETECTED DURING COMPILATION-" and carry compilation severity codes, "numbered 1 through 5" (J 90.04.01–02); message 67 is the compile-time namesake of the object-time condition, not its handler.

    Still open: what MOVPAK counts as an "improper data condition": it cannot simply be "any non-digit", since J allows scientific-decimal source fields free-form content, "For the source fields of the scientific decimal type, a free form of data is allowed within the limits of the field", with worked examples containing embedded blanks (J 02.04.04 e), and the class matters, since "Arithmetic operations are performed only in the internal (binary) mode" (J 02.03.03), so every external field feeding arithmetic passes through one of these converts; which individual subroutine sets the cell; what the target field or accumulator holds afterwards; and whether the cell is ever cleared: all three flag cells are described only as "set non-zero", and no initialisation, reset or per-statement clearing is stated anywhere in J 90.02, J 90.03, or the Loader chapter J 03. (F p. 44, p. 47, pp. 108–109; J 02.03.02–03; J 02.04.04; J 02.07.07; J 02.08.01; J 05.06.04; J 90.01.02, 90.01.05; J 90.02.07, 90.02.10–12, 90.02.14–19, 90.02.24, 90.02.25–33; J 90.04.01–02; J 90.05.02; J 90.05 listing, PDF pp. 192, 194, 196, 198–216; images/page-148.png, page-149.png, page-155.png, page-163.png, page-168.png)

    Implementation disposition (D4.3; M4-17, docs/design/m4-codegen.md, 2026-08-05): reproduced exactly: the numeric handlers arm the cell per D4.3's trigger, and nothing reads, prints, or clears it.

  7. Is there a maximum count of receiving fields in MOVE or result fields in SET/ADD (beyond sentence capacity, msg 177)?

  8. When multiple receiving/result fields overlap in storage (via REDEF), what is the store order and are later stores affected by earlier ones? Decided as design (D4.8; M4-21, docs/design/m4-codegen.md, 2026-08-05): stores run left to right in written order, each from the shared intermediate, so an earlier store reaches a later one only through the storage the targets share. Ours; nothing attests it.

  9. Do the data movements of DO … USING … GIVING and of function references obey full MOVE editing (decimal alignment, justification), or are they raw transmissions? F says values are "moved". (F pp. 52–53, 57–58) Decided as design (M3-19; M4-13, docs/design/m4-codegen.md, 2026-08-05): the substitutions lower as MOVEs around the bare DO (F p. 53's expansion, adopted by M3-19), so they take full MOVE editing.

  10. For repeated ADD x TO accumulator into an edited or scaled field, is the addition performed on the stored (already rounded/edited) value each time? (F p. 47)

Control flow

  1. If the loop body modifies the DO index variable or the p/q/r parameter fields, is F's expansion (which re-reads q and r each pass and keeps i programmer-visible) binding? (F pp. 50–51) Decided as design (M4-13, docs/design/m4-codegen.md, 2026-08-05): the attested increment block re-loads the index from its field every pass (CLA INDEX, statement 206,00), so mid-loop changes to the index are visible and the expansion binds for it; the sample's q and r are literals baked into the constant pool, so the re-read-each-pass reading for named parameter fields is our design, following the expansion.

  2. Does the index of a completed DO … FOR loop retain the value r afterward, and what is its value after a GO TO abandons the loop? (The J sample copies INDEX to POS before exiting, suggesting "unreliable".) (F pp. 50–51; J 90.05) Narrowed (M4-13, docs/design/m4-codegen.md, 2026-08-05): the D5.1 decode settles the generated answer: the increment precedes a magnitude test, so a completed loop's index holds the first value past r (r + q when the step divides r − p exactly), not r (and the body does run for i = r); after a GO TO out it holds whatever the last executed increment left, which for a mid-body exit is the current pass's value (D5.1's recorded decision). The GO TO half stays a design reading, not attested behavior.

  3. What exactly triggers msg 170 "-WHEN- SUBSTITUTED FOR -IF- BECAUSE OF IMPROPER USE.": which improper IF placements does the compiler silently repair? (J 90.04.01)

  4. Is there any bound on n in the conditional GO TO's WHEN list or the assigned GO TO's procedure list, other than the 60-operator sentence limit and table capacities? (J 90.04.01 msg 171)

  5. How is DO return linkage physically established (per-procedure return cell vs index register), determining whether simultaneously active DOs of different procedures interact? (J 90.02 describes generated subroutines but not DO linkage.)

    Resolved (90.05 listing evidence + 90.02 mining, 2026-08-01; adversarially re-verified against 400-dpi page renders, 2026-08-02): a per-procedure return cell, not a live index register. The word at the procedure label is a placeholder AXT 0 (0774 00 0 00000); each DO plants its return address in that word's address field with SXA P,4; entry is at P+1; and the procedure's terminal instruction is TRA* P (octal flag field 60, i.e. bits 12-13 set = indirect), returning through the head word. Six procedures, six such returns: END.OF.MASTERS 00331/00350 (PDF p. 202), FICA.ROUTINE 01165/01217 (p. 210), WITHOLDING.TAX.ROUTINE 01220/01261 (p. 211), BOND.ROUTINE 01262/01403 (p. 212), SEARCH 01404/01472 (p. 213), DEPARTMENT.END 01473/01620 (p. 215). Nine call sites occupy pp. 201-203 and 205-207, in two code shapes, not one:
    (i) plain DO P (8 of the 9) compiles AXT *+3,7 / SXA P,4 / TRA P+1, e.g. p. 205 00542 0774 00 7 00545 AXT *+3,7 / 00543 0634 00 4 01473 SXA DEPARTMENT.END,4 / 00544 0020 00 0 01474 TRA DEPARTMENT.END+1 (tag digits 7 and 4 read independently in the octal and the symbolic column of the page render), the AT END DO clause compiling the identical triple (p. 201, 00205 GN)058); (ii) DO P FOR i = p(q)r (the single instance, statement 206,00 DO SEARCH FOR INDEX = 1(1)12.) compiles 00702 0774 00 4 00711 AXT GN)086,4 / 00703 0634 00 4 01404 SXA SEARCH,4 / four instructions of loop initialisation (00704-00707) / 00710 0020 00 0 01405 TRA SEARCH+1 (pp. 206-207): the planted return is the generated loop-increment label GN)086 rather than *+3, the AXT tag is 4 rather than 7, and the TRA need not adjoin the SXA. The loop back-edge 00721 TPL GN)085 re-enters SEARCH+1 on each of the 12 iterations without re-executing the SXA, so one planted return serves the whole loop, direct confirmation that the linkage lives in storage rather than in a register. Consequences: simultaneously active DOs of different procedures cannot interact (each procedure owns its cell), while re-DOing an already-active procedure overwrites its pending return, confirming the §8.5.5 nested/recursive reading. 90.02 corroborates the static model: all compiler-generated storage is fixed blocks reserved by BSS (RS), TS), PI), plus the constant pool) with no stack or save-area chain, and IR4 (the TSX linkage register) is reused both as the data base register (LAC BL)2,4 / CAL DATANAME,4) and as scratch (PDX 0,4 / TXL *2,4,5), so a surviving return must live in storage (J 90.02.03-06, 90.02.11). (J 90.05 listing, PDF pp. 195-196, 201-203, 205-207, 210-213, 215; images/page-203.png, page-205.png, page-206.png, page-207.png, page-211.png, page-213.png, page-215.png) Corroborating stated text (90.02 re-mining, adversarially verified 2026-08-02): J 02.08.03 shows the located-data reference sequence as the compiler emits it (LAC BASE.LOCATOR.OF.DATE,4 / TXL SYS)294,4,0 / CLA DATE.DISP,4) and states "Note that the contents of index register 4 are destroyed, and that instructions have been inserted in the program"; so a DO'd procedure's first reference to a located data item destroys any return held in IR4, and a return that survives an arbitrary body must be planted in storage, exactly the head-word cell the listing exhibits. (J 02.08.03; J 90.02.11, 90.02.33)

  6. Does J accept F's AT END any-imperative-clause with a non-transfer clause, given J 02.07.05 ("a single imperative statement only") and msg 106 ("STATEMENT OR SECTION NAME MUST FOLLOW -AT END-"), while the sample uses both AT END DO x and AT END GO TO x?

    Narrowed (90.02 mining, 2026-08-01): the generated code settles the mechanism, not the parse. J's generic GET calling sequence is TSX IOC)8,4 / PZE FILENAME,,SYS)260 / PZE END-OF-FILE-PROCEDURE,,ERROR-PROCEDURE / IOCDN* BL)2,,14 (J 90.02.04); the address field of the third word holds the AT END exit, occupied by SYS)265, which "appears as part of the GET calling sequence to the IOCS Read routine whenever the 'AT END' option is not used with the GET verb" and "prints a message concerning the unexpected end-of-file and exits to the CT Monitor" (J 90.02.29), while its decrement holds the ON ERROR exit, defaulting to SYS)283 (J 90.02.32). In the sample, GET MASTER, AT END DO END.OF.MASTERS. compiles that word as PZE GN)058,,SYS)283, and the clause becomes a compiler-generated out-of-line block placed after the calling sequence and jumped over by the normal-return TRA GN)059: GN)058 AXT *+3,7 / SXA END.OF.MASTERS,4 / TRA END.OF.MASTERS+1 (J 90.05 listing, PDF p. 201). *+3 is GN)059, which is the code of the next source sentence (statement 189, MOVE MASTER DEPARTMENT TO CURRENT.DEPT, GO TO GET.DETAIL), so an AT END clause that returns resumes at the statement following the GET, exactly the continuation a non-transfer imperative would need. GET DETAIL, AT END GO TO END.OF.DETAILS. likewise receives its own generated block, GN)062 TRA END.OF.DETAILS, although the bare target address would have served in the calling-sequence word; inference: the AT END clause is emitted through ordinary statement code generation rather than being planted as a name, and nothing in the IOCS interface confines it to a transfer. Pulling the other way, msg 106,00 "STATEMENT OR SECTION NAME MUST FOLLOW -AT END-. CHECK 'NAME.1'." is worded from the same template as 92,00 and 93,00 ("STATEMENT OR SECTION NAME MUST FOLLOW -ONERROR- / -FORLABEL- IN THE -FILE- CARD."), whose operands are literally bare names, and J's own template calls the slot END-OF-FILE-PROCEDURE.

    Still open: whether the field-test parser accepted a clause such as AT END MOVE ...; both surviving samples use only DO and GO TO. Recommended implementation: accept any single imperative statement (F p. 40; J 02.07.05), compile it out-of-line with a return to the statement after the GET as the DO case demonstrates, and diagnose non-transfer clauses at low severity. (F p. 40, p. 109; J 02.07.05–06; J 90.02.04, 90.02.28–29, 90.02.32; J 90.04.01 msgs 92, 93, 106; J 90.05 listing, PDF pp. 195, 201; images/page-142.png, page-183.png, page-201.png)

    Verified and further narrowed (independent re-derivation + scan check, 2026-08-02): the generated-code reading holds on re-checking: PZE END-OF-FILE-PROCEDURE,,ERROR-PROCEDURE in the generic GET sequence (J 90.02.04), SYS)265 supplied "whenever the 'AT END' option is not used with the GET verb" (J 90.02.29), SYS)283 supplied "whenever the 'ON ERROR' option in not used in the Environment description of the file" (J 90.02.32, printed "in not used"), SYS)260 by contrast said only to "may appear" in a GET calling sequence, with no source option named (J 90.02.28) (inference: it is therefore not a programmer-replaceable slot) and in the sample 00202 0 00433 0 00205 11001 +13 PZE GN)058,,SYS)283 / 00204 … TRA GN)059 / 00205 … GN)058 AXT *+3,7 / SXA END.OF.MASTERS,4 / TRA END.OF.MASTERS+1, verified on images/page-201.png (no FILE card in the sample codes ON ERROR, so SYS)283 stands in every GET). Three findings sharpen the entry. (i) The shape is uniform: all four GETs in the sample (statements 188, 190, 191, 194, at object locations 00200–00207, 00222–00231, 00233–00240 and 00277–00306) put the AT END clause in a generated block placed immediately after the calling sequence and jumped over by a normal-return TRA to a generated label that begins the next sentence's code: GN)059, GN)061, GN)063, GN)065 respectively (J 90.05 listing, PDF pp. 201–202). (ii) The AT END DO x block is not an AT-END-specific construct: an ordinary in-line DO (statement 199, 199,00 71512 END.OF.RUN. DO DEPARTMENT.END, (J 90.05 listing, PDF p. 196)) compiles to the identical triple, 00370 0774 00 7 00373 10001 END.OF.RUN AXT *+3,7 / SXA DEPARTMENT.END,4 / TRA DEPARTMENT.END+1 (J 90.05 listing, PDF p. 203), and the DO'd procedure returns indirectly through its head cell, 00350 0020 60 0 00331 10001 GN)067 TRA* END.OF.MASTERS against 00331 0774 00 0 00000 10000 END.OF.MASTERS AXT 0 (J 90.05 listing, PDF p. 202). Inference: the return address planted by SXA is the *+3 operand, which in the AT END case is the very label the normal path transfers to, so the end-of-file and not-end paths converge on the sentence after the GET and a returning, non-transfer AT END clause would have needed no new machinery. (iii) Pulling the other way harder than previously recorded: msg 106,00 belongs to a larger family than msgs 92,00/93,00: J also carries 127,00 0 TRANSFER BYPASSED BECAUSE 'NAME.1' IS NOT A STATEMENT OR SECTION NAME. and 128,00 … IS A STATEMENT OR SECTION NAME ADDRESSED BY A -DO-. for ill-formed transfer targets, and, specific to the DO verb's own operand, 188,00 0 'NAME.1', ADDRESSED BY A -DO-, IS NEITHER A STATEMENT NOR A SECTION NAME. (J 90.04.01, PDF pp. 183, 185). Inference: a bad name inside AT END DO x would already be caught by 188,00 (and inside AT END GO TO x by 127,00), leaving 106,00 to police the AT END slot itself; no manual sentence says which diagnostic the compiler actually issues for a malformed AT END clause. On balance the field-test parser is best read as requiring the AT END clause to designate a procedure (GO TO name and DO name both attested in the sample, a bare name plausible), with a non-transfer imperative unattested and probably rejected even though the code generator would plainly have handled one.

    Still open: whether AT END MOVE … (or SET, FILE, ADD) was accepted; no surviving sample exercises it and no manual sentence settles it. Recommended implementation unchanged: accept any single imperative statement (F p. 40, p. 109; J 02.07.05), compile it out-of-line with a return to the sentence following the GET as the DO case demonstrates, and diagnose the non-transfer case at low severity for J compatibility. Fidelity aside, not bearing on the question: the appendix template prints the buffer-pointer line as IOCDN* BL)2,,14 while the sample listing prints the mnemonic as IOCTN* in all four GET sequences (IOCTN* BL)2,,15 for the three MASTER GETs at 00203, 00225 and 00302, IOCTN* BL)3,,3 for the DETAIL GET at 00236); both spellings are reproduced as printed. (J 02.07.05–06; J 90.02.04, 90.02.28–29, 90.02.32; J 90.04.01 msgs 92, 93, 106, 127, 128, 188; J 90.05 listing, PDF pp. 195–196, 201–203; images/page-183.png, page-201.png, page-202.png)

  7. Are WHEN conditions and IF sentences subject to the compile-time constant-folding J describes for unequal-length alphameric = comparisons (only the false-branch transfer generated)? (J 02.04.07)

    Narrowed (90.02 mining, 2026-08-01; adversarially verified against page scans 2026-08-02): The rule is written operator-scoped, not construct-scoped. J 02.04.07 rule 2.b reads "Alphameric fields of unequal length are treated on the basis of the operator used in the comparison", and sub-rule i "In tests for an = or NOT = condition the fields will always be found to be unequal. In the following example where fields A and B are of alphameric type with unequal length the only code generated will be a transfer to D." (verified character-for-character against images/page-025.png). The subsection is headed "C. Conditional Statements" (J 02.04.06) and its six rules speak throughout of "comparisons" and "tests"; no rule names a construct as its scope, and constructs appear only inside worked examples: rule 1's "the following IF statement represents an invalid comparison" and rule 2.b.i's pair "IF A = B THEN GO TO C OTHERWISE GO TO D." / "IF A NOT = B THEN GO TO D OTHERWISE GO TO C." The semantic half of the rule ("the fields will always be found to be unequal") therefore binds every context that evaluates such a condition: conditional sentences (F p. 25), the conditional GO TO's WHEN clauses (F p. 48) and TR operands (F p. 24) alike, the more so because J's language chapter documents no conditional construct's syntax at all: across J 02.00–02.08 the string "GO TO" appears only inside those two examples, and WHEN only in the key-word list (J 02.03.02) and in the Data Description clause BLANK WHEN ZERO (J 02.05.05, 02.05.07), J 02.04 being by its own title "Procedure Description Clarification and Amplification" of the F language. Only the code-shape half is exhibited, and only on IF sentences. Note that "a transfer to D" names the branch the constant outcome selects, not specifically the false branch: in the first example D is the OTHERWISE target of an always-false =, in the second it is the THEN target of an always-true NOT =, so for IF both directions of the fold are attested. Neither appendix that could exhibit a fold does so. J 90.02 has nothing on the subject: it "explains the format and content of the instruction listing" (J 90.02.00) and then catalogues listing conventions and the IOC)/SYS) runtime library, with no per-construct code templates; an exhaustive search of it finds no occurrence of fold, optimiz-, eliminat-, suppress-, "only code", "no code", conditional, relation, branch, false or unequal, its one "truncation" being SYS)130's overflow flag (J 90.02.10), and its two nearest items are irrelevant to the point: SYS)162, a run-time routine that "performs an alphabetic comparison on two fields" whose calling sequence carries independent LENGTH(1)/LENGTH(2) operands (J 90.02.12), and the MOVPAK routine SYS)242, which "moves alphabetic fields to alphabetic fields where some information was unknown at compile time" (J 90.02.25), the appendix's sole occurrence of the phrase "compile time". The sample program cannot settle it either, because it contains no unequal-length alphameric =/NOT = comparison: its entire inventory of alphameric relations is the WHEN pair GO TO CHECK.NEW.DEPT WHEN D.EMP.NO = M.EMP.NO, LOW.DETAIL WHEN D.EMP.NO LT M.EMP.NO. (both operands pictorial-less groups of AA + AAAA, hence 6-character alphameric fields of equal length by J 02.05.06 c) with rule 4 of J 02.04.07 (inference: J nowhere defines the term "non-format field", and 02.05.06 c) is the only candidate definition)), the two = HIGH.VALUE sentinel tests, and CURRENT.DEPT IS NOT EQUAL TO D.DEPT (both AA); every other relation in the program is numeric (J 90.05 listing, PDF pp. 192–193, 195–197). All five of those alphameric relations produced object code: the listing contains exactly five LAS three-way logical compares, one per relation, and SYS)162 is never called anywhere in the program (J 90.05 listing, PDF pp. 201–203, 204–205). The shape is an inline load-and-compare followed by a transfer decode of LAS's three skip slots: three TRAs where all three outcomes branch away (LAS 1)EMPLOYEE.NUMBER,2 / TRA *+3 / TRA *+2 / TRA LOW.DETAIL, PDF p. 201), two where one outcome falls through into the following code (LAS 1)EMPLOYEE.NUMBER,2 / TRA *+2 / TRA CHECK.NEW.DEPT, the third slot falling into the next WHEN clause's CAL, PDF p. 201; LAS RS)0 / TRA *+2 / TRA GN)070, the third slot falling into the AXT/SXA/TRA triple that performs DO DEPARTMENT.END, PDF p. 205). Two things follow. First, IF and WHEN demonstrably share one comparison code generator: the WHEN pair at COMPARE.EMPLOYEE.NUMBERS (CAL 2)EMPLOYEE.NUMBER,1 … LAS 1)EMPLOYEE.NUMBER,2 plus decode, PDF p. 201) and the IF at CHECK.NEW.DEPT (CAL CURRENT.DEPT / LGL 18 / ANA CP)+30 / SLW RS)0 … CAL 2)DEPARTMENT,1 / ANA CP)+30 / LAS RS)0 plus decode, PDF pp. 204–205) emit the same skeleton, differing only in the shift, mask and scratch-word store needed for a 2-character field held mid-word, which, together with msg 170,00 "-WHEN- SUBSTITUTED FOR -IF- BECAUSE OF IMPROPER USE." showing a shared front-end path (J 90.04.01), makes it likely (inference, nowhere stated) that the fold applies to WHEN clauses identically. Second, a figurative constant does not create an unequal-length case: IF D.EMP.NO = HIGH.VALUE compiles to a full run-time compare against CP)+23, generated as OCT 747474747474 (six left-parenthesis characters, HIGH.VALUE in the 709/7090 collating sequence (J 02.04.01)), materialised at exactly the length of the field it is compared with (J 90.05 listing, PDF pp. 202, 216). (That observation says nothing about constant folding in general: only one operand of such a test is known at compile time, so its outcome is not.) The fold rests solely on the statically known field lengths, there being no blank padding of the shorter field.

    Still open: the emitted form of a folded WHEN clause (presumably no code for an always-false = clause and an unconditional transfer for an always-true NOT = one, which would strand every later clause of the same conditional GO TO, since "Any remaining conditional expressions are left unevaluated" (F p. 48)) and whether folding is diagnosed at all, which J's message list suggests it is not, carrying only "ILLEGAL COMPARISON STRUCTURE." (msg 107,00) and "CANNOT USE VARIABLE LENGTH ITEMS FOR COMPARISON." (msg 123,00) (J 90.04.01).

  8. May the assigned GO TO's parenthesized procedure-name list be split across cards at any word boundary per the general continuation rule, or are there additional restrictions? (F pp. 28, 49)

Input/output

  1. What is the exact card syntax and placement of the PATTERN option on the FILE card (keyword form, delimiters, interaction with per-record options)? Only its existence, purpose, and 16-record limit are recoverable. (J 02.07.04; J 90.04.01 msgs 48–50)

  2. What is the field layout of the standard 14-word tape label (header and trailer) that IOCS checks and writes? It lives in the IOCS manual (C28-6100-2) and the unavailable Appendix 90.07.

    Resolved (external source, 2026-08-01; scan-verified 2026-08-02): The IOCS manual gives the layout in full and confirms the length three independent ways: "IOCS will automatically process 14-word labels of the following formats:", heading the Standard Label Formats section (external: C28-6100-2, PDF p. 29 / printed p. 21); "The standard label area at symbolic locations IOCS + 43 (see page 39) will be used; its length is 14 words." (external: C28-6100-2, PDF p. 32 / printed p. 24 — item 3 of the list of procedures executed when a NON-standard label package is specified — the manual: "If the decrement is zero, standard images are assumed; if it is non-zero, the following procedures will be executed:" — i.e. even a user label package still works through the standard 14-word area; erratum applied 2026-08-02); and the entry "LAREA | IOCS + 43 to IOCS + 56 | Label area (14 words)" in the table of quantities "located near the beginning of IOCS" under References to System Subroutines (external: C28-6100-2, PDF p. 47 / printed p. 39), 43–56 inclusive being exactly 14 words. LAREA is almost certainly the area J calls IOC)29, "a 14 word area within IOCS which is used to process all labels" (J 90.02.08), and the area the LABEL type code redefines (J 02.05.03); inference, from the matching size and role; neither manual states the equation. The label is 14 words = 84 BCD characters, and the IOCS tables index it by BCD position 1–84 (only the blank-reel table is dimensioned in card columns). Header label: word (BCD positions) content, meaning (external: C28-6100-2, PDF p. 30 / printed p. 22): 1 (1–6) 1HDRbb, label identifier; 2 (7–12) bXXXXX, tape serial number; 3 (13–18) bXXXXX, file serial number; 4 (19–24) bXXXXb, reel sequence number ("the first reel of a file is reel 0001, the second is reel 0002"); 5 (25–30) XXbYYY, creation date ("XX — Year", "YYY — Day of year (001-365)"); 6 (31–36) bbbXXX, retention days; 7 (37–42), a packed flag word the table breaks into five rows: 37–38 bX file density, position 37 blank and the digit in 38 (0 low, 1 high); 39 file mode (0 BCD, 1 binary); 40 block check sum indicator (binary files only); 41 block sequence indicator (binary files only); 42 "Checkpoint record indicator / 0 – No checkpoint record / 1 – Checkpoint record follows label"; 8–10 (43–60) BCD file name; 11–12 (61–72) "Not used, but reserved for 709/90 Sort compatibility"; 13–14 (73–84) not used. Words 3, 4 and 8–10 are the fields IOCS validates when the file is opened and at the beginning of each new reel of a multi-reel file: file serial number against the FILE card; reel sequence number against the FILE card "unless, of course, reel switching has occurred, in which case IOCS will have advanced the reel sequence number stored in the File Control Block"; and file name against the FILE card, except that "If no file name is given on the FILE card, this test is bypassed." Failure gives LABEL ERROR, INPUT REEL INVALID (external: C28-6100-2, PDF p. 31 / printed p. 23). Two of these are the object-time counterpart of COMTRAN's SERIAL and REEL options, whose 5- and 4-character limits match the label's bXXXXX and bXXXXb; COMTRAN's RETAIN (3 characters) corresponds instead to header word 6 and is never checked on input, only on the output side (J 02.06.12, which says the SERIAL/REEL/RETAIN information "is kept in the IOCS file block" and "is used by IOCS in checking and preparing standard labels"). The File Control Block keeps all four separately, as words 7, 8, 9 and 10–12: file serial number, reel sequence number, retention days, file name (external: C28-6100-2, PDF p. 73 / printed p. 65). Trailer label, same 14 words, only three defined (external: C28-6100-2, PDF p. 31 / printed p. 23): 1 (1–6) 1EORbb "End of reel trailer" or 1EOFbb "End of file trailer"; 2 (7–12) bXXXXX block count; 3 (13–18) bXXXXX unit control word, "the location in storage of the first word of the Unit Control Block which specifies the tape unit the reel was prepared on, and the logical number it was assigned"; 4–14 (19–84) not used. Header and trailer therefore share only their length and the convention that word 1 is a six-character identifier beginning 1. "During writing, an EOR label is prepared by IOCS when the end of a reel is encountered. An EOF label is prepared when the file is closed." The only count in either label is a block count, in the trailer. Its table gloss reads "Number of blocks in file", but the accompanying prose defines it per reel: "BLOCK COUNT is the number of data blocks on this reel. This is checked for every input reel. If it differs from the number of blocks actually read in, a sequence error is given" (external: C28-6100-2, PDF p. 31 / printed p. 23); the running value is held in File Control Block word 4 bits 3–17, "Counter for block sequence checking" (external: C28-6100-2, PDF p. 75 / printed p. 67). No record count appears in any standard label; see open question 50. The third standard format, the blank-reel label, is dimensioned in card columns because it is written card-to-tape: word 1 (cols 1–6) 1BLANK, word 2 (7–12) bXXXXX tape serial number, words 3–14 (13–80) not used (external: C28-6100-2, PDF p. 29 / printed p. 21). A reel accepted for labeled output must carry either a 1BLANK label or a 1HDR label on which (creation date + retention days) has been reached; if not, "either or both" of LABEL ERROR, OUTPUT REEL INVALID and LABEL ERROR, RETENTION NOT EXPIRED are printed (external: C28-6100-2, PDF p. 32 / printed p. 24).

  3. What is the IOCS-to-programmer calling convention for the FOR LABEL exit (distinguishing open/close/reel-switch; returning control)?

    Resolved (external source, 2026-08-02): the IOCS manual prints the linkage in full, and it is not a single exit but a five-entry transfer vector, which is precisely why one COMTRAN FOR LABEL statement.name cannot express it and why "portions of the FOR LABEL coding must be done in CRYPT" (J 02.05.03).

    Where the routine's address lives. "If the non-standard labels to be processed adhere to the general IOCS labeling scheme, non-standard label images may be easily handled by IOCS, using different routines to check and prepare label images. For this purpose, IOCS allows a non-standard label image package to be specified for each file. The location of the first cell of this package can be specified in the decrement of each entry in the list of files used for the ATTACH routine. If the decrement is zero, standard images are assumed; if it is non-zero, the following procedures will be executed: 1. All labels, both headers and trailers, will be read and written by the system. 2. All EOF marks associated with labels will also be read and written by the system. 3. The standard label area at symbolic locations IOCS + 43 (see page 39) will be used; its length is 14 words. 4. All the system actions and messages will apply." (external: C28-6100-2, PDF p. 32 / printed p. 24). The address is then held in the File Control Block as word 3 bits 3–17, "Location of entry point for standard or non-standard label image routines" (external: C28-6100-2, PDF p. 75 / printed p. 67), the FCB diagram labelling the same field "Entry point for non-standard label image routines" (external: C28-6100-2, PDF p. 73 / printed p. 65). That field carries no asterisk, and the appendix's key reads "Items marked with an asterisk are generated in the File Control Block by the Preprocessor. The remaining positions are initially zero." (external: C28-6100-2, PDF p. 73 / printed p. 65), so the Preprocessor never fills it, and the zero it is left holding is exactly the "decrement is zero, standard images are assumed" default (inference, from the two statements together). (Errata for the open-question-45 entry, which glosses the 14-word sentence as "item 3 of the list of what happens when standard label images are assumed": the list is the non-zero-decrement case, what happens when a non-standard package is supplied. The 14-word figure it cites is unaffected; only the framing needs correcting.)

    There is no control-card route to it, in either system. The IOCS Preprocessor's *FILE card carries only column 32, "Labeling conventions: H—High density label / L—Low density label / S—Standard density convention / blank—No label" (external: C28-6100-2, PDF p. 52 / printed p. 44). Decisively for COMTRAN, J's own Appendix 90.08 tabulates every field of the Loader *FILE card as generated by the Compiler from Environment FILE and SPECIF options (columns 17, 18-21, 22-25, 27, 28, 29, 30, 31, 32, 33, 34, 35, 38-41, 44-48, 51-53 and 54-72), and none of them is a label-routine entry point (J 90.08.01). The address can therefore only be planted at object time by generated code, by one of two routes J's runtime already has: the ATTACH file-list decrement, IOC)5 being "The entry point to the IOCS ATTACH subroutine", or a direct store into FCB word 3 through IOC)2, "A cell in the CT Monitor communication area which locates (L) a number (N) of IOCS file blocks. I/O information is kept in each of the 12 word blocks for every file in the CT program" (J 90.02.08). Inference: neither manual says which the field-test compiler used.

    Register and parameter conventions. Two rules precede the vector: "5. At each TSX, index register 2 will contain the 2's complement of the location of the first word of the File Control Block for the file being processed." and "6. The contents of all index registers used must be saved and restored." (external: C28-6100-2, PDF p. 33 / printed p. 25). There are no parameter words: the label image is the parameter and it is passed in storage: the 14-word area "LAREA | IOCS + 43 to IOCS + 56 | Label area (14 words)" (external: C28-6100-2, PDF p. 47 / printed p. 39), which is the area COMTRAN's LABEL type code redefines (J 02.05.03) and which is almost certainly J's IOC)29, "a 14 word area within IOCS which is used to process all labels" (J 90.02.08); inference from matching size and role, as flagged at open question 45; neither manual states the equation. Everything else the routine needs is reachable off index register 2: file serial number (FCB word 7), reel sequence number (word 8), retention days (word 9), file name (words 10–12), the block-sequence counter (word 4 bits 3–17), and the label / multi-reel / density / end-of-tape flags (word 2) (external: C28-6100-2, PDF pp. 74–76 / printed pp. 66–68). J confirms the programmer is expected to work from exactly those cells: the SERIAL, REEL and RETAIN information "is kept in the IOCS file block ... 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).

    The vector, verbatim. "Assuming that the non-standard label package begins at symbolic location MYLBLS, then the following actions will occur as indicated: 1. TSX MYLBLS, 1 — To check header label input file. The routine must return by means of: TRA 1, 1 if label is correct / TRA 2, 1 if the input label is invalid. Bit 35 of the 7th word of the label area must be 1 upon either return if a checkpoint record is to be skipped. 2. TSX MYLBLS + 1, 1 — To check trailer label, input file. Return must always be: TRA 1, 1. Upon return, the sign of the MQ must be: + if EOR; tape switching will occur / − if EOF; an EOF exit will be taken. 3. TSX MYLBLS + 2, 1 — To check label on tapes to be used for output. Return must be: TRA 1, 1 if the reel may be used / TRA 2, 1 if (creation date + retention days) has not been reached / TRA 3, 1 if it is not possible to use the reel. 4. TSX MYLBLS + 3, 1 — To prepare output trailer label. Return must always be: TRA 1, 1. Upon return, bits P, 1-35 of the AC must contain: 1EORbb if an EOR trailer is to be prepared / 1EOFbb if an EOF trailer is to be prepared. 5. TSX MYLBLS + 4, 1 — To prepare output header label. Return is: TRA 1, 1." (external: C28-6100-2, PDF p. 33 / printed p. 25, the manual setting each alternative return on its own line.) Item 1's checkpoint bit is consistent with the standard header layout, where BCD position 42 (the last character of word 7, i.e. bit 35) is the "Checkpoint record indicator" (external: C28-6100-2, PDF p. 30 / printed p. 22). How the routine learns which event applies: by entry point; there is no event code and no parameter. The five cells are one word each and IOCS enters the one appropriate to the event, so both the event and its direction are implicit in the entry chosen. Mapping onto J's three COMTRAN events ("when the file is opened or closed, or when a reel switch occurs", J 02.05.03): opening an input file → entry 1; opening an output file → entry 3, vetting the reel already mounted, then entry 5, writing the new header; reel switch on input → entry 2 for the exhausted reel's trailer, then entry 1 for the new reel's header; reel switch on output → entry 4 with AC = 1EORbb, then entries 3 and 5 for the new reel; closing an output file → entry 4 with AC = 1EOFbb; closing an input file → no call at all, the trailer having been checked when it was read. That mapping is inference (the manual nowhere tabulates events against entries) drawn from the entry descriptions plus IOCS's standard-label timing, "Note: During writing, an EOR label is prepared by IOCS when the end of a reel is encountered. An EOF label is prepared when the file is closed." (external: C28-6100-2, PDF p. 31 / printed p. 23), and the glossary's CLOSE, "The IOCS routine used to terminate file usage, prepare end of file trailer labels, and rewind the file" (external: C28-6100-2, PDF p. 83 / printed p. 75).

    Two returns are decisions, not merely status. At entry 2 the user routine, not IOCS, decides whether the reel just finished is the last: the MQ sign it leaves determines whether IOCS switches reels or raises end of file, the same discrimination the standard trailer's 1EORbb/1EOFbb identifier makes for standard labels (external: C28-6100-2, PDF p. 31 / printed p. 23). At entry 4 the routine announces in the AC which trailer kind it has built. How it is expected to know which is wanted is not stated; the natural sources are FCB word 2 bit 15 ("End-of-tape: 1 – No / 0 – Yes") or bit 16 ("File permanently closed"), both reachable off index register 2 (external: C28-6100-2, PDF p. 75 / printed p. 67); inference, supported by no text. What the routine may do: only inspect and fill the 14-word image. All tape motion stays with IOCS ("All labels, both headers and trailers, will be read and written by the system"; "All EOF marks associated with labels will also be read and written by the system"), and the system's own reactions are unchanged ("All the system actions and messages will apply"), so the standard label-error apparatus remains in force: UNIT XXXXX (file name) LABEL ERROR with its cause line, IF SSWX DOWN IGNORED, OPERATOR ACTION PAUSE, and Label Control Sense Switch handling (external: C28-6100-2, PDF p. 68 / printed p. 60; PDF p. 63 / printed p. 55). Inference, and unstated: that entry 1's TRA 2, 1 is what raises INPUT REEL INVALID and entry 3's TRA 2, 1 / TRA 3, 1 what raise RETENTION NOT EXPIRED / OUTPUT REEL INVALID; the manual says only that the system messages apply, never which return triggers which. A hard length constraint also survives into the non-standard case: IOCS rejects any label record that is not exactly fourteen words, "(file name) NO LABEL, BLANK CREATED — The record read as the label of an input file was not fourteen words in length" and "(file name) NO TRAILER — The record read as the trailer label of an input file was not fourteen words in length. The end of file condition is assumed. There is no stop associated with this error." (external: C28-6100-2, PDF p. 69 / printed p. 61), so J's "a label of 14 words or less" (J 02.06.11) must mean the programmer may use fewer than 14 words of the area, not write a shorter record (inference). Finally, the mechanism reaches only labels that "adhere to the general IOCS labeling scheme"; "Non-standard labels may be either a mere arrangement of the standard format or an entirely different labeling procedure. If non-standard labeling procedures are desired, the IOCS labeling routines must be entirely replaced. However, if only changes in label formats are desired, the IOCS label handling routines will still apply." (external: C28-6100-2, PDF p. 32 / printed p. 24), the second case being beyond anything COMTRAN can express. Note also "Labeling is not available for files processed on any on-line card equipment." (external: C28-6100-2, PDF p. 29 / printed p. 21), so FOR LABEL is inoperative on a card file. How control returns: by skip return through index register 1. TSX leaves in the index register the 2's complement of its own location: "TSX — Transfer and Set Index ... This instruction places the 2's complement of the core address of the TSX(IC) in the specified index register (T). The computer takes its next instruction from location Y." (external: 22-6528-4, PDF p. 39 / printed p. 39), and "Effective addresses are always formed in the computer by the addition of the 2's complement of the contents of the index register." (external: 22-6528-4, PDF p. 10 / printed p. 10). So TRA 1, 1 returns to the word immediately following the TSX, TRA 2, 1 to the second word after it and TRA 3, 1 to the third: at entries 1 and 3 the caller must reserve one and two words respectively after the TSX for the alternate returns. This settles J's otherwise unmotivated CRYPT requirement three times over. (i) No COMTRAN statement can execute TRA 2, 1, set the MQ sign, or load the AC with a BCD identifier. (ii) The machine has only three index registers, "Three index registers (XR) are used in the computer. These registers are called A, B, and C or 1, 2, and 4." (external: 22-6528-4, PDF p. 9 / printed p. 9), and IOCS commandeers two of them at every entry, IR1 as the return link and IR2 as the FCB pointer, while COMTRAN object code uses IR1 and IR2 freely as record base registers (LAC BL)2,1 / CLA 1)FICA,1, J 90.05 listing, PDF p. 210; CAL 1)DATE,1, PDF p. 211; SLW 1)DATE,2, PDF p. 205) and IR4 as its TSX linkage and data base register (LAC BL)2,4 / CAL DATANAME,4, J 90.02.04–05). A COMTRAN procedure entered at a label exit would destroy the return address in IR1 at its first based data reference (inference). (iii) Item 6 obliges the routine to save and restore whatever it uses, which no COMTRAN-level construct does.

    Still open: the COMTRAN surface. FOR LABEL statement.name names one procedure while IOCS wants five entry points, and neither manual says how the compiler bridges the two: whether it emits a five-word vector all of whose entries funnel into the named procedure after setting a discriminator, and if so what cell the programmer is to test. No such cell is named anywhere in J (02.05.03, 02.06.05, 02.06.12, 90.02, 90.04, 90.08), and Appendix 90.07, "SAMPLE NON STANDARD LABEL PROCESSING (Not Currently Available)", which would have shown it, does not exist in this edition. Recommendation for the compiler: generate the five-word vector, plant its address in the ATTACH file-list decrement (equivalently FCB word 3 bits 3–17), reserve the alternate-return words after each TSX, and define a documented event code the FOR LABEL procedure can test (a design choice, not a recovered fact). Confidence: certain on the IOCS calling convention (printed in full, verified against the page images) and on the return arithmetic (7090 principles of operation); tentative on the COMTRAN-to-IOCS glue. §8.5.6's "FOR LABEL / LABELN linkage documented only by a missing appendix" should accordingly be narrowed (the runtime linkage is now fully specified, and only the compiler's surface-to-vector mapping is unrecovered) rather than closed. (J 02.05.03; J 02.06.05, 02.06.11–12; J 00.00 contents; J 90.02.04–05, 90.02.08; J 90.05 listing, PDF pp. 205, 210–211; J 90.08.01; external: C28-6100-2, PDF pp. 29–34 / printed pp. 21–26, PDF p. 47 / printed p. 39, PDF p. 52 / printed p. 44, PDF p. 63 / printed p. 55, PDF pp. 68–69 / printed pp. 60–61, PDF pp. 73–76 / printed pp. 65–68, PDF p. 83 / printed p. 75; external: 22-6528-4, PDF/printed pp. 9, 10, 39)

  4. Does OPEN ALL FILES exist in the implemented language? J discusses only CLOSE ALL FILES and records no deferral of the OPEN form; presumably yes per F p. 39, but unverifiable from J. Resolved (90.02 mining, 2026-08-01): yes; OPEN ALL FILES is in the implemented language. The field-test sample's first procedure statement is 188,00 71466 START. OPEN ALL FILES, (J 90.05 listing, PDF p. 195), the listing closes with "NO ERRORS WERE DETECTED DURING COMPILATION" (J 90.05 listing, PDF p. 197), and the object code generated at that label is START TSX SYS)175,4 / +1 PZE IOC)1 (J 90.05 listing, PDF p. 200), SYS)175 being the routine of which J says "This routine opens all files in the file list located by IOC)1" (J 90.02.14), and IOC)1 being "A cell in the CT Monitor communications area which locates (L) a list of files, and designates the number (N) of files in the list. This List is used in Opening and Closing files" (J 90.02.08). The processor in fact carries the complete four-way OPEN/CLOSE runtime that F's two forms of each verb require: SYS)174 "opens the file designated FILENAME" (J 90.02.13), SYS)175 opens all, SYS)176 "closes the file designated FILENAME" and SYS)177 "closes all files in the file list located by IOC)1" (J 90.02.14). The named-file OPEN is independently attested by diagnostic 139,00 "FILE NAME SHOULD FOLLOW -OPEN-." (J 90.04.01), and ALL, FILES, OPEN and CLOSE are all J reserved key words (J 02.03.02). The CLOSE side corroborates the reading: CLOSE ALL FILES, STOP RUN. (J 90.05 listing, PDF p. 196) compiles to TSX SYS)177,4 / PZE IOC)1, then the STOP display call TSX SYS)178,4 with its two constant-pool words, then a second TSX SYS)177,4 / PZE IOC)1 immediately before the end-of-job return TXI IOC)40,0 (J 90.05 listing, PDF p. 204), the implicit close-all that J 02.04.06 ascribes to STOP RUN ("All open files are closed prior to this transfer of control as if a CLOSE ALL FILES had been supplied"). J's silence about OPEN ALL FILES in 02.04.06 is therefore an omission of prose, not of the feature; F p. 39 stands as its definition. (F p. 39; J 02.03.02; J 02.04.06; J 90.02.08, 90.02.13–14; J 90.04.01 msgs 138–139; J 90.05 listing, PDF pp. 195–197, 200, 204; images/page-153.png, page-195.png, page-200.png)

    Verified (independent re-derivation + scan check, 2026-08-02): every link in the chain was re-read from the sources and checked against the page images, and each holds character for character: TSX SYS)174,4 / PZE FILENAME with "This routine opens the file designated FILENAME." (J 90.02.13, images/page-152.png); TSX SYS)175,4 / PZE IOC)1 with "This routine opens all files in the file list located by IOC)1.", followed on the same page by the matching SYS)176 "closes the file designated FILENAME" and SYS)177 "closes all files in the file list located by IOC)1" (J 90.02.14, images/page-153.png); the source line 188,00 71466 START. OPEN ALL FILES, (images/page-195.png); the object pair 00165 0074 00 4 00257 10010 START TSX SYS)175,4 / 00166 0 00000 0 00001 10010 +1 PZE IOC)1 (images/page-200.png); the two TSX SYS)177,4 / PZE IOC)1 pairs at 00517/00520 and 00524/00525 straddling the STOP display call TSX SYS)178,4 and ending at TXI IOC)40,0, IOC)40 being "the end of job return point in the CT Monitor communication area for all CT jobs" (J 90.02.08), (images/page-204.png); and the diagnostic pair 138,00 0 FILE NAME SHOULD FOLLOW -CLOSE-. / 139,00 0 FILE NAME SHOULD FOLLOW -OPEN-. (J 90.04.01, PDF p. 184, images/page-184.png). Two supports are added. First, beneath the SYS) wrappers the runtime carries the IOCS primitive itself: "IOC)7 The entry point to the IOCS OPEN subroutine.", listed immediately after "IOC)6 The entry point to the IOCS CLOSE subroutine." (J 90.02.08), so the open path exists at both levels of the object-time library. Second, J's single sentence on the verb, "A file is referenced by the commands OPEN and CLOSE to initiate and complete file activity. (See Commercial Translator General Information manual)." (J 02.07.01), is an explicit deferral to F rather than a restriction, and Appendix 90.01 defers no part of OPEN, so nothing in J qualifies F's second form. (J 02.07.01; J 90.01; J 90.02.08; J 90.04.01 msgs 138–139; images/page-152.png, page-153.png, page-184.png, page-195.png, page-200.png, page-204.png)

  5. What happens at object time when a FILE'd record exceeds the file's BLOCKSIZE and SPANS was not specified for the output file? Input-side violations are defined; output-side behaviour is not. (J 02.07.06; J 90.04.01 msg 5)

  6. Is there a maximum record length independent of BLOCKSIZE 9999, or a limit on record.names per FILE card (beyond 63 files total and 16 per PATTERN)?

  7. How does the record-count comparison at CLOSE (F p. 41) behave for unlabeled or LABELN files: is any count check performed outside standard labels? Resolved (external source, 2026-08-02): no reel- or file-level count check exists outside standard labels, and F p. 41's record-count comparison has no IOCS counterpart even inside them.

    What IOCS checks on a standard-labeled input file. Word 2 of the trailer is a block count, verified for every reel, not only the last: "BLOCK COUNT is the number of data blocks on this reel. This is checked for every input reel. If it differs from the number of blocks actually read in, a sequence error is given. In this case it should be noted that a sequence error for the reel can occur even though each block is not being checked for sequence" (external: C28-6100-2, PDF p. 31 / printed p. 23), restated under Input File Trailer Labels as "The Block Count which appears in every trailer written by the system is checked and a sequence error exit is taken if it does not agree with the number of blocks 'read.'" (external: C28-6100-2, PDF p. 32 / printed p. 24). The running total is File Control Block word 4 bits 3–17, "Counter for block sequence checking" (external: C28-6100-2, PDF p. 75 / printed p. 67): "Every File Control Block carries a block sequence number for the current reel of the file. On a labeled file, this sequence number is always written in a trailer label at the end of each reel and checked when it is read" (external: C28-6100-2, PDF p. 41 / printed p. 33).

    Note the consequence for J: J 02.07.06 says "If block sequence checking is desired the Environment SPECIF card option SEQ must be selected", but the trailer check is automatic on any labeled file whatever SEQ says; the italicised IOCS sentence above exists precisely to make that point. A COMTRAN file with LABELS and no SEQ can therefore still take a block sequence error.

    What a mismatch does, and where. Not a message: a program exit. The condition is a "sequence error", one of the three ERR conditions of the READ routine: "ERR is the location to which transfer is made when any of three types of error conditions occur:
    (a) a redundancy which cannot be corrected;
    (b) check sum error (binary file); and
    (c) sequence error. The condition is recognized at the first reference to a buffer in which it occurs. The error encountered may be ignored by continuing to 'read' the file" (external: C28-6100-2, PDF p. 24 / printed p. 16). The abnormal-conditions table gives "READ | Block sequence error | ERROR exit MQ(S-2) = 1" (external: C28-6100-2, PDF p. 79 / printed p. 71, MQ subscripted S-2 as printed), matching the history-record convention "1—if a sequence error occurred" (external: C28-6100-2, PDF p. 25 / printed p. 17) and the glossary's ERR, "An address, specified in the calling sequence of the READ routine, which is used as an exit upon recognition of an uncorrectable redundancy, or a block sequence or check sum error" (external: C28-6100-2, PDF p. 84 / printed p. 76). No block-count or sequence-error text appears anywhere in the IOCS System Messages and Halts list (external: C28-6100-2, PDF pp. 66–70 / printed pp. 58–62) or in the restart messages (PDF pp. 71–72 / printed pp. 63–64). In COMTRAN this is the file's ON ERROR exit, and J says so in its own words: "IOCS cannot continue processing after discovering an unrecoverable redundancy error, a block checksum error or a block sequence error without direction from the programmer. The ON ERROR option of the Environment FILE card provides for communication between IOCS and the programmer in these three error situations" (J 02.07.07), the identical triple, reached through the identical calling-sequence slot, IOCS's READ being "TSX READ,4 / PZE FILE,,EOB / PZE EOF,,ERR / IOXY A,,m" where "FILE is the file designation, EOB is the end of buffer switch, EOF is the end of file exit, and ERR is the error exit" (external: C28-6100-2, PDF p. 23 / printed p. 15) against J's TSX IOC)8,4 / PZE FILENAME,,SYS)260 / PZE END-OF-FILE-PROCEDURE,,ERROR-PROCEDURE / IOCDN* BL)2,,14 (J 90.02.04). The correspondence is word for word, so SYS)260 is the EOB switch and the COMTRAN ON ERROR procedure is IOCS's ERR exit, defaulting to SYS)283 when no ON ERROR is coded (J 90.02.32); inference from the two templates, corroborated by J's own remark that record length errors are "referred to as EOB errors in the IOCS manual" (J 02.07.06). The error is resumable: "The error encountered may be ignored by continuing to 'read' the file."

    And it does not fire at CLOSE. The check is described inside READ, at the moment the trailer is read; CLOSE's label work is output-side only: "For a regular output file, a close other than the MON type, causes writing of
    (1) an EOF mark, a trailer label, and another EOF mark, if the file is labeled, or
    (2) an EOF mark only, if the file is unlabeled" (external: C28-6100-2, PDF p. 27 / printed p. 19), and the glossary defines CLOSE as "The IOCS routine used to terminate file usage, prepare end of file trailer labels, and rewind the file" (external: C28-6100-2, PDF p. 83 / printed p. 75). Inference (the manual states no negative): nothing at close compares anything on an input file.

    Unlabeled files: nothing at all. With no labels there is no trailer and hence no count, and IOCS makes end-of-data the programmer's problem. Single-reel: "It is the programmer's responsibility, in this case, to determine which EOF mark signifies the actual end of the file. No reel switching is possible for input files of this type." Multi-reel: "An EOF exit is given once per reel for each EOF encountered and if the file is again referenced by a READ operation, reel switching will occur and buffering will be resumed. For this type of file, the user must have a recognizable data record to indicate that the end of the file has been reached." (external: C28-6100-2, PDF p. 34 / printed p. 26.) This also settles open question 53, and the J-to-IOCS bridge is explicit: the compiler generates Loader *FILE column 29 = "M - multi-reel unlabeled file" from "MULTI, neither LABELS nor LABELN" (J 90.08.01), which is exactly IOCS's Multi-Reel Unlabeled Files case. Nothing substitutes for the end-of-reel label check: a sentinel data record is the only recourse, which is the HIGH.VALUE idiom the J sample uses.

    The one check independent of labeling, and its unstated restriction. "In addition, for a binary file, a block sequence word can be appended to the end of each block, regardless of whether the file is labeled or unlabeled. This word contains the sequence number of the block in its address and may also contain an 18-bit folded check sum of the block in the left half of the word." (external: C28-6100-2, PDF p. 41 / printed p. 33). This is a per-block sequence check, not a file- or reel-level count, and it is the only labeling-independent sequence check IOCS has; uncorrectable-redundancy detection, the other labeling-independent integrity mechanism, checks no counts. These are the object-time counterparts of COMTRAN's SPECIF SEQ and CKSUMS: the compiler generates *FILE column 33 "block sequence numbers to be checked | SPECIF - SEQ" and column 34 "block checksums to be checked | SPECIF - CKSUMS" (J 90.08.01), and IOCS's own definition of those columns restricts them: column 33 "Block sequence numbering flag (significant for binary files only): S—Sequencing words provided", column 34 "Check sum flag (available for binary sequence numbered files only): C—Check sums included" (external: C28-6100-2, PDF p. 52 / printed p. 44). The FCB encoding admits no other combination: word 2 bits 10–11 are "00 – No block sequence words / 10 – Block sequence word is present, no check sums. / 11 – Block sequence word is present, check sums are present (input) or are to be computed (output)"; there is no state for check sums without a sequence word (external: C28-6100-2, PDF p. 74 / printed p. 66). J mentions neither restriction, saying only "Block checksums are not checked unless the Environment SPECIF card option CKSUMS is selected" (J 02.07.06). Since "If no specification is made the file is assumed to be BCD" (J 02.06.04), and every file in the J sample is BCD, the practical conclusion is that on a normal COMTRAN file SEQ and CKSUMS are inoperative and the compiler passes them through unchecked; inference, from the card mapping plus the IOCS column definitions. Worth recording in §7 alongside the option table.

    LABELN / non-standard labels. IOCS still reads and writes the labels and their EOF marks and still maintains the block counter, but the content check passes to the user: entry MYLBLS + 1 "To check trailer label, input file" is the routine that sees the trailer image (external: C28-6100-2, PDF p. 33 / printed p. 25; see open question 46). Inference: IOCS cannot itself perform the block-count comparison on a non-standard trailer, because it does not know where in the image the count lies; the manual scopes the check to "every trailer written by the system" (external: C28-6100-2, PDF p. 32 / printed p. 24), and checking is exactly the half of the labeling routines the package replaces ("using different routines to check and prepare label images", same page). J corroborates the general delegation: the SERIAL/REEL/RETAIN information "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), a statement about those three fields rather than the block count, but the same division of labour. What IOCS still supplies is the running counter in FCB word 4 bits 3–17, reachable off index register 2 at every entry, so a FOR LABEL routine can do the comparison itself. Countervailing evidence, which the manual never disambiguates: item 4 of the non-standard-package list, "All the system actions and messages will apply", could be read as retaining it. Confidence on this sub-point: probable. Can F p. 41 be mapped onto IOCS at all? F says "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" (F p. 41), the count having been started at OPEN ("Checking is performed, and a record count is initiated", F p. 39, for input and output alike) and maintained at FILE ("A count of the number of records written is maintained", F p. 41). Four of its five elements fail against IOCS, and the failure of the first is definitional.

    Unit: IOCS's glossary fixes "record" in the physical sense: "BLOCK — A physical record; that is, a tape record, a card, or a line of print"; "BLOCK COUNT — The number of blocks processed on the current reel of a file, kept in the corresponding File Control Block"; against "LOGICAL RECORD — Data which, as a group, has some logical significance to the user" (external: C28-6100-2, PDF pp. 83, 85 / printed pp. 75, 77). Every count IOCS keeps is of physical records, and no logical-record count appears in any standard label. The only two other places IOCS counts "records" are tape-repositioning data, "If the Unit Control Block is for a tape unit, it also contains counts which specify the current position of the tape (file count, and record count within the file)" (external: C28-6100-2, PDF p. 49 / printed p. 41), and the reel-removal printout "UNIT XXXXX (file name) REEL XXXX – XXXXX RECORDS" (external: C28-6100-2, PDF p. 67 / printed p. 59); neither is a label field and neither is compared with anything. Inference: F's record count coincides with IOCS's block count only on an unblocked file, one logical record per block; for any COMTRAN file whose BLOCKSIZE holds more than one record, F's quantity denotes nothing IOCS keeps.

    Timing: F at CLOSE, IOCS inside READ when the trailer is read.

    Reporting: F "notification … through external display", IOCS a sequence-error ERR exit with MQ prefix 1 and no printed message at all.

    Scope: F only at end of file, IOCS every input reel. What does survive is F's conditional "if label records are present" (precisely right, since outside standard labels there is nothing to compare) and F's output-side clause "If specified by the programmer, an end-of-file label containing the record count is written", which is structurally right: IOCS writes the 1EOFbb trailer at close with a count in word 2 at exactly that point, only it counts blocks.

    Resolution for the language definition. Answer to the question as put: no; under LABELN the check is whatever the FOR LABEL routine performs, and unlabeled files get none. F p. 41's input-side close-time record-count comparison should be recorded not as an F/J divergence proper (J diverges from nothing, it defers, "A file is referenced by the commands OPEN and CLOSE to initiate and complete file activity. (See Commercial Translator General Information manual)." (J 02.07.01), leaving F's text as J's only prose on the verb) but as an F description the object-time system cannot honour, and dropped from the implemented semantics. The compiled sample bears that out: the GET calling sequence is four words with no counter increment (00200 TSX IOC)8,4 / PZE INPUTMASTER,,SYS)260 / PZE GN)058,,SYS)283 / IOCTN* BL)2,,15) and CLOSE ALL FILES compiles to TSX SYS)177,4 / PZE IOC)1 with no comparison anywhere (J 90.05 listing, PDF pp. 201, 204); inference: the field-test compiler maintained no record count at all. What a COMTRAN compiler must document instead is that a labeled input file's per-reel block count is verified automatically by IOCS, whatever SEQ says, and that a mismatch is delivered to the file's ON ERROR exit, resumable, with no message. Confidence: certain on the main claim, on the ON ERROR routing and on the block-versus-record finding; probable on the LABELN delegation; the record ↔ block identification and the non-implementation of F's count are inference. (F p. 39, p. 41; J 02.06.04, 02.06.12; J 02.07.01, 02.07.06–07; J 90.02.04, 90.02.32; J 90.05 listing, PDF pp. 201, 204; J 90.08.01; external: C28-6100-2, PDF p. 23 / printed p. 15, PDF pp. 24–25 / printed pp. 16–17, PDF p. 27 / printed p. 19, PDF pp. 31–34 / printed pp. 23–26, PDF p. 41 / printed p. 33, PDF p. 49 / printed p. 41, PDF p. 52 / printed p. 44, PDF pp. 66–72 / printed pp. 58–64, PDF pp. 74–75 / printed pp. 66–67, PDF p. 79 / printed p. 71, PDF pp. 83–85 / printed pp. 75–77)

  8. What are the semantics of an output file assigned to OU (system output unit) with respect to interleaving with compiler/loader listing output? (J 02.06.10; J 05)

  9. For DISPLAY, what exactly does the 255-word internal-form check count, and how are physical records split on the 716 printer? (J 02.04.02.01)

  10. What substitutes for the end-of-reel label check on an unlabeled MULTI input file? (F p. 40; J 02.06.04–05) Narrowed (external source, 2026-08-02): IOCS offers no substitute check; see Q50's resolution: outside standard labels there is no count check of any kind, and on an unlabeled file the end of data must be signalled by the programmer's own recognizable sentinel record; reel switching on unlabeled MULTI files is likewise uncounted (external: C28-6100-2; full inventory and citations under Q50).

  11. In the update-in-place idiom (FILE MASTER followed by GET MASTER on locate-mode files, as the sample uses), when is the input buffer considered released to the output side? J describes each verb separately; the idiom is never walked through. (J 02.07; J 90.05)

Environment, library, and system

  1. What is the physical library format and how is it built or maintained? F says only that data descriptions and procedures can be stored "in the library, on tape or in cards"; J drops the facility. (F p. 12, p. 62; J 90.01.02)

  2. Can a CALL synonym be used everywhere its old.name could (Data Description, Environment, CRYPT), and what is the synonym's scope relative to the CALL's position in the source? May it be qualified at all? (F p. 59; J 02.04.04–05)

  3. Where exactly may ENTER CRYPT appear ("at any logical point"): inside a section, inside a DO-subroutine, between divisions; and may the ENTER sentence be named? (J 02.08.01)

  4. Does OPTION COLLATE COM affect only comparisons and HIGH.VALUE/LOW.VALUE, or other behaviour as well? (J 02.06.16; J 02.04.01)

    Narrowed (90.02 mining + 90.05 listing evidence, 2026-08-01; adversarially verified 2026-08-02): two effects are documented, and the generated-code appendix plus the compiled sample show that the whole object-time apparatus behind them is one table, one switch word, and constants planted at compile time (enough to bound the answer, not to prove a negative). Effect 1 is comparison-instruction selection: the compiler "normally generates comparison type instructions based on the 709/7090 collating sequence", and "Use of this option instructs the compiler to generate comparison type instructions on the basis of the Commercial collating sequence" (J 02.06.16). Effect 2 is the figurative-constant extremes, "HIGH.VALUE will be considered to be the left parenthesis, (, and LOW.VALUE the zero, 0, unless the Commercial collating sequence (COM) is specified in the Environment Description. The Commercial HIGH.VALUE is 9 and the LOW.VALUE is blank" (J 02.04.01), and this one reaches past comparison into stored data, since the MOVE/SET result chart flags the HIGH.VALUE and LOW.VALUE rows "#", "Value dependent upon collating sequence order specified (Commercial or 709)" (J 02.04.02): MOVE HIGH.VALUE TO X deposits ( natively and 9 under COM. Against a strictly comparison-only reading stands J's own summary of the card, which is worded far more broadly, "OPTION cards are used when the programmer wants the processor to depart from its standard use of 709/7090 collating sequence, or when he wishes special emphasis placed on minimizing either storage or running time requirements in his object program" (J 02.06.02), and that sentence, not any positive evidence of a third effect, is what keeps this entry short of resolved.

    Observed in the compiled sample (native mode): both halves of effect 2 are planted constants, not run-time decisions. 197,00 71504 END.OF.MASTERS. IF D.EMP.NO = HIGH.VALUE THEN GO TO END.OF.RUN / OTHERWISE SET M.EMP.NO = HIGH.VALUE. (J 90.05 listing, PDF p. 196) compiles its SET as the generic MOVPAK character fill with the character in an in-line word, TSX SYS)182,4 / TXI SYS)245,1,6 / OCT 747474747474 (PDF p. 202, repeated for statement 198,00 at PDF p. 203), and compiles its comparison against constant-pool word CP)+23, whose definition is the identical word 01723 747474747474 ... +23 OCT 747474747474 (PDF pp. 202, 216). The word is six copies of one character, which J 02.04.01 fixes as ( for the native sequence (external corroboration, not from the manuals: 74 octal is ( in 709/7090 BCD). Under COM the same two sites would carry 9s; nothing in either sequence consults a mode at object time. The runtime library likewise contains exactly one collating artifact and exactly one consumer of it: SYS)161, "This is a conversion table used in converting from 709 to 705 collating sequence", used by SYS)162, whose calling sequence is TSX SYS)162,4 / OP SYS)161 / PZE LOC(1), T(1), LOCATOR(1) / PZE LENGTH(1), ,6*BYTE(1) / PZE LOC(2), T(2), LOCATOR(2) / PZE LENGTH(2), ,6*BYTE(2) / HIGH RETURN from comparison / EQUAL RETURN from comparison / LOW RETURN from comparison, and of which J says "This subroutine performs an alphabetic comparison on two fields. OP is a CVR or NOP depending of the need to adjust the collating sequence before the comparison" (J 90.02.12; "depending of" is the original's typo, and the dropped "y" in the same paragraph's "the field is located b the 'pointer' word" is a defect of the printed page — both confirmed on images/page-151.png, which is also the page the 90.02 conversion note misdates as PDF p.153). Inference from code shape, not a stated rule: four properties of that mechanism make COLLATE COM look comparison-only at object time. (i) The collate switch is a word of the call site, not a mode cell the routine interrogates, so it is fixed per comparison at compile time, precisely what per-section scoping requires ("limit the modal specification to a particular section … the mode of generation reverts to the normal mode at the end of the specified section", J 02.06.17), and no communication cell listed in the appendix holds a collating mode (J 90.02.08–11, which run to monitor cells, date/time, move source/target pointers and overflow flags). (ii) The adjustment is made "before the comparison" inside a routine that has no target operand and only three exits, HIGH/EQUAL/LOW, so it can only re-rank operand characters transiently; stored records, buffers and files keep their 709 representation. (iii) Nothing else in the appendix mentions collation, translation or the 705 sequence: the MOVPAK alphabetic movers SYS)239–242 copy or insert characters with no translate step, and every figurative-constant fill takes its character from the generated code: blanks and zeros have dedicated routines ("This MOVPAK subroutine moves blanks to an alphabetic field", SYS)243; "…moves zeros to an alphabetic field", SYS)244), while HV compiles, as the sample shows, into SYS)245, "This MOVPAK subroutine moves characters to an alphabetic field. The second word contains 6 characters of the type to be moved" (J 90.02.25–26); J classes HV and LV as move source types alongside BL and ZE (J 90.02.10), but which routine carries LV is unrecorded; natively 0 and under COM blank are exactly the values SYS)244 and SYS)243 already provide, and the point is unaffected either way, since all three fills are given their character by the caller. (iv) SYS)161 is a Type 2 item, one of the "Subroutines contained on the system tape which are placed in core by the CT Loader as required by the particular object program being loaded" (J 90.02.07), so a program with no COM comparison never loads the table; and COLLATE leaves no trace outside generated instructions: the appendix on "Compiler Use of Environment Description Options in Generation of Loader Symbolic Control Cards" fills those cards "on the basis of options exercised on Environment FILE and SPECIF cards" only (J 90.08.00–02), the object-deck format defines no collating flag (J 90.03), the loader has no collate control card (J 03), COLLATE appears nowhere among the deferred features or restrictions (J 90.01), and the sole -OPTION- card diagnostic in the 210-message list is "-OPTION- CARD FORMAT ERROR." (J 90.04.01 msg 3). The blast radius is further bounded by the comparison rules themselves, "Numeric fields are compared arithmetically without regard to length" and edited fields "are converted to pure numeric fields" for comparison, so neither can be affected, while "All non-format fields … are compared alphamerically" and therefore do fall under the mode (J 02.04.07), and by the fact that neither manual defines a SORT verb or any other ordering operation a collating sequence could govern (the single occurrence of the word, "In sorting problems, a programmer may use many tapes", J 06.05.02, is about tape-channel assignment for sort applications).

    Still open:
    (a) what a COM comparison physically looks like: no compilation with an OPTION card survives (the sample's Environment Description carries only FILE and SPECIF cards, J 90.05 listing, PDF p. 195), and under the default mode its alphameric comparisons, including the two = HIGH.VALUE sentinel tests, compile as an inline CAL/LAS three-way compare followed by a TRA decode, with CVR, SYS)161 and SYS)162 absent from the entire object listing (J 90.05 listing, PDF pp. 198–216; compares at pp. 201–203), so whether COM forces such compares through SYS)162 or instead emits inline CVRs is unrecorded;
    (b) the cross-mode question, since J 02.04.01 words the HIGH.VALUE/LOW.VALUE rule program-wide ("specified in the Environment Description") while J 02.06.17 lets COLLATE be scoped to one section: a sentinel planted as 9 inside a COM section and later compared under the native sequence is undefined (see open question 60);
    (c) strictly, the evidence bounds the object-time footprint and cannot exclude a compile-time-only effect that leaves no runtime trace, which is what J 02.06.02's broader wording would have to mean if it means anything more than 02.06.16 does. Recommended implementation: treat COLLATE COM as affecting exactly
    (1) the ordering used by alphameric and non-format comparisons and
    (2) the character value of HIGH.VALUE/LOW.VALUE wherever those constants are compiled, with no effect on stored representation, I/O, moves of other data, or arithmetic. (J 02.04.01; J 02.04.02; J 02.04.07; J 02.06.02; J 02.06.16–17; J 90.01; J 90.02.07, 90.02.08–11, 90.02.10, 90.02.12, 90.02.25–26; J 90.03; J 90.04.01 msg 3; J 90.08.00–02; J 90.05 listing, PDF pp. 195–196, 198–216, 201–203, 216; images/page-151.png)

  5. How is a COND (console-key) condition.name used syntactically: only as IF condition.name, or also with NOT and in compound conditions? (J 02.06.17)

  6. What happens when OPTION cards conflict (repeated global specifications, COLLATE COM mid-program without IN)? (J 02.06.16–17)

  7. Is SPECIF UNIT2 meaningful for single-reel (non-MULTI) files? Its semantics are stated only for reel switching. (J 02.06.08)

  8. What happens when a GROUP lists a file absent from the named POOL, and may a file belong to more than one POOL or GROUP? Only format errors are diagnosed. (J 90.04.01 msgs 161–165)

  9. What ordering constraints hold among Environment cards: must a FILE card precede SPECIF/POOL/GROUP cards referencing its file.name? (Only SPECIF's "may appear anywhere within the environment division" is stated, J 02.06.07.)

  10. What does the compiler do with a recognized-but-deferred construct (INCLUDE, COPY/LIBRARY, LOAD, OVERLAP, CONTRL) beyond the diagnostic: is the statement skipped, and does it consume a statement number? (J 90.04.01 msgs 108, 110, 176)

  11. What actual severity (1–5) does each of the 210 messages carry? The listing prints 0 throughout; no assignment table survives. (J 90.04.01)

  12. Does a severity 2–4 error make the punched object deck unreliable, or merely suppress automatic execution? (J 02.01.01 says only severity 5 suppresses the deck.)

  13. What limit triggers msg 200 (variable-length fields): is it the 25-item QUANTITY IN table or a distinct counter? (J 90.04.01; J 90.01.05 e) Settled by D9.7 (docs/design/decisions.md, 2026-08-02; noted here 2026-08-04): msg 200 takes the printed 25 of J 90.01.05 item e; the distinct-counter reading stays on record there as the amendment.

  14. Are shorter-than-12-digit COND key settings legal (padded) or an error? (J 90.04.01 msg 6; J 02.06.17)

  15. What is STOP n's restart behaviour on the field-test processor: does it preserve F p. 54's resume-with-next-command semantics? (J 05.06.04)

  16. What was the *COMPILE card's full option set in the 1961 system, and when was it renamed $CMPLE? (J 90.05 listing PDF p. 192; J 02.01.01)

    Narrowed (90.05 listing evidence, 2026-08-01; scan-verified 2026-08-02): the Oct 18 1961 run compiled under *COMPILE LIST (verified glyph by glyph at 400 dpi) with identification field CT PUBLICATIONS, which reappears on the *CTEXT and *CTEND loader cards. Column measurement puts LIST at card column ≈16 and the identification at ≈55 on all three cards, i.e. the same option and secondary.identifier columns the 1962 $CMPLE card uses, so those two fields' mechanics carry over (J 02.01.01 for the option set and for the identifier on *CTEND; J 03.02.09 for the identifier on *CTEXT as well, which 02.01.01 does not mention). The verb field does not carry over: *COMPILE occupies columns 7-14, so the 1961 card cannot have held deck.name in $CMPLE's columns 8-13; a three-letter token CTC prints at columns ≈1-3 on the print line immediately below the card image and is probably that deck.name, but since it prints on a separate line this is unresolved. The full 1961 option set remains unrecovered; LIST is the only option observable. The rename is bounded by the two artifacts alone: *COMPILE in use on the 18 Oct 1961 run, $CMPLE documented in the Jan 1962 manual (a bracketing inference that assumes the reprinted listing is contemporaneous with its printed date and that the two forms did not coexist). (J 90.05 listing, PDF pp. 192, 198, 216; J 02.01.01; J 03.02.09; images/page-192.png, page-198.png, page-216.png)

Sample-program loose ends

  1. What do non-zero clause digits in statement numbers (e.g. 219,03) look like in a real error listing? The sample compiles clean, so only ,00 forms appear. (J 02.02.01; J 90.05)

  2. What was the MASTER field TRIGGERS (pictorial AAA) for? Declared, pads NAME to a word boundary, never referenced (presumably reserved switch positions). (J 90.05 listing PDF p. 192)

    Narrowed (90.05 listing evidence, 2026-08-01; adversarially re-verified against page renders, 2026-08-02): TRIGGERS occurs exactly once in the surviving corpus, its declaration 7,00 71204 TRIGGERS 2 AAA, level 2, a sibling of DAT and RATE rather than a member of DAT (J 90.05 listing, PDF p. 192; verified on the page render), and appears nowhere in the object listing (PDF pp. 198-216) nor anywhere in the source Procedure Division. Its allocation is not printed (MASTER is a locate-mode record, so its fields surface only as displacements from BL)2) but it is fixed by arithmetic and independently confirmed by those displacements: DAT = EMPLOYEE.NUMBER (AA + AAAA = 6 characters) + NAME A(15) = 21 characters, TRIGGERS' AAA carries that to 24 = exactly 4 words, and the object code's MASTER displacements (1)DATE,1 word 5, EXEMPTIONS,1 6, 1)FICA,1 10, 1)WHT,1 11, 1)BONDEDUCTION,1 12, BONDACCUMULATION,1 13, 1)BONDENOMINATION,1 14) reproduce exactly the layout that follows, totalling the 15 words the program reads and writes (IOCTN* BL)2,,15; IOST MASTER,,15). TRIGGERS therefore occupies characters 22-24 = bytes 3-5 of word 3, and is precisely the padding that word-aligns RATE. Two qualifications on "never referenced":
    (i) name-absence is strong but not formally conclusive: the constant pool does name its data pointers symbolically (CP)+37-+61 are all PZE name,,byte, PDF p. 216), so a move or arithmetic touching TRIGGERS would have surfaced the name there, yet the same pool also names storage by offset from a different symbol (PZE RETPREM-2, PZE INSPREM-2, PZE 2)RATE+0), so a reference need not carry a field's own name; what settles it is that TRIGGERS is absent from the source Procedure Division too, so no source construct can generate one: the nearest group move, statement 193,00 MOVE MASTER DAT TO ERROROUT INFO, is emitted as a 21-character move (TXI SYS)240,1,21, PDF p. 202), stopping exactly at the TRIGGERS boundary; (ii) the field's bytes are nevertheless transferred wholesale, since statement 208,00's FILE MASTER writes the entire 15-word record image from the input buffer (LXA BL)2,4 / SXA GN)089,4 / GN)089 IOST MASTER,,15, PDF p. 210): on this locate-mode update-in-place file TRIGGERS is copied from input reel to output reel unchanged, never read and never set. The reserved-switch-positions reading stands, as inference. (J 90.05 listing, PDF pp. 192, 195-196, 198-216; images/page-192.png, page-202.png, page-210.png, page-216.png)

  3. Does the native 709 collating sequence place ( (HIGH.VALUE) above the digits, as the sample's sentinel less-than routing requires? Resolved (scan check, 2026-08-01): yes; ( is the final, highest character of the native sequence, above all letters and digits (independently verified on the page-050 scan); the sentinel idiom is sound. (J 02.04.01; J 02.06.16; images/page-050.png)

  4. Was F's serial-number sequence-checking claim ever true of any processor, given J disclaims it and the sample deck carries no serials? (F p. 37; J 02.03.01; J 90.05)

  5. What construct used the group-3 key word THROUGH? It appears in J's Environment-conditional key-word list (J 02.03.03) but in no command form, option, or example in either manual; F does not list it. Possibly reserved for a planned range form that never shipped. (J 02.03.03; noted during the M1 reserved-word extraction, 2026-08-03)

  6. What did the object program print for a STOP and for the base-locator guard? J 05.06.04 gives the form "AT xxxxx,yy STOP nnnnnn" and leaves the spacing of the four constant-pool words open; J 90.02.33 says SYS)294 "prints an error message" and prints no text, and J 90.04 carries no object-time entry for it. J 05.06.04 sends both messages to the on-line printer, and neither manual reproduces an on-line printer sheet: the 90.05 appendix reproduces the sample run's report output only. No unsealed evidence survives (D0.9). Answered as a design decision (docs/design/runtime.md RT-2, 2026-09-06): the STOP line drops the pool words' blank padding and reads AT 199,14 STOP RUN; the guard's line reads BASE LOCATOR NOT LOADED. (J 05.06.04; J 90.02.14; J 90.02.33; J 90.05; images/page-217.png)