Part 3 of 10 of the COMTRAN Language Definition.

3. Data description and storage model

This section defines the Data Description division of a COMTRAN source program: the file/record/field hierarchy, the fixed-column data description card, every type code, the pictorial (format-character) repertoire, constants, modes, justification and word-boundary rules, tables and subscript declaration, and every stated numeric limit. F28-8043 chapter 4 is the 1960 language description; J28-6169 section 02.05 (with 02.03 and 90.01) is authoritative for the implemented 709/7090 language. Divergences are flagged throughout and summarized in §3.11.

3.1 Files, records, and fields — the data hierarchy

The manuals define the three units of data by the verbs that may operate on them (F p. 63):

• Distinctions among "subfields," "fields," and "groups of fields" are not made by separate terms; they are handled entirely by level numbers (F p. 64). See §3.2, Level.
• Files may contain label records at beginning and end; most labeling is handled by the input-output package and the environment description, but the programmer may prescribe label details with the LABEL type code (F p. 63–64; see §3.3 LABEL).
• J tightens the record definition: "A record is a data hierarchy which may not be part of any data organization except a file or a section." (J 02.05.01)
• Declaration is mandatory: "The name of each data field referenced in Procedure statements or Environment Descriptions must appear in the name field of a Data Description entry. Neither storage allocation nor assignment of data characteristics is made for data fields not so named." (J 02.05.01)
• Files and groups of files are not entered as such in a data description: the hierarchy of data description entries begins at the record level (F p. 69, Figure 2 footnote). Records are tied to files in the Environment Description (see the Environment description section; also F p. 71: "Each record named in the data description must also be named in the environment description").

3.2 The *DATA division and the data description card

A "division header" must be placed immediately before the first entry of each consecutive group of data description cards: "The name *DATA, placed so that the asterisk is in Column 7, should be the only entry on the line (i.e., card), except for the serial number and identification entries in Columns 1-6 and 73-80." (F p. 65) The *DATA header appears as such in the 7090 compiler's symbolic listings (J 90.02.02, 90.05).

One card is used per kind of data item. The card format is fixed-column: unlike the procedure description, it "does not allow 'free form' description" (F p. 65). Column layout (F p. 65):

Ctl. and Serial (Col. 1–6)

• Sequence matters: "the sequence controls the internal position of the data" (F p. 65). The serial number is normally numeric; the first three digits ("CTL") are common to a page, Columns 4–6 carry the rest. Normally only Columns 4–5 are used initially, leaving Column 6 blank so that correction cards can be collated in later; the blank is first in the collating sequence, so 23_ < 235 < 24_ (F p. 65–67).
• F states serial numbers "will be checked for correctness of sequence" when read in; the numeric collating sequence in all IBM machines is blank first, then 0–9 (F p. 67).
• F/J divergence: the 7090 compiler does not check: "Card serial numbers in columns 1-6 of source decks are not sequence checked by the compiler." (J 02.03.01)

Data Name (Col. 7–22)

• Any name assigned to the data described; names may contain up to 30 characters (rules for forming names, F p. 15 — see §2, Language structure). Since only 16 columns are available, longer names continue in the Data Name columns of the next card, flagged by any non-blank character in Column 72; the processor closes up any blanks in the Data Name columns, so the carryover may be indented (F p. 67). J states the same: "All imbedded and leading blanks in the name fields of cards associated with an entry are eliminated and the non-blank characters are compressed to form a single name." (J 02.03.01)
• Names are written with an assumed left margin immediately to the left of Column 7; indentation is permitted for visual level-structure display and is ignored by the processor (F p. 67–68).
• If no name is assigned, Columns 7–22 are left blank (F p. 67). Names may be given to any item of data or to any group of items stored consecutively; any such name may be used as an operand in a procedure statement (F p. 67).
• No overlapping named groups: "Data-names must not overlap. ... the same field may not be included as a part of each of two overlapping named groups of fields." E.g., with successive fields A, B, C: if X names the pair A and B, then Y may not name the pair B and C. To refer to B and C together, the group must be redefined via REDEF; redefinition does not delete the original names (F p. 67).
• Name qualification (compound names) resolves non-unique names via higher-level names, e.g. EASTERN REGION SALES FORCE PAY RECORD (F p. 70–71); see §2. Qualified names may not be used in the Environment Description or in CRYPT instructions (J 02.03.03; J 90.01.04).

Level (Col. 23–24)

