LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-OHAMPAIGN bl0.'%4 IJlCeY The person charging this material is re- sponsible for its return to the library from which it was withdrawn on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasons for disciplinary action and may result in dismissal from the University. To renew call Telephone Center, 333-8400 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN IAN 13198 aci L161— O-1096 Digitized by the Internet Archive in 2013 http://archive.org/details/localinformation409levi JfC-r «c 'So? Report No. 1+09 COO-1U69-017 1 * LOCAL INFORMATION RETRIEVAL FOR THE SIMULATION AND MODELING SYSTEM by HAROLD LEVIN August 1970 ''"".■: ■• 'HE LIBRARY OE THE NOV 9 If UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPi Report No. i+09 LOCAL INFORMATION RETRIEVAL FOR THE SIMULATION AND MODELING SYSTEM* HAROLD LEVIN August 1970 Department of Computer Science University of Illinois Urbana, Illinois 6l801 This report was supported in part by the Atomic Energy Commission under grant US AEC AT(ll-l)lU69 and submitted to the Graduate College of the University of Illinois at Urban a- Champaign in partial fulfillment of the requirements for the degree of Master of Science in Computer Science, 1970 r Ill ^ ACKNOWLEDGMENT The author wishes to express his appreciation to Professor C. W. Gear, who advised this thesis; and to Martin J. Michel, who provided many interesting ideas during its development. Thanks are also due to Miss Barbara Hurdle for her excellent typing, and to the author's wife for her endless patience. iv TABLE OF CONTENTS Page LIST OF FIGURES v 1. INTRODUCTION 1 2. IR FACILITIES 3 3. LIBRARY FUNCTIONAL DESCRIPTION 7 LIST OF REFERENCES IT APPENDICES A. IR INTERNAL ROUTINES 18 B. DISK STORAGE ALLOCATION 23 C. DISK MONITOR SYSTEM. 26 LIST OF FIGURES Fi gure Page 1. Simplified System Architecture 1 2. IR Function Table 5 3. File Structure 9 k. Free Block Lists 11 5. IRREQ Flow Diagram 12 6. Read and Save Flow Diagrams 13 7. Delete Flow Diagram ik 8. Write Flow Diagram (Part l) 15 9. Write Flow Diagram (Part 2) l6 B-l. Disk Storage Map 2 5 C-l. SWAPTAPE Format (Block Numbers) 28 1. INTRODUCTION A group in the Department of Computer Science at the University of Illinois is currently developing a general purpose simulation and modeling system. Figure 1 shows a simplified picture of the system architecture . IBM 360/75 44- DEC PDP-8 < — > TERMINAL CONTROL DISK USER GRAPHICS TERMINALS Figure 1. Simplified System Architecture The PDP-8 is used to handle all drawing functions, and together with the terminal control and the graphics terminals, allows a user to draw various networks, describe their functional character- istics, save the networks for later use, or request network analysis. The PDP-8 also maintains a temporary library of user pictures and networks on the local disk, while a permanent library is maintained in the 360. Extensive network analysis is also performed in the 360. This paper describes one component of the PDP-8 software system, namely, the IR (Information Retrieval) routines. These routines are responsible for: 2 3 1. Performing all disk operations for GLASP. ' 2. Maintaining the local library on the disk. 3. Communicating with IR in the 360. Chapters 2 and 3 describe the functional characteristics of IR. Appendix A contains descriptions of the internal routines in IR, Appendix B describes the disk layout for IR, while Appendix C describes the Disk Monitor System that was implemented for program development on the PDP-8. 2. IR FACILITIES A. GLASP Utilities Two programs are contained in IR to perform utility operations for GLASP. 1. BNKSWP This program is used to save and restore core banks and 1 on the disk. Eight such core images can "be saved, one for each of the eight terminals that GLASP supports. Due to the nature of the disk, two banks of core may be transferred in one disk access. Transfer time (including a half rotation average latency) is 6l ms . in either direction, 2 . DSKGET A collection of numbered program segments is maintained on the disk. Each program segment is 102U words long and always resides at 3^000q in the PDP-8. GLASP may read or write any particular segment by calling DSKGET. Transfer time (including latency) is 22.3 ms . B. Library System The principle function of IR is to build and maintain the local library. Programs running under GLASP will need facilities for saving and retrieving subpictures, textual data, and network descriptions created by users at the graphics terminals. IR is insensitive to the type of data, and merely handles blocks of PDP-8 words along with a name and type supplied by the calling program. The system is coded in such a way as to reduce disk references and to reduce latency times when reading and writing files . Communi cations between programs and the IR library is through parameters stored in the console vector, and via ROUTX. Specifically, a program describes the desired operation by setting up words 5-12 in the console vector of the current console, and goes to ROUTX with a request for IR. GLASP keeps track of all system resources and will transfer control to IR if IR is not busy. A location in core points to the current console vector. IR will service the request, put a return code indicating the degree of success into the console vector, and return to the program via GLASP utility OPDONE. The console vector parameters for IR are shown below: WORD 5: WORD 6: WORDS 7-9: WORD 10: WORD 11: WORD 12: The FUNCTION word decodes as: BIT 0: BIT 1: BIT 2: BIT 3: FUNCTION 6 BIT FILE TYPE 6 CHARACTER FILE NAME (packed ASCII) CORE LOCATION OF DATA LENGTH OF FILE PROTECTION - write 1 - read - communicate with the 360 where appropriate 1 - no 360 communications - save file locally 1 - do not save locally - if a file to be written already exists, overlay the old copy 1 - do not overlay an existing file BIT h: - no action 1 - delete the named file BITS 5-6: core bank of data BITS 7-11: return code placed here Common combinations of the function bits are tabulated below (X is a "don't care"). FUNCTION BIT 1 2 3 ^ Actions X X X 1 X 1 X X 1 10 0X0 10 1X0 1 1 X X 10 10 110 10 10 10 110 1110 Figure 2 Delete locally and in 360. Delete locally only. Read locally or from 360, save a copy locally. Read from either one, do not save a copy locally. Read locally only. Write a copy both locally and in the 360, overlay if necessary. Write a copy in both; do not overlay an existing file. Write in 360 only; overlay allowed. Write in 360 only; no overlay allowed. Write locally only, overlay allowed. Write locally only, no overlay allowed. No operation. No operation — sets a return code of 3 if file exists locally. IR Function Table The calling program sets word 11 during "writing to indicate the length of the file. This may be between 2 and TT^lg words . For reading, the program sets the amount of core available to receive the file. If the file does not fit, IR indicates that with an appropriate return code. In any case, this word will always be set to the actual length of the file. Return codes are 0: 1 2 3 k 5 9 operation successful. file to be read does not fit in core. file to be read not found. attempt to illegally overlay a file. file to be deleted not found in 360. file to be deleted not found locally. file to be deleted not found anywhere, 3. LIBRARY FUNCTIONAL DESCRIPTION This chapter describes the inner workings of the various routines that comprise the library system. Appendix A contains the names and calling sequences of internal routines in the entire system. A. Directory The library directory is stored on the disk as a contiguous block of 8192 words. Each directory entry is 8 words long and contains the following information: WORD 1: TYPE WORD 2: USER ID WORDS 3-5: 6 CHAR FILE NAME WORD 6: FIRST BLOCK NUMBER OF FILE WORD 7: FILE LENGTH WORD 8: PROTECTION The TYRE word contains the user file type in bits 6-11. Bits 2-5 are currently unused. Bits and 1 decode as follows: BIT 0: - entry is not currently in use 1 - entry is in use BIT 1: - this entry has never been used 1 - entry has had a name in it The USER ID is obtained from GLASP and uniquely identifies the user that created the file. The FILE LENGTH is coded as: BITS 0-k: number of full blocks BITS 5-H: length of last block The PROTECTION word is currently unused. At a future date it will "be used to allow users limited access to each, other's files. A file name is placed in the directory as follows: 1. A hash-coding is performed on the 6 character name and USERID, mapping it into the range (0,17To). 2. A 6k word (8 entry) block of the directory whose number is obtained from (l) is read into core (the access routines check to see if that block is already in core to avoid re-reading). 3. A sequential search is started at the beginning of the block for a free entry (BIT of the TYPE equal to 0). The next sequential blocks are read into core if necessary, k. An entry is made, and the block is rewritten onto the disk, An entry is found in a fashion similar to insertion, except that searching stops when: 1. The correct name is located, or 2. An entry that has never been used (i.e., BIT 1 of TYPE equals 0) is found. The reason for criterion (2) is best illustrated by an example, Assume that names A, B, and C all map into block N that has never been used, and are inserted in the above order. File B is then deleted. The search for file C should not give up at the first free entry (i.e., that formerly occupied by B) , but should continue until an entry is reached that has never been used. This guarantees that searches never terminate prematurely. The directory has room for 102U entries. Current estimates are that not more than half of the directory will ever be in use which implies that the hashing technique will rarely have to access more than one block. B. File Storage and Allocation The bulk of the disk is dedicated to actual file storage. This area of the disk is divided into blocks of 128 words each. A file is a linked string of blocks, and has the following structure: FIRST 126 127 126 127 126 127 L-l L 127 BLOCK DATA | • -*| DAI A • ■■ »■ DAI A • " """* DAI A UiMUoIijJJ 1 NUMBER (L = LENGTH) Figure 3. File Structure All blocks except the last contain 127 words of data, followed by a one word link pointing to the next block. The last block in the file, which may also be the only block, contains anywhere from 2 to 128 words without a link. The reason that a last block never contains one word is that the previous block may be made into the last block of length 128 words, thereby including the one word. A file's position on the disk is fully described by: 1. The first block number of the file. 2. The number of full blocks (i.e., blocks with links). 3. The number of words in the last block. The disk contains 6lUU words per physical track, or exactly k8 blocks of 128 words. Since the disk is fixed head, blocks M and N are equivalent with respect to head position if M = N, mod U8. One block 10 takes approximately 820 usee, to pass under the heads. It can be seen that if two successive blocks in a fiie > M and N, are related such that (1) N - M+2, mod U8 then the software has approximately 820 usee, from the time block M is transferred before block N is in a position to be read or written. Software response time for initiating a transfer is considerably less than this, so if all blocks in a file satisfy the above relationship, a file can be read or written at the rate of 2k blocks every revolution. The total transfer time T for a file of L blocks, including an average half-revolution latency of l6.7 ms. is (2) T = 16.7 + 1.62L ms. The block allocation scheme must therefore allocate block numbers that satisfy (l) in order to achieve this reduced transfer time. This is achieved by maintaining two lists of unused blocks on the disk. One list contains the block numbers in sorted order (i.e., successive blocks differ by 2, mod k8 where possible), while the other list contains unsorted block numbers. Blocks are allocated from the first list, and deallocated into the second list. When the list of sorted blocks is exhausted, the unsorted list is sorted out, emptied, and transferred back into the first list. To minimize accessing the disk for free block numbers, a copy of the top 6k words of the sorted list is kept in memory. Blocks are allocated from here until the list is emptied, at which point it is refilled from the disk. The disk layout is shown in Figure k. 11 ADD FREED BLOCKS HERE UNSQRTED. LIST SORTED LIST , ■■ !-*• OBTAIN NEW BLOCKS FROM HERE Figure h. Free Block Lists Sorting of free blocks takes place infrequently as there are 1359 blocks available (block is not used) . Sorting is done by the following algorithm: 1. An IR program segment for sorting is loaded into 3i+000 Q by DSKGET. 2. Banks and 1 are saved by BNKSWP. 3. The unsorted list is read into bank 0. h. The block numbers are sorted into one of hQ slots in bank 1 where block N is placed into slot N, mod kQ. 5. A scan is made of the slots starting at slot 0. A block number is removed and placed back into a list in bank 0. The scan examines every other slot and keeps removing blocks. If a slot is empty, the next sequential slot is examined. Note that slot follows slot hf . 6. Scanning stops when all slots are empty. 7. The free block lists are restored to the disk. 8. Banks and 1 and the program segment are restored. This procedure takes about 0.5 seconds, and guarantees that where possible, successive blocks differ by S, mod U8 where S is >_ 2 and minimal. Flowcharts for the main IR functions are shown in Figures 5-9. 12 INITIALIZE, GET PARAMETER RETURN CODE = ( IRDONE J 1 ' RETURN LENGTH AND RETURN VIA OPDONE RETURN CODE Figure 5. IRREQ Flow Diagram ( READ J 13 RETURN CODE = 1 ( IRDONE V SEARCH LOCAL DIRECTORY FOR FILE REQUESTS FILE FROM 360 SAVE FILE ON LOCAL DISK Figure 6. Read and Save Flow Diagrams 11+ RETURN CODE = k NO INCREMENT RETURN CODE BY 5 NO REQUEST DELETION IN 360 SEARCH LOCAL DIRECTORY DELETE FROM LOCAL DISK Figure 7. Delete Flow Diagram 15 IRDONE RETURN CODE = 3 WRITE SEARCH LOCAL DIRECTORY SEND TO 360 OVERLAY=YES Wl Figure 8. Write Flow Diagram (Part l) 16 SEND TO 360 OVERLAY=YES SEND TO 360 OVERLAY=NO YES i , RETURN CODE = 3 Figure 9. Write Flow Diagram (Part 2) IT LIST OF REFERENCES Gear, C. W. , Hyde, C, Levin, H. , Michel, M. J., Ratliff, K. , Wilkins, S., The Simulation and Modeling System , Department of Computer Science File No. 82^, University of Illinois, Urbana, Illinois, 1970. Michel, M. J. Graphical Remote Access Simulation System (GRASS), The Communication and Monitor System (GASP/GLASP) , Master's Thesis, Department of Computer Science, University of Illinois, Urbana, Illinois, February 1970). 3 Uth Quarterly Technical Progress Report , Section 3.2, Department of Computer Science, University of Illinois, Urbana, Illinois, 19&9. 18 APPENDIX A IR INTERNAL ROUTINES This appendix contains excerpts from the IR system that define the names and calling sequences of most of the internal routines It should prove helpful if it is ever necessary to expand the system. 19 GODISK Performs a disk transfer using locations defined in page of bank 3. BNKSWP TRANSFERS WORDS 1+-17777 CALLING SEQUENCE: TAD (BLK+DIR /0=WRITE, U000=READ JMS BNKSWP (RETURN) BLOCK NUMBERS ARE: 0, 2, U, 6, 10, 12, lU, l6 USES DISK WORDS DKC1 to DKC1+177777 DSKGET READS AND WRITES PROGRAM SEGMENTS AT 3^000-35777 CALLING SEQUENCE: TAD (BLK+DIR /BLK n| Date August 1970 FOR AEC USE ONLY '• AEC CONTRACT ADMINISTRATOR'S COMMENTS, IF ANY, ON ABOVE ANNOUNCEMENT AND DISTRIBUTION RECOMMENDATION: PATENT CLEARANCE: LJ a. AEC patent clearance has been granted by responsible AEC patent group. LJ b. Report has been sent to responsible AEC patent group for clearance. LJ c. Patent clearance not required. NOV 2 2 1972