E9RH 
 
 HHI 
 
 ■ 
 
 rir! 
 
 
LIBRARY OF THE 
 
 UNIVERSITY OF ILLINOIS 
 
 AT URBANA-CHAMPAIGN 
 
 ■no.577-'58Z 
 
 ccp.2 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/onlinefilingolfp582lern 
 
\0, 5£2Report No. UIUCDCS-R-73-582 
 
 0N-LINE FILING (0LF) 
 A PR0GRAM PACKAGE F0R STUDENT REC0RDS 
 
 by 
 
 Edward Mark Lerner 
 
 October 1973 
 
Report No. UIUCDCS-R-73-582 
 
 0N-LINE FILING (0LF) * 
 A PR0GRAM PACKAGE F0R STUDENT REC0RDS 
 
 by 
 
 Edward Mark Lerner 
 
 October 1973 
 
 Department of Computer Science 
 University of Illinois at Urbana-Champaign 
 Urbana, Illinois 61801 
 
 * 
 
 This work was supported in part by the Department of Computer Science and 
 submitted in partial fulfillment of the requirements for the degree of 
 Master of Science in Computer Science, October 1973. 
 
m 
 
 ACKNOWLEDGMENT 
 
 The author would like to take this opportunity to thank the many 
 people who contributed to the success of this project: his advisor, Dr. H. G, 
 Friedman, Jr., for his guidance; the systems programmers of the Computing 
 Services Office for their assistance and cooperation; Mrs. Vivian Alsip for 
 typing this report. 
 
 The author especially wishes to thank his wife for her patience and 
 encouragement, without which this project might not have been completed. 
 
IV 
 
 TABLE OF CONTENTS 
 
 Page 
 
 1. INTRODUCTION 1 
 
 2. SYSTEM CONSIDERATIONS 5 
 
 3. SEARCH STRATEGY & FILE STRUCTURE 9 
 
 3.1 Basic Search Methods 9 
 
 3.2 The 0LF Tree 9 
 
 3.3 File Names 15 
 
 3.3.1 Student Files 15 
 
 3.3.2 Directory Files 16 
 
 3.3.3 Other Files 17 
 
 3.4 Search Strategies 17 
 
 4. PROCESSORS 22 
 
 4.1 The Processor Interface 22 
 
 4.2 Sample Processors 25 
 
 4.2.1 CREATE FILE (CRFILE) 25 
 
 4.2.2 DELETE FILE (DLFILE) 26 
 
 4.2.3 GPA CALCULATOR (CALC) ..... 27 
 
 4.2.4 A SAMPLE STATISTICS PROCESSOR (USERA) 27 
 
 5. SAFETY & SECURITY 29 
 
 6. UTILITIES PROGRAMS. 32 
 
 7. CONCLUSION 33 
 
 APPENDIX 
 
 A. COMPUTING SERVICES OFFICE DOCUMENTS RELEVANT TO 0LF. . 34 
 
 B. 0LF OPERATIONS MANUAL 39 
 
 B.l Introduction 39 
 
 B.2 Search Commands 39 
 
 B.3 Data Statements 41 
 
 B.4 Errors 42 
 
 B.5 Input Modes 44 
 
 B.6 Use of 0LF 45 
 
 B.7 Present Processors 48 
 
Page 
 
 C. NEW PROCESSORS. 53 
 
 C.l Changes in 0LF 53 
 
 C.2 Scratch Files 54 
 
 C.3 Programming Aids 54 
 
 C.4 Information 54 
 
 D. 0LF PROGRAM LISTINGS 56 
 
 BIBLIOGRAPHY 94 
 
VI 
 
 LIST OF FIGURES 
 
 Page 
 
 1. Graduation Requirements Form—Department of Computer Science 
 (Side 1) 2 
 
 2. Graduation Requirements Form—Department of Computer Science 
 (Side 2) 3 
 
 3. The PL0RTS Tree 6 
 
 4. The 0LF Tree 10 
 
 5. 0LF within the PL0RTS Tree 11 
 
 6. 0LF Directories 13 
 
 7. The Student File 14 
 
 8. Interconnections in the 0LF Tree 18 
 
 9. Tree Pointers 21 
 
 10. Processor Access Rights Table (PART) 23 
 
 11. Search Commands 40 
 
 12. Data Statements 42 
 
 13. 0LF Statement Hierarchy . . 44 
 
 14. Sample CALC Data Statements 51 
 
 15. Sample Use of USERA 52 
 
1. INTRODUCTION 
 
 At present, the various departments of the University of Illinois 
 (UI) manually maintain student records. Courses—scheduled, in progress, 
 and completed—and grades received are typically recorded on a form like the 
 one shown in Figures 1 and 2, used by the Department of Computer Science. 
 Faculty members (advisors) who help plan students' programs use the infor- 
 mation on these forms to arrive at their recommendations for future course- 
 work. 
 
 The advisor's duties are complicated by several considerations. 
 Often he must counsel students in different curricula; occasionally, as in 
 the Department of Computer Science, these curricula reside in different 
 colleges. A student is allowed to meet either current requirements or the 
 requirements which were in effect when he entered his curriculum— whichever 
 are least stringent. The amount of information with which an advisor must 
 be familiar is clearly large. 
 
 To lighten the burden on the advisor, it would be advantageous to 
 automate this information retrieval and data processing system. A prototype 
 on-line filing (0LF) program package has been written to provide the frame- 
 work for such a system. 
 
 Viewed in its simplest form, 0LF is a program which retrieves an 
 existing student record. It is designed to allow secure and easy interaction 
 with subroutines— data processors— requiring different access rights (to both 
 data files and to other processors) and search strategies (all students, 
 students of one department, etc.). Some of the functions necessary for a 
 complete system include file insertion/deletion, program approval (prerequisite 
 checking), and grade point average (GPA) calculation. By incorporating 
 
Name: 
 
 High School : 
 Transfer from: 
 Entered U of I 
 
 Social Sec. No.: 
 Rank: Class: 
 Hours: 
 Entered Curriculum: 
 
 Percentile: 
 G.P.A.: 
 
 Candidate 
 
 for Distinction 
 
 A. MAJOR 
 
 □ 
 
 1 . Mathematics 
 120 
 
 130/131 
 140/141 
 341 (345/349) 
 342 
 
 317 (319) 
 318 
 347 
 348/361 (363) 
 
 2. Computer Science 
 
 121 
 
 201 
 287 
 293/294/301/310 
 
 B. MINOR 
 
 s- 
 <_> 
 
 CO CD 
 
 s- -o 
 
 ZJ as 
 
 o s_ 
 
 re o 
 
 s_ tu 
 
 (_> 4-> 
 CD 
 
 co i — 
 
 S- Q. 
 
 rs E 
 
 o o 
 
 re o 
 
 [31 
 
 ) 
 
 (i: 
 
 
 
 (8) 
 
 
 C. ELECTIVES 
 
 (24 approx) | 
 
 
 
 
 
 
 
 
 
 
 
 D. COLLEGE 
 
 REQUIREMENTS 
 1. Physical Ed. 
 
 2. 
 
 Rhetoric 
 
 3. 
 
 Foreign 
 
 
 Language 
 
 
 101 
 
 
 102 
 
 
 103 
 
 
 104 
 
 4. 
 
 Biological 
 
 
 Science 
 
 5. Social 
 Science 
 
 6. Humanities 
 
 s- 
 
 CO CD 
 
 s- -a 
 
 3 ra 
 O i- 
 
 4) 
 
 CJ3 
 
 
 
 
 
 
 
 
 
 S- CD 
 
 C_> +J 
 CD 
 
 CO i — 
 
 S- Q. 
 
 n E 
 
 o o 
 
 re o 
 
 6) 
 
 
 ne) 
 
 §) 
 
 
 (8) 
 
 
 6) 
 
 
 Graduated: 
 
 Hours 
 
 G.P.A, 
 
 Figure 1. Graduation Requirements Form-- 
 
 Department of Computer Science (Side 1) 
 
MATHEMATICS AND COMPUTER SCIENCE CURRICULUM 
 Notes on Graduation Requirements Form 
 
 Transfers : 
 
 Enter, in the appropriate section, the number of hours credit together 
 with a T for grade for all courses transferred onto the student's record. 
 
 A: The courses marked on the form are requirements, where a / indicates an 
 alternative and courses in parentheses, if taken before entry to the cur- 
 riculum, are alternatives to the immediately preceding course on the left, 
 
 Dl: Four semesters of P.E. required, no credit hours. 
 
 D3: Entrance to the four course sequence in a single foreign language may be 
 made at a point determined by a proficiency examination, and the first 
 course taken may be for credit. 
 
 D4, D5, D6: Refer to LAS Student Handbook, 1969-70, pp. 8-9. 
 
 Advanced Courses : 
 
 The requirement of 30 hours in advanced courses is automatically satisfied 
 by the addition of 1 more 200 or 300 level course. 
 
 Completed Requirements : 
 
 As requirements for each section are completed, check (•) the appropriate 
 "completion" square and enter the number of hours of credit gained in that 
 section. Indications of the minimum credit requirements are shown in 
 parentheses. 
 
 Comments : 
 
 Requirement Dl is no longer in effect. 
 
 Figure 2. Graduation Requirements Form-- 
 
 Department of Computer Science (Side 2) 
 
write-protection, search control, and I/O management within 0LF, it becomes 
 safe to allow users to write processors. 0LF, therefore, makes possible the 
 compilation of many presently unavailable statistics. 
 
 The 0LF system and a GPA calculator, file insertion/deletion proces- 
 sors, and a sample statistics processor designed to use 0LF are discussed 
 below. 
 
2. SYSTEM CONSIDERATIONS 
 
 PL0RTS, the filing, remote job entry, and timesharing facility of 
 the UI uses an IBM 360/75 interfaced to teletype (TTY) and IBM 2741 terminals 
 through a PDP-7. PL0RTS files are maintained on magnetic discs. Interactive 
 jobs are limited to 100K bytes of main memory. If several users try con- 
 currently to use a single file, a copy is loaded into core storage for each. 
 The PL0RTS monitor prevents one user from overwriting a file being read by 
 another user. 
 
 At present, BASIC and F0RTRAN are supported in their CALL/36O-0S 
 implementations (with a few minor changes to follow the conventions of 
 PL0RTS). 0LF has been programmed in F0RTRAN because of the inferior character- 
 manipulation features of CALL/36O-0S BASIC. 
 
 Access to PL0RTS requires knowledge of two items: a valid PL0RTS 
 problem specification number (PS#) used for accounting purposes and a name 
 recognized as that of a user under that PS#. PL0RTS files form a tree as shown 
 in Figure 3. A complete name has the form 
 
 PS# . username . level 1 name. level 2name levellastname 
 
 where each level name is a character string of eight or fewer EBCDIC charac- 
 ters (exclusive of blank, comma, or period). File names created within a pro- 
 gram can contain "characters" which are not available on a terminal; any such 
 name can then be accessed only by a program. In order that a file be acces- 
 sible by program, the part of its name corresponding to the underlined por- 
 tion of the general form above cannot exceed eight characters. The more 
 qualified (the more levels to) a file's name, the greater the access time for 
 the file. 
 
 A PL0RTS user is given full access (read/write/execute privileges) 
 
C3 
 
 C_) 
 
 CO 
 
 
 ZD 
 
 CD 
 
 Q. 
 
 <U 
 
 • 
 
 s. 
 
 <D CT> 
 
 h- 
 
 r— cr> 
 
 
 •i- cr> 
 
 00 
 
 U. (Ti 
 
 f- 
 
 
 cc 
 
 
 is 
 
 
 _j 
 
 
 Q. 
 
 
 CU 
 
 LU 
 
 a; Ln 
 
 i— KO 
 
 •i- «=j- 
 u_ CO 
 
 s- 
 
 CD 
 
only to the branch of the tree named by the PS# and name with which he logged 
 in. (To access a file farther down on that branch, he need specify only the 
 remaining part of its name.) He can read (copy) another user's file if he 
 knows the complete file name. This is the basic PL0RTS security arrangement. 
 
 Execution of TSBATCH, a catalogued procedure in the batch proces- 
 sing system, makes card image input appear to the PL0RTS monitor to be a 
 PL0RTS terminal. This has three advantages. First, large amounts of input 
 can be fed to an "interactive" program through the card reader (any mis- 
 punched information—hopefully a small subset of the original data—can then 
 be resubmitted in true interactive mode). Second, a PL0RTS program can be 
 run as one job step of a longer batch job. Third, PL0RTS can be used even 
 when the PDP-7 is not available. 
 
 Each PL0RTS file is composed of blocks. A block contains, besides 
 information for the monitor, eight or more card images (varying because 
 trailing blanks are suppressed). Files can be created either by the terminal 
 command 0PEN, or, during program execution, by invoking for output the sub- 
 routine 0PEN. One block is allocated to a file when it is created; additional 
 blocks are automatically added as needed. 
 
 Unfortunately, files can be deallocated only by the terminal command 
 destroy (DEST). However, a program can lose all information in a file without 
 deallocating its disc space by opening the file for output. (If the file has 
 multiple blocks, this maneuver will reduce to one the number of blocks allo- 
 cated.) An executing job can, however, write onto disc the card image of a 
 DEST command for each obsolete file. A TSBATCH job can then use these records 
 to perform the file deallocation. 
 
 As mentioned, PL0RTS files are kept on magnetic discs. Programs are 
 swapped between main memory and disc during execution. Data files appear 
 
8 
 
 sequential to executing programs. In this environment, program structure is 
 optimized with respect to response time by: 
 
 1) minimizing the number of file accesses; 
 
 2) manipulating files in core storage whenever possible 
 (so that access of file items is direct); 
 
 3) compacting the program to minimize the time spent 
 waiting for main memory to become available for reloading. 
 
 The methods used in 0LF to implement these goals are discussed below. 
 
3. SEARCH STRATEGY & FILE STRUCTURE 
 
 3.1 Basic Search Methods 
 
 A program can locate, or determine the absence of, a student's file 
 by generating the appropriate file name and invoking for input the 0PEN sub- 
 routine. If, upon return, the error flag is set, the file is absent; other- 
 wise the file has been successfully accessed. 
 
 The single search strategy possible using this method requires 
 naming each file individually. An attempt to compile university-wide statis- 
 tics would require approximately 30,000 such specifications. A prepared list 
 of students would make group access feasible, but preparation of a student list 
 for each group (e.g., each college and curriculum) likely to be accessed 
 collectively would entail an inordinate amount of effort and replication. 
 
 A tree structure (e.g., Figure 3) allows use of a family of search 
 strategies. Within a tree, a member is uniquely defined by the concatenation 
 of the name of the leaf with the names of all nodes leading to the leaf. More 
 pertinent to this discussion, a set of members can often be selected by naming 
 one node common to the set--the root of a subtree. A tree designed with 
 thought towards probable access classes will most often be searched by tracing 
 only selected subtrees. 
 
 3.2 The 0LF Tree 
 
 0LF student files are accessed through the tree shown in Figure 4. 
 A node is implemented as a directory (list) of its immediate branches. Both 
 student files and directory files of all levels are found in the top level of 
 the PL0RTS tree, as shown in Figure 5. Each 0LF file exists independently on 
 disc. 
 
 Each directory file consists of an INTEGER*4 length field and a 
 
10 
 
 <L> 
 
 s~ 
 
 
 
 
 
 ISt 
 
 
 to 
 
 
 
 cu 
 
 
 c 
 
 4- 
 
 
 -C 
 
 
 o 
 
 O 
 
 
 1— 
 
 
 •r" 
 
 
 
 
 
 -4-> 
 
 to 
 
 
 
 
 C 
 
 E 
 
 
 • 
 
 
 <3J 
 
 rrj 
 
 
 •vt- 
 
 
 > 
 
 TJ 
 
 
 
 
 C 
 
 «=c 
 
 
 <D 
 
 
 o 
 
 
 
 s- 
 
 
 o 
 
 S- 
 
 o 
 
 
 13 
 
 CD 
 
 
 <u 
 
 </) 
 
 
 •r - 
 
 
 E 
 
 •1— 
 
 
 U_ 
 
 
 A3 
 
 > 
 
 
 
 
 c 
 
 -o 
 
 (0 
 
 
 
 
 <u 
 
 
 
 
 
 J^ 
 
 to 
 
 
 
 
 •1— 
 
 rC 
 
 
 
 
 4- 
 
 -C 
 
 
 
 
 U_ 
 
 ** 
 
 
 
 
 _l 
 
 CO 
 
 
 
 *$■ 
 
 ts. 
 
 o 
 
 
 
 en 
 
 
 CO 
 
 
 
 o 
 
 -M 
 
 1 
 
 
 
 CO 
 
 1 
 
 O 
 <L> 
 
 o 
 
 <3- 
 
 
 
 o 
 
 ^~ 
 
 1 
 
 
 
 «=d- 
 
 4- 
 0) 
 
 to 
 
 
 
 r— 
 
 J- 
 
 CO 
 
 
 
 tO 
 
 
 
 
 
 CO 
 
 O 
 
 CO 
 
 
 
 
 c 
 
 in 
 
 CO 
 
 
 
 to 
 
 JO. 
 
 o 
 
 
 
 a> 
 
 -4-> CM 
 
 
 
 o 
 
 •r— 
 
 r— 
 
 
 
 -o 
 
 s U 
 
 
 
 
 
 r-~ 
 
 
 
 a> 
 
 +J 
 
 
 
 
 4- 
 
 c 
 
 E 
 
 
 
 23 
 
 cu 
 
 ZJ 
 
 
 
 E7> 
 
 -a 
 
 i — 
 
 
 
 •r— 
 
 3 
 
 =3 
 
 
 <7> 
 
 4- 
 
 +-> 
 
 U 
 
 
 to 
 
 
 to 
 
 ■r- 
 
 
 C\J 
 
 t/i 
 
 
 s- 
 
 
 i— 
 
 • r— 
 
 a> 
 
 $- 
 
 
 1 
 
 -E 
 
 -C 
 
 13 
 
 
 m 
 
 1— 
 
 l— 
 
 O 
 
 
 CO 
 
 
 
 
 
 CvJ 
 
11 
 
 
 l— 
 cm 
 Sl 
 
 _l 
 
 D_ 
 <L> 
 
 +J 
 
 c 
 .c 
 
 4-> 
 •r- 
 
 Ll_ 
 
 _J 
 
 LO 
 CD 
 
 s_ 
 =J 
 
. 12 
 
 REAL*8 vector. The meaning of each component depends upon the directory level 
 Figure 6 further illustrates the directory structure. 
 
 The single level -one directory lists all curricula whose students 
 have 0LF files. Each element of the vector holds the name of a level -two 
 directory file, formed from a numeric curriculum code. The file names are 
 kept in ascending order. The value of the length field equals the number of 
 curricula listed. 
 
 Each level-two directory stores the complete list of undergraduate 
 advisors for the curriculum after which the file is named. Elements in the 
 first half of the vector contain the names, truncated to eight letters, of 
 the advisors in alphabetic order. Each advisor's name has as an associated 
 entry in the second half of the file, the name (obtained from the advisor's 
 social security number) of a level -three directory file. These associated 
 elements have as a group the same relative positions in the bottom half of 
 the vector as do the alphabetized names in the top half. The length field has 
 as its value the number of advisor names (which equals the number of level- 
 three file names) listed. 
 
 Each level-three directory holds the list of all students (advisees) 
 of the advisor after whom the file is named. Each vector element stores the 
 name of one student's file, formed from his social security number. The file 
 names are kept in ascending order. The value of the length field indicates 
 the total number of advisees of an advisor, even if the advisor counsels for 
 several curricula (see Search Strategies, below). 
 
 The major components of the student file are the header (identifi- 
 cation), the general information block (GPA, hours towards degree, etc.), the 
 requirements check-off list, and the course history block. A more detailed 
 description accompanies Figure 7. 
 
(a) 
 
 199 
 
 $$061102 
 
 $$124359 
 
 $$220014 
 
 $$220016 
 
 20 
 21 
 22 
 
 $$220099 
 
 $$220101 
 
 $$221001 
 
 40 
 
 $$370124 
 
 n/^\An 
 
 199 
 
 200 
 
 $$999999 
 
 LEVEL 1 
 
 13 
 
 J0NES 
 
 SMITH 
 
 WILLIAMS 
 
 506A917C 
 
 41724163 
 
 63A2F691 
 
 LEVEL 2 
 
 (b) 
 
 INTEGER *4 LENGTH (3) 
 
 0124659A 
 
 2246193B 
 
 22AF3129 
 
 24CC1234 
 
 199 
 
 3 
 
 4 
 
 REAL*8 DIRECT(260) 
 
 $$061102 
 
 $$124359 
 
 $$220014 
 
 $$220016 
 
 
 199 
 
 200 
 
 201 
 PR0T0TYPE DESIGN 
 CAPACITIES SH0WN 202 
 
 221 
 222 
 223 
 
 LEVEL 3 
 
 $$999999 
 
 J0NES 
 
 SMITH 
 
 >■ LEVEL 1 
 
 
 506A917C 
 
 41724163 
 
 63A2F691 
 
 (a). 0LF Directories as Stored on Disc 
 
 The conventions for file names are explained in 
 the section File Names. 
 
 240 
 241 
 242 
 243 
 
 260 
 
 0124659A 
 
 2246193B 
 
 22AF3129 
 
 > LEVEL 2 
 
 }■ LEVEL 3 
 
 (b). 0LF Directories as 
 
 Stored in Main Memory 
 
 Figure 6. 0LF Directories 
 
