:Info: raw_access.gi: 02/26/82 raw access Also referred to as the raw mode, it is the access mode granted a process to an object by discretionary access control. Raw access to an object is computed from the access control list (ACL), ring brackets, and AIM attributes of the object. See also access.info. :Info: ready_message.gi: 02/26/82 ready message A message that is printed each time a user is at command level. Printing this message may be inhibited, or the user may define his or her own ready message. The standard system ready message tells the time of day, the number of CPU seconds and pages of information brought into main memory since the last ready message, and the current listener level (if greater than 1). See the general_ready, ready_on and ready_off commands. :Info: record.gi: 02/26/82 record The term "record" has two meanings on Multics. In one sense, it means the smallest unit of disk allocation, containing 1024 36-bit words (4096 characters). In PL/I and FORTRAN, it means a block of data transferred during input or output. :Info: recursion.gi: 02/26/82 recursion The ability of a procedure to invoke itself. :Info: reference_name.gi: 02/26/82 reference name When a segment is made known to a process, particular names may be associated with it in that process. This is called initiation. Thereafter, a symbolic reference to this reference name is directed to the associated segment. Reference names need not be the same as any of the segment's entrynames. :Info: relative_pathname.gi: 02/26/82 relative pathname A pathname that names a segment in its relation to the working directory. :Info: retrieval.gi: 02/10/84 retrieval The process of copying a segment or directory back into the storage system hierarchy from backup tapes. Multics has two backup systems: volume and hierarchy. These backup systems copy segments and directories from the storage system hierarchy onto tapes at specified intervals. When you ask for a retrieval, you are asking the operator to copy your segment or directory from these tapes back into the storage system hierarchy. The operator can use tapes produced by either backup system to recover segments and directories. But the primary functions of the two kinds of backup tapes are different. See "Notes on backup tapes" next. Notes on backup tapes: Volume backup tapes are primarily used for recovery from major system failures which damage a large portion of the file system. An example of this is a head crash which causes physical damage to a disk pack. When this happens, all of the segments which reside on the damaged disk pack must be restored onto a new pack. Segments are written to volume backup tapes at frequent intervals. However, these tapes are normally retained only for short periods of time, perhaps two or three weeks, depending on site policy. Hierarchy backup tapes are primarily used for long term backup storage. Segments are written to hierarchy backup tapes at less frequent intervals. However, these tapes are normally retained for long periods of time, perhaps a year or more, again depending on site policy. The operator normally uses hierarchy backup tapes to recover individual segments and directories that you yourself have deleted or which have been damaged during a system crash (hardware, software or power failure). In addition to the fact that hierarchy tapes are retained longer, there is another major reason why they are usually used for individual retrievals. User segments are in sequential order on hierarchy tapes. They are not in sequential order on volume tapes, and in fact, may be spread over MANY tapes. Thus, fewer hierarchy tapes than volume tapes need to be mounted to do a retrieval. The procedure for requesting a retrieval varies. Your site should have its own help file spelling out its policy on requesting retrievals and explaining its schedule of when backup tapes are created. This help file should be kept in the directory called >doc>installation_info_segs (>doc>iis). If your site doesn't have a help file like this, please check with your System Administrator for the correct, exact procedure to follow at your site. Usually, the procedure involves sending mail to the operator. See "Notes on sending mail to operator" next. Notes on sending mail to operator: When you send mail to the operator, you should include the complete pathname(s) of the segment(s)/directory(ies) you want retrieved, and the approximate date and time they were last modified. Be sure to type the pathnames correctly, using capital letters when required. Use primary names of segments and directories, not add_names, because that makes it easier for the operator to find your files. If you are not certain of the date and time the version of the segment/directory you want to retrieve was modified, give the operator a range of dates and times within which you believe it was modified (e.g.: modified between May 16 and June 1; modified yesterday between 1230 and 1400). See "Examples of sending mail to operator" below. The operator will determine which (if any) backup system produced the tape copy of the segment or directory you want to retrieve. Whether or not your segment/directory can be retrieved depends on when and how long it was on the system, and what the backup schedule in place at your site is like. To understand the backup schedule, you need to know more about the backup systems. See "Notes on backup systems" next. Notes on backup systems: The procedure by which the volume and hierarchy backup systems copy segments and directories from the storage system hierarchy onto tape is called dumping. The segments and directories selected for dumping are determined by the mode -- incremental, consolidated, or complete -- in which the dumping is performed. An incremental dump locates and copies all segments and directories which have been created or modified since the last time an incremental dump was done. Its main function is to limit the amount of information that can be lost due to changes that have been made since the last incremental tape was created. A consolidated dump locates and copies all segments and directories which have been modified after some specified time in the past. Its main function is to consolidate the most recent information stored on a group of incremental tapes, thus decreasing the number of tapes which must be saved and processed. It does this by copying all segments which have been modified since the last consolidated dump. A complete dump locates and copies every segment and directory in the storage system without regard for when they were last modified. Its main function is to establish a checkpoint in time. If it's ever necessary to recover a major portion of online storage, the tape with the most recent complete dump on it marks a cutoff point, beyond which no older dump tapes are needed. Now you have enough background to understand a backup schedule. See "Examples of backup schedule" next. Examples of backup schedule: The following example shows a schedule of when different backup procedures could be run and how long the tapes they produce could be held. Keep in mind that some sites only run one of the backup systems, not both of them. Also keep in mind that segments and directories are only copied to incremental and consolidated backup tapes when they are newly created or when they have been modified. procedure interval retention Hierarchy Incremental every 12 hours 2 weeks Hierarchy Consolidated every Saturday 1 year Hierarchy Complete end of month 1 year (normally between 26th and 30th) Volume Incremental hourly 7 days Volume Consolidated daily (1800 hrs) 7 days Volume Complete 7 days 14 days Notes on backup schedule: The first three procedures shown in the example provide long term backup protection of the file system. The tapes they produce are the ones the operator normally uses for retrieving user segments and directories. The last three procedures shown in the example provide a method of recovering from major system crashes which damage the file system. The tapes they produce are mainly used for rebuilding physical volumes (disk packs) after they are destroyed by head crashes and have to be replaced. However, the tapes they produce can also be used to recover individual segments or directories. Examples of sending mail to operator: sdm Operator Subject: retrieval request Message: Please retrieve the following files: 1. >udd>Mcc>Johnson>test_A.fortran modified yesterday morning between 800 and 1000 2. >udd>Mcc>Johnson>file_B modified 1st week in February and deleted from system sometime in Apr. 3. >udd>Mcc>Johnson>file_C created four weeks ago last Tuesday and deleted the following day. 4. >udd>Mcc>Johnson>PLI (directory) as it was the end of Nov - 9 months ago. . If the schedule shown above under "Examples of backup schedule" was the one being used, the operator would be able to retrieve all of the segments and directories in this example except for # 3. Since # 3 was only on the system for one day, it was only captured on short term retention tapes that are overwritten in 2 to 3 weeks. If the retrieval request had been made within two weeks, the operator would have been able to retrieve the segment. If your site allows users to use the enter_retrieval_request command, you should refer to the description of that command. Remember that you can only use it to do a VOLUME retrieval. It doesn't work for a hierarchy retrieval. :Info: ring.gi: 02/26/82 ring A particular level of privilege at which programs may execute. Lower numbered rings are of higher privilege than higher numbered ones. The supervisor program runs in ring 0, most user programs run in ring 4. :Info: ring_brackets.gi: 02/26/82 ring brackets A set of integers associated with each segment that define in what rings that segment may be written, read, called, or executed. :Info: ring_structure.gi: 03/05/82 ring structure The structure of access control on Multics which is implemented by special hardware. Operation is controlled in such a way that the computer's work is done in a number of mutually exclusive subsets. These subsets may be considered concentric rings of privilege, representing different levels of access rights. The innermost or hardcore ring is made up of those segments essential to all users. This innermost ring, designated as ring 0, represents the highest level of privilege. The work of most users is done in ring 4. Ring 7 is the ring of least privilege. :Info: root.gi: 02/26/82 root The directory that is the base of the directory hierarchy. All other directories are subordinate to it. It has an absolute pathname of >. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved