!TITLE Introduction ! Programs running in a user process in EMAS 2900 have access to ! ! * the un-privileged instruction set of the 2900 series ! * a virtual memory, currently of 32 Mbytes ! * a set of procedures, collectively known as the "Director ! interface", which enables the process to do the following: ! ! a) create and access files ! b) perform interactive I/O ! c) handle error and asynchronous contingencies ! d) access "private" magnetic tapes ! e) send and accept inter-process messages ! ! Since the procedures comprising the Director interface do not provide ! facilities for program compilation, loading or execution, it is ! assumed that most users of the System will wish either to adopt an ! existing set of such facilities or to write their own. Such a set ! of facilities is known as a "subsystem". The appearance of EMAS ! 2900 to a user is determined by the appearance of the subsystem he ! is using. ! ! There is available with EMAS 2900 the "Edinburgh Subsystem", which ! provides facilities for developing and running user programs and ! packages. This subsystem is used in Edinburgh University, its ! appearance to users is described in Ref. 1. ! ! It is not intended, however, that the Edinburgh Subsystem need ! provide the only user interface to the System, but that other ! installations should be free to provide their own subsystems, ! reflecting their particular requirements. This manual describes ! the facilities available to the writers of such subsystems. ! Familiarity with "EMAS 2900: Concepts" (Ref. 2) is essential. ! ! It has been a design principle of EMAS 2900 that a user process may ! not interfere, intentionally or otherwise, with any other process. ! At the same time, if a subsystem does not use the Director interface ! correctly, the process can easily disappear without trace, ! particularly before establishing workable contingency handling. The ! facilities described here are intended to allow a subsystem to be ! built in an incremental way from an interactive terminal, and ! avoiding such pitfalls. Since a very considerable amount of basic ! work has already been established in the form of the Edinburgh ! Subsystem, it would be reasonable to expect that: ! ! a) A new subsystem would be prepared using the facilities of the ! Edinburgh Subsystem. ! ! b) A new subsystem would be created in the Edinburgh standard object ! file format. !<Conventions ! In general, use should be made of the "EMAS 2900: Concepts" manual ! (Ref. 2), which contains a glossary of terms used in this and other ! EMAS 2900 documents. The following notes supplement that glossary ! and describe additional relevant terms. ! ! Local Controller, Supervisor ! In this manual the terms "Local Controller" and "Supervisor" are ! used to describe resident supervisory code concerned with ! controlling the user process. ! ! File system number, disc number ! EMAS disc-packs have two decimal digits as the last two characters ! of the 6-character label, e.g. EMAS02. The decimal number which ! the pair of digits represent is called the disc number or the ! file system number (interchangeably). ! ! System disc ! System start-up comprises IPL followed by the loading into main ! store of a Supervisor (Global Controller, Local Controller and ! device handlers) from a specified site on a specified disc. ! That disc is called the "System disc" (or IPL disc or SLOAD disc) ! for the session, since from that same disc various System components ! are used by default: Director, permanent processes 1, 2, 3 and 4 ! (respectively called DIRECT, VOLUMS, SPOOLR and MAILER), and the ! Edinburgh Subsystem. The sites containing the code and GLAP (see ! below) for these components are connected into the virtual memory of ! each user process, as appropriate, and paged from their respective ! sites on the System disc. ! ! GLAP, GLA ! In the Edinburgh standard object file format, code and certain ! other areas are shareable. However, the area which contains the ! following components is fundamentally unshareable, it also needs ! to be written to at program load time and during execution: ! ! a) global variables (perhaps having initialisation values) ! b) references to code and data areas in other modules ! c) code and data entry descriptors in this module ! ! This area in the object file is called the GLAP (General Linkage ! Area Pattern). The initial action of a program load is to ! connect the object file into virtual memory, and then to make a ! copy of the GLAP into another segment which is writeable, and ! unshared by any other user process, leaving the complete object ! file (including the GLAP) available for shared use by other ! processes. The copy of the GLAP in the unshared segment is ! called the GLA (General Linkage Area). ! ! Main log and Director log ! System components are able to note chosen events either in the "main ! log" or in the Director log, 'DIRLOG'. When a current log file is ! full, or when the command D/PRINT (or D/DIRPRINT) is given to DIRECT, ! a new file is supplied and the old one is passed to SPOOLR. It is ! queued by SPOOLR until the JOURNAL system (Ref. 3) accepts it for ! analysis and long-term storage. When the D/PRINT command is given, ! a copy of the current file may also sent to the line printer queue, ! in SPOOLR. Director is able to monitor process start-up and other ! events - as described in this manual - by writing either to DIRLOG ! or, if specified, to a file belonging to the process owner. ! ! IMP80 programming language ! In this manual, programming entities and record formats are ! described in terms of the IMP80 programming language (Ref. 4). !> !<The File System ! The main principles and features are as follows: ! ! a) Each disc-pack is treated as a unit, all the files described by ! the indexes on a disc, reside on that disc. ! ! b) The file system is implemented "in process" and comprises ! provision of the following primitives, to be called by outer code ! (higher ACR, less privileged), in particular a subsystem: ! ! CREATE file ! CHANGE file SIZE ! DESTROY file ! CONNECT file ! DISCONNECT file ! ! Interfaces to lower ACR code are limited to the following ! requests: ! ! * MOVE or CLEAR section of disc space ! ! * CLAIM or FREE semaphore number conventionally associated with a ! file index or "bitmap". ! ! * For CONNECT and DISCONNECT, writing into or deleting from the ! "Master Page Tables" the relationships between the segment ! numbers of the virtual memory and groups of sections of disc ! space. The "Master Page Tables" reside in the Local Controller ! stack for the process, and the Local Controller organises the ! virtual memory hierarchy and the satisfying of page faults ! from the information therein. ! ! c) Just as the user accesses a file by requesting that it be ! CONNECTed into his virtual memory and then referencing the ! appropriate virtual addresses obtained, so the Director code, ! which implements the file system, creates and accesses the indexes ! and the "bitmaps" by CONNECTing them also into the virtual memory ! at a lower ACR level (more privileged) than that of the subsystem ! and the user. ! ! Director organises the file system in terms of epage units (see the ! Glossary in Ref. 2). A 100 Mbyte disc pack contains 24000 epages ! (approximately X'5E00'), and currently Director uses from X'40' or ! X'800' to X'5000' for the file system. (On a disc which may be used ! as a System disc, epages below X'800' are used for the IPL supervisor ! (Chopsupe), 3 versions of a main supervisor, 4 versions of Director, ! and so on.) The first 128 pages of the file system space are used for ! the "bitmap" for the disc pack, and for the file indexes for the files ! which reside on the disc-pack. ! ! The "bitmap" is an area containing one bit representing each epage on ! the pack, numbered from 0 to X'5E00' approximately. A zero bit means ! that the epage is free, a one bit that it is allocated. The bitmap ! is located at the start of the file system space, the indexes follow, ! and the users' file pages start beyond the indexes. The actual start ! page numbers are all constants in Director's code. ! ! Director allocates the users' files in maximum-sized units of one ! "section", 128 Kbytes. A file consisting of 1 segment has either 1 or ! 2 sections, and larger files have more sections as necessary. The file ! index contains a file descriptor giving the name of the file and a list ! of the starting epage numbers of each section of the file. When a ! CREATE request is made, Director searches the bitmap for ! a group or groups of the required numbers of free pages and sets the ! bits accordingly. For a CONNECT request, Director extracts the ! starting epage numbers of the sections of the file from the index and ! inserts them into the "claimed block" table and puts pointers from the ! "secondary segment" table to the claimed block table entries. The ! addresses of the starts of these tables are passed to Director at ! process start-up. ! ! To reference a file index, Director first searches the "name-number ! table", which relates owner names to index page numbers. When the ! entry for the file owner has been found, Director connects the relevant ! pages into virtual memory. ! ! N.B. Director connects bitmaps, name-number tables and indexes "on ! demand" into the user's virtual memory in segments (not ! accessible to the user) numbered between 16 and 31. For ! efficiency, the bitmap and name-number table for the pack on ! which the process owner's file index and files reside, and also ! the section containing the file index itself, are left ! connected for the duration of the process. !> !<References ! 1 EMAS 2900: User's Guide (describes the facilities of the ! Edinburgh Subsystem). ERCC (1979). ! 2 EMAS 2900: Concepts. ERCC, 2nd Edition (1978). ! 3 EMAS 2900: The JOURNAL System. ERCC (1979). ! 4 The IMP Language and Compiler. Stephens, P.D., Computer Journal, ! Vol. 17 no. 3 (1974). ! 5 The Primitive Level Interface. ICL internal document PSD 2.5.1 ! (1975). ! 6 EMAS 2900 Subsystem Note 9: Edinburgh Standard Object File ! Format. ERCC (1979). ! 7 The EMAS Director. Rees, D.J., Computer Journal, Vol. 18 no. 2 ! (1975). ! 8 EMAS 2900 System Note 4: EMAS 2900 System Calls. ERCC (1977). ! 9 EMAS 2900 Supervisor Note 4: Local Stacks. ERCC (1977). ! 10 EMAS 2900 Supervisor Note 1: PON Mechanism for Director. ERCC ! (1978). ! 11 EMAS 2900 Supervisor Note 15: Communications Record Format. ERCC ! (1979). !>