10/11/88 unified_file_transfer, uft Syntax as a command: uft path1 {path2} -to DEST | -from DEST {-control_args} Function: The unified_file_transfer (uft) request lets you submit an interactive file transfer request to a remote host. Arguments: path1 String path1 specifies the source file to be used for the transfer. It must be preceded by -name or -nm if the file name begins with a "-". can be a "star" name if the file being transferred resides on the host. Star convention is allowed, and as much requests as found files will be entered. path2 String path2 specifies pathname of destination file, and has the same syntax and restrictions as path1. path2 accepts equal conventions. When omitted, equals path1 (Default). If path1 uses star convention, equal convention is mandatory. Control arguments: -to STR to be used when file is to be sent from HOST to REMOTE. String STR is correspondent name given in the NIT (Network Information Table) to the remote UFT application. The NIT associates the UFT correspondent name to its DSA network address (session_id and mailbox). STR can be given by active function "list_uft_correspondent" (refer to command "luc" for details). -from STR, -fm STR to be used when file is to be received onto the HOST. String STR is correspondent name given in the NIT (Network Information Table) to the remote UFT application. The NIT associates the UFT correspondent name to its DSA network address (session_id and mailbox). STR can be given by active function "list_uft_correspondent" (refer to command "luc" for details). See "Notes" below for referral of remaining control arguments. Notes: The syntax of the unified_file_transfer request is the same as the enter_uft_request command. All control arguments used to define the file characteristics and other request options are described in the enter_uft_request.info info segment. Type "help eur" for a description of these control arguments. Between two Multics systems, data is read and written without consideration of the file organization. The bit count of each segment of the destination file is adjusted at the end of the transfer to the same value as the bit count of the corresponding segment in the source file. There is no data_type translation. Between a Multics system and a non-Multics system, the file transfer is a "record" transfer; Multics reads or writes the file transferred on a record basis using the vfile access methods. Multics DSA UFT does not support tape files. Tape files must be stored in a Multics disk file before being sent by Multics DSA UFT. Multics DSA UFT can receive a file only in a Multics disk file. The Multics requestor accepts transfers between different file organizations but it does not change the format of the record. It is your responsibility to ensure that the record format used is appropriate for the destination file. When specifying control arguments to the unified_file_transfer request, the control arguments used to define the characteristics of the destination file are used to request the creation of the remote file. Those control arguments that affect the characteristics of the destination file are prefaced by "-d" (for example, -d_status). Those control arguments that affect the source file are prefaced by "-s" (for example, -s_record_format). Some systems do not retain file attributes after file creation (such as data_type on Multics). For these systems, it may be necessary to define the missing file attributes in the transfer request. ----------------------------------------------------------- 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