02/06/81: The process preservation facility allows an interactive process to be preserved if it becomes disconnected from its login terminal due to a phone hangup or an FNP crash. The process is preserved until the site's maximum inactive time has elapsed. During this time, the user can call back, log in, and request reconnection to the disconnected process. Other options include destruction of the disconnected process (with or without creation of a new process), or creation of an additional process (for users with permission to have multiple interactive processes). Saving processes: The project and the user must both be given the disconnect_ok attribute by the system and project administrator in order to have disconnected processes saved. The login control argument, -save_on_disconnect (-save) requests the saving of the process created by this login if it becomes disconnected. The project administrator can give a user the save_on_disconnect (save) attribute, which specifies a default of -save, eliminating the need to type the argument at each login. The -no_save_on_disconnect (-nosave) login argument can be used to override this default. The system administrator can enable the facility for all users on a project without modifying and installing the PDT, by giving the project both the disconnect_ok and save_on_disconnect attributes in the SAT. Note that this removes control of this facility from the project administrator. Connecting to a saved process: is controlled by a number of new login control arguments: -create, -connect, -new_proc, -destroy, -list. If a user who has a disconnected process logs in without specifying the disposition of the process by giving one of those arguments, the user is placed in the connect request loop, in which requests analogous to the new control arguments are accepted (create, connect, etc.) Type "help" in the connect request loop for more information. This information can also be seen while logged in, by typing "help connect_help", but note that the wording of this information assumes that the user is presently in the connect request loop. The reconnection process does deal correctly with the case where a user has multiple interactive processes, some of which are disconnected. The state of your process after you connect to it will be as if you had just hit the QUIT button: you may have lost some output and some typed ahead input, and you are at a command level one higher than you were before. (This is true unless you were in a subsystem that has its own QUIT handler, in which case the state of your process depends on how your subsystem responds to QUIT.) In the normal case, the message "Wait for QUIT" is printed on your terminal, followed, after some seconds, by "QUIT", and any other output that the process might produce, such as a ready message, messages sent by other users during the time of disconnection, etc. The start, release, or program_interrupt commands can be used, as appropriate, to abort or resume execution of the program that was running at the time of disconnection. The user is not restricted to those three commands - anything valid after a QUIT is valid after reconnection. Restrictions: Only a process using the tty_ dim to control its login terminal can be connected to. This excludes the ARPANET dim and any private dims. This restriction will be removed as time permits. Users with their own direct process overseers, and users running subsystems that do their own IPS masking and signal handling might encounter difficulties in saving, or reconnecting to, disconnected processes. Dealing with restrictions: To avoid having a saved process that cannot be connected to, either request a default of -nosave, or login -nosave when any of the above circumstances prevail (e.g., logging in over the ARPANET), or type the no_save_on_disconnect command in the process. This command takes no arguments, and produces no output; it causes the process to log itself out when it receives a sus_ signal. This can be reversed by the save_on_disconnect command, which is only effective if -save was in effect at login time, either by default or by use of the argument. If you have a disconnected process that will not respond to your connect attempt, use the new_proc or destroy requests to dispose of it. ----------------------------------------------------------- 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