• "Any number from 1 to 99 can be used. All data description entries must be assigned level numbers." (F p. 68) J: "Any numbers 01-99 may be used to specify the level of fields. Leading zeros are optional and all level numbers less than 10 are right justified by the compiler." (J 02.05.01)
• Hierarchy rule: "each item is considered to be a subdivision of the last item preceding it which has a lower number" (F p. 68). Data is organized "vertically": no item is related directly to another at the same level except through a higher-level item (F p. 68).
• Level numbers need not be consecutive; any number greater than that of the next higher classification serves, and skipping numbers is recommended to allow later insertions (F p. 68).
• The highest level (i.e., the numerically smallest level number) in a program need not be 01 (J 02.05.01). All data fields at the level equal to the highest level in a source program are left justified unless explicitly specified as right justified, even if no justification is specified and previous fields do not complete full words (J 02.05.01, with worked example at level 05).
• Level numbers describe structure only; "Level numbers are not actually attached to the data" (F p. 71).
• Limit: number of levels in a data hierarchy, approximately 23 maximum (J 90.01.05).

Type (Col. 25–30)

If blank, the entry describes an ordinary data field or group of fields (F p. 71). Type codes:

Full semantics of each code: §3.3.

Quantity (Col. 31–35)

• Specifies "the total number of times the data description is required," for consecutive items of identical description; "This number must refer to data items occurring in sequence." (F p. 77)
• Default: columns usually blank; "In that case, it will be assumed that they contain a value of 1" (F p. 77; J 02.05.04: "If no value is specified, 1 is assumed").
• Maximum: "The maximum Quantity which may be specified is 2¹⁵ - 1." (J 02.05.04) [= 32767]
• "No check against this value is made at execute time." (J 02.05.04)
• "quantity numbers should not be assigned to data items not having names, unless these items include named items at a lower level" (F p. 77; repeated verbatim J 02.05.04).
• Nesting (F): "Quantity numbers may be specified for as many as three levels in a single 'nested' group": e.g. STATE quantity 5, DISTRICT 4, CITY 7 reserves 5 STATE, 20 DISTRICT, 140 CITY items (F p. 77). J is silent on a three-level cap (see ambiguity note, §3.11); its program-wide limit is ~85 array dimensions (J 90.01.05).
• A quantity entry applies its multiplication to the entry and its subordinate fields (the RATE example, F p. 75: 30 in Quantity opposite RATE lays out RATE with its four subfields 30 times).
• Quantity may not be used at the record level: "The 'Quantity columns' ... use of these columns with a data hierarchy, such as RECORD, is unacceptable." (J 02.05.01) Hence "record.names may not be subscripted" (J 90.01.03).
• Storage effect: "An entry in this field is used by the compiler to reserve storage for sequential data of the same format." (J 02.05.04)

Mode (Col. 36)

• I = internal mode, E = external mode (F p. 78). J gives the 7090 meanings: "Internal mode (I) designates that the associated numeric field is to contain data in binary form. External mode (E) designates that the stored form is BCD." (J 02.05.04)
• Mode is specified at the lowest level of data organization, the level where the field pictorial is shown; the mode of a larger unit is a consequence of the modes of its components (F p. 78).
• Storage-model consequence: "Arithmetic operations are performed only in the internal (binary) mode." (J 02.03.03) External-mode fields are unpacked and converted every time they enter arithmetic (J 02.03.03; see §3.6).

Justify (Col. 37)

• L = left justified, R = right justified, blank = packed (F p. 78–79).
• Justification for an input item describes the item as it already exists (tells the system where to look); for other items it controls placement (F p. 78).
• Left justification: left-hand character goes in the left-hand position of the next available machine word, possibly leaving the right portion of the preceding word unoccupied. Right justification: item stored to the right in the next available machine word. No justification: data is packed, "there will be no blank spaces between successive items" (F p. 78–79).
• Alignment of alphameric information cannot be specified in the field pictorial; it is done with the Justify column (F p. 79).
• J word-boundary rules and the restriction "Specification of right justification is effective only for data items with explicitly described formats. Left justification is always effective." (J 02.05.04); full detail in §3.6.

Description (Col. 38–71)

Five kinds of information may appear, and when several are needed on one line they are written in this order, separated by one or more blanks (F p. 79):

1. Format characters (the "field pictorial").
2. Constants.
3. Data names associated with the type codes REDEF and COPY.
4. The word LIBRARY, followed by the name of a data description stored in the library.
5. The words QUANTITY IN, followed by the name of a field which will contain a quantity at object time.

J adds a sixth kind of Description-field content not in F: the BLANK WHEN ZERO clause (J 02.05.07; see §3.4). Full detail on all of these: §3.4.

Cont. (Col. 72)

