03/08/88 kermit Syntax as a command: kermit {-control_args} Function: invokes the Multics implementation of the Kermit file transfer program. The Multics Kermit program provides the capability to transfer files between a Multics system and a remotely located system (e.g., a personal computer) using the KERMIT protocol. Once invoked, Multics Kermit prompts you for the various file transfer requests. Multics Kermit has been implemented with a server feature that permits you to login to Multics from a remote site and specify file transfer operations without having to escape back and forth between the Multics system and the remote system. Control arguments: -abbrev, -ab enables abbreviation expansion of request lines. -io_switch STR, -iosw STR specifies that communication with the remote system be done over the I/O switch whose name is STR. If you omit it, the user_i/o switch is assumed. -no_abbrev, -nab does not enable abbreviation expansion of request lines. (Default) -no_prompt, -npmt suppresses the prompt for request lines in the request loop. -no_request_loop, -nrql does not enter the request loop after performing any operations given by -request. -no_start_up, -nsu, -ns does not execute the start_up exec_com. -profile PATH, -pf PATH specifies the pathname of the profile to use for abbreviation expansion. The suffix "profile" is added to PATH if you don't include it explicitly on the command line. This control argument implies -abbrev. -prompt STR, -pmt STR sets the request loop prompt to STR. (Default: ^/Multics-Kermit^[ (^d)^]:^2x) -quit exits the Kermit program after performing any operations given by -request. -request STR, -rq STR executes STR as a Kermit program request line before entering the request loop. -request_loop, -rql enters the Kermit program request loop after performing any operations given by -request. (Default) -start_up, -su executes the Kermit program start_up exec_com start_up.kermit. The users home directory, the project directory, and >site are searched, in that order, for the start_up. The exec_com is executed before the request_string and before entering the subsystem request_loop. (Default) List of requests: The following is a summary of requests used to respond to prompts from the Kermit program. In this summary "-ca" is used as shorthand for "-control_args". For a complete description ofany request, issue the Kermit request: help request_name . prints a line describing the current invocation of the Kermit program. ? prints a list of requests available in the Kermit program. abbrev {-ca}, ab {-ca} controls abbreviation processing of request lines. do rq_str {args}, [do rq_str args] executes/returns a request line with argument substitution. exec_com ec_path {ec_args}, ec ec_path {ec_args} [exec_com ec_path {ec_args}], [ec ec_path {ec_args}] executes a file of Kermit program requests that can return a value. execute cmd_line, e cmd_line [execute active_str], [e active_str] executes a Multics command line or evaluates a Multics active string. finish sends a request to a remote server to shut down server operation and return the remote system to its request's loop. get remote_source_path {local_destination_path} sends a request to a remote server requesting that the named file(s) be sent from the remote system. help {topics} {-ca} prints information about Kermit program requests and other topics. If you supply no topics, methods for getting help are listed. list_help {topics}, lh {topics} displays the name of all Kermit program info segments on given topics. list_requests {STRs} {-ca}, lr {STRs} {-ca} prints a brief description of selected Kermit program requests. You can use STR to specify that only specific requests be listed. log {PATH} {-ca} directs the Kermit program to start logging transactions. logout sends a request to the remote server directing it to log you out from the remote system. quit, q exits the Kermit program. quit_log directs the Kermit program to stop logging transactions. receive {PATH}, r {PATH} receives a file or file group from the other system. send local_source_path {remote_destination_path} s local_source_path {remote_destination_path} sends a file or file group to the other system. server instructs the Kermit program to cease taking commands from the keyboard and to receive all further instruction in the form of Kermit packets. set mode {STR} establishes or modifies various modes for file transfers. show {modes} displays mode values. statistics, st shows statistics about the most recent file transfer. subsystem_name, [subsystem_name] prints/returns the name of this subsystem. subsystem_version, [subsystem_version] prints/returns the version number of this subsystem. The following list of modes are recognized by the Kermit program and the set and show Kermit requests. The values associated with each mode are also given. List of modes affecting file storage: file_type STR indicates the type of file being transferred. STR can be either binary or ascii. file_warning STR indicates the action to be taken when an incoming file name has the same name as an existing file name in the default directory when receiving files. STR can be either on or off. If file_warning is on, the Kermit program renames the file to avoid overwriting the preexisting one; if file_warning is off, the incoming file replaces the preexisting one. If logging transactions, the log indicates the name of the file in which the data was stored. (Default: on) incomplete STR indicates the action to be taken if a file was not completely transferred. STR can be either keep or discard. If you specify keep, all incomplete files are saved; if you give discard, incomplete files are discarded. (Default: keep) List of modes affecting file transfer: control_prefix CHR, cp CHR is the character to use for quoting of control characters, where CHR is any character in the range ! through > or ` through ~, but different from eight_bit_prefix and repeat_prefix. (Default: #) eight_bit_prefix CHR, ebp CHR is the ASCII character Multics Kermit program uses, when transmitting binary files via a 7-bit connection, to quote characters that have the 8th bit set. CHR is one of the following, but different from control_prefix and repeat_prefix: Y characters with the 8th bit set are quoted if the remote system requests it. N characters with the 8th bit set are not quoted. & or any character in the range ! through > or ` through ~. Use the specified character for quoting characters with the 8th bit set. If the Multics Kermit program's eight_bit_prefix character is different from the remote program's, then no 8th bit prefixing is done. The value of this mode is ignored if line_byte_size is 8. (Default: &) end_of_packet CHR, eop CHR is the character the Multics Kermit program uses as a line terminator for incoming packets, where CHR is an ASCII character between SOH (001 octal) and US (037 octal) inclusive and different from the start_of_packet character. (Default: carriage return, 015 octal) line_byte_size N indicates whether data is being transmitted via a 7-bit or 8-bit connection, where N can be either 7 or 8. A 7-bit connection is desirable when transferring ASCII files or when the 8th bit of each transmitted byte is required for parity or changed by intervening communications equipment. Use an 8-bit connection for transferring binary files, as it decreases protocol overhead. If you can't use an 8-bit connection for a binary file transfer, then you can use a 7-bit connection with the eight_bit_prefix mode enabled to transfer binary files. (Default: 7) packet_length N, pl N is the maximum packet length the Multics Kermit program can receive, where N is an integer between 20 and 94 (decimal). (Default: 80) NOTE: Long packets can be selected when the user has explicitly selected N which is larger than 94 with a SET command. The maximum length of long packets can be up to 1500 characters. parity STR used for communicating with systems or networks that require the 8th bit for character parity. The parity used must be the same for Kermit programs on both the local and remote system. STR can be one of none eight data bits and no parity. mark seven data bits with the parity bit set to 1. space seven data bits with the parity bit set to 0. even seven data bits with the parity bit set to make the overall parity even. odd seven data bits with the parity bit set to 1 to make the overall parity odd. The value of the mode is ignored if line_byte_size is 8. (Default: none) repeat_prefix CHR, rp CHR is the character the Multics Kermit program uses to indicate a repeated character, where CHR can be any character in the range ! through > or ` through ~, but different from the control_prefix and eight_bit_prefix. Space " " denotes no repeat count processing is to be done. If the Multics Kermit program repeat_prefix character is different from the remote system's, then no repeat prefixing is done. (Default: ~). retry_threshold N, rt N specifies how many times to try sending or receiving a particular packet before giving up, where N is an integer between 5 and 15 inclusive. (Default: 5) start_of_packet CHR, sop CHR is the character to be used for the start of packet, where CHR is an ASCII character between NUL (000 octal) and US (037 octal) inclusive. The start_of_packet character must be the same for Kermit programs on both the local and remote system, but different from the end_of_packet character. (Default: SOH, octal 001) timeout N specifies how many seconds the Multics Kermit program wants the remote system to wait for a packet from Multics before trying again, where N is an integer value between 5 and 20. (Default: 15) Notes on kermit development: The KERMIT protocol was developed at Columbia University. Many implementations of KERMIT are avaiable from the KERMIT group at Columbia. Direct inquiries about KERMIT to KERMIT Distribution Columbia University Center for Computing Activities 7th Floor, Watson Laboratory 612 West 115th Street New York, New York 10025 Notes on remote systems: The Multics Kermit program supports the transfer of 7-bit ASCII files and 8-bit binary files. You can transfer ASCII files between any two systems, whereas you can only transfer binary files between systems that are able to retain the original value of the data byte. For example, sending a Multics binary file in which all bits of the 9-bit byte are used to a system that uses 8-bit bytes results in the loss of the most significant bit (i.e., the transferred file on the remote system differs from the original file sent). However, a binary file received by the Multics Kermit program from a remote system that uses 8-bit bytes can then be sent by Multics Kermit to a second such remote system. The resulting file on the second system is identical to the original file sent. Notes on file transfer: For transmission between systems, you must assign files to one of two categories--ASCII or binary. On systems with 8-bit bytes, ASCII files have the high-order bit of each byte set to zero, whereas binary files use the high-order bit of each byte for data, in which case its value can vary from byte to byte and must be preserved. Binary file transmission is permissible as long as the two Kermit programs involved can control the value of the 8th bit (i.e., it is not being used for parity or changed by intervening communications equipment). In that case the 8th bit of a transmitted character matches that of the original data byte without any special 8th bit prefixing. For example, to send or receive a binary file of 8-bit bytes when an 8-bit connection is possible, set line_byte_size to 8, set file_type to binary, and start the transfer. If an 8-bit connection is not possible, then you can send binary files via a 7-bit connection using the eight_bit_prefix. For example, set file_type to binary, set line_byte_size to 7, set parity to str, set eight_bit_prefixing to chr, and start the transfer. To send or receive an ASCII file, set file_type to ascii, set line_byte_size to 7, set any other desired modes, and start the transfer. The Multics Kermit program does not support the transfer of 9-bit bytes when the most significant bit is used for data. Thus sending a Multics binary file to a second Multics site results in the loss of the most significant bit of each byte. Notes on procedure for using kermit (multics/personal computer): Use the following procedure to transfer files between Multics and a personal computer using Kermit: 1. Start Kermit on the personal computer. 2. Set any desired modes. 3. Connect to Multics via the connect command. Once connected, the standard Multics banner is displayed. 4. Login to Multics. 5. Start Kermit on Multics. It responds with the prompt "Multics-Kermit:". 6. Set any desired modes. 7. Execute either a send or receive request, specifying the file or file group. 8. Use the appropriate escape sequence to get back to Kermit command level on the personal computer. 9. Execute the corresponding request on the personal computer. For example, if you issue the send request on Multics, execute the receive request on the personal computer or vice versa. 10. File transfer begins. The personal computer displays the status of the file transfer. 11. To transfer more files, connect back to Multics Kermit and enter a carriage return to get the "Multics-Kermit:" prompt. Go to step 7. 12. Exit Multics Kermit by issuing the quit request and logout. 13. Use the appropriate escape sequence to get back to Kermit command level on the personal computer. Notes on procedure for using kermit (multics server/personal computer): Use the following procedure to transfer files between Multics and a personal computer using the Kermit server: 1. Start Kermit on the personal computer. 2. Set any desired modes. 3. Connect to Multics via the connect command. Once connected, the standard Multics banner is displayed. 4. Login to Multics. 5. Start Kermit on Multics. It responds with the prompt "Multics-Kermit:". 6. Set any desired modes. 7. Execute the server request. 8. Use the appropriate escape sequence to get back to Kermit command level on the personal computer. 9. Execute the Kermit server request on the personal computer for sending or receiving files. 10. File transfer begins. The personal computer displays the status of the file transfer. 11. To transfer more files, go to step 9. 12. Exit Multics Kermit by issuing the Kermit server quit request on the personal computer. 13. Connect back to Multics and logout. 14. Use the appropriate escape sequence to get back to Kermit command level on the microcomputer. Notes on procedure for using kermit (multics/multics): Use the following procedure to transfer files between two Multics systems using Kermit: 1. Login to the local Multics. 2. Connect to the remote Multics via the dial_out command. 3. Login to the remote Multics. 4. Start Kermit on the remote Multics. 5. Set any desired modes. 6. Execute the server request. 7. Use the appropriate escape sequence to start up Kermit on the local Multics (e.g., e kermit -iosw [switch_name]) 8. Execute the Multics send request to send files to the remote system, or the get request to receive files from the remote system. 9. To transfer more files, go to step 8. 10. When done, execute the finish request to exit the remote server and quit from the local kermit to reconnect to the remote Multics, or execute the logout request to logout from the remote Multics and then quit the local Kermit. ----------------------------------------------------------- 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