14 
 
 I I T T - T P 1 1 
 
 
 
 —I 1 1 1 1 
 
 r T l 1 l 1 1 — — T — 1 r 1 
 
 — I 1 1 1— 
 
 r — 
 
 
 i i 1 i i 
 
 ■ 
 
 
 ■ ill 
 
 1 1 1 1 1 1 1 ■ 1 1 
 
 1 I 1 I 
 
 imarj muni 
 
 ToMrtf 
 OaarM 
 
 Hours 
 
 Hours 200- 
 Ltni ind 
 
 Above 
 
 Moon 
 
 Fall 
 
 Hours 
 Otltlfd* 
 
 Coll to* 
 
 GPA 
 
 GrA 
 tn 
 Rajer 
 
 Hours * 
 Grate 
 
 Hours 
 III 
 
 Hsjor 
 
 Houn • 
 Crates tn 
 Major 
 
 CPA for 
 
 Transfer 
 Crarfft 
 
 
 
 
 
 
 TTTTTTTTTTTTTTT 
 
 ? = £■ s if s-s |g ;£ s fcjsg s; g- j; g; g; s; 
 
 r?ii 
 
 :s st ^t |s 
 is 1? °r "? 
 "§ s l 5 i 
 
 f Si il I SI II 
 
 i Ss s: ; ; s 
 
 IHTEGEOV G1B2(M» 
 
 Year Sanur 
 Oms yyyy 1 
 
 INTEGER*? CHEUJV02) "Nu I remen t* check-off list 
 
 !•••£ 
 
 OparuMnt Block 
 
 t t 1 1 T t t t t t 
 
 !: f~ •: £| i 
 
 f ^ f i\ 8 s i 
 
 s I i 1 
 
 heai*8 ocoor(ii) 
 
 }•••£ 
 
 _i i i i_ 
 
 fpectt) "vie. To Indtcata anything umiiual 
 •i»ui a fivn-fq., an 
 fntrodMCtory court* not 
 comldaPMl as houn (acluaaal 
 ".thin ow's ajor. 
 
 Oaaartaawt Codas Major (?) 
 Maar |li 
 Carnal Caucatlaa (0) 
 
 Coursa 
 History 
 Hock 
 
 51 
 
 a crvdlt 
 Is alvaa ta autttplas 
 of ,S aaars. tha> faetor 
 of Z alia* wta of 
 Intaajar xarlaklas. 
 
 Figure 7. The Student File 
 
15 
 
 The design of the student file is complicated by the goal of allowing 
 for user-supplied processors with unknown data requirements. A small amount of 
 unassigned space is included in the file to be defined as necessary. It is 
 expected that the information which is currently found in the file will be 
 adequate for most purposes. 
 
 3.3 File Names 
 
 A complete advisory and record keeping system requires student data 
 files, directories, course description tables, and requirements tables for 
 curricula and colleges. A consistent naming convention is needed to avoid 
 duplication of file names. A convenient feature (but see section on SAFETY 
 & SECURITY, below) is direct accessibility from the terminal. 
 
 3.3.1 Student Files 
 
 UI identifies its students by social security number (SSN). The 
 
 eight character limit for program-accessible PL0RTS file names precludes 
 
 direct use of nine digit SSNs as identifiers. The following algorithm is 
 
 used: 
 
 The SSN, interpreted as a nine digit decimal number, 
 is converted to an eight digit hexadecimal number. 
 Each hexadecimal digit is stored in character repre- 
 sentation in a separate byte of a REAL*8 variable. 
 This character string consists entirely of characters 
 available on the terminal and contains no characters 
 that are invalid (or undesirable, like period) in 
 PL0RTS file names. 
 
 Student files are on level 4 of the 0LF tree. 
 
- 16 
 
 3.3.2 Directory Files 
 
 The single level-one directory file is the master curriculum list 
 named CURRIC. 
 
 The name of each level-two file is derived from a six-digit college/ 
 curriculum code. The two leftmost digits indicate the college and the re- 
 maining four digits identify the curriculum within the college; curriculum 
 codes shorter than four digits must be extended to four digits by adding non- 
 significant zeroes. A basis for all of a curriculum's file names is formed by 
 storing these digits in character form left-justified in a REAL*8 variable. 
 (No decimal to hexadecimal conversion is required since the code is only six 
 digits long.) The directory name for the curriculum is generated by right- 
 justifying these six digits in another REAL*8 variable and inserting $$ into 
 the two vacant high-order bytes. Other files for this curriculum, if needed, 
 can be named by using other (non-alphanumeric) characters in place of $$. A 
 level-two file named $$220014 contains the advisor list of curriculum 14 of 
 college 22. 
 
 The name of each level -three file is generated from an advisor's SSN. 
 It is convenient (see PROCESSORS) that level-three file names be distinguish- 
 able from level -four file names, also generated from SSNs. 
 
 Nine digit SSNs are bounded by 
 
 < SSN < 10 9 -1 
 while the range for a positive FORTRAN full word integer K is 
 
 < K < 2*10 9 . 
 
 Q 
 
 Adding 10 to an advisor's SSN yields a ten digit "SSN" which is convertible to 
 a file name by the algorithm used for level -four file names, but which is 
 easily identified as being a level -three file name. 
 
17 
 
 3.3.3 Other Files 
 
 A complete system requires various curriculum, department, and 
 college tables. A basis for curriculum file names is discussed above. Differ- 
 erent curriculum files resemble level -two directory file names with $$ replaced 
 by other characters. 
 
 College files can be similarly formed: **22 might be the name of 
 the requirements file of college 22. 
 
 Department files can be formed from the standard UI department name 
 abbreviations. Since these consist of five or fewer letters, names for sev- 
 eral departmental files can be generated by addition of special characters. 
 
 A few files like CURRIC (all are listed in the appendices) have pre- 
 determined alphabetic names. 
 
 3.4 Search Strategies 
 
 Every record search requires a set of search limits. (The implicit 
 limit in searching an unstructured file collection is the collection size, 
 although the search, if successful, may not reach this limit.) The natural 
 search limit in a tree-organized record set is the last common node--the root 
 of the smallest subtree which includes all members of the search class. 
 
 The four natural classes in the 0LF tree are: all students, all 
 students within a single curriculum, all students of a common advisor, and an 
 individual student. They correspond, respectively, to last common nodes at 
 levels one, two, three, and four. 0LF uses all four access classes. 
 
 A small amount of interconnection (not shown on previous figures) 
 exists between directory branches. An advisor's node is attached to the nodes 
 of all curricula in which he advises. Some advisor files, and hence some 
 student files, might therefore (see Figure 8) be accessible by several paths. 
 The curriculum entry in the general information block of a student's file is 
 
18 
 
 _l 
 UJ 
 
 > 
 
 UJ 
 
 > 
 
 VD 
 
 O 
 
 O 
 
 O l 
 
 •=3- o 
 o o 
 
 O I 
 
 o o 
 o o 
 o o 
 
 o-— > 
 
 (0 
 
 
 3 
 
 
 o 
 
 
 ■Jp" 
 
 . . 
 
 i- 
 
 lO 
 
 J- 
 
 <D 
 
 3 
 
 £ 
 
 o 
 
 m 
 
 
 c 
 
 cu 
 
 
 CD 
 
 <D 
 
 s- 
 
 .C 
 
 .c 
 
 +-> 
 
 +J 
 
 >> 
 
 s- 
 
 J3 
 
 o 
 
 
 4- 
 
 ■o 
 
 
 01 
 
 S- 
 
 W o o o 
 
 o 
 
 to "5j- «* «3" 
 
 to 
 
 <u o o o 
 
 •i - 
 
 o o o o 
 
 > 
 
 U O O O "O 
 
 ■o o o o 
 
 <0 
 
 o o o 
 
 
 CD O O O 
 
 c 
 
 _Q • • • 
 
 (0 
 
 c> o~i oi 
 
 
 E "vt" «vj" «3" 
 
 to 
 
 rt5 CM CM CM 
 
 »r- 
 
 O i— i— r— 
 
 
 uuu 
 
 </) 
 
 -t-> < <C ■=£ 
 
 CU 
 
 c o o o 
 
 J- 
 
 <L) ID LT> LT> 
 
 o 
 
 -o • • • 
 
 •-o 
 
 3 "vt" <£> 00 
 
 
 -t-> l— I— r— 
 
 cu 
 
 </) O O O 
 
 to 
 
 o o o 
 
 •zj 
 
 </> CM CM CM 
 
 (0 
 
 •r- CM CM CM 
 
 u 
 
 -C -to^-bO-"*/* 
 
 cu 
 
 I— -b^-faO^-b^ -O 
 
19 
 
 compared to the current level -two search node to avoid extraneous or redundant 
 processing. Thus, while 0LF files are not organized in a true tree (as de- 
 fined above), a simple procedure renders the difference inconsequential. 
 
 Each search need not be specified from the level -one node. Pre- 
 viously specified nodes are defaulted subject to the conventions that: 
 
 1) in any access mode, nodes beneath the level of access 
 become undefined at the completion of the search; 
 
 2) all nodes past a changed node must be redefined; 
 
 3) whenever a new processor is selected, a new search 
 strategy must be defined starting from the level-one 
 node. 
 
 A program can access any file directly (without using the 0LF tree), 
 if its name is known, by invoking the subroutine OPEN. This is not the in- 
 tended 0LF access mode, and is used in only one instance (see PROCESSORS). 
 
 The 0LF tree helps realize the three response-optimizing goals set 
 in SYSTEM CONSIDERATIONS: minimal file accessing, editable-in-core files, 
 and a compact load module. 
 
 Batch-access of student files is implemented through systematic 
 progression along the tree. One or more (depending on the access level) 
 directories (where a directory is the internal representation of a node) is 
 referenced repeatedly. In individual access mode, it is not unlikely that 
 files of a common advisor will be processed sequentially. One directory of 
 each level is therefore kept in main memory, and a new directory is loaded only 
 when necessary. Since there is a single level-one file (CURRIC) only levels- 
 two and -three directories are ever replaced. 
 
 Like the directory files, the student file has a compact organiza- 
 tion. In the prototype design, three directories occupy 2092 bytes while a 
 
20 
 
 student file fills 1648 bytes. These requirements, less than 4K bytes com- 
 bined, are an acceptable fraction of the 100K allowed to PL0RTS programs. 
 Keeping these files in main memory allows direct access of file items, with- 
 out jeopardizing the compactness of the load module. 
 
 Figure 9 shows the internal representation of the pointer system 
 used in tree access. 
 
1 st DIRECT0RY 
 (CURRICULUM -< 
 LIST) 
 
 $$170369 
 
 $$220014 
 
 $$361416 
 
 2 nd DIRECT0RY 
 (ADVISOR i 
 LIST) 
 
 
 J0NES 
 
 WILLIAMS 
 
 60000000 
 
 5010AC39 
 
 3 rd DIRECT0RY 
 
 (ADVISEE 
 
 LIST) 
 
 146AF930 
 
 234C1692 
 
 25CD7083 
 
 32196681 
 
 DIRECT 
 
 3 2 4 
 
 21 
 
 $$220014 
 
 5010AC39 
 
 146AF930 
 
 WILLIAMS 
 
 MASTER 
 
 146AF930 
 
 LENGTH 
 
 # 0F ADVISEES IN DIRECT0RY 
 
 # J8F ADVIS0RS IN DIRECT0RY 
 
 # 0F CURRICULA IN DIRECT0RY 
 
 0UT 
 
 CURRENT STUDENT FILE 
 
 Figure 9. Tree Pointers 
 
22 
 
 4. PROCESSORS 
 
 0LF does not itself manipulate any of the information within indi- 
 vidual student files: this is the job of data processing subroutines, here- 
 after called processors, which operate within 0LF. Each new processor can 
 use previously-written processors as subprocessors. A processor that adds 
 transfer students to 0LF can be constructed from a file creation processor, 
 a program recording processor, and a credit assignment processor (which in 
 turn would invoke a GPA calculating processor). 
 
 4.1 The Processor Interface 
 
 At the interface between 0LF and the processors are the terminal 
 input buffer and the processor access rights table (PART), shown in Figure 10. 
 The regulated rights are student file I/O, directory file output, and direct 
 access of student files. Access of . one processor by another is restricted in 
 only two ways: the subprocessor's file I/O rights must be a subset of the 
 rights of its invoking processor, and no processor can be invoked, directly or 
 indirectly, by itself. The latter restriction is inherent to FORTRAN; the 
 reasons for the former restriction should become apparent in light of the dis- 
 cussion below. 
 
 A necessary condition to guarantee that all instructions intended 
 for 0LF are properly received is the denial of terminal input to the proces- 
 sors. The terminal is, unfortunately, unconditionally available to all PL0RTS 
 programs. After reading enough information to define a search strategy, 0LF 
 rewrites on disc all terminal input until a blank line is submitted. (If in- 
 put is via the card reader, the first card image not in data format causes 
 buffering to terminate. This card image is used--after return from the active 
 processor—as the next command to 0LF.) The processors are supposed to read 
 
r.i 
 
 PR0CESS0R 
 NAME 
 
 STUDENT FILE 
 INPUT 
 LIMIT 
 
 STUDENT FILE 
 
 0UTPUT 
 AUTH0RIZATI0N 
 
 DIRECT0RY- 
 
 EDITING 
 
 AUTH0RIZATI0N 
 
 DIRECT 
 
 ACCESS 
 
 AUTH0Pi.'AT|0N 
 
 EXTRA 
 
 ACCESS 
 
 AUTH0HIZATl{!r 
 
 CREATE 
 
 FILE 
 
 
 
 DELETE 
 FILE 
 
 
 
 
 
 1 
 
 
 
 
 
 GPA 
 CALCULAT0R 
 
 
 
 
 
 
 
 
 
 USERA 
 
 
 
 
 
 
 
 The processors named above are described in the section Sample Processors 
 
 Student File Input Limit: ".cad header, general information block 
 
 1: Read entire student file 
 Student File Output 
 Authorization: 
 
 Directory-Editing 
 Authorization: 
 
 Direct Access 
 Authorization: 
 
 Extra Access 
 Authorization: 
 
 0: Not allowed to rewrite file 
 
 1: Allowed to rewrite file 
 
 0: Not allowed to edit directory 
 
 1: Allowed to edit directory 
 
 0: Tree access only 
 
 1: Direct (non-tree) access allowed 
 
 0: Invoke processor once per student file 
 
 1: Invoke processor once per student file 
 plus once at completion of batch access 
 
 Figure 10. Processor Access Rights Table (PART) 
 
. 24 
 
 from the buffer, but this policy cannot be enforced. A multi-step processor 
 can read an input stream repeatedly by rewinding the sequential disc data 
 set. If necessary, the input stream can be edited for the use of sub- 
 processors. 
 
 A file is edited by writing an altered version of the file over the 
 original contents. Write protection for 0LF files is implemented through 
 control of file output. File access is restricted to 0LF since file names are 
 kept secret from the processors. 0LF will not copy a file back onto disc 
 unless the initiating processor has student file output authority in PART. 
 All processors return completion codes; 0LF does not rewrite the current stu- 
 dent file--even if the active processor has write authority—if the last com- 
 pletion code indicates a processing error. 
 
 Certain processors may use only information found near the beginning 
 of student records. The student file input parameter in PART controls the 
 amount of data read from each. record. (The time saved by a partial read-in is 
 less than might be expected--the buffer assigned by the PL0RTS monitor to the 
 disc controller is larger than a complete student file.) Rewriting of a par- 
 tially loaded file causes erasure of the unread portion of the file; there- 
 fore all editing processors (except DELETE FILE) must read entire files. 
 
 0LF access requires reading many directory files. A copy directory 
 parameter in PART tells 0LF whether or not the current level -three directory 
 must be rewritten onto disc before a new one is loaded (equivalent to whether 
 or not the active processor edits the directories). The file insertion/ 
 deletion processors, and any multi-step processors which invoke them, must 
 have copy directory enabled. 
 
 Statistics-gathering processors may need to be invoked once after 
 the completion of a batch access (e.g., to calculate standard deviations after 
 
25 
 
 determining means). The extra access parameter in PART tells 0LF whether or 
 not the current processor is allowed an extra access. 
 
 It should now be clear that the file I/O rights of a subprocessor 
 must be a subset of the rights of its invoker. A subprocessor cannot success- 
 fully edit a file if the initiating processor does not have student file out- 
 put authorization. A subprocessor which requires data from complete student 
 records cannot function correctly if the processor invoking it requests a 
 partial read-in (that is, if the initial processor of a multi-step processor 
 has a limited student file input parameter in PART). A statistics sub- 
 processor may not be able to complete its calculations if the processor using 
 it is not executed once after each batch access. 
 
 It is expected that direct file access—file locating without use 
 of the 0LF tree—will be used only by CREATE FILE (a sample processor discus- 
 sed below) or processors invoking CREATE FILE. For purposes of generality, 
 the direct access capability is included within 0LF and enabled by a direct 
 access parameter in PART. 
 
 4.2 Sample Processors 
 
 The sample processors discussed below are intended to demonstrate 
 the ease with which new capabilities can be added to 0LF, and to clarify the 
 interface conventions. This section is not an exhaustive list of useful 
 processors. 
 
 4.2.1 CREATE FILE (CRFILE) 
 File creation entails: 
 
 1) determining that the proposed file does not yet exist; 
 
 2) checking that the directory of the proposed advisor has 
 room for another student; 
 
. 26 
 
 3) creating the file--with a filled header and initialized 
 general information block, requirements check-off list, 
 and course history block; 
 
 4) adding the name of the new file to the disc file of new 
 files (see SAFETY & SECURITY, below); 
 
 5) adding the name of the proposed file to the proper level- 
 three directory. 
 
 CRFILE is the processor which requires direct file access. The 
 mistyping of SSNs is a predictable error. Standard 0LF (tree) access de- 
 termines the presence or absence of a student file only from a specific level- 
 three directory. The SSN of a student known to 0LF might be the same as the 
 number mistakenly entered as the SSN of the student for whom the new file is 
 to be created. Unless old and new students both have the same advisor, tree 
 access cannot discover that a file named after the proposed "new" SSN already 
 exists. Opening the old file to create the new student's file destroys the 
 original record. 
 
 The SSN of a student is sufficient information to enable 0LF to 
 generate his file's proper name. If tree access fails to find a file with a 
 proposed new name, the 0PEN subroutine is invoked for input. Upon return, if 
 the error flag is set, the proposed file name is unknown to 0LF (and PL0RTS), 
 and the proposed file can be created. If the file already exists, the header 
 is read, determining to whom 0LF believes that SSN belongs. (Both forms of 
 access are performed by 0LF, not CRFILE.) The distinguishability of student 
 and advisor file names (see File Names, above) prevents attempting to read a 
 student header from an advisor file, which would cause a data format error. 
 
 4.2.2 DELETE FILE (DLFILE) 
 File deletion entails: 
 1) determining that the to-be-deleted file exists; 
 
27 
 
 2) removing the name of the to-be-deleted file from the 
 proper level -three directory; 
 
 3) entering the name of the file to be deleted into the 
 deallocated files list; 
 
 4) commenting when an advisor loses his last advisee. 
 
 4.2.3 GPA CALCULATOR (CALC) 
 
 CALC finds the GPA resulting from practically any subset of courses 
 taken by any student. The selectable subsets are the intersections of any of 
 the following sets: 
 
 1) all courses within the major and minor subjects; 
 
 2) all courses within the major subject only; 
 
 3) all courses within the minor subject only; 
 
 4) all courses within a named department; 
 
 5) all courses taken during and after a specified semester; 
 
 6) all courses taken during or after a given status (e.g., 
 freshman, sophomore, etc.) is reached; 
 
 7) all courses within the last given number of hours; 
 
 8) all courses including and above a specific level (100, 
 200, etc.); 
 
 9) all courses not yet included in the cumulative GPA (grades 
 just recorded). 
 
 CALC returns, in addition to a GPA, the number and total hours of 
 the courses used in the calculation. 
 
 4.2.4 A SAMPLE STATISTICS PROCESSOR (USERA) 
 
 Most user-supplied processors are expected to be statistics-gatherers 
 The sample processor described below is intended to be indicative of the 
 
. 28 
 
 potentialities of 0LF; it also, by invoking CALC, illustrates the rules 
 governing multi-step processors (see their respective PART entries, in 
 Figure 10) . 
 
 The XX department wants to prove or disprove the belief of some of 
 its advisors that the course YYY108 should be a prerequisite for all 200- 
 (and above) level XX courses. The advisors who feel that YYY108 is a useful 
 course have consistently recommended it to their advisees. This processor 
 will calculate and compare the GPAs in 200- and above level XX courses for 
 the two sets of XX students: those who took YYY108 as suggested, and those 
 who did not. 
 
 The department name (XX), the course name (YYY108), and the course 
 cutoff level (200) are read in by USERA. The input line indicating the course 
 cutoff level is passed by USERA, via the input buffer, to CALC. USERA conse- 
 quently can be used by any department interested in any course; any set of 
 courses which can be selected. by CALC can be examined by USERA. 
 
