:Info: update_seg: us: 07/20/86 update_seg, us Syntax as a command: us operation {arguments} {-control_arguments} Function: This command is used to define the contents of a modification and to install or de-install the modification in one or more system or user libraries. Refer to the "Installation Process" section below for more details. Arguments: operation designates the operation to be performed. See "List of Operations" below. arguments are optional arguments which depend upon the particular operation to be performed. Operation Groups: The operations permitted by update_seg are grouped into five functional categories, as shown below. _ set_defaults, sd | initiate, in | Creation operations print_defaults, pd _| _ add | delete, dl | Definition operations move, mv | replace, rp _| _ print, pr | Listing operations list, ls _| _ install | Installation operations de_install _| _ clear _| Clearing operation The creation operations create and initiate an installation object (io) segment in which a modification is defined. The definition operations define the segments of the modification, and the steps which must be performed to install those segments. The listing operations list the segments of the modification and the installation steps to be performed for those segments. The installation operations install and de-install the modification. Finally, the clearing operations reset an io segment when an installation has failed and the modification has been installed. List of operations: add defines a segment which is to be added to a library. clear clears all error codes set during a prior installation or de-installation operation. de_install de-installs the modification defined in an installation object segment. delete defines a segment which is to be deleted from a library. initiate creates a new installation object (io) segment and initiates it for use by update_seg. install installs the modification defined in an io segment. list creates an installation listing segment containing information about an io segment. move defines a library segment to be moved to another library directory. print prints information about the modification defined in an io segment. print_defaults prints the default values associated with an io segment. replace defines a segment which is to replace another segment in a library. set_defaults sets the global default ACL, ring brackets, and documentation directory. Installation Process: A modification is a group of physically- or logically-related segments that must be installed in a library at the same time in order to maintain library consistency and integrity. For example, a source segment and its compiled object segment are physically-related segments which must be installed concurrently to ensure that library source segments correspond to library object segments. On the other hand, two object segments that interact with one another are logically-related segments that must be installed concurrently to ensure proper operation. The update_seg command is the library maintainer's interface to the Multics Installation System (MIS). MIS installs the related segments of a modification into a library at the same time (or nearly so): 1. by dividing the installation of each segment into a series of steps (getting the unique id, names, and ACL of new and old segments, copying the target segment, adding to and deleting from the target segment's names, freeing names on the old segment, etc). 2. by performing one step for all segments of the modification before moving on to the next step. 3. by installing the segments which are used by library users (e.g., object segments) as a group after installing the other segments in the modification (e.g., source segments, archives, and info segments). Using this strategy, the installation window (the period of library inconsistency) can be reduced to less than one minute per modification, and is usually about five seconds per modification. MIS offers several benefits to the library maintainer. The MIS subroutines which perform each installation step are all restartable. If a system failure or a process failure occurs during an installation, the installation can be resumed from the point of interruption, as long as the Multics Storage System remains intact across the failure. The MIS subroutines are also reversible. Each MIS subroutine performs a specific installation function when invoked in "installation" mode with a group of arguments. The same MIS subroutine will perform the logical inverse of its installation function (a de-installation function) when it is invoked in "de-installation" mode with the same group of arguments. If a bad modification has been installed, it can be removed from the libraries by invoking MIS in "de-installation" mode, without the use of supplementary tools or special procedures. MIS provides planned automatic error recovery. If MIS detects a fatal installation error, it can recover automatically from the error by invoking, in "de-installation" mode, the installation subroutines which completed before the fatal error occurred. Most common installation errors (name duplication, entry not found, record quota overflow, etc.) are handled in this manner. MIS allows a limited degree of rerunnability. All MIS subroutines are rerunnable after having been invoked in "de-installation" mode, as long as the segments in the modification have not been changed since the de-installation. The installer can correct many minor errors (e.g., name duplications) without having to start the installation from the very beginning. Finally, MIS automatically documents an installation. An MIS subroutine creates a description of a modification, and appends this description to an ASCII installation log as a part of the installation. In addition, a paragraph summarizing the modification can be inserted at the top of an installations info segment to notify users of changes to the libraries. update_seg stores the definition of a modification in an installation object (io) segment as a list of tasks. The task list consists of one or more task blocks, each representing a call to one of the MIS installation subroutines. The defined modification is installed by sorting these task blocks by type of installation step and calling the MIS subroutines associated with the order task blocks. The update_seg command interfaces with the MIS task list processor and installation subroutines to perform the definition and installation operations. Access required: Update_seg can install segments in any ring from 1 to 7 if the user has access to the installation_tools_ gate. If installation_tools_ is not accessible, then segments can be installed in any ring from the current ring of execution to ring 7. :Info: update_seg.add: us.add: 07/21/86 update_seg add operation Syntax as a command: us add new_seg target_seg {-control_args} Function: This operation defines a segment which is to be added to a library as part of a modification. The definition is appended to the currently-initiated io segment. The following installation steps are required for the most common case of the add operation. 1. Get the unique id of the new segment. 2. Get the names on the new segment. 3. Gather detailed information about the new segment for documentation of the installation. 4. Create a uniquely-named target segment in the library, and copy the contents of the new segment into the target segment. 5. Set the ring brackets on the target segment. 6. Set the ACL on the target segment. 7. Add the new segment's names to the uniquely-named target segment. 8. Remove the unique name from the target segment. 9. Document the addition of the new segment to the library. Arguments: new_seg is the pathname of the new segment to be added to the library. A relative or absolute pathname may be given. target_seg is the pathname of the target segment which is to be created in the library directory. A relative or absolute pathname may be given, and the Multics equal convention may be used to equate components in the final entrynames in the new_seg and target_seg pathnames. Note that an error will occur if the final entryname of the target_seg pathname is not one of the names placed on the target segment as it is installed. Control arguments: -acl mode1 User_id1 ... modeN {User_idN} defines the access control list (ACL) to be placed on the target segment. Normally the default ACL is used. Each access mode is paired with the access control name which follows. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -add_name names, -an names defines a list of names to be added to the target segment, where names are one or more entrynames. -archive, -ac specifies that the segment being defined in a definition operation is an archive, and that the names of its archive components are to be added to the target segment of the definition operation. Normally the archive component names are not added to the target segment. -defer, -df specifies that the installation subroutines which gather information about the segments in a definition operation should defer their information gathering until the installation operation is performed. Thus, changes made to the segment after the modification is defined will be reflected in the installed segment. Normally, name and ACL changes made between the definition and installation operations are not reflected in the installed target segment. Segment replacements during this period cause a fatal installation error. -delete_acl User_ids, -da User_ids defines a list of ACL entries which are to be removed from the ACL of the target segment of a definition operation. A User_id is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". -delete_name names, -dn names defines a list of names to be removed from the target segment of a definition operation, where names are one or more entrynames. -initial_acl, -iacl specifies that the Initial ACL (IACL) for segments of the target directory is to be placed on the target segment. -log specifies that detailed information about the installation of the target segment is to be logged in Installations.log. -max_length {N}, -ml {N} specifies that the maximum length attribute of the target segment of a definition operation is to be set. If N > 0, the maximum length is set of N words. If N = 0, the maximum length is set to the current length of the segment being installed. If N is omitted, the maximum length is set to sys_info$max_seg_size. If -max_length is omitted, the maximum length is set to sys_info$default_max_length for regular segments, and to the current length of the segment being installed for special segments. (See -special_seg below for information about special segments.) -name names, -nm names defines the list of names to be placed on the target segment, where names are one or more entrynames. Normally, the names on the new segment are placed on the target segment. -ring_brackets r1 {r2 {r3}}, -rb r1 {r2 {r3}} defines a set of ring brackets to be placed on the target segment, where r1 is the write bracket, r2 is the read bracket, and r3 is the gate bracket. If r2 is omitted, it is set to the maximum of the following values: the write bracket, the current validation level, or 5. If r3 is omitted, it is set to the maximum of the following values: the read bracket, the current validation level, or 5. It may not be specified unless r2 is also specified. Normally, the default ring brackets are placed on the target segment. -set_acl mode1 User_id1 ... modeN {User_idN}, -sa mode1 User_id1 ... modeN {User_idN} defines a list of ACL entries which are to be added to the ACL of the target segment. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -special_seg, -ss defines the target segment of a definition operation as a special segment. The properties of special segments are described below under "Special Segments." Special Segments: The -special_seg control argument is used to reduce the installation window for the user-visible segments of a modification. For example, if a modification contains two bound segments, one of which calls the other, then it is important to reduce the time between the installation of the first segment and the installation of the second. Otherwise, users of the first segment could receive errors when it tried to reference the second. To reduce the length of user-observable installation windows, the segments of a modification being installed in user search directories can be defined as special segments which have the following properties: 1. The final installation of all special segments (adding names to these segments) is deferred until all regular segments have been installed. 2. The de-installation of a modification causes the regular segments which were installed to be deleted from the library. Special segments are renamed instead of being deleted. 3. The default setting for the maximum length attribute of segments differs for special segments from that used for regular segments. Special segments use the current length of the segment being installed as the default maximum length. Regular segments use sys_info$default_max_length. Deferring the final installation of special segments until the last possible moment provides several desirable advantages. If a fatal error occurs while installing a regular segment, no special segments will have been installed and the user-visible portions of the libraries will remain in a consistent state. In addition, the installation window for special segments is shortened by grouping them together at the end of the installation, because there are fewer segments going through the final installation step (adding names) at the same time. This further reduces the user's exposure to library inconsistencies. Special segments cannot be deleted by a de-installation operation because some users may being using them. However, renaming the special segments prevents more users from using them after they have been de-installed. :Info: update_seg.clear: us.clear: 07/21/86 update_seg clear operation Syntax as a command: us clear {io_seg} {-control_args} Function: This operation clears all error codes set during a prior installation or de-installation operation. This allows the io segment to be printed or listed prior to a reinstallation of the modification without having prior error messages appear in the output. The clear operation also clears segment unique identifiers stored in the modification definition. These unique identifiers are stored to ensure that the segments defined in modification definition operations are those which are actually installed or de-installed. Clearing these identifiers disables such checking, and allows the de-installation of a modification whose segment unique identifiers have been reset by a Multics storage system reload. NOTE: Extreme care should be taken when clearing segment unique identifiers to ensure that the correct segments will be de-installed by the subsequent de_install operation. Arguments: io_seg is an optional argument which specifies the pathname of an existing io segment which is to be cleared. If the final entryname does not have an io suffix, then one is assumed. (See "Notes" below for a discussion of this argument.) Control arguments: -error, -er specifies that error codes stored in the modification definition are to be reset. -uid specifies that unique identifiers for the segments in the modification are to be reset, thus disabling unique identifier checking during subsequent installation and de-installation operations. Notes: If an io_seg argument is given with the clear operation, the named io segment is reinitiated and it remains initiated after the io segment has been cleared. Thus, all further update_seg operations refer to this initiated io segment. If no io_seg argument is given, then the currently-initiated io segment is cleared, if one is initiated. :Info: update_seg.de_install: us.de_install: 07/21/86 update_seg de_install operation Syntax as a command: us de_install {io_seg} {-control_args} Function: This operation de-installs the modification defined in an io segment. The modification must have been previously installed, either completely or partially. Arguments: io_seg is an optional argument which specifies the pathname of an existing io segment defining the modification to be de-installed. If the final entryname does not have an io suffix, then one is assumed. (See "Notes" below for a discussion of this argument.) Control arguments: -severity N, -sv N defines the severity level of fatal de-installation errors. All errors whose severity is equal to or greater than N are treated as fatal errors. N must be an integer from 1 to 5 inclusive. The default severity is 1, making all deinstallation errors fatal. (Refer to "Controlling the Fatality of Deinstallation Errors" below for a description of the severity levels associated with the various kinds of deinstallation errors.) -stop disables the automatic error recovery mechanism, causing update_seg to stop when a fatal deinstallation error occurs. (Refer to "Deinstallation Errors" below for more information.) Notes: If an io_seg argument is given with the de_install operation, the named io segment is reinitiated, and it remains initiated after the modification has been de-installed. Thus, all further update_seg operations refer to this initiated io segment. If no io_seg argument is given, then the modification defined in the currently-initiated io segment is de-installed, if one is initiated. Access required: As with the install operation, The Multics Installation System calls entries in the installation_tools_ gate in order to install Multics System Library segments into rings 1-7. If the library maintainer does not have access to this gate, then update_seg can install segments in rings from the current ring of execution to ring 7. Deinstallation Errors: If an error occurs during the deinstallation of a modification, a message is printed to diagnose the error. As with installation errors, the message for a deinstallation error has a Warning caption for a nonfatal error or an Error caption for a fatal error. A nonfatal error does not stop the deinstallation. A fatal error stops the deinstallation and automatically reinstalls the modification. When the stop control argument is given, a fatal error stops the deinstallation without reinstalling it. Controlling the Fatality of Deinstallation Errors: A given deinstallation error may be nonfatal or fatal, depending upon the severity level associated with that error, and upon the fatal severity level given by the library maintainer in the -severity control argument. The errors which fall into each severity level are described below: severity 1 Errors incurred while: restoring a name which is already on an old segment; removing a name which is not on the target segment; or deleting the target segment. severity 2 Errors incurred while: restoring a name on an old segment which is already on another entry in the old segment's directory; removing the final name from the target segment; or resetting the ACL or ring brackets on the target segment. severity 3 All other errors. Correcting Fatal Deinstallation Errors: Fatal deinstallation errors usually occur because the segments in the target directory (or their attributes) have been changed since the modification was installed. Such modifications could occur: if a subsequent modification affected one or more of the segments of the modification; if the Multics storage system was reloaded, causing a new unique identifier to be assigned to each segment; if a system crash forced the target directory to be salvaged; etc. The proper corrective action for most deinstallation errors involves returning the segments in the modification to their state just after installation. In some cases, this may be as simple as deinstalling a subsequent modification. In other cases, returning to the installation state may be undesirable. For example, the deinstallation of a subsequent modification could restore a module with a serious bug. It might be better to replace all bad modules with fixed versions if these are available, rather than restoring to modules with worse bugs. In some cases, returning to the installation state may be impossible. It would be very difficult to restore the unique identifiers for segments in a reloaded directory. The update_seg clear -uid operation is provided to disable unique identifier checking by update_seg in such cases. However, it must be used with extreme caution. Without this checking, other segments besides those in the modification may be affected by the deinstallation. Finally, it may not be possible to restore segments in a salvaged directory to their original state. In such cases, it may be necessary to use -severity 4 in the de-install operation to de-install other portions of the installation, and then to de-install portions in the salvaged directory manually. Care must be taken in such operations, because the library will be inconsistent until both the automatic and manual de-installation operations are complete. Having such a large de-installation window may necessitate performing the de-installation during a special session of Multics when users are not allowed to log on. Recovering from a Crash: As with an install operation, a de-installation interrupted by a system crash can be restarted by using the de_install operation, or can be reversed by using the install operation. :Info: update_seg.delete: update_seg.dl: us.delete: us.dl: 07/21/86 update_seg delete (dl) operation Syntax as a command: us dl target_seg {-control_args} Function: This operation defines a segment which is to be deleted from a library as part of a modification. The definition is appended to the currently-initiated io segment. The following steps are required for the most common case of the delete operation. 1. Get the unique id of the segment to be deleted (the target segment). 2. Get the names on the target segment. 3. Gather detailed information about the segment being deleted for documentation of the installation. 4. Add a unique name to the target segment. 5. Free the names on the target segment. 6. Document the deletion of the target segment from the library. At the time of the installation operation, the segment is not actually deleted from the library. Instead, the segment's names are freed and a unique name is added to the segment to mark it as a candidate for deletion by the library_cleanup command at some later date. The segment cannot be deleted because it cannot be terminated in the process of any library user who might be using it. The segment's names are freed by adding an integer suffix to the primary segment name, as described in the lfree_name command description in Section XIII; and by deleting any other names on the segment. The renamed primary name is retained to identify the segment. The remaining names are deleted to prevent library users from referencing the segment. Arguments: target_seg is the pathname of the segment to be deleted from the library. A relative or absolute pathname may be given. Control arguments: -defer, -df specifies that the information gathering in steps 1-3 above is to be deferred until the installation operation. -log specifies that detailed information about the deletion of the target segment is to be logged in Installations.log. -special_seg, -ss defines the target segment to be a special segment. The properties of special segments are described below under "Special Segments." Special Segments: The -special_seg control argument is used to reduce the installation window for the user-visible segments of a modification. For example, if a modification contains two bound segments, one of which calls the other, then it is important to reduce the time between the installation of the first segment and the installation of the second. Otherwise, users of the first segment could receive errors when it tried to reference the second. To reduce the length of user-observable installation windows, the segments of a modification being installed in user search directories can be defined as special segments which have the following properties: 1. The final installation of all special segments (adding names to these segments) is deferred until all regular segments have been installed. 2. The de-installation of a modification causes the regular segments which were installed to be deleted from the library. Special segments are renamed instead of being deleted. 3. The default setting for the maximum length attribute of segments differs for special segments from that used for regular segments. Special segments use the current length of the segment being installed as the default maximum length. Regular segments use sys_info$default_max_length. Deferring the final installation of special segments until the last possible moment provides several desirable advantages. If a fatal error occurs while installing a regular segment, no special segments will have been installed and the user-visible portions of the libraries will remain in a consistent state. In addition, the installation window for special segments is shortened by grouping them together at the end of the installation, because there are fewer segments going through the final installation step (adding names) at the same time. This further reduces the user's exposure to library inconsistencies. Special segments cannot be deleted by a de-installation operation because some users may being using them. However, renaming the special segments prevents more users from using them after they have been de-installed. :Info: update_seg.initiate: update_seg.in: us.initiate: us.in: 07/21/86 update_seg initiate (in) operation Syntax as a command: us in {io_seg} {-control_args} Function: This operation is the first operation required to install a modification. It creates a new installation object (io) segment and initiates it for use by update_seg. Only one io segment can be initiated in a process at any given time. This restriction allows the library maintainer to omit the io segment name from most update_seg operations. When the io segment name is omitted, then the operation refers to the io segment which is currently initiated. This is usually the io segment segment named in the last initiate operation. Besides creating new io segments, the initiate operation can be used to switch to and initiate another existing io segment, or to change the attributes of an existing io segment. Arguments: io_seg is the pathname of the io segment to be initiated. If the final entryname does not have an io suffix, then one is assumed. If io_seg is omitted, then the attributes of the currently-initiated io segment are changed. Control arguments: -acl mode1 User_id1 ... modeN {User_idN} defines the default access control list (ACL) used by the initiated io segment. This ACL is placed on new segments being added to a library when no -acl control argument is given in an add definition operation. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. Normally, the global default ACL is used as the default ACL on a new io segment. Use the update_seg print_defaults operation to print the global default ACL. -fill, -fi reformats the text of the modification summary entered with the -log control argument. Reformatting is done similar to the "fill-on" and "align-left" controls of the compose command. (default) -log indicates that a summary of the modification is to be typed in as part of the initiate operation. This summary is placed in one or more documentation segments, as described under "Automatic Documentation" below. Normally, no summary is associated with a new io segment. -no_fill, -nfi uses the modification summary exactly as typed. -restart, -rt indicates that the io segment identified by io_seg exists and is to be reinitiated. Normally a new io segment is created when io_seg is given. -ring_brackets r1 {r2 {r3}}, -rb r1 {r2 {r3}} defines the default ring brackets used by the initiated io segment. These ring brackets are placed on new segments being added to a library when no -ring_brackets control argument is given in an add definition operation. r1 is the write bracket, r2 is the read bracket, and r3 is the gate bracket. If r2 is omitted, it is set to the maximum of the following values: the write bracket, the current validation level, or 5. If r3 is omitted, it is set to the maximum of the following values: the read bracket, the current validation level, or 5. It may not be specified unless r2 is also specified. Normally, the global default ring brackets are used as the default ring brackets on a new io segment. Use the update_seg print_defaults operation to print the global default ring brackets. -set_log_dir path, -sld path gives the pathname of the documentation directory to be used by the io segment. Normally the working directory is used. Global Defaults: The global default ACL, ring brackets, and documentation directory have the values shown below: ACL: re *.*.* ring brackets: 1,5,5 documentation directory: working directory These values may be changed for the life of the library maintainer's process by using the set_defaults operation. The current global defaults may be printed by using the print_defaults operation. Automatic Documentation: The directory defined in a -set_log_dir control argument is called the documentation directory. Two types of information about a modification are logged in segments contained in this directory. Installations.info A summary of each the modification is inserted at the beginning of Installations.info. The library maintainer specifies this summary information in the update_seg initiate operation, via the -log control argument. This is a segment designed to inform users of recent changes to the libraries. Installations.log Detailed information about which segments and bound segment components are changed by the modification is appended to Installations.log, along with the summary described above. This log contains a permanent record of all installations. Use of these documentation segments is shared among several different update_seg installers by using a lock word in the segment Installations.lock. When the -log control argument is given, the initiate operation responds by printing "Input." All subsequent lines typed by the library maintainer are used as a summary of the modification being defined in the io segment. Input of the summary ends when the library maintainer types a line containing only a period (.). The summary is placed in both of the documentation segments when the modification is installed. When -fill is given or used by default, the summary lines are truncated or filled out to 65 characters to improve the readability of the documentation segments. A completely blank line or a line beginning with a space or horizontal tab (HT) character will force a break in the filling of the previous line. The summary of a modification can be changed at any point before the modification is installed (before an installation operation). Reinitiating the io segment with the -log control argument causes any previously-defined summary to be replaced by a new summary. The summary associated with any io segment can be printed by the "us print -log" operation. :Info: update_seg.install: us.install: 07/21/86 update_seg install operation Syntax as a command: us install {io_seg} {-control_args} Function: This operation installs the modification defined in an io segment. Arguments: io_seg is an optional argument specifying the pathname of an existing io segment defining the modification to be installed. If the final entryname does not have an io suffix, then one is assumed. (See "Notes" below for a discussion of this argument.) Control arguments: -severity N, -sv N defines the severity level of fatal installation errors. All errors whose severity is equal to or greater than N are treated as fatal errors. N must be an integer from 1 to 5 inclusive. The default severity is 1, making all installation errors fatal. Refer to "Controlling the Fatality of Installation Errors" later in this section for a description of the severity levels associated with the various kinds of installation errors. -stop disables the automatic error recovery mechanism, causing update_seg to stop when a fatal installation error occurs. (Refer to "Installation Errors" below for more information.) Notes: If an io_seg argument is given with the install operation, the named io segment is reinitiated and it remains initiated after the modification has been installed. Thus, all further update_seg operations refer to this initiated io segment. If no io_seg argument is given, then the modification defined in the currently-initiated io segment is installed. Any error codes which were set during a prior installation operation are automatically cleared before beginning the installation. This ensures that all errors which may be reported pertain to the current installation operation. Access required: The Multics Installation System calls entries in the installation_tools_ gate in order to install Multics System Library segments into rings 1-7. If the library maintainer does not have access to this gate, then update_seg can install segments in rings from the current ring of execution to ring 7. Installation Errors: If an error occurs during the installation of a modification, a message is printed to diagnose the error. Two types of errors may occur: nonfatal errors and fatal errors. The diagnostic message for a nonfatal error begins with a Warning caption, while that for a fatal error begins with an Error caption. Nonfatal errors do not stop the installation, but are merely diagnosed as they occur so that the library maintainer can take corrective action after the installation is complete. Fatal errors have a more serious impact on the installation. Normally, the occurrence of a fatal error stops the installation of the modification, and automatically de-installs all portions of the modification which were installed prior to the error. When the -stop control argument is given, the occurrence of an error merely stops the installation. The -stop control argument should be used with care because stopping the installation of a modification will probably leave the target library in an inconsistent state. When -stop is used, the library maintainer must recover from any installation errors as quickly as possible to reduce this period of inconsistency. Because the normal error recovery procedures minimize the period of library inconsistency and are so fast and easy to use, the -stop control argument is not recommended for general use. Controlling the Fatality of Installation Errors: A given installation error may be nonfatal or fatal, depending upon the severity level associated with that error and upon the fatal severity level given in the -severity control argument. The Multics Installation System defines four severity levels, numbered 1 through 4. One of these severity levels is assigned to each possible installation error, depending upon how severely that error impacts the installation. Errors with a high severity level impact an installation more severely than those with a lower severity. The errors which fall into each severity level are described below: severity 1 Errors incurred while: adding a name which is already on the target segment; deleting a name or ACL entry which is not on the target segment; or processing an archive with more than 100 components. severity 2 Errors incurred while: adding an invalid ACL entry to the target segment; adding a name which is already on another entry in the target directory; setting the target segment's bit count, maximum length attribute, or safety switch; deleting the final name from the target segment; and freeing the names on the old segment. severity 3 All other errors except for record quota overflows. severity 4 Record quota overflow errors. The library maintainer must determine which severity levels shown above contain errors fatal to the installation being performed. The maintainer should then set the fatal severity level for the installation by using the -severity control argument. Determination of the fatal severity level greatly depends on the type of modification being installed. A severity 1 error occurring during the modification of a heavily-used user search directory could have severe consequences for the library users, and would probably warrant a fatal severity level of 1. On the other hand, a severity 1 error occurring during the installation of new information segments into a documentation directory would have less impact on library users, since no users would be depending upon the new segments. A fatal severity level of 2 might be appropriate in this case. Low fatal severity levels are recommended for general use. The automatic error recovery for fatal errors is very fast and subsequent reinstallation of the modification is easy do to. High fatal severity levels should be used only in unusual circumstances and with extreme caution. Correcting Fatal Installation Errors: If a fatal installation error occurs, the normal error recovery procedure automatically de-installs all portions of the modification installed before the error occurred. The library maintainer can follow one of the two strategies below to correct the error: 1. If the error did not involve the definition of the modification (the contents, attributes or pathnames of any of the segments in the modification), then the library maintainer can correct the cause of the error and reinstall the modification using the install operation. An example of such an error is a record quota overflow in the target directory, or a name duplication between the target segment and an existing library entry. 2. If the error did involve the definition of the modification, then the library maintainer must redefine the modification correctly in a new io segment and reinstall the modification using the install operation. An example of such an error is an attempt to place the wrong name on a target segment causing a name duplication, or a -delete_name control argument attempting to delete the final name from a target segment. If the -stop control argument was given with the install operation, then the installation is stopped if a fatal error occurs without de-installing whatever portions of the modification were installed prior to the error. The library maintainer can follow one of three strategies to correct the error: 1. If the error did not involve the modification definition, the library maintainer can correct the error and continue the installation by using the install operation. 2. If the error did not involve the modification definition, the library maintainer can use the de_install operation to de-install the modification until the error is corrected, and then use the install operation to reinstall the modification. 3. If the error did involve the modification definition, the library maintainer must use the de_install operation to de-install the modification, must then redefine the modification correctly in a new io segment, and install that segment using the install operation. Recovering From a Crash: If the system should crash during an installation, or a fatal process error occur during an installation, then the installation of the modification can be continued by using the install operation. Alternately, parts of the modification installed prior to the crash can be de-installed by using the de_install operation. While it is usually safe to attempt to de-install a modification after a system crash, the de-installation will probably fail if the crash has affected any Multics storage system directory referenced as part of the modification. If such a failure occurs, it is necessary to complete the de-installation manually by using the l_free_name, l_set_ring_brackets, l_set_acl, l_delete, l_delete_name, and l_rename commands. :Info: update_seg.list: update_seg.ls: us.list: us.ls: 07/21/86 update_seg list (ls) operation Syntax as a command: us ls {io_seg} {-control_args} Function: This operation creates an installation listing segment containing information about an io segment. The listing segment is created in the working directory. If the listed io segment is named io_seg.io, then its listing segment is named io_seg.il. The installation listing normally contains the following information items. 1. The pathname of the io segment. 2. The date and time at which the installation listing was created. 3. The access identifier of the process which created the io segment. 4. The version of update_seg used to create the io segment. 5. The date and time at which the last creation, definition, or listing operation was performed on the io segment. 6. If the modification has been installed, the access identifier of the process which installed the modification and the date and time of installation. 7. If the modification has been de-installed, the access identifier of the process which de-installed the modification and the date and time of de-installation. 8. If the io segment has been cleared (see the description of "update_seg clear"), the access identifier of the process which cleared the io segment and the date and time of clearing. 9. The summary of the modification, if one was defined when the io segment was initiated. 10. A list of the definition operations performed on the io segment. This list includes the pathnames of the target segment, old segment, and/or new segment for each definition operation. 11. If the modification has been installed, a list of any errors which occurred during the installation. 12. A description of the modification which includes the following information for each modification segment: a. The type of definition operation (add, delete, replace, or move) and the pathnames of the target segment, old segment, and/or new segment given in the definition of each modification segment. b. A list of control arguments given in the definition operation. c. The names, ACL, and ring brackets to be placed on the target segment. d. The detailed information about each modification segment used to document the installation. Arguments: io_seg is an optional argument specifying the pathname of an existing io segment which is to be listed. If the final entryname does not have an io suffix, then one is assumed. (See "Notes" below for a discussion of this argument.) Control arguments: -brief, -bf suppresses item 12 above from the listing. -long, -lg appends to the listing a detailed description of the modification which includes the installation steps required to install each modification segment. Notes: If an io_seg argument is given with the list operation, the named io segment is reinitiated, and it remains initiated after the io segment has been listed. Thus, all further update_seg operations will refer to this initiated io segment. If no io_seg argument is given, then the currently-initiated io segment is listed, if one is initiated. The -brief and -long control arguments can be used together to provide a detailed description of the modification without the regular description outlined in item 12 above. The detailed description includes all of the information in the regular description. However, because of the length of the detailed description, it is often useful to have both the shorter regular description as a quick reference and the longer detailed description for an installation step reference. :Info: update_seg.print: update_seg.pr: us.print: us.pr: 07/21/86 update_seg print (pr) operation Syntax as a command: us pr {io_seg} {-control_args} Function: This operation prints information on the terminal about the modification defined in an io segment. One set of information is included for each segment of the modification. This information normally includes the following items. 1. The type of definition operation (add, delete, replace, or move), and the pathnames of the target segment, old segment, and/or new segment given in the definition of each modification segment. 2. A list of the control arguments given in the definition operation. 3. The names, ACL, and ring brackets to be placed on the target segment. 4. The detailed information about the modification segment to be included in Installations.log when the -log control argument was given in the definition operation. Arguments: io_seg is an optional argument which specifies the pathname of an existing io segment whose modification is to be printed. If the final entryname does not have an io suffix, then one is assumed. (See "Notes" below for a discussion of this argument.) Control arguments: -brief, -bf suppresses information items 2-4 given above from the printed output. -error, -er suppresses information about all modification segments except those that encountered an error during the most recent attempt to install or de-install the modification. The printed information includes the installation step in which the error occurred, and an error message describing the error. -log prints only the summary of the modification provided when the io segment was initiated. -long, -lg adds a list of the installation steps required to install each modification segment to the printed information. Notes: If an io_seg argument is given with the print operation, the named io segment is reinitiated and it remains initiated after the modification information has been printed. Thus, all further update_seg operations will refer to this initiated io segment. If no io_seg argument is given then the modification information for the currently-initiated io segment is printed. The -brief and -long control arguments can be used together to suppress information items 2-4 given in the list above while including a list of installation steps. Similarly, the -long and -error control arguments can be used together to print all of the installation steps, rather than just those in which an error occurred. :Info: update_seg.print_defaults: update_seg.pd: us.print_defaults: us.pd: 07/21/86 update_seg print_defaults (pd) operation Syntax as a command: us pd {io_seg} Function: This operation prints the global default ACL, ring brackets, and documentation directory. It also prints the default values associated with an io segment. The default documentation directory is printed only if different from the working directory. Arguments: io_seg is an optional argument which specifies the pathname of an existing io segment whose defaults are to be printed. If the final entryname does not have an io suffix, then one is assumed. Notes: If an io_seg argument is given with the print_defaults operation, the named io segment is reinitiated, and remains initiated after the defaults have been printed. Thus, all further update_seg operations will refer to this initiated io segment. If no io_seg argument is given, then the defaults of the initiated io segment are printed if one is initiated. :Info: update_seg.move: update_seg.mv: us.move: us.mv: 07/21/86 update_seg move (mv) operation Syntax as a command: us mv old_seg target_seg {-control_args} Function: This operation defines a segment which is a library segment to be moved to another library directory as part of a modification. The definition is appended to the currently-initiated io segment. The following steps are required for the most common case of the move operation. 1. Get the unique id of the segment to be moved (the old segment). 2. Get the names on the old segment. 3. Get the ACL on the old segment. 4. Get the ring brackets on the old segment. 5. Gather detailed information about the old segment for documentation of the installation. 6. Create a uniquely-named target segment in the other library, and copy the contents of the old segment into this target segment. 7. Set the ring brackets on the target segment to those on the old segment. 8. Set the ACL on the target segment to that on the old segment. 9. Add a unique name to the old segment. 10. Free the names on the old segment. 11. Add the old segment's names to the target segment. 12. Remove the unique name from the target segment. 13. Document the movement of the library segment. Arguments: old_seg is the pathname of the segment to be moved. A relative or absolute pathname may be given. target_seg is the pathname specifying where the old segment is to be moved to. A relative or absolute pathname may be given, and the Multics equal convention may be used to equate components in the final entrynames of the old_seg and target_seg pathnames. Note that an error will occur if the final entryname of the target_seg pathname is not one of the names placed on the target segment as it is installed. Control arguments: -acl mode1 User_id1 ... modeN {User_idN} defines the access control list (ACL) to be placed on the target segment. Normally the default ACL is used. Each access mode is paired with the access control name which follows. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -add_name names, -an names defines a list of names to be added to the target segment, where names are one or more entrynames. -archive, -ac specifies that the segment being defined in a definition operation is an archive, and that the names of its archive components are to be added to the target segment of the definition operation. Normally the archive component names are not added to the target segment. -defer, -df specifies that the installation subroutines which gather information about the segments in a definition operation should defer their information gathering until the installation operation is performed. Thus, changes made to the segment after the modification is defined will be reflected in the installed segment. Normally, name and ACL changes made between the definition and installation operations are not reflected in the installed target segment. Segment replacements during this period cause a fatal installation error. -delete_acl User_ids, -da User_ids defines a list of ACL entries which are to be removed from the ACL of the target segment of a definition operation. A User_id is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". -delete_name names, -dn names defines a list of names to be removed from the target segment of a definition operation, where names are one or more entrynames. -initial_acl, -iacl specifies that the Initial ACL (IACL) for segments of the target directory is to be placed on the target segment. -log specifies that detailed information about the installation of the target segment is to be logged in Installations.log. -max_length {N}, -ml {N} specifies that the maximum length attribute of the target segment of a definition operation is to be set. If N > 0, the maximum length is set of N words. If N = 0, the maximum length is set to the current length of the segment being installed. If N is omitted, the maximum length is set to sys_info$max_seg_size. If -max_length is omitted, the maximum length is set to sys_info$default_max_length for regular segments, and to the current length of the segment being installed for special segments. (See -special_seg below for information about special segments.) -name names, -nm names defines the list of names to be placed on the target segment, where names are one or more entrynames. Normally, the names on the new segment are placed on the target segment. -ring_brackets r1 {r2 {r3}}, -rb r1 {r2 {r3}} defines a set of ring brackets to be placed on the target segment, where r1 is the write bracket, r2 is the read bracket, and r3 is the gate bracket. If r2 is omitted, it is set to the maximum of the following values: the write bracket, the current validation level, or 5. If r3 is omitted, it is set to the maximum of the following values: the read bracket, the current validation level, or 5. It may not be specified unless r2 is also specified. Normally, the default ring brackets are placed on the target segment. -set_acl mode1 User_id1 ... modeN {User_idN}, -sa mode1 User_id1 ... modeN {User_idN} defines a list of ACL entries which are to be added to the ACL of the target segment. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -special_seg, -ss defines the target segment of a definition operation as a special segment. The properties of special segments are described below under "Special Segments." Notes: Just as in a delete operation, the old segment in a move operation is not deleted at the time of the installation operation. Instead, the old segment's names are freed, and a unique name is placed on the segment to mark it as a candidate for deletion by the library_cleanup command at a later date. Special Segments: The -special_seg control argument is used to reduce the installation window for the user-visible segments of a modification. For example, if a modification contains two bound segments, one of which calls the other, then it is important to reduce the time between the installation of the first segment and the installation of the second. Otherwise, users of the first segment could receive errors when it tried to reference the second. To reduce the length of user-observable installation windows, the segments of a modification being installed in user search directories can be defined as special segments which have the following properties: 1. The final installation of all special segments (adding names to these segments) is deferred until all regular segments have been installed. 2. The de-installation of a modification causes the regular segments which were installed to be deleted from the library. Special segments are renamed instead of being deleted. 3. The default setting for the maximum length attribute of segments differs for special segments from that used for regular segments. Special segments use the current length of the segment being installed as the default maximum length. Regular segments use sys_info$default_max_length. Deferring the final installation of special segments until the last possible moment provides several desirable advantages. If a fatal error occurs while installing a regular segment, no special segments will have been installed and the user-visible portions of the libraries will remain in a consistent state. In addition, the installation window for special segments is shortened by grouping them together at the end of the installation, because there are fewer segments going through the final installation step (adding names) at the same time. This further reduces the user's exposure to library inconsistencies. Special segments cannot be deleted by a de-installation operation because some users may being using them. However, renaming the special segments prevents more users from using them after they have been de-installed. :Info: update_seg.replace: update_seg.rp: us.replace: us.rp: 07/21/86 update_seg replace (rp) operation Syntax as a command: us rp new_seg old_seg {target_seg} {-control_args} Function: This operation defines a segment which is to replace another segment in a library as part of a modification. The definition is appended to the currently-initiated io segment. The following steps are required for the most common case of the replace operation. 1. Get the unique id of the segment to be replaced (the old segment). 2. Get the names on the old segment. 3. Get the ACL on the old segment. 4. Get the ring brackets on the old segment. 5. Get the unique id of the segment to replace the old segment (the new segment). 6. Get the names on the new segment. 7. Gather detailed information about the new segment for documentation of the installation. 8. Create a uniquely-named target segment in the library, and copy the contents of the new segment into this target segment. 9. Set the ring brackets on the target segment to those on the old segment. 10. Set the ACL on the target segment to that on the old segment. 11. Add a unique name to the old segment. 12. Free the names on the old segment. 13. Add the new segment's names to the target segment. 14. Remove the unique name from the target segment. 15. Document the replacement of the library segment. Arguments: new_seg is the pathname of the new segment to be installed. A relative or absolute pathname can be given. old_seg is the pathname of the library segment which is to be replaced. A relative or absolute pathname may be given, and the Multics equal convention may be used to equate components in the final entrynames of the new_seg and old_seg pathnames. Note that, if the target_seg argument is omitted, an error will occur if the final entryname of the old_seg pathname is not one of the names placed on the target segment as it is installed. target_seg is the optional pathname of the target segment, if this differs from the pathname of the old segment. A relative or absolute pathname may be given, and the Multics equal convention may be used to equate components in the final entrynames of the target_seg and old_seg pathnames. Normally the pathname of the old segment is formed by using the directory portion of old_seg and the final entryname portion of new_seg (i.e., [directory old_seg]>[entry new_seg]). Note that an error will occur if the final entryname of the target_seg pathname is not one of the names placed on the target segment as it is installed. Control arguments: -acl mode1 User_id1 ... modeN {User_idN} defines the access control list (ACL) to be placed on the target segment. Normally the default ACL is used. Each access mode is paired with the access control name which follows. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -add_name names, -an names defines a list of names to be added to the target segment, where names are one or more entrynames. -archive, -ac specifies that the segment being defined in a definition operation is an archive, and that the names of its archive components are to be added to the target segment of the definition operation. Normally the archive component names are not added to the target segment. -defer, -df specifies that the installation subroutines which gather information about the segments in a definition operation should defer their information gathering until the installation operation is performed. Thus, changes made to the segment after the modification is defined will be reflected in the installed segment. Normally, name and ACL changes made between the definition and installation operations are not reflected in the installed target segment. Segment replacements during this period cause a fatal installation error. -delete_acl User_ids, -da User_ids defines a list of ACL entries which are to be removed from the ACL of the target segment of a definition operation. A User_id is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". -delete_name names, -dn names defines a list of names to be removed from the target segment of a definition operation, where names are one or more entrynames. -initial_acl, -iacl specifies that the Initial ACL (IACL) for segments of the target directory is to be placed on the target segment. -log specifies that detailed information about the installation of the target segment is to be logged in Installations.log. -max_length {N}, -ml {N} specifies that the maximum length attribute of the target segment of a definition operation is to be set. If N > 0, the maximum length is set of N words. If N = 0, the maximum length is set to the current length of the segment being installed. If N is omitted, the maximum length is set to sys_info$max_seg_size. If -max_length is omitted, the maximum length is set to sys_info$default_max_length for regular segments, and to the current length of the segment being installed for special segments. (See -special_seg below for information about special segments.) -name names, -nm names defines the list of names to be placed on the target segment, where names are one or more entrynames. Normally, the names on the new segment are placed on the target segment. -old_name, -onm specifies that the names on the old segment are to be placed on the target segment. Normally, the names on the new segment are placed on the target segment. -ring_brackets r1 {r2 {r3}}, -rb r1 {r2 {r3}} defines a set of ring brackets to be placed on the target segment, where r1 is the write bracket, r2 is the read bracket, and r3 is the gate bracket. If r2 is omitted, it is set to the maximum of the following values: the write bracket, the current validation level, or 5. If r3 is omitted, it is set to the maximum of the following values: the read bracket, the current validation level, or 5. It may not be specified unless r2 is also specified. Normally, the default ring brackets are placed on the target segment. -set_acl mode1 User_id1 ... modeN {User_idN}, -sa mode1 User_id1 ... modeN {User_idN} defines a list of ACL entries which are to be added to the ACL of the target segment. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -special_seg, -ss defines the target segment of a definition operation as a special segment. The properties of special segments are described below under "Special Segments." Notes: The -name and -old_name control arguments are mutually exclusive. If both are given in a replace operation, then the last one given is used. Just as in a delete operation, the old segment in a replace operation is not deleted at the time of the installation operation. Instead, the old segment's names are freed, and a unique name is placed on the segment to mark it as a candidate for deletion by the library_cleanup command at a later date. Special Segments: The -special_seg control argument is used to reduce the installation window for the user-visible segments of a modification. For example, if a modification contains two bound segments, one of which calls the other, then it is important to reduce the time between the installation of the first segment and the installation of the second. Otherwise, users of the first segment could receive errors when it tried to reference the second. To reduce the length of user-observable installation windows, the segments of a modification being installed in user search directories can be defined as special segments which have the following properties: 1. The final installation of all special segments (adding names to these segments) is deferred until all regular segments have been installed. 2. The de-installation of a modification causes the regular segments which were installed to be deleted from the library. Special segments are renamed instead of being deleted. 3. The default setting for the maximum length attribute of segments differs for special segments from that used for regular segments. Special segments use the current length of the segment being installed as the default maximum length. Regular segments use sys_info$default_max_length. Deferring the final installation of special segments until the last possible moment provides several desirable advantages. If a fatal error occurs while installing a regular segment, no special segments will have been installed and the user-visible portions of the libraries will remain in a consistent state. In addition, the installation window for special segments is shortened by grouping them together at the end of the installation, because there are fewer segments going through the final installation step (adding names) at the same time. This further reduces the user's exposure to library inconsistencies. Special segments cannot be deleted by a de-installation operation because some users may being using them. However, renaming the special segments prevents more users from using them after they have been de-installed. :Info: update_seg.set_defaults: update_seg.sd: us.set_defaults: us.sd: 07/21/86 update_seg set_defaults (sd) operation Syntax as a command: us sd {-control_args} Function: This operation sets the global default ACL, ring brackets, and documentation directory associated with an installation object (io) segment. Control arguments: -acl mode1 User_id1 ... modeN {User_idN} defines a new global default access control list (ACL). This ACL is placed on all segments being added to the library if -acl is not given in the "update_seg add" operation. modeI is any valid access mode for segments (eg, r re rw rew null n). User_idI is an access control name that must be of the form Person_id.Project_id.tag. Missing components in the access control name are assumed to be "*". If the last modeI has no User_idI following it, the user's Person_id and Project_id are assumed. -ring_brackets r1 {r2 {r3}}, -rb r1 {r2 {r3}} defines a new set of global default ring brackets. These ring brackets are placed on all segments being added to the library if -ring_brackets is not given in the "update_seg add" operation. r1 is the write bracket, r2 is the read bracket, and r3 is the gate bracket. If r2 is omitted, it is set to the maximum of the following values: the write bracket, the current validation level, or 5. If r3 is omitted, it is set to the maximum of the following values: the read bracket, the current validation level, or 5. It may not be specified unless r2 is also specified. -set_log_dir path, -sld path defines the directory identified by path as the directory containing the installation log and installation info segments. These segments are described further under "Automatic Documentation" below. Notes: If one or more control arguments listed above are omitted, then the corresponding global default value remains unchanged. Automatic Documentation: The directory defined in a -set_log_dir control argument is called the documentation directory. Two types of information about a modification are logged in segments contained in this directory. Installations.info A summary of each the modification is inserted at the beginning of Installations.info. The library maintainer specifies this summary information in the update_seg initiate operation, via the -log control argument. This is a segment designed to inform users of recent changes to the libraries. Installations.log Detailed information about which segments and bound segment components are changed by the modification is appended to Installations.log, along with the summary described above. This log contains a permanent record of all installations. Use of these documentation segments is shared among several different update_seg installers by using a lock word in the segment Installations.lock. All of these segments (or links to the segments) must appear in the log directory. :Info: update_seg.examples: us.examples: 07/21/86 Examples of update_seg Operation Examples: The following are typical examples of terminal sessions using update_seg to modify segments. Brief explanations of each command line typed by the user are given below each example. Example 1 ! update_seg initiate >udd>Multics>example1 ! update_seg add >udd>Multics>seg1 >sss>seg1 ! update_seg replace >udd>Multics>seg2 >sss>seg2 ! update_seg delete >sss>seg3 ! update_seg move >sss>seg4 >unbundled>seg4 ! update_seg install Installation beginning. Installation complete. ! update_seg list ! eor example1.il 1 request signalled, 0 already queued. Example 1 creates and initiates an io segment called example1.io in the directory >udd>Multics, using global default values for the default ACL and ring brackets. It defines a modification consisting of four segments. seg1 is to be added to >sss, with default ACL and ring brackets. seg2 is to replace segment >sss>seg2; the old segment's ACL and ring brackets are placed on the target segment. >sss>seg3 is to be deleted. >sss>seg4 is to be moved to the directory >unbundled. After definition the modification, it is installed. A listing is created showing the operations performed during the library modification, along with any errors which may have occurred. The listing in example1.il is then dprinted. Example 2 ! us initiate example2 -acl re User.Multics -rb 4 5 5 ! us add >udd>Multics>seg5 >sss>seg5 ! us add seg6 >sss>seg6 -acl re *.Multics -rb 1 5 5 ! us replace seg7 >sss>== -acl re User.Multics n * -ss -log ! us install Installation beginning. Copying special target segments. Adding names to special target segments. Installation complete. Example 2 creates an io segment called example2.io, setting the default ACL to re User.Multics and the default ring brackets to 4,5,5. Adds seg5 to the directory >sss, using the default ACL and ring brackets. Adds seg6 to >sss, with an ACL of re *.Multics.* and ring brackets 1,5,5. Replaces >sss>seg7 with a new version, with an ACL of re User.Multics.* and null *.*.* on the target segment. Put the ring brackets of >sss>seg7 on the target segment. Also treat the target segment as a special segment and log the modification of this segment in Installations.log. Example 3 ! update_seg initiate >udd>Multics>example1 -restart ! update_seg de_install De-installation beginning. Non-special target segments deleted. De-installation complete. ! update_seg de_install example2 De-installation beginning. Names removed from special target segments. Non-special target segments deleted. De-installation complete. ! update_seg list -long Reinitiates example1.io, the io segment created in Example 1 above. De-installs the modification defined in this io segment. Reinitiates example2.io, io segment created in Example 2. De-installs the modification defined in this io segment. Creates a listing segment, example2.il. Example 4 ! us initiate library -log Input. ! MCR 128: Fix bug in the delete command (bound_fscom1_) ! which prevented segments whose copy switch is on from ! being deleted. ! . ! us rp bound_fscom1_.s.archive >ldd>sss>s== -archive ! us rp bound_fscom1_.archive >ldd>sss>o>== -archive ! us rp bound_fscom1_ >sss>== -ss -log ! us install Installation beginning. Copying special target segments. Adding names to special target segments. Installation complete. Example 1 creates and initiates a new io segment called library.io. The -log control argument is used to add a summary of the modification to the io segment. This summary is inserted at the top of Installations.info, and appended to the end of Installations.log when the modification is installed. The modification replaces >ldd>sss>s>bound_fscom1_.s.archive, and >ldd>sss>o>bound_fscom1_.archive. Archive component names to the target archive segments, and the old segment's ACL and ring brackets are used. The modification replaces >sss>bound_fscom1_, logging the replacement of this segment in Installations.log and treating the target segment as a special segment. ----------------------------------------------------------- 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