1 11/18/87 background_file_transfer, bft, BFT
2
3 Syntax as a command:
4 bft key name1 name2...name1N name2N -control_args
5 bft key request_identifier request_identifier ...
6
7
8 Function: Invokes the background file transfer BFT capability from
9 command line which providing the means for transferring files between
10 Multics and the Personal Computer PC under a background operation
11 transparent to the user. BFT is a Multics Online WorkStation
12 Environment MOWSE capability and thus requires that MOWSE be active
13 when requests are made. See bft.gi.info.
14
15 The following information applies to the command interfaces which
16 exist on both Multics and the PC, meaning that BFT commands may be
17 entered from either system.
18
19
20 Arguments:
21 key
22 specifies the request that is to be made of the file transfer
23 facility. If not given, a usage message is displayed.
24
25
26 List of keys:
27
28 list, ls
29 This will generate a listing of the transfer requests in the bft
30 queues. This facility is available only from Multics.
31
32
33 load, l
34 This will cause the BFT modules to be loaded on both machines.
35 Note that this command is available only on Multics. On the PC the
36 user should issue the bft_load command.
37 unload, u
38 This is to be used to unload the BFT server modules from both the
39 PC and Multics. All transfers in progress will be interrupted and
40 the queues will remain intact with the current entries.
41
42
43 store, s
44 This is to request a transfer from the host machine to the remote.
45 This option requires at least one filename as an argument. Name1
46 is the filename on the local machine source which is to be
47 transferred to name2N destination on the remote machine. If
48 name2N is not given it will default to name1N. The Multics equal
49 is supported for both Multics and PC requests.
50 fetch, f
51 This is to request a transfer from the remote machine to the host.
52 This option requires at least one filename as an argument. Name1
53 is the filename on the remote machine source which is to be
54 transferred to name2N destination on the local machine. If
55 name2N is not given it will default to name1N. The Multics equal
56 is supported for both Multics and PC requests.
57
58
59 cancel, c
60 This will remove one entry per request_identifier from the list of
61 transfer requests, in either direction. See "Notes on
62 request_identifiers". The star convention is not supported.
63 recover, r
64 This will restart interrupted transfers and continue the transfer
65 of pending requests in the queue. It is sufficient to merely
66 submit the recover keyword and both queues PC->Multics and
67 Multics->PC will be recovered and interrupted transfers will be
68 started from where they left off.
69
70
71 Control arguments transfer:
72
73 -file_type TYPE, -ft TYPE
74 /F TYPE
75 specifies that the file is to be transferred as a TYPE file where
76 type is either binary or ascii. Default ascii
77 -queue N, -q N
78 /Q N
79 submits the request to the queue of priority N. There are 4
80 priorities numbered 1, 2, 3, and 4 with queue 1 being of the
81 highest priority. Default queue 3.
82
83
84 -notify, -nt
85 /N ON
86 have bft notify the user upon completion of transfers.
87 -no_notify, -nnt
88 /N OFF
89 turn off transfer completion notification. Default
90
91
92 Control arguments listing:
93
94 -brief, -bf
95 briefly display the bft queues, giving for each queue store and
96 fetch and their priorities 1...4 each entry's identifier,
97 source, and destination entryname. Default
98 -long, -lg
99 display the bft queues, giving for each queue store and fetch and
100 their priorities 1...4 each complete information on each entry:
101 full identifier, source and destination full pathnames, and
102 additional transfer control modes.
103
104
105 Notes on names: Names are names of files to which a request is to be
106 applied. In the store and fetch commands, name1 is the source file
107 and name2 is the destination file. If name2 is not given, then it is
108 defaulted to name1.
109
110 The starname convention is allowed for name1 and must follow the
111 standard specific to the system to which that name applies - if name1
112 refers to a PC file, then the DOS starname convention is used; if
113 names1 refers to a Multics file, then Multics starname convention is
114 used.
115
116 The Multics equalname convention is allowed for name2 regardless of
117 where the request initiated.
118
119
120 Notes on request_identifiers: The following is a description of the
121 types of request idendifiers that the "cancel" request may take.
122
123 path
124 identifies the relative pathname of the request. The star
125 convention is not allowed. Pathnames are expanded immediately
126 relative to the system from which the command was issued.
127 -id ID
128 /I ID
129 identifies one or more requests to be cancelled based on the entry
130 ID of the request. The star convention is not allowed.
131 -entry ENTRY, -et ENTRY
132 /E ENTRY
133 identifies one or more entries based solely on their entry name.
134
135
136 Notes on file_types: The file_type binary indicates that the file is
137 to be transferred with no <CR>/<LF> conversions. The file_type ascii
138 will transfer from PC->Multics converting a <CR><LF> pair to a single
139 <LF>; Multics->PC transfers will convert a <LF> to a <CR><LF> pair.
140
141
142 Notes on pathnames: When entering Multics pathnames on the PC it is
143 important to surround the pathname with double quotes. This is
144 necessary since MS-DOS will try to interpret less-than "<" and
145 greater-than ">" characters as I/O redirection commands. While
146 entering commands on the PC, for example, the user should not type
147
148 bft s test.pl1 >udd>m>joe>test.pl1
149
150 but should instead type
151
152 bft s test.pl1 ">udd>m>joe>test.pl1"