29 
 
 5. SAFETY & SECURITY 
 
 Two crucial problems of automated system design are reliability 
 (will the system be available when needed) and safety (is the system pro- 
 tected against accidental and malicious tampering). 0LF, as a program package 
 within PL0RTS, can be no more dependable or secure than PL0RTS limitations 
 allow. 
 
 0LF is available whenever PL0RTS is available. (A TSBATCH job 
 can execute 0LF programs when the PDP-7 (the terminal — IBM 360 interface) is 
 not running, but the benefits of interactive processing are lost.) 0LF clearly 
 must be paralleled by an alternate system at least at the times of heaviest 
 use--the registration and advanced enrollment periods. Printouts of the 0LF 
 student records can supply such a supportive system. In most cases, advisors 
 will be able to counsel using only the information on such printouts. In the 
 event of an equipment failure, only the printouts will be avail able--but this 
 is the situation under the present record keeping system. A special processor 
 can be added to 0LF to furnish a conveniently formatted record from each stu- 
 dent file. 
 
 The protection of program files is straightforward. Full access to 
 any PL0RTS file requires knowledge of the triplet (PS#,username,filename). 
 Each user is forced to use his own copy of 0LF (and its current processors) by 
 keeping the username of a master program file secret. As a secondary benefit, 
 this procedure prevents user-supplied processors of narrow applicability from 
 proliferating in the master program file. The minor editing of 0LF necessary 
 before use of a new processor is made on an 0LF copy, and, if the processor is 
 to be kept, the master copy can be updated by authorized personnel after de- 
 bugging is complete. Extra copies should be destroyed after use. A backup 
 
. 30 
 
 tape copy of the master program file (inaccessible without the tape's name) is 
 kept since a user who learns the codeword might maliciously alter the program 
 file. 
 
 Data files must be protected from undebugged processors and PL0RTS 
 (hardware and system software) failures. Processor-inflicted damage is possible 
 only when a processor does not conform to 0LF interfacing conventions. A 
 processor with PART entries for both partial student file read-in and student 
 file output authorization may erase parts of files; a processor with PART 
 student file output authorization that returns an undeserved no-error completion 
 code may overwrite correct information; a directory editing processor without 
 PART authorization for directory file output can render groups of student files 
 inaccessible by normal 0LF methods. Processors can be debugged with a single 
 student file--preferably of an imaginary student. A backup tape of all data 
 files should be prepared after each execution of 0LF (as another job step) in 
 case of errors in the next execution. 
 
 0LF prints a message immediately before and after invoking a proces- 
 sor. A missing completion message indicates which file was being processed 
 when a system failure occurred. A more serious problem is the state of the 
 directory files following a system failure. DLFILE maintains a file on disc 
 of all student files edited from level-three directories but not yet de- 
 allocated. If DLFILE was the active processor, the last file deleted from the 
 level -three directory loaded at the time of failure may not have been added to 
 the deallocate list. CRFILE maintains a similar list of all student files 
 added to level-three directories during the current execution. If CRFILE was 
 the active processor at failure, the most recently created file might not have 
 been added to the list. In all cases, the output of 0LF indicates which directory 
 and student file were loaded when failure occurred. 
 
31 
 
 If failure occurs, any insertions and deletions to the current level- 
 three directory by CRFILE and DLFILE may not be reflected in the disc copy of 
 this directory. An error recovery program (see UTILITIES PROGRAMS) revises the 
 directories to reflect the changes shown in the create and deallocate lists. 
 Any system failure (except a head crash that destroys one of the recovery files 
 at a time when CRFILE or DLFILE is executing) is recoverable. 
 
 As programmed, 0LF data files are not safe from malicious indi- 
 viduals. Files are accessible for proofreading and/or simple editing by ex- 
 plicit terminal command because all file names are constructed of characters 
 available on terminals. File security is thus diminished in return for ease 
 of access. The remainder of this section discusses possible changes to make 
 0LF more secure at the expense of convenience. 
 
 Files whose names contain "characters" not included in the terminal 
 character set are accessible only by program. A one-to-one substitution of 
 non-printable for printable characters—a simple table look-up procedure- 
 suffices to adapt the present file name generating subroutine to this naming 
 convention. Malicious mischief immediately requires a higher level of effort. 
 
 Added safety could be obtained by keeping the substitution table in a 
 disc file protected by a different codeword than the master program file. If 
 security is violated, a recovery procedure would be: change the contents of 
 the substitution table; change the codeword guarding the substitution table; 
 rename, according to the new table (via utility program), all data files. 
 
32 
 
 6. UTILITIES PROGRAMS 
 
 0LF must be supported by several programs which are not needed by 
 general users. 
 
 CRFILE and DLFILE edit the level-three directories; the program 
 DIRECTORY EDITOR (DREDIT) adds or deletes advisors and curricula in the higher- 
 level directories. DREDIT is similar to the other file editors, and is kept 
 apart from 0LF only because its relatively infrequent use does not justify an 
 increase of 0LF storage requirements. 
 
 An error recovery program (RECOVR) is used after a PL0RTS failure 
 occurs following use of CRFILE, DLFILE, or DREDIT. RECOVR edits directories 
 to correspond to the create and deallocate lists maintained by these programs. 
 The file-copying program (C0PY) and file-restoring program (REC0PY) safeguard 
 all student records. 
 
 Envisioned program-approving and progress-assessing processors will 
 use various course and prerequisite data files. These files will require pro- 
 grams for their creation/deletion/editing, which in turn might need error 
 recovery programs. Like DREDIT, the latter will be used too infrequently to 
 incorporate in 0LF proper, and will undoubtedly be run as independent programs. 
 
33 
 
 7. CONCLUSION 
 
 An on-line filing (0LF) system for student records has been de- 
 signed and programmed. 0LF can be instructed to access various groups of 
 student records for use by various data processing subroutines (processors) 
 Since all records are stored on-line and are machine readable, 0LF provides 
 a statistics-compiling capability. It is intended that 0LF eventually be 
 extended, by the programming of new processors, into a complete advisory 
 and record-keeping system. 
 
34 
 
 APPENDIX A 
 
 COMPUTING SERVICES OFFICE DOCUMENTS 
 RELEVANT TO 0LF 
 
 This appendix contains reproductions of four documents pertinent to 
 the use of PL0RTS and/or CALL/36O-0S F0RTRAN. Typographical errors present 
 in the original Computing Services Office documents have been corrected. Cer- 
 tain conventions observed in the body of this report differ from conventions 
 observed in the following documents. 
 
35 
 
 COMPUTING SERVICES OFFICE PLORTS FORTRAN H 17-1 
 
 UNIVERSITY OF ILLINOIS at URBANA-CHAMPAIGN 
 
 FORTRAN is a widely used programming language, implemented as part of the 
 PLORTS timesharing system. To use PLORTS FORTRAN, a person must be authorized 
 to use the PLORTS system, and must have use of a Teletype-compatible or IBM 
 2741 -compatible device. The PLORTS system is discussed in manual CSO-1000, 
 which is available through the consultants, room 166 DCL, and room 83 Com- 
 merce West, or for sale at the Illini Union Bookstore. 
 
 The FORTRAN language implemented is described in IBM manual H20-0710, CALL 
 360-0S FORTRAN LANGUAGE REFERENCE MANUAL, except that CALL/OS commands (such as 
 FILE) are not implemented in PLORTS, and the maximum record that may be read or 
 written using formatted I/O is 80 characters. A procedure to aid in converting 
 existing programs from OS/360 FORTRAN to PLORTS FORTRAN, called FORTCONV, is 
 described in a separate reference guide. 
 
 Once a FORTRAN program has been entered into a PLORTS file, the program 
 may be executed interactively by typing FORTRAN. Execution of a FORTRAN pro- 
 gram may be stopped by execution of a STOP statement, discovery of a run-time 
 error, or by typing KILLL if the program is waiting for input. Execution of a 
 FORTRAN program is halted every 15 seconds and the user is asked if he or she 
 wishes to continue. To continue, type YES or Y; to stop, type NO, N or KILLL, 
 e.g., 
 
 1.000 " THIS PROGRAM COMPUTES MEAN, VARIANCE AND STANDARD 
 2.000 " DEVIATION FOR A SEQUENCE OF POSITIVE NUMBERS AND 
 3.000 " SAVES THE NUMBERS IN A PLORTS FILE NAMED SAVEA. 
 4.000 CALL 0PEN(1,'SAVEA\ 'OUTPUT') 
 5.000 1 READ(5,*) A 
 6.000 IFCA.LT. 0.0) GOTO 3 
 7.000 WRITE (1,2) A 
 8.000 2 FORMAT (E15.6) 
 9.000 1=1+1 
 10.000 S = S + A 
 11.000 Q = Q + A*A 
 12.000 GO TO 1 
 13.000 3 S = S/I 
 14.000 Q = Q/I - S*S 
 15.000 A = SQRT(Q) 
 16.000 WRITE(6,4) S,Q,A 
 
 17.000 4 FORMAT (14X,' MEAN', 14X,' VARIANCE', 7X,% 
 18.000 'STANDARD DEVIATION '/3F20. 6) 
 19.000 STOP 
 20.000 END 
 FORTRAN 
 ?1 
 
 ?2.0 
 ?3E0 
 ?-l 
 
 MEAN VARIANCE STANDARD DEVIATION 
 
 2.000000 0.666666 0.816496 
 
36 
 
 COMPUTING SERVICES OFFICE REF-22-1 
 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN FORTCONV 
 
 2/8/73 
 
 FORTCONV is a procedure to aid in the conversion of programs from IBM 
 FORTRAN to PLORTS FORTRAN. 
 
 The program accepts a FORTRAN source program, and outputs a PLORTS 
 FORTRAN version. If conversion is needed and is simple, (for example, 
 changing the C in a comment to a "), statements are converted. If conver- 
 sion is more difficult, or would require interpretation of the program, the 
 statement is flagged and deleted from the output. 
 
 Suggested use of the program: 
 
 // EXEC FORTC0NV 
 
 {FORTRAN program(s)} 
 
 /* 
 
 The output from this run may be inspected and corrections made. When 
 an acceptable PLORTS FORTRAN deck is produced, it may be checked and filed at 
 
 the same time by: 
 
 // EXEC FORTC0NV 
 PS=ps#,NAME=signonname,DEST=filename 
 
 {FORTRAN program} 
 /* 
 
 NOTE: The program will not insert CALL 0PEN or CALL CL0SE statements. 
 The printed output from the program is relatively lengthy. Use a lines 
 estimate on your ID card approximately equal to twice the number of input 
 cards plus 200. 
 
 A job card (green card) and your ID cards (see REF-01) must be at the 
 front of every deck. 
 
37 
 
 COMPUTING SERVICES OFFICE 
 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 61801 
 
 360 Notice No. 1676 
 CALL/OS Load Modules 
 
 The PLORTS CALL/OS system has been extended to allow for the use of CALL/ 
 OS load modules. The object code generated from a FORTRAN or BASIC compila- 
 tion can be saved in another file by using the parameter 'FILE=filename' on 
 the FORTRAN or BASIC command. 
 
 Examples: 
 
 FORTRAN FILE=0BJECT1[ .other parms] 
 BASIC FILE=0BJECT2[, other parms] 
 
 The object code from the compilation will be stored in the file specified. 
 
 The original filename will become a catalogue file, making normal PLORTS 
 
 editing of the object code impossible. Note, this object code is only valid 
 to run on the PLORTS CALL/OS system. 
 
 In order to run an object program, issue an 'EXEC or 'EXECE' command 
 from closed mode. 'EXECE' like 'OPENE' allows access to files under another 
 PS and name. 
 
 Examples: 
 
 EXEC 0BJECT1[, other parms] 
 
 EXECE 9999. SIGNON . OBJECT! [ 9 other parms] 
 
 Note, a BASIC program can not be executed with the DEBUG option unless it was 
 compiled with DEBUG at the time the object code was saved. 
 
 The examples above indicate that parameters can be used to alter the com- 
 pilation and execution of CALL/OS programs. The following parameters are 
 currently available. 
 
 FILE=filename (described above) 
 
 DEBUG Allows post-mortem analysis, correction and restarting of BASIC 
 programs. See OPENMSG 7 for a complete description. 
 
 TIME=dd where 0<dd<100 dd controls the frequency with which 
 'CONTINUE?' prompts are issued. An executing program may 
 use a minimum of dd seconds of CPU time between successive 
 prompts. Default value is 5 sec. 
 
 In addition, CALL/OS FORTRAN file I/O has been extended to allow data to be 
 filed at the end of an already existing file. To use this facility simply open 
 a file for 'MOD' instead of 'OUTPUT'. 
 
 CALL OPEN (8,'FILENAME','M0D') 
 
 This feature is valid for both formatted and unformatted files. Opening 
 a file for 'OUTPUT' will continue to destroy and recreate the file. 
 
 David Subject 
 DS:jmv March 5, 1973 
 
38 
 
 COMPUTING SERVICES OFFICE 
 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 61801 
 
 360 Notice No. 1697 
 Modifications to CALL/OS 
 
 The filing of CALL/OS object code (Notice No. 1676) has been modified to 
 eliminate the saving of certain unnecessary data, thus reducing the amount of 
 code saved and the number of blocks required to save it. The modification 
 will only effect programs using large non-initialized arrays; that is, arrays 
 not initialized during compilation such as with a FORTRAN "DATA" statement. 
 Existing object modules may still be executed, but must be recreated to make 
 use of the new feature. 
 
 In addition, the CALL/OS FORTRAN "OPEN" subroutine has been modified to 
 allow an optional 4th parameter in which a completion code can be returned. 
 This feature will allow a program to intercept and interpret any errors which 
 occurred trying to open a file and continue executing if desired. If the 4th 
 parameter is not specified then any errors which occur will terminate execu- 
 tion as is now the case. The 4th parameter must be an integer*4 variable or 
 member of an integer*4 array. 
 
 Examples : 
 
 CALL OPEN (8, 'FILE NAME ',' INPUT' , I) 
 Possible completion codes are: 
 
 - successful open 
 
 1 - no space available for an 'OUTPUT'file 
 
 2 - 'INPUT' file does not exist 
 
 3 - 'INPUT' file is a catalog file 
 
 4 - 'OUTPUT' file is currently being used 
 
 5 - an illegal file name was specified 
 
 If the return code is 0, the file is open. In all other cases, it is not, 
 
 Dave Subject 
 April 11, 1973 
 
 DS:jmv 
 
39 
 
 APPENDIX B 
 0LF OPERATIONS MANUAL 
 
 B.l Introduction 
 
 This appendix is a self-contained, non-technical manual for 0LF users 
 (3LF is an on-line filing and data processing system for student records. It 
 consists of a data retrieval program and data processing subroutines (proces- 
 sors). Search commands and processor data statements form the 0LF instruction 
 set. 
 
 0LF input records are limited in length (by the terminal line ca- 
 pacity) to seventy-two characters. An input record is divided into eight 
 fields to form an 0LF instruction. A new field begins every tenth character, 
 starting with the left-most character of the input record. Fields one through 
 eight are numbered consecutively from left to right. The contents of each 
 field are left- justified within that field. Formatted input does not in- 
 convenience an 0LF user since PL0RTS terminals can be programmed to tabulate. 
 
 B.2 Search Commands 
 
 A processor and a set of student records are selected by search com- 
 mands to initiate the processing of information. A processor is specified by 
 a single L0CATE statement; various sets of student records are selected by from 
 one to three L0CATE statements, as explained below. All forms of search com- 
 mands are shown symbolically in Figure 11, where the decomposition of each 
 command into fields is indicated. The symbols in field three are replaced as 
 described below to form syntactically correct 0LF instructions. 
 
40 
 Field— l" Field— 2 Field— 3 
 
 L0CATE PROCESSOR procname 
 
 L0CATE CRRCLM curr# 
 
 L0CATE ADVIS0R advname 
 
 L0CATE STUDENT ssn 
 
 Figure 11. Search Commands 
 
 A processor is selected by a single L0CATE PROCESSOR command. The 
 desired processor's name, of eight or fewer letters in length, is substituted 
 for the symbol "procname" shown in Figure 11. A new set of student records 
 must be selected after each processor request. 
 
 The records of the set of all students enrolled in a specific cur- 
 riculum are selected by a L0CATE CRRCLM command. A six-digit curriculum code 
 replaces the symbol "curr#" of Figure 11. 
 
 The records of all students sharing a common advisor and enrolled in 
 a previously named curriculum are selected by a L0CATE ADVIS0R command. The 
 name of the common advisor, of eight or fewer letters in length (truncated if 
 necessary), replaces the symbol "advname" shown in Figure 11. 
 
 The record of one student counseled by a previously named advisor and 
 enrolled in a previously specified curriculum can be selected by a L0CATE 
 STUDENT command. The student's nine digit social security number (SSN) is 
 substituted for the symbol "ssn" shown in Figure 11. 
 
 The L0CATE CRRCLM, L0CATE ADVIS0R, and L0CATE STUDENT commands, as 
 described above, are used in conjunction to select single student records. 
 Individual access mode is convenient when separate data is needed to process 
 each file (e.g., when recording course grades). When the data to be processed 
 is present in the student records before processing begins (e.g., when compiling 
 curriculum-wide statistics from the completed coursework of students), a 
 
41 
 
 batch-mode access of records—access of many records by only a few commands-- 
 is useful . 
 
 Alternate forms of the non-processor search commands request three 
 levels of batch access. The symbols "curr#", "advname", and "ssn" of Figure 11 
 take the value "*" (asterisk) to request access, respectively, to: all records 
 known to 0LF (the records of all students in all curricula), the records of 
 all students previously specified in a L0CATE CRRCLM statement, and the 
 records of all students previously specified by L0CATE CRRCLM and L0CATE ADVIS0R 
 statements. These search strategies are called, respectively, batch access 
 levels zero, one, and two. For example, the commands 
 
 L0CATE 
 
 CRRCLM 
 
 220014 
 
 L0CATE 
 
 ADVIS0R 
 
 SMITH 
 
 L0CATE 
 
 STUDENT 
 
 * 
 
 select for processing, at batch-access level two, all advisees of Professor 
 Smith in curriculum 220014. A search command containing an asterisk completes 
 the definition of the record set to be processed. 
 
 B.3 Data Statements 
 
 As explained above, individual access mode is used primarily by 
 processors which read data for each student file accessed; batch-access mode 
 is used primarily by processors which use the information already in the student 
 records. Two data statement formats correspond to the two access methods. 
 
 A data statement which is to be read by an individual -access proces- 
 sor is labeled with the SSN of the student whose record is to be processed. 
 The label is compared to the SSN of the owner of the last-requested student 
 record to minimize erroneous input. The SSN occupies the first field of the 
 input record; the remaining seven fields are filled to satisfy the information 
 requirements of the particular processor. 
 
42 
 
 The data read by batch-access processors relates to groups of 
 student records. The word DATA in the first field of the data statement 
 identifies a batch-access data statement. The information required by a 
 processor is located in the remaining seven fields of the statement. 
 
 0LF search commands occupy only three of the eight fields in each 
 statement. A processor (e.g., DLFILE, discussed below) can be written to 
 extract information from fields four through eight of the last search command 
 in a file specification. The data fields of a search command can be used in 
 addition to standard data statements. Figure 12 illustrates the general forms 
 of data statements. 
 
 Field— 1 Field— 2 Field— 3 Field— 4 ... Field— 8 
 
 333224444 Datum 1 Datum 2 Datum 3 ... Datum 7 
 DATA Datum 1 Datum 2 Datum 3 Datum 7 
 L0CATE Filetype Filename Datum 1 Datum 5 
 
 The third statement is a combined search command/data 
 statement. If "Filetype" is not "STUDENT" then "File- 
 name" must be "*" (i.e., data may appear only on the 
 last of a set of search commands). 
 
 Figure 12. Data Statements 
 
 B.4 Errors 
 
 0LF language errors can be grouped into three classes: processor 
 errors, non-translatable search commands, and invalid search commands. A 
 secondary classification groups errors into recoverable and non-recoverable 
 categories: all errors except non-translatable search commands are recoverable. 
 
 The occurrence of a non-translatable or an inconsistent data field 
 on a data statement constitutes a processor error. (The presence or absence 
 of information in the data fields of a search command is determined after the 
 
43 
 
 selection of an access mode; therefore, a processor error cannot be caused by 
 an error in a data field of a search command unless the command fields are 
 error-free.) A processor responds to an error by printing an error message 
 and either skipping the processing step or performing only that portion of 
 the processing step which is independent of the improper field. The particu- 
 lar response depends on the processor involved. 
 
 A request for an unknown student or directory file constitutes an 
 invalid search command. When 0LF detects such a command, an error message is 
 printed and a new search command is requested. 
 
 Another form of invalid search command is possible when CRFILE (i.e., 
 the file-creating processor, discussed below), or a processor invoking it, is 
 active. 0LF ordinarily searches for a requested student record only in the 
 file of his advisor; when a new file is to be created, 0LF must determine that 
 the proposed file does not exist in the file of any advisor. An attempt to 
 access a file by a general search should be unsuccessful. Discovery of a file 
 by general search is an error to which 0LF responds by printing an error 
 message and a new search request. 
 
 A non-translatable search command error can take two forms: a syn- 
 tactically incorrect statement, or a statement that is out of context. 0LF 
 syntax has been explained above. 
 
 0LF expects to receive commands according to the hierarchy of Figure 
 13. An out-of-order statement is considered a non-translatable search command 
 error. A statement may be out of context because another statement is missing. 
 A long series of data statements could result from omitted search commands; 
 accordingly, five or more consecutive data statements are interpreted as a 
 missing search command— a form of non-translatable search command error. 
 
 The recoverable/non-recoverable classification of errors relates to 
 input mode and is discussed in the next section. 
 
44 
 Level Statement 
 
 1 L0CATE PR0CESS0R 
 
 2 L0CATE CRRCLM 
 
 3 L0CATE ADVIS0R 
 
 4 L0CATE STUDENT ' 
 
 3 
 
 5 Data Statements 
 
 i 
 Omitted when preceded by L0CATE CRRCLM * 
 
 2 
 
 Omitted when preceded by L0CATE ADVIS0R * 
 
 3 
 
 Data statements are required by processors, not by 0LF. 0LF enforces a 
 limit, discussed below, of four consecutive data statements. 
 
 Figure 13. 0LF Statement Hierarchy 
 
 B.5 Input Modes 
 
 0LF was designed for interactive use. Interaction, unfortunately, 
 is \jery time-consuming when large amounts of information are being read or 
 printed. The 0LF user can choose card (off-line), rather than terminal, input 
 mode in such cases. 
 
 0LF treats the two input modes differently in three significant 
 areas: printing, input stream delimiting, and response to errors. All card 
 input is printed to make possible the evaluation of 0LF output; terminal input 
 is not printed since the user can read the input which he himself has typed. 
 
 In terminal mode, the stream of data statements is delimited by a 
 blank line (i.e., by typing carriage-return as the first character of an 
 input record). A non-blank line which cannot be recognized as a data statement 
 is an error. It is unreasonable to require that blank cards be inserted 
 throughout an input deck. In card mode, the first card in the data stream 
 which, by error or design, cannot be recognized as a data statement terminates 
 the stream. On the assumption that the first statement following data is a 
 
45 
 
 search command, the image of this card is retained for interpretation as a 
 command. 
 
 Any error detected by 0LF in terminal mode can be corrected by the 
 user. In card mode, 0LF terminates processing upon discovery of non- 
 recoverable errors. A non-recoverable error, as defined above, is a non- 
 translatable, out-of-context, or missing search command. An unavailable 
 command might be a L0CATE PR0CESS0R statement; continued processing following 
 such an error would jeopardize the contents of the student records. 
 
 It should be clear that card mode has both advantages and dis- 
 advantages over terminal mode. The user can have keypunchers prepare his 
 input deck, and his job can be run without the need of his periodic inter- 
 vention; an error, either on his part or on the part of keypunchers, may waste 
 a run. Certain jobs can best be done off-line (e.g., printing a copy of each 
 student record for back-up purposes); jobs containing many search commands may 
 best be run interactively. 
 
 B.6 Use of 0LF 
 
 A user must log into PL0RTS to run 0LF. The log-in procedure is 
 described in the PL0RTS Guide (reference 4). When card mode is to be used, 
 log-in should be accomplished through the catalogued procedure TSBATCH. 
 
 Processing is initiated by an EXEC command (see Appendix A, 360 Notice 
 No. 1676). 0LF will type 
 
 INPUT ON CARDS— TYPE YES OR NO? 
 Terminal users should type NO; off-line users should respond (by a card from 
 the input deck) YES. 
 
 Once the input mode has been determined, 0LF will type 
 TYPE PR0CESS0R REQUEST 
 
46 
 
 to which the user should respond with a L0CATE PR0CESS0R command. In card 
 mode, an error at this point causes termination; in terminal mode, an error 
 causes a processor request to be printed. This is standard 0LF response to 
 a non-recoverable error. 
 
 Once the processor request has been satisfied, 0LF types 
 
 TYPE SEARCH REQUEST 
 
 to which the user should respond with an appropriate search command. Certain 
 errors at this point are non-recoverable (see Errors, above). If the search 
 command is acceptable, but does not constitute a complete search definition 
 (e.g., L0CATE CRRCLM 220014), another search command is requested. 
 
 Once the search strategy is set, 0LF attempts to access the file(s) 
 specified. At this point 0LF determines whether or not the curricula and 
 advisors specified exist. Naming an unknown curriculum or advisor in a search 
 command is a non-recoverable error. 
 
 Another error may occur when CRFILE, or a processor invoking it, is 
 active. The existence of a proposed new file outside of the directory of the 
 proposed advisor is noted by an error message, and the processing step in- 
 volving that student file is skipped. This is the standard 0LF response to 
 recoverable errors. 
 
 It is a recoverable error in most cases to specify a non-existent 
 student record; when CRFILE or a processor invoking it, is active, the request 
 of a non-existent file is not an error. 
 
 Once a student file has been accessed, or if it is to be created, 
 once it has been found not to exist, 0LF types 
 
 TYPE DATA (IF ANY) 
 ? 
 
47 
 
 to which the user should respond as appropriate for the active processor. 
 Some processors may expect data from the last L0CATE statement in place of, 
 or in addition to, any data submitted at this time. 0LF tests the data state- 
 ment for the proper format of the current access level. Out-of-format state- 
 ments cause a warning to be printed and, in terminal mode, the data request to 
 be reprinted. Data requests are repeated until a data delimiter or a fifth 
 data statement is detected. Five consecutive data statements constitute a 
 non-recoverable error. 
 
 The user will receive data requests before each processing step when 
 in individual access mode. During each batch access, data is requested only 
 once, immediately before processing the first of the set of selected files. 
 
 Prior to entering the active processor, 0LF types a message naming 
 the current processor and the student file to be processed. A completion 
 message is printed upon return from the processor. Processor errors are 
 treated differently by various processors, but are always recoverable. When 
 an error occurs, the unedited copy of the current student record is kept. 
 
 Following an error-free processing step, certain processors require 
 0LF to edit its own files. 0LF suppresses editing when an error arises while 
 attempting to edit. 
 
 When a just-completed processing step involves the last of the se- 
 lected student records (as is always the case when in individual access mode), 
 0LF requests a new search command, and the procedure repeats. If the last- 
 named curriculum and/or advisor describes the next set of student records, then 
 new search instructions can begin, respectively, with a L0CATE ADVIS0R or 
 L0CATE STUDENT command. 
 
 Certain processors (e.g., USERA, below) are invoked once for each student 
 record accessed plus once at the completion of the batch access. 
 
48 
 
 When a completed processing step, or a processing step which was 
 skipped because of a recoverable error, did not use the last of the selected 
 set of student records, then (attempted) processing of the next file begins. 
 This case occurs only when in a batch-access mode. 
 
 After completion of all processing requested by a set of commands 
 (which may consist of many processing steps when in a batch-access mode), an 
 alternate response to 0LF's search request is a L0CATE PR0CESSOR command. 
 Following such a response, a new set of search commands is required, starting 
 with L0CATE CRRCLM. 
 
 The user, upon finishing all processing, can signal completion as a 
 response to either a processor search request by typing D0NE. 0LF responds 
 
 AFTER THIS JOB ENDS, TYPE: RUNN C0PY. 
 PL0RTS signals completion of a job by printing ST0P, and the charges for 
 all computer time used. Entered after the 0LF job is completed, the RUNN 
 C0PY command initiates another program which prepares a tape copy of 0LF 
 files for use in the event of a future PL0RTS failure. PL0RTS will respond 
 by typing a job receipt. The user may log-out after initiating C0PY. 
 
 B.7 Present Processors 
 
 As of this writing, 0LF includes five processors. A brief descrip- 
 tion of each processor and its data requirements is given below. 
 
 DUD is a processor which performs no processing. It demonstrates 
 safely to new users the order in which student records are processed in the 
 various access modes. Any input submitted to DUD is ignored. 
 
 CRFILE is the processor which creates student files. The L0CATE 
 STUDENT statement specifying the to-be-created file must include the following 
 
49 
 
 data items: the student's name (last name first) in fields four and five; 
 the proposed entry semester in field six; the proposed entry year in field 
 seven. 
 
 Another data statement is used when the student is enrolling in a 
 co-curriculum: the characters C0CRRLM belong in field two and the co- 
 curriculum's six-digit code belongs in field three. Any additional data 
 statements are ignored. 
 
 CRFILE signals (via its completion code) an error in processing if 
 a datum on the L0CATE card is non-translatable, or if the proposed entry date 
 is in the past. A non-translatable or unknown co-curriculum code causes 
 processing of the co-curriculum to be skipped but does not prevent file cre- 
 ation. An appropriate message is printed by CRFILE in each of the above cases. 
 
 If the data on the L0CATE statement is acceptable, the new file is 
 created, containing the student's SSN, name, college code, curriculum code, 
 advisor's name, and entry date. When submitted correctly, a co-college code 
 and co-curriculum code are also stored. The remainder of the record is ini- 
 tialized as appropriate. 
 
 0LF discards the new file if CRFILE signals an error. When proces- 
 sing goes normally, 0LF attempts to add the name of the new file to its master 
 files (directories). An error message is printed and the new file is dis- 
 carded if the directory of the student's advisor is full. 
 
 DLFILE is the processor which destroys existing student files. Fields 
 four and five of the L0CATE STUDENT card which specifies the to-be-destroyed 
 file must contain the name of the owner of that file, exactly as stored in the 
 file. This comparison prevents the accidental destruction of files. The error 
 message printed when an incorrect name is supplied shows the owner's name, so 
 that misspelling can be differentiated from more serious mistakes. 
 
50 
 
 If the name field on the L0CATE statement matches the name stored 
 in the student file then normal completion is signalled to 0LF, which removes 
 the name of the file from the appropriate directory. If the student file was 
 the only file named in the directory, a message is printed identifying the 
 now-empty directory. 
 
 CALC is the processor which calculates grade-point averages (GPAs). 
 In addition to a GPA, the number and total hours of courses used in the cal- 
 culation are available. 
 
 CALC will find the GPA of practically any subset of courses in a 
 student record. When no data statements are submitted (CALC does not look 
 for data on a L0CATE statement), the GPA is found for courses not yet in the 
 cumulative GPA--presumably the last semester's grades. The cumulative GPAs 
 of all courses, major area of study, and individual departments are also up- 
 dated. 
 
 Combinations of data statements request GPA calculations on differ- 
 ent subsets of the completed coursework. Any group of four or fewer (0LF 
 limitation) of the following statements may be used to choose a particular set 
 of courses. The GPA calculation is done with the set of courses described by 
 the intersection of the sets selected by the individual statements. 
 
 A type of course (major or minor) is selected by a data statement 
 with TYPE in field two and MAJ0R or MIN0R in field three. Both major and minor 
 areas of study are selected by using two data statements. Alternatively, MAJ0R 
 and MIN0R can appear in fields three and four of a single statement (either 
 word first) . 
 
 Courses of one department are selected by a data statement with DEPT 
 in field two and the five-letter department code in field three. 
 
51 
 
 Courses completed since a given date (semester) are chosen by a 
 data statement with SEMESTER in field two, a semester name--FALL (or AUTUMN), 
 SUMMER, or SPRING--in field three, and the year in field four. 
 
 Courses completed since attaining a given academic status are se- 
 lected by a data statement with STATUS in field two and an academic year— 
 FRESHMAN, S0PH0M0RE, JUNI0R, or SENI0R— in field three. 
 
 The last n hours of coursework completed are chosen by a data state- 
 ment with H0URS in field two and a non-negative integer n in field three. 
 The value of n must be written in three digits, using non-significant zeroes 
 as needed. 
 
 Courses at and above a given level n (e.g., 100, 200, etc.) are 
 selected by a data statement with LEVEL in field two and a positive integer n 
 in field three. The value of n must be written in three digits, using non- 
 significant zeroes as needed. 
 
 Figure 14 shows typical CALC data statements. 
 
 Field—! Field— 2 Field— 3 Field— 4 
 
 333224444 TYPE MAJ0R MIN0R 
 333224444 LEVEL 200 
 333224444 H0URS 030 
 
 The above three statements, if submitted to CALC, 
 would request a GPA calculation of all advanced 
 level (i.e., 200-level and above) courses within 
 the last thirty completed hours of study and within 
 either the major or the minor areas of study for the 
 student whose SSN is 333-22-4444. Notice that the 
 number thirty (third statement) is written with 
 three digits. 
 
 Figure 14. Sample CALC Data Statements 
 
52 
 
 USERA is a statistics-compiling processor which helps determine the 
 value of a course of interest as a prerequisite for coursework in any chosen 
 department. The GPAs of students who have taken the course are compared to 
 the GPAs of students who have not taken it. 
 
 The name of the course and department under consideration are sub- 
 mitted to USERA, respectively, in fields four and five of a L0CATE statement. 
 Specific courses from within the chosen department are selected for the com- 
 parison by CALC-form data statements, which are used by CALC. USERA generates 
 the data statement for CALC which selects the chosen department. 
 
 Figure 15 shows statements required for a typical use of USERA. 
 
 Field— 1 Field— 2 Field— 3 Field— 4 Field— 5 
 4- . .4-4' 4-4- 4- 4* 4-4- 4- 
 
 L0CATE PR0CESS0R USERA 
 
 L0CATE CRRCLM 220014 
 
 L0CATE ADVIS0R * XX YYY108 
 
 DATA STATUS SENI0R 
 
 DATA LEVEL 300 
 
 The above statements command 0LF to compare GPAs of 
 two groups of senior students enrolled in curriculum 
 220014— those who have taken the course YYY108, and 
 those who have not. Only 300-level XX courses are 
 used in the calculations. 
 
 Figure 15. Sample Use of USERA 
 
53 
 
 APPENDIX C 
 
 NEW PROCESSORS 
 
 The capabilities of 0LF can be increased, when desirable, by the 
 
 1 
 addition to 0LF of new processors. This appendix is concerned with the me- 
 chanics of creating new processors. Variable names and statement numbers used 
 in the discussion below appear in APPENDIX D: 0LF PROGRAM LISTINGS. 
 
 C.l Changes in 0LF 
 
 A few minor changes are made in 0LF to accommodate each new proces- 
 sor. In combination with reference to the program listings, the following 
 remarks should make clear the nature and necessity of these modifications. 
 
 1) The number of processors assumed to exist is given by 
 the initial value of the INTEGER*4 variable R0WS. 
 
 2) There should be one row in the INTEGER*4 array PART 
 for each processor. The PART entries of each proces- 
 sor are stored in one record (card image) of the disc 
 file named PART, according to a F0RMAT of (5(11, IX)). 
 
 3) The name of each processor is stored as the value of 
 an element of the REAL*8 vector PR0CS. 
 
 4) Each processor may be invoked by only a single CALL 
 statement, which in turn may be reached only via the 
 computed G0 T0 at statement 569. 
 
 5) Each processor must accept the INTEGER*4 argument 
 ERR0R. ERR0R is the completion code of the processor: 
 
 System expansion is restricted only by the TOOK byte main memory limitation 
 
54 
 
 a value of zero implies error-free processing; a value 
 of one indicates a processing error. 
 
 C.2 Scratch Files 
 
 Some processors will use disc files to save intermediate results. 
 A scratch file must not be given the same name as any present or potential 
 0LF file. The file-naming conventions have been discussed in the text of 
 this report. Program files and a few data files have names selected with- 
 out regard to any specific convention. These files are named: 0LF, DREDIT, 
 REC0VR, C0PY, REC0PY, BUFFER, PART, CURRIC, DATES, C0PY1 , C0PY2, SAVE, CC0PY, 
 REST0RE, DELETE1, DELETE2, CRLIST, and DLLIST. Any other names may be used 
 to identify scratch files. 
 
 C.3 Programming Aids 
 
 The task of programming an 0LF processor is simplified by the 
 modular structure and debug option of 0LF. Several character-manipulation 
 and file-handling subprograms compose a large portion of 0LF's code. With 
 the exception of a subroutine which prints 0LF error messages, each subprogram 
 was written with a far broader capability than 0LF required. Each subprogram 
 and processor contains a set of debug print statements which may be enabled 
 (disabled) by the initialization of the INTEGER*4 variable DEBUG to one (zero). 
 Utilization of 0LF components thus simplifies the debugging of new processors 
 while minimizing the amount of new code to be debugged. 
 
 C.4 Information 
 
 0LF can communicate large amounts of information to its processors. 
 
 Use of existent subprograms, which minimizes storage requirements, is also 
 desirable in view of the main memory limitation. 
 
55 
 
 Additional information can come from user input and data files. This section 
 discusses the nature of this information. 
 
 Most of the information that 0LF will share with its processors is 
 found in C0MM0N. This information consists of a student file (HEADER through 
 DBL0CK) and copies of directories and directory-related information (VEC 
 through LL). Additional information may be communicated through a processor 
 parameter list. The mandatory completion code (ERR0R) was discussed above. 
 FINI, an INTEGER*4 variable whose value changes from zero to one upon the 
 completion of a batch access, tells a processor with extra access authoriza- 
 tion in PART (e.g., USERA) whether or not a certain execution of the proces- 
 sor is the extra access. 
 
 0LF accepts a maximum of four consecutive data statements (exclusive 
 of data on a search instruction). User input is stored in the disc file 
 BUFFER. A processor which edits BUFFER for its subprocessor(s) need not 
 observe the four statement limit. 
 
 The remaining sources of information are envisioned system data 
 files. The anticipated expansion of 0LF into a full advisory system will 
 necessitate the creation of such data files as course equivalence tables and 
 curriculum requirements lists. A program-approving processor would logically 
 read from the former; a progress-assessing processor would necessarily use 
 the latter. 
 
56 
 
 APPENDIX D 
 0LF PROGRAM LISTINGS 
 
 " THE OLF PROGRAM PACKAGE 
 ■t 
 
 H CLF MAIN PROGRAM 
 if 
 
 " VECTOR CONTAINS THE 3 DIRECTORIES: 
 
 " VECTOR(l) TO VECTCR(200> HOLD CURRIC (LEVEL-1) 
 
 •• VECTOP(201) TO VECTOR(240) HOLD A LEVEL-2 DIRECTORY 
 
 " VECT0R(241) TO VECT0R1260) HOLD A LEVEL-3 OIRECTOPY 
 
 •• MASTER IS THE ARRAY OF SEARCH NODES 
 
 " MASTER(l) TO MASTERJ3) HOLD THE 3 SEARCH NODES 
 
 •• MASTERI4) HOLDS AN ADVISOR NAMF — RELATED TO MASTER(2) 
 
 •• DUPLIC IS A COPY OF MASTER 
 
 " LAST(l) TO LASTI3) HOLD THE NAMES OF LOADED DIRECTORIES 
 
 ■ PROCS HOLDS THE NAMES OF ALL (ROWS) AVAILABLE PROCESSORS 
 •• PART IS THE PROCESSOR ACCESS RIGHTS TABLE: 
 
 ■ PART HAS SIZE ROWS X 5 — SO PROCESSORS CAN BE ADDED 
 " ROW I HOLDS THE RIGHTS OF THE I-TH PROCESSOR 
 
 M COLUMN 1 IS STUDENT FILE INPUT AUTHORIZATION 
 
 " COLUMN 2 IS STUDENT FILE OUTPUT AUTHORIZATION 
 
 " COLUMN 3 IS DIRECTORY FILE OUTPUT AUTHORIZATION 
 
 " CCLUMN 4 IS DIRECT ACCESS AUTHORIZATION 
 
 " COLUMN 5 IS EXTRA PROCESSOR CALL AUTHORIZATION 
 
 " THE STUDENT FILE IS COMPOSED OF: 
 
 " HFADEP,GIB8,GIB4,GIB2tCHEK0V,DCODE,DBL0CK 
 
 " LINE IS THE INPUT BUFFER 
 
 M LENGTH(I) CONTAINS THE NUMBER OF ENTRIES IN THE I-TH DIRECTORY 
 
 " THE VALUE OF BATCH INDICATES THF ACCESS MODE: 
 
 " BATCH=0 ALL STUDENTS 
 
 " 3ATCH=1 ALL ST'JCENTS IN 1 CURRICULUM 
 
 " BATCH=2 ALL STUDENTS OF I ACVISOR IN I CURRICULUM 
 
 " BATCH=3 A SINGLE STUDENT 
 
 " THE VALUE OF STATUS INDICATES THE PROGRESS OF A SEARCH: 
 
 M STATUS=1 SEARCH JUST STARTING 
 
 " STATUS=? SEARCH IN PRCGPESS 
 
 " STATUS=3 LAST ACCESS OF SEARCH 
 
 M STATUS=4 DONE WITH OLF 
 
 " THE FOLLOWING VARIABLES ARE USED BY THE PROCESSORS: 
 
 ■ SLAVE IS THF IMAGE OF MASTER 
 
 ■ VFC IS THE IMAGE OF VECTOR 
 
 " LL IS THE IMAGE OF LENGTH 
 
 " NODES IS THE IMAGE OF LAST 
 ii 
 
 REAL*8 CURRIC/'CURR I C /, VECTOR ( 260 ), LAST( 4) M* 'DUMMY' / ,% 
 OUT, GIB 8(5) ,FLAG/' ????????•/ ,LOC ATE/ • LOCATE •/, PROC, % 
 DONE /•DONE' / , ANS ( 4 1/ »CRRC LM« f • AD VI SOR ' ♦ •STUDENT* , • PROCESSOR • /ft 
 DUMMY/* DUMMY'/, PROCS (5 ) / • CP F ILE • , « DLF ILE ■ , 'CALCS 
 •DUD', i USERA , /,LIST(2)/»CRLIST« , • DLL I ST • / , DCODE (12 ) , % 
 MASTER (4), SLAVE (4 1 ,VEC( 260 ), PRCS SR/ • PROCESSOR' / ,% 
 DUPLIC(4) ,N0DES(4) , EOUI V ,DAT A/ • D A T A'/,? 
 
57 
 
 EQU(8),PR0B(8)/3** *,*N A M E *,*D A B *,*0 V E * ,S 
 
 2** */,NAME2 
 INTEGER*2 HEADER (32) ,STAR/ •*•/,*$/•$$•/ ,GI B2( 20 ), 55 
 
 CHEK0V(12),DBLDCK( 56, 12 ) , LI NE( 72 ) ,BL/« •/ 
 INTEGER ERR, OK, ST ATUS, BATCH/0/, AUX ,LLEN (3 ) , SKIP/0/,? 
 
 L 1(3) /I, 201, 241 /,L 3(31/0,20,0/, TYPE (4 >/2 ,5, 1 ,5/ ,3 
 
 PGM,ERROR,CARD/0/,CEBUG/0/,YES/*YES*/,N0/*NO*/,PR,? 
 
 COPY (3 ) /3*0/, LENGTH 3 1/3*1/, PART (5, 5 ),f 
 
 FINI ,ROWS/5/,BEGIN/0/,DUP,LL(3) , BB/O/ ,PTR, VI ( 2 ) / • INTO* , • FROM • / 
 REAL GIB4(16),V<2)/* *,*DEST*/ 
 COMMON HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,S 
 
 VEC, SLAVE, NODES, LL 
 EQUIVALENCE (HEADER! 1),EQU( 1 ) ) , ( L INE ( 1 ) , EQUI V) 
 C0MPLEX*16 END(2) /•NORMALLY* ,* IN ERROR 1 /,? 
 
 POSSIBi 2)/* PROCESSOR* ,* SEARCH*/ 
 
 N 
 
 " INITIALIZATION 
 
 ii 
 
 » LOAD PROCESSOR ACCESS RIGHTS TABLE (PART) 
 
 ii 
 
 CALL OPEN( 1,*PART* ,* INPUT* ) 
 
 RE AC (1,2) ( (PART( I ,J) , J=l , 5 ) , 1= 1, ROWS ) 
 
 2 F0RMAT(5(I1,1X)) 
 CALL CLOSE(l) 
 
 IF (DEBUG.EQ. 1) WRITE (6,2000) ( (PART ( I , J ) , J= 1 , 5 ) , 1=1, ROWS) 
 
 ?000 FORMAT!* *P AR T: • / ( IX , 51 2 ) ) 
 •i 
 
 " LOAD THE LEVEL-l DIRECTORY CURRIC 
 
 •i 
 
 CALL LCAD (1, CURRIC, 0, LAST, VEC TOR, LENGTH, CURRIC, 0) 
 •i 
 
 M DETERMINF INPUT MODE — CARDS OR TERMINAL 
 
 w 
 
 3 WRITE(6,4) 
 
 4 FCPMATC INPUT ON CARDS — TYPE YES OP NO*) 
 PEAD(5,5) UK 
 
 5 F0PMATIA4) 
 
 IF ( IJK.EQ.NO) GO TO 99 
 
 IF ( IJK.NE.YES) GO TO 3 
 
 CARD=l 
 99 PR=1 
 it 
 
 •* REQUEST PROCESSOR (OR SEARCH) COMMAND 
 •i 
 
 6 WRITE(6,7) POSSIB(PR) 
 
 7 FOPMATC TYPE *,A9,* REQUEST*/) 
 IF (SKIP.NE.O) GO TO 10 
 READ(5,8) LINE 
 
 8 FORMAT172A1) 
 
 IF (CARD.NE.l ) GO TO 12 
 
 10 WRITE(6,11) LINE 
 
 11 F0PMAT(1X,72A1) 
 
 12 SKIP=0 
 STATUS=1 
 
 20 ERR=0 
 DUP=0 
 0K = 
 
58 
 
 tt 
 •• 
 
 N 
 
 tl 
 II 
 •I 
 
 30 
 
 •• 
 •i 
 ii 
 
 35 
 
 •• 
 •i 
 
 M 
 
 40 
 
 it 
 •i 
 •i 
 45 
 
 it 
 ii 
 •• 
 
 50 
 
 •« 
 tt 
 •• 
 
 52 
 
 ii 
 
 53 
 
 55 
 
 ti 
 it 
 
 FINI=0 
 INCR=0 
 
 TEST CURRFNT STATUS 
 
 IF (STATUS-2) 30,200,1000 
 
 DETERMINE THE NEW SEARCH STRATEGY 
 
 ITYPE=5 
 LEN = 8 
 ISTART=1 
 
 TRANSLATE 1ST FIELD 
 
 CALL CCNVRT(0UT,ITYPF.,LINE,LEN,AUX,1,ERR,6555) 
 IF (OUT. E0. LOCATE) GO TO 45 
 IF (OUT. NE. DONE) GO TO 40 
 
 FINISHED WITH THIS PROCESSOR 
 
 STATUS=4 
 GO TO 150 
 
 INPUT CANNOT BF TRANSLATED 
 
 ERR = 5 
 
 GO TO 555 
 
 TRANSLATE 2ND FIELD 
 
 ISTART=11 
 
 CALL CONVRT(OUT,ITYPE,LINE,LFN,AUX, 11,EPP,6555) 
 
 DO 50 1=1,4 
 
 DETERMINE BATCH ACCESS LEVEL FOP THF NEW SEARCH 
 
 IF (OUT.EQ.ANSU J ) GO TO 52 
 
 CONTINUE 
 
 GO TO 40 
 
 IS THIS A REQUEST F CR A NEW PROCFSSOR? 
 
 IF (PR.EO. 1) GO TO 56 
 
 IF (I.E0.4) GO TO 58 
 
 IF (I.LE.BATCH+1) GO TO 55 
 
 MUST SPECIFY A NODE KEARFR TO THF ROOT 
 
 EPP=6 
 
 GO TO 5 55 
 
 BATCH=I-1 
 
 IF (LINE(21).NE.STAR ) GO TO 60 
 
 THE LAST NODE SPECIFIED IS THE ROOT OF THE 
 SEARCH SUPTREE 
 
59 
 
 56 MASTER(I)=FLAG 
 LLEN( I )=0 
 
 IFU.EQ.3) GO TO 57 
 1 = 1*1 
 
 GO TO 56 
 
 57 STATUS=1 
 
 GO TO 150 
 it 
 
 " MUST TRANSLATE THIS NODE NAME 
 
 n 
 
 58 IF (LINE(21).EQ.STAR) GC TO 132 
 60 ISTART=21 
 
 ITYPE=TYPE(I) 
 IF (I.NE.3) GO TO 120 
 IF (BATCH. EQ. 2) LEN=9 
 it 
 
 " TRANSLATE 3RD FIELD 
 
 ti 
 
 120 CALL CONVRT(OUT,ITYPE, LINE, LEN , AUX , I START , ERR, 6555 ) 
 
 MASTER (I)=OUT 
 ii 
 
 » PROCESS THE NEW LINE 
 
 •i 
 
 IF (I.NE.4) GO TO 130 
 DO 122 PGM=1,R0WS 
 
 IF (OUT.EQ.PROCS(PGM)I GO TO 125 
 122 CONTINUE 
 ERR = 5 
 
 125 PROC=PROCS(PGMJ 
 
 IF (DEBUG. EQ. I) WRITE(6,126) PROC 
 
 126 FORMAT! • *THE ACTIVE PROCESSOR IS • ,A8) 
 
 BB=0 
 ti 
 
 ■ GET THE NEXT SEARCH SPECIFICATION 
 
 PR=2 
 BATCH=0 
 GO TO 6 
 130 IF (PR.NE.l) GO TO 133 
 
 132 ERR=11 
 
 GO TO 555 
 
 133 IF (I.NE.3) GO TO 135 
 BATCH=3 
 
 STATUS=1 
 
 GO TO 150 
 
 135 IF (I.EQ.l) CALL R ENAMEI $$, MASTER ( 1 ) ) 
 
 IF (I.E0.2) MASTERU) = NASTEP(2) 
 
 BATCH=BATCH+1 
 n 
 
 " READ NEXT LINE OF TFE SEARCH SPECIFICATION 
 ti 
 
 GO TO 6 
 
 M 
 
 M ACCESS A STUDENT FILE 
 •• 
 
 150 IF (STATUS. NE . 4) GO TO 200 
 n 
 
60 
 
 " PREPARING TO TERMINATE JOB 
 
 it 
 
 152 WPITE{6,155) 
 
 155 FORMATC GOING INTO FINAL WRAPUP 1 ) 
 
 IF (COPY(3).EQ.l) CALL LOAO( 3, DUMMY, COPY( 3 ), L AST, VECTOR ,S 
 LENGTH, DUMMY, 0) 
 
 WRITE(6,165) 
 165 FORMAT!' AFTER THIS JOB ENDS, TYPE:',' RUNN COPY') 
 
 STOP 
 •• 
 
 « ACCESSING STUDENT FILES 
 
 ii 
 
 200 IF (CEBUG.EO.l) WR I TE( 6, 2030} STATUS, BATCH , (MASTER ( MM ) ,MM=1 ,3 ) 
 
 2030 FORMATC *SEARCH STRATEGY DETERMINED:*? 
 
 • STATUS=», I1,5X,»EATCH=* ,Il,/» MASTERS , 3A12 ) 
 
 ILK = 
 
 KK=BATCH+1 
 
 1 = 1 
 
 IF (STATUS. GT.l) GO TO 215 
 
 STATUS=2 
 
 BB=0 
 
 KM=1 
 
 210 IF (MASTER(I).NE.FLAG) GO TO 220 
 
 ii 
 
 " FIND THE NAME OF THE NEXT LEVEL-I DIRECTORY 
 
 N 
 
 215 I=KM 
 
 MASTER (I) =VECT0R(L1( I)+LLEN(I )+L3(I)) 
 
 LLEN( I ) = LLEN(I ) ♦ 1 
 
 217 DUP=1 
 
 GO TO 222 
 n 
 
 M IF MASTER(I) IS THE CURRENT LEVEL-I DIRECTORY, 
 
 " IT MUST EXIST 
 
 •t 
 
 220 IF (MASTER! I) .EQ.LASTl 1+1) ) GO TO 217 
 
 •« 
 
 " SEARCH FOP MASTER(I) IN DIRECTORY(I) 
 
 M 
 
 CALL BISECT (VECTOR, LENGTH, MASTER (I ),DUP,PTR, I, LAST) 
 LLEN( I )=PTR-L1( I)*l 
 IF (DUP.EQ.O) GO TC 222 
 
 IF (I.EQ.2) MASTER(2)=VECT0P(PTR+L3(2) ) 
 222 DUPLICd ) = MASTER(I) 
 
 IF (I.EQ.2) DUPLIC(4)=MASTER(4) 
 IF (DUP.NE.O) GO TO 225 
 IF (I.E0.3) GO TO 260 
 
 THE DIRECTORY JUST REQUESTED IS UNKNOWN 
 
 GO TO 300 
 225 NAMF2=VECT0R(L1(I )+LLEN( I)-l) 
 
 IF ( I.EQ.3) GO TO 26C 
 
 " LOAD FILE NAMED MASTER(I) INTO LEVEL-(I+1) DIRECTORY 
 
 N 
 
 KARD=CARD 
 
61 
 
 
 CALL L0AD(l4-l,MASTERU) t COP Yd + 1 1 , LAST , VECTOR , LENGTH, % 
 
 
 NAME2,KARDI 
 
 
 1*1*1 
 
 
 KM=KM*1 
 
 
 IF <LENGTH( I) .NE.O) GO TO 210 
 
 
 IF (BATCH. NE.3) GO TC 240 
 
 
 DUP = 
 
 
 STATUS=3 
 
 
 DUPLIC(3)=MASTER(3) 
 
 
 PTR=L1(3) 
 
 
 GO TO 290 
 
 240 
 
 LLENU)=LLEN(I)+1 
 
 
 ILK=1 
 
 
 1 = 1-1 
 
 
 GO TO 261 
 
 260 
 
 0UT=MASTER(3) 
 
 it 
 
 IF (BATCH. EO. 3), GO TC 263 
 
 n 
 
 it 
 
 IS THE BATCH ACCESS COMPLETED WITH THIS LAST FILE? 
 
 261 
 
 J=3 
 
 262 
 
 IF (LLEN(J).LT. LENGTH! J)) GO TO 265 
 
 
 J=J-1 
 
 
 IF (J.GE.KK) GO TO 262 
 
 263 
 
 STATUS=3 
 
 
 GO TO 290 
 
 265 
 
 KM=J 
 
 IF (J. NE.3 ) GO TO 267 
 
 MASTER(3)=FLAG 
 
 GO TO 290 
 267 KI=LLEN(J) 
 
 DO 270 L=J,3 
 
 LLEN(L)=0 
 270 MASTER(L)=FLAG 
 
 LLEN(J)=KI 
 290 IF (ILK.EQ.O) GO TO 295 
 
 H 
 
 M AN EMPTY DIRECTORY V.AS SPECIFIED 
 
 N 
 
 ERR=12 
 GO TO 555 
 ii 
 
 " IF THE FILE WAS FOUND— GO PROCESS IT 
 ii 
 
 295 IF (DUP.EO.l) GO TO 350 
 
 IF (I. NE.3) GO TO 300 
 it 
 
 " DOES THE CURRENT PROCESSOR HAVE DIRECT ACCESS OK? 
 
 M 
 
 IF (PART(PGM,4).EQ.l ) GC TO 305 
 ii 
 
 H THE LEVEL-J FILE JUST REQUESTED IS MISSING 
 
 ii 
 
 300 ERR=6+I 
 FINI=1 
 GO TO 555 
 
