MULTICS TECHNICAL BULLETIN MTB766
To: MTB Distribution
From: MCrawford
Date: 08/07/87
Subject: Multics DSA Unified File Transfer Facility Reference
Guide
-----------------------------------
This MTB includes the procedures for using the Unified File
Transfer (UFT) facility of the Multics DSA Network System.
-----------------------------------
Comments on this MTB should be directed by Multics mail to:
System M: GDixon.Multics
or by phone to:
Gary Dixon
HVN: 862-3593
DDD: 602-862-3593
_________________________________________________________________
Multics project internal documentation; not to be reproduced or
distributed outside the Multics project without permission of the
Director of MDC.
CONTENTS
Page
Section 1 Multics DSA Unified File Transfer
Facility . . . . . . . . . . . . . . . . 1-1
The Multics DSA Unified File Transfer
Facility Functions . . . . . . . . . 1-1
The DSA Unified File Transfer Facility
- Requestor Functions . . . . . . . . 1-1
Submitting DSA UFT Requests from the
DSA UFT Subsystem . . . . . . . . . . 1-2
Submitting Interactive DSA UFT
Requests . . . . . . . . . . . . . 1-3
Creating a File on a Remote Host
- create Request . . . . . . . 1-4
Deleting a File on a Remote Host
- delete Request . . . . . . . 1-7
Requesting Information About a
Remote Host - get_information
Request . . . . . . . . . . . . 1-8
Set default for Requestor
Options - r_default Request . . 1-10
Set Trace for Requestor Option -
r_trace Request . . . . . . . . 1-11
Renaming a File on a Remote Host
- Rename Request . . . . . . . 1-11
Set Default for Server Option -
s_default Request . . . . . . . 1-12
Set Trace for Server - s_trace
Request . . . . . . . . . . . . 1-13
Performing Interactive File
Transfer - Unified File
Transfer Request . . . . . . . 1-13
Section 2 DSA and UFT Multics Commands . . . . . . 2-1
Submitting a Queued DSA UFT Request 2-1
Cancelling a Queued UFT Request
- cancel_uft_request Request . 2-1
cancel_uft_request, (cur) . . . . . 2-2
Entering a Queued UFT Request -
enter_uft_request Request . . . 2-3
enter_uft_request, (eur) . . . . . 2-3
Listing Queued UFT Requests -
list_uft_request Request . . . 2-5
CONTENTS (cont)
Page
list_uft_request, (lur) . . . . . . 2-6
Modifying a Queued UFT Request -
modify_uft_request Request . . 2-7
modify_uft_request, (mur) . . . . . 2-7
Section 3 Multics DSA Unified File Transfer
Facility Configuration . . . . . . . . . 3-1
Configuring the Multics DSA UFT
Facility . . . . . . . . . . . . . . 3-1
Defining the Network Information
Table Entries (NIT) for DSA UFT . 3-2
The System Statement . . . . . . 3-2
The Mailbox Statement . . . . . 3-2
The session_type_descriptor
Statement . . . . . . . . . . . 3-2
The Service Statement . . . . . 3-3
The Correspondent Statement . . 3-3
Defining the I/O SysDaemon for DSA
UFT . . . . . . . . . . . . . . . 3-3
The UFT Requestor function . . . 3-3
Queue Management . . . . . . . . 3-4
Special commands for uft driver 3-4
iod_tables . . . . . . . . . . . 3-5
I/O SysDaemon Tables
Request_type Statements for DSA
UFT . . . . . . . . . . . . . . 3-5
I/O SysDaemon Tables Device
Statements for DSA UFT . . . . 3-6
Registering the DSA UFT Daemon
Person_id in the Project Master File 3-6
Registering the I/O SysDaemon in the
Person Name Table . . . . . . . . . . 3-7
Creating the Message Coordinator for
DSA UFT . . . . . . . . . . . . . . . 3-7
Creating Input and Output Message
Segments for DSA UFT . . . . . . . 3-8
Creating Message Coordinator
Sources and Virtual Consoles for
DSA UFT . . . . . . . . . . . . . 3-8
Virtual Console Definition for
DSA UFT - Define Request . . . 3-9
Routing DSA UFT Daemon Output -
Route Request . . . . . . . . . 3-9
Appendix A Multics DSA UFT Trace Facility . . . . . A-1
The Trace Requests . . . . . . . . . . A-1
System Traces . . . . . . . . . . . . A-2
Trace options in effect : . . . . . A-2
CONTENTS (cont)
Page
Setting server trace options. . . . A-3
Setting log pathname. . . . . . . . A-3
Setting trace options (answer y to
set, n or CR to Reset). . . . . . A-3
Setting record length. . . . . . . A-3
Trace options in effect : . . . . . A-3
Appendix B Unified File Transfer Requests Arguments B-1
SECTION 1
MULTICS DSA UNIFIED FILE TRANSFER FACILITY
The Multics DSA Unified File Transfer Facility permits the
transfer of files between Multics and remote systems connected to
a DSA network.
THE MULTICS DSA UNIFIED FILE TRANSFER FACILITY FUNCTIONS
The Multics DSA Unified File Transfer Facility (UFT)
includes the following two functions:
o UFT Requestor function
o UFT Server function
The UFT Requestor function is responsible for executing the
UFT requests that you submit to Multics. The Requestor function
initiates connections to remote systems.
The UFT Server function is responsible for receiving
incoming UFT requests from remote systems and executes the
transfer requests specified.
THE DSA UNIFIED FILE TRANSFER FACILITY - REQUESTOR FUNCTIONS
The Multics DSA Unified File Transfer (UFT) facility
performs file transfer and other related requests with any
computer connected on a DSA network. DSA UFT Requestor function
lets you issue file transfer requests in two modes:
o interactive mode (unified_file_transfer request)
o queued request mode (enter_uft_request request)
Interactive mode processes your file transfer request
immediately; files submitted by a queued request are placed in a
special network application request queue and are transferred
when the queued request is available for processing (i.e., when
the preceding requests have been processed). Execution of the
queued request depends upon the default request queue in use or
the priority queue that you specify. Requests placed in higher
priority request queues are given preference.
The interactive file transfer request (uft) and the queued
file transfer request (enter_uft_request) can be issued from
Multics command level, or they can be issued from the DSA UFT
subsystem which is invoked with the dsa_uft command (see below).
A series of DSA UFT requests are available that assist in
the processing of both interactive file transfer requests and
queued file transfer requests. All DSA UFT requests must be
issued from the DSA UFT subsystem as described below. The DSA
UFT requests are outlined in Table 1-1 and 2-1, respectively.
SUBMITTING DSA UFT REQUESTS FROM THE DSA UFT SUBSYSTEM
To submit an interactive DSA UFT request or a queued DSA UFT
request to a remote host, you must:
1. Invoke the DSA UFT subsystem with the command:
dsa_uft
Once you have entered the dsa_uft request, the following
prompt will appear on your screen:
dsa_uft:
2. When you receive the dsa_uft subsystem prompt, you can enter
any of the requests allowed for interactive processing or
queued processing (see Table 1-1 and 2-1, respectively).
Note that when issuing remote DSA UFT requests to a remote
Multics host, you must specify your user password for the remote
host as described in the request descriptions.
The format of the dsa_uft request is:
dsa_uft {control_args}
CONTROL ARGUMENTS:
-abbrev, -ab
enables abbreviation processing within the DSA UFT
subsystem.
-debug, -db
enables debug mode.
-ec_suffix
specifies the execution command (ec) suffix to be used. The
default is dsa_uft.
-info_dir STR,
directory containing the info segs of the subsystem.
-no_abbrev, -nab
disables abbreviation processing within the DSA UFT
subsystem (default).
-no_debug, -ndb
disables debug mode (default).
-no_prompt, -npmt
indicates that no prompt will be used within the DSA UFT
subsystem
-no_start_up, -nsu
indicates that no start_up.ec file will be used to contain
DSA UFT requests (default).
-profile <pathname>, -pf <pathname>
the pathname of the profile file to be used if abbreviation
processing is enabled.
-prompt STR, -pmt STR
STR is the character string to be used as the prompt in the
DSA UFT subsystem. By default prompt value is "dsa_uft".
-start_up, -su
indicates a start_up.ec file will be used to contain DSA UFT
requests.
-wd
specifies that the execution command file search list will
not be used. Only the current working directory will be
searched for the execution command file.
Submitting Interactive DSA UFT Requests
To submit an interactive DSA UFT request, invoke the DSA UFT
subsystem as described above. Any of the interactive DSA UFT
requests listed in Table 1-1 can be entered from the DSA UFT
subsystem.
Table 1-1. Interactive UFT Requests
REQUEST ABBREVIATION ACTION
create cr Create a file on a remote host
delete dl Delete a file on a remote host
get_information gi Request information on a remote
host
r_default r_d Set default for requestor options
r_trace Set trace for requestor
rename rn Rename a file on a remote host
s_default s_d Set default for server options
s_trace Set trace for server
unified_file_transfer uft Perform an interactive file
transfer in the user's process
CREATING A FILE ON A REMOTE HOST - CREATE REQUEST
The create command lets you create a file on a remote host
and set the appropriate file attributes. The create request is a
file management convenience tool. It is not necessary to create
a destination file before issuing a file transfer request. The
file is created dynamically on the remote system in the same
format.
The arguments describing the remote file attributes are
given as arguments to the create request. Depending upon the
type of remote system, some arguments are mandatory and others
may be ignored (see the remote system file transfer protocol
manual for details).
Depending upon the remote system, some file characteristics
specified by the create request may not be retained by the remote
system.
The format of the create request is:
cr {-name} <file_name> -at <correspondent> {<control_args>}
where:
<file_name>
is the name of the file you want to create; it must be
specified in a syntax acceptable to the host on which the
file is to reside; <file_name> must be preceded by -name (or
-nm) if the file name begins with a "-"; it must be followed
by "-at <correspondent>"; it must be enclosed in quotes if
it contains spaces or special characters.
-at <correspondent>
<correspondent> must be the name given in the Network
Information Table (NIT) to the remote UFT application. The
NIT associates to the UFT correspondent name its DSA network
address (session_id and mailbox).
CONTROL ARGUMENTS:
-billing STR
specifies the accounting identification used by the remote
host (not Multics); there is no default.
-catalogue <file_name>, -cat <file_name>
for a non-Multics system, <file_name> specifies a catalogue
file. The -catalogue control argument is required only when
the catalogue file for the file description is not
implicitly known. <file_name> must be specified in a syntax
acceptable to the host on which the file will resides; it
must be enclosed in quotes if it contain spaces or special
characters.
-control_interval_format STR, -cif STR
STR specifies the control interval format. The control
interval format can be blocked_unspanned,
unblocked_unspanned, blocked_spanned, or unblocked_spanned.
For Multics, there is no control interval format.
-control_interval_size N, -cis N
indicates the control interval size to be used. The maximum
control interval size is 65535.
-data_type <data_type>, -dt <data_type>
<data_type> can be either ascii, binary, ebcdic, gbcd, hbcd,
jis or undefined. It specifies the data code of the data to
be contained in the file. The default is "undefined".
-file_format STR, -ff STR
STR specifies the specific format of the file. The file
format can be disk_ufas_6_66, disk_36_bit_ufas,
disk_64_ufas, disk_68, disk_66_gfrc, disk_64_bfas, disk_62,
disk_6_no_ufas, disk_ibm_no_vsdm, disk_ibm_vsam,
tape_ufas_ans_ascii, tape_ufas_ebcdic, tape_66_gfrc,
tape_foreign, diskette_basic_iso, diskette_basic_ibm,
cassette_standard_iso, or cassette_foreign.
-format_version N, -fv N
N specifies the specific version of the file format. The
format version can be 0, 1, or 3. The format version is 1
or 3 for tape_ufas_ans_ascii (the default is 1). For other
formats, the default value is correct.
-max_record_length N, -mrl N
specifies the maximum record length for the file to be
created. The maximum record length that can be specified is
65535.
-no_password, -npw
if the -no_password control argument is present the user
will not be prompted for a password with a mask. The
password will not be used by the remote host to authenticate
the submitter.
-options <options>, -opt <options>
-status < >, -st < >
<options> can be either keep, new, or replace. The -options
control argument indicates what should be done if the file
to be created already exists. If "new" then an error will
be returned (default); if "keep or truncate (tc)", the
existing file will be kept but the creation will be
considered successful; if "replace (rp)", then the existing
file will be deleted and a new file created as specified.
-organization <file_organization>, -org <file_organization>
<file_organization> can be sequential, relative, indexed,
extended_indexed, general_indexed, random, queued, l6_r2,
l6_r5, byte_stream, or unstructured. It specifies the file
organization of the file to be created. Multics supports
unstructured, sequential, relative, and general_indexed file
organizations. The default is sequential.
-password, -pw
if the -password control argument is present the user will
be prompted for a password with a mask. The password may be
used by the remote host to authenticate the submitter. For
a remote Multics system, the -password control argument is
mandatory. (Default)
-person STR, -user STR
STR specifies the remote user identification used by the
remote host on whose behalf the delete is to be executed.
This may be used by the remote host for authentication of
the job submitter. The default is the Multics user_id of
the user who submitted the request.
-project STR, -pj STR
STR specifies the project identification used by the remote
host on whose behalf the delete is to be executed.
-record_format STR, -rf STR
STR is the record format to be used for the file. The
format can be fixed, variable, or undefined. For Multics,
the record format is always variable.
The following example illustrates the procedure for creating a
segment, cr_1, on a remote Multics host.
cr uft_dest>cr_1 -at dsa.MUL1.FILETRAN
DELETING A FILE ON A REMOTE HOST - DELETE REQUEST
To delete a file on a remote host, issue the delete request
from the DSA UFT subsystem.
The format of the delete request is:
dl {-name} <file_name> -at <correspondent> {control_args}
where:
<file_name>
<file_name> is the name of the file to be deleted and must
be specified in a form acceptable to the host on which it
resides; it must be preceded by -name (or -nm) if the file
name begins with a "-"; it must be followed by "-at
<correspondent>"; it must be enclosed in quotes if it
contains spaces or special characters. If the
<correspondent> is running on a Multics system, then
<file_name> can be a "star" name, and all of the files which
match the "star" name will be deleted.
-at <correspondent>
<correspondent> is the name given in the Network Information
Table (NIT) to the remote UFT application. The NIT
associates to the UFT correspondent name its DSA network
address (session_id and mailbox).
CONTROL ARGUMENTS:
-billing STR
STR specifies the accounting identification used by the
remote host (not Multics); there is no default.
-catalogue <file_name>, -cat <file_name>
for a non-Multics system, <file_name> specifies a catalogue
file. It is required only when the catalogue file for the
file description is not implicitly known. <file_name> must
be specified in a syntax acceptable to the host on which the
file will resides; it must be enclosed in quotes if it
contain spaces or special characters.
-no_password, -npw
if the -no_password control argument is present the user
will not be prompted for a password with a mask. The
password will not be used by the remote host to authenticate
the submitter.
-password, -pw
if the -password control argument is present, the user will
be prompted for a password with a mask. The password may be
used by the remote host to authenticate the submitter. For
a remote Multics system, the -password control argument is
mandatory. (Default)
-person STR, -user STR
STR specifies the remote user identification used by the
remote host on whose behalf the delete is to be executed.
This may be used by the remote host for authentication of
the job submitter. The default is the Multics user_id of
the user who submitted the request.
-project STR, -pj STR
STR specifies the project identification used by the remote
host on whose behalf the delete is to be executed.
The following example illustrates the procedure for deleting
a segment, cr_1, on a remote Multics host.
dl uft_dest>cr_1 -at dsa.MUL1.FILETRAN
REQUESTING INFORMATION ABOUT A REMOTE HOST - GET_INFORMATION
REQUEST
The get_information request lets you obtain information
about a file on a remote host. You can obtain any or all of the
following information about a file on a remote host:
o file name
o history
o logical attributes
o physical attributes
The format of the get_information request is:
gi {-name} <file_name> -at <correspondent> {<control_args>}
where:
<file_name>
<file_name> specifies the file about which you want
information and must be specified in a form acceptable to
the host on which the file resides. <file_name> must be
preceded by -name (or -nm) if it begins with a "-"; it must
be followed by "-at <correspondent>"; it must be enclosed in
quotes if it contains spaces or special characters. If the
<correspondent> is running on a Multics system, then
<file_name> can be a "star" name, and information on all of
the files that match the "star" name will be returned.
-at <correspondent>
<correspondent> is the name given in the Network Information
Table (NIT) to the remote UFT application. The NIT
associates to the UFT correspondent name its DSA network
address (session_id and mailbox).
CONTROL ARGUMENTS:
-attributes <attributes>, -att <attributes>
<attributes> specifies the type of information desired.
<attributes> are: history, logical, physical, space, or
all. You can specify several attributes.
-billing STR
STR specifies the accounting identification used by the
remote host (not Multics); there is no default.
-catalogue <file_name>, -cat <file_name>
For a non-Multics system, <file_name> specifies a catalogue
file. This control argument is required only when the
catalogue file for the file description is not implicitly
known. <file_name> must be specified in a syntax acceptable
to the host on which the file will resides; it must be
enclosed in quotes if it contain spaces or special
characters.
-no_password, -npw
if the -no_password control argument is present the user
will not be prompted for a password with a mask. The
password will not be used by the remote host to authenticate
the submitter.
-password, -pw
If the -password control argument is present, the user will
be prompted for a password with a mask. The password may be
used by the remote host to authenticate the file transfer.
For a remote Multics system, the -password control argument
is mandatory. (Default)
-person STR, -user STR
STR specifies the remote user identification used by the
remote system on whose behalf the information is to be
obtained. This may be used by the remote host for
authentication of the submitter. The default is the Multics
user_id of the user who submitted the request.
-project STR, -pj STR
STR specifies the project identification used by the remote
system on whose behalf the information is to be obtained.
The following is an example of the get_information request
which will return all pertinent information about the segment
cr_1:
gi -nm uft_dest>cr_1 -at dsa.MUL1.FILETRAN -att all
SET DEFAULT FOR REQUESTOR OPTIONS - R_DEFAULT REQUEST
The format of the server request is:
r_default {<control_args>}
CONTROL ARGUMENTS:
-at <correspondent>
<correspondent> is the name given in the Network Information
Table (NIT) to the remote UFT application. The NIT
associates to the UFT correspondent name its DSA network
address (session_id and mailbox).
-billing STR
STR specifies the accounting identification used by the
remote host (not Multics); there is no default.
-password, -pw
If the -password control argument is present, the user will
be prompted for a password with a mask. The password may be
used by the remote host to authenticate the file transfer.
For a remote Multics system, the -password control argument
is mandatory. (Default)
-person STR, -user STR
STR specifies the remote user identification used by the
remote system on whose behalf the information is to be
obtained. This may be used by the remote host for
authentication of the submitter. The default is the Multics
user_id of the user who submitted the request.
-project STR, -pj STR
STR specifies the project identification used by the remote
system on whose behalf the information is to be obtained.
SET TRACE FOR REQUESTOR OPTION - R_TRACE REQUEST
See Appendix A.
RENAMING A FILE ON A REMOTE HOST - RENAME REQUEST
The rename request lets you rename a file on a remote host.
The format of the rename request is:
rn {-name} <file_name> -at <correspondent> {<control_args>}
where:
<file_name>
<file_name> indicates the name of the file to be renamed and
must be specified in a form acceptable to the host on which
the file resides. If <file_name> begins with a "-", it must
be preceded by -name (or -nm). <file_name> must be followed
by "-at <correspondent>". It must be enclosed in quotes if
it contains spaces or special characters.
-at <correspondent>
<correspondent> must be the name given in the Network
Information Table (NIT) to the remote UFT application. The
NIT associates to the UFT correspondent name its DSA network
address (session_id and mailbox).
CONTROL ARGUMENTS:
-billing STR
STR specifies the accounting identification used by the
remote host (not Multics); there is no default.
-catalogue <file_name>, -cat <file_name>
for a non-Multics system, <file_name> specifies a catalogue
file. This control argument is required only when the
catalogue file for the file description is not implicitly
known. <file_name> must be specified in a syntax acceptable
to the host on which the file will resides. It must be
enclosed in quotes if it contain spaces or special
characters.
-new_name STR, -nwnm STR
STR must be the file_name of the file being renamed and must
be specified in a form acceptable to the host on which the
file resides. It must be enclosed in quotes if it contains
spaces or special characters. If the remote system is a
Multics, the file name is an entryname.
-no_password, -npw
if the -no_password control argument is present the user
will not be prompted for a password with a mask. The
password will not be used by the remote host to authenticate
the submitter.
-password, -pw
if the -password control argument is present, the user will
be prompted for a password with a mask. The password may be
used by the remote host to authenticate the submitter. For
a remote Multics system, the -password control argument is
mandatory. (Default)
-person STR
STR specifies the remote user identification used by the
remote system on whose behalf the renaming is to be
executed. This may be used by the remote host for
authentication of the submitter. The default is the Multics
user_id of the user who submitted the request.
-project STR
STR specifies the project identification used by the remote
system on whose behalf the renaming is to be executed.
In the following example, the rename command is used to
rename the file cr_1 to rn_1:
rn uft_dest>cr_1 -at dsa.MUL1.FILETRAN -nwnm rn_1
SET DEFAULT FOR SERVER OPTION - S_DEFAULT REQUEST
The DSA UFT Server function accepts incoming file transfers
from remote systems. The DSA UFT server function is executed in
the user process without prior execution of a start_up.ec file.
The server request retains arguments for the server in the user
value segment as a substitute for the start_up.ec file. The
server request is the only request associated with the Server
function; if used, it must be issued from the DSA UFT subsystem.
The format of the server request is:
s_default {<control_args>}
CONTROL ARGUMENTS:
-change_default_working_dir <pathname>, -cdwd <pathname>
defines a working directory for the UFT Server other than
the user's default working directory.
-no_working_dir, -no_wd
the user's default working directory is used to contain
incoming file transfers from the Server function. This is
the default.
-notify, -nt
Server process notifies the user upon completion of file
transfer.
-no_notify, -no_nt
Server process does not notify the user upon completion of
file transfer (default).
SET TRACE FOR SERVER - S_TRACE REQUEST
See Appendix A.
PERFORMING INTERACTIVE FILE TRANSFER - UNIFIED FILE TRANSFER
REQUEST
The unified_file_transfer (uft) request lets you submit an
interactive file transfer request to a remote host.
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 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.
The format of the unified_file_transfer request is:
eur path1 {path2} <-to|-from DEST> {<uft_args>} {<-control_args>}
where:
-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 "-". <source_file> 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.
-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).
UFT_args:
Are the deferred file transfer request control arguments. All
of the control arguments specified for the interactive file
transfer request are valid. Refer to the
unified_file_transfer_args.gi (uft_args.gi) for details of the
arguments allowed.
CONTROL ARGUMENTS:
(See appendix B for a list of control arguments)
The following example illustrates the procedure for
submitting an interactive file transfer request to a remote
Multics host; no file compression is specified (-ncmpr); if the
destination file already exists, it will be kept (-dst) and the
file transfer will be considered successful (see above):
uft uft_origin>unstructured_1 -nm uft_dest>unstructured_1
-to dsa.MUL1.FILETRAN -ncmpr -dst tc
In the following example, a file transfer request is issued
to receive a file from a remote DPS6 host; no file compression is
used (-ncmpr); the destination file is kept if it already exists;
the file organization is specified as sequential (-dorg
sequential):
uft >>UDD>GAUMETOU>COMPRESSION -nm
uft_returned>compression -ncmpr -dst tc
-dorg sequential -from S869
Table 1-1. Requests for Queued UFT File Transfer Requests.
REQUEST ABBREVIATION ACTION
cancel_uft_request cur Cancel and delete a deferred
UFT request
enter_uft_request eur Queue a UFT request for later
execution
list_uft_correspondent luc list uft correspondence
list_uft_request lur List the status of selected
queued UFT requests
modify_uft_request mur Modify the queuing parameters
of queued UFT requests
See Section 2 for the descriptions of the above requests.
SECTION 2
DSA AND UFT MULTICS COMMANDS
Submitting a Queued DSA UFT Request
To submit a queued DSA UFT request, invoke the DSA UFT
subsystem as described above with the dsa_uft command. You can
issue any of the queued DSA UFT request listed in Table 1-1 from
the DSA UFT subsystem. You have the option of entering the DSA
UFT queued file transfer request itself either from the DSA UFT
subsystem or from Multics command level.
Table 1-1. Requests for Queued UFT File Transfer Requests.
REQUEST ABBREVIATION ACTION
cancel_uft_request cur Cancel and delete a deferred
UFT request
enter_uft_request eur Queue a UFT request for later
execution
list_uft_correspondence luc list uft correspondence
list_uft_request lur List the status of selected
queued UFT requests
modify_uft_request mur Modify the queuing parameters
of queued UFT requests
NAME: CANCEL_UFT_REQUEST,, CUR
SYNTAX AS A COMMAND
cur <entryname> {<control_args>}
FUNCTION
The cancel_uft_requests (cur) request lets you cancel and delete
queued file transfer requests. A request that is currently
running cannot be cancelled and deleted by this request.
Entryname is the name of the source file.
CONTROL ARGUMENTS
-entryname <STR>, et
STR is the entryname of the source file.
-identifier <request_id>, -id <request_id>
specifies that <request_id> is the id of the request to be
cancelled. This is returned by the enter_uft_request request.
See the Multics Programmer's Reference Manual for a
description of Request IDs.
-at STR
STR is the correspondent name given in the NIT (Network
Information Table) to the remote UFT application. If this
control argument is present only the requests for this
corespondent will be cancelled. If this control argument is
omitted, the requests for all correspondents will be
cancelled.
-queue N, -q N
specifies that the request to be cancelled is in priority
queue N. If this control argument is omitted, only the
default priority queue will be checked.
-all, -a
specifies that all priority queues should be checked for this
request. This control argument is incompatible with the
-queue control argument. The default is to only check the
default priority queue for this function.
-brief, -bf
suppresses messages telling that a particular request
identifier was not found or that requests were cancelled. The
default is to print these messages. kx -user <user_id>
specifies the name of the submitter of the request to be
cancelled, if not specified, the user_id of the current
___________________ __________________
cancel_uft_request, enter_uft_request,
___________________ __________________
process is assumed. The <user_id> can be of the form:
Project_id, Person_id, or .Project_id. Both r and d extended
access to the queue are required. This control argument is
primarily for operators and administrators.
ENTERING A QUEUED UFT REQUEST - ENTER_UFT_REQUEST REQUEST
________________________________________
NAME: ENTER_UFT_REQUEST,, EUR
SYNTAX AS A COMMAND
eur path1 {path2} <-to|-from DEST> {<uft_args>} {<-control_args>}
FUNCTION
The enter_uft_request (eur) request lets you queue a file
transfer request for later execution. When you enter the
request, a deferred request id is printed, that must be used when
issuing the cancel_uft_request, list_uft_request, or
modify_uft_request requests.
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 "-". <source_file> 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.
-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
__________________ __________________
enter_uft_request, enter_uft_request,
__________________ __________________
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).
Uft_args:
Are the deferred file transfer request control arguments. All
of the control arguments specified for the interactive file
transfer request are valid. Refer to the
unified_file_transfer_args.gi (uft_args.gi) for details of the
arguments allowed.
CONTROL ARGUMENTS
-brief, -bf
suppresses any printed output from the request. The default
is to print a line indicating the request_id and how many
similar requests are already queued.
-comment STR, -com STR
specifies <string> as a comment to be carried with the queued
request. This could be used to convey information to the
Multics operator for requests that are deferred. There is no
default comment.
-long_id, -lgid
causes the long form of the request id to be printed for a
queued request. The default is to print the short form of the
request id.
-notify, -nt
notifies the submitter after the entry is transferred.
(Default)
-long_notify, -lgnt
A notification is sent to submitter just before transfer
begins and another one, more detailed, when transfer is over.
__________________ __________________
enter_uft_request, enter_uft_request,
__________________ __________________
-no_notify, -nnt
does not notify the submitter.
-queue N, -q N
specifies the priority queue for this request. The default is
to enter the request in the default priority queue. The
number of queues available and the default queue are specified
in the iod tables.
ACCESS REQUIRED
To send a file, you must have "r" (read) access to the file. If
you specify deletion of the file after successful completion of
the transfer, you must have "m" (modify) access to the directory
containing the file. You must also specify the same access for
the daemon process performing the queued transfer
(UftS.SysDaemon). You must also give the UftS.SysDaemon "s"
(status) access to the directory containing the file to be
transferred for validation purposes. For example, when sending a
queued file transfer request, use the following commands to set
the appropriate access for the UftS.SysDaemon:
sa <file_name> r UftS.SysDaemon
sa <directory_name> sm UftS.SysDaemon
If you are to receive a file, you must have "sma" (status,
modify, append) access to the directory that is to contain the
file. For example, you could use the following command to set
the appropriate access to the directory:
sa <directory_name> sma <person_id>
The IO.SysDaemon process must also have "sma" access to the
directory that is to receive the file. In addition, the
IO.SysDaemon process must have "s" access to the directory
containing the directory that is to receive the file for
validation purposes.
__________________ _________________
enter_uft_request, list_uft_request,
__________________ _________________
NAME: LIST_UFT_REQUEST,, LUR
SYNTAX AS A COMMAND
lur <entryname> {<control_args>}
FUNCTION
lists Unified file transfer requests in the I/O daemon queue.
CONTROL ARGUMENTS
-entryname <entryname>, et < >
specifies that entryname is the entryname of the source file.
-identifier <request_id>, -id <request_id>
specifies that <request_id> is the id of the request to be
listed. This is returned by the enter_uft_request request.
See the Multics Programmer's Reference Manual for a
description of Request IDs.
-at <correspondent>
<correspondent> is the name given in the NIT (Network
Information Table) to the remote UFT application. If this
control argument is present only the requests for this
correspondent will be listed. If this control argument is
omitted the requests for all correspondents will be listed.
-queue N, -q N
specifies that only requests in priority queue N are to be
listed. If this control argument is omitted, only requests in
the default priority queue will be listed.
-all, -a
specifies that requests in all priority queues should be
listed. This control argument is incompatible with the -queue
control argument. The default is to only list the default
priority queue for this function.
-long, -lg
causes all of the queue specific information about the request
to be listed. This includes time, comment, requests this
request is being held for, etc. No request specific
information is listed. The default is to only print a line
containing the short id, the current state, and the priority
of the request.
_________________ ___________________
list_uft_request, modify_uft_request,
_________________ ___________________
-request_info, -rqi
causes any request specific information to be listed. The
actual information listed is dependent on the type of request.
The default is not to list any request specific information.
-total, -tt
only lists totals for the requests selected by the other
control arguments.
-admin {user_id}, -am {user_id}
selects requests of all users or of the specified user inside
queue specified with argument "-queue" or "-all". Default
user_id is all users, and requires read extended access to the
queue(s) to read other users' requests.
-position, -psn
prints queue positions of each selected request. With -total,
prints a list of queue positions. Requires r extended access
to the queue(s), to read other users requests.
MODIFYING A QUEUED UFT REQUEST - MODIFY_UFT_REQUEST REQUEST
________________________________________
NAME: MODIFY_UFT_REQUEST,, MUR
SYNTAX AS A COMMAND
mur <entryname> {<control_args>}
FUNCTION
This command allows a user to modify the queuing parameters that
you specified in an enter_uft_request. Entryname is the name of
the entryname of the source file.
CONTROL ARGUMENTS
-entryname <entryname>, -et
specifies that entryname is the name of the source file.
-identifier <request_id>, -id <request_id>
___________________ ___________________
modify_uft_request, modify_uft_request,
___________________ ___________________
specifies that <request_id> is the id of the request to be
modified. This is returned by the enter_uft_request request.
See the Multics Programmer's Reference Manual for a
description of Request IDs.Edit
-user STR
STR specifies the user identification used by the remote
system on whose behalf the file transfer is to be done. This
may be used by the remote host for authentication of the file
transfer. The default is the Multics user_id of the user who
submitted the request.
-project STR, -pj STR
STR specifies the project identification used by the remote
system on whose behalf the file transfer is to be done.
-at STR
STR is the correspondent name given in the NIT (Network
Information Table) to the remote UFT application. If this
control argument is present only the requests for this
corespondent will be modified. If this control argument is
omitted the requests for all correspondents will be modified.
-comment STR, -com STR
specifies that the comment on the request should be changed to
<string>.
-notify, -nt
notifies the submitter after the entry is transferred.
(Default)
-long_notify, -lgnt
A notification is sent to submitter just before transfer
begins and another one, more detailed, when transfer is over.
-no_notify, -nnt
does not notify the submitter.
-to_queue N, -q N
specifies that the request should be moved to priority queue
N.
SECTION 3
MULTICS DSA UNIFIED FILE TRANSFER FACILITY CONFIGURATION
This section contains the information necessary to configure
Multics DSA UFT on your Multics system.
The Multics DSA UFT facility can be configured to execute
interactive file transfer requests, queued file transfer
requests, or both interactive file transfer requests and queued
file transfer requests depending upon the needs of the particular
site.
CONFIGURING THE MULTICS DSA UFT FACILITY
To configure Multics DSA UFT on your system to process
interactive file transfer requests, the only procedure that must
be performed is:
1. Add specific UFT entries to the NIT (see below).
To configure the Multics DSA UFT facility for queued file
transfer processing or both interactive and queued file transfer
processing, the following procedures must be performed:
1. Add specific UFT entries to the NIT (see below).
2. Define I/O SysDaemon in Input/Output daemon table (IODT) -
Request_type and Device statements
3. Register the UFT I/O daemon in the PMF and PNT
4. Create the DSA UFT message coordinator which includes:
- creating input and output message segments
- creating message coordinator sources and virtual
console
- defining message coordinator channel in the Channel
Master File
Each of the above procedures is described in detail below.
Defining the Network Information Table Entries (NIT) for DSA UFT
The entries required for the Network information table are
described in detail in Section 4 of the Multics DSA Administrator
Guide. They include:
o System statement
o Mailbox statement
o session_type_descriptor statement
o Service statement
o Correspondent statement
The requirements for each statement are briefly described below.
Refer to section 4 of the Multics DSA Administrator Guide (68 A2
74SB) for a complete description of each statement.
THE SYSTEM STATEMENT
All of the systems with which the DSA UFT facility will
exchange files must be configured in the Network Information
Table. The substatement "system_type" is used to adapt the
processing of the local DSA UFT facility to the requirements of
the remote system(s).
THE MAILBOX STATEMENT
The "dsa.SCID.FILETRAN mailbox must be configured with the
substatement "service:login_service;". This mailbox is used by
the login server to listen to and accept the sessions initiated
by the remote system.
The "dsa.SCID.UFT_REQ mailbox must be configured with the
substatement "service:uft_service;". This mailbox is used by the
Requestor functions of the local DSA UFT facility to connect to
remote DSA UFT applications.
THE SESSION_TYPE_DESCRIPTOR STATEMENT
Within the session_type_descriptor statement:
o the "mode" substatement values are forced to "twai"
(two way alternate, initiate turn)
o The "protocol" substatement values are forced by UFT
and none of the protocols are selected
o In the "options" substatement, the "nine_bit" option is
forced by UFT
o For system performance purposes, it is strongly
recommended that the "multiple_records" and
"mixed_records" options be specified.
THE SERVICE STATEMENT
The Service statement should be specified as follows:
Service: login_service;
endpoint: dsa.<Sc_loc name>.FILETRAN,
get_service_module: >...>dsa_uft_login_service_;
end;
The "endpoint" substatement must be added to the definition of
the login service to listen to and accept from remote systems.
The second Service statement required is as follows:
Service: uft_service;
endpoint: dsa.<Sc_loc name>.UFT_REQ;
get_service_module: >...>dsa_uft_login_service_;
end;
THE CORRESPONDENT STATEMENT
The substatement "request_type" specifies the I/O SysDaemon
request type that must be used to enqueue deferred file transfer
requests for this correspondent. The default value is "dsa_uft".
The Correspondent statement is not necessary if no specific
Request_type must be defined. If a Request_type is defined, it
must also be defined in the I/O daemon tables.
Defining the I/O SysDaemon for DSA UFT
THE UFT REQUESTOR FUNCTION
The requestor function is performed by an I/O SysDaemon
(IO.SysDaemon uftr). The driver dsa_uft_driver_ is responsible
for :
- managing uft requests queues under control of the coordinator.
- validating requests sent by the coordinator.
- establishing remote server connections.
- transferring files.
QUEUE MANAGEMENT
The standard IO driver operator commands are allowed.
Request processing is always interrupted by quit. After the
quit:
- start -> processing resumes
- cancel -> request is lost
- defer -> request is kept in queue for a later reprocessing
- kill -> request is saved in the coordinator's saved list
for 'grace_time'
- save -> request is saved until the coordinator logs out.
Killed or saved requests can be restarted by the restart
command.
Deferred requests are reprocessed by restart_q command.
If the connection is refused or if the transfer is
interrupted, then the request is deferred. The driver will
automatically attempt a 'restart_q' after a setable delay. This
feature can be inhibited.
SPECIAL COMMANDS FOR UFT DRIVER
One command is available :
- restart_delay [time]
sets the automatic restart_q delay.
(Default is restart)
NOTES
If the requestor seems to be blocked while processing a request,
the cancel command (after quit) will cause the session to be
terminated and the driver to process the next request.
The Daemon requestor has to check the user's access on the files
to be transferred (both as sender and receiver).
There will not be major changes in the requestor for the final
full DSA version.
IOD_TABLES
/* UFT */
Request_type: dsa_uft;
generic_type: dsa_uft;
driver_userid: IO.SysDaemon;
default_queue: 3;
accounting: nothing;
max_access_class: system_high;
device uft;
Device uft;
driver_module: >sl3p>dsa>e>dsa_uft_driver_;
line *;
args " ";
default_type: dsa_uft;
To define the I/O daemon for DSA UFT you must:
1. Edit the appropriate Device and Request_type definitions
into the I/O daemon tables
2. Compile the I/O daemon tables with the iod_tables_compiler
request.
The pathname of the I/O daemon table at most sites is
>ddd>idd>iod_tables.iodt. The specific entries required in the
I/O daemon table for DSA UFT are detailed in the I/O SysDaemon
Tables Statements below.
I/O SYSDAEMON TABLES REQUEST_TYPE STATEMENTS FOR DSA UFT
DSA UFT requires the following Request_type statement and
substatements in the I/O daemon tables:
Request_type: <name>;
The Request_type <name> must be "dsa_uft" or one of the
request types referred to by the "correspondents" in the
Network Information Table. Otherwise, the request type will
not be used.
generic_type: <name>;
DSA UFT requires <name> to be "dsa_uft".
driver_userid: <Person_id.Project_id>;
Must identify the user identity selected to run this
connection.
default_queue: <number>;
For DSA UFT, you can select any default queue number you
choose for your site.
accounting: <name>;
DSA UFT requires <name> to be "nothing".
max_access_class: <string>;
There is no restriction on the access class that can be
specified for DSA UFT.
Device: <name>;
Specifies the devices that can be used to process requests
of the associated type. More than one device substatement
can be defined per request type.
request_type_info: <...>;
The DSA UFT driver is always "autogo"; the driver wait time
can be any value.
I/O SYSDAEMON TABLES DEVICE STATEMENTS FOR DSA UFT
DSA UFT requires the following device statement and
substatements to define the input/output driver in the I/O daemon
tables:
Device: <name>;
Defines the name of a major device and denotes the beginning
of a device description. Any subrequest statements (see
below) apply to this device until the next Line, Device, or
Request_type statement is encountered. The device <name>
should be one of the names referred to by the request type.
driver_module: <name>;
For DSA UFT, <name> must be >sl3p>dsa>e>dsa_uft_driver_"
line: <name>;
For DSA UFT, <name> must be "*".
args: <string>;
For DSA UFT, <string> should be " " since UFT receives its
arguments from the Network Information Table.
REGISTERING THE DSA UFT DAEMON PERSON_ID IN THE PROJECT MASTER
FILE
The Project Master File is the basic project-administration
data base and contains the project's specification of user
attributes and the list of users who are permitted to log in
under the project. The PMF must be converted to the
system-usable Project Definition Table (PDT) with the cv_pmf
request.
DSA UFT runs under the SysDaemon (>udd>SysDaemon) project.
The DSA UFT Person_id (I/O) and associated attributes must be
added to the Project Master File for the SysDaemon project and
the PMF converted to the PDT. Using an editor, invoke the PMF
for the Daemon project and add the following entries to define
the DSA UFT daemon person_id:
Person_id: <character_string>;
<character_string is the Multics Person_id. The recommended
Person_id is "I/O"
initproc: <pathname>;
the pathname must be "iod_overseer_"
attributes: <character_strings>;
the <character_strings> are attribute names separated by
commas DSA UFT requires that you use the following attribute
names:
^v_process_overseer Indicates that no other process overseer can be
specified for DSA UFT.
daemon DSA UFT can be logged in by the operator via the
message coordinator (see below).
multip Permits multiple logins for DSA UFT.
REGISTERING THE I/O SYSDAEMON IN THE PERSON NAME TABLE
The I/O SysDaemon must be registered in the Person name
Table (PNT) and the User Registration File (URF). To register
the I/O SysDaemon user identity in both the PNT and URF, use the
"new_user$nua" request. The dsa_uft.Daemon user identity must be
registered:
CREATING THE MESSAGE COORDINATOR FOR DSA UFT
For the DSA UFT daemon to issue messages and receive
directives, you must:
1. create the input and output message segments
2. establish the message coordinator sources and virtual
consoles
3. if the operator connects to Multics via a MCS front-end,
register a message coordinator channel in the CMF for the
terminal being used to send and receive messages
4. if the operator connects to Multics via a DSA front-end,
virtual message coordinator channels are used (see the DSA
Operator manual for details).
The procedures for performing each of the above functions are
described below.
Creating Input and Output Message Segments for DSA UFT
For the DSA UFT SysDaemon to issue messages and receive
directives, you must create the input and output message
segments. To do this, issue the following create request only
once to create the input and output message segments:
create >system_ccontrol_1>(input_source_name output_source_name).message
using create_daemon_queries command.
This permanently creates the required input and output message
segments in the system_control_1 directory.
Creating Message Coordinator Sources and Virtual Consoles for DSA
UFT
Use the define request and the route request to establish
the virtual console and message coordinator sources, respectively
(see below). Most often, the two requests are entered in the
system_start_up.ec file.
DSA UFT messages can be sent to:
o an actual terminal
o a log file
o both a log file and a terminal
If you want to send messages to a terminal only, or a
terminal and a log file, you must register a message coordinator
channel for the terminal in the Channel Master File (CMF) and
issue an accept request in addition to the define request and
route request (see below).
VIRTUAL CONSOLE DEFINITION FOR DSA UFT - DEFINE REQUEST
The define request defines the virtual console that will
receive messages from the DSA UFT daemon. The format of the
define request is:
define VCONS TYPE DEST
The define request must be used in conjunction with the
sc_request request. For example, to define a virtual console
named dsa_iod that forwards all output to the terminal whose
channel is dsa.h200 as defined in the CMF the following request
would be used:
sc_request define dsa_iod tty dsa.h002
To define a virtual console that forwards all output sent to it
to a log file named dsa_iolog, the following request would be
used:
sc_request define dsa_iolog log dsa_iolog
ROUTING DSA UFT DAEMON OUTPUT - ROUTE REQUEST
The route request sends output from the DSA UFT daemon to
the designated virtual console. A route request must be issued
for the user_i/o, error_i/o, and log_i/o streams of the input
driver and output driver. The format of the route request is:
route SOURCE STREAM VCON
APPENDIX A
MULTICS DSA UFT TRACE FACILITY
The Multics DSA UFT trace facility lets you perform various
tracing features. It is intended for use by the programming
staff.
THE TRACE REQUESTS
The trace request lets you perform a trace of all file
transfers executed by your person_id on the following:
o Server function
oo Requestor function
o Login server
Each of the these trace requests have the same control arguments
(described below).
The format of the Server function trace request is:
s_trace {<control args>}
The format of Requestor function trace request is:
r_trace {<control_args>}
By using the "errors" option to the -trace control argument
(see below), it will supply you with all user notifications and
errors that occur. Other trace options are for debugging
purposes and are primarily used by programming personnel.
CONTROL ARGUMENTS:
-at <correspondent>
<correspondent> is the name given in the NIT (Network
Information Table) to the remote UFT application.
-length N
-len N
specifies the length of the record that must be traced for
in_records or out_records options.
-trace STR
-tr STR
STR specifies the trace options desired. Trace options can
be structures, states, errors, in_records, out_records,
ctrl_records, or all. For user purposes, only the errors
option is recommended.
-user_log <pathname>
the pathname of the directory where user trace records will
be placed. STR can be "pd" (process directory), "hd" (home
directory), "wd" (working directory), or the full pathname
of any user selected directory.
The following is an example of the r_trace request.
r_trace -tr all -user_log uft_log>dsa_uft_ul
SYSTEM TRACES
When using deferred file transfer requests
(enter_uft_request), the trace options are stored in a value
segment. The "dsa_uft_value_seg" field in the "Mna_general_info"
section of the NIT (Network Information Table) defines the
pathname of this value segment.
Entries in the logfiles (defined in dsa_uft_value_seg) are
created either by the requestor (IO.SysDaemon) or by the uft
server (Login_Server.Daemon).
System trace options can be set by using the exec_com
uft_trace.ec located in the directory >site>dsa>exec_coms. This
exec_com works in an interactive way, asking questions and
setting trace options according to the responses. Following is
an example of an invocation of the exec_com.
ec uft_trace
Trace options in effect :
dsa_uft_req_trace_length "140"
dsa_uft_req_trace_options "101001"
dsa_uft_req_trace_user_log ">udd>Multics>Darras>uft>r_log"
dsa_uft_server_trace_length "0"
dsa_uft_server_trace_options "000000b"
dsa_uft_server_trace_user_log " "
Modify these options ? y
Requestor or Server (r/s) ? s
Setting server trace options.
Turn on the trace (y/n) ? y
Setting log pathname.
Log dirname (>site>DSA>uft_logs_dir) :<uft
Log entryname (s_log) :
Setting trace options (answer y to set, n or CR to Reset).
Structures :y
States :
Errors :y
Input :
Output :
Control_rec :y
Setting record length.
Record length (140) :
Trace options in effect :
dsa_uft_req_trace_length "140"
dsa_uft_req_trace_options "101001"
dsa_uft_req_trace_user_log ">udd>Multics>Darras>uft>r_log"
dsa_uft_server_trace_length "140"
dsa_uft_server_trace_options "101001"
dsa_uft_server_trace_user_log ">udd>Multics>Darras>uft>s_log"
Modify these options ? n
Tracing features may only be used by qualified personnel for
debugging purposes. Write access on the dsa_uft_value_seg should
be restricted to privileged users. Typical acls should be :
r IO.SySDaemon.*
r Login_Server.Daemon.*
rw *.SysAdmin.*
rw *.Sysmaint.*
APPENDIX B
UNIFIED FILE TRANSFER REQUESTS ARGUMENTS
Inside Unified File transfer requests, control arguments
that affect the characteristics of the destination file are
prefixed by "-d" (for example, -d_data_type). 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.
Control argument (transfer mode):
-brief, -bf
no messages are issued by the UFT subsystem.
-record_transfer, -rctf
force record transfer between two Multics systems.
-compression, -cmpr
specifies that the file should be compressed for the transfer
to allow more efficient use of the line.
-no_compression, -ncmpr
specifies that the file should not be compressed for the
transfer.(default)
-checkpoint_interval N, -ckm_int N
specifies that checkpoint marks should be used every N records
during the transfer. When Multics DSA UFT is the sender, the
default is not to use checkpointing.
-s_delete, -sdl
mark the source file for deletion after the transfer has been
completed. The file will actually be deleted only if the
transfer was successful. The default is not to delete the
source file.
-person STR, -user STR
STR specifies the user identification for system on whose
behalf the file transfer is to be done. It may be used by the
remote host for authentication. Default is the Multics
user_id of the user who submitted the request.
-project STR, -pj STR
STR specifies the project identification used by the remote
system on whose behalf the file transfer is to be done.
-billing STR
STR specifies the accounting identification used by the remote
host (for non-Multics systems) there is no default.
-password, -pw
If the control argument is present, the user will be prompted
for a password with a mask. The password may be used by the
remote host to authenticate the file transfer. For a remote
Multics system the password is mandatory. (Default).
-no_password, -npw
If the control argument is present, the user will not be
prompted for a password .
Control argument (Source file):
-s_record_format STR, -srf STR
specifies the record format of the source file being
transferred. The record format can be fixed, variable, or
undefined.
-s_max_record_len N, -smrl N
the maximum record length of the source file.
-s_control_interval_size N, -scis N
the control interval size to be used for the source file. The
maximum allowable control interval size is 65535. For
Multics, there is no control interval size.
-s_data_type <data_type>, -sdt <data_type>
the data type of the data in the source file to be
transferred. The data type can be ascii, binary, ebcdic,
gbcd, hbcd, jis, or undefined. The default is ascii.
-s_file_format STR, -sff STR
the specific format of the source file to be transferred. The
file format can be disk_ufas_6_66, disk_36_bit_ufas,
disk_64_ufas, disk_68, disk_66_gfrc, disk_64_bfas, disk_62,
disk_6_no_ufas, disk_ibm_no_vasm, disk_ibm_vsam,
tape_ufas_ans_ascii, tape_ufas_ebcdic, tape_66_gfrc,
tape_foreign, diskette_basic_iso, diskette_basic_ibm,
cassette_standard_iso, or cassette_foreign. The file format
for Multics is "disk_68".
-s_format_version N, -sfv N
the version of the source file format. The format version can
be 0, 1, or 3. For Multics, the format version is 1 or 3 for
tape_ufas_ans_ascii (the default is 1). For other formats,
the default value is correct.
-s_control_interval_format STR, -scif STR
the control interval format of the source file to be
transferred. The control interval format can be
blocked_unspanned, unblocked_unspanned, blocked_spanned, or
unblocked_spanned. For Multics, there is no control interval
format.
-s_label_definition STR, -sld STR
specifies the tape labels for source tape files. Tape labels
can be standard, non_standard, unlabelled, or compact.
-s_block_serial_number N, -sbsn N
specifies the block serial numbers for source tape files.
-s_catalogue <file_name>, -scat <file_name>
for a non-Multics system, <file_name> specifies a catalogue
file. This control argument is only needed when the catalogue
file containing the file description is not implicitly known.
-s_file_sequence_number N, -sfsn N
for tape files only. Indicates a multifile tape and specifies
the file sequence number within the tape(s). N can be any
number from 0 to 255. Zero (0) has the special meaning "any"
(tape number); 255 has the special meaning "next" (tape
number). Absence of a special value indicates a monofile
tape.
-s_no_rewind, -snr
specifies the tape positioning at the end of a tape transfer.
-s_unload, -sunl
specifies tape status at the end of a tape transfer
Control argument (Destination file):
-d_allocation_size_unit STR, -dasu STR
the allocation unit used. The allocation unit can be kbytes,
record, or ci. The default is record. This control argument
is ignored by Multics DSA UFT.
-d_current_allocation_size STR, -dcas STR
the current file allocation in the unit specified by
-d_allocation_unit_size, above. If the source file is on
Multics, Multics UFT automatically provides this information
to the remote system.
-d_increment_allocation_size STR, -dias STR
the size of the increment to be used in the unit specified in
-d_allocation_unit_size argument, above. If the destination
file is on Multics, this argument is ignored.
-d_max_allocation_size STR, -dmas STR
the maximum allocation size for the file in the unit specified
in the -d_allocation_unit_size argument, above. If the
destination file is on Multics, this argument is ignored.
-d_expiration_date STR, -ded STR
STR is expiration date of the destination file in the
following format YYMMDD where YY is the year, MM is the month,
and DD is the day. Optionally, hhmmss can be specified where
hh is the hour, mm is the minute, and ss is the second. If
the destination file is on Multics, this argument is ignored.
-d_status STR, -dst STR
STR specifies what is to be done if the destination file to be
created already exists. Values for STR : truncate (tc, or
keep)
replace (rp)
extend (ext, or append)
new (Default) if STR is new, an error will
be returned if file is already existing. (only case of
returned error).
-d_organization STR, -dorg STR
the file organization of the destination file to be created.
STR can be sequential, relative, indexed, extended_indexed,
general_indexed, random, queued, l6_r2, l6_r5, byte_stream, or
unstructured. It specifies the file organization of the file
to be created. Multics supports only unstructured,
sequential, relative, and general_indexed file organizations.
The default is sequential.
-d_record_format STR, -drf STR
specifies the record format of the destination file. The
record format can be fixed, variable, or undefined.
-d_max_record_len N, -dmrl N
the maximum record length of the file.
-d_control_interval_size N, -dcis N
the control interval size to be used for the destination file.
The maximum allowable control interval size is 65535. For
Multics, there is no control interval size.
-d_data_type <data_type>, -ddt <data_type>
the data type of the data in the destination file to be
transferred. The data type can be ascii, binary, ebcdic,
gbcd, hbcd, jis, or undefined. The default is ascii.
-d_file_format STR, -dff STR
the specific format of the destination file. The file format
can be disk_ufas_6_66, disk_36_bit_ufas, disk_64_ufas,
disk_68, disk_66_gfrc, disk_64_bfas, disk_62, disk_6_no_ufas,
disk_ibm_no_vasm, disk_ibm_vsam, tape_ufas_ans_ascii,
tape_ufas_ebcdic, tape_66_gfrc, tape_foreign,
diskette_basic_iso, diskette_basic_ibm, cassette_standard_iso,
or cassette_foreign. The file format for Multics is
"disk_68".
-d_format_version N, -dfv N
the version of the destination file format. The format
version can be 0, 1, or 3. For Multics, the format version is
1 or 3 for tape_ufas_ans_ascii (the default is 1). For other
formats, the default value is correct.
-d_control_interval_format STR, -dcif STR
the control interval format of the destination file. The
control interval format can be blocked_unspanned,
unblocked_unspanned, blocked_spanned, or unblocked_spanned.
For Multics, there is no control interval format.
-d_label_definition STR, -dld STR
specifies the tape labels for destination tape files. Tape
labels can be standard, non_standard, unlabelled, or compact.
-d_block_serial_number N, -dbsn N
specifies the block serial numbers for destination tape files.
-d_catalogue <file_name>, -dcat <file_name>
for a non-Multics system, <file_name> specifies a catalogue
file. This control argument is only needed when the catalogue
file containing the file description is not implicitly known.
-d_file_sequence_number N, -dfsn N
for tape files only. Indicates a multifile tape and specifies
the file sequence number within the tape(s). N can be any
number from 0 to 255. Zero (0) has the special meaning "any"
(tape number); 255 has the special meaning "next" (tape
number). Absence of a special value indicates a monofile
tape.
-d_no_rewind, -dnr
specifies the tape positioning at the end of a tape transfer.
-d_unload, -dunl
specifies tape status at the end of a tape transfer
EXAMPLES
The following example illustrates the procedure for submitting a
file transfer request to a remote Multics host on MUL1, file
[user hd]>unstructured_1 is created. If this file is already
existing, request is aborted (default status : new)
eur uft_origin>unstructured_1 -to MUL1
In the following example, a file transfer request is issued to
receive a file from a remote DPS6 host; no file compression is
used (-ncmpr) ; the destination file is kept if it already
exists; the file organization is specified as sequential ( -dorg
sequential):
eur >>UDD>GAUMETOU>COMPRESSION uft_returned>compression
-from S869 -ncmpr -dst tc -dorg sequential