L I E> R.AR.Y 
 
 OF THE 
 
 UN IVLRSITY 
 
 Of ILLINOIS 
 
 5I0.S4- 
 U6r 
 
 no.355-3G0 
 
 cop.2. 
 
The person charging this material is re- 
 sponsible for its return on or before the 
 Latest Date stamped below. 
 
 Theft, mutilation, and underlining of books 
 are reasons for disciplinary action and may 
 result in dismissal from the University. 
 
 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 
 
 NOV 1 1971 
 
 OCT 13 
 
 Recto 
 
 L161— O-1096 
 

 /SpL^&H 
 
 Report No. 356 
 
 # 
 
 
 ICL: A CONTROL LANGUAGE FOR ILLIAC IV 
 
 by 
 Denise Christine Pavis 
 
 October 13, I969 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 
 
 THE LIBRARY OF THE 
 
 fSfilLINfllS 
 
Report No. 356 
 
 ICL: A CONTROL LANGUAGE FOR ILLIAC IV 
 
 by 
 Denise Christine Pavis 
 
 October 13, I969 
 
 Department of Computer Science 
 
 University of Illinois at Urbana-Champaign 
 
 Urbana, Illinois 6l801 
 
 *This work was supported in part by the Advanced Research Projects Agency 
 as administered by the Rome Air Development Center under Contract No. 
 US AF 30(602)UlU4 and submitted in partial fulfillment of the requirements 
 for the degree of Master of Science in Computer Science, October, I969. 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/iclcontrollangua356pavi 
 
ii 
 
 ABSTRACT 
 
 This paper describes ICL, Illiac Control Language and the job parser 
 which interprets the ICL. ICL is a free format, ALGOL-like language which 
 allows the user to specify tasks to be processed in serial or parallel and 
 provides for the conditional execution of tasks dependent upon the results of 
 previously processed tasks. The job parser builds a tree which represents the 
 ordering of tasks and dossiers, which contains in tabular form all information 
 about a task and its associated files necessary to process the task. 
 

 ACKNOWLEDGMENT 
 
 The author would like to express her sincere appreciation to the 
 members of the operating systems group and Mr. Peter Alsberg in particular for 
 their invaluable advice and criticism during the design of ICL. 
 
 Mrs. Patricia Douglas must be thanked for her excellent job of typing 
 the manuscript. 
 
 Finally, the author would like to express her gratitude to the 
 Department of Computer Science and the ILLIAC TV project for its financial 
 support and for the use of its facilities and the aid of its staff. 
 
IV 
 
 TABLE OF CONTENTS 
 
 Page 
 
 1. INTRODUCTION 1 
 
 2. SYNTAX 2 
 
 2.1 Task 2 
 
 2.1.1 Introduction 2 
 
 2.1.2 Procedure Declaration 2 
 
 2.1.3 Procedure Body 3 
 
 2.1.2+ Execute Card 3 
 
 2.1.5 1^ File Card k 
 
 2.1.6 B6500 File Card 9 
 
 2.1.7 Examples of Procedures 9 
 
 2.2 Logic 10 
 
 2.2.1 Logic Card 10 
 
 2.2.2 Conditional Logic Statement 11 
 
 2.2.3 STOP 12 
 
 2.2.4 STEP 12 
 
 2.2.5 Switch Set Statement 12 
 
 2.2.6 Example of Logic Card 13 
 
 2.3 An ICL Program 13 
 
 2.3.1 Control Program 13 
 
 2.3.2 Library 15 
 
 3. IMPLEMENTATION: THE JOB PARSER 16 
 
 3.1 Introduction 16 
 
 3-2 The Tree Builder 16 
 
 3.3 The Doer 22 
 
Page 
 LIST OF REFERENCES 25 
 
 APPENDIX: ICL SYNTAX 26 
 
VI 
 
 LIST OF FIGURES 
 
 Figure Page 
 
 1. Logic Tree Ik 
 
 2. B6500 Disk File Name Block for MY/FIRST/ PR OGRAMLIB 21 
 
 3- Disk Blocks 23 
 
V) J 
 
 LIST OF TABLES 
 
 Table Page 
 
 1. THE ILLIAC DOSSIER 19 
 
 2. THE ILLIAC FILE DOSSIER 20 
 
 3. B6500 DISK FILE NAME BLOCK 21 
 
1. INTRODUCTION 
 
 The Illiac Control Language, ICL, is the user's interface to ILLIAC IV. 
 The job parser interprets the ICL and builds a tree which represents the entire 
 job. Each node represents a task to be performed on the ILLIAC IV or the B6500 
 and points to a dossier which describes the task and the data files required by 
 the task. Several tasks may be specified to be executed in parallel, since each 
 node has a pointer to the next parallel task and a pointer to the next sequen- 
 tial task associated with it. 
 
 Several design criteria strongly influenced ICL. First, a user famil- 
 iar with B5500 - B6500 control language should not have to learn an entirely new 
 language. Second, the language should be free format. Third, the language 
 should reflect the parallel capabilities of ILLIAC IV by allowing the user to 
 specify tasks to be done in parallel. Fourth, the language should allow for 
 conditional execution of tasks depending upon the results of completed tasks. 
 Fifth, the job parser, the ICL interpreter, should be capable of interacting 
 with the on-line user, reporting to him the status of his job and any errors in 
 his ICL code. Sixth, as much advantage as possible should be taken of the B65OO 
 MCP. 
 
 Chapter 2 describes the syntax of ICL. Chapter 3 describes the job 
 parser and gives the format of the tables and dossiers built by the job parser. 
 
 of a four-quadrant configuration. 
 
SYNTAX 
 
 The syntax of ICL is specified in TBNF [1]. All identifiers in ICL 
 have a maximum length of 17 characters and are represented by the symbol <*I> 
 in the TBNF productions. The symbol <*N> represents an integer. The complete 
 syntax is given in the Appendix; the following description is intended as an in- 
 troduction to ICL and as a user's manual for the first edition. 
 
 2.1 Task 
 
 2.1.1 Introduction 
 
 An ICL task is defined to be a single program to be executed on the 
 B65OO or the ILLIAC IV or any series of operations which can be specified by 
 
 a legal sequence of E-6500 control cards. Syntactically , a task or tasks may be 
 
 * ** 
 
 declared as a procedure to be invoked by the appearance of a procedure call. 
 
 2.1.2 Procedure Declaration 
 
 <procedure declaration> ::= PROCEDURE <*I> <parameter list>? <insert>? ; 
 
 <procedure body> 
 <parameter list> ::= ( LIST [<*I> <default>?] SEPARATOR ,) 
 <default> ::= "=" <file identified [2] 
 
 The parameter list allows the same procedure to be used for many dif- 
 ferent purposes by changing the calling parameters. The default option specifies 
 
 Procedure declarations will not be permitted in the first edition, 
 but keep reading as one will have to know what a procedure body is. 
 
 See 2.1.6. 
 