• Any non-blank character in Column 72 marks the next card as a consecutive part of the entry. A continued name continues in the Data Name columns; an overflowing description continues in the Description columns (F p. 84).
• Description continuation: the break must occur between words, "since the processor will assume a blank at the end of each line. Multiple blanks, however, are treated as single blanks." (F p. 83, General Note)
• Constants carried over to a new line: "the portion on each line must be treated as a complete constant (i.e., enclosed in quotation marks); the continuation indication is not used in this case, and no blanks will be assumed between successive lines" (F p. 83). J deviation: the 7090 processor happens to handle Data Description literals continued in violation of this rule correctly, but "Use of this characteristic of the 7090 processor should not be made if compatibility with other processors is desired." (J 02.03.01)
• J restrictions: "The name and description fields only of Data Description entries may be continued. All other specifications to be made for an entry must be made on the first card of that entry since these fields are not scanned on continuation cards." (J 02.03.01) The processor "replaces the contents of column 72 with a blank in Data and Environment lines"; each word or literal must be complete upon a line (J 02.03.01).
• Entry termination: "Data and Environment entries are considered complete when column 72 is blank. The period (.) must not be used to signal completion. In these sections, a period is considered part of the previous word, thus creating an undefined name." (J 02.03.02)

Identification (Col. 73–80)

Optional program-identification code; any characters from the basic character set; "the characters in these columns have no effect on either the processor or the object program" (F p. 84).

3.3 Type codes in detail

RECORD

• Marks the data as a record, "accessible by GET and FILE instructions"; each record so named must also be named in the environment description (F p. 71).
• J amplifications (J 02.05.01):

  • A record is a data hierarchy that may not be part of any data organization except a file or a section.

  • Quantity columns may not be used on a RECORD entry.

  • "When the type code RECORD is recognized the previous data organization is always terminated. Record definition is terminated by specification of a level number equal to or less than the one associated with RECORD."

  • "A record must have length, and redefinition of a record area does not give it length." The compiler considers no length specified for REC1 in:

    Name    Level    Type      Description
    REC1    01       RECORD
                      REDEF     REC1
    AREA    01                  A(40)
    

    (J 02.05.01)

  • "The length of a record is normally determined on the basis of fields defined within it. Length may also be given to a record through use of a pictorial with the RECORD entry itself." (J 02.05.02)

• Restrictions (J 90.01.03): "A name associated with the RECORD type code must be unique. If the record is defined within a section the section.name may not be used as a qualifier of the record.name." "Since a quantity specification may not be made at the record level, record.names may not be subscripted."
• Records are fixed length unless a QUANTITY IN option appears within them (then variable length — J 02.07.03; see §3.8 and the Input/Output section).

COND

• Declares that the entry names one of the possible conditions (values) a conditional variable (a field) may assume (F p. 71–72). The condition-name is "the name of the value which can be placed in a field; it is not the name of the field itself" (F p. 72).

• Binding: condition-name entries are given a lower level (higher number) than the conditional variable's field entry and immediately follow it in the data description; the actual value is written in the Description columns as a constant in quotation marks (F p. 72). Worked example (F p. 72):

  SERIAL  DATA NAME                    LEVEL  TYPE     QUANTITY  MODE JUST  DESCRIPTION
          MARITAL.STATUS               0  6                                 A
          SINGLE                       0  7  COND                           'S'
          MARRIED                      0  7  COND                           'M'
          DIVORCED                     0  7  COND                           'D'
  

• Semantics: MARRIED ≡ MARITAL.STATUS = 'M'; SET MARRIED and IF MARRIED are interpreted as SET MARITAL.STATUS='M' and IF MARITAL.STATUS='M' (F p. 72). See §2 (condition-names) and the procedure section (SET, IF).

• COND entries are optional: a programmer who writes only full-form conditional expressions (IF MARITAL.STATUS = 'M' ...) need not declare condition-names (F p. 72).

• J rules: "Normally this type code is associated with several entries naming and describing the values a particular field may have. These entries must be preceded by a higher level entry defining the format of the fields and must all have the same level number and include the COND type code." (J 02.05.02)

• Restrictions: "Neither a data item (literal) nor a condition.name may be subscripted. However, a conditional variable may be subscripted." (J 90.01.03)

• There is also a COND Environment card (J 02.06.17): separate mechanism; see the Environment description section.

REDEF

