03/31/83 Absentee facility A facility for requesting absentee processes is available to users. A user can request that a process be created that executes commands from a segment and places its output into a segment. To request an absentee computation, one first constructs an absentee control segment that is similar in syntax to an exec_com segment. The absentee process (when it is created for the user) reads from this control segment. The suffix of the control segment must be ".absin". Then the command enter_abs_request (ear) requests that an absentee process be created on behalf of the user. The output of this absentee process goes into an absentee output segment. The name of this output segment can be specified in the ear command. If the name is not specified, then the pathname of the control segment is used, except that its suffix is .absout. The user can delay the creation of the absentee process until after a specified time by means of the -time control argument to the ear command. If this option is not selected, at an arbitrary time in the future an absentee process is created for the requestor. Type "help enter_abs_request" or "help ear" for further discussion of this command. The resulting process is identical to an interactive process except that: 1) read operations from user_input are done from the absentee input segment. 2) write operations to user_output are directed to the absentee output segment. 3) special condition handlers are established for record_quota_overflow and cput. 4) any error intercepted by the standard unclaimed signal handler, except for command_error and command_question, logs out the absentee process. Two other commands are installed as part of the absentee facility-- 1) list_abs_requests (lar)--a command that gives the user information on the requests for absentee processes that the user has made. Type "help list_abs_requests" or "help lar" for more information. 2) cancel_abs_request (car)--a command that can be used to delete a request for an absentee process. For further details, type "help cancel_abs_request" or "help car". Examples: Suppose that a user wants to request an absentee computation to perform an offline compilation. The user creates a control segment called absentee_pl1.absin containing: cwd current pl1 x -table -source -symbols dp -dl x.list logout The command line-- enter_abs_request absentee_pl1.absin causes an absentee process to be created (some time in the future) that: 1) sets the working directory to a directory named current inferior to the user's default working directory. 2) compiles a pl1 program named x.pl1 with three control arguments 3) dprints one copy of the list segment. 4) logs out. The output of these tasks appears in the same directory as absentee_pl1.absin in a segment called absentee_pl1.absout. Notes: 1) The enter_abs_request command checks for the existence of the absentee control segment and refuses the request if it is not present. 2) An absentee process can be requested only for the Person_id and Project_id of the user submitting the request. 3) The facility is designed so that more than one absentee process can run at one time. The user should take care, when submitting several requests that use the same control segment, that the output of each request is directed to a different output segment (see enter_abs_request -output_file). 4) There can be both an interactive and an absentee process for the same user at the same time. 5) The who command denotes absentee users by placing an asterisk directly after person.project, for example "Green.Multics*". 6) The cancel_abs_request command can cancel a request for an absentee process that is already logged in. 7) The user can ask operations to bump or to cancel an absentee process. The difference is as follows. Bumping destroys the absentee process but allows the computation to begin again. Cancelling an absentee process prevents it from ever being restarted. This distinction is relevant only if the absentee computation was declared to be restartable via the -restart (-rt) control argument of the ear command. The user who contacts operations to destroy an absentee process should be sure to specify which function is wanted. 8) The new_proc command is an undefined command in an absentee process. It results in the termination of the absentee process. 9) For an absentee process to end properly, logout should be the last command encountered in the absentee control segment. If this condition is not met, an error message (indicating that the input is exhausted) is printed. 10) The absentee control segment should not be edited or its bit count changed during the course of the absentee process. This action causes unpredictable results. 11) Since the syntax of the absentee control segment is the same as an exec_com segment, the user should be aware of a few deviations. Certain exec_com requests are ignored in an absentee environment. Currently these are: 1) &attach 2) &detach 3) &command_line 4) &ready The reasons for these differences are-- 1 & 2) Input is already attached to the absentee input segment. 3) In an absentee process, command lines cannot be distinguished from input lines. 4) Unlike exec_com, control of the ready message can be achieved only by the ready_on and ready_off commands. All other control requests work normally. 12) The absentee facility provides a number of priority queues. The absentee commands (ear, lar, car) have a -queue control argument that allows the user to specify the particular queue desired. There are four queues. Site administrators can control the default queue used to submit requests when -queue isn't given to ear, pl1_abs, etc.; the cost of using each queue; scheduling parameters for absentee processes in each queue; and the lowest priority queue serviced on each shift. 13) The answering service enforces a limit stop (defined by the installation) on the cpu time that can be used by an absentee process. A user is able to specify a per-job time limit less than or equal to this maximum. Specification of a time limit causes a cpu timer to be established in the absentee process. Resetting all cpu timers makes the limit ineffective. 14) A user cannot convert his interactive process to an absentee process, nor his absentee process to an interactive one. 15) If a record quota overflow occurs during the execution of an absentee process, in some cases the end of the absentee output segment can be overwritten with a short message. 16) In an absentee process, cu_$set_cl_intermediary is invoked to set the procedure called by the standard unclaimed signal handler after outputting diagnostics. Thus, after getting a signalled error (except command_error or command_question), the standard unclaimed signal handler passes control to a procedure equivalent to logout. 17) An argument is passed to start_up.ec to indicate which type of process is being created. Type "help start_up.ec" for further details. 18) A resetread on user_input results in the termination of the absentee process. Procedures currently performing a resetread when handling errors include the following: basic debug edm qedx ----------------------------------------------------------- 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