that if the matching calling parameter does not occur then the parameter will 
 be set to the default. 
 
 <insert> ::= IN <B6500 disk file name> 
 
 The insert option allows the user to automatically place the proce- 
 dure into the library file given by the B6500 disk file name. 
 
 2.1.3 Procedure Body 
 
 <procedure body> ::= <execute card> | BEGIN <step block> END 
 
 <step block> ::= [<execute card> [<lk file card> * | <B6500 file card> * ]*]* | 
 
 < any legal B6500 control card sequence with the "?" replaced by 
 
 "#" > 
 
 If more than one execution is specified by a procedure, the tasks 
 represented are processed sequentially. A B65OO control card sequence is trans- 
 ferred to a zip file after replacing the "##" by "?" and is handed to the B65OO 
 MCP [2] by the B6500 scheduler [3]. 
 
 2.1. k Execute Card 
 
 <execute card> ::= EXECUTE <switchset>? <program name> ON <machine name> 
 
 <time limit>? ; 
 <switchset> ::= <switch> := 
 <switch> : := SW<*N> 
 
 Switches SW1 through SW255 are global variables (type integer) avail- 
 able to the user to store the results of programs. If the program is a system 
 
 Library files are disk files containing ICL procedures. See 2.3.2. 
 
program (e.g. the TRANQUIL compiler), the switch will be set by the system pro- 
 gram to represent the relative success or failure of the program. If the pro- 
 gram is a user program there will be a facility for passing an integer between 
 
 2k 
 1 and 2 -1 to the operating system which will then set the switch to this 
 
 * 
 value. Switches may be used in if statements to specify conditional execution 
 
 of tasks. 
 
 <program name> ::= <B6500 disk file name> 
 
 <machine name> ::= [lU|lLLIAC IV] <number of quadrant s>? |b6500 
 
 <number of quadrant s> ::= ([l|2|3|*+]) 
 
 <time limit> : : = FOR <*N> 
 
 The time limit is given in terms of an integral number of seconds. 
 EXAMPLES: EXECUTE SW2 := A/B ON ik ; 
 
 EXECUTE C/D ON B6500 FOR 5 \ 
 
 2.1.5 Ik File Card 
 
 <lk file card> ::= FILE <*I> = ^initialization part> (<disk map part>) ; 
 
 IMMEDIATE < data > ## ENDDATA ; ] 
 
 The immediate form of the ILLIAC file card specifies that the file 
 follows in line and is terminated by ## ENDDATA where "##" appears in columns 
 one and two. 
 
 <initialization part> ::- [(<segments per record>? <motion part>)]? 
 <segments per record> ::= <*N> 
 
 *See 2.2.2. 
 
 ** 
 
 for four-quadrant configuration. 
 
