11/16/88 mowse_io_ Function: The I/O module is responsible for controlling communications within MOWSE through data packetization, and dispatching received data to its appropriate handler. An "appropriate handler" is either a user_input queue which collects foreground data to be retrieved through calls to iox_$get_chars and iox_$get_line, or background applications which process background data packets. Syntax: mowse_io_ {switch_name} Arguments: switch_name Is the name of the io switch under which mowse_io_ will be attached. If none is given, then mowse_io_ will attempt to attach itself next to tty_. Notes: If tty_ does not exist, then attachment will fail. Opening: The opening modes supported are stream_input_output. Editing: Editing is not the responsibility of mowse_io_, it merely passes on editing requests to WSTERM. Buffering: This I/O module is responsible for the manipulation of two logical subchannels of data communications: foreground and background. Both of these subchannels will block awaiting the capability of transmitting characters. Input of characters is performed upon the arrival of a complete packet - signalled through the immediate call event channels and the wake_tbl/wakeup tty_ modes - where the input is sorted out and placed into the appropriate channel buffer. Retrieval and transmission of characters along the foreground subchannel will block to the calling routine awaiting the availability of characters or the capability of transmission of characters. List of entry points: The following is a list of all entry points in mowse_io_ available through calls to iox_ entrypoints. attach close detach_iocb get_chars The get chars operation reads as many characters as are available, up to but not exceeding the number requested by the caller. No error code is returned if the number read is less than the number requested, at least one character is always returned. The characters read may comprise only a partial input line, or several input lines; no assumptions can be made in this regard. get_line The get_line operation is supported. No error code is returned if the read operation occurs with the input buffer length at zero. For further explanation, see the iox_$get_line entry. modes open put_chars The put_chars operation is supported (see the iox_$put_chars entry). control Control orders accessible through calls to iox_$control provide the necessary additional functionality to the I/O module. These control orders allow the caller to access functionality specific to the I/O module. With mowse_io_ it has been necessary to provide control orders which are "visible" to the user as well as specialized orders which are to remain undocumented to the user. Following is a list of the control orders which are supported by mowse_io_ and require specific handling by mowse_io_. List of orders: For complete description of those orders not described, please refer to the appropriate Multics documentation. abort debug_on debug_off These orders allow all communications packets being sent and received both locally and remotely (PC) by Multics to be recorded into a specified Multics segment. The info_ptr points to the structure below (defined in mowse_io_control_info.incl.pl1) or can be null in which case the segment name "debug.mowse_io_" is default. dcl 01 mowse_io_debug_info based (mowse_io_debug_info_ptr), 02 version char (8), 02 segment_name char (32) var; where version Is the version number of the structure. It must be mowse_io_info_version_1. segment_name Is the name of the segment in the current working directory to which the packets will be recorded. get_editing_chars get_event_channel returns the identifier of the ipc_ event channel associated with the foregrond data event channel. The info_pointer should point to a fixed bin (71) aligned quantity into which the channel identifier is stored. get_input_conversion set_input_conversion Input translation by MOWSE is performed by WSTERM and will accept only one escape character, all other changes will be recorded and installed into tty_ when mowse_i/o is detached (see tty_). line_length printer_off printer_on These orders allow the printer facility to be turned on and off in order to specify read unechoed terminal characters. When these orders are specified, a control message is formulated to the PC MOWSE of the type PON/POFF. quit_disable quit_enable read_status reconnection Is the control order which is to be received by mowse_io_ when a reconnection to a disconnected process has been requested. It is mandatory that this control order be issued to mowse_io_ at reconnection, otherwise MOWSE will not operate correctly. Reconnection will be implemented in a later version of MOWSE. reset_read reset_write set_default_modes set_editing_chars set_term_type trace_on trace_off These orders allow all messages being sent and received by an application to be recorded in a specified Multics segment. The info_ptr points to the structure below (defined in mowse_io_control_info.incl.pl1), or can be null in which case the default segment name will be "trace.mowse_io_". dcl 01 mowse_io_debug_info based (mowse_io_debug_info_ptr), 02 version char (8), 02 segment_name char (32) var; where version Is the version number of the structure. It must be mowse_io_info_version_1. segment_name Is the name of the segment in the current working directory to which the messages will be recorded. write_status List of non-supported control orders: Because of the special need for mowse_io_ to control the communications aspect of the Multics process, the following control orders must be rejected by mowse_io_ as they will affect the functionality of mowse_io_ (these non-supported orders are list in mowse_io_bad_control.incl.pl1): get_chars_timeout get_line_timeout interrupt listen position put_chars_timeout start_xmit_hd stop_xmit_hd input_flow_control_info output_flow_control_chars set_framing_chars set_input_translation set_line_type set_output_translation set_wakeup_table send_initial_string set_event_channel wru modes The modes operation is supported when the I/O switch is open. The recognized modes are below. The modes string is parsed via the mode_string_ entries to parse the modes string. MOWSE requires full control over the communication modes in order to communicate effectively with the PC. Thus MOWSE will reset the modes to the manner in which mowse_io_ requires them. pl crecho more (ignored ) ll lfecho more_mode (ignored ) When a modes order is requested, in addition to "changing" the above modes, mowse_io_ will also issue a message along the foreground subchannel which is destined for the terminal emulator in order that it may make the necessary changes. Control operations from command level: The following is a list of control operations which are accessible from command level through io_call as follows: io_call control switch_name order_arg IO call arguments: switch_name The name of the I/O switch. order_arg Any control order described above (and in tty_) which can accept null info pointer as well as read_status, write_status, terminal_info, and the following as shown: store_id where id is the answerback string. set_term_type type {-control_args} where type is the new terminal type and -control_args can be of any -initial_string (-istr), -modes, and -ignore_line_type. These control_args are accepted by io_call, but are ignored by mowse_io_. line_length N where N is the new line length. Notes on acceptable control order active functions: The following control orders can be used as active functions: [io_call control switch_name read_status] returns true if input available; false otherwise. [io_call control switch_name write_status] returns true if output is pending; false otherwise. [io_call control switch_name terminal_info terminal_type] returns the current terminal type. [io_call control switch_name terminal_info baud] returns the baud rate [io_call control switch_name terminal_info id] returns the terminal identifier (answerback). [io_call control switch_name terminal_info line_type] returns the current line type ----------------------------------------------------------- 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