62 
 
 " TRY TO ACCESS THE STUDENT FILE DIRECTLY 
 
 N 
 
 305 CALL OPEN(1,OUT, 'INPLT' ,K| 
 
 IF (K.EQ.O) GO TO 320 
 n 
 
 " FILE DOES NOT EXIST 
 
 •i 
 
 DO 310 1*1,8 
 310 EQUd )=PROB(I ) 
 
 DO 315 1=1,9 
 315 HEADER! I) = LINEU + 20) 
 
 GO TO 500 
 
 H 
 
 " THE FILE EXISTS — FIND OUT ITS OWNER 
 
 N 
 
 320 ERR=3 
 
 READ(1,355) HEADER, GIB8 
 
 CALL CLOSEd) 
 
 GO TO 555 
 350 IF (DEBUG. EQ.l) WRITE(6,352) OUT 
 352 FORMAT!* *NOW READING STUDENT FILE ',A8) 
 
 N 
 
 " READ IN THE APPROPRIATE APCUNT OF THE STUDENT FILE 
 
 M 
 
 CALL OPEN(l , OUT, 'INPUT* ) 
 
 READl 1,355) HEADER , G IB8,GI B4,G 1 82 ,CHEKOV 
 3 55 F0RMAT(32A1,5A8/16A4/20A2, 12A1) 
 
 IF (PART(PGM, I) .EQ.l) REAC(1,360) DCODE,DBLOCK 
 360 F0RMAT(6A8/6A8/(28A2)) 
 
 CALL CLOSEd) 
 
 n 
 it 
 
 MAKE SURE THAT THIS STUDENT IS IN THE RIGHT CURRICULUM 
 
 IF (DUPLICll).EQ.GIB8(2) ) GO TO 500 
 
 WRONG CURRICULUM — ACVISOR COUNSELS >1 CURRICULUM 
 
 DUP=0 
 ERR = 4 
 GO TO 555 
 
 M 
 
 " LOCK FOR INPUT IF IN INDIVIDUAL ACCESS MODE 
 
 " (BATCH=3) OR IF ON 1ST ACCESS OF A BATCH ACCESS 
 it 
 
 500 IF (BATCH. EQ. 3) GO TC 501 
 IF (BB.EQ.O) GO TO 501 
 GO TO 555 
 
 N 
 •I 
 
 501 BB=1 
 
 BUFFER INPUT TO THE PROCESSOR 
 
 CALL OPEN( 12, 'BUFFER ', 'OUTPUT* I 
 WRITE(12,8) LINE 
 
 H 
 
 " REQUEST DATA FOR PROCESSOR (IF ANY) 
 
 ii 
 
 NUM=1 
 
63 
 
 502 ITRY=1 
 
 503 WRITE(6,504) 
 
 504 FORMATC TYPE OATA (IF ANY)'/) 
 READ(5,8) LINE 
 
 IF (BATCH. EQ. 3) GO TO 508 
 
 IF (EQUIV.EQ.DATA) GC TO 530 
 
 GO TO 513 
 508 00 510 1 = 1 ,9 
 
 IF (HEADERU) .NE.LINEI I)) GO TO 513 
 510 CONTINUE 
 
 GO TO 530 
 
 513 IF (CARD. NE. II GO TO 514 
 SKIP=1 
 
 GO TO 540 
 •i 
 
 " ACCEPT A CARRIAGE RESTORE AS END OF DATA 
 
 " WHEN IN TERMINAL INPUT MODE 
 it 
 
 514 DO 515 1=1,72 
 
 IF (LINE(I).NE.BL) GC TO 520 
 
 515 CONTINUE 
 
 GO TO 540 
 it 
 
 " CANNOT TRANSLATE LAST LINE 
 
 •i 
 
 n 
 
 " GET FOUR CHANCES TO GET IT RIGHT WHEN 
 " IN TERMINAL INPUT MODE 
 
 M 
 
 520 IF (ITRY.GT.4) GO TO 525 
 
 IF (BATCH. EQ. 3) WR ITE ( 6, 522) ( L INF ( M ) , M= 1,9 ) 
 
 522 FORMAT( 1X,9A1,' DOES NOT MATCH THE SSN OF THE ',% 
 
 •REQUESTED FILE') 
 IF (BATCH. LT. 3) WPITE(6,523) 
 
 523 FORMAT!' TYPE "DATA " IN COLUMNS ',« 
 
 •1 TO 8 FOR BATCH MODE DATA INPUT') 
 
 ITRY=ITRY+i 
 
 GO TO 503 
 
 525 ERR=5 
 
 GO TO 540 
 n 
 
 " TRANSFER THIS LINE TO THE BUFFER 
 
 N 
 
 530 WRITE(12,8) LINE 
 
 IF (CAPD.EQ.l) WRITE(6,11) LINE 
 
 NUM=NUM+1 
 
 IF (NUM.LE.4) GO TO 503 
 ii 
 
 " TOO MUCH INPUT 
 w 
 
 ERR=2 
 
 540 CALL CL0SE(12) 
 n 
 
 " PRINT STATUS BEFORE CALLING PROCESSOR 
 
 M 
 
 555 CALL OUTPUT(ERR, PROC, BATCH, DUPLIC, LAST, I, GIB8,% 
 LINE, HEADER, I ST ART ,LEN, NAME2 , OK) 
 
64 
 
 ■ IF THERE»S BEEN AN ERROR ABOVE, SKIP PROCESSONG STEP 
 
 it 
 
 IF (1-OK) 556,560,637 
 •• 
 
 '• SERIOUS ERRORS—CAUSE TERMINATION IN CARD MODE 
 
 M 
 
 556 IF (CAPD.EQ.O) GO TO 99 
 WRITE(6,557) 
 
 557 FORMAT! • SINCE INPUT IS ON CARDS, PROGRAM MUST STOP') 
 GO TO 152 
 
 •i 
 
 " PREPARE FOR BRANCH TO CURRENT PROCESSOR 
 
 H 
 
 560 ERROR=0 
 
 DO 562 1=1,4 
 562 SLAVE(I) = DUPL ICC I) 
 
 DO 568 1=1,3 
 
 K=LENGTH( I ) 
 
 LLU) = K 
 
 IF (I.E0.2) K=K+L3(I) 
 
 M=L1(I ) 
 
 DO 567 J=M,K 
 
 567 VEC(J)=VECTORCJ) 
 
 568 NODES( II=LAST(I ) 
 
 N 
 
 " BRANCH TO PROCESSOR 
 
 N 
 
 569 GO TO (570, 575, 580, 585,590), PGM 
 
 570 CALL CRFILEIERROR,INCR,DUP) 
 GO TO 600 
 
 575 CALL DLFILECERROR, INCR ) 
 
 GO TO 600 
 580 CALL CALC(GPA, HOURS, ERPCP,NUM, 1,0) 
 
 GO TO 600 
 585 CALL DUD 
 
 GO TO 600 
 590 CALL USERA(ERROR,FINI) 
 •i 
 
 " IF THE PROCESSOR SIGNALLEC AN ERROR, DISALLOW OUTPUT 
 
 H 
 
 600 IF (ERROR. NE.O) GO TC 630 
 
 H 
 
 ■ IS THERE DIRECTORY EDITING AUTHORITY? 
 
 " (EDITING NOT ALLOWED AFTER STATISTICS ACCESS) 
 ii 
 
 IF (FINI.EO.l) GO TO 630 
 IF (PART(PGM,3) .EO.O) GO TO 610 
 n 
 
 " DOES IT WANT TO EDIT THE DIRECTORY? 
 
 M 
 
 IF ( INCP.EQ.O) GO TO 610 
 
 NAME2=MASTER(4) 
 
 CALL REVISE(VECTOR,LENGTH,OUT,OUT,PTR,3,INCR,LAST,ERROR,NAME2) 
 n 
 
 " IF THE EDITING SUBPROGRAM REPORTS AN ERROR, DISALLOW EDITING 
 
 •i 
 
65 
 
 IF <EPPOR.NE.O) GO TO 630 
 n 
 
 " THE DIRECTORY WILL BE REWRITTEN ONLY IF 
 
 « THIS FLAG IS SET 
 
 N 
 
 C0PY(3)=1 
 K=INCR 
 
 IF (K.EQ.-l) K=2 
 CALL 0PEN(1,LIST(K), 'MOD') 
 WRITE (1,605) V(K) ,OUT ,V l( K ) ,DUPL IC ( 2 ) 
 605 F0RMAT(A4,1X,A8,10X, A4,1X,A8) 
 CALL CLOSE(l) 
 
 » IS OUTPUT OF THE STUDENT FILE AUTHORIZED? 
 ii 
 
 610 IF (PART(PGM,2) .EQ.O) GO TO 630 
 
 CALL OPEN( It OUT, 'OUTPUT') 
 
 WRITE (1,615) HEADER,C-IB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK 
 615 F0RMAT(32Al,5A8/16A4/20A2f 12A1 /6A8/6A8/ (28A2 ) ) 
 
 CALL CLOSE(l) 
 
 M 
 
 " WRITE COMPLETION MESSAGE 
 
 ii 
 
 630 ERR0R=ERR0R+1 
 
 WRITE(6,635) PROC, END (ERROR ) 
 
 635 F0RMAT(1X,A8, • ENDED f ,A16) 
 ii 
 
 " AFTER STATISTICS WRAPUP ASK FOR NEW PROCESSOR 
 
 •• 
 
 637 IF (FINI. EQ.l) GO TO 6 
 n 
 
 M CHECK SEARCH STATUS 
 
 GO TO 20 
 PREPARE FOR STATISTICS WRAPUP — IF ANY 
 
 1000 IF (PART(PGM,5) .EQ.O) GO TO 6 
 EPR = 1 
 FINI=1 
 GO TO 555 
 
 END 
 
 OLF PROCESSORS 
 
 PROCESSOR CRFILE CREATES EACH NEW STUDENT FILE 
 
 SUBROUTINE CR FILE ( ERROR, I NCR, DUP) 
 
 REAL*8 DCODE( 12),GIB8(5) ,S LAVE ( 4 ), OUT, BLANK/' '/,VEC( 260) , NODES( 4 ) 
 
 INTEGER*2 LLINE(72) , CBLOCK ( 56 , 12) , GIB2 ( 20) ,CHEKOV( 12) ,HEADFR( 32 >,? 
 
 M(20),BL/' '/,ZEPO/'0'/ 
 REAL GIB4(16) 
 
 INTEGER ERROR, DEBUG/ 0/ , DUP, ENTRY, LL (3) ,$$*2/'$$'/ 
 COMMON HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,% 
 
66 
 
 VEC, SLAVE, NODES, LL 
 
 EQUIVALENCE (GI B8 ( 1) ,M( 11 I 
 
 IF (DEBUG. EQ.l) WRITE(6,5) 
 5 FORMATC *ENTERING CRFILEM 
 
 CALL OPEN( 12, 'BUFFER', 'INPUT* ) 
 
 READ(12,8) LLINE 
 
 8 FORMATI72A1) 
 
 IF tDUP.EO.O) GO TO 20 
 it 
 
 " THE PROPOSED FILF ALREADY EXISTS 
 
 it 
 
 WRITE<6,10) 
 
 10 FORMATC THE PROPOSED FILE ALREADY EXISTS') 
 
 GO TO 990 
 ii 
 
 ■ DOES THE NAME FIELD CONTAIN ANY TYPOS? 
 •i 
 
 20 CALL CCNVRT(OUT, 3, LLINE, 20, JUNK, 31, ERROR, &990) 
 ii 
 
 •• IS THE PROPOSED ENTRY DATE OK? 
 
 CALL TIMES(ENTRY,LLINE,51,61,K,ERR0R,£990) 
 IF (K.GE.O) GO TO 60 
 WRITE(6,40)(LLINE( I ) ,1=51,65) 
 40 F0RMATI1X, 15A1,« IS PAST — CAN''T BE AN ENTRY DATE') 
 GO TO 990 
 
 M 
 
 " INITIALIZE THE NEW FILE 
 
 N 
 
 60 DO 70 1=1,30 
 
 70 HEADER( I)=LLINF( 1+20) 
 
 HEADER! 10) = BL 
 
 HEADER<31)=BL 
 
 HEADER<32)=BL 
 
 DO 90 1=1,12 
 90 CHEKOVU ) = ZERO 
 
 DO 100 1=1,16 
 100 GIB4(I)=0.0 
 
 DO 110 1=1,20 
 110 GIB2(I)=0 
 
 GIB2(2)=ENTRY 
 
 GIB81 1)=BLANK 
 
 GIB8(2)=SLAVE(i) 
 
 GIB8(3)=SLAVE<4) 
 
 GIB8U) = BLANK 
 
 GIB8(5)=BLANK 
 ii 
 
 " INSERT COLLEGE CODE FRCM 2ND BYTE OF CURRICULUM CODE 
 
 it 
 
 M( 1 ) = M(6) 
 
 N 
 
 INCR=1 TELLS OLF TO ADD THE NEW FILE TO THE ADVISOR LIST AND 
 TO THE LIST OF NEW FILES 
 
 INCR=1 
 K=0 
 
 •i 
 

 67 
 
 • IF THERE IS NO MORE CATA — RETURN 
 n 
 
 READ(12,8,END=1000) LLINE 
 K=l 
 if 
 
 " PROCESS CO-CURRICULUM FIELD 
 
 N 
 
 CALL CONVRT(OUT,2,LLINE,8, JUNK, 21 , ERROR ,£1 15) 
 
 GO TO 300 
 
 it 
 
 " LET MISTAKE IN CO-CURRICULUM GO BY WITH A WARNING 
 n 
 
 115 ERROR=0 
 
 WRITE(6,120) 
 120 FORMAT!' CREATING THE FILE WITHOUT CO-CURRICULUM*) 
 
 GO TO 1000 
 it 
 
 •• MAKE SURE THAT THE PROPOSED CO-CURRICULUM EXISTS 
 
 •• 
 
 300 CALL RENAME($$,OUT) 
 
 CALL BISECTIVEC.LL , OUT, DUP,PTR,1, NODES) 
 
 IF (DUP.EQ.l) GO TO 350 
 
 WRITE16,310) OUT 
 310 FCRMAT(« CURRICULUM ',A8,' IS UNKNOWN*) 
 
 GO TO 115 
 350 GIB8(5)=OUT 
 ii 
 
 " GET CO-COLLEGE CODE FRCM CO-CURRICULUM CODE 
 
 ii 
 
 M( 13)*M(18) 
 
 GO TO 1000 
 990 ERR0R=1 
 
 1000 IF (DEBUCEQ.l) WR I TE (6 , 1005 ) ERROR 
 1005 FORMAT*' ^LEAVING CRFILE — EPR0R=',I1) 
 
 RETURN 
 
 END 
 •• 
 
 M 
 •I 
 
 n 
 
 " PROCESSOR DLFILE DELETES EACH OBSOLETE STUDENT FILE 
 
 M 
 
 SUBROUTINE DL F ILE ( ERROR , I NCR ) 
 
 REAL*8 VEC(260),DC0DE( 12) ,G I B8( 5 ) , SLAVE (4) , OUT, NODES ( 4) ,GIB4*4( 16) 
 
 INTEGER*2 LLINEI72) , CBL0CM56, 12) , GI B2 ( 20 ) , CHEKOVl 12 ), HEADER ( 32 ) 
 
 INTEGER ERROR, DEBUG/0/, LL(3) 
 
 COMMON HEADER,GIB8,GIB4,GIB2,CHEK3V,DC0DE,DBL0CK,S 
 
 VEC, SLAVE, NODES, LL 
 
 IF (DEBUG. EO.i) WRITE<6,5) 
 
 5 FORMATC + ENTERING DLFILE') 
 
 •• 
 
 " COMPARE HEADER TO THE NAME FIELD IN THE DELETE REQUEST 
 
 ii 
 
 20 CALL OPEN! 12, 'BUFFER ', 'INPUT' ) 
 
 READ(12,22) LLINE 
 22 F0RMAT172A1) 
 
 CALL CL0SEU2) 
 
68 
 
 DO 25 1=11,30 
 
 IF <LLINEU«-20).NE.HEADER(I )) GO TO 30 
 25 CONTINUE 
 GO TO 40 
 
 M 
 
 " NAMES DON'T MATCH 
 
 n 
 
 3 WRITE (6,35) (HEADERC I ), 1 = 11,30) 
 
 35 FORMATP NAMES DIFFERENT — FILE FOR »,20A1) 
 
 GO TO 990 
 w 
 
 " ADD COMPLETION DATE TO THE FILE 
 
 rt 
 
 40 CALL OPEN( 1, 'DATES' , 'INPUT* ) 
 
 READ(1,45) GIB2(7) 
 45 F0RMAT(I5) 
 
 CALL CLOSE(l) 
 
 N 
 
 " INCP=-1 TELLS OLF TO DELETE THE FILE FROM THE ADVISOR 
 
 " LIST AND TO ADD IT TO THE OBSOLETE FILE LIST 
 
 ii 
 
 INCR=-l 
 
 GO TO 1000 
 990 FRR0R=1 
 
 1000 IF (DEBUG. EO. I) WR IT E( 6, 1005) ERROR 
 1005 FORMATC *LEAVING DLFILE — ERR0R = , ,I1) 
 
 RETURN 
 
 END 
 
 M 
 
 •I 
 M 
 II 
 
 n 
 
 " PROCESSOR CALC CALCULATES GPA'S FROM VARIOUS SETS OF GRADES: 
 
 " GRADES RECORDED IN THE FILE BUT NOT INCLUDED IN GPA, OR 
 
 " THE UNION OF UP TO ANY 4 OF THE FOLLOWING: 
 
 " 1) ALL COURSES WITHIN THE MAJOR AREA OF STUDY 
 
 " 2) ALL COURSES WITHIN THE MINOR AREA(S) OF STUDY 
 
 " 3) ALL COURSES WITHIN THE MAJOR AND MINOR AREAS OF STUDY 
 
 M 4) ALL COURSES WITHIN A SPECIFIC DEPARTMENT 
 
 " 5) ALL COURSES PAST A GIVEN SEMESTER 
 
 " 6) ALL COURSES PAST A GIVEN ACADEMIC STATUS 
 
 H 7) ALL COURSES WITHIN A GIVEN NUMBER OF HOURS 
 
 M 8) ALL COURSES INCLUDING AND ABOVE A GIVEN LEVEL (E.G., 100) 
 
 " THE DEFAULT VALUES ARE: 
 
 " ALL DEPARTMENTS, 
 
 M MAJOR, MINOR, AND GENERAL EDUCATION COURSES, 
 
 " 100 LEVEL, 
 
 " FROM FRESHMAN STATUS, 
 
 " FROM ENTRY, AND 
 
 " ALL HOURS COMPLETED 
 
 " GRADES USED IN CALCULATIONS ARE A , B, C , D, E , AB . 
 
 " AB IS REPRESENTED INTERNALLY AS G. 
 
 ■ GRADES NOT YET INCLLDED IN A GPA ARE FLAGGED WITH 
 
 " AN ASTERISK (E.G., A*). AN 'IP' GRADE CODE STANDS 
 
 " FCP • IN PROGRESS'. 
 
 N 
 