Motion part> :: = [MOVE ON LIST [<B6500 disk file name> | § <*I>] 
 SEPARATOR &]? [MOVE OFF [<B6500 disk file name> | 
 
 The initialization part specifies the number of ILLIAC IV disk seg- 
 ments per record (default of one), where the file comes from and where it is to 
 be placed when the task is completed. Several B6500 disk files may be concaten- 
 ated to make one ILLIAC file at initialization time. In order to be saved a 
 file must be moved off the ILLIAC disk. 
 
 <disk map part> :: = <prefix> «map element list>) | <map element list> | 
 
 SIZE OF [<B6500 disk file name> | # <*I>] 
 
 The SIZE OF form of the disk map part implies that the user does not 
 want to map his data onto the disk in any special manner and knows only that 
 his file is the same size as some file on the B6500 disk. 
 
 <prefix> ::= <*K> | [@] ? <iocation> | location list> 
 
 <location> ::= EU <euno> | SU <suno> | TRK <trkno> | SEG <phase> 
 
 <location list> ::= ( LIST <location> SEPARATOR ,) 
 
 <euno> : : = ' 1 
 
 <suno>*:: =0 | 1 | 2 | 3 | k \ 5 | & | 7 I 8 | 9 | 10 | 11 
 
 <trkno> : : = < integer between and hrj inclusive > 
 
 <phase> : : = < integer between and II99 inclusive > 
 
 The disk map part of the ILLIAC file card allows the user to map his 
 data onto the disk in the' manner which affords him the most efficiency. A pre- 
 fi^may indicat e that the specification which follows is to be repeated one or 
 
 later. ^ 6Se ^^ ^ ValM f ° r the first s y stem ' ^y will be changed 
 
more times; is to be placed on a particular electronics unit, storage unit, or 
 track; or is to "be phased relative to a particular segment number. Electronics 
 units, storage units, tracks, and segments can be expressed in absolute or rela- 
 tive terms. The presence of "@" before a prefix indicates that the prefix is 
 absolute, e.g. @EU1, @SU5 implies that space for the specification following 
 is to be reserved on the EU and SU which are respectively numbered 1 and 5 by 
 the hardware. Otherwise a prefix is relative, e.g. SU5 implies that the follow- 
 ing specification is to be placed on any SU and, once chosen, that SU will be 
 known as SU5 in case any later specifications require placement on the same SU. 
 
 EXAMPLES OF PREFIXES: 
 
 Make 2 copies of the following specification. 
 (@SUO, EUl) Space for the following specification is to be reserved 
 
 on absolute storage unit and relative electronic unit 
 1. 
 @SEG15 For the following specification relative segment is 
 
 to be set to absolute segment 15- 
 
 <map element list> : := LIST <map element> SEPARATOR , 
 
 <map element> ::= <*N> <qualifier> : <*N> <size qualifier> | 
 
 <*N> <size qualifier> - <*N> <size qualifier> | 
 
 <*N> <qualifier> : <repetitive element> | 
 
 <*N> C <size qualifier> | <*N> <T qual> | 
 
 <prefix> (<iiiap element list>) 
 <Tqual> ::= [T | R | S] < any alphameric string > | < > 
 <size qualifier> ::= [R S] < any alphameric string > | < > 
 <qualifier> ::= [D | M | R \ S] < any alphameric string > | < > 
 Repetitive element> ::= (<*N> @ <*N> <qualifier> : <*N> <size qualifier>) 
 
There are several forms of the map element; this variety allows the 
 user to think of the disk in terms of degrees, milliseconds, segments or re- 
 cords. The user requests disk space in units of segments, records or tracks. 
 (E.g. 200, 1+00S, 2TRK. ) If there is no qualifier the request is assumed to be 
 a request for records. He may ask for a contiguous portion of the disk by 
 appending a "C to his request (e.g. 200C, J+OOC SEG). He may ask that a re- 
 quest be phased with respect to a relative or absolute zero by preceding his 
 request with a phase specification in terms of degrees, milliseconds, segments, 
 or records. A phased request is by implication a contiguous request. (E.g. 
 10D: 100, 5MILLISEC: 100SEGMENTS. ) Checking is done on the first letter of 
 the qualifier; any blank free alphameric sequence is allowed to follow; hence 
 D is equivalent to DEGREES is equivalent to DEG, etc. 
 
 The conversion between degrees and segments is 360° per 1200 segments. 
 Hence 3° corresponds to 10 segments. Any phase request in terms of degrees 
 which is not a multiple of three will be handled as if it were the next higher 
 multiple of three (e.g. a request for 10DEG is equivalent to a request for 
 12DEG) . The disk has a kO millisecond rotational latency and hence one milli- 
 second corresponds to 30 segments. 
 
 The repetitive element requests a given block of disk space to be re- 
 peated at a given interval for a specified number of times. For example, 
 5 @ 10MS: 7S reserves five blocks of seven segments where the first segments 
 of any two consecutive blocks are separated by 10 milliseconds. 
 
 EXAMPLES : 
 
 10 DEG: 10 Starting at degree 10 (converted to segment 
 
 ho) space for 10 records is reserved. 
 500C Space for 500 contiguous records is reserved. 
 
 100S - 500 S Starting at segment 100, 500 segments are 
 
 reserved. 
 
8 
 
 2(@EU0(10D: 10, 100C), 50CS) On absolute electronic unit 0, starting at 
 
 degree 10, space for 10 records is reserved, 
 space for an additional 100 contiguous re- 
 cords is reserved on absolute electronic 
 unit 0. 50 contiguous segments are reserved 
 anywhere on the disk. Two copies of the en- 
 tire specification are made. 
 
 An entire Ik file card looks like: 
 
 FILE C = (2 MOVE ON A/B & Al/Bl)( @ SEG5 (@EU0 (100: 500, 200: 500 ), @ EU1 
 (100: 500, 200: 500)), 1000C) 
 
 and conveys the following information: 
 
 1) The file is blocked two segments per record. 
 
 2) The file is to be initialized from B6500 disk file A/B concatenated with 
 B6500 disk file Al/Bl. 
 
 3) The file is not to be saved. 
 
 k) On absolute electronic unit 0, relative segment is to be set to absolute 
 segment 5- Space for 500 records (1000 segments) starting at relative 
 segment 200 (absolute segment 205, relative record 100 ) and for 500 more 
 records starting at relative segment ^00 (absolute segment *+05, relative 
 record 200) is to be reserved on electronic unit 0. 
 
 5) The same request as k is to be repeated on absolute electronic unit 1. 
 
 6) 1000 additional contiguous records (2000 segments) are reserved; they may 
 be anywhere on the disk. 
 
2.1.6 B6500 File Card 
 
 <B6500 file card> ::= FILE <*I> = <file identified 
 
 <file identifier> ::= <B6500 disk file name> <options> | <immediate file> | 
 
 <unit file> 
 
 <options> : := < to be specified > 
 
 <Bb500 disk file name> ::= LIST <*I> SEFAKATOR/ 
 
 <unit file> ::= < to be specified > 
 
 <immediate file> : : = FILE <*L> = IMMEDIATE <data> ## ENDDATA 
 
 Unit files are not implemented in the first version. Immediate files 
 have the same format and meaning as in lh file card. Options will be identical 
 to the options allowed by Burroughs 6500 MCP for their file cards (not as yet 
 released) [2]. 
 
 A B65OO file card which follows a B6500 execution request has the 
 obvious meaning. However, a B65OO file card may appear after an ILLIAC IV exe- 
 cution request. In this case, the file referred to is assumed to be a data 
 file for use by the job partner. 
 
 2.1.7 Examples of Procedures 
 
 PROCEDURE STEP1 (X = Xl/Yl); 
 BEGIN 
 
 EXECUTE A/B ON ILLIAC IV FOR 5; 
 
 FILE C = (MOVE ON #X)((@SEGO, EU1, SUO)(0: 500, 1000: 100), 
 10M: 50, 100) 
 
 FILE D = (SIZE OF M/N/Q) ; 
 END; 
 
 The #<*!> construct permits quick recognition of the parameter as it 
 appears in the text. If in the procedure call the parameter X is not specified, 
 
10 
 
 then file C will be initialized from file Xl/Yl. Note that the parameters are 
 not positional and may therefore occur in any order. Procedure STEP1 may be 
 invoked by the following calls: 
 
 STEP1 (X - Q/R) 
 STEP1 
 
 PROCEDURE STEP2 
 BEGIN 
 
 EXECUTE SW5 := A/B ON B65OO; 
 
 FILE M = IMMEDIATE; 
 { data} 
 
 # ENDDATA; 
 END; 
 
 PROCEDURE STEP3 
 BEGIN 
 
 ## COMPILE MY/PROG XALGOL SYNTAX; 
 
 # XALGOL FILE CARD = S0URCE/J0B1 SERIAL; 
 END; 
 
 2.2 Logic 
 
 2.2.1 Logic Card 
 
 * 
 
 <logic card> ::= BEGIN <logic body> END | <procedure call> 
 
 <logic body> ::= LIST <parallel statement> SEPARATOR [NEXT | ;] 
 
 <parallel statement> : ;= LIST <step> SEPARATOR [& | ALSO] | <set switch statement > 
 
 A special terminal symbol following the ,f END" will most likely be 
 
 added to the syntax later. 
 
11 
 
 <set switch statement> ::=<switch> := [<switch> | <*N> | [MAX MIN] 
 
 ( LIST <switch> SEPARATOR , ) ] 
 <step> ::= <procedure call> | <procedure body> | <file identifier> | 
 
 (<parallel statement>) | Conditional logic statement> | STOP 
 <procedure call> ::= <*I> <calling parameter list>? 
 
 <calling parameter list> ::= ( LIST [<*I> = <file identifier^ SEPARATOR ,) 
 Conditional logic statement> ::= IF <boolean> THEN (<parallel statement>) 
 
 ELSE (<parallel statement>) 
 <boolean> ::= <switch> [< | > | = | NEQ | LEQ, | GEQ] [<*N> | <switch>] 
 
 The logic card allows the user to specify the logical sequence in 
 which his tasks are to be processed. Tasks separated by "ALSO" or "&" will be 
 
 "ivrn-u-m" M " 
 
 processed in parallel. The appearance of NEXT or ; implies that all pre- 
 vious tasks must be completed before the next task is initiated. "ALSO" or 
 "&" takes precedence over "NEXT" or "j " but parentheses allow the user to 
 specify any ordering since the expression within the parentheses is evaluated 
 first. The conditional logic statement provides further control by allowing 
 conditional execution of tasks. 
 
 2.2.2 Conditional Logic Statement 
 
 In the conditional logic statement the value of a switch is compared 
 
 2k 
 to another switch or to an integer between 1 and 2-1. If the result of the 
 
 comparison is true the parallel statement following the "THEN" will be executed; 
 
 if the result is false the parallel statement following the "ELSE" will be 
 
 not implemented in first edition. 
 
12 
 
 executed. The parallel statements following the "THEN" and "ELSE" must be 
 
 enclosed in parentheses. 
 
 EXAMPLES: 
 
 IF SW10 > 5 THEN (STOP) ELSE (A & B) 
 
 IF SW20 NEQ SW17 THEN (A) ELSE (IF SW6 LEQ 200 THEN (A) ELSE 
 (C NEXT D) ALSO R) 
 
 2.2.3 STOP 
 
 The special reserved word "STOP" when executed stops all further pro- 
 cessing and indicates that the user's job is to be terminated. 
 
 2.2. k STEP 
 
 A step then can be a conditional logic statement, a "STOP", a proce- 
 dure call, or a procedure, or it can be a file identifier. The file referred 
 to by the file identifier must contain more ICL which is inserted at this point. 
 When the ICL on this file is exhausted control will be returned to the original 
 file. 
 
 2.2.5 Switch Set Statement 
 
 To avoid race conditions set switch statements can occur only after 
 
 a "}" or "NEXT". Switches can be set from other switches, to any integer be- 
 
 2k , 
 
 tween and 2 - 1 or the maximum or minimum of a list of switches (where the 
 
 list has maximum length of six switches) 
 
 Note: Go tos are not allowed since before any task can be sent off 
 to be processed all tasks that precede it must be completed. Keeping track of 
 all possible paths and the corresponding number of preceding tasks per path 
 that must be completed would increase the complexity of the job parser by an 
 estimated factor of 2. 
 
13 
 
 EXAMPLES: 
 
 SW1 :- SW5 
 SW1 := 257 
 SW17 := MAX (SW2, SW3, SWk, SW6) 
 
 2.2.6 Example of Logic Card 
 
 The job parser interprets the user's ICL creating a tree which repre- 
 sents the logical structure of the user's job. Each node of the tree is an en- 
 coding of a conditional logic statement including a true and a false pointer 
 corresponding to the THEN and ELSE branches, or a switch setting statement 
 which has only a sequential pointer, or a task to be executed which has a se- 
 quential and a parallel pointer, or a join which brings together the THEN and 
 ELSE branches and which has a parallel and a sequential pointer, or a STOP 
 which has no pointers. 
 
 A & IF SW2 > 10 THEN (C & (D NEXT F)) ELSE (G & H NEXT R) & Z NEXT SW5:= 200 
 NEXT Q; 
 
 The above ICL generates the symbolic tree of Figure 1 where S = 
 sequential, P = parallel, T = true, F = false and an "X" in the pointer indi- 
 cates that the pointer is null. Single letter identifiers are procedure calls. 
 
 2.3 An ICL Program 
 
 2.3.1 Control Program 
 
 <control program> : := <accounting card>; [<library card>;] * 
 
 <procedure declaration> * <logic card> 
 <accounting card> ::= < to be specified > 
 
Ik 
 
 IF 
 
 » S 
 
 H 
 
 + S 
 
 ]SJ 
 
 R 
 
 * S 
 
 1SJ 
 
 ■ ^C 
 
 F 
 
 ^ 
 
 ft? 
 
 JOIN 
 
 ^ 
 
 UI 
 
 Set switch 
 
 ^ 
 
 Q, 
 
 1X1X1 
 
 Figiire 1. Logic Tree. 
 
15 
 
 2.3-2 Library 
 
 <library card> : : = LIBRARY = LIST <B6500 disk file name> SEPARATOR , 
 
 A library card gives a list of disk files or libraries which contain 
 procedures. Any procedure called in logic card must be declared or be found in 
 a declared library. 
 EXAMPLE: 
 
 LIBRARY = LIB1/NAME/PR0CS, LIB2/PR0CS 
 
16 
 
 3. IMPLEMENTATION: THE JOB PARSER 
 
 3-1 Introduction 
 
 There is a job parser attached to each user. The job parser inter- 
 prets the user's ICL, builds a tree which describes the logical structure of 
 the user's tasks and dossiers or tables which describe the tasks, initiates 
 tasks, and cleans up after the completion of a task. The job parser is really 
 two modules; the first, the builder, builds the tree and the dossiers. The 
 second, the doer, runs down the tree sending off ILLIAC tasks to the disk file 
 allocator and B6500 tasks to the B65OO scheduler. The builder will be discus- 
 sed first. 
 
 3.2 The Tree Builder 
 
 As mentioned in the syntax description section, each type of step in 
 the logic card generates a different type of node in the tree. A set switch 
 step generates this node: 
 
 sequential pointer 
 
 last 3 switch indices in max. -min. 
 list or unused 
 
 index of 
 switch tc 
 be set 
 
 no. of 
 
 nodes 
 
 that 
 
 join 
 
 here 
 
 no. of 
 nodes 
 that join 
 here that 
 are done 
 
 first 3 switch indices from max. -min. 
 list or switch index or integer from 
 which first switch is to be set. 
 
 1+7 k6 k\ 
 
 k^k3ik2 kl 33 28 23 
 1 if set from max or min 
 
 1 if max, if min 
 
 1 if set from another switch 
 
 EXAMPLE: SW10:= MAX (SW2, SW3, SW*+, SW5) 
 
 not filled in yet 
 
 n 
 
 
 
 
 
 10 
 
 not 
 in yet 
 
 filled fil 
 
 .led 
 oy doei 
 
 1+7 1+6 1+5 kk ^3 k2 kl 
 
 33 
 
 28 
 
 23 
 