• Purpose: redefine an area or item previously defined, for time-shared use of storage, renaming, regrouping with new level structures, and setting up tables (F p. 73). "Use of the REDEF code does not erase data in storage, unless an attempt is made to place two or more different constants in the same area; however, it does superimpose a new format upon the data already present." (F p. 73) "Redefinition does not cancel the previous definition. ... Once an area has been defined, all names associated with the definition may be used at any time, regardless of subsequent redefinitions." (F p. 73)
• F card usage: the REDEF entry carries the type code REDEF, has "the same level number as the entry being redefined," and the name of the area being redefined is written in the Description columns (F p. 73, 81). In F's example the REDEF line itself is unnamed "but the programmer could assign one if he wished" (F p. 75).
• F/J divergence on the REDEF card: J requires the REDEF line to be bare: "When the REDEF type code is used, it should appear on a line with no additional coding except a serial number and the name of the item being redefined. The first item appearing thereafter must have the same level number as the item referenced by the REDEF." (J 02.05.02) Under J the redefinition's structure begins with the following entries; F's optional name-on-the-REDEF-line does not fit J's rule (see ambiguities).
• J storage-assignment semantics: "When a REDEF is first encountered, the contents of the storage assignment counter are saved by the compiler, and assignment proceeds according the REDEF. The effect of a REDEF is terminated upon encountering an item of a level above or equal to the level of the item referenced by the REDEF or upon encountering another REDEF. Termination of the former type causes the storage assignment counter to be restored and assignment proceeds in the normal manner." (J 02.05.02)
• Name qualification ignores REDEFs: "Compound names are formed without regard to REDEFs (or other type codes) and as a function of the level and position within the program of the simple names only." (J 02.05.02, with two worked examples in which the completely qualified name of H is A G H.)
• Restrictions:
  • "An area involved in a REDEF must not contain subscript variables or a QUANTITY.IN value." (J 90.01.03)
  • "Whenever an input record containing an array is involved in a REDEF, the record containing the array should precede the REDEF in order to get optimum results." (J 90.01.03)
  • Constants "cannot be defined ... as part or all of the redefinition of an area." (J 02.05.06) (Plausible resolution, not stated by J: the F table technique (constants first, REDEF second) appears unaffected, since the constants belong to the original definition rather than the redefinition. See §3.7 and §8.5.)
  • Redefinition of a record area does not give the record length (J 02.05.01).
  • I/O interaction: if a record is REDEF'd to share an area with data other than records of the same file, all records of the file are automatically 'transmitted' (with a message if they were to be located); all records related through REDEF are made available when any one is requested by GET (J 02.07.05). Records from different files REDEF'd together are not automatically transmitted by the field test processor; SPANS or HOLD must be used (J 90.01.01). See the Input/Output section.

COPY and library data descriptions

• F semantics: COPY copies a data description previously defined in the program under a new name and, optionally, a new level. New name in Data Name columns, COPY in Type, original name in Description; "This description must already have been read into the system for the COPY code to be able to operate on it." (F p. 76) The copy replaces the original name with the new name, and if a new level number is given, all subordinate level numbers are adjusted to retain their original relationship: original 01, 03, 04 copied at level 05 becomes 05, 07, 08 (F p. 76, with the PAY.RCD.MASTER → PAY.RCD.DETAIL worked example on F p. 76–77).
• Library form: "The word LIBRARY, followed by the name of a data description stored in the library, designates a data description which is to be copied. ... When a library data description is prescribed, the type code COPY must be used." (F p. 81) Library conventions: see §7.
• F/J divergence (both deferred in J): "Implementation of COPY has been deferred." (J 90.01.03) "Mechanization of the INCLUDE verb has been deferred, and consequently no library facilities are currently available." (J 90.01.02)

LABEL

• F: "The type code LABEL identifies a data description as that of a label record. This will cause a redefinition of the label area in the input-output control system." Details deferred to processor publications (F p. 77).
• J implementation: LABEL "allows the programmer to redefine with the indicated data description entries, the single 14 word label area in the Input/Output Control System from which all labels for output files are written and into which all input labels are read." The area may only be processed via the FOR LABEL option on Environment FILE cards, which transfers control to the specified procedure.name at open, close, or reel switch (implementation in Appendix 90.07). Labels processed this way are limited to 14 words, and portions of the FOR LABEL coding must be done in CRYPT; the manual notes the alternative of "defining labels as records and processing with the GET and FILE verbs." (J 02.05.03)

RCDMRK (J only)

"The RCDMRK type code causes insertion of a single character record mark constant in the indicated position. No description field specification is required since the compiler automatically provides a pictorial with a single A. Information may be freely moved into or out of this position subject only to the restriction imposed by its single character alphameric format." (J 02.05.03) Not present in F.

PARAM and FUNCT (F only — removed)

