1 02/28/85 test_io_daemon
 2 
 3 Syntax as a command:  test_io_daemon pathname
 4 or
 5 test_io_daemon -control_arg
 6 
 7 
 8 Function:  runs the I/O daemon subsystem in test mode in the user's
 9 process.
10 
11 
12 Arguments:
13 pathname
14    is the pathname of an iod_tables segment produced by the
15    iod_tables_compiler command.  The directory containing the
16    iod_tables segment is used as the test directory.
17 
18 
19 Control arguments:
20 -directory dir_pathname, -dr dir_pathname
21    specifies the pathname of a test directory.  The iod_tables segment
22    contained in the directory is used as the test iod_tables segment.
23 
24 
25 Notes:  For more details on the use of this command, refer to the
26 System Maintenance Procedures manual, Order No.  AM81.
27 
28 
29 List of requests:
30 coord
31    allows the coordinator part of your test process to come to command
32    level.  If you want to run just a coordinator, this request is the
33    only one you have to issue.  If you want to run both a coordinator
34    and a driver, you have to follow this request with the driver
35    request.
36 debug
37    calls the system debug command to allow you to set and reset break
38    points and execute interactive Multics commands (by using the ".."
39    debug request).  You may issue the debug request from both
40    coordinator command level and driver command level.  The system
41    response to this request is "Calling debug."
42 
43 
44 driver
45    allows the driver part of your test process to come to command
46    level.  If you want to run just a driver, this request is the only
47    one you have to issue.  If you want to run both a coordinator and a
48    driver, you have to preceed this request with the coord request.
49    Note:  the driver request is not accepted by the coordinator part of
50    your test process if you've suspended the driver part previously by
51    using the coord request.
52 
53 
54 pi
55    generates a program_interrupt signal.  This request allows you to
56    discard any undesirable output (or occurence) by generating a quit
57    signal, and to then return to the last stack frame with a
58    program_interrupt handler (i.e., debug or probe).  Normally, you use
59    this request to return to the debug or probe request after you've
60    interrupted one of its functions with a quit signal.  You may issue
61    this request from both coordinator command level and driver command
62    level.
63 probe
64    calls the system probe command to allow you to set and reset break
65    points and execute interactive Multics commands (by using the ".."
66    probe request).  You may issue the probe request from both
67    coordinator command level and driver command level.  The system
68    response to this command is "Calling probe."
69 
70 
71 resume
72    directs the driver to attempt recovery from iodd signal command
73    level (in test mode, the driver will not attempt recovery of error
74    conditions, but instead, after all error messages are displayed,
75    will stop at iodd signal command level) or to return to normal
76    command level from request command level or to quit command level
77    (aborting any current request), as if it were not in test mode.  You
78    may only issue this request at driver command level.
79 
80 
81 return
82    does the same thing as the logout command, except that it doesn't
83    display any messages.  You may issue this request from both
84    coordinator command level and driver command level.  When you issue
85    it from driver command level, your process returns to coordinator
86    command level (assuming you were running both a driver and a
87    coordinator).  The coordinator is not notified that the driver has
88    logged out.  When you issue the return request from coordinator
89    command level, the entire coordinator/driver test environment is
90    released and your process returns to the original process command
91    level.