69 
 
 SUBROUTINE CALC (GPA , HOURS , ERR OR ,NUM, PRI NT, SET ) 
 
 INTEGER*2 LLI NE( 72 ) , CBLOCK ( 56, 12) , GIB2 ( 20) ,HEAD=R(32) ,CHEKOV< 12),% 
 
 GRADE, UK, AB/'AB'/.Giej/^G* .'ES'DS'CS'BS'A*/,* 
 
 IP/»IP»/ 
 INTEGER ERROR, SUM1,SUM2,SUM3, SUM*, DEPT( 12 ) , DDATE, AUX, % 
 
 FINI ,S,T,DEBUG/0/,CUT0FF,END,PRINT,SET,H,HR,L0NG(6)/4*8,2*3/,% 
 
 Li(2)/2,l/,L2(2)/2,l/,LLt3),TYPE(6)M*5,2*6/,PP,K0L/l/ 
 REAL*8 VEC1260) ,OUT , SLAVE ( 4 ) , DCODE < 12 ) ,GI B8 (5 ) , A< 3 ) / • MA JOR • 9 % 
 
 •MINOR 1 , • »/,B< 4) /'FRESHMAN* , • SOPHOMORE' ,' JUNIOR* , 'SENIOR •/,% 
 
 KEY<6)/*TYPE*,'DEPT' ,' STATUS' , • SEMESTERS 'HOURS 1 ,* LEVEL' / 9 % 
 
 N0DESC4) ,GIB4*4(16) 
 COMMON HEA0ER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,S 
 
 VEC, SLAVE, NODES, LL 
 IF (DEBUG. EQ.l) WRITE<6,5) SET 
 5 FCPMATP *ENTERING CALC — SET=',I1) 
 
 it 
 
 « INITIALIZATIONS 
 
 it 
 
 PP=PRINT 
 NUMBER=0 
 DO 7 J=l,12 
 7 DEPT(J)=0 
 
 MM=0 
 IFAIL=0 
 NUM=0 
 HOURS=0.0 
 GPA=0.0 
 NMAJOR=0 
 T = 
 SUM 1=0 
 SUM2=0 
 SUM3=0 
 SUM4=0 
 KK=1 
 
 S=0 
 •• 
 
 " IF SET = 1, THEN LEVEL, DDATE, ETC. FROM THE LAST 
 
 " USE OF THE PROCESSOR ARE TO BE USED AGAIN 
 
 •i 
 
 IF (SET.NE.O) GO TO 1900 
 1 = 
 •• 
 
 " THERE ARE IEND DEPT . BLOCKS USED IN THIS FILE 
 
 n 
 
 IEND=GIB2(10) 
 
 ODATE=0 
 
 IT0P=3 
 
 IBOT=0 
 
 LEVEL=100 
 
 M 
 
 " FIND CURRECT SEMESTER 
 
 M 
 
 CALL OPEN( I, 'DATES' , 'INPUT' ) 
 READIltlO) NOW 
 10 F0RMATU5) 
 
 CALL CLOSEtl) 
 
70 
 
 " READ SEARCH CLASS OESCRIPT IONC S ) 
 
 it 
 
 CALL OPENC 12, 'BUFFER', UNPUTM 
 
 N 
 
 " FIRST LINE IN BUFFER IS AN OLF COMMAND, 
 
 " NOT A DATA LINE FOR THIS PROCESSOR 
 
 •i 
 
 READ(12,20) LLINE 
 17 READU2,20 ,END=1000) LLINE 
 
 20 FORMATC72A1) 
 
 1 = 1 
 
 M 
 
 " DETERMINE TYPE OF DESCRIPTION 
 
 ti 
 
 CALL CCNVRT(OUT,5,LL IN E, 8, AUX, 1 1 , ERROR, £29901 
 
 DO 30 J=l,6 
 
 IF (OUT. EO. KEY! J) ) GC TO 40 
 30 CONTINUE 
 
 GO TO 2800 
 40 IF CJ.EQ.4) GO TO 400 
 
 MM=1 
 •• 
 
 " CCNVERT THE DATA FIELD 
 
 n 
 
 50 CALL C0NVRT(OUT,TYPE(J) , LLINE, LONG C J ) , AUX, 11* 10*MM, ? 
 
 ERROR, £29931 
 n 
 
 " SET THE STRATEGY 
 n 
 
 GO TO ( 100, 200, 300, 4C0, 500, 600) , J 
 
 N 
 
 " MAJOR AND/OR MINOR CCURSES 
 
 ii 
 
 100 DO 115 K=l,3 
 
 IF IACK).EQ.0UT) GO TO 120 
 115 CONTINUE 
 
 GO TO 2800 
 120 IF C0UT.EQ.AC3>) GO TO 170 
 
 IF CLICK). LT. ITOP) IT0P = L1(K) 
 
 IF (L2(K).GT. IBOT) ieOT=L2CK) 
 
 KK=KK+1 
 
 MM=2 
 
 IF CKK.LE.2) GO TO 50 
 
 GO TO 17 
 
 170 IF (KK.EO.l) GO TO 2800 
 
 GO TO 17 
 •i 
 
 " COURSES IN A SPECIFIC DEPARTMENT 
 
 200 DO 250 K0L = 1, IEND 
 
 IF (OUT.EO.DCODE(KOL)) GO TC 270 
 250 CONTINUE 
 
 WRITEC6,260) OUT 
 260 FOPMATC "«,A8, ,H IS NOT A DEPT. USED IN THIS FILE') 
 
 GO TO 3000 
 270 I=KCL 
 
 IEND=KOL 
 
71 
 
 GO TO 17 
 ii 
 
 " COURSES AFTER REACHING A SPECIFIC ACADEMIC STATUS 
 ii 
 
 300 DO 350 K=l,4 
 
 IF (OUT.EQ.B(K) ) GO TO 370 
 350 CONTINUE 
 
 GO TO 2800 
 370 K=GIB2(K+2) 
 
 IF (K.EQ.O) K=N0W+10 
 
 IF (K.GT.DDATE) DDAT E=K 
 
 GO TO 17 
 •i 
 
 " COURSES TAKEN DURING OR AFTER A GIVEN SEMESTER 
 
 n 
 
 400 CALL TIMES (K, LL INE,2 1,31 , KR , ERROR, £3000) 
 
 IF (K.GT.DDATE) DDATE=K 
 
 GO TO 17 
 •i 
 
 •• COURSES WITHIN THE LAST SC-MANY HOURS 
 
 GIB2I15) IS THE NUMBER OF COURSES COMPLETED 
 
 •i 
 
 500 IF (GIB2(15).EQ.0) GC TC 3000 
 FINI=0 
 H=0 
 HR=AUX*2 
 
 FIND LAST HR HOURS WORTH OF CREDIT BY SEARCHING 
 BACKWARDS IN TIME THROUGH THE FILE. 
 INITIALIZE CUTOFF DATE TO PRESENT. 
 SET END TO STUDENT'S ENTRY DATE 
 
 
 CUTOFF=NOW 
 
 
 
 END=GIB2(2) 
 
 
 510 
 
 DO 525 J=i,IEND 
 
 K2 = (DBL0CK(3, J )-l)*5*7 
 
 
 •i 
 
 DO 525 Kl=7,K2,5 
 
 
 •• 
 
 PEJECT THIS COURSE IF 
 
 NOT 
 
 ii 
 
 REJECT THIS COURSE IF 
 
 NOW 
 
 it 
 
 M 
 
 PEJECT THIS COURSE IF 
 
 NOT 
 
 TAKEN IN SEMESTER AT DATE CUTOFF 
 
 IN PROGRESS 
 
 YET INCLUDED IN GP A 
 
 IF (08LrCK(Kl*l, J). NE. CUTOFF) GO TO 520 
 
 GRADE=DBL0CK(K1+3,J) 
 
 IF (GRADE. EQ. IP) GO TO 520 
 ii 
 
 " LOOK FOR * IN RIGHT BYTE 
 
 M 
 
 I JK =GR ADE- (GRADE/ 256-25 5*2 56- 1)*2 56 
 
 IF (IJK.EQ.92) GO TO 520 
 
 H=H+DBL0CK(K1*2, J) 
 •i 
 
 " GONE BACK FAR ENOUGH IF H.GE.HR OR 
 
 H IF HAVE BACK-TRACKEC THROUGH TO ENTRY DATE 
 
 H (I.E., CUTOFF. EO. END) 
 
 H 
 
 520 IF (CUTOFF. LE. END) GC TC 522 
 
72 
 
 IF (H.LT.HR) GO TO 525 
 522 FINI=1 
 
 525 CONTINUE 
 
 IF (FINI.EQ.O) GO TO 540 
 
 IF (CUTOFF. GT.DDATE) DDATE=CUTOFF 
 
 GO TO 17 
 540 CUT0FF=CUT0FF-1 
 
 IF CMOD(CUTOFF,10).EQ.O) CUT0FF=CUT0FF-7 
 
 GO TO 510 
 it 
 
 " ADVANCED LEVEL COURSES 
 
 N 
 
 600 IF (AUX.LE.O) GO TO 2800 
 
 LEVEL=AUX 
 
 GO TO 17 
 ft 
 
 " INCLUDE NEW GRADES IN GPA 
 
 1000 IF (I.NE.O) GO TO 1900 
 
 1 = 1 
 
 T=l 
 
 IACV=0 
 
 GO TO 1900 
 n 
 
 " UPCATE GIB4, GIB2 
 
 n 
 
 1050 GIB4(2)=GIB4(2)+H0URS 
 
 GIB4( 1)=GIB4( l)+H0URS-IFAIL*.5 
 
 GIB4(3)=GIB4(3)+IADV*.5 
 
 GIB4(8)=GIB4< 8)+SUMl*.5 
 
 IF (GIB4(2).NE.0.0) CI B4( 6 )=GIB4( 8) /GI B4< 2 ) 
 
 GIB41 10) = GIB4(10)«-SUP3*.5 
 
 GIB4(9)=GIB4(9)+SUM4*.5 
 
 IF (GIB4(9).NE.0.0) GI B4( 7) =GI B4( 10 )/G I B4( 9) 
 
 GIB2< 15)=GIB2( 15)+NUM 
 
 GIB2( 14)=GIB2( 14)*NMAJ0R 
 
 GIB2(13)=GIB2(13)+NUN 
 
 PP=0 
 
 T = 2 
 
 H 
 
 " UPDATE DEPARTMENT INFORMATICN BLOCKS 
 
 ti 
 
 1 = 1 
 
 1070 SUM1=0 
 
 SUM2=0 
 
 NUMBER=0 
 
 IFAIL=0 
 
 IF (DEPTH J.EQ.l) GO TO 2050 
 
 GO TO 1200 
 1080 DBLOCK( 1, I )=SUM2-IFAIL 
 
 DBLOCK (2, I ) = DBLOCK( 1, I ) 
 
 CBL0CM5, I ) = SUM1 
 1200 1=1+1 
 
 IF (I.LE.IENO) GO TO 1070 
 
 GO TO 3000 
 
 H 
 
 " FIND GPA OF SEARCH CLASS 
 
73 
 
 « ITCP=3 -> NOT RESTRICTED TO MAJOR AND/OR MINOR 
 
 M 
 
 1900 IF (DEBUG. EO.l) WR ITE( 6, 19101 LE VE L» DDATE, I TOP , IBOT , I , I END 
 1910 FORMATP LIMITS: LEVEL = , t I3, t DDATE=«,I5,X 
 
 • ITOP-SIli 1 IB0T=»,I1,» DEPTS "t^t" TO »,I2) 
 2000 IF (IT0P.EQ.3) GO TO 2050 
 
 i* 
 
 " RIGHT TYPE? 
 n 
 
 S=DBL0CK(4,I) 
 
 IF (S.LT.ITOP) GO TO 2700 
 
 IF (S.GT.IBOT) GO TO 2700 
 
 2050 IF (DEBUG. EQ.l) WRIT E(6 ,205 1) DCODEU),I,% 
 
 (DBL0CK(K3,I),K3=1,6) 
 
 2051 FORMATM NEW DEPT .= • , A8, • CBLOCK ( l->6, • , 12, • )= • » % 
 
 614) 
 K2=(DBL0CK(3, M-l )*5+7 
 DO 2500 K1=7,K2,5 
 K3=KH-4 
 
 IF (DEBUG. EQ.l) WRIT E(6, 2055) < DBLPCK ( K4 t I ) »K4=K1 ,K3) 
 2055 FORMATt* COURSE = ' , I 3 ,» DATE= , ,I5,» HOUR S*2= • , 12 ,% 
 
 • GRADE=•,A2,• CCDE=»,I3) 
 n 
 
 w WAS THE COURSE TAKEN TCC LONG AGO? 
 ti 
 
 IF (DBL0CK(KH-1,I).LT.CCATE) GO TO 2500 
 n 
 
 M IS THE COURSE TOO LCW-LEVEL? 
 it 
 
 LVL=DBL0CK(K1, I) 
 
 IF (LVL.LT. LEVEL) GO TO 2500 
 
 GRADE=DBL0CK(Kl+3, I ) 
 
 DO 2100 J=l,6 
 
 M 
 
 " HAS THIS COURSE BEEN INCLUDED IN A GPA YET? 
 M (IS IT A t B,C,D,E,OR AB?) 
 
 IF (T.EQ.l ) GO TO 2080 
 
 2060 IF (GRADE. NE.G( J) ) GO TO 2100 
 ti 
 
 " THIS COURSE BELONGS IN THE DESIRED GPA 
 
 it 
 
 H=DBL0CK(K1+2,I ) 
 SUM1 = SUM1«-<J-1)*H 
 SUM2=SUM2+H 
 
 IF (J.LT.3) IFAIL=IFAIL*H 
 NUMBER=NUMBER+1 
 IJK=G( J) 
 
 IF (J. EO.l) IJK=AB 
 
 IF (PP. EO.l) WRITE(6,2063) DCODE (I ) » DBLOCK (Kl , I ) ♦ I JK 
 2063 FORMAT!* USING •,A6,I3,« WITH GRADE »tA2) 
 IF (T.NE.l) GO TO 2500 
 
 THESE ARE JUST-RECEIVED GRADES — CHANGE "*" TO " » 
 
 DBLCCMKl + 3,1 )=G( J) 
 DEPT( I)=l 
 
74 
 
 IF (LVL.GE.200) IADV = IADV«-H 
 
 H 
 
 " UPDATE HOURS AND GRADES IN MAJOR, IF APPROPRIATE 
 
 IF (DBL0CM4, I) .NE.2 I GO TO 2500 
 
 SUM3=SUM3+(J-1)*H 
 
 SUM4=SUM4+H 
 
 NMAJOR=NMAJOR-H 
 
 GO TO 2500 
 2080 GRADE=GRADE-28 
 
 GO TO 2060 
 2100 IF (GRADE. LT. DBLOCK ( Kl+3, I » ) GR ADE=DRLOCK( Kl+3 , I ) 
 2500 CONTINUE 
 
 IF (T.EQ.2) GO TO 1080 
 2700 1=1*1 
 
 IF (I.LE.IEND) GO TO 2000 
 
 1=1-1 
 
 IF (SUM2.EQ.0) GO TO 2520 
 
 GPA=SUM1/FL0AT(SUM2) 
 
 H0URS=SUM2*.5 
 2520 MJM=NUMBER 
 
 IF (T-l) 3000,1050, 1C80 
 2800 K=MM+2 
 
 WRITE<6,2810) OUT,K 
 2810 FORMAT!* " , ,A8,« , » IS AN IMPROPER RESPONSE FOP FIELD ',11) 
 2990 ERR0P=1 
 
 3000 IF (PRINT. EQ.l) WR IT E(6 , 3005) GPA, HOURS, NUM 
 3005 FORMATS LEAVING CALC GPA=»,F5.3,» HOURS*' ♦ F6. 2 ,* 
 • NUM=»,I3) 
 
 CALL CLCSE(12) 
 
 RETURN 
 
 END 
 
 « 
 
 PROCESSOR USERA CCMFARES THE GPAS OF TWO SETS OF STUDENTS — 
 
 H THOSE WHO TOOK A SPECIFIED COURSE BEFORE TAKING OTHER COURSFS 
 
 w IN A GIVEN DEPARTMENT, AND THOSE WHO DID NOT TAKE IT 
 
 SUBROUTINE USERA ( ERR CR , FI N I ) 
 
 INTEGER*2 LL I NE ( 72 ) , FEADER ( 32 I , CHEKOV( 12 ) , GI B2 ( 20) ,S 
 
 DBL0CK(56,12) 
 INTEGER ERR OR, COL/- 1/, DEBUG/1/, SET, STAR T/0/,N( 2) /2*0/,% 
 
 LL(3) ,FINI 
 REAL*8 FILE(2)/«FILEl f , , FILE2«/,GIB8(5) , VEC( 260 ) , SLAVE ( 4 ) ,f 
 
 N0DES(4),VERB(2)/»fcITH« , • WITHOUT • /,DCODE ( 12 ) ,DEPT1,DEPT2 
 PEAL GIB4( 16) , G( 2 ) /2 *0. /,H ( 2 ) /2*0. / ,SDEV( 2 )/2*0./ 
 COMMON HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,S 
 
 VEC, SLAVE, NODES, LL 
 IF (DEBUG. EO.l) WRITE(6,5) FINI 
 FORMAT! • *ENTERING USERA — FINI-SU) 
 
 IF FINI = I THEN THIS 
 GO CALCULATE THE MEAN 
 
 IS THE STATISTICS WRAPUP CALL 
 
 AND THE STANDARD DEVIATION HOURS*GRADES 
 
 IF (FINI. EO.l) GO TO 1000 
 
75 
 
 IF (START. NE.O) GO TC 20 
 
 M 
 
 " READ THE NAMES OF THE COURSE AND DEPARTMENT IN QUESTION 
 
 m 
 
 CALL OPEN( 12, 'BUFFER •»• INPUT* ) 
 READ(12,6)LLINE 
 
 6 F0RMAT172A1) 
 
 CALL C0NVRT(DEPT1,5,LLINE,8,JUNK,31,ERR0R,£2150I 
 
 CALL CCNVRT(DEPT2,4,LLINE,8,NUM,41,ERR0R,£2150> 
 •i 
 
 " THE REMAINING BUFFERED INFCRMATION IS FOR PROCESSOR CALC 
 
 " ADDING A CALC-FORM COMMAND FOR DFPT. DEPT1 
 
 M CALC IGNORES THE FIRST LINE IN THE BUFFER 
 
 t» 
 
 CALL CL0SE(121 
 
 CALL 0PEN(12, 'BUFFER S'MOD* ) 
 
 WRITE<12,7) DEPTl 
 
 7 F0RMAT(10X,»DEPT' ,6X,A8) 
 •i 
 
 " CREATE FILE1 £ FILE2 TO CLEAR THEM OUT 
 
 " GPA*HOURS FOR STUDENTS WITHOUT TEST COURSE GO IN FILEl 
 
 " GPA*HOURS FOR STUDENTS WITH TEST COURSE GO IN FILE2 
 
 DO 15 1=1,2 
 
 CALL OPEN( I,FILE{I», f OUTPUTM 
 
 15 CALL CLOSE(I) 
 
 START=1 
 
 20 J=l 
 
 if 
 
 •• HERE, K IS THE NUMBER CF DEPARTMENT BLOCKS USED 
 
 " BY THE CURRENT STUDENT 
 
 N 
 
 K=GIB2(10) 
 
 IF (K.EQ.O) GO TO 3000 
 
 DO 30 1 = 1, K 
 
 IF (OCODEC D.EQ.DEPT2) GO TO 35 
 
 30 CONTINUE 
 it 
 
 " HAS TAKEN NO COURSES IN THE SAME DEPARTMENT AS THE TEST COURSF 
 •t 
 
 GO TO 100 
 35 KK=DBL0CK(3,I) 
 
 DO 37 M=1,KK 
 
 IF (DBLOCK(2*M*5,I ).EO.NUM) GO TO AO 
 37 CONTINUE 
 
 N 
 
 " HAS NOT TAKEN THE TEST COURSE 
 
 •• 
 
 GO TO 100 
 n 
 
 w HAS TAKEN THE TEST CCURSE 
 
 M 
 
 40 J=2 
 
 H 
 
 " IF THE STUDENT HAS THE GIVEN DEPARTMENT IN THE SAME COLUMN AS THE 
 
 H LAST STDUENT FILE SEEN BY CALC, THEN THE SEARCH STRATEGY USED BY 
 
 " CALC DOES NIT CHANGE — SET=1 TELLS CALC TO LEAVE THE BUFFER 
 
76 
 
 m CLOSED ANO REUSE ITS OLD SEARCH STRATEGY 
 
 M 
 
 100 SET=1 
 
 00 130 1=1, K 
 
 IF IDC0DE1 II.EQ.DEPT1) GO TO 150 
 
 130 CONTINUE 
 it 
 
 STUDENT HAS NOT TAKEN ANY COURSES IN THE GIVEN DEPARTMENT 
 
 N 
 
 GO TO 3000 
 
 N 
 
 " IF I=COL THEN LEAVE SET = i 
 
 w 
 
 150 IF U.EQ.COL) GO TO 170 
 
 SET = 
 
 COL=I 
 •i 
 
 M FIND THE DESIRED GPA 
 
 ii 
 
 170 CALL CALCIGPA, HOURS, ERROR, NUMB, 1, SET) 
 •• 
 
 H FCRGET ABOUT THIS STUDENT IF HE HASN'T TAKEN ANY COURSE 
 
 " OF INTEREST IN THIS COMPARISON 
 
 H 
 
 IF (NUMB.FO.O) GO TO 3000 
 
 GR=GPA*HOURS 
 
 G( J)=G(J)*GR 
 
 H(J)=H{J)+HOUPS 
 
 N< J)=N(J)*i 
 
 SAVE THIS STUDENT'S GRADES*H0URS FOR USE IN FINDING THE STANDARD 
 DEVIATION AFTER THE MEAN IS KNOWN 
 
 CALL OPENl J,FILE( J), 'MCDM 
 
 WPITE(J,200) GR 
 
 200 F0RMAT(F10.3) 
 
 CALL CLOSE(J) 
 «i 
 
 GO GET THE NEXT STUCENT FILE 
 n 
 
 GO TO 3000 
 
 M 
 
 w FIND THE AVERAGE COMPOSITE GPA FOR EACH CLASS 
 
 N 
 
 1000 IF (N(l).NE.O) G(l)=G( 1)/N(1) 
 IF (N(2).NE.O) G(2)=G(2)/N(2) 
 DO 1500 1=1,2 
 CALL OPEN( I,FILE(I ), MNPUT* ,K) 
 
 FIND THE STANDARD DEVIATICNS FOP EACH CLASS 
 
 SEE IF FILE( I ) EXISTED 
 
 IF (Nl I ).E0.0) GO TO 1500 
 
 K=NU) 
 
 DO 1400 J=1,K 
 
 REACH ,200, EN0=1500I GR 
 
77 
 
 SDEV( I) = SDEV( 1 1 -KG ( I )-GR)**2 
 1400 CONTINUE 
 1500 CALL CLOSE(I) 
 
 DO 2000 1=1,2 
 
 SDEV< I)=SQRT(SDEV(I) ) 
 2000 WRITE(6,2100) N( I ) , VERB (I) , DEPT2 , NUM,G ( I ), SDEVC I) 
 2100 F0RMAT(1X,I4,» STUDENTS ',A8,A5,I3/' GRADES*HOURS ( AVE) =• ,% 
 
 F8.3,5X, 'STANDARD CEVIATICN=' ,F8.3) 
 ii 
 
 " RE-INITIALIZE THE PROCESSOR FOR FURTHER USE 
 
 n 
 
 START=0 
 
 DO 2140 1=1,2 
 
 N(I)=0 
 
 GU) = 0. 
 
 SDEVU )=0. 
 
 H( I ) = 0. 
 2140 CONTINUE 
 2150 CALL CL0SE!1,2,12) 
 
 IF (ERROR. EQ. 10) ERR0R=1 
 3000 IF (DEBUG. EQ.l) WRIT E( 6,3200 ) ERROR 
 3200 FORMAT! • *LEAVING USERA — ERR0R=',I1) 
 
 RETURN 
 
 END 
 n 
 
 •• 
 
 M 
 It 
 
 SUBROUTINE DUD 
 RETURN 
 
 END 
 n 
 n 
 ii 
 « 
 
 H OLF SUBPROGRAMS 
 
 H 
 
 w SUBROUTINE LOAD LOAOS FILE NAMED NAME INTO DIRECTORY SELECTED 
 
 « BY LEVEL. IF NAME=LAST( LEVEL ) , PROCESSING IS SKIPPED 
 
 " IF C0PY=1, FILE NAMED LAST(LEVEL) IS COPIED TO DISC BEFORE FILE 
 
 " NAMED NAME IS LOADEC INTO CORE 
 
 •i 
 
 SUBROUTINE LO AC ( LEV E L, NAME, COPY, L AST, VECTOR ,L ENGTH, NAME2,KARD ) 
 
 REAL*8 NAME,VECT0R(260) ,LAST( 4 ) ,NAME2 
 
 INTEGER COPY, Ll(3)/1, 201, 241/, L3(3) /O, 20,0/, LENGTH(3) , DEBUG/0/ 
 
 IF (DEBUG. EQ.l) WRITE(6,1) LEVEL, NAME 
 1 FORMAT! 1 CENTERING LCAC — LEVEL=',I1,% 
 
 •, TO FIND »,A8) 
 
 IF (NAME.EQ.LAST(LEVED) GO TO 100 
 
 IF (KARD.EQ.l) WRITE(6,4) LEVE L, NAME2 , NAME 
 4 FORMAT!' NOW LOADING LEVEL-', II, • DIRECTORY • , A8, • {',A8,')') 
 
 J=L1(LEVEL) 
 
 IF (COPY.EQ.O) GO TO 50 
 
 IF (DEBUG. EQ.l) WRITE(6,8) LAST(LEVEL) 
 8 FORMAT!' MUST COPY FILE *,A8,» FIRST') 
 
 CALL 0PEN(1,LAST(LEVEL), 'OUTPUT* ) 
 
 K=J*-L3( LEVEL) +L ENGTH (LEVEL )-l 
 
78 
 
 WR I TEC 1, 10) LENGTH ( LEVEL) ,( VECTOR (I >,I=J,K) 
 10 F0RMATCA4/U0A8)) 
 
 CALL CLOSE(l) 
 
 COPY=0 
 50 CALL OPENCi, NAME, 'INPUT' ) 
 
 READll,55) M 
 55 F0PMATCA4) 
 
 LENGTH(LEVEL)=M 
 
 K=J+M-1+L3(LEVEL) 
 
 IF (M.EO.O) K=J+L3(LEVEL) 
 
 RE AC (1,60) (VECTOR! I) ,I=J,K) 
 60 F0RMATU0A8) 
 
 LAST(LEVEL)=NAME 
 100 IF (DEBUG. EQ. I) WRITE(6,105) 
 105 FORMATS ^LEAVING LCAD' ) 
 
 CALL CLOSE(l) 
 
 RETURN 
 
 END 
 •• 
 
 ti 
 
 N 
 W 
 
 M SUBROUTINE OUTPUT PRINTS STATUS OF SYSTEM JUST BEFORE 
 " INVOKING (OR SKIPPING) THE CURRENT PROCESSOR 
 
 SUBROUTINE OUTPUT (I , PROC, BATCH, DUPL IC , LAST , J ,GI B8,% 
 LINE, HEADER, I START ,LEN ,NAME2 ,0K) 
 
 REAL*8 GIB8(5) , XXX ,YYY, PROC , DUPL IC (4) , LAST (4) ,NAME2,S 
 KIND(3)/'CRRCLM« , • ADV ISOR ',' STUDENT • / 
 
 INTEGER*2 HEADER ( 32 ) ,A ( 4 ) , B ( 4) /**• • / , LINE ( 72 I ,S 
 QUOTE/""/ 
 
 INTEGER BATCH, DEBUG/C/, OK 
 
 EQUIVALENCE ( YYY,A( 1)), (XXX, BCD) 
 
 0K = 
 
 IF (DEBUG. EQ.l) WRITE(6,1) I 
 1 FORMAT!' *ENTERING OLTPUT — ERR0R=',I2) 
 
 K=I + 1 
 
 IF (K.GT.2) WRITE(6,5) 
 5 FORMATCOSKIPPING PROCESSING STEP') 
 
 GO TO (10, 10, 30, 50, 60, 67, 70, 80, 80, 90, 67, 100, 110), K 
 10 WRITE(6,15) PROC 
 15 FORMAT! 'OABOUT TO ENTER PROCESSOR »,A8) 
 
 IF (K.EQ.i) WRITE(6,17) HE ADER, DUPL IC ( 3 ) 
 17 FORMAT!' STUDENT: ',22A1,' !',A8,')') 
 
 IF (K.EQ.2) WRITE(6,20) 
 20 FCPMATdX, 'STATISTICS WPAPUP') 
 
 CK=1 
 
 GO TO 1000 
 30 WRITE(6,40) 
 40 FORMAT!'*-' ,24X, • — TOC MUCH INPUT') 
 
 0K = 2 
 
 GO TO 1000 
 50 YYY=GIB8(2) 
 
 B(l)=A!2> 
 
 B(2)=A(3) 
 
 B!3)=A{4) 
 
 WRITE (6,55) (HEADER (K),K = 10, 29) , XXX, GIBS 13) 
 
79 
 
 55 FORMAT!' FILE BELONGS TO I ,20A1,« CRRCLM= • t A8 , • ADVI SOR = * , A8) 
 
 GO TO 1000 
 60 WRITE(6,65) ( HE AOER ( M) , M=l , 9 ) , GI B8 (3 ) 
 
 65 F0RMAT(1X,9A1,« WAS ACCESSED ONLY BECAUSE SAB,' ADVISES • ,% 
 •SEVERAL CURRICULA.*) 
 
 GO TO 1000 
 
 67 IENDMSTART-H.EN-1 
 
 IF CK.E0.6) WRITE(6,68) (LINE! L ) , L=I ST ART, I ENO) , QUOTE 
 
 68 FORMAT( •♦ i ,26X,»CANNCT TRANSLATE "•,21AD 
 0K = 2 
 
 GO TO 1000 
 70 K=BATCHH-1 
 
 IF (K.EQ.O) K=l 
 
 WRITE16.75) KIND(K) 
 75 FORMATP IMPROPER COMMAND — SPECIFY AT OR BELOW , ,A7, 1 LEVEL') 
 
 0K=2 
 
 GO TO 1000 
 80 K=J 
 
 IF (K.EQ.2) K=4 
 
 WRITE(6,85) OUPLIC(J),J,LAST(J) 
 85 FORMATP FILE ■ , A8 , • IS NOT IN LEVEL-SU.* DIRECTORY ',A8) 
 
 GO TO 1000 
 90 WRITE(6,95)(LINEIK) , M21 ,29) , NAME2 
 
 95 FORMATC FILE »,9A1,' IS NCT IN LEVEL-3 DIRECTORY «,A8) 
 
 GO TO 1000 
 100 WRITE(6,105) 
 105 FORMATS YOU MUST SPECIFY A NFW PROCESSOR') 
 
 0K = 2 
 
 GO TO 1000 
 110 KK=J+1 
 
 WRITE(6,115) KK,NAME2 
 115 FORMATP LEVEL-*. lit* DIRECTORY '.AS,' IS EMPTY*) 
 1000 IF (DEBUG. EQ.l) WRI TE(6 , 10 10 ) 
 1010 FORMATP *LEAVING OUTPUT*) 
 
 RETURN 
 
 END 
 •t 
 
 M 
 
 •I 
 tl 
 
 " FUNCTION COMP: 
 
 " RETURNS CCMP= I IF KEY.GT.XMBER 
 
 " RETURNS COMP = IF KEY.EQ.XMBER 
 
 " RETURNS C0MP=-1 IF KEY.LT.XMBER 
 
 n 
 
 INTEGER FUNCTION COMP( PASS . LEVEL ♦ XMBER, KFY ) 
 INTEGER PASS,DEBUG/0/,T0P(2)/18,l/,B0T(2)M4,17/,l 
 
 MATRIX(4),BEGIN(4)/4,8,12,16/ 
 INTEGER*2 DIGIT( 16 ) , tsUM ( 44 ) / • $ * , * • , * 1 • , • 2* , * 3* . * 
 •4*,*5',*6*,*7*,*8*,*9*,*A*,*B*,*C*,*D*.'E*,*F*.I 
 * * , *A* ,*B* ,*C* ,*C*,'E* ,*F* ,*G* .*H* ,» I* , *J* 
 
 •N'.'O'.'P'.'O'.'R'.'S'.'T'.^U'.'V* 
 
 REAL*8 KEY, XMBER, X.Y 
 
 EQUIVALENCE(X,MATRIX(1) ),( Y, MATRIX! 3) ) 
 IF (DEBUG. EQ.l) WRITE(6,5) XMBER, KEY 
 FORMAT( f *ENTERING CCMP— XMBER= • , A8, % 
 
80 
 
 • KEY=«,A8) 
 
 COMP=0 
 
 K=3 
 
 IF (PASS.EQ.l) GO TO 20 
 
 PASS=1 
 
 K=l 
 
 KK=MOD!LEVEL,2)«-l 
 
 ISTART=TOP!KK) 
 
 IEND=BOT<KK) 
 
 X=KEY 
 20 Y=XMBER 
 
 DO 60 I=K,4 
 
 KKK=BEGIN<I ) 
 
 MULT=0 
 
 IF (MATRIX! I) .LT.O) *ULT=-i 
 
 DI GIT (KKK)=MOD (MATRIX! I ), 256 )* 256*64 
 
 MATRIX! I ) = MATRIX(I )/ 256+255*^ULT*l 6777 2 16 4-MULT 
 
 KKK=KKK-1 
 
 00 60 J=l,3 
 
 DIGIT! KKK)=MOD! MATRIX! I ) , 256) *256+64 
 
 MATRIX! I )= MATRIX! I J/256 
 60 KKK=KKK-1 
 
 00 100 1=1,8 
 
 DO 70 J=ISTART, IEND 
 
 IF (DIGITU).EQ.NUM! J) ) GO TO 75 
 70 CONTINUE 
 75 JJJ=I+8 
 
 00 80 JJ=ISTART,IEND 
 
 IF IDIGITUJJ ).EO.NUM!JJ) I GO TO 85 
 80 CONTINUE 
 85 L=J-JJ 
 
 IF il.EQ.O) GO TO IOC 
 
 COMP=IABS!L)/L 
 
 GO TO 150 
 100 CONTINUE 
 
 150 IF (DEBUG. EQ.l) WRITE!6,170) COMP 
 170 FORMATS *LEAVING COKP — CCMP=«,I2) 
 
 RETURN 
 
 END 
 
 SUBROUTINE RENAME RIGHT-SHIFTS XXX BY TWO BYTES AND 
 INSERTS CHAR INTO THE RESULTING VACANCY 
 
 IF (DEBUG. EQ.l) WPITE(6,1) XXX, CHAP 
 
 FORMAT!* *ENTERING RENAME — XXX= i ,AP, 1 , CHAR=»,A2) 
 
 XXXX=XXX 
 
 MULT1=0 
 
 MULT2=0 
 
 IF (MATRIX! 1) .LE.O) MULT1=-1 
 
 IF (MATRIX(2).LE.O) FULT2=-1 
 
 MATRIX!2)=MATRIX!2)/65 5 36+£5536*!6 5535*MULT2S 
 
 ♦ MOD I MATRIX! 1), 65 5 26 I )+MULT2 
 MATRIX( 1)=MATRIX! 1 )/ (5 536+6 55 36*! 6 5535 *MUL TH-CHAR )♦ MULT 1 
 XXX=XXXX 
 
81 
 
 10 
 
 ft 
 
 IF (DEBUG. EQ.l) WRITE!6,10) XXX 
 FORMAT!' *LEAVING RENAME — XXX=',A8) 
 RETURN 
 
 n 
 it 
 w 
 ii 
 
 SUBROUTINE REVISE INSERTS IDELETES) KEY1 FROM DIRECTORY! LEVEL ) 
 IF INCR=+1<-1). IF LEVEL=2, IT ALSO INSERTS (OELETES) KEY2 
 
 SUBROUTINE REV I SE( VECTOR ,LENGTH,KEY1, KEY2, PTR , LEVEL ,% 
 INCR, LAST, ERR, NAME2) 
 
 REAL*8 VECT0R(260),L/SST(A) , CHOICE! 2)/' INSERT', 'DELETE* /,? 
 KEY1,KEY2, BLANK/' »/,NAME2 
 
 INTEGER LENGTH!3),DUP,PTR,EPR,L1(3)/1,201,241/,L3(3)/0,20,0/,S 
 LEN!3)/200,2Q,2G/,CEBUG/0/ 
 
 KK=L3ILEVEL) 
 
 IT0P=L1(LEVEL) 
 
 KM=ITOP+LENGTHILEVEL I+L3! LEVED-1 
 
 IBOT=KM-KK 
 
 IF (DEBUG. EQ.O) GO TC 10 
 
 K=l 
 
 IF UNCP.EQ.-l) K = 2 
 
 WRITE (6,5) CHOICE! K) ,KEY1 , LEVEL , LAST ! LEVEL ), PTR 
 5 FORMAT!' *ENTERING REVISE — TO »,% 
 
 A7,A8/* IN LEVEL-* #11,* 
 • DIRECTORY ',A8,» AT POSITION ',13) 
 
 DO 7 I=ITOP,KM 
 7 IF (VECTOR(I).NE. BLANK) WRITE(6,297) I, VECTOR! I) 
 
 10 IF (INCR.EO.-l) GO TC 100 
 
 IF (LENGTH (LEV EL). ECO) GO TO 30 
 
 IF (LENGTH(LEVEL) . EQ .LEN( LEVEL )) GO TO 250 
 
 DO 20 I=PTR,IBOT 
 
 K=IBOT+PTR-I 
 
 KK=K+L3(LEVEL) 
 
 IF (LEVEL. EO. 2) VECTOR ( KK + 1 )= VECTOR (KK ) 
 20 VECTPR(K+1)=VECT0R(K) 
 
 30 VECT0R(PTR)=KEY1 
 
 IF (LEVEL. EQ. 2) VECTOR ( PTR +L31 LEVEL ) )=KEY2 
 
 GO TO 270 
 100 DO 150 I=PTR,IBOT 
 
 KK=I*L3(LEVEL) 
 
 VECTOR (KK ) = VECTOR ( KK+1 ) 
 150 VECTOR! I )= VECTOR! 1*1 ) 
 
 GO TO 270 
 250 ERR=1 
 
 INCR=0 
 
 WRITF(6,260) NAME2 ,L AST t LEV EL ) ,KEY1 
 260 F0RMAT(1X,A9, ' ( • ,A8, •) IS FULL — CAN"T ADD ',A8) 
 2 70 LE NGTH ( LEVEL )=LENGTMLEV EL ) + I NCR 
 
 IF (LENGTHILEVEL).NE.O) GO TO 285 
 
 WRITE (6,280) L EVEL ,NAME2, LAST I LEVEL ) 
 280 FORMAT!' LEVEL-', II, • DIRECTORY ',A8,' !',A8,') IS NOW EMPTY') 
 
 KLH=L1!LEVEL) 
 
 VECTOR IKLH)=BLANK 
 
 VECT0RJKLH + L3ILEVEL) )=BLANK 
 
82 
 
 285 KM=KM+INCR 
 
 IF (DEBUG. EQ.O) GO TC 300 
 
 WRITE(6,290) ERR 
 290 FORMATS *LEAVING REVISE — ERROR**,!!) 
 
 DO 295 I=ITOP,KM 
 295 IF (VECTOR! I). NE. BLANK) WRITE(6,297) I.VECTOR(I) 
 297 FORMAT(« ( • , I 3, • ) • , 5X, A8) 
 300 RETURN 
 
 END 
 
 " SUBROUTINE BISECT DCES BINARY SEARCH FOR KEY IN DI RECTORY( LEVEL ) 
 
 M IF KEY IS FOUND, CUP=1 AND PTR=POSITION IN FILE; 
 
 ■ IF KEY IS NOT FOUND, DUP=0 AND PTR=POINT OF INSERTION IN FILE. 
 
 ii 
 
 SUBROUTINE BI SECT ( VECTOR .LENGTH, KEY, DUP,PTR,L EVEL , LAST ) 
 
 REAL*8 VECT0R1260) , KEY, LASTU), BLANK/ 1 •/ 
 
 INTEGER DUP, PTR, L ENGTH { 3), TOP (3)/ 0,200, 240 /,COMP, DEBUG/0/,? 
 
 L3(3)/0,20,0/ 
 IPASS=0 
 DUP=0 
 
 ITOP=TOP(LEVEL) 
 IB0T=IT0P+LENGTH(LEVEL)+1 
 IF (DEBUG. EO.O) GO TC 10 
 J=IT0P+1 
 
 K=IB0T-1+L3(LEVEL) 
 
 WRITE(6,5) KEY, LEVEL ,LAST( LEVEL) 
 5 FORMAT! • *ENTERING BISECT — SEARCHING FOR •,? 
 
 A8,/« IN LEVEL-'. lit 1 DIRECTORY »,A8) 
 DO 7 I=J,K 
 
 7 IF (VECTOR(I).NE. BLANK) WRITE(6,8) I,VECTOR(I) 
 
 8 FORMAT!* (»,I3,«) «,A8) 
 
 10 IF (IT0P*-1.GE.I80T) GO TO 120 
 
 PTR=(IT0P*IB0T)/2 
 
 IF (CCMPUPASS, LEVEL ,V ECTOR ( PTR ) , KEY)) 20,100,30 
 20 IBOT=PTR 
 
 GO TO 10 
 30 ITOP=PTR 
 
 GO TO 10 
 100 DUP=l 
 120 IF (DUP.EO.O) PTR=IBCT 
 
 IF (DEBUG. EQ.O) GO TC 300 
 
 WRITE(6,200) 
 200 FCRMAT(» ^LEAVING BISECT — •) 
 
 IF (DUP.EO.O) WRITE(6,210) KEY, PTR 
 210 F0PMAT(»+«,30X,A8,' BELONGS AT POSITION ',13) 
 
 IF (DUP.EQ.l) WRITE(6,220) KEY, PTR 
 220 FORMAT! •♦• ,30X,A8, • FOUND AT POSITION ■ v I 3 1 
 300 RETURN 
 
 END 
 
 SUBROUTINE TIMES CONVERTS FIELDS STARTING AT PI AND P2 
 
83 
 
 " IN LLINE TO A COMPOSITE DATE INDICATING BOTH 
 
 " YEAR AND SEMESTER. THE 1ST FIELD IS A SEMESTER 
 
 •• NAME AND THE 2ND FIELD IS A YEAR NUMBER. 
 
 N 
 
 SUBROUTINE TI MESCDAT E,L INE ,P1 , P2, FUTURE ,ERROR , *) 
 
 INTEGER Pit P2 , FUTURE, ERROR, DEBUG/O /,DA TE,L INE*2( 72) 
 
 REAL*8 SEASON, CHOICE (4) /'SPRINGS 'SUMMER* , • FALLS • AUTUMN' /, OUT 
 
 IF (DEBUG. NE. 1) GO TC 10 
 
 DATE=0 
 
 Kl=Pl+7 
 
 K2=P2+3 
 
 WRITE (6,5) (LINE! I ) , I=P2 ,K2 ) , ( LINE ( I),I=P1,K1) 
 5 FORMAT!' *ENTERING TIMES',? 
 
 • YEAR=' ,4A1,5X,'SEASCN=',8A1) 
 10 CALL C0NVRT(SEAS0N,5 ,L INE, 8, JUNK, PI , ERROR, G990) 
 
 DO 30 1=1,4 
 
 IF (SEASON. EQ. CHOICEU) ) GO TO 50 
 30 CONTINUE 
 
 WRITE(6,35) SEASON 
 35 FORMATC W ',A8,' M IS NOT A VALID SEMESTER NAME') 
 
 ERR0R=1 
 
 GO TO 1000 
 50 IF (I.EQ.4) 1=3 
 
 CALL C0NVRT(OUT,6,LINE,4,DATE,P2,ERROR,£990) 
 
 DATE=DATE*10-H 
 
 FUTURE=0 
 
 CALL OPEN( 1, 'DATES' , 'INPUT' ) 
 
 READ(i,60) NOW 
 60 F0RMATII5) 
 
 K= DATE-NOW 
 
 IF (NOW. NE. DATE) FUTURE=I ABS( K )/K 
 
 GO TO 1000 
 990 ERROR=i 
 
 1000 IF (DEBUG. EO.l) WR IT E( 6, 1005 ) DATE, FUTURE 
 1005 FORMATC LEAVING TIMES — YEAR*' ,15," FUTURE = ',I2) 
 
 CALL CLOSE( 1) 
 
 IF (ERROR. NE.O) RETUPN 1 
 
 RETURN 
 
 END 
 ii 
 
 it 
 
 ii 
 
 n 
 
 " SUBROUTINE CONVRT CCNVERTS LEN CHARACTERS STARTING AT LINE(START) 
 
 " (CCNVEPSION TYPE DETERMINED BY VALUE OF ITYPE): 
 
 " 1) TO NAME OF STUDENT FILE (SSN IN HEXADECIMAL) 
 
 " 2) TO BASIS FOR CURRICULUM FILES (DECIMAL) 
 
 " 3) JUST CHECKS FOR INVALID CHARACTERS 
 
 " 4) TO DEPARTMENT NAME (IN OUT) £ COURSE # (IN AUX ) 
 
 " 5) TO BASIS FOR DEPARTMENT FILE NAMES 
 
 " OR TO AN ADVISOR'S NAME (ALPHABETIC) 
 
 " 6) CONVERTS CHARACTER TO DECIMAL NUMBER (IN AUX) 
 
 " 7) CONVERTS ¥ IN AUX TO HEXADECIMAL FILE 
 
 " NAME IN OUT 
 
 SUBROUTINE CONVRT (OUT, I TYPE, L INE, LEN, AUX, START, EPR ,* ) 
 INTEGER*2 IN( 20 ) , LI NE( 72) , NUMBER ( 1 1 ) /'0 • , 'IS^S^SS 
 
84 
 
 • /,ALPHA(30)/«A« ,% 
 
 I'lMS'J'f'K'i'L' ,»M» , 
 ,tpi t »Qi ,«R»,»S«,«T» f'US ■V , t 'H'i'X'i 'Y't 
 't' , • • , •♦ '» * •' *♦ »-* /,ITEMP(2) ,LT, BLANK, DOLLAR/' 
 QUOTE/ 1 "V 
 
 INTEGER MATRIX12) ,HEX,AUX, START, DEBUG/0/, ERR 
 
 REAL*8 OUT,FLAG/•????????•/,XXX,CLEAR(5),BL/ , •/ 
 
 EQUIVALENCE (MATRIX! 1), XXX 1,1 ITEMP( 11, IT),? 
 ( BLANK, ALPHA (27) ), ( IN( 1 ) ,CLE AR ( 1)) 
 
 M=0 
 
 ERR=0 
 
 LLEN=LEN 
 
 XXX=0.000 
 
 HEX=268435456 
 
 IF (LLEN.GT.201 LLEN=20 
 
 DO 2 1=1,5 
 
 CLEAR( I ) = BL 
 
 K=START 
 
 DO 5 I=1,LLEN 
 
 IN(I)=LINE(K) 
 
 K = K + 1 
 
 IF (DEBUG. EQ.l) WRITE(6,6) ITYPE,IN 
 IRMAT(» *ENTI 
 •CONVERTING 
 
 GO TO (10, 500, 1000, 1700, 500, 10, 60), ITYPE 
 10 KUM=0 
 
 DO 50 I=1,LLEN 
 
 LT=IN(I ) 
 
 DO 30 J = l, 10 
 
 IF (LT.EO.NUMBER(J) ) GO TO 40 
 30 CONTINUE 
 
 GO TO 2500 
 40 NUM=NUM*10+J-1 
 50 CONTINUE 
 60 IF (ITYPE. EQ. 7) NUM=AUX 
 
 AUX=NUM 
 
 IF (ITYPE. EQ. 7) GO TC 70 
 
 IF (ITYPE. NE. I) GO TC 3000 
 70 DO 100 1=1,2 
 
 DO 100 J=l,4 
 
 M=8-2*J 
 
 L=NUM/HEX 
 
 NU^=NUH-L*HEX 
 
 N=16**M 
 
 IF (L.LE.9) MATRIX! I ) = MATR IX( I )+N*( L+l 5*16) 
 
 IF (L.GT.9) MATRIXU ) = MATRIX( I )*N*( (L-9)«-12*16) 
 100 HEX=HEX/16 
 
 GO TO 3000 
 500 L=l 
 
 DO 600 1=1,8 
 
 LT=IN( I ) 
 
 IT=0 - 
 
 ITEMP(2)=LT 
 
 IF (ITYPE. NE. 2) GO TC 527 
 
 DO 525 J=l,ll 
 
 IF (LT.EQ.NUMBER( J) ) GO TO 540 
 525 CONTINUE 
 
85 
 
 GO TO 2500 
 527 00 530 J=l,27 
 
 IF (LT.EQ.ALPHA(J) ) GO TO 540 
 530 CONTINUE 
 
 GO TO 2500 
 540 IF (I.EQ.5) L*2 
 
 IF (I.EQ.5) HEX=268435456 
 
 MATRIX (L)=MATR I X(L ) + UT-64) /256*( HEX/16) 
 
 HEX=HEX/256 
 600 CONTINUE 
 
 IF (ITYPE.EQ.4) GO TC 1850 
 
 GO TO 3000 
 1000 DO 1200 1=1,20 
 
 LT=IN(I) 
 
 DO 1100 J=l,30 
 
 IF (LT.EQ.ALPHA(J)) GO TO 1200 
 1100 CONTINUE 
 
 GO TO 2500 
 1200 CONTINUE 
 
 GO TO 3000 
 1700 DO 1800 IPT=1,6 
 
 DO 1750 J=l,26 
 
 IF (IN(IPT).EQ.ALPHA(J) ) GO TO 1800 
 1750 CONTINUE 
 
 GO TO 1820 
 1800 CONTINUE 
 
 GO TO 2500 
 1820 LLEN=IPT-i 
 
 K=9 
 
 DO 1830 I=IPT,8 
 
 IN(K)=IN(I ) 
 
 IN( I )=BLANK 
 1830 K=K*-1 
 
 GO TO 500 
 1850 L=IPT+2 
 
 K=9 
 
 DO 1910 1=7,9 
 
 IN(I )=IN(K) 
 1910 K=K*1 
 
 N0N0=NUMBER(1) 
 
 DO 1915 1=1,6 
 1915 IN(I)=NCNO 
 
 LLEN=9 
 
 GO TO 10 
 2500 XXX=FLAG 
 
 ERR=10 
 
 WRITE (6,2600) ( IN( I ), 1 = 1 ,LLEN) , QUOTE 
 2600 FORMATP CANNOT TRANSLATE M S21A1) 
 3000 OUT=XXX 
 
 IF (DEBUG. EQ.l) WP I T E( 6,3005) OUT,AUX 
 3005 FORMAT(« *LEAVING CONVRT — CUT=»,A8,% 
 • AUX=«,I10) 
 
 IF (ERR.NE.O) RETURN 1 
 
 RETURN 
 
 END 
 
86 
 
 •i 
 
 " OLF UTILITY PROGRAMS 
 
 n 
 
 " DREDIT CREATES AND DELETES DI RECTCRY FILES 
 
 M SUBPROGRAMS INVOKED IN CRECIT ARE SHOWN IN THE OLF LISTING 
 
 •• 
 
 REAL*8 CURRIC/*CURRIC*/,LAST( 4) /4* 'DUMMY* / ,X, Y, Z ,S 
 
 VECTOR (260) , NAME, ENTRY (2 ), VERB, BLANK / • •/, ACTION ( 3) % 
 /•INSERT*, 'DELETE* , • NEXT* /, LIST( 2 ) /• CRLI ST* , »DLLIST*/,S 
 BUF(21)/21*« */,DU»'MY/*DUMMY*7,CH0ICE(2) /*FOUND*,*IS NOT*/,? 
 THING 
 
 REAL*4 V1(2)/*INT0*, 'FROM* / , ANSI 3) /• 1' ,*2* ,*DONE*/ 
 
 INTEGER ERR0R,PTR,DUP,TYPE(3)/2,5,1/,ACT(2)/1,-1/,S 
 AUX0UT,LENGTHI3) ,CCPYI2 ) /2*0 /,LEN ( 3) /8, 8 , 10/, % 
 ZERO/0/, IRUN/0/,KIND(2)/5,2/,V(2)/* *,*DEST*/,% 
 LLEN(2)/21,2/ 
 
 INTEGER*2 INI 20 ) ,LI NE( 72 ) , $$/* $$ • / , A (4 ) ,ONE/* I • /, % 
 BL/* •/ 
 
 C0MPLEX*16 W0RDS(2)/*CURRICULUM ¥*,*NAME AND SSN*/,? 
 BUFF, CLEAR/* •/ 
 
 EQUIVALENCE ( IN(1),L INEI 1 ) ) , (NAME, A ( 1 ) ),% 
 IBUFI 1) ,BUFF) 
 it 
 
 " LOAD LEVEL-1 DIRECTORY CURRIC 
 ti 
 
 CALL LOAD( 1 ,CURR IC , ,LAST , VECTOR, LENGTH , CURR IC ,0) 
 5 M=l 
 n 
 
 » REOUEST THE NAME OF THE TO-BE-EDITED FILE 
 •• 
 
 WRITE(6,10) 
 10 FORMAT! • TYPE LEVEL — 1 OR 2 COR DONE) AND NAME OF FILE*,? 
 • TO BE EDITED*/) 
 
 READ(5,15) ANSWER, IN 
 15 FCRMAT(A4,6X,20A1) 
 
 DO 20 LEVEL=l,3 
 
 IF (ANS(LEVEL).EO. ANSWER) GC TO 40 
 20 CONTINUE 
 23 WRITE(6,25) 
 
 25 FORMAT! • SORRY — COULCN**T UNDERSTAND THAT*) 
 27 GO TO (5,100) ,M 
 40 IF (LEVEL. EQ. 3) GO TC 500 
 
 CALL CCNVRT(NAME,KINC(LEVEL),LINE,8,AUXOUT,l,EPROR,&27) 
 
 IF (LEVEL. EQ.2) GO TC 45 
 
 IF (NAME. NE. CURRIC) GO TO 23 
 
 GO TO 100 
 
 " PREFACE CURRICULUM CODE WITH $$ 
 
 45 CALL RENAME(*$,NAME) 
 
 H 
 
 " IS THE REQUESTED FILE KNCWN? 
 
 •i 
 
 CALL BISECT (VECTOR, LENGTH, NAME, DUP,PTR, 1,LAST) 
 IF (DUP.EQ.l) GO TO 90 
 WRITE(6,50) A(2),A(3),A(4) 
 