• F: FUNCT identifies a function-name (a data-name specified in the GIVING clause of a BEGIN SECTION command) which "must be fully described in accordance with the provisions of this chapter" (F p. 73). PARAM identifies a parameter: each data-name listed in the USING clause of a BEGIN SECTION command (F p. 73). See F's functions discussion (F p. 32) and the procedure section.
• F/J divergence: "These two type codes described in the General Information Manual are no longer in the language." (J 02.05.03)

3.4 The Description field in detail

Format characters (the field pictorial)

Format characters serve two functions: they show the number of character spaces a field occupies, and the kind of character occupying each space; the result is a "field pictorial" (F p. 79). For data brought in at object time, the pictorial must reflect the data as it already exists: "changes in input data cannot be effected by the field pictorial"; for data produced by the program, the pictorial directly controls how the data is handled (F p. 79). With the stated exceptions (V, S, F, overpunched signs, (n)), one format character is required per data character of reserved storage (F p. 79).

The complete repertoire (F p. 80):

Worked examples of pictorial ranges (F p. 81):

Field types on the 7090 (J chart)

The implemented compiler classifies every field into one of six types (chart, J 02.05.05; overpunched digits shown with combining overline per the conversions):

Chart notes (J 02.05.05):

1. "The only sign specification which may be used for an external decimal field is an overpunched + or - in the rightmost position of the field. A + and - may not appear in the character by itself."
2. "An edited field may have a character position reserved for the sign or may have the sign over the rightmost digit."
3. "Numeric external fields may contain leading blanks which are treated as leading zeros."
4. "Scientific decimal is the edited form of the floating point. The maximum fractional portion of a scientific decimal field is 16 digits."

Rules and restrictions on pictorials (J)

• Group fields ("non-format" fields): "A field for which no pictorial is given is treated as alphameric with length equal to the length of its subfields." (J 02.05.06) Conversely, "No subfields may be specified for the field whose format is described. The only entry which may legitimately appear at a lower level is a COND definition." (J 02.05.06) In J's example, A (subfields B, C: internal 99 each) and D (subfields E, F: A(6) each) are each treated as alphameric fields of length 12 (J 02.05.06). Such fields without pictorials are the "non-format fields" of J 02.04.07, which "are compared alphamerically" (J 02.04.07; see procedure section).
• Mixed pictorials illegal: "A field may not be described as a mixed numeric and alphameric field, i.e., both A's and 9's in a pictorial. If this specification is made the field is treated as alphameric." (J 90.01.03)
• Non-format characters: "Any non-format character appearing in the pictorial will result in the pictorial being interpreted as a name. An error message will be produced if the pictorial is not a data, key, or a procedure name." (J 02.05.06) (This is how REDEF/COPY target names and QUANTITY IN clauses coexist with pictorials in the same columns.)
• Precision: "Fixed point double precision numbers are denoted in the Data Description by formats representing more than 10 digits. Double precision internal floating point numbers are specified by 'FF' in the Data Description." (J 02.05.06)
• Edited fields are converted to pure numeric fields for comparison; they may not be compared to alphameric fields (J 02.04.07). Comparisons between numeric and alphameric fields are invalid (J 02.04.06). See procedure section.

Constants in data descriptions

• A constant is "a value, or a group of symbols, placed in the program for use without alteration" (F p. 81). It is declared by writing a field pictorial followed, after at least one blank, by the actual value enclosed in quotation marks on the same line (F p. 81). Example (F p. 81):

  SERIAL   DATA NAME              LEVEL  TYPE    QUANTITY   MODE  JUSTIFY  DESCRIPTION
           PERCENT.CONST                                                            V99 '05'
  

• Constants vs. literals (F p. 81): literals are written in procedure statements, constants in data description entries; "Constants, unlike literals, must always be enclosed in quotation marks, even though they may be wholly numeric."

