11/18/87 background_file_transfer, bft, BFT Syntax as a command: bft key {name1 {name2...name1N name2N}} {-control_args} bft key request_identifier {request_identifier ...} Function: Invokes the background file transfer (BFT) capability from command line which providing the means for transferring files between Multics and the Personal Computer (PC) under a background operation (transparent to the user). BFT is a Multics Online WorkStation Environment (MOWSE) capability and thus requires that MOWSE be active when requests are made. See bft.gi.info. The following information applies to the command interfaces which exist on both Multics and the PC, meaning that BFT commands may be entered from either system. Arguments: key specifies the request that is to be made of the file transfer facility. If not given, a usage message is displayed. List of keys: list, ls This will generate a listing of the transfer requests in the bft queues. This facility is available only from Multics. load, l This will cause the BFT modules to be loaded on both machines. Note that this command is available only on Multics. On the PC the user should issue the bft_load command. unload, u This is to be used to unload the BFT server modules from both the PC and Multics. All transfers in progress will be interrupted and the queues will remain intact with the current entries. store, s This is to request a transfer from the host machine to the remote. This option requires at least one filename as an argument. Name1 is the filename on the local machine (source) which is to be transferred to name2N (destination) on the remote machine. If name2N is not given it will default to name1N. The Multics equal is supported for both Multics and PC requests. fetch, f This is to request a transfer from the remote machine to the host. This option requires at least one filename as an argument. Name1 is the filename on the remote machine (source) which is to be transferred to name2N (destination) on the local machine. If name2N is not given it will default to name1N. The Multics equal is supported for both Multics and PC requests. cancel, c This will remove one entry per request_identifier from the list of transfer requests, in either direction. See "Notes on request_identifiers". The star convention is not supported. recover, r This will restart interrupted transfers and continue the transfer of pending requests in the queue. It is sufficient to merely submit the recover keyword and both queues (PC->Multics and Multics->PC) will be recovered and interrupted transfers will be started from where they left off. Control arguments (transfer): -file_type TYPE, -ft TYPE /F TYPE specifies that the file is to be transferred as a TYPE file where type is either binary or ascii. (Default ascii) -queue N, -q N /Q N submits the request to the queue of priority N. There are 4 priorities numbered 1, 2, 3, and 4 with queue 1 being of the highest priority. (Default queue 3). -notify, -nt /N ON have bft notify the user upon completion of transfers. -no_notify, -nnt /N OFF turn off transfer completion notification. (Default) Control arguments (listing): -brief, -bf briefly display the bft queues, giving for each queue (store and fetch) and their priorities (1...4) each entry's identifier, source, and destination entryname. (Default) -long, -lg display the bft queues, giving for each queue (store and fetch) and their priorities (1...4) each complete information on each entry: full identifier, source and destination full pathnames, and additional transfer control modes. Notes on names: Names are names of files to which a request is to be applied. In the store and fetch commands, name1 is the source file and name2 is the destination file. If name2 is not given, then it is defaulted to name1. The starname convention is allowed for name1 and must follow the standard specific to the system to which that name applies - if name1 refers to a PC file, then the DOS starname convention is used; if names1 refers to a Multics file, then Multics starname convention is used. The Multics equalname convention is allowed for name2 regardless of where the request initiated. Notes on request_identifiers: The following is a description of the types of request idendifiers that the "cancel" request may take. path identifies the relative pathname of the request. The star convention is not allowed. Pathnames are expanded immediately relative to the system from which the command was issued. -id ID /I ID identifies one or more requests to be cancelled based on the entry ID of the request. The star convention is not allowed. -entry ENTRY, -et ENTRY /E ENTRY identifies one or more entries based solely on their entry name. Notes on file_types: The file_type binary indicates that the file is to be transferred with no / conversions. The file_type ascii will transfer from PC->Multics converting a pair to a single ; Multics->PC transfers will convert a to a pair. Notes on pathnames: When entering Multics pathnames on the PC it is important to surround the pathname with double quotes. This is necessary since MS-DOS will try to interpret less-than ("<") and greater-than (">") characters as I/O redirection commands. While entering commands on the PC, for example, the user should not type bft s test.pl1 >udd>m>joe>test.pl1 but should instead type bft s test.pl1 ">udd>m>joe>test.pl1" ----------------------------------------------------------- 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