87 
 
 50 F0RMAT(1X,3A2,« IS A^ UKKNCWN CURRICULUM') 
 GO TO 5 
 
 N 
 
 ■ LOAD THE TO-BE-EOITED FILE 
 
 n 
 
 90 CALL L0A0(2, NAME, CCPY<2), LAST, VECTOR, LENGTH, NAME, 0) 
 
 100 M=2 
 
 N 
 
 M OETERMINE THE TYPE CF EDITING REOUIRED 
 
 •• DETERMINE THE NAME OF THE FILE TO BE INSERTED (DELETED) 
 
 it 
 
 WRITE(6,U0) WORDS(LEVEL) 
 110 FORMATC TYPE ACTION, »,A12) 
 
 READ! 5, 120) VERB, ( IN ( I ) , 1= I, 8 I , ( IN( I ) , 1 = 12 ,20) 
 120 F0RMAT(A8,2X,8A1,2X,^A1) 
 
 DO 130 1=1,3 
 
 IF (VERB. EO. ACTION! I )) GO TO 150 
 130 CONTINUE 
 
 GO TO 23 
 •* 
 
 •» IF TYPE OF EDITING = NEXT, GO GET THE NAME OF THE 
 « NEXT FILE TO BE EDITED 
 
 H 
 
 150 IF (I.E0.3) GO TO 5 
 
 INCR=ACTII) 
 
 J=0+LEVEL 
 
 K=l 
 160 CALL CONVRT(ENTRY(K) ,TYPE( J) ,L INE, LEN ( J ) , AUXOUT,? 
 (K-l)*10+l, ERROR, C27) 
 
 J = 3 
 
 IF (LEVEL. NE. 2) GO TC 200 
 
 IF (K.E0.2) IN(11)=BL 
 
 IF (K.EQ.2) GO TO 200 
 
 K=2 
 ii 
 
 M ADD 1 BILLION TO THE ADVISOR'S SSN TO MAKE ADVISOR FILENAME 
 
 •* CLEARLY DISTINGUISHABLE FRCM STUDENT FILENAME 
 if 
 
 IN(U)=ONE 
 
 GO TO 160 
 
 200 IF (LEVEL. EQ.l) CA LL R ENAME ( $$,ENTRY( 1) ) 
 
 it 
 
 " DOES THE FILE TO BE INSERTED (DELETED) EXIST? 
 
 n 
 
 CALL BISECT(VECTOR, LENGTH, ENTRY( 1) ,OUP , PTR , LEVEL , LAST ) 
 IF (I-DUP.EQ. I) GO TO 220 
 i, 
 
 n FILE EITHER EXISTS WHEN IT SHOULDN'T OR 
 
 w DOESN'T EXIST WHEN IT SHOULD 
 
 M 
 
 WRITE (6,205) ENTRY ( 1 ) , CHO ICE( I ) , LA ST ( LE VEL ) , VERB 
 205 F0RMAT(1X,A8,IX,A6,» IN DIRECTORY ',A8,S 
 • CAN"T »,A6,' IT') 
 
 GO TO 100 
 220 IF (LEVEL. EQ.l) GO TC 245 
 
 IF (INCR.EO.-l) GO TD 245 
 
II 
 
 FIND THE 
 
 •1 
 
 OWNER OF 
 
 II 
 
 
 88 
 
 " CREATING A NEW FILE — HAKE SURE THAT THE PROPOSED 
 
 " FILE DOES NOT EXIST ON ANOTHER BRANCH OF THE OLF TREE 
 it 
 
 CALL OPEN( 1,ENTRY(2) ,MNPUT«,N) 
 IF (N.NE.O) GO TO 243 
 
 H 
 
 " THE FILE EXISTS 
 
 n 
 
 PEA0(i,270) N 
 
 IF (N.EQ.O) GO TO 235 
 
 n 
 
 NAME AND CURRICULUM OF THE PRESENT 
 THE DISPUTED SSN FROM A STUDENT FILE 
 
 READ(1,275) X 
 
 CALL OPEN(2,X,» INPUT') 
 
 REAC(2,230) Y,Z 
 230 F0RMAT(40X,2A8) 
 
 CALL CL0SE(2) 
 
 GO TO 240 
 •• 
 
 " IF THIS IS A NEW ADVISOR FILE, IT HAS 
 
 M A HEADER SHOWING OWNER'S NAME AND CURRICULUM 
 
 235 REACH, 275) Z,Y 
 
 240 WRITE (6,242) ( IN(N),N=12,20),Z,Y 
 
 242 F0RMAT(1X,9AI,« IS THE SSN LISTED FOR «,A8,' OF »,S 
 
 •CURRICULUM f ,A8) 
 CALL CLOSE(l) 
 GO TO 100 
 
 243 CALL CLOSE(l) 
 ii 
 
 " INSERT (DELETE) THE FILE 
 
 M 
 
 245 CALL REVISEIVECTOR, LENGTH, ENTRY(l) , ENTR Y( 2) , PTR, LEVEL,? 
 
 I NCR, LAST, ERROR, ENTRY(K) ) 
 IF (ERROR. EQ.l) GO TC 100 
 IF (INCR.EO.O) GO TC 300 
 
 " CREATE THE NEW FILE 
 
 ii 
 
 CALL OPENl 1,ENTRY(K) , 'OUTPUT' ) 
 
 WRITE(1,270) ZERO 
 270 F0PMATU4) 
 
 IF (LEVEL. EQ.l) GO TO 273 
 
 BUF(1)=ENTRY( 1) 
 
 BUF(2)=NAME 
 273 KK=LLEN(LEVEL) 
 
 WRITE (1,275) (BUF( J) ,J=i,KK) 
 275 FORMAT(IOAB) 
 
 IF (LEVEL. EO. 2) BUFF=CLEAR 
 
 CALL CLOSE(l) 
 
 ADD FILE TO A BACKUP LIST (CRLIST OR DLLIST) 
 
 CALL OPEN(l,LIST( I), f MOD» ) 
 
 THING= BLANK 
 