• Constants "may contain any character"; the punctuation/spacing rules do not apply inside them (F p. 28). (The 1960s literal-delimiting quote is rendered as ' in the conversions.)

• Decimal points are not normally required in table constants; the decimal location is specified by the later pictorial (F p. 74).

• Continuation: each line's portion must be a complete quoted constant; no continuation punch; no blanks assumed between successive lines (F p. 83; see §3.2 Cont.).

• J restrictions: "Constants cannot be defined. i in a field whose pictorial characterizes it as an edited field. ii as a part of a located input area. (see section 02.07). iii following a variable length field. iv as part or all of the redefinition of an area." (J 02.05.06)

• J sizing rules:

  • Alphameric constants: "No format specification is required in the definition of alphameric constants. The length of the literal is assumed as the length of the field." If a pictorial is furnished and its length is greater than the constant, the constant is left-justified and blank-filled; if less, characters are placed from the left until the field is full, the remainder discarded, and an error message produced (J 02.05.06).
  • External decimal constants: "the length specified by the pictorial must be exactly equal to the length of the constant. Also, the constant must utilize the sign convention given in the pictorial e.g., If the pictorial is 999⁺, the number 123⁺ would be correct whereas 123 would not be correct" (J 02.05.07).
  • Internal decimal constants: pictorial length may be larger than the constant (constant right-justified); if the constant is larger it is truncated at the left end to the pictorial's size, converted, stored, and an error message produced. "The appropriate sign conventions for internal decimal constants are: i leading + or - ; ii trailing + or - ; iii no sign" (J 02.05.07).

QUANTITY IN data.name

• F mechanics (F p. 82–83): an "advanced" facility to regroup an already-reserved area at object time. A quantity value is placed in a named field, and the entry refers to it by "QUANTITY IN" plus the field's name in the Description columns. Values found in the named fields at object time override any values in the Quantity columns. Storage is reserved by the compiler from the ordinary Quantity value (in F's example, 100 items of 999V99 = 500 character spaces, reusable as a 10×10, 20×5, or 4×25 table by storing new values in COLUMN.QTY / ITEM.QTY) (F p. 82–83). Worked entries (F p. 83):

  SERIAL   DATA NAME              LEVEL  TYPE    QUANTITY   MODE  JUSTIFY  DESCRIPTION
           TABLE                    01
           COLUMN                   02                                              QUANTITY IN COLUMN.QTY
           ITEM                     03               100                            QUANTITY IN ITEM.QTY
  

• J: "Use of this option indicates that the associated entry(s) is to be repeated a variable number of times as determined at execute time by the value in the indicated 'data.name'. The compiler reserves sufficient storage for the maximum number of times the field may be present on the basis of the value entered in the Quantity Field." (J 02.05.07)

• Consequences in the implemented language:

  • A field using QUANTITY IN is a variable length field; variable length fields may not be compared (J 02.04.07).
  • A record containing any QUANTITY IN field is a variable length record (J 02.07.03; see §3.8).
  • "Fields may not be defined following a variable length array as part of the same data hierarchy." (J 90.01.04)
  • Constants may not be defined following a variable length field (J 02.05.06).
  • An area involved in a REDEF must not contain a QUANTITY.IN value (J 90.01.03).
  • Figurative constants may not be moved to variable length arrays (they may be moved to fixed length arrays or to array elements) (J 90.01.02; J 02.04.01, ARRAY/FIELD example: MOVE BLANKS TO ARRAY illegal, MOVE BLANKS TO FIELD(3) proper).
  • Limit: number of QUANTITY IN specifications ≈ 25 (J 90.01.05).
  • The dimensions of an array must be set before subscript values for the array are calculated; failure "causes invalid object code" (J 90.01.02; see §3.7).

BLANK WHEN ZERO (J only)

"When associated with an output field this clause indicates that the field is to be replaced with blanks when it becomes zero. Since leading blanks in numeric input fields are automatically treated as zeros, the use of this clause is redundant [for input]. In some cases it may even result in decreased efficiency in the object program as these fields are treated as edited types." (J 02.05.07) The clause by itself characterizes a field as an edited field (J 02.05.05 chart). Not present in F. Neither manual shows its exact written form or position on the card (see ambiguities).

3.5 Signed-number representation and overpunch

• F: + and - may reserve an actual character position, or may be entered as an overpunch with format character 8 or 9, "in either the units or high-order position of a field," in which case no space is reserved (F p. 80).
• F/J divergence: on the 7090, "The only sign specification which may be used for an external decimal field is an overpunched + or - in the rightmost position of the field. A + and - may not appear in the character by itself." (J 02.05.05 note 1) An edited field may have either a reserved sign position or the sign over the rightmost digit (J 02.05.05 note 2). The conversions render a minus-zone overpunch with a combining overline (9̅, 8̅) and a plus-zone overpunch with a superscript plus (9⁺, and constants such as 123⁺) (J 02.05.05, 02.05.07).
• Numeric external fields may contain leading blanks, which are treated as leading zeros (J 02.05.05 note 3).
• Internal-mode sign: for a right-justified internal field, "the sign value in the sign bit of the word"; for left/no-justify internal fixed point fields, the sign occupies the "leftmost bit of the field" (J 02.05.04; see §3.6).
• Zero: "For comparison purposes zero is considered an unsigned number, even though computational sequences generated by the compiler may produce negative or positive zeros." (J 02.04.07)

