SECTION 7

ADDITIONAL CONCEPTS

The purpose of this section is to explain several concepts that are important in computer technology and have somewhat specialized applications in Multics. Some of these concepts you've probably encountered already and others you no doubt soon will. The presentation here will stay mainly on the conceptual level, that is, with no explanation of the procedure for implementing the processes. Any applications demonstrated will be used simply for the purpose of illustrating how a concept is applied to a procedure.

ONLINE

Being online means being logged in, entering information and using information already stored in the system. In Multics, online is an interactive process in that the system responds immediately to the user's input. This way you do not have to prepare an entire job beforehand to be run all at once; instead, the system will interact with you.

A necessary additional aspect of interactive usage is time-sharing. Many users can interact with the system at the same time, even to the point of sharing the same segments simultaneously. For this reason, the system tells you each time you log in how many people are online and how many the system can accommodate at that time. And because the computer is shared this way, you may sometimes be preempted while working on the system.

ABSENTEE

Absentee, on the other hand, is a process that can be run when the user is not logged in and interacting with the system. Instead, the user prepares an entire job beforehand and has it run at a specified time. It is analogous to batch processing on other systems. And an absentee job is not a time-sharing process in the sense that online processes are. The absentee job is placed in a waiting line (a queue) and run as background to the normal interactive work on the system.

The principal difference between an absentee process and an interactive one is that in an absentee process the I/O switches are attached to special absentee segments instead of to a terminal. One of these segments is the control segment containing commands and other input data which you create with a text editor. The other is an output segment which stores the results of the absentee job. The system adds a third component to the User_id to distinguish absentee from interactive processes: absentee processes are labelled Person_id.Project_id.m while interactive processes use an "a" as the third component. These third components are called "instance tags."

The details of executing absentee processes are given with the enter_abs_request command in the MPM Commands.

Punched cards, when they are run on Multics, are processed in a batch similar to the manner in which absentee jobs are processed. The standard way of handling card decks in Multics is to place the deck in the card reader and read it into a system pool. You then log in on a terminal and transfer the card file from the system pool to your working directory using the copy_cards command. The segment that this command creates is stored in the system can be used in interactive and absentee processes, just as a segment created on a terminal would be used.

STORAGE SYSTEM

The segment is the basic unit of storage in the Multics system. It can vary in size, that is, in the amount of information it contains, and it may contain a collection of program instructions, text or other data, or it may be empty (a null segment). There is a limit to the amount of information that can be stored in a segment, but if any single collection of information is too long for one segment, it can be stored in a group of segments called a multisegment file.

Multics keeps track of segments by cataloging them in directories. The base directory, the one from which all other directories and all segments emanate, is called the root directory. Figure 1 uses a representation of an inverted tree to demonstrate the relation of user Tom Smith and his project, Pubs, to the root. (Directories are represented by rectangles and segments by lozenges.) Notice the two directories immediately under the root (sss and udd). The sss (system_library_standard directory) is one of several library directories that catalog all the system commands and subroutines. The udd (user_directory_directory) directory is a catalog of project directories. It contains one directory entry for each project on the system. Likewise, each project directory normally contains one directory for each user on that project.

The Multics system's virtual memory makes all segments in the storage system directly addressable. That means that in effect there is hardly any difference between main memory and secondary storage on Multics: information can be retrieved from storage virtually as fast as from memory.

Since the physical movement of information between secondary storage and main memory is totally automatic, its structure is of no concern to the user when working on a process. A user does not have to be concerned with where and on what devices the segments reside.

Figure 1. Hierarchical Storage System

SEARCH RULES

Whenever the user issues a command or references a program or other segment, the system must search through directories to find the specified command or program. This search is regulated by a list of search rules that specify a set of directories to be searched in a particular order. But the search rules that the system automatically follows may be changed or supplemented by the user. The set_search_rules command enables the user to change the default search rules, and the add_search_rules and delete_search_rules commands enable the user to add or delete search directories. To check your current search rules, you can invoke the print_search_rules command.

Adding another directory to be searched after the working directory is a convenient way for an entire project to share a group of special programs peculiar to the work of that project. After a user on the project adds this special directory to the search rules, any programs in that directory can be executed as easily as the system commands. This addition to the search rules means that each user on the project saves the time and cost of either copying each one of the programs or linking to each one.

Also, by manipulating the search rules, the user can determine whether a system command or a user-written command with the same name is to be used.

LINKING

Multics allows a user to create a link to a segment anywhere in the storage system, as long as access to the directory of the linked segment is available. By creating a link, you can reference another segment as though it were in the directory containing the link. In short, you can use this particular segment without actually having to make a copy of it.

Linking with the link command is not to be confused with dynamic linking. The latter is the Multics term for the mechanism in the system that provides a highly efficient means of referencing stored segments. It is enough, for our purposes here, to say that, with dynamic linking a segment must be searched for only once during a process. When a segment is found by using the search rules, its place in the storage system is remembered so that another search does not have to be made the next time the segment is needed.

BOUND SEGMENTS

A bound segment is a single executable segment made up of two or more separately compiled segments. Normally, you would bind program segments that you intend to execute together repeatedly. (See the bind command in MPM Commands.) Bound segments are easier for the user to process, and the system can run them much more efficiently than under the regular dynamic linking procedure. In fact, by binding segments you can not only save execution time, you can also save money through decreased computing time and storage space.

ARCHIVE SEGMENTS

Each segment in Multics is assigned space in increments of pages. Since this can result in quite a bit of blank space on the last page of segments, Multics provides the archive command to pack the contents of individual segments together into one archive segment. You can maintain control over these individual segments by invoking the archive command with different arguments, (see the archive command in MPM Commands). The advantage of archive segments is that they reduce the user's storage load and therefore cost.

EDITOR MACRO

In general computer terminology, macro refers to a group of executable statements. To that extent a macro is like an exec_com segment on Multics. But in Multics the term macro is applied only to a sequence of text editor requests. This sequence of requests, called an editor macro, acts like a program or exec_com. Placing it in a separate buffer preserves it for repeated application in the text editing environment.

<< Previous Section                                          Appendix A >>

Contents | 1 | 2 | 3 | 4 | 5 | 6 | 7 | A | B | C