17 
 
 A conditional logic statement generates this block: 
 
 true pointer 
 
 false pointer 
 
 switch 
 index 
 
 kj k6 k5 
 
 compar- 
 ison 
 code 
 
 3% 
 
 no. 
 
 join 
 here 
 
 no. nodes 
 joining 
 done 
 
 switch index or integer to be com- 
 pared to 
 
 33 2$ 
 
 37 
 
 23 
 
 1 if compare to switch 
 if compare to integer 
 
 ,EQL 
 NEQ 1 
 
 LSS 2 
 LEQ k 
 
 GTR 3 
 
 GEQ 5 
 
 EXAMPLE : 
 
 IF SW10 > 200 THEN (A & B) ELSE (C) generates: 
 
 pointer to A 
 
 pointer to C 
 
 
 
 
 
 10 
 
 3 
 
 
 
 not filled 
 in yet 
 
 not filled 
 in yet 
 
 200 
 
 1+7 k6 h5 37 3^ 33 
 
 28 
 
 23 
 
 The join node that corresponds to each if has the following format 
 
 sequential pointer 
 
 parallel pointer 
 
 no . node s 
 joining 
 here from 
 false 
 branch 
 
 no. nodes 
 joining 
 here from 
 true 
 branch 
 
 no. of 
 
 nodes 
 
 that 
 
 are 
 
 done 
 
 pointer to if that gener- 
 ated the join 
 
 47 1+6 
 
 Uc 
 
 39 38 37 
 
 3^ 33 
 
 28 
 
 23 
 
 if corresponding if is false, 1 if true 
 (filled in by doer) 
 
 EXAMPLE: 
 
 not filled in yet 
 
 not filled in yet 
 
 WT6k5 
 
 filled 
 by doer 
 
 filled 
 by doer 
 
 pointer to if 
 
 w 
 
 39 38 37 33 28 
 
 23 
 
18 
 
 A procedure call or a procedure body generates an execution node with the 
 following format : 
 
 sequential pointer 
 
 switch to \ / 
 be set from v 
 condition 
 code 
 
 parallel pointer 
 
 ^ 
 
 no. nodes 
 that join 
 here 
 
 no. nodes 
 
 joining 
 here that 
 are done 
 
 pointer to dossier 
 or zip file 
 
 h3 
 
 35 3^ 
 
 33 28 23 
 
 1 if restart after halt load 
 
 1 if done 
 
 1 if initialized 
 
 1 if zip file pointer (B6500 task) 
 
 filled by doer 
 
 Procedure logic determines what type of step the ICL specifies. If 
 it is a procedure call or procedure body, procedure EXECUTECARD is called to 
 determine whether the task is an ILLIAC or B6500 task. If it is a B65OO, a 
 zip file is created and a pointer to the zip file is inserted in the corres- 
 ponding node. If it is an ILLIAC task, dossiers describing the task are gener- 
 ated. The ILLIAC dossier has the format specified in Table 1. 
 
 The ILLIAC dossier points to the disk file requests. Each ILLIAC 
 task generates at least one file request—that of the program file. Each addi- 
 tional ILLIAC TV file generates a new dossier, and all file dossiers are linked 
 together. The format of the file dossiers is given in Table 2. They are gener- 
 ated by procedure I^FILE CARD which parses the Initialization part and which 
 calls PREFIX and MAPLIST to parse the disk map part. 
 
 B6500 file cards referring to job partner data files are handled by 
 storing the card image in a disk block and pointing to it from the ILLIAC 
 dossier. 
 
 Since the external B65OO disk file name may be arbitrarily long, 
 special blocks are designed to contain these names. The pointer to the job 
 
TABLE 1 
 
 THE ILLIAC DOSSIER 
 
 19 
 
 
 WORD 
 
 FIELD 
 
 L 
 
 0:1 
 
 [47:2U] 
 [23:24] 
 
 L 
 
 1:1 
 
 
 LS 
 
 2:1 
 
 
 L 
 
 3:3 
 
 
 L 
 
 6:3 
 
 
 L 
 
 9 = 3 
 
 
 FS 
 
 12:1 
 
 [1+7:24] 
 [23:24] 
 
 S 
 
 13:1 
 
 
 FS 
 
 14:1 
 
 [47:24] 
 [23:24] 
 
 L 
 
 15:1 
 
 [1+7:21+] 
 [23:24] 
 
 
 16:1 
 
 [47:24]FS 
 [23:24]S 
 
 S 
 
 L 
 
 17:1 
 18:1 
 
 
 
 19:1 
 
 [47:8]L 
 
 [39:8]L 
 
 [31:8]FS 
 
 [23:8]FS 
 
 [15:2]S 
 
 [13:1]L 
 
 [12:1]L 
 
 [11:1]L 
 
 [10:1]L 
 
 [ 9:1]L 
 
 [ 8:1]L 
 
 [ 7:1]L 
 
 L 
 
 20:1 
 
 [33:8] 
 [25:4] 
 [21:5] 
 [16:17] 
 
 L 
 
 21:1 
 
 
 S 
 
 22:1 
 
 [23:24]S 
 
 
 23:7 
 
 
 FIELD CONTENTS 
 
 link to the next older lead dossier (DISK ALLOC] 
 
 link to the next younger lead dossier (DISK ALLOC] 
 
 job ID number (JOB PARSER] 
 
 job step number (JOB PARSER] 
 
 project ID (JOB PARSER] 
 
 user ID (JOB PARSER] 
 
 access code (JOB PARSER] 
 
 pointer to the next sequential step (JOB PARSER] 
 
 pointer to the next parallel step (JOB PARSER] 
 
 step condition code (EXEC MONIT) 
 
 pointer to the file map table (DISK ALLOC] 
 
 pointer to the file name table (DISK ALLOC] 
 
 pointer to the preprocess requests (DISK ALLOC] 
 
 pointer to the postprocess requests (DISK ALLOC] 
 
 pointer to the disk file requests (JOB PARSER] 
 
 pointer to the job partner name (JOB PARSER] 
 
 maximum time for this step element (NS) (JOB PARSER] 
 
 maximum time for the whole job (MS) (JOB PARSER] 
 
 category requested (JOB PARSER] 
 
 category received (DISK ALLOC] 
 
 step level (JOB PARSER] 
 
 number of steps that join here (JOB PARSER] 
 
 number of quadrants required (JOB PARSER] 
 
 dossier built (JOB PARSER] 
 
 request queued (DISK ALLOC] 
 
 file space allocated (DISK ALLOC] 
 
 data preprocessed (D PROCESSR] 
 
 execution completed (EXEC MONIT) 
 
 data postprocessed (D PROCESSR] 
 
 file space freed (DISK ALLOC] 
 
 year (69, 70, etc.) :"\ time of (JOB PARSER] 
 
 month: /entry (JOB PARSER] 
 
 day: ' I into (JOB PARSER) 
 
 time (seconds): J system (JOB PARSER) 
 
 time of entry into disk file allocator (DISK ALLOC] 
 
 pointer to job partner data files (JOB PARSER, 
 reserved for future expansion 
 
TABLE 2 
 THE ILLIAC FILE DOSSIER 
 
 20 
 
 WORD 
 
 FIELD 
 
 0:1 
 
 07:24] 
 
 
 [23:24] 
 
 1:3 
 
 
 4:3 
 
 
 7:1 
 
 [47:24] 
 
 
 [23:24] 
 
 8:1 
 
 [47:24] 
 
 
 [23:24] 
 
 FIELD CONTENTS 
 
 number of words used in this "block 
 
 pointer to next block 
 
 file name 
 
 unused 
 
 number of segments/record 
 
 total number of segments in the file 
 
 pointer to preprocess requests 
 
 pointer to postprocess requests 
 
 Starting at word 8 and continuing until the file is exhausted are two- 
 word blocks specifying the segment relations. The file specification 
 is terminated by a two -word block containing zeros. 
 
 9:1 [47:24] segment number to start at 
 
 [22:24] number of segments, including above, involved in 
 this specification 
 
 10:1 [43:1] =1 if specific segment is required 
 
 [42:1] =1 if the space is contiguous 
 
 [4l:l] =1 if the space is phased 
 
 [40:1] =1 if a virtual EU is required 
 
 [39:1] =1 if a virtual SU is required 
 
 [38:1] =1 if a virtual TRK is required 
 
 [37:1] - 1 if a specific EU is required 
 
 [36:1] =1 if a specific SU is required 
 
 [35:1] =1 if a specific TRK is required 
 
 [34:4] EU number 
 
 [30:8] SU number 
 
 [22:10] TRK number 
 
 [12:13] phase (in terms of segments) 
 