3.6 Mode, justification, and the machine storage model

The 709/7090 storage model, as stated by J:

• Arithmetic is binary only: "Arithmetic operations are performed only in the internal (binary) mode." (J 02.03.03) External (BCD) fields entering arithmetic are unpacked and converted each time; the manual's remedy is MOVE-ing them once to an internal-mode area (J 02.03.03 — e.g., the IR999 field X in the worked example, J 02.03.03/02.03.03.01; the I is scan-confirmed as the letter I, see §8.5.8).
• Internal mode, right justified (R): the 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)
• Internal mode, left justified (L) or unjustified (blank): "The length of a numeric internal mode fixed point field designated as left justified or without justification specification is the least multiple of 6 bits sufficient to contain the number and its sign (leftmost bit of the field so designated)." (J 02.05.04)
• Left justification (any mode): "reserves storage beginning with the leftmost bit of a new word and extending through as many words and bits as necessary." No justification "differs only in that storage reservation begins immediately to the right (within the same word if possible) of the preceding storage reservation", i.e., packing (J 02.05.04; F p. 79).
• External mode, right justified: "storage is reserved beginning in a new word so that the field's last character is also the rightmost character of its final word." (J 02.05.04)
• Effectivity rule: "Specification of right justification is effective only for data items with explicitly described formats. Left justification is always effective." (J 02.05.04)
• Default at top level: all fields at the highest (numerically smallest) level used in the program are left justified unless explicitly right justified (J 02.05.01).
• Precision: fixed point double precision = pictorials of more than 10 digits; floating point double precision = FF; a double-precision right-justified internal field occupies two words (J 02.05.06, 02.05.04). Mixed-mode expression evaluation rules (floating/double forcing) are procedure-side: J 02.04.05.01; see the procedure section.
• Addressing granularity: a positional indicator for an array element "contains the location (word and byte) of the particular element" (J 02.04.07); storage is word-organized with character (6-bit) resolution within words. (Neither manual states the 36-bit word size explicitly in these sections; the 6-bit-multiple rule and "six (6) BCD characters" control word (J 02.07.03) imply six characters per word.)
• F's machine-independent framing: data is always identified by its position; the processor assigns each named item an initial location from the length and relative position given in the data description, and tracks all changes of position (F p. 62). Packing trade-offs (space vs. unpacking cost) are discussed at F p. 78–79.

3.7 Lists, tables, and subscripts (declaration side)

Concept and layout

• A list or table is "an ordered grouping of data"; fixed data is usually entered as a series of constants, variable data arrives with input records or is produced by the program (F p. 28). A printed table is stored row by row as "one long 'string' of data"; two- or three-dimensional structure is preserved by level numbers (F p. 29). Every line must consist of exactly the same number of character spaces, with each item in corresponding position (F p. 29).
• Placement requires two steps: "(1) establishing the structure and format of the table, and (2) making provisions to enter the required data in that structure" (F p. 28).

The canonical F technique: constants + REDEF

Step 1. Enter the data as constants (F p. 74):

SERIAL   DATA NAME                      LEVEL   DESCRIPTION
         RATE.TABLE                      01
                                          02     'LOS ANGELES        15342 28516 21287'
                                          02     'MIAMI              07860 14163 11892'

Step 2. Superimpose structure by redefinition (F p. 75):

SERIAL   DATA NAME              LEVEL   TYPE    QUANTITY   MODE  JUSTIFY  DESCRIPTION
                                  01     REDEF                                    RATE.TABLE
         RATE                     02                30
         CITY                     03                                             AAAAAAAAAAAAAA
         ONE.WAY                  03                                             999V99
         ROUND.TRIP               03                                             999V99
         EXCURSION                03                                             999V99

The 30 in Quantity opposite RATE reserves the RATE group (with its four subfields) 30 times; ONE.WAY (17) then obtains the one-way rate on the 17th line, and MOVE ONE.WAY (DESTINATION) TO BILL.AMOUNT uses the value found in the DESTINATION field at object time (F p. 75–76). Code values used as subscripts "must be assigned in a sequence corresponding to the lines of the table" (F p. 76). A city name can be bound to a line number by declaring, e.g., MIAMI as the name of the constant value '17' (F p. 30).

Subscript rules

• Subscripts are written in parentheses after the data-name; multiple subscripts in one pair of parentheses are separated by single commas (F p. 28, rule 10; F p. 30).

