02/28/85 test_io_daemon

Syntax as a command:  test_io_daemon pathname
or
test_io_daemon -control_arg


Function:  runs the I/O daemon subsystem in test mode in the user's
process.


Arguments:
pathname
   is the pathname of an iod_tables segment produced by the
   iod_tables_compiler command.  The directory containing the
   iod_tables segment is used as the test directory.


Control arguments:
-directory dir_pathname, -dr dir_pathname
   specifies the pathname of a test directory.  The iod_tables segment
   contained in the directory is used as the test iod_tables segment.


Notes:  For more details on the use of this command, refer to the
System Maintenance Procedures manual, Order No.  AM81.


List of requests:
coord
   allows the coordinator part of your test process to come to command
   level.  If you want to run just a coordinator, this request is the
   only one you have to issue.  If you want to run both a coordinator
   and a driver, you have to follow this request with the driver
   request.
debug
   calls the system debug command to allow you to set and reset break
   points and execute interactive Multics commands (by using the ".."
   debug request).  You may issue the debug request from both
   coordinator command level and driver command level.  The system
   response to this request is "Calling debug."


driver
   allows the driver part of your test process to come to command
   level.  If you want to run just a driver, this request is the only
   one you have to issue.  If you want to run both a coordinator and a
   driver, you have to preceed this request with the coord request.
   Note:  the driver request is not accepted by the coordinator part of
   your test process if you've suspended the driver part previously by
   using the coord request.


pi
   generates a program_interrupt signal.  This request allows you to
   discard any undesirable output (or occurence) by generating a quit
   signal, and to then return to the last stack frame with a
   program_interrupt handler (i.e., debug or probe).  Normally, you use
   this request to return to the debug or probe request after you've
   interrupted one of its functions with a quit signal.  You may issue
   this request from both coordinator command level and driver command
   level.
probe
   calls the system probe command to allow you to set and reset break
   points and execute interactive Multics commands (by using the ".."
   probe request).  You may issue the probe request from both
   coordinator command level and driver command level.  The system
   response to this command is "Calling probe."


resume
   directs the driver to attempt recovery from iodd signal command
   level (in test mode, the driver will not attempt recovery of error
   conditions, but instead, after all error messages are displayed,
   will stop at iodd signal command level) or to return to normal
   command level from request command level or to quit command level
   (aborting any current request), as if it were not in test mode.  You
   may only issue this request at driver command level.


return
   does the same thing as the logout command, except that it doesn't
   display any messages.  You may issue this request from both
   coordinator command level and driver command level.  When you issue
   it from driver command level, your process returns to coordinator
   command level (assuming you were running both a driver and a
   coordinator).  The coordinator is not notified that the driver has
   logged out.  When you issue the return request from coordinator
   command level, the entire coordinator/driver test environment is
   released and your process returns to the original process command
   level.


                                          -----------------------------------------------------------


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