21 
 
 partner, pointer to preprocess and pointer to postprocess requests point to 
 these kinds of blocks. The format is given in Table 3 and an example in 
 Figure 2. 
 
 TABLE 3 
 B6500 DISK FILE NAME BLOCK 
 
 0:1 [1+7:2^] 
 [23:24] 
 
 number of words used in this block 
 pointer to next block 
 
 Starting at word 1 and continuing until the name is exhausted are three- 
 word blocks. The n-th block contains the number of characters and the 
 n-th identifier or the name. 
 
 1:1 [1*7:6] 
 
 [41:1+2] 
 2:2 
 
 number of characters of identifier (for BCL input) 
 first 7 characters of identifier 
 remainder of identifier 
 
 
 
 9 
 
 
 1 
 
 2 
 
 ' m y 
 
 
 
 2 
 
 
 3 
 
 
 4 
 
 5 
 
 F 
 
 I 
 
 R 
 
 s 
 
 T 
 
 
 
 5 
 
 
 
 
 
 
 
 
 
 6 
 
 
 
 
 
 
 
 
 
 7 
 
 10 
 
 p 
 
 R 
 
 
 
 G 
 
 R 
 
 A 
 
 M 
 
 8 
 
 L 
 
 1 
 
 B 
 
 
 
 
 
 
 9 
 
 
 
 
 
 
 
 
 
 10 
 
 
 
 
 
 
 
 
 
 
 
 29 
 
 
 Figure 2. B6500 DISK FILE NAME BLOCK FOR MY/FIRST/PROGRAMLIB. 
 
22 
 
 The tree builder might be best understood by considering an example 
 of a task and constructing the appropriate disk blocks. 
 
 EXECUTE SW10 := SYS/PARSER ON ILLIAC IV (l) WITH PARSER/'PARD FOR 5; 
 FILE B = (8 MOVE ON A/B MOVE OFF C/D)((@EU1, @SUO, @TRKO) 
 (0: 600 SEGMENTS), SU1 (•+((): 10, 10MS: 20)), 
 100C, 500, 200C) 
 generates the disk blocks of Figure 3* 
 
 3.3 The Doer 
 
 The doer runs in parallel with the builder. It begins at node of 
 the tree and runs down the tree sending ILLIAC IV tasks to the disk file alloca- 
 tor and B6500 tasks to the B65OO scheduler. It also checks for tasks that have 
 been completed, freeing the disk blocks belonging to that task. 
 
 A task is sent off provided that all tasks which logically precede it 
 have been completed. The doer works by chasing down the parallel pointers, 
 sending off tasks, until a null or empty parallel pointer is reached. It will 
 then back up and chase down sequential pointers. When it can send off no more 
 tasks, it will check for completions and begin again. 
 
 The doer proceeds according to the following algorithm: 
 1. Number of nodes that join here is not equal to number of nodes that join here 
 that are done—put node in WAITS stack and go to 2, else continue. 
 
 1.1 Stop node — quit. 
 
 1.2 If node — evaluate if, go to true or false node. 
 
 1.3 Set switch node — set the switch, go to next sequential node. 
 1.1+ Join node — go to 1.5*2. 
 
 Assuming two processors on the B6500, it is started after the builder 
 so that it will have some data to work with. 
 
23 
 
 
 JOB PARTNER NAME f 
 
 
 
 
 
 
 
 7 
 
 
 
 1 
 
 
 
 
 
 
 
 
 2 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 4 
 
 p 
 
 A 
 
 R 
 
 r. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 a 
 
 ^^^^^ == ~~~ 
 
 as 
 
 2fi 
 
 ™r==»-<r" 
 
 
 POSTPROCE3S 
 
 
 \ ' 
 
 
 
 
 
 
 7 
 
 
 1 
 
 1 
 
 C 
 
 
 
 
 
 
 
 2 
 
 
 
 
 
 
 
 
 
 S 
 
 
 
 
 
 
 
 
 
 4 
 
 1 
 
 D 
 
 
 
 
 
 
 
 8 
 
 
 
 
 
 
 
 
 
 a 
 
 
 
 
 
 
 
 
 
 7 
 9 
 
 
 —v~— 
 
 t» 
 
 
 
 — r , 
 
 KEY> i/ FILLED IV PROSRAM OTHER THAN JOB PARSER 
 
 M NOT USED IN FIRST EDITION OF THE 
 
 OPERATING tlTHCM 
 ? FILLED IN LATER OR NOT KNOWN FROM 
 
 INFORMATION OIVEN 
 
 NOTE- KL INPUT ASSUMED 
 
 Figure 3« Disk Blocks. 
 