• "as many as three subscripts may be used within the same pair of parentheses" (F p. 30); the number of subscripts used must correspond to the number of levels of the table required to obtain the item (F p. 30–31). PAGE (150) LINE (10) WORD (4) and PAGE LINE WORD (150, 10, 4) are equivalent; a unique name may be subscripted directly: WORD (150, 10, 4) (F p. 30). "Subscripts are always written in descending order of level." (F p. 78) Example: with quantities 5, 4, 7 on STATE/DISTRICT/CITY, CITY (3,2,6) obtains the sixth CITY of the second DISTRICT of the third STATE (F p. 77–78).

• General form of a subscript (F p. 31):

  a * VARIABLE ± b
  

  "in which the quantities a and b are literals and the name VARIABLE is the name of a field which may contain a variable quantity. This name may be a compound name, but, whether simple or compound, it must not have a subscript. Condition-names may not be used in subscripts. A name, literal, or arithmetic expression used as a subscript must represent a positive integral value." (F p. 31) A subscript may also be a single data-name or a literal (F p. 31, 75).

• Origin: "The initial value of an array is A(1) and not A(0)." (J 02.04.07.01)

• "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)

• "The dimensions of an array must be set before calculation of subscript values associated with the array is performed. Presently, failure to observe this restriction causes invalid object code." (J 90.01.02, with the SET I/SET J/SET Q example.) When an array follows a variable length array, subscripts must be set prior to a subscripted reference (J 90.01.02).

• Each unique subscripted name (A(J,K), A(J,K+1), A(2,3), ...) causes generation of one positional indicator, re-evaluated when its subscripts change value (J 02.04.07); details and CRYPT "Symbolic Registers" belong to the procedure/CRYPT sections.

• Restrictions: record.names may not be subscripted (J 90.01.03); a data item (literal) or condition.name may not be subscripted, a conditional variable may (J 90.01.03); the (old.name) in CALL may not be subscripted (J 90.01.01, 02.04.05).

• Field-test caveat: "All input records containing arrays will be processed in the transmit mode by the field test processor." (J 90.01.01)

3.8 Record length: fixed vs. variable (storage view)

Primary treatment in the Input/Output section; the data-description-relevant facts:

• "There are two record types, fixed length and variable length." A fixed length record "cannot vary from the length specified by the data description." (J 02.07.03)
• "The QUANTITY IN clause, by designating that the length of a field within a record is variable in length, identifies the record as being a variable length record." The number of words processed on read/write is defined at object time by the current QUANTITY IN data.name value(s); "Storage, if the record is transmitted, is always allocated on the basis of the maximum size of the record." (J 02.07.03)
• The standard variable length record is preceded by a control word containing the record length: "Although this control word is not described as part of the record in the Data Description and may not be addressed by the programmer, it must be considered in specifying block size" (J 02.07.03). BCD form: six BCD characters giving the length in words (J 02.07.03).
• Located records: all references to fields of a located record initially specify location zero and are adjusted upon GET; referencing before the first GET destroys low memory (J 02.07.05). Constants cannot be part of a located input area (J 02.05.06).

3.9 Storage areas

F chapter 4 closes with the storage-areas doctrine (F p. 84–85):

• Programmers conventionally distinguish an input area (space reserved for the original record before processing), working storage (e.g., intermediate results needed later but never output), an output area (where the output record is assembled), and areas for reference data "such as constants, literals, and tables" (F p. 84).
• COMTRAN erases the distinction: "Storage areas are automatically reserved when the data description is written, regardless of how the area is to be used." (F p. 84–85) All areas are addressed by location and governed by the same instructions (F p. 84).
• Obligations on the programmer: all data-names required for input and output, as specified in the processor manual, must be properly described; "every item of data used in the program, whether as input, output, or for intermediate operations" must be described (F p. 85). J's converse: no storage is allocated for fields not named in a Data Description entry (J 02.05.01).
• On the 7090, buffer storage for I/O is reserved by the Loader and assigned dynamically (J 02.07.02); located records live in buffers, transmitted records get their own storage; see the Input/Output section.

3.10 Numeric limits and defaults — summary

(Values from J 90.01.05 are headed "Appox-Max Size": approximate maxima of compiler internal tables.)

3.11 F/J divergences in data description — summary

Open flags for the compiler writer (detailed in the §8.5 catalog): the maximum subscript/quantity-nesting depth under J; the exact written form and card position of BLANK WHEN ZERO; the meaning of "non-format field"; and whether a named REDEF line is accepted. (The exact reading of the External Decimal row of the J 02.05.05 chart, formerly flagged here, has been scan-resolved; see §8.5.8.)