MULTICS DESIGN DOCUMENT MDD-017
To: MDD Distribution
From: George Gilcrease
Date: December 3, 1987
Subject: The Multics I/O SysDaemon
Abstract:
An overview of the operation of the I/O SysDaemon. The scope of
this document is a synopsis of the I/O SysDaemon software: a
description of the primary associated databases, and a narrative
of the order of events and communication between the I/O
SysDaemon coordinator process and a representative driver
process.
_________________________________________________________________
Multics Design Documents are the official design descriptions of
the Multics Trusted Computing Base. They are internal documents,
which may be released outside of Multics System Development only
with the approval of the Director.
i
MDD-017 The Multics I/O SysDaemon
CONTENTS
Page
Section 1 The Multics I/O SysDaemon - an Overview . 1-1
1.1 Operation of the I/O SysDaemon . . 1-1
1.2 I/O SysDaemon Security Features . 1-1
1.2.1 The User IO.SysDaemon . . . . 1-2
1.2.2 Action at Request Submission 1-3
1.2.3 Access Checking at Printing . 1-3
1.2.4 Checks After Printing . . . . 1-3
Section 2 I/O SysDaemon Databases . . . . . . . . . 2-1
2.1 >daemon_dir_dir Contents . . . . . 2-1
2.1.1 >ddd>io_daemon_dir Contents . 2-1
2.1.2 >ddd>cards Contents . . . . . 2-2
2.1.3 >ddd>io_msg_dir Contents . . 2-3
Section 3 I/O SysDaemon Program Modules . . . . . . 3-1
3.1 Program Modules . . . . . . . . . 3-1
3.2 The I/O SysDaemon Queues . . . . . 3-2
3.3 The I/O SysDaemon Coordinator . . 3-2
3.3.1 Entries in iodc_. . . . . . . 3-2
3.3.1.1 iodc_$iodc_init entry . 3-2
3.3.1.2 driver_signal entry . . 3-3
3.3.1.3 free_device entry . . . 3-4
3.3.1.4 new_driver entry . . . . 3-4
3.3.1.5 driver_command . . . . . 3-4
3.3.1.6 proc_dies label . . . . 3-5
3.3.1.7 command_level entry . . 3-5
3.4 Driver Processes . . . . . . . . . 3-6
Section 4 I/O SysDaemon Test Run . . . . . . . . . 4-1
4.1 Test iod_tables.iodt . . . . . . . 4-1
4.2 Test printer_info.rqti . . . . . . 4-2
4.3 Test script . . . . . . . . . . . 4-2
ii
The Multics I/O SysDaemon MDD-017
SECTION 1
THE MULTICS I/O SYSDAEMON - AN OVERVIEW
The software that handles local and remote printing, punching,
and card input is called the I/O SysDaemon. The I/O SysDaemon is
organized into a coordinator process and a number of driver
processes; a driver is associated with each local or remote
device.
_1_._1 _O_P_E_R_A_T_I_O_N _O_F _T_H_E _I_/_O _S_Y_S_D_A_E_M_O_N
The I/O SysDaemon normally is run with system message coordinator
terminals. For remote devices, partial control of the process is
from the device itself, using its card reader or input keyboard.
The system administrator sets up the environment in which this
facility runs by creating and modifying the I/O SysDaemon
databases, creating info segments or other information to inform
the user community of what is available, and setting up special
operator exec_coms or instructions. The operator runs the
facilities according to the instructions given by the system
administrator, taking care of the needs of the peripheral devices
and following special requests made by the system.
_1_._2 _I_/_O _S_Y_S_D_A_E_M_O_N _S_E_C_U_R_I_T_Y _F_E_A_T_U_R_E_S
The I/O SysDaemon incorporates certain features in support of the
access isolation mechanism (AIM). Every request processed by the
I/O SysDaemon has an access class. The access class of the
request is equal to the authorization of the process that
submitted the request. Each piece of output normally has an
access class banner:
ox for print requests, the access class banner appears on
the head sheet of each printout.
ox for punch requests on the local punch, the access class
banner appears in the flip cards at the beginning of
each deck.
1-1
MDD-017 The Multics I/O SysDaemon
However, if the access class of a request is system_low, and the
access class name for system_low is set to a null string (defined
in the installation_parms), then the access class banner is
omitted.
In the interest of security, it may be desirable to have requests
of the same type automatically separated according to access
class. The mechanism for separating output according to access
class is the "device_class", defined in the iodt_tables.iodt
source segment. Each request type can be partitioned into any
number of separate device classes. One or more devices may be
specified for each device class. When a driver process is
initialized, the operator normally indicates the device to be
run, and the request type. However, if device classes have been
defined for the request type, the operator must also indicate a
device class. This determines the access class range of requests
that the driver processes.
The interface with the AIM and processes using the I/O SysDaemon
may be divided into four areas: process characteristics of the
user IO on the project SysDaemon, action at the time a request is
submitted, access checking at the time of printing, and
processing after printing.
_1_._2_._1 _T_h_e _U_s_e_r _I_O_._S_y_s_D_a_e_m_o_n
The I/O software usually runs as the user IO on the project
SysDaemon, but may sometimes be the user RJE for remote
input/output, HASP for a hasp workstation, and in test mode may
be a privileged user who is performing I/O SysDaemon tests. From
a security view, the usual I/O SysDaemon users may be forced to
login only as consoleless daemons (that is, only by privileged
command from another process, and never as an interactive user)
by administratively locking their passwords.
IO.SysDaemon runs in ring 4, at system_high security level.
Additionally, in the start_up command file for the user IO,
segment and directory system privileges are set, but
communications, interprocess communication, ring 1, RCP resource
management, and security-out-of-service privileges are not given.
Since the default ACL entry of r *.SysDaemon.* is placed on most
segments when they are created, IO.SysDaemon has access to read
most segments on the system. The only unreadable segments are
those in rings 0 - 3, or those which explicitly deny access to
IO.SysDaemon or *.SysDaemon.
Security information for output files is audited by the I/O
SysDaemon software at various stages in the processing of a
request.
1-2
The Multics I/O SysDaemon MDD-017
_1_._2_._2 _A_c_t_i_o_n _a_t _R_e_q_u_e_s_t _S_u_b_m_i_s_s_i_o_n
At the time a user requests a segment to be output by the I/O
SysDaemon, a check is made in dprint_$access_check to determine
if the IO driver process which will perform the request will have
sufficient access to do so. The driver must have at least read
access on the target segment, and have status access on the
containing directory. In order to delete the segment after it
has been printed, the driver must have modify access at the
containing directory. In addition, a check is made to see if
user can read the segment (has read access from ring brackets,
and has an authorization equal to or greater than the
classification of the segment). If not, the request is denied.
At this time the printable string of the user's authorization
level is saved for possible use as banner information. The
user's authorization level is stored in the request entry for
later re-verification, for it is possible for a user's
authorization to be changed between the time of requesting a
segment be outputted, and the actual time this request is
satisfied.
The user may specify the -access_labels control argument to the
enter_output_request command, which will cause top and/or bottom
security labels to appear on his output. If -access_labels is
overridden by -label control, this overriding is audited.
_1_._2_._3 _A_c_c_e_s_s _C_h_e_c_k_i_n_g _a_t _P_r_i_n_t_i_n_g
A request has been enqueued, and the I/O Coordinator has selected
the request queue entry for outputting. Before the segment is
printed, the user's access to read the segment (ACL, ring and
authorization stored with the request) is revalidated. If there
is not sufficient access, the request is denied, and a security
audit message is issued. If there is a difference in what
authorization string is stored in the request for labels, and the
users's authorization, or if authorization-level labels are
supressed, an audit message is generated.
_1_._2_._4 _C_h_e_c_k_s _A_f_t_e_r _P_r_i_n_t_i_n_g
If the user had requested that the output segment be deleted
after printing, the same regimen of access and security checks is
performed, with the same audit output as when the deletion was
requested, before the segment is deleted.
1-3
The Multics I/O SysDaemon MDD-017
SECTION 2
I/O SYSDAEMON DATABASES
The Multics I/O SysDaemon software depends on the existence of
certain directories and segments, the most important of which are
created and initialized at a new Multics site by the
acct_start_up.ec.
The main node of the I/O SysDaemon file hierarchy is the
directory named >daemon_dir_dir (>ddd).
_2_._1 _>_D_A_E_M_O_N___D_I_R___D_I_R _C_O_N_T_E_N_T_S
- io_daemon_dir (idd) directory, which holds all I/O SysDaemon
databases.
- cards directory, a storage pool for card deck images read by
the local card input process, or a remote station.
- io_msg_dir directory, containing mailboxes for each (station)
for the driver to driver message facility.
_2_._1_._1 _>_d_d_d_>_i_o___d_a_e_m_o_n___d_i_r _C_o_n_t_e_n_t_s
- coord_comm.ms, a ring 1 segment in which driver processes place
messages for the I/O SysDaemon coordinator.
- coord_lock, a segment used by the process overseer of the I/O
SysDaemon to prevent initialization of a driver process before an
I/O SysDaemon coordinator has been created, and prevents creation
of more than one coordinator.
- iod_tables, the master control table for the I/O SysDaemon
coordinator; compiled by the iod_tables_compiler command.
- iod_tables.iodt, source segment for iod_tables.
2-1
MDD-017 The Multics I/O SysDaemon
- iod_working_tables, the working copy of iod_tables used by
device drivers and users; copied from iod_tables during the I/O
SysDaemon coordinator initialization.
- iodc_data, a segment containing the process identifier of the
I/O SysDaemon coordinator and the event channel identifier to be
used by a new driver for initial communication with the
coordinator.
- printer_notice, an optional segment containing information the
site wishes to be printed on the page following the heading sheet
of every printer listing.
- xxx_n.ms, the ring 1 message segments for the I/O SysDaemon
queues, one for each priority queue of a request type, xxx is the
request type name, and n is the queue number (1 <= n <= 4).
- coord_dir directory, working storage for the I/O SysDaemon
coordinator, created and managed by the coordinator, having the
access class of the authorization of the coordinator.
- rqt_info_segs directory, which holds any request type info
segments used by drivers, its access class is system_low.
- <major device> directories, separate directories for each major
device currently being run by a device driver. These directories
are managed by the I/O SysDaemon coordinator and their names are
site dependent. Each major device directory contains a driver
status segment for each minor device associated with the major
device. The access class is the authorization of the device
driver.
_2_._1_._2 _>_d_d_d_>_c_a_r_d_s _C_o_n_t_e_n_t_s
The storage pool for card deck image segments consists of a
subtree of the directory hierarchy, which is headed by
>ddd>cards. One access class directory for each access defined
access class is contained in the cards directory. Storage is
allocated within the access class directory that corresponds the
process' authorization. Person directories are contained in the
appropriate access class directory, created for each person who
needs temporary storage. A person directory contains all
segments and multisegment files for a given person of a given
access class. For example, if a user with the Person_id of
Robertson is at system_low, the following directory is allocated
for his card deck image segments:
>daemon_dir_dir>cards>system_low>Robertson
2-2
The Multics I/O SysDaemon MDD-017
_2_._1_._3 _>_d_d_d_>_i_o___m_s_g___d_i_r _C_o_n_t_e_n_t_s
This directory contains mailboxes in the form <device>.mbx for
each device and remote station that uses the driver to driver
message facility.
2-3
The Multics I/O SysDaemon MDD-017
SECTION 3
I/O SYSDAEMON PROGRAM MODULES
_3_._1 _P_R_O_G_R_A_M _M_O_D_U_L_E_S
PROGRAM MODULES
+--------------+ +-------------+
| REQUEST | | REQUEST |
| QUEUE | | QUEUE |
+--------------+ +-------------+
| | | |
+--------------+ +-------------+
. +-------------+ .
. | COORDINATOR | .
. +-------------+ .
. | | .
. . . . . | | . . . . .
. +-------------+ .
. / | \ .
. / | \ .
. / | \ .
. / | \ .
+-------------+ +-------------+ +-------------+
| DRIVER | | DRIVER | | DRIVER |
+-------------+ +-------------+ +-------------+
| | | | | |
| | | | | |
+-------------+ +-------------+ +-------------+
| | |
| | |
+-------------+ +-------------+ +-------------+
| OUTPUT | | OUTPUT | | REMOTE |
| DEVICE | | DEVICE | | OUTPUT |
+-------------+ +-------------+ | DEVICE |
| | | | +-------------+
| | | | | |
+-------------+ +-------------+ +-------------+
3-1
MDD-017 The Multics I/O SysDaemon
_3_._2 _T_H_E _I_/_O _S_Y_S_D_A_E_M_O_N _Q_U_E_U_E_S
The program create_daemon_queues creates the I/O SysDaemon
message segments, normally under the >ddd>iod directory. Their
format is described in the include file iod_tables_hdr.incl.pl1,
and q_group_tab.incl.pl1. I/O SysDaemon program modules service
these request queues.
_3_._3 _T_H_E _I_/_O _S_Y_S_D_A_E_M_O_N _C_O_O_R_D_I_N_A_T_O_R
This is the central procedure of the I/O SysDaemon software.
Communication with driver processes and the coordinator process
is managed through entry points in iodc_, the main control
procedure of the coordinator. Most entries are enabled via event
wakeups.
_3_._3_._1 _E_n_t_r_i_e_s _i_n _i_o_d_c__
3.3.1.1 IODC_$IODC_INIT ENTRY
(Called by iodc_overseer_)
Function:
This is the main entry point for iodc_. It initializes the
coordinator and waits for drivers.
Tasks:
(1) the saved list of queue entries left by the last coordinator
is checked for segments to be deleted.
(2) the coord_dir directory is deleted to make sure it gets
recreated with the proper access class.
(3) make a subdirectory to hold the coordinator's writable data
segments (segments modified after initialization). This
subdirectory will be upgraded, if necessary, with a quota 250
records. Twenty-five records will be assigned.
(4) set up the needed data segments; make the coordinator's
private copy of iod_tables.
(5) complete the coordinator's initialization:
- initialize table pointers and other static information.
- set up message segment for new driver messages.
- place userid for each queue group on message segment acl.
- initialize other coordinator procedures.
3-2
The Multics I/O SysDaemon MDD-017
- delete all device directories and segments.
- initialize the device class table.
- set up the driver's event channels and the timer
channel for freeing saved requests.
3.3.1.2 DRIVER_SIGNAL ENTRY
(Wakeup from driver process)
Function:
This entry receives the wakeup from a driver process that has
just finished a request, or otherwise become ready for work, or
has just received a "restart", "save", or "logout" command.
Contained in the event message is a signal-type code, 0-5, which
identifies the drivers request. Process then, according to the
value of the signal-type (signal_label):
Tasks:
signal_label 0: driver is done with a request. signal_label 1:
driver wants a new request, and is done with a request.
(1) If the request has not been placed in the saved list, place
the request in the saved list.
(2) If signal_label is 0, then exit.
(3) If there is a request pending in the queues, or if a restart
is in progress, flag the next entry to select in the queues the
next time around.
(4) If no new request is found, free the request descriptor area,
and wakeup the driver, else fill in the request descriptor area
for the driver to use in satisfying the request, and wakeup the
driver.
(5) If the series number of output requests has reached a
multiple of 10,000, a new-series message is issued.
(6) exit.
signal_label 2: save the request signal_label 3: restart the
request
(1) For restart commands, record that requests for the device
class have been restarted, and look for the request from which to
restart. For save requests, scan through the requests, setting
all the "saved" bits in all the requests done of the specified
series. A restart or save of a given series is only allowed to
be performed by a driver of the same device class that the series
3-3
MDD-017 The Multics I/O SysDaemon
was originally done under. However, a driver with multiple minor
devices has one device class for each minor device, so even if
the minor device that actually sent the wakeup does not have the
matching device class, the action will be allowed if one of the
other minor devices does have the matching device class.
(2) If the sequence id specified in the restart or save request
is not found, a message is issued.
(3) If the series restarted or saved is in use, give the driver a
new series number.
(4) Send an acknowledgement to the requesting driver.
(5) Exit.
signal_label 4: driver logout command.
(1) The major device assigned to the driver proccess is freed;
exit.
signal_label 5: return driver command channel.
(1) The driver needs the event channel to send commands to line
drivers. Set the driver command channel; exit.
3.3.1.3 FREE_DEVICE ENTRY
(Called by iodc_)
Function:
This entry frees a major device for use by another driver.
Tasks:
(1) The process id assigned to the device is zeroed, and each
minor device is marked as inactive. The major device directory
and all contained driver stauts segments are deleted. If an
unfinished request is found for a minor device, that request is
made pending for the associated device class, and marked as
"continued".
3.3.1.4 NEW_DRIVER ENTRY
3.3.1.5 DRIVER_COMMAND
(Wakeups from drivers)
3-4
The Multics I/O SysDaemon MDD-017
Function and Tasks:
(1) If the driver command is restart, then go to the restart code
in signal_label (3).
(2) If the command is for a new driver, then initialize the new
driver data variables, open any queues needed by the driver,
modify the coordinator control databases to reflect the new
driver, send a wakeup to the new driver, then exit.
(3) If the command is to restart the queue, go to the head of the
queue for the driver and flush any normal waiting entries from
the waiting list, leaving priority requests, then exit.
(4) If the command is for a next request, the queues for the
driver are searched for a matching request, and that request is
threaded into the priority queue (1) for the driver, then exit.
(5) If none of the above commands, inform the requesting driver
of the error, then exit.
3.3.1.6 PROC_DIES LABEL
(Come here is process disaster)
Function and Tasks:
Issue message, all drivers will be reinitialized, then invoke the
"new_proc" command.
3.3.1.7 COMMAND_LEVEL ENTRY
(The coordinator command processor)
Function and Tasks:
(1) If the command is "help" then display the list of coordinator
commands.
(2) If the command is "start" then enable the coordinator.
(3) If the command is "return" then return if in test mode.
(4) If the command is "debug" then if in test mode, call debug.
(5) If the command is "probe" then if in test mode, call probe.
(6) If the command is "pi" then if testing, signal the
program_interrupt condition.
3-5
MDD-017 The Multics I/O SysDaemon
(7) If the command is "logout" then if in test mode, return, else
call logout.
(8) If the command is "print_devices" then print a list of
drivers and devices.
(9) If the command is "list" then print a list of active devices
controlled by the coordinator.
(10) If the command is "restart_status" then print a list of
restartable requests.
(11) If the command is "term" then terminate the requested
driver.
(12) If the command is "wait_status" then list all requests
waiting for devices by device-class.
(13) If the command is "driver" then if in test mode,
reinitialize for driver.
(14) If the command is none of the above, issue an error message,
ask for command again.
_3_._4 _D_R_I_V_E_R _P_R_O_C_E_S_S_E_S
The initialization procedure for all IO SysDaemon drivers is
iodd_$iodd_init. It is called (by iodc_) with two arguments:
system_dir, which defines the directory which
will contain common databases, and
testing, which indicates the driver is being
run in test mode.
This procedure determines from the operator which device is being
used, establishes communication with the coordinator, attaches
the device control terminal if needed, and transfers to the
driver control program specified in the iod_tables control file.
iodd_$iodd_init entry: Function and Tasks:
(1) Initialaize static/control variables.
(2) Initialize the control terminal.
(3) Find the tables in iod_working_tables so the requested device
and device class can be validated. Set pointers to the proper
tables.
(4) Attach the line if a master console, and wait for slave
dialup.
3-6
The Multics I/O SysDaemon MDD-017
(5) Find the major device in tables.
(6) Find each associated minor device and save the device index
and default device class from operator request: new_device,
quit, default, or "".
(7) Loop through the requested minor devices asking the
coordinator to establish this process as the driver process.
(8) If the coordinator allows this as a driver process, then
locate the driver status segment.
(9) Establish the accounting procedure to be used for each minor
device driver.
(10) If there is a request_type_info segment for the driver, then
associate the minor device with the request type name for
operator x command.
(11) Set up the event channel to communicate with the
coordinator.
(12) Set the entry variable for calling the driver module.
(13) Indicate to the coordinator that this driver is initialized.
(14) Call the driver initialize entry in the static io daemon
data to allow the driver process to begin work.
3-7
The Multics I/O SysDaemon MDD-017
SECTION 4
I/O SYSDAEMON TEST RUN
To illustrate the flow of execution and the communication between
the I/O SysDaemon coordinator process and a driver process, the
following test run is provided. The test shows the establishment
of a coordinator process, the logging in of a driver driver
process, and the printing of two requests from a request queue.
_4_._1 _T_E_S_T _I_O_D___T_A_B_L_E_S_._I_O_D_T
This .iodt source segment will be
converted by the iod_tables_compiler
command into binary format.
Time: 30;
Max_queues: 1;
Device: prta; Here, a line printer is defined.
driver_module: printer_driver_;
prph: prta;
default_type: printer;
Device: prtb; Another line printer is defined.
driver_module: printer_driver_;
prph: prtb;
default_type: printer;
Device: prtc; And another line printer is defined.
driver_module: printer_driver_;
prph: prtc;
default_type: printer;
(etc. to Device: prtg;)
Request_type: printer; The printer queues furthur defined.
generic_type: printer;
driver_userid: Gilcrease.Multics;
accounting: nothing;
4-1
MDD-017 The Multics I/O SysDaemon
rqti_seg: printer_info; This request-type information will
device: prta; be furthur defined in printer_info.rqti,
device: prtb; printed on the next page.
device: prtc;
device: prtd;
device: prte;
device: prtf;
device: prtg; End;
_4_._2 _T_E_S_T _P_R_I_N_T_E_R___I_N_F_O_._R_Q_T_I
rqti_seg: printer_info; This printer request type information
source segment will be converted by
driver_attributes: ^meter, ^auto_go; the cv_rqti_info command into binary
form. It describes some physical
driver_wait_time: 30; characteristics, and processing
mechanisms for the printer request
message: type.
"New printer driver using MR11.0 and printer_info
request type info seg.
Please load regular paper stock.
Check the alignment of the sample head sheet
and give driver the go command when ready.";
banner_type: standard;
banner_bars: single;
prt_control: auto_print, ^force_nep, ^force_esc;
paper_width: 136;
paper_length: 66;
lines_per_inch: 6;
line(1): 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16;
end;
_4_._3 _T_E_S_T _S_C_R_I_P_T
! dp -q 1 (test.output output.test)
1 request signalled, 0 already in printer queue 1
1 request signalled, 1 already in printer queue 1
! ldr
printer queue 1: 2 requests. 2 total requests.
204212.3 test.output
204213.4 output.test
4-2
The Multics I/O SysDaemon MDD-017
! test_io_daemon iod_tables
Enter command: coordinator, driver, or return:
! coord
CALL# RECURSION/HIGHEST ENTRYPOINT
-> 1 1/1 iodc_$iodc_init
I/O Coordinator Version: 3.2
-> 1 1/1 iodc_$free_device
<- 1 1/1 iodc_$free_device
-> 2 1/1 iodc_$free_device
<- 2 1/1 iodc_$free_device
-> 3 1/1 iodc_$free_device
<- 3 1/1 iodc_$free_device
-> 4 1/1 iodc_$free_device
<- 4 1/1 iodc_$free_device
-> 5 1/1 iodc_$free_device
<- 5 1/1 iodc_$free_device
-> 6 1/1 iodc_$free_device
<- 6 1/1 iodc_$free_device
-> 7 1/1 iodc_$free_device
<- 7 1/1 iodc_$free_device
I/O Coordinator initialized
-> 1 1/1 iodc_$command_level
! driver
-> 1 1/1 iodd_$iodd_init
-> 1 1/1 iodd_msg_
IO Daemon Driver Version: 5.7
Driver running in test mode.
<- 1 1/1 iodd_msg_
-> 2 1/1 iodd_msg_
Enter command or device/request_type:
<- 2 1/1 iodd_msg_
! prtc printer
-> 3 1/1 iodd_msg_
Requesting devices from coordinator.
<- 3 1/1 iodd_msg_
New driver for device prtc,
request type printer (series = 10000)
-> 1 1/1 iodc_$driver_signal
<- 1 1/1 iodc_$driver_signal
-> 1 1/1 printer_driver_$init
-> 4 1/1 iodd_msg_
New printer driver using MR11.0 and printer_info
request type info seg.
Please load regular paper stock.
Check the alignment of the sample head sheet
and give driver the go command when ready.
<- 4 1/1 iodd_msg_
-> 5 1/1 iodd_msg_
4-3
MDD-017 The Multics I/O SysDaemon
prtc driver ready at 08/15/86 1343.0 mst Fri
<- 5 1/1 iodd_msg_
-> 1 1/1 iodd_listen_
-> 1 1/1 iodd_get_cmd_
Enter command:
! go
<- 1 1/1 iodd_get_cmd_
-> 1 1/1 iodd_command_processor_
<- 1 1/1 iodd_command_processor_
-> 2 1/1 iodd_get_cmd_
<- 2 1/1 iodd_get_cmd_
-> 2 1/1 iodc_$driver_signal
<- 2 1/1 iodc_$driver_signal
-> 1 1/1 printer_driver_$request
-> 1 1/1 do_prt_request_
-> 6 1/1 iodd_msg_
Request 10001 printer q1: >udd>m>gg>ddd>idd>test.output
from gg.m.a
<- 6 1/1 iodd_msg_
-> 1 1/1 io_daemon_account_
<- 1 1/1 io_daemon_account_
-> 7 1/1 iodd_msg_
Charge for request 10001: $0.00 (71 lines, 2 pages)
<- 7 1/1 iodd_msg_
<- 1 1 do_prt_request_
<- 1 1/1 printer_driver_$request
-> 3 1/1 iodd_get_cmd_
<- 3 1/1 iodd_get_cmd_
-> 3 1/1 iodc_$driver_signal
<- 3 1/1 iodc_$driver_signal
-> 2 1/1 printer_driver_$request
-> 2 1/1 do_prt_request_
-> 8 1/1 iodd_msg_
Request 10002 printer q1: >udd>m>gg>ddd>idd>output.test
from gg.m.a
<- 8 1/1 iodd_msg_
-> 2 1/1 io_daemon_account_
<- 2 1/1 io_daemon_account_
-> 9 1/1 iodd_msg_
Charge for request 10002: $0.00 (71 lines, 2 pages)
<- 9 1/1 iodd_msg_
<- 2 1/1 do_prt_request_
<- 2 1/1 printer_driver_$request
-> 4 1/1 iodd_get_cmd_
<- 4 1/1 iodd_get_cmd_
-> 4 1/1 iodc_$driver_signal
<- 4 1/1 iodc_$driver_signal
-> 10 1/1 iodd_msg_
prtc driver: No requests, driver is idle.
<- 10 1/1 iodd_msg_
-> 5 1/1 iodd_get_cmd_
4-4
The Multics I/O SysDaemon MDD-017
<- 5 1/1 iodd_get_cmd_
-> 5 1/1 iodc_$driver_signal
<- 5 1/1 iodc_$driver_signal
-> 6 1/1 iodd_get_cmd_
! logout
<- 6 1/1 iodd_get_cmd_
-> 2 1/1 iodd_command_processor_
UW 2 1/1 iodd_command_processor_ unwound
UW 1 1/1 iodd_listen_ unwound
UW 1 1/1 printer_driver_$init unwound
-> 11 1/1 iodd_msg_
<- 11 1/1 iodd_msg_
<- 1 1/1 iodd_$iodd_init
Enter command.
-> 6 1/1 iodc_$driver_signal
-> 8 1/1 iodc_$free_device
<- 8 1/1 iodc_$free_device
Driver logout for device prtc
<- 6 1/1 iodc_$driver_signal
! logout
UW 1 1/1 iodc_$command_level unwound
<- 1 1/1 iodc_$iodc_init
-----------------------------------------------------------
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