2k 
 
 1.5 Execution node 
 
 1.5.1 Send off task to disk file allocator or B6500 scheduler. 
 
 1.5.2 Both parallel and sequential pointers empty, put node in PAREMPTY and 
 SEQEMPTY" stacks, go to 2. 
 
 1.5. 3 Sequential pointer empty, put node in SEQEMPTY stack; parallel pointer 
 null, go to 2, else get node pointed to by parallel pointer and go to 1. 
 
 1.5.4 Parallel pointer empty, put node in PAREMPTY stack; sequential pointer 
 null, go to 2, else get node pointed to by sequential pointer and go to 1. 
 1.5-5 Sequential pointer not null, parallel not null, put node in SEQSKIP stack 
 if not there already, get node pointed to by parallel pointer and go to 1; 
 parallel pointer null, get node pointed to by sequential pointer and go to 1. 
 1.5-6 Sequential pointer null, parallel pointer OK, get node pointed to by 
 parallel pointer and go to 1. 
 
 1.5-7 Both null, quit. 
 
 2. Get here if nothing else can be sent off. 
 
 2.1 Something has been completed, set done bit, repeat. 
 
 2.2 No more completions. 
 
 2.2.1 Check WAITS if anything can be done, now get node number and go to 1. 
 
 2.2.2 Go through the SEQEMPTY stack to see if any sequential pointers have 
 been filled in — if so, transfer node to SEQSKIP stack if not there already. 
 
 2.2.3 Go through PAREMPTY stack if any of the parallel pointers have been 
 filled in — get node and go to 1. 
 
 2.2.4 Go through SEQSKIP stack— get first node and go to 1. 
 
 2.2.5 Go to 2. 
 
25 
 
 LIST OF REFERENCES 
 
 [1] Trout, H. , "A BNF Like Language for the Description of Syntax Directed 
 
 Compilers", Report No. 300, Department of Computer Science, Univer- 
 sity of Illinois at Urb ana -Champaign (January 1969). 
 
 Burroughs Corporation, "Master Control Program Design Concepts for the 
 B6500/B7500 Information Processing System", Systems Programming 
 Department, Business Machines Group, Burroughs Corporation, Pasadena, 
 California (June I969). 
 
 [3] Alsberg, P., and Mills, C. , "The Structure of the ILLIAC IV Operating Sys- 
 tem", to be published by ACM, Second Symposium on Operating Systems 
 Principles (October I969). 
 
26 
 
 APPENDIX 
 ICL SYNTAX 
 
 <CUNTROL 9^D6KAM>: t«<ACCOUNTING CARD> <LI13RARY CARD>* 
 cPRpfFbUPfc DECLARATION CARD>*<LnGIC CAPD> 
 
 <L1BPARY :aR0>II«L IPKARY»<FILF NAME LIST>i 
 
 <F ILF NA"r LISt>««*i IST<R6500 DISK FILE NAMf> SEPARATOR > 
 
 <PROCEDURi DECifRATIbN C ARD>ll «PROCEDURE<* I> <PARAMETER LIST>? 
 <TN«r R T>?;<PHOCFDI)RF BODY>j 
 
 <PARAMETT, LIST>» » a fLrsTf<*I><OEFAULT>?]SEPARATOP »> 
 
 <ULFAULT>II« 3<H[t l9FMIFIEf<> 
 
 <INSFRl>t|« IN <P».50H DISK FILF NAMF> 
 
 <PR0CEDli«»r ppDv>: «e<EXFCUTE CARD>/REGlN <STFP Rl rC*> END 
 
 <LxECUTE :ARD>: t*LXECljTE <SwTTCHSET>? <PROC.RAM NAMF> ON 
 <HAr"lKE KAML> <TIMF LIMIT>?; 
 
 <SNITCHSPT>I |s<SWJTrh>|« 
 
 <SWlTCH>i t BSW<*K> 
 
 <PROGKAM vAMF>t l»<FRE 1PENT1FIER> 
 
 <MACHINE \AHE>I » = l I «/ I LL I AC I V/ ILL I AC I V J t ( t /2/3/4 ) 1?/b65C0 
 
 <TIMF Ll'MT>. »«FP|. <*N> 
 
 <STEP BL0CK>I :«r<F XECUTE CARD>fIA FILE CARD>*/ 
 
 <Po500 FILE CARD>*]*]*/ 
 
 «ANv LL6AL R6500 CONTROL CARD SEQUENCE WITH ? 
 
 REPi KED bY t*i 
 <L0GIC CA^D>t JeHF ( ,U' <LOGlC HODY> END/<pROCEDllRF fALL> 
 <LOGIC PHDYlt* tTs» <PARALLEL STATEMENT> SEPARATOR 1 1 /NEXT ] 
 <PARALLF|. STATF^FnI>» » = L I ST<STFP>SEPAKATORt 8/ALSO 1/ 
 
 <SET SWITCH STPT> 
 <SET SHIT:" SI Ml > I ir<SWlTCH>|«t<SWlTCH>/<*I>/ 
 
 [MAy/MjN](LTsT<SWlTCH>SEPARATC)R# )I 
 