MAKE SURE ALL DIRECTORIES HAVE BEEN REWRITTEN BEFORE STOPPING 
 
 89 
 
 IF (LEVEL. EQ. 2) THING=ENTRY< I) 
 WRITE (1,280) V( I), ENTRY (K! ,THI NG, VI ( I ) , NAM E 
 280 FORMA T(A4, IX, A8 , IX , A8, IX, A4, 1 X,A8) 
 CALL CLOSE(l) 
 
 M 
 
 •• ENABLE DIRECTORY REWRITE 
 
 H 
 
 300 COPY(LEVEL)=l 
 
 I R UN= 1 
 n 
 
 " GET NEXT COMMAND 
 
 n 
 
 GO TO 100 
 
 500 DO 550 1=1,2 
 n 
 
 •i 
 
 M 
 
 550 IF (COPY(I).EQ.l) CALL LCAC( I , DUMMY, COP Y( I ) ,LAST, t 
 
 VEC TOR, LENGTH, DUMMY, 0) 
 •* 
 
 •• IF ANY FILES HAVE BEEN EDITED, REQUEST A TAPE COPY 
 
 it 
 
 IF (IRUN.EQ.l) WRITE(6,560) 
 560 FORMATP AFTER JOB ENDS — TYPE: PUNN COPY') 
 
 STOP 
 
 END 
 ti 
 
 •i 
 
 N 
 It 
 
 M RECOVR EDITS DIRECTORIES AFTER SYSTEM FAILURE TO 
 
 " CONFORM TO FILES CRLIST AND DLLIST 
 
 " SUBPROGRAMS INVOKED BY RECOVR ARE SHOWN IN THE OLF LISTING 
 
 n 
 
 INTEGER LENGTH(3),ACT(2)/1,-1/,DUP,PTR,ERR,S 
 C0PY(3)/3*0/,0K(2)/0, 1/ 
 
 INTEGER*2 $$/•$$•/, A 
 
 REAL* 8 VECTOR (260) , L AST (4) M* • DUMMY* /, DUMMY/' DUMMY • /, BLANK/' •/,* 
 LIST (2) /'CRLIST' , 'DLL I ST' / , ITEM1 ,1 TEM2, CURR IC/ • CURR I C / , FI LE 
 
 EQUIVALENCE (A, FILE) 
 
 00 1000 1=1,2 
 
 INCR=ACT(I ) 
 
 IOK=OKU) 
 
 CALL 0PEN(10,LIST(I) ,' INPUT' ) 
 
 DO 500 J= 1,10000000 
 
 READ(10,10,END=1000) I TEM2 , ITEMl ,FI LE 
 10 F0RMAT(5X,A8,1X,A8,6X,A8) 
 
 LEVEL=3 
 
 IF (FILE.EC.CURRIC) LEVEL=1 
 
 IF (A.EQ.$$) LEVEL=2 
 
 CALL L CAD (LEV EL, FILE, COPY (LEVEL), LAST, VECTOR, L ENGTH, BLANK , 0) 
 
 IF ( ITEMl. EQ. BLANK) ITEM1=ITEM2 
 
 C0PY(LEVEL)=1 
 
 CALL BISECTIVECTOR, LENGTH, ITEMl ,DUP ,PTR , LEVEL , LAST ) 
 
 IF (IOK.EQ.DUP) CALL REVIS E( VECTOR , LENGTH, % 
 ITEMl, I TEM2,PTR, LEVEL, I NCR, LAST, ERR, FILE) 
 500 CONTINUE 
 
90 
 
 1000 CALL CLOSEUO) 
 
 DO 1050 1=1,3 
 1050 IF «COPY(LEVEL).EQ.l) CALL LCAOC I , DUMMY, 1 , LAST , VECTOR ,* 
 LENGTH,DUMMY,0) 
 
 STOP 
 
 END 
 
 COPY IS A BATCH JOB WHICH INVOKES SEVERAL 
 PROGRAMS TO CREATE TAPE COPIES OF OLF FILES 
 FOR BACKUP PURPOSES 
 
 //* ID CARD IMAGES GO HERE 
 
 // EXEC TSBATCH 
 
 //SYSIN DD * 
 
 (PLORTS LOGIN INFORMATION GOES HERE) 
 
 OPEN CCOPY 
 
 FORTRAN 
 
 CLOSE 
 
 RUNN ID,C0PY1,SAVE,SLSTAR 
 
 RUNN ID,C0PY2,SAVE,SLSTAR,CELETE1,CLLIST,DELETE2 
 
 LOGOUT 
 
 /* 
 
 M 
 
 " CCOPY CREATES A FILE (SAVE) WHICH IS A COMPOSITE 
 " OF ALL OLF CATA FILES 
 
 n 
 
 REAL*8 VECT0RC260) ,G IB8( 5 ) ,DC ODE < 12 ) , NAMEI4) / • CURR IC ,3** •/ 
 
 REAL GIB4U6) 
 
 INTEGER*2 GIB2I20) ,CHEKOV( 12) ,HEA0ER( 32 ) ♦ DBLOCM 56 , 12 ) 
 
 INTEGFR PART(5,5) ,L ENGTH I 3 ) ,L i< 3) / 1 ,201 ,24 I/, L3( 3) /0,20,0/,S 
 LEN(3) , ROWS/5/ 
 
 CALL OPEN( 10, •SAVE* , 'OUTPUT* ) 
 
 CALL OPENCl, 'DATES* , "INPUT* I 
 
 REA0I1,5) I, J 
 5 F0RMATC2I5) 
 
 WRITE<10,5) I, J 
 
 CALL 0PEN(2, 'PART* ,• INPUT* ) 
 
 REAC(2,10)((PART( I, J ), J=l , 5 ) , I = 1 ,ROWS) 
 10 F0RMAT(5(U,1X) ) 
 
 WRITE(10,10){ (PART(I,J),J=1,5),I=1,R0WS) 
 
 CALL CL0SE(1,2) 
 
 1 = 1 
 12 LEN(I)=0 
 
 CALL OPEN( I,NAME(I), 'INPUT* ) 
 
 READ! I, 15) K 
 15 F0RMAT(A4) 
 
 WRITE(10,15) K 
 
 LENGTH(I)=K 
 
 IF (LENGTH(l) .EO.O) CO TO 80 
 
 IF (K.EQ.O) GO TO 60 
 17 LEN( I)=LEN(I )+l 
 
 IF (LENII ) .NE.l) GO TO 22 
 
 ISTART=L1( I) 
 
 IEND=L1CI )+L3(I J+K-i 
 
91 
 
 REAC( 1,20 ) I VECTOR (J) ,J=ISTART, IEND1 
 20 F0RMATU0A8) 
 
 WRITE <10,2 0M VECTOR! J), J=I START, IEND) 
 22 NAME! I +1)= VECTOR (Ll( I)+L3( I)+LEN( I )-l) 
 
 1*1*1 
 
 IF (I.LE.3) GO TO 12 
 
 CALL CLOSEtl) 
 
 DO 40 J=ISTART,IEND 
 
 CALL OPEN! I, VECTOR ( J ) , • INPUT* ) 
 
 READ(1,25) HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK 
 25 F0RMAT(32A1,5A8/16A4/20A2,12A1/6A8/6A8/(28A2I ) 
 
 40 WRITE(10,25) HEAOER, GI B8,Gl B4 ,GI B2 ,CHEKOV, OCODE, DBLOCK 
 
 1=1-1 
 60 1=1-1 
 
 IF (LEN(I).LT.LENGTHU)) GO TO 17 
 
 IF (I.GT.l ) GO TO 60 
 80 CALL CLOSE(1,2,3,10) 
 
 WRITE(6,100) 
 100 FORMAT!* ALL FILES PREPARED FOR COPY*) 
 
 STOP 
 
 END 
 it 
 
 n 
 it 
 •• 
 
 ID IS A PLORTS FILE CCNTAINGING ID CARD IMAGES 
 
 C0PY1 AND C0PY2 ARE PLORTS FILES CONTAINING CARD IMAGES 
 WHICH INVOKE THE CATALOGUED PROCFDUPE COPY. C0PY1 
 CREATES A COPY OF THE FILE SAVE ON THE FIRST BACKUP 
 TAPE, C0PY2 CREATES A COPY OF SAVE ON THE SECOND BACKUP 
 TAPE. DUPLICATE COPIES PREVENT THE DESTRUCTION OF 
 THE BACKUP SYSTEM BY A SYSTEM FAILURE DURING PREPARATION 
 OF A NEW BACKUP TAPE 
 
 COPYl: 
 
 /♦SETUP UNIT=TAPE,ID=02725 5,RING 
 
 // EXEC COPY 
 
 //SYSUT2 DO DSN=LERNER.P6416. COPYl, DISP=(NFW, KEEP), UNIT=TAPE, 
 
 // VOL=SER=027255,LA8EL=(2,SL), 
 
 // DCB=<LRECL=80,BLKSIZE=3 200,RECFM=FB) 
 
 //SYSUT1 DD * 
 
 C0PY2: 
 
 /♦SETUP UNIT=TAPE,ID=027310,RING 
 
 // EXEC COPY 
 
 //SYSUT2 DD DSN=LERNER.P6416.C0PY2,DISP=(NEW,KEEP) ,UNIT=TAPE, 
 
 // V0L=SEP=027310,LABEL=(1,SL), 
 
 // DCB=<LRECL=80,BLKSIZE=3200,RECFM=FB) 
 
 //SYSUT1 DD * 
 
92 
 
 SLSTAR IS A PLDHTS FILE CONTAINING THE CARD IMAGE: /* 
 
 OELETE1 STARTS A NEW JOB STEP TO DEALLOCATE OBSOLETE 
 
 FILES. AFTER THE BACKUP HAS BEEN MADE AND THE DEALLOCATION 
 
 LIST HAS BEEN USED, SAVE, CRLIST, AND DLLIST ARE ALL OBSOLETE 
 
 // EXEC TSBATCH 
 
 //SYSIN DD * 
 
 (PLORTS LOGIN INFORMATION GOES HERE) 
 
 DELETE2 DOES THE FINAL DEALLOCATION AND A LOGOUT 
 
 DEST CRLIST 
 DEST DLLIST 
 DEST SAVE 
 LOGOUT 
 /* 
 
 RESTORE IS A BATCH JOB WHICH USES TWO PROGRAMS TO 
 
 RESTORE OLF FILES TC A TIME BEFORE A SYSTEM FAILURE. 
 
 THE BACKUP TAPE CREJTEC BY COPY IS USED FOR THE RESTORATION 
 
 //* ID CARD IMAGES GO HERE 
 
 /♦SETUP UNI T=TAPE, ID=0272 5 5, NOR I NG 
 
 // EXEC FILE,PAPM=»6416,LERNER I 
 
 //SAVE DD DSN=LERNER.P6416.C0PY1,DISP=(SHARE,KEEP),UNIT=TAPE, 
 
 // VOL=SER=027255,LABEL=(2,SL) 
 
 //SYSIN DD * 
 
 DD=SAVE,PRINT=YES 
 
 /* 
 
 // EXEC TSBATCH 
 
 //SYSIN DD * 
 
 (PLORTS LOGIN INFORMATION GOES HEREI 
 
 RECOPY 
 
 FORTRAN 
 
 C 
 
 LOGOUT 
 
 /* 
 
 RECOPY READS A FILE (SAVE) WHICH IS A COMPOSITE OF ALL 
 OLF DATA FILES AT SCME EARLIER TIME, AND RECREATES THE 
 THE INDIVIDUAL FILES 
 
 REAL*8 VECT0RC260) ,CCODE( 12 ) , NAME 14 )/ • CURRICSS** •/,% 
 
93 
 
 GIB8(5) , BLANK/' •/ 
 
 REAL GIB4<16) 
 
 INTEGER*2 HEADER! 32 ) ,CHEKOV ( 12 ) , GI B2 (20 ) , DBLDCM 56, 12 > 
 
 INTEGER R0WS/5/,PART<5,5) .LENGTHC 3 ) ,L1 ( 3) /l ,201 ,241/ ,L3( 3) * 
 /0,20,0/,LEN<3l 
 
 CALL OPEN( 10, •SAVE* ,'INPUT' I 
 
 CALL OPEN( 1, 'DATES*, 'OUTPUT* ) 
 
 REA0(10,5) I ( J 
 5 F0RMAT(2I5) 
 
 WRITE(1,5) I, J 
 
 CALL 0PENC2,' PART' , 'OUTPUT • ) 
 
 READ! 10, 10) ((PART (I, J) , J=l , 5) , 1 = 1 , ROWS) 
 10 F0RMAT(5(Il,lxn 
 
 WR I TE ( 2 , 10 M ( P ART ( I , J ) , J= 1 , 5 ) , I = 1 , ROW S ) 
 
 CALL CLDSE(1,2) 
 
 1 = 1 
 12 LEN(I)=0 
 
 CALL OPEN(I,NAME(I ), 'OUTPUT' ) 
 
 READ(10,15) K 
 15 F0RMATU4) 
 
 WRITE! 1,15 ) K 
 
 LENGTH(I)=K 
 
 IF (K.EQ.O) WRITE(I,20) BLANK 
 
 IF (LENGTH(l).EQ.O) GO TO 80 
 
 IF (K.EO.O) GO TO 60 
 17 LEN(I) = LENU)+i 
 
 IF (LEN(I).NE.l) GO TO 22 
 
 ISTART=L1( I) 
 
 IEND=L1U )*L3(I)+K-1 
 
 RE AC (10,20) (VECTOR (J ) , J=I START , I END ) 
 20 F0RMAT(10A8) 
 
 WRITE ( I,20)(VECT0R(J),J=ISTART, I END) 
 22 NAME(I«-1) = VECT0R(L1( I)+L3( I)+LEN(I)-1) 
 
 1=1 + 1 
 
 IF (I.LE.3) GO TO 12 
 
 CALL CLOSE(l) 
 
 DO 40 J=ISTART,IEND 
 
 CALL OPEN( 1,VECT0R(J), 'OUTPUT' ) 
 
 RE AD (10,25) HEADER,GIB8,GIB4,GIB2,CHEKOV,0CODE,DBL0CK 
 2 5 FORMAT(32Al,5A8/16A4/20A2, 12 A I /6A8/6 A8/ ( 28 A2) ) 
 40 WRITE(i,25) HEADER , G IB8 ,GI B4,GIB2 ,CHEKOV, DCODE ,DBLOCK 
 
 1 = 1-1 
 60 1=1-1 
 
 IF (LEN(I ).LT.LENGTH(I) ) GO TO 17 
 
 IF (I.GT.l) GO TO 60 
 80 CALL CLOSE(l,2,3,10) 
 
 WRITE(6,100) 
 100 FORMATC FILES ARE NCW RESTOREO') 
 
 STOP 
 
 END 
 
94 
 
 BIBLIOGRAPHY 
 
 [1] Data Processing for Education Administration . Detroit: American 
 Data Processing, Inc., 1969. 
 
 [2] Knuth, Donald E. The Art of Computer Programming . Vol. I: Funda- 
 mental Algorithms . Addison-Wesley Series in Computer Science 
 and Information Processing, ed. by Richard S. Varga and 
 Michael A. Harrison. Reading, Massachusetts: Addison-Wesley 
 Publishing Company, 1968. 
 
 [3] Lancaster, F. Wilfrid. Information Retrieval Systems: Character - 
 istics, Testing, and Evaluation . Information Sciences Series, 
 ed. by Robert M. Hayes and Joseph Becker. New York: John Wiley 
 & Sons, Inc., 1968. 
 
 [4] PLORTS Guide: A Guide to Using the Computing Services Office Low- 
 Cost Terminal Filing and Remote Job Entry Facility for IBM 
 System/ 360 . Urbana, Illinois: Computing Services Office, 
 University of Illinois at Urbana-Champaign, 1972. 
 
 [5] Watson, Richard W. Timesharing System Design Concepts . McGraw- 
 Hill Computer Science Series, ed. by Richard W. Hamming and 
 Edward A. Feigenbaum. New York: McGraw-Hill Book Company, 
 1970. 
 

 IIBLIOGRAPHIC DATA 
 HEET 
 
 1. Report No. 
 
 UIUCDCS-R-73-582 
 
 2. 
 
 3. Recipient's Accession No. 
 
 . Tn le and Subtitle 
 
 0N-LINE FILING (0LF) 
 A PR0GRAM PACKAGE F0R STUDENT REC0RDS 
 
 5. Report Date 
 
 October 1973 
 
 6. 
 
 . Author(s) 
 
 Edward Mark Lerner 
 
 8- Performing Organization Rept. 
 
 No - UIUCDCS-R-73-582 
 
 . Petforming Organization Name and Address 
 
 University of Illinois at Urbana-Champaign 
 
 10. Project/Task/Work Unit No. 
 
 Department of Computer Science 
 Urbana, Illinois 61801 
 
 11. Contract/Grant No. 
 
 2. Sponsoring Organization Name and Address 
 
 University of Illinois at Urbana-Champaign 
 Department of Computer Science 
 
 13. Type of Report & Period 
 Covered 
 
 Master's Thesis 
 
 Urbana, Illinois 61801 
 
 14. 
 
 5. Supplementary Notes 
 
 5, Abstracts 
 
 0LF is a set of F0RTRAN programs which automates the maintenance and use 
 of student records. Processing of information may be done in either batch or inter- 
 active mode. pLF is designed to facilitate the expansion of its data processing 
 capabilities. 
 
 7. Key Words and Document Analysis. 17a. Descriptors 
 
 lata Processing 
 
 Education 
 
 nformation Retrieval 
 
 
 
 'b. Identifiers /Open-Ended Terms 
 re. C.OSATI Field/Group 
 
 
 1 
 
 ! 
 
 1. Availability Statement 
 
 RELEASE UNLIMITED 
 
 19. Security Class (This 
 Report) 
 
 UNCLASSIFIED 
 
 21. No. of Pages 1 
 
 100 
 
 20. Security Class (This 
 Page 
 
 UNCLASSIFIED 
 
 22. Price 
 
 )RM NT1S-3S ( 10-70) 
 
 USCOMM-DC 40329-P7 1 
 
\ 
 
 ■>v 
 
 
UNIVERSITY OF ILLINOIS-URBANA 
 510.B4 IL6R no. C002 no. 577-582(1973 
 On-line tiling (OLF) a program package 
 
 3 0112 088400707