This is UFT README in HTML form. For more information,
see the web page "uft.html" in the directory
where this file was found.
This is free software. You may use it at no charge. You can distribute it provided that the code itself remain unchanged and all notices (including this copyright notice) remain intact. This software comes with no warranty. This software is property of the author and may not be sold without express written permission from the author.
To build the POSIX version on your system, get into the application root (just above the src directory) and enter the command
make
If that worked, you may wish to go ahead and
make install
Given the reliable transport, such as TCP, and an open-ended tagging method, we can transfer any static object (file) with any arbitrary set of attributes from one system to another, even between otherwise incompatible platforms. This concept is a funcional superset of the file transfer capability of IBM's NJE networking as found on familiar networks like BITNET. Such an operation is inverse to, and complementary to, the World Wide Web in that files are sent rather than fetched.
SIFT/UFT combines an open-ended tagging of binary objects on top of TCP resulting in a general purpose file transfer mechanism. A plain text meta file is created by the sending user agent and accompanies the binary object along a TCP path to the target recipient host. SIFT transfer agents can (and in general should) leave both the file and meta file intact, allowing that the object defined may be gatewayed if needed and that the final disposition rest with the receiving entity.
The meta file is plain text which is the common thread among
all general purpose computing systems, while the data file
(the "binary object") is an octet stream, carried by TCP,
and may represent a plain text file or any of a
variety of other formats.
Loose Definition of "plain text":
Plain text looks the same to the machine as it does to you.
That is, if some program is to process a plain text file, then
it is interpreted the same by the program as it would be by a human.
There are no "gotchas" from non-printables or
In the VM implementation, IBM has supplied tools for quite some time
that process "spool files". See RDRLIST, RECEIVE,
SENDFILE and related commands in CMS HELP.
In the POSIX implementation, each inbound UFT object (file) has
three physical files: nnnn.cf, nnnn.df
and nnnn.ef. The .cf file is a "control
file" or "metafile" in 'env' form. The .df is
the "data file" and is a canonicalization of the real file being sent.
The .ef file holds extended attributes, the resource fork,
or other extra data used by the sending O/S associated with this file.
(UNIX does not use this file)
For each user to whom files have been sent, there is a directory
under /usr/spool/uft. So /usr/spool/uft/troth
would hold my UFT files. The quickest way to access files here
would be to 'rcv' (receive) them, where 'rcv'
is a shell script that "does the right thing". One can, of course,
manually process /usr/spool/uft/troth/0001.df according to
what's in /usr/spool/uft/riddle/0001.cf. The number
0001 goes up so that the next item would be 0002, 0003, and so on.
Leading zeros are kept in the filename so sorting works. Another
script, 'rls' lists the files in queue to be received.
Send files with
© Copyright 1995, 1997, Richard M. Troth, all rights reserved.
where "unsolicited" does NOT mean unwanted,
just that you didn't go get it, it came to you.
Where WWW is anonymous get, UFT is anonymous put.
UFT might also stand for Universal File Transfer
because the protocol can be carried over other
transports, not only TCP/IP but also SNA (LU 6.2),
modem dial-up, Novell or DECNET.
SIFT usually refers to mail transport
while UFT suggests TCP, but they're otherwise identical.
sf [ -a |
-i ] file
[ to ] user