27 
 
 <STEP>I l*«PROCrni»ht CALt>/<PROCEDURE BOOY>/ 
 
 <ft| t jOfNTIF IFR>/(<PARALUL STATFMFNT>>/ 
 
 <CJNnTlIONAL LOGIC *TATEMENT> 
 <PROCEDURr CAL|>U«<*I> <CALLING PARAMFTFR LlST>? 
 <CALLlNG 'ArAmftFh i J ST> 1 1 «(L I ST t <♦ I >»<F Il_F IDENTIFIER> 3 
 
 SEPARATOR >) 
 <CONniTin\(AL LPGH fTATEMFNT>« t«!f <BUOLFAN> THFN 
 
 (<PAPALLFL STATEMENT>) ELSt ( <PARALLEL $TATtMENT>) 
 <BOPUAK>i j=<b^lTt h >r</>/«/NE«/LFO/GEo]t<*N>/<SW!TCH>J 
 <I* FILF CARD>I t«F HE <*I>«r<INlTlALl7ATlON PART> 
 
 (<DI«K MAP PAR1>)J]/ IMMED1ATF <pATA> f* ENDDATA 
 
 <D1SK MA" PaRT>» *«<F REF!*>C<MAP EIFMEnT l.lST>)/ 
 
 <"Ap F[EPtNT LIST>/ SIZE UF <B6500 DISK FILE NAME> 
 
 <PREFlX>t:=<*N>/f* 3?<LntATION>/<LOCATION LTST> 
 <LOCA7IPM>t t«E|i*Fl.NP>/SH<SUNf)>/TRK<TRhNO>/SFG<PHASE> 
 <PHASE>t t*<AMY IwiLGtR UFTWFFfc o ANp 11992 
 <L0CATIPN LlST>»lsUlST <!-OCATIpN> SEFARATpR O 
 <EUNP>» ».3D/1 
 
 <SU^P>« »«3/l/*/3/<4^/iS/7/P/9/lO/ll 
 <TRKN0>» l«ANY IKUGFH RETKEEN AkP «7> 
 <MAP ELEMENT L!ST>iibLIST <MAP ELEMENT> SEPARATPR # 
 <MAP LLF*Oi> t |«<*N><«UALIFIFR>K*N><S17F QUALIFIFR>/ 
 <*N><5IZF OUALIFIF R>-<*N><SIZF OljALlFIFR> / 
 
 <*N><P|.AL lFIFR>KRf PETITIVE F| \>/ 
 <*N>C<biZF 0UALIFIER>/ 
 
 <*N><T(,U»L>/ 
 
 <PRFPTX>(<MAP Fl.FMENT IIST>) 
 <TQUAL>i t»lR/S/HsA*Y ALPHAMERIC SEOUINCFJ/O 
 <SI7F QUA.lFIEpH i*rR/SJ*AMY ALPHAMERIC SE0UAmCE*/<> 
 <QUAl IFIf 9> « »«rPA/R/$]£AfcY ALPHAMERIC SFQUENCE>/<> 
 <REPF7ITTvF FLT>» » *( < *N>P<*N><QijALlF IE R> K*N> > 
 
28 
 
 <IN!TULT*MTO|w PARTt J=(<SEGMENTS PER RECURD>? 
 
 <MOt PS FART>)/<> 
 <SEGMJNtS PfR RECURP>: »=<*N> 
 <MOT!ON PART>l|«^OVF ON(<SOuRCE>) 
 
 MOVf PFFcr<P6*00 DISK FILE NAME>/*<M> 1 > 
 <SOURCE>» !»LIS T f<B6500 DISK FILE NAME>/#<M>J SEPARATOR ft 
 <B6500 FTlF CArD>: IbF TLF. <*I>*<FUE IDENT1FIER> 
 <B6b00 DT$K FI,t nMK>ii«i IsT<*I> SEPARATOR/ 
 <UMT FIL£>Ms<Tn BF SPFCJFIFD> 
 <FlLF IUFsil If1ER>I l«<M<S5nn DISK FILE NAmE><OPT IPKS> 
 
 /<IMMFC1ATF FILF>/<UNIT FILE>/*<*I> 
 <OPTTONS> t 1 «<Tp PF. SFFCIFIED> 
 
 <IHMfDIAT[; F I L P > t 1 »F I LF<*I >*T MM^D! ATE SDATA* *# F^HDATA 
 <ACCOUNTTViG CApp>:i*<TO PF SPFCIFIED* 
 
UNCLASSIFIED 
 
 Security Classification 
 
 DOCUMENT C( MTROL DATA - R ft D 
 
 (Security clmmmHIcmllon ol llllm, body of abmttmcl mnd Inditing mrmolmUtm mumi It* mnlmrmd whmn tnm ormrmll report It clammltlmd 
 
 ORIGINATING ACTIVITY (Corpormlm mu tr, or, 
 
 Department of Computer Science 
 1 University of Illinois at Urbana-Champaign 
 Urbana, Illinois 6l801 
 
 |a». REPORT SECURITY CLiillFICiTIOf 
 
 UNCLASSIFIED 
 
 2b. GROUP 
 
 REPORT TITLE 
 
 ICL: A CONTROL LANGUAGE FOR ILLIAC IV 
 
 DESCRIPTIVE NOTE* ( Typ* of rmport mnd hcfutln datum) 
 
 search Report 
 
 AUTMORISI (Fltmt Mm, mlddlm inlilml. Imtt nmmm) 
 
 Lse Christine Pavis 
 
 REPORT DATE 
 
 -ber 13, I969 
 
 7«. TOTAL NO. Or PACES 
 
 3L 
 
 7b. NO. OF REP* 
 
 m. CONTRACT OR GRANT NO. 
 
 46^26-15 -305 
 
 b. PROJECT NO. 
 
 US AF 30(602)laW+ 
 
 •*. ORIGINATOR'S REPORT NUMBERIS) 
 
 DCS Report No. 356 
 
 •b. OTHER REPORT NOISI (Any other nianbarm thmt mmy be mmmlgnmd 
 thtm rmperf) 
 
 0. DISTRIBUTION STATEMENT 
 
 Qualified requesters may obtain copies from DCS. 
 
 I. SUPPLEMENTARY NOTES 
 
 N 3HE 
 
 18. SPONSORING MILITARY ACTIVITY 
 
 Rome Air Development Center 
 Griffiss Air Force Base 
 Rome, New York 13M+0 
 
 J ABSTRACT 
 
 This paper describes ICL, Illiac Control Language and the job parser 
 which interprets the ICL. ICL is a free format, ALGOL-like language which 
 allows the user to specify tasks to be processed in serial or parallel and 
 provides for the conditional execution of tasks dependent upon the results of 
 previously processed tasks. The job parser builds a tree which represents the 
 ordering of tasks and dossiers, which contains in tabular form all information 
 about a task and its associated files necessary to process the task. 
 
 >D /2-..1473 
 
 TTWPT.AKSTFTEn 
 Security Classification 
 
UNCLASSIFIED 
 
 Security Classification 
 
 KEY WORDS 
 
 ROLE WT 
 
 ROL E WT 
 
 Illiac Control Language 
 Job parser 
 
 UNCLASSIFIED 
 
 Security Classification