

                                      INTER-MULTICS FILE TRANSFER

                                        FACILITY REFERENCE MANUAL





SUBJECT

     Inter-Multics File Transfer (IMFT) Reference Material




















SPECIAL INSTRUCTIONS

     This is  the first addendum  to CY73, Rev  1, dated December
     1983.

     Throughout this manual, change  bars in the margins indicate
     technical  changes  and   additions,  and  asterisks  denote
     deletions.



SOFTWARE SUPPORTED

     Multics Software Release 12.2



ORDER NUMBER

     CY73-01A                                      October 1988









                             PREFACE




     This  manual is  intended for  system administrators, system
operators, and users.  It  contains the information necessary for
a system  administrator to configure  IMFT, a system  operator to
run  IMFT, and  a user  to  issue,  delete, list,  and move  IMFT
requests, and display foreign site names.


     Section  1  and  Section  2  are  intended  for  the  system
administrator,  and  contain  introductory  information  and IMFT
configuration requirements, respectively.


     Section 3  is intended for the system  operator and contains
the information  the system operator  might require to  run IMFT.
Section 4  contains general user information and  the commands to
issue, delete, list, or move IMFT requests, and list IMFT sites.


     Document                            Referred to in Text as


     Multics Communications                MAM Communications     *
     Administration
     (Order No. CC75)

     Multics Project Administrator's       MAM Project            |
     Manual                                                       |
     (Order No. AK51)

     Multics System Administration         MAM System             |
     Procedures                                                   |
     (Order No. AK50)










(c) Honeywell Information Systems Inc., 1988 File No.: 1L13, 1U13

                                               08/88     CY73-01A

     Multics Maintenance Procedures        System Maintenance     |
     (Order No. AM81)

     Multics Admin, Maint, and             AMOC                   |
     Operations Commands                                          |
     (Order No. GB64)                                             |

     Multics Programmer's Reference        Programmer's Reference
     Manual
     (Order No. AG91)

     Multics Commands and Active           Commands
     Functions
     (Order No. AG92)
                                                                  *

_S_i_g_n_i_f_i_c_a_n_t _C_h_a_n_g_e_s _i_n _C_Y_7_3_-_0_1_A

     IMFT can now support X.25 connections across multiple public |
networks.  It also can be  configured to drop the connection when |
there  is nothing  to transfer  and reconnect  when a  request is |
ready to be processed.                                            |


     Access  checking has  been changed  to require  explicit ACL |
entries  for both  the driver  and user  on all  objects that are |
transferred, as  well as to  the parent directories.   This means |
that the ACL entries must be of the form "Person.Project.*".  The |
"Person.*.*",  "*.Project.*"   or  "*.*.*"  forms  will   not  be |
accepted.


     The  enter_imft_request  command  now  allows  the  user  to |
extend, update,  or replace files  with the -extend,  -update and |
-replace control  options.  The source  file can be  deleted upon |
successful transfer  of the object with the  -delete option.  The |
-date_time_after  option allows  users  to  select objects  to be |
transferred based on their date_time_contents_modified value.
















(c) Honeywell Information Systems Inc., 1988 File No.: 1L13, 1U13

                                               08/88     CY73-01A









                             CONTENTS


                                                         Page

Section 1     Introduction  . . . . . . . . . . . . . .   1-1
                 Structure of an IMFT Connection  . . .   1-1
                    I/O Daemon Driver Processes . . . .   1-2
                    Communication Channels  . . . . . .   1-2
                    Connection Modes  . . . . . . . . .   1-3     |
                       HASP Connection Mode . . . . . .   1-3     |
                       X.25-Slave Connection Mode . . .   1-4     |
                       IMFT-Dial Connection Mode  . . .   1-5     |
                          IMFT-Dial Drivers . . . . . .   1-6     |
                          IMFT-Dial Connection Mode               |
                           Protocol . . . . . . . . . .   1-7
                          IMFT-Dial Idle Disconnect . .   1-7     |
                          IMFT-Dial Connection Mode               |
                           Using an X.25 Multiplexed              |
                           Channel  . . . . . . . . . .   1-8
                          IMFT-Dial Connection Mode
                           Using Asynchronous Channels    1-9

Section 2     Administration of an IMFT Connection  . .   2-1
                 Defining a Multiplexed Channel . . . .   2-1
                    Terminal Type File  . . . . . . . .   2-2
                       TTF Entries for an IMFT HASP
                        Channel . . . . . . . . . . . .   2-3
                       TTF Entries for an IMFT X.25
                        Channel . . . . . . . . . . . .   2-4
                    Channel Master File . . . . . . . .   2-5
                       CMF Entries for a HASP
                        Multiplexed Channel . . . . . .   2-6
                          CMF Entries for a HASP
                           Operator Terminal  . . . . .   2-7
                          CMF Entries for Card-Reader
                           Subchannels  . . . . . . . .   2-9
                          CMF Entries for Card-Punch
                           Subchannels  . . . . . . . .  2-11
                          Channel Master File Example
                           for IMFT HASP Configuration   2-12
                       CMF Entries for an X.25
                        Multiplexed Channel . . . . . .  2-14
                          CMF Entries for X.25 Login              |
                           Subchannels  . . . . . . . .  2-15
                          CMF Entries for X.25 Slave
                           Subchannels  . . . . . . . .  2-17


                               iii             08/88     CY73-01A

                         CONTENTS (cont)


                                                         Page

                          CMF Entries for X.25 Autocall
                           Subchannels  . . . . . . . .  2-19
                          Channel Master File Example
                           for IMFT X.25 Configuration   2-20
                       CMF Entries for Asynchronous               |
                        Login Channels  . . . . . . . .  2-21
                       CMF Entries for Asynchronous               |
                        Autocall Channels . . . . . . .  2-23
                 Defining the I/O Daemon for IMFT . . .  2-24
                    Choosing Names for IMFT Variables .  2-25
                    Access Isolation Mechanism
                     Considerations . . . . . . . . . .  2-26
                    I/O Daemon Table  . . . . . . . . .  2-27
                       I/O Daemon Device Definition for
                        IMFT  . . . . . . . . . . . . .  2-28
                          Device Statements . . . . . .  2-29
                       Request_Type Definition for IMFT  2-40
                          Request_Type Statements . . .  2-41
                    IMFT Project Master File Entries  .  2-43
                    IMFT Person Name Table Entries  . .  2-45
                 Preparing Imft for Operation . . . . .  2-46
                    Assigning Access to the PNT . . . .  2-46
                    Subchannel Access Control Segment .  2-46
                    system_privilege_ Access  . . . . .  2-47
                    queue_admin_ Access . . . . . . . .  2-47
                    Asynchronous Channel Access Control           |
                     Segment  . . . . . . . . . . . . .  2-47
                    Message Coordinator . . . . . . . .  2-48
                       define Command . . . . . . . . .  2-49
                       route Command  . . . . . . . . .  2-49
                    IMFT Initialization . . . . . . . .  2-50
                       login Command  . . . . . . . . .  2-50
                       reply Command  . . . . . . . . .  2-51

Section 3     Operator Procedures . . . . . . . . . . .   3-1
                 Initializing the IMFT Connection . . .   3-1
                 Running the IMFT Driver Process  . . .   3-2
                    The IMFT Input Driver . . . . . . .   3-2
                    The IMFT Output Driver  . . . . . .   3-2
                       Cancelling a Running Request . .   3-3
                       Deferring a Running Request  . .   3-3
                 Terminating an IMFT Connection . . . .   3-5
                    line_speed  . . . . . . . . . . . .   3-6     |
                    receive . . . . . . . . . . . . . .   3-7







                                iv             08/88     CY73-01A

                         CONTENTS (cont)


                                                         Page

Section 4     User Commands . . . . . . . . . . . . . .   4-1
                 Access Requirements  . . . . . . . . .   4-2
                    Notes on AIM  . . . . . . . . . . .   4-5
                       Common Access Class Ceiling  . .   4-5
                 User Commands  . . . . . . . . . . . .   4-7
                    enter_imft_request eir  . . . . . .   4-8
                    list_imft_requests lir  . . . . . .  4-14
                    cancel_imft_request cir . . . . . .  4-19
                    move_imft_request mir . . . . . . .  4-22
                    print_imft_sites  . . . . . . . . .  4-26









































                                v              08/88     CY73-01A








                            SECTION 1


                           INTRODUCTION




     The  Inter-Multics File  Transfer Facility  (IMFT) lets  you
transfer files and subtrees between Multics systems.  This manual |
contains a description of IMFT  on a HASP multiplexed channel, on |
an X.25 multiplexed channel and on asynchronous channels.


     Before  you can  use IMFT   to transfer  files and  subtrees
between systems, it must be configured  as part of both the local
system and the  remote system.  As a system  administrator, it is
your responsibility to configure IMFT on the system for which you
are responsible.


     Once  configured,  IMFT  is  easily  maintained and requires
little,  if any, operator  intervention.  User requests  for data
transfer are placed in priority queues for later processing by an
I/O daemon.


_S_T_R_U_C_T_U_R_E _O_F _A_N _I_M_F_T _C_O_N_N_E_C_T_I_O_N

     An IMFT connection links two  Multics systems, one local and
one remote,  to permit the  transfer of files  and subtrees.  The
IMFT connection requires:

     ox    Two I/O daemon driver processes

     ox    An appropriate communications channel.                  |

This manual provides the information necessary for you, as system
administrator,  to define  the appropriate  communication channel
and   driver   processes.    For   information   about   hardware
requirements and software support for a HASP multiplexed channel, |
an  asynchronous channel  and  an  X.25 multiplexed  channel, see |
Appendix A of the MAM Communications manual (CC75).               |





                               1-1             08/88     CY73-01A


_I_/_O _D_a_e_m_o_n _D_r_i_v_e_r _P_r_o_c_e_s_s_e_s

     On  both the  local system  and the  remote system,  an IMFT
connection requires two I/O daemon driver processes:

     ox    Input driver
          receives files  and subtrees from the  output driver on
          the remote system

     ox    Output driver
          transmits files and subtrees to the input driver on the
          remote system, and  (optionally) transmits requests for
          the  transfer of  files  and  subtrees from  the output
          driver of the remote system


     Associated with the output driver on each system is a set of
priority queues in which users  place transfer requests using the
enter_imft_request  command.   These  queues  are  defined with a
single  I/O daemon Request_type,  as described below.   There may
also be a set of queues used to request transfers from the remote
system; these queues are defined with a separate Request_type.


     For  a complete  description of  I/O daemons,  refer to  the
System Maintenance manual (AM81).


_C_o_m_m_u_n_i_c_a_t_i_o_n _C_h_a_n_n_e_l_s

      Each IMFT configuration requires  either a HASP multiplexed
channel,  two  asynchronous  channels   or  an  X.25  multiplexed |
channel.  There are major  differences between the channel types. |
An X.25 channel operates with  subchannels that can both send AND
receive  information.   A  data  channel  that  functions in this
manner is  called bidirectional.  Asynchronous channels  are also |
bidirectional.    A  HASP  channel,   on  the  other   hand,  has |
subchannels  that   either  send  OR  receive   data;  these  are
unidirectional channels that are  linked into pairs, as described
below.


     The  physical connection  between  two  systems is  either a
hardwired  connection or  a dial-up  connection.  In  a hardwired
connection,  the  two  systems   are  permanently  connected  via
dedicated phone  lines or other similar equipment.   In a dial-up
connection, one  system (system operator)  makes a phone  call to
the other  to establish the connection.  The  IMFT connection can
be either hardwired or dial-up.  Connection type must be either a
Binary   Synchronous  Communication   (BSC)  line   (for  a  HASP
connection), or  a High-level Data Link Control  (HDLC) line (for
an  X.25  connection),  with  line  speeds  up  to  72kb,  or  an |
asynchronous channel.


                               1-2             08/88     CY73-01A


     If  you  use  a  hardwired  connection,  you  can define the
channel and driver processes to permit automatic operation of the
connection without  operator intervention.  If you  use a dial-up
connection, some  operator intervention is required  to start and
stop the driver processes on one or both systems.                 |


_C_o_n_n_e_c_t_i_o_n _M_o_d_e_s                                                  |

     There are several modes of configuring the drivers using the |
various  communications links.  The  HASP connection mode  uses 5 |
subchannels  of a  HASP multiplexer.   The X.25-Slave  connection |
mode uses  slave and dialout subchannels of  an X.25 multiplexer. |
The IMFT-Dial  connection mode uses login/dialout  connections on |
any  bidirectional  communication  link.   The  link  may be X.25 |
login/dialout subchannels or asynchronous login/dialout channels. |
                                                                  |
                                                                  |
HASP CONNECTION MODE                                              |
                                                                  |
     An IMFT configuration on a HASP multiplexed channel requires
the following subchannels:

     ox    1 operator subchannel

     ox    2 card-reader subchannels

     ox    2 card-punch subchannels


     An  IMFT  connection  uses  the  card-reader  and card-punch
subchannels of  a HASP multiplexed channel  to allow simultaneous
data transfer in both directions  over a single physical channel.
Although  IMFT does  not  actually  use physical  card-readers or
card-punches, a HASP multiplexed  channel permits its subchannels
to  be  configured  as   operator  consoles,  card-readers,  card
punches,  or   line  printers.   IMFT  uses   a  card-reader  and
card-punch subchannel pair to  simulate an ordinary bidirectional
data channel.   Each driver requires its own  pair of subchannels
and,   therefore,  an   IMFT  connection   uses  two  card-reader
subchannels and two card-punch subchannels.














                               1-3             08/88     CY73-01A


     The  following figure  shows a  HASP configuration  for both
System A and  System B.  "pun" means card punch,  and "rdr" means
card reader.



              System A                          System B
            /     /\                             /\      \
    Operator     /  \                           /  \      Operator
    Console     /    \                         /    \     Console
     ^         /      \                       /      \         ^
     |        /        \                     /        \        |
     |     Input       Output             Input      Output    |
     |     Driver      Driver             Driver     Driver    |
     |       |          /  \               /  \         |      |
     |       |         /   pun <---------rdr   \        |      |
     |       |        rdr-------------------> pun       |      |
     |      / \                                        / \     |
     |     /   \                                      /   \    |
     |    /    pun <--------------------------------rdr    \   |
     |    rdr-------------------------------------------> pun  |
     |                                                         |
      ---------------------------------------------------------



                 Figure 1-1.  Hasp Configuration



X.25-SLAVE CONNECTION MODE                                        |

     This  IMFT  configuration  on  an  X.25  multiplexed channel |
requires the following subchannels:

     ox    1 slave subchannel

     ox    1 autocall subchannel


     An X.25 connection is bidirectional;  it is configured as an
autocall  subchannel on  one end  (at System  A), and  as a slave
subchannel on the other end  (at System B).  Both subchannels can
receive or send data.  The  autocall or dialout subchannel on one
system  initiates  the  connection  with  the corresponding slave
subchannel on the other system.









                               1-4             08/88     CY73-01A


     The  following  figure  shows  the  X.25  IMFT configuration
between  System   A  and  System  B.   "slv"   stands  for  slave
subchannel, and "auto" stands for autocall subchannel.




                System A                        System B
                /      \                       /      \
            Input       Output             Input       Output
            Driver      Driver             Driver      Driver
              /           |                   |          \
             /           auto <------------> slv          \
            slv <--------------------------------------> auto



              Figure 1-2.  X.25-Slave Configuration


     In the  above figure, the  way the login  subchannel and the |
autocall subchannel  are set up (for both  systems) is arbitrary. |
The X.25 configuration is equally valid if System A has two slave |
subchannels and  System B has  two autocall subchannels,  or vice
versa.  What  is important is that each  connection is configured
as a slave  subchannel on one end, and an  autocall subchannel on
the other.


IMFT-DIAL CONNECTION MODE                                         |

This  connection mode  is useful   when special  features in  the |
communications protocol cannot be  used to establish a connection |
on the remote system.  This occurs  when using more than one X.25 |
public network between the two Multics sites.                     |


A call-request  packet is used  on X.25 networks  to connect from |
one system  to another.  The X.25  protocol allows the use  of an |
additional-info field  in a call-request packet  to specify which |
slave subchannel to use for a connection.                         |


     iods="tty_ e.h016.* -ds * 377710052602:phxfti"               |

In  the  above  example,  the  "phxfti"  would  be  placed in the |
additional-info  field.   This  field,  however,  is  used by the |
originating network  to specify the  host identifier on  the next |
network when  the connection has  to cross a  gateway.  The slave |
subchannel information is thus lost  and the connection cannot be |
made.   The   IMFT-Dial  connection  mode  utilizes   the  "dial" |
pre-access command to connect to an existing process.  Therefore, |
the originating dialout end of the  IMFT needs only to connect to |


                               1-5             08/88     CY73-01A


a login  channel on the  other system.  This  doesn't require any |
special support  from the communications protocol  (being used on |
the connection) to  establish a link between the  IMFT drivers on |
each system.                                                      |


Since this  connection mode is independent  of the communications |
protocol, asynchronous  dialout/login channels may be  used.  The |
hardware  used (modems  and autocall   devices) must  be able  to |
support  8-bit  data  transfers.   However,  use  of asynchronous |
channels is  not encouraged as there  is no means to  ensure data |
integrity  of  the  transferred  information.   The X.25 protocol |
packetizes the data  and uses checksums to check if  the data was |
sent  correctly.   If  the  check   fails,  then  the  packet  is |
retransmitted.


IMFT-Dial Drivers                                                 |

There are two ends to any IMFT connection, an input driver (which |
receives  data) and  an output  driver (which  sends data).   The |
method of  establishing the connection and the  direction of data |
transport between the  two ends are not related.  One  end of the |
connection  is an  in-dial driver  which receives  calls from the |
out-dial driver at the other  end.  Therefore, an input driver is |
not necessarily  an in-dial driver,  and an output  driver is not |
necessarily an out-dial driver; the  call direction does not have |
to correspond to the direction of the data flow.                  |


This connection mode permits any login channel on the in-dial end |
to be available for connection.  This significantly increases the |
number  of available  channels, without  dedicating any channels. |
Since  the connection  is not  limited to  a specific  channel, a |
number of fall-back paths may  be used in cases of communications |
link problems.


The in-dial IMFT process establishes a dial server with the local |
Multics Answering  Service.  This permits an  incoming connection |
to be made through any login channel.  The in-dial driver sets up |
its  dial  service  specifically  for  the  use  of  the expected |
incoming service, supplying a  unique dial identifier.  This dial |
identifier  must be  used by   the out-dial  driver on  the other |
system.


The out-dial driver  does a dialout, as an  X.25-Slave IMFT would |
do, though it does not  specify which particular slave subchannel |
is  to receive  the connection.   After the  connection has  been |
made, it performs a protocol handshake with the Multics system to |
establish  the IMFT transport  service, starting with  the "dial" |



                               1-6             08/88     CY73-01A


preaccess command to establish its  connection to the remote IMFT |
in-dial driver.


IMFT-Dial Connection Mode Protocol                                |

The  connection  is  established  through  an  exchange  of data. |
Checks are done throughout the  handshake to ensure that the line |
is validly  connected and to permit  unsupervised operation.  The |
dialog  on the  line looks   like the  following dialog  with the |
remote in-dial system supplying all the data except that which is |
prefixed  with the  "!"  character.   The "!"   character is  not |
actually sent.


  Unattended Service                                              |
  Multics MR12.2: Honeywell Bull, Phx AZ (Channel c.h000.002)     |
  Load = 30.5 out of 270.0 units: users = 46, DATE/TIME           |
! dial DIAL_ID IMFT.Daemon                                        |
  ASCII terminal "3106" dialed to DIAL_ID (IMFT.Proj) at DATE/TIME|
!  IMFT TRANSPORT ESTABLISHED                                     |
  <<Start of normal IMFT system identifier and AIM validation.>>  |


If  the expected  response is   not received,  the connection  is |
released  and the driver  will go to  sleep for a  specified time |
before retrying the connection.  A  message is entered in the log |
indicating the connection failure.   The driver will keep trying, |
but subsequent connection failures are not logged.                |

Some  connections established  through multiple  networks cause a |
blank line  to be transmitted  after the greeting  banner.  These |
will be ignored.   Once the channel is connected  to the process, |
the process sets  the modes to rawo (among others)  and the blank |
lines no longer are displayed.


IMFT-Dial Idle Disconnect                                         |

The  X.25-Slave IMFT  connection requires  a dedicated  full-time |
connection, entailing full-time connect  time charges even if the |
line  is idle.   Alternatively the  system may  initiate the IMFT |
X.25-Slave service on  a schedule, and drop the  service when the |
queues  have  emptied;  this  requires  overt  system or operator |
action.


The  IMFT-Dial service permits  automatic detachment of  the line |
when there is no traffic, and  reattachment to and restart of the |
service when  transfer requests are  seen in the  queue.  Network |
services will  be needed and  charged only when  data is actually |
transferred without any additional system or operator action.



                               1-7             08/88     CY73-01A


Normal  idle disconnection is  indicated by log  messages stating |
that the out-dial driver has  logged out from the in-dial driver, |
and  that the  in-dial driver  is waiting  for reconnection.   An |
abnormal disconnection (i.e.  a line  drop) is still signalled as |
a hangup.


Reconnection  goes   through  the  full  out-dial   protocol  and |
validation, ensuring that any  subsequent connection has the same |
security as the initial connection.


Connect and disconnect operations are done without reinitializing |
the transmitting  IMFT process (whether it is  the out-dialing or |
the in-dialing  end), in order to retain  daemon parameters (such |
as pause_time and defer_time) and  the current state of deferrals |
in the IMFT sending queue.


IMFT-Dial Connection Mode Using an X.25 Multiplexed Channel       |

     When  this  IMFT  configuration  uses  an  X.25  multiplexed |
channel, it requires the following subchannels:                   |

     ox    1 login subchannel                                      |

     ox    1 autocall subchannel                                   |


     An X.25 connection is bidirectional;  it is configured as an |
autocall  subchannel on  one end  (at System  A), and  as a login |
subchannel on the other end  (at System B).  Both subchannels can |
receive or send data.  The  autocall or dialout subchannel on one |
system  initiates  the  connection  with  the corresponding login |
subchannel on the other system.




















                               1-8             08/88     CY73-01A


     The  following  figure  shows  the  X.25  IMFT configuration |
between  System   A  and  System  B.   "lgn"   stands  for  login |
subchannel, and "auto" stands for autocall subchannel.            |




                System A                        System B          |
                /      \                       /      \           |
            Input       Output             Input       Output     |
            Driver      Driver             Driver      Driver     |
              /           |                   |          \        |
             /           auto <------------> lgn          \       |
            lgn <--------------------------------------> auto     |



                 Figure 1-3.  X.25 Configuration                  |


     In the  above figure, the  way the login  subchannel and the |
autocall subchannel  are set up (for both  systems) is arbitrary. |
The X.25 configuration is equally valid if System A has two login
subchannels and  System B has  two autocall subchannels,  or vice
versa.  What  is important is that each  connection is configured
as a login  subchannel on one end, and an  autocall subchannel on
the other.


IMFT-Dial Connection Mode Using Asynchronous Channels

     When this IMFT configuration  uses asynchronous channels, it
requires the following channels:

     ox    1 login channel

     ox    1 autocall channel


     An   asynchronous  connection    is  bidirectional;   it  is
configured as an  autocall channel on one end (at  System A), and
as a login channel on the other end (at System B).  Both channels
can receive or send data.  The autocall or dialout channel on one
system  initiates  the  connection  with  the corresponding login
channel on the other system.










                               1-9             08/88     CY73-01A


     The  following  figure  shows  the  X.25  IMFT configuration
between System A  and System B.  "lgn" stands  for login channel,
and "auto" stands for autocall channel.




                System A                        System B
                /      \                       /      \
            Input       Output             Input       Output
            Driver      Driver             Driver      Driver
              /           |                   |          \
             /           auto <------------> lgn          \
            lgn <--------------------------------------> auto



             Figure 1-4.  Asynchronous Configuration


     In the  above figure, the  way the login  subchannel and the |
autocall subchannel  are set up (for both  systems) is arbitrary. |
This  configuration is equally  valid if System  A has two  login
channels and System  B has two autocall channels,  or vice versa.
What  is important  is that  each connection  is configured  as a
login channel on one end, and an autocall channel on the other.





























                               1-10            08/88     CY73-01A









                            SECTION 2


               ADMINISTRATION OF AN IMFT CONNECTION




     To configure an IMFT connection, you must:

     1.   Define the HASP multiplexed channel, asynchronous login |
          and dialout channels, or X.25 multiplexed channel.      |

     2.   Define  the I/O  daemons, which  includes the following
          steps:

          ox    Determine the  Person_id and Project_id  names, as
               well  as the  local  system  name and  the foreign
               system name(s)

          ox    Select a dial_identifier, if applicable            |

          ox    Decide  on   access  categories  and   levels,  if
               applicable

          ox    Define  the devices  and the  Request_types in the
               I/O daemon tables

          ox    Register the I/O daemon in the Project Master File
               (PMF) and in the Person Name Table (PNT)

     3.   Initialize IMFT for operation


     This section  contains the information necessary  to perform
all of the above procedures.


_D_E_F_I_N_I_N_G _A _M_U_L_T_I_P_L_E_X_E_D _C_H_A_N_N_E_L

     You must  define the channels  that IMFT will  use, like all |
communications channels, in the  Channel Master File (CMF).  IMFT
requires  a definition  for  the  communications channel  on each
system.




                               2-1             08/88     CY73-01A


     If you  are setting up a  HASP channel, configure it  on one
system as the  "host"; on the other system  configure the channel
as  the "workstation".   Either system   can be  the host  or the
workstation.  The  terms host and  workstation do not  have their
usual  meaning here.   Ordinarily a  system configured  as a HASP
workstation performs remote-job-entry (RJE)  tasks; it is usually
an RJE terminal  with an operator's console and one  or more card
readers,  line  printers,  and   card  punches.   Job  decks  are
transmitted to  the HASP host  system for execution,  and sent to
the   workstation  for   printing/punching  or   online  perusal.
However, in  an IMFT configuration, each system  performs as BOTH
host and workstation; each system  can both send and receive file
transfers.  Therefore, although one system is called the host and
the other the workstation, the  two systems do not differ greatly
in their IMFT capabilities.


     If you are  setting up an X.25 channel, configure  it on one
system as the "DCE", and on  the other system configure it as the
"DTE".  Either system can be the  DCE or the DTE.  DCE stands for
Data  Communications  Equipment,  and  DTE  means  Data  Terminal
Equipment.  For  an IMFT configuration,  both the DTE  system and
the  DCE  system  have  the  ability  to  send  and  receive file
transfers.


     For both HASP and  X.25, specify the channel's configuration
parameters  by terminal types  defined in each  system's Terminal
Type Files (TTF).


_T_e_r_m_i_n_a_l _T_y_p_e _F_i_l_e

     The  Terminal Type  File  (TTF)  defines all  terminal types
known to  the system.  It  is not the  intent of this  section to
define all aspects of the TTF, but only the information necessary
to define the IMFT connection.  For a complete description of the
TTF, refer to the Programmers' Reference manual (AG91).           |


     The pathname of the TTF is usually:

     >udd>SysAdmin>admin>TTF

Once you have made the appropriate entries to the TTF, compile it
via  the  cv_ttf  command  (see  the  Commands  manual, AG92) and |
install it via the install command (see the AMOC manual, GB64).   |








                               2-2             08/88     CY73-01A


TTF ENTRIES FOR AN IMFT HASP CHANNEL

     IMFT  requires  the  following  TTF  entries  for  the  HASP
multiplexed channels:

terminal_type:  <type_name>;
            The <terminal_type> describes  the characteristics of
            the  REMOTE system.    For IMFT,  the <terminal_type>
            name  is  variable;  one  of  the  following names is
            recommended:

            ox    IMFT_HASP_HOST
                 if the system is the WORKSTATION

            ox    IMFT_HASP_WORKSTATION
                 if the system is the HOST

            additional_info:  <string>;
            The    additional_info   statement    specifies   the
            additional information needed to  run the terminal on
            an  IMFT connection.   The additional_info  arguments
            required for IMFT are:  type= host (type= workstation
            for a  system configured as the  host), and rts_mode=
            no.   If  you  are   running  IMFT  without  operator
            intervention  (see mode=  auto in  "Device Definition
            for  IMFT"),  it  is  recommended  that  you  specify
            connect_timeout= none.  For a detailed description of
            these   arguments   see   Appendix   A   of  the  MAM |
            Communications manual (CC75).


Example 1

     terminal_type: IMFT_HASP_HOST;
      additional_info: "type= host, connect_timeout= none,
                        rts_mode= no"

In  the above example,  a terminal type  is defined for  a system
configured as the workstation.


Example 2

     terminal_type: IMFT_HASP_WORKSTATION;
      additional_info: "type= workstation, connect_timeout= none,
                        rts_mode= no"

     In  the above  example, a   terminal type  is defined  for a
     system configured as the host.






                               2-3             08/88     CY73-01A


TTF ENTRIES FOR AN IMFT X.25 CHANNEL

     IMFT  requires  the  following  TTF  entries  for  the  X.25
multiplexed channels:

terminal_type:  <type_name>;
            The <terminal_type> describes  the characteristics of
            the LOCAL system; in  this case, it describes whether
            the  system functions  as the   DTE or  the DCE.   In
            setting up an IMFT  configuration on X.25 between two
            Multics  systems, it  doesn't matter  which system is
            configured as the DTE and  which is configured as the
            DCE.  The IMFT <terminal_type>  name is variable; one
            of the following names is recommended:

            ox    IMFT_X25_DCE
                 if the system is the DCE

            ox    IMFT_X25_DTE
                 if the system is the DTE

additional_info:  <string>;
            The    additional_info   statement    specifies   the
            additional information needed to  run the terminal on
            an   IMFT  connection.    The  only   additional_info
            arguments required for an  IMFT X.25 multiplexer are:
            type= and  n_lc=.  The argument n_lc=  has no default
            value.  This  parameter specifies the number  of X.25
            logical channels to be defined.  It can be any number
            between 1  and 4095.  The type= argument  has a value
            of  DTE  or  DCE;  it  specifies  whether the Multics
            system   behaves  as  the   DTE  or  the   DCE.   The
            terminal_type definitions for both multiplexers (site
            A and site B) must be such  that one is a DTE and the
            other is a  DCE; as stated above, it  does not matter
            which site  is configured as the DCE,  and which site
            is configured as the DTE.   (For example, if site A's
            terminal type  is "type=DTE", site B's  terminal type
            must  include  "type=DCE",  or  vice  versa.)   For a
            detailed  description  of   the  optional  parameters
            included  in the  additional_info statement,  see the |
            MAM Communications manual (CC75).


Example 1

     terminal_type: IMFT_X25_DCE;
      additional_info: "n_lc=32 type=DCE"

In  the above example,  a terminal type  is defined for  a system
configured as a DCE.




                               2-4             08/88     CY73-01A


Example 2

     terminal_type: IMFT_X25_DTE
      additional_info: "n_lc=20 type=DTE"

In  the above example,  a terminal type  is defined for  a system
configured as a DTE.


_C_h_a_n_n_e_l _M_a_s_t_e_r _F_i_l_e

     You must define the channels that  IMFT will be using in the |
CMF.  The  Channel Master File (CMF) contains  the description of |
all  Front-end  Network   Processors  (FNPs),  multiplexers,  and
terminal channels in  a system.  It is not the  intention of this
section to  detail the CMF  definition in its  entirety, but only
the  information necessary  to define  the IMFT  connection.  You
should   be  able  to   edit  the  IMFT   specific  configuration
information   into   an   existing   CMF.    Refer   to  the  MAM
Communications  manual  (CC75)  for  a  full  description  of CMF |
creation; Appendix A describes CMF entries for a HASP multiplexed |
channel and for an X.25 multiplexed channel.


     If  you  are  using  a  hardwired  connection, the channel's
definition  in the CMF  on both systems  should specify that  the
multiplexer is "active".  Additionally,  for both systems specify
"connect_timeout=  none" as  one of  the channel's  configuration
parameters.   By including  these specifications  for a hardwired
connection, the channel is always ready whenever both systems and
both Front-end  Network Processors (FNP) to which  the channel is
connected are running.


     The pathname of the CMF is usually:

     >udd>SysAdmin>admin>CMF

Once you have made the required entries to the CMF file:

     1.   Convert the CMF file to the required Channel Definition
          Table  (CDT)  via  the  cv_cmf  command  (see  the  MAM
          Communications manual, CC75).                           |

     2.   Install  the  converted  version  of  the  CMF  via the
          install command (see the AMOC manual, GB64).            |









                               2-5             08/88     CY73-01A


CMF ENTRIES FOR A HASP MULTIPLEXED CHANNEL

The HASP channel consists of:

     ox    One operator terminal channel

     ox    At least two card-reader subchannels

     ox    At least two card-punch subchannels

and the other required CMF entries for the HASP channel.


     IMFT  requires  the  following  CMF  entries  for  the  HASP
multiplexed channel:

name: <channel_name>;
            Specifies a unique channel name for the HASP channel.
            The channel name  must be of the form  x.hNNN where x
            is a  unique letter from a through  h identifying the
            Front-end  Network Processor  (FNP); hN  is the  High
            Speed Line Adaptor (HSLA) identifier (h0, h1, or h2);
            NN  is   a  2-digit  channel  number   identifying  a
            subchannel   of   the   specified   HSLA   (see   the
            Programmer's Reference manual, AG91).                 |

service: <service_type>;
            IMFT requires the  <service_type> to be "multiplexer"
            for the HASP multiplexed channel.

multiplexer_type:  <type>, <active or inactive>;
            The <type> must be  hasp; for a hardwired connection,
            it is recommended that "active" also be specified (or
            omitted  since  it  is  the  default);  for a dial-up
            connection, active or inactive can be used.

baud: <baud_rate>;
            Specifies  the   baud  rate  of  the   channel.   The
            <baud_rate>  must  be  compatible  with  the FNP line
            adapter type and be chosen from the following list:

                 2400    19200
                 4800    40800
                 7200    50000
                 9600    72000

line_type: <line_type>;
            For IMFT, the <line_type> must be "BSC".







                               2-6             08/88     CY73-01A


terminal_type:  <terminal_type>;
            For IMFT, the <terminal_type> is variable; one of the
            following names is recommended:

            ox    IMFT_HASP_HOST
                 if  this   system  is  being  configured   as  a
                 workstation.

            ox    IMFT_HASP_WORKSTATION
                 if this system is being configured as a host.


Example

     name: b.h203;
        service: multiplexer;
        multiplexer_type: hasp;
        baud: 4800;
        line_type: BSC;
        terminal_type: IMFT_HASP_HOST;                            |


     In  the above  example, a  CMF entry  is created  for a HASP
multiplexed   channel.    The   system   is   configured  as  the
workstation.  The <terminal_type> tells your local system how the
REMOTE system is defined.


CMF Entries for a HASP Operator Terminal

     IMFT uses the HASP  subchannels:  operator, card-reader, and
card-punch.   To  define  the  operator  subchannel  of  the HASP
multiplexed channel, the following statements are required:

name: <channel_name>;
            Although  a pair  of names  can be  specified in this
            name  statement, the  operator channel  requires only
            the  name of  the  channel  number specified  for the
            unique HASP channel name  referred to in "CMF ENTRIES
            FOR HASP MULTIPLEXED CHANNEL" and the suffix:  .opr.

service: <service_type>;
            <service_type>   must   be   specified   as  "slave",
            designating that the service is used only for special
            channels  attached by the  I/O daemons for  bulk data
            input/output or other special subsystems.

line_type: <line_type>;
            For IMFT, the <line_type> must be "BSC".






                               2-7             08/88     CY73-01A


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.

check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |

                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.

            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |










                               2-8             08/88     CY73-01A


     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example

     name: b.h203.opr;
         service: slave;                                          |
         line_type: BSC;                                          |


     In  the above example,  a CMF entry  is created for  a local
system designated as the workstation.


CMF Entries for Card-Reader Subchannels

     IMFT  requires  that  you  define  at  least two card-reader
subchannels in the CMF.   The card-reader subchannels require the
following CMF entries:

name: <channel_name 1> - <channel_name 2>;
            For   the  card-reader    subchannels  of   the  HASP
            multiplexed channel specify x.hNNN.rdrn - x.hNNN.rdrn
            where  x.hNNN  is  the  unique  HASP  channel  number
            specified above.  Up to  eight reader subchannels can
            be  defined.   IMFT   requires  any  two  card-reader
            subchannels.

service: <service_type>;
            The  <service_type>  must  be  specified  as "slave",
            designating that the service is used only for special
            channels  attached by the  I/O daemons for  bulk data
            input/output or other special subsystems.

line_type: <line_type>;
            For IMFT, the <line_type> must be "BSC".


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.







                               2-9             08/88     CY73-01A


check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |

                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.

            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |




















                               2-10            08/88     CY73-01A


     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example

     name: b.h203.rdr1 - b.h203.rdr8;
         service: slave;                                          |
         line_type: BSC;                                          |
         check_acs: slave;                                        |


     In  the  above  example,  eight  card-reader subchannels are
defined.  IMFT requires two reader subchannels.

Note  that this  CMF entry  contains the  optional CMF statement, |
"check_acs:".  For a description  of optional CMF statements, see |
the MAM communications manual (CC75).


CMF Entries for Card-Punch Subchannels

     IMFT  requires  that  you  define  at  least  two card-punch
subchannels  of the  HASP channel   in the  CMF.  The  card-punch
subchannels require the following CMF entries:

name: <channel_name 1> - <channel_name 2>;
            For the card-punch subchannels, specify x.hNNN.punn -
            x.hNNN.punn where  x.hNNN is the unique  HASP channel
            number  specified above.   The total  number of  card
            punches and line printers configured cannot exceed 8.
            IMFT requires any two card-punch subchannels.


service: <service_type>;
            The  <service_type>  must  be  specified  as "slave",
            designating that the service is used only for special
            channels  attached by the  I/O daemons for  bulk data
            input/output or other special subsystems.

line_type: <line_type>;
            For IMFT, the <line_type> must be "BSC".


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.


                               2-11            08/88     CY73-01A


check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |

                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.

            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |

     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example

     name: b.h203.pun1 - b.h203.pun8;
         service: slave;                                          |
         line_type: BSC;                                          |










                               2-12            08/88     CY73-01A


     In  the  above  example,  eight  card-punch  subchannels are
defined.  IMFT requires two card-punch subchannels.


Channel Master File Examples for IMFT HASP Configuration


Example 1

     Example  1 is  a sample  CMF  file  entry for  an IMFT  HASP
connection on a local system configured as the workstation.

     name: b.h203;
       service: multiplexer;                                      |
       multiplexer_type: hasp;                                    |
       baud: 4800;                                                |
       line_type: BSC;                                            |
       terminal_type: IMFT_HASP_HOST;                             |
         name: b.h203.opr;                                        |
           service: slave;                                        |
           line_type: BSC;                                        |
         name: b.h203.rdr1-b.h203.rdr8;                           |
           service: slave;                                        |
           line_type: BSC;                                        |
         name: b.h203.pun1-b.h203.pun8;                           |
           service: slave;                                        |
           line_type: BSC;                                        |


Example 2

     The  following example  is a   sample CMF  file for  an IMFT
connection on a remote system configured as the host:

     name: c.h208;
       service: multiplexer;                                      |
       multiplexer_type: hasp;                                    |
       baud: 9600;                                                |
       line_type: BSC;                                            |
       terminal_type: IMFT_HASP_WORKSTATION;                      |
         name: c.h208.opr;                                        |
           service: slave;                                        |
           line_type: BSC;                                        |
         name: c.h208.rdr1-c.h208.rdr8;                           |
           service: slave;                                        |
           line_type: BSC;                                        |
         name: c.h208.pun1-c.h208.pun8;                           |
           service: slave;                                        |
           line_type: BSC;                                        |






                               2-13            08/88     CY73-01A


CMF ENTRIES FOR AN X.25 MULTIPLEXED CHANNEL

     You must define  an X.25 multiplexed channel in  the CMF for |
either  X.25-Slave  or  IMFT-Dial  connection  modes.   The  X.25 |
channel uses the following subchannels:

     ox    At least one slave (inward) subchannel
          for the X.25-Slave connection mode                      |

     ox    At least one login (inward) subchannel                  |
          for the IMFT-Dial connection mode                       |

     ox    At least one autocall (outward) subchannel

and other required CMF entries for the X.25 channel.


     Although   the  X.25  channel   must  be  configured   as  a
login/slave subchannel  on one end and as  an autocall subchannel |
on the  other end, this  does not mean  that two systems  with an
IMFT X.25 connection must each  have a login/slave subchannel and |
an autocall subchannel.   It is equally feasible for  System A to
have  two  autocall  subchannels,  and   System  B  to  have  two
login/slave subchannels, or vice versa.  Typically, there will be |
several  login channels  configured and  none need  to be  set up |
especially for the IMFT-Dial connection mode.                     |


     The following  CMF entries for the  X.25 multiplexed channel
must be defined:

name: <channel_name>;
            Specifies a unique channel name for the X.25 channel.
            The channel name must be  of the form x.hNNN, where x
            is a  unique letter from a through  h identifying the
            Front-End  Network Processor  (FNP); hN  is the  High
            Speed Line Adaptor (HLSA) identifier (h0, h1, or h2);
            and  NN is  a  2-digit  channel number  identifying a
            subchannel   of   the   specified   HSLA   (see   the
            Programmer's Reference manual, AG91).                 |

service: <service_type>;
            IMFT requires the  <service_type> to be "multiplexer"
            for the X.25 multiplexed channel.

multiplexer_type:  <type>, <active or inactive>;
            The <type> must be  X25.  For a hardwired connection,
            it is recommended that "active" also be specified (or
            omitted  if  it  is  the  default).   For  a  dial-up
            connection, active or inactive can be used.





                               2-14            08/88     CY73-01A


baud: <baud_rate>;
            Specifies  the   baud  rate  of  the   channel.   The
            <baud_rate>  must  be  compatible  with  the FNP line
            adapter type and be chosen from the following list:

                 2400     19200
                 4800     40800
                 7200     50000
                 9600     72000

line_type: <line_type>;
            For IMFT, the <line_type> must be "X25LAP".

terminal_type:  <terminal_type>;
            The  <terminal_type>  describes  whether  the  system
            functions as  the DTE or  the DCE.  In  setting up an
            IMFT  configuration  on   X.25  between  two  Multics
            systems, it doesn't matter which system is configured
            as the DTE  and which is configured as  the DCE.  The
            IMFT  <terminal_type> name  is variable;  one of  the
            following names is recommended:

            ox    IMFT_X25_DCE
                 if this system is being configured as a DCE.

            ox    IMFT_X25_DTE
                 if this system is being configured as a DTE.


Example

     In  the example  below, a  CMF entry  is shown  for an  X.25
multiplexed channel.  The system is configured as the DCE.

     name: g.h026;
       service: multiplexer;
       multiplexer_type: x25;
       baud: 9600;
       line_type: X25LAP;
       terminal_type: IMFT_X25_DCE;

There  are  other  statements  that  may  be  included in an X.25
channel  description  in  the  CMF.   See  the MAM Communications |
manual   (CC75)  for  a   full  description  of   these  optional |
statements.


CMF Entries for X.25 Login Subchannels                            |

     A login subchannel is one which incoming calls are connected |
to if no  specific subchannel is specified.  To  define the login |
subchannel  of  the  X.25   multiplexed  channel,  the  following |
statements are required:


                               2-15            08/88     CY73-01A


name: <channel_name>;                                             |
            For the  login subchannel, specify  x.hNNN.nnn, where |
            x.hNNN is the unique X.25 channel name referred to in |
            "CMF  Entries for  an X.25  Multiplexed Channel".   A |
            pair  of   names  can  be  specified   in  this  name |
            statement.

service: <service_type>;                                          |
            The <service_type> must  be "login", designating that |
            the subchannel can be used for normal logins.         |


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.

check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.
                                                                  |
                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |
                                                                  |
                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment
                                                                  |
            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.
                                                                  |
            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.




                               2-16            08/88     CY73-01A


               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.
                                                                  |
                    all - Use all of the above keywords.          |
                                                                  |
     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example

     name: g.h026.001 - g.h026.010;
       service: login;
       comment: "X.25 login channels";


     In  the above  example, ten  login subchannels  are defined.
The  IMFT-Dial  connection  mode   will  require  as  many  login
subchannels  as there  are in-dial  drivers.  Note  that this CMF
entry  contains   the  optional  statement  "comment:".    For  a
description   of   optional   CMF   statements,   see   the   MAM
Communications manual (CC75).


CMF Entries for X.25 Slave Subchannels

     A slave subchannel is one which is attached to the system by
another process; that process then manages the slave channel.  To
define the slave subchannel of  the X.25 multiplexed channel, the
following statements are required:

name: <channel_name>;
            For the slave subchannel, specify x.hNNN.slvnn, where
            x.hNNN is the unique X.25 channel name referred to in
            "CMF  Entries for  an X.25  Multiplexed Channel".   A
            pair  of   names  can  be  specified   in  this  name
            statement.

service: <service_type>;
            The <service_type> must  be "slave", designating that
            the service is only  for special channels attached by
            the I/O  daemons for bulk data  input/output or other
            special subsystems.


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |


                               2-17            08/88     CY73-01A


Reference  manual  (AG91)  for  additional  information on access |
control segments.

check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |

                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.

            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |

     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example

     name: g.h026.slv01 - g.h026.slv02;
       service: slave;                                            |
       comment: "X.25 slave channels for IMFT input driver";      |


     In  the above  example, two  slave subchannels  are defined.
IMFT requires a minimum of  one slave subchannel.  Note that this
CMF  entry contains  the  optional  statement "comment:".   For a


                               2-18            08/88     CY73-01A


description   of   optional   CMF   statements,   see   the   MAM |
Communications manual (CC75).


CMF Entries for X.25 Autocall Subchannels

     An  autocall or  dialout subchannel  is a  process that  can
initiate  an outbound  connection with  another process  (i.e., a
slave terminal).   To define the autocall subchannel  of the X.25
multiplexed channel, the following statements are required:

name: <channel_name>;
            For the  autocall subchannel, specify  x.hNNN.autnn -
            x.hNNN.autnn, where x.hNNN is the unique X.25 channel
            name  referred  to  in   "CMF  Entries  for  an  X.25
            Multiplexed Channel".

service: <service_type>;
            The <service_type> must be "autocall" for IMFT.


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.

check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |

                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.


                               2-19            08/88     CY73-01A


            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |

     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example

     name: g.h026.aut01 - g.h026.aut04;
       service: autocall;                                         |


     In the above example, four autocall subchannels are defined.
IMFT requires a minimum of one autocall subchannel.


Channel Master File Example for IMFT X.25 Configuration

     Example  1 is  a sample  CMF  file  entry for  an IMFT  X.25
connection on a local system configured as a DCE.


Example 1

     name: g.h026;
       service: multiplexer;                                      |
       multiplexer_type: x25;                                     |
       baud: 9600;                                                |
       line_type: X25LAP;                                         |
       terminal_type: IMFT_X25_DCE;                               |
         name: g.h026.slv01 - g.h026.slv04;                       |
           service: slave;                                        |
         name: g.h026.aut05 - g.h026.aut11;                       |
           service: autocall;                                     |










                               2-20            08/88     CY73-01A


Example 2

     The following example is a sample  CMF file for an IMFT X.25
connection on a remote system configured as a DTE:

     name: b.h000;                                                |
       service: multiplexer;                                      |
       multiplexer_type: x25;                                     |
       baud: 9600;                                                |
       line_type: X25LAP;                                         |
       terminal_type: IMFT_X25_DTE;                               |
         name: b.h000.slv01 - b.h000.slv04;                       |
           service: slave;                                        |
         name: b.h000.aut05 - b.h000.aut11;                       |
           service: autocall;                                     |


CMF ENTRIES FOR ASYNCHRONOUS LOGIN CHANNELS                       |

     A login channel is one which  is used for normal logins.  To |
define an asynchronous  login channel, the  following  statements |
are required:

name: <channel_name>;                                             |
            For the  login channel, specify x.hNNN,  where x.hNNN |
            is the unique  channel name.  A pair of  names can be |
            specified in this name statement.

service: <service_type>;                                          |
            The <service_type> must  be "login", designating that |
            the subchannel can be used for normal logins.         |

baud: <baud_rate>;                                                |
            Specifies  the   baud  rate  of  the   channel.   The |
            <baud_rate>  must  be  compatible  with  the FNP line |
            adapter type and be chosen from the following list:

                  110    1200     7200                            |
                  150    1800     9600                            |
                  300    2400    19200                            |
                  600    4800                                     |


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.



                               2-21            08/88     CY73-01A


check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |

                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.

            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |

     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example                                                           |

     name: d.h016 - d.h023;                                       |
       baud: 2400;                                                |
       service: login;                                            |
       comment: "Login channel on Courier 2400e X-0110 rotary.";  |


     In the above example, eight login channels are defined.  The |
IMFT-Dial connection mode will require  as many login channels as |
there are in-dial drivers.  Note that this CMF entry contains the |
optional statement "comment:".  For a description of optional CMF |
statements, see the MAM Communications manual (CC75).             |


                               2-22            08/88     CY73-01A


CMF ENTRIES FOR ASYNCHRONOUS AUTOCALL CHANNELS                    |

     An autocall channel is one which  is used for placing a call |
to another modem, in this case, an asynchronous modem.  To define |
an  asynchronous autocall  channel, the  following statements are |
required:

name: <channel_name>;                                             |
            For  the  autocall  channel,  specify  x.hNNN,  where |
            x.hNNN is  the unique channel name.  A  pair of names |
            can be specified in this name statement.              |

service: <service_type>;                                          |
            The  <service_type> must  be "autocall",  designating |
            that  the channel  can be  used for  placing calls to |
            other modems.

baud: <baud_rate>;                                                |
            Specifies  the   baud  rate  of  the   channel.   The |
            <baud_rate>  must  be  compatible  with  the FNP line |
            adapter type and be chosen from the following list:

                  110    1200     7200                            |
                  150    1800     9600                            |
                  300    2400    19200                            |
                  600    4800                                     |


     Optionally, the check_acs statement can be included.  If not |
included, no access  checking is done and any  process may access |
the channel in any manner appropriate to the configuration of the |
channel.  If  the statement is  included, then an  access control |
segment must be  created.  (This is covered in  a later section.) |
See   the  MAM   Communications  manual   (CC75)  for  additional |
information about the check_acs  statement.  See the Programmer's |
Reference  manual  (AG91)  for  additional  information on access |
control segments.

check_acs: <keyword(s)>                                           |
            Each  keyword (described   below) specifies  that the |
            channel         access        control         segment |
            (>sc1>rcp>CHANNEL_NAME.acs)  is  to  be  checked  for |
            appropriate  access when  the specified  operation is |
            performed.  One or more keywords can be specified; if |
            multiple  keywords   are  specified,  each   must  be |
            separated  by a comma.   Use of this  keyword assumes |
            the creation  of an access control  segment (ACS) for |
            the channel.

                  login - The user must have rw access to the ACS |
                          segment to log in over this channel.    |




                               2-23            08/88     CY73-01A


                  slave - A user  entering the "dial"  or "slave" |
                          preaccess  command   must  specify  the |
                          -user control argument and must have rw |
                          access to the ACS segment

            priv_attach - The user must have rw access to the ACS |
                          segment to attach  this channel through |
                          the dial facility.

            dial_server - A  user  accepting  dial-in connections |
                          (via    dial_manager_$allow_dials_   or |
                          dial_manager_$registered_server_)  must |
                          have  rw access  on the  ACS segment of |
                          the connecting channel  for the channel |
                          to be connected to the user's process.

               dial_out - The user must have rw access to the ACS |
                          segment to use the channel for dial_out |
                          requests.

                    all - Use all of the above keywords.          |

     Individual  keywords can  be preceded  by ^  to disable  the |
particular keyword.


Example                                                           |

     name: b.h016;                                                |
       baud: 2400;                                                |
       service: autocall;                                         |
       generic_destination: acu.8bit;                             |
       comment: "Autocall channel on X-7654.";                    |


     In the above example, one  autocall channel is defined.  The |
IMFT-Dial connection mode will  require as many autocall channels |
as there are out-dial drivers.  Note that this CMF entry contains |
the optional statement "generic_destination:".  For a description |
of  optional CMF  statements, see  the MAM  Communications manual |
(CC75).


_D_E_F_I_N_I_N_G _T_H_E _I_/_O _D_A_E_M_O_N _F_O_R _I_M_F_T

     To define the daemon for IMFT:

     1.   Add  the definitions of  the input and  output drivers,
          and  the definition(s)  of the  Request_type(s) used by
          the user commands to the I/O daemon tables.

     2.   Register  the I/O  daemon  in  the Project  Master File
          (PMF) and in the Person Name Table (PNT).


                               2-24            08/88     CY73-01A


     Prior to  making the entries in these  special files, review
the information required in the sections below, and decide on the
Person_id  and Project_id names  you want to  assign to IMFT,  as
well as the names you want to  assign to the local system and the
foreign system.  If you are  using the Access Isolation Mechanism
(AIM), decide upon  the access levels and categories  you plan to
assign.


_C_h_o_o_s_i_n_g _N_a_m_e_s _f_o_r _I_M_F_T _V_a_r_i_a_b_l_e_s

     Prior to adding the required IMFT entries to the appropriate
system files and  tables, choose the names you want  to assign to
variable entries such as:

     ox    Person_id

     ox    Project_id

     ox    local_system name

     ox    foreign_system name

     ox    dial identifier if using IMFT-Dial connection mode


     For the Person_id it is recommended that you use IMFT.


     Every project on the system  has a Project_id in the Project
Master  File (PMF).   A separate  Project_id can  be created  for
IMFT, or you can add keywords  and their values in the PMF placed
under an  existing Project_id.  If IMFT  is to be available  on a
system  wide basis,  add the   required PMF  entries to  a system
overhead project such as "Daemon"  or "SysDaemon".  If IMFT is to
be available  for a small group  of users in a  specific project,
add the required entries to that project entry in the PMF.


     When choosing a local  system and foreign system identifier,
the local_system  keyword on one system  must be the same  as the
foreign_system   keyword   on   the   other   system,   and   the
foreign_system  keyword on  one system  must be  the same  as the
local_system  keyword on  the other  system.  The  foreign_system
name  must  be  used  to  generate  the  Request_type <name>s, as
described later in this section.


     The  dial  identifier  must  be  set  up  if  the  IMFT-Dial |
connection mode  is selected for  this IMFT connection.   See the |
MAM  System  manual  (AK50)  for  a  description  of setting up a |
registered dial identifier.  This dial identifier must be used in |



                               2-25            08/88     CY73-01A


both  the out-dial driver's  definition and the  in-dial driver's |
definition so the 2 drivers can establish a connection.           |


_A_c_c_e_s_s _I_s_o_l_a_t_i_o_n _M_e_c_h_a_n_i_s_m _C_o_n_s_i_d_e_r_a_t_i_o_n_s

      IMFT  is designed  to  interact  with the  Access Isolation
Mechanism  (AIM) provided that  the proper sensitivity  level and
access categories are specified in the max_access_class statement
(see "IMFT Request Type Definition" below).


     When using AIM with IMFT, the AIM sensitivity levels and the
access categories  must have the  same meanings on  both systems.
When specifying the sensitivity  level, specify the highest level
whose meaning is the same on both systems.  Data equal to or less
than this level can then be transferred.


    Not only must the access categories have the same meanings on
both systems,  but they must  be specified in  the same positions
(order) on both systems.


     For  example, here  is the  order of  access categories  for
System 1 and System 2:

     _S_y_s_t_e_m _1                   _S_y_s_t_e_m _2
       lisd                       dscc
       sstd                       sstd
       mslc                       lisd

For these two systems, only the sstd category can be transferred.
Even though the lisd category exists on both systems, it occupies
different positions on each system, so it is unusable.


     Files and  subtrees can be transferred only  if their access
class is less  than or equal to (1) the  process authorization of
the  user who  submitted the  request and  (2) the  common access
class ceiling.   See "Common Access  Class Ceiling" in  Section 4
for a definition of the common access class ceiling.


     Files and  subtrees are created  on the foreign  system with
the same access class that they have on the local system.


     The   max_access_class   keyword   (described   in   "Device
Definition for IMFT" below) can be used in the args statements of
the  input  and  output  drivers  to  restrict  the level of data
transfer  to an access  class less than  the common access  class
ceiling.  If this  keyword is used, it must be  specified in both


                               2-26            08/88     CY73-01A


the  output driver  on one   system and  the corresponding  input
driver on the other system.


     If the  max_access_class keyword is used,  create the driver
processes on  both systems with  a process authorization  that is
greater  than  or  equal  to  the  access  class specified by the
keyword.   Otherwise,  the  processes  must  be  created  with an
authorization that is greater than  or equal to the common access
class ceiling.   In neither case do the  process authorization of
the  output driver  and the   corresponding input  driver on  the
remote  system need  to be  equal.  See  "IMFT Person  Name Table
Entries" later in this section for a discussion of how to set the
process authorizations of the driver processes.


     The   min_access_class   keyword   (described   in   "Device
Definitions for IMFT" below) can be used in the args statement of
the  input  and  output  drivers  to  restrict  the level of data
transfer to an access class above the specified minimum.  If this
keyword is used,  it must be specified in both  the output driver
on one  system, and the  corresponding input driver  on the other
system.


     All  IMFT  driver  processes  must  be  given  access to the
system_privilege_ gate.  See  "system_privilege_ Access" later in
this section for a description of  how to insure that this access
is granted.


     For a complete description of AIM, refer to the Programmer's
Reference manual (AG91).                                          |


_I_/_O _D_a_e_m_o_n _T_a_b_l_e

     I/O daemon tables define the devices and Request_types to be
used with the  I/O daemon.  A source file consists  of a sequence
of  statements and  substatements that  define and  describe each
device and Request_type.  It is not the intent of this section to
present  a full description  of I/O daemon  tables, but only  the
device and Request_type definitions  required for IMFT I/O daemon
definition.  For  a full description of I/O  daemon tables, refer
to the System Maintenance manual (AM81).                          |


     The  pathname of  the source   of the  I/O daemon  tables is
usually:

     >ddd>idd>iod_tables.iodt




                               2-27            08/88     CY73-01A


     Once  you have edited  the appropriate information  into the
I/O  daemon tables source,  the tables must  be compiled via  the
iod_tables_compiler command  (see the AMOC manual,  GB64).  It is |
recommended,  for convenience,  that the  pre-compiled version of |
the  I/O daemon  tables be  stored in  the same  directory as the
compiled version with the name iod_tables.iodt.


I/O DAEMON DEVICE DEFINITION FOR IMFT

     The IMFT  driver requires that you define  two major devices
in the I/O  daemon tables:  one for the input  driver and one for
the  output  driver.   These  devices  must  specify  use  of the
"imft_driver_" driver module.


     You  must define at  least one minor  device for the  output
driver of each site, and you may define a maximum of two.  Before
choosing minor devices, decide whether you want to be able to:

    ox   transfer files to the remote site

    ox   transfer files from the remote site

    ox   perform both of the above functions

If you only  want to transfer files to the  remote site, you must
define  one   output  driver  minor  device   that  enables  such
transfers.  Likewise, if you only  want to request file transfers
from  the remote site,  you must define  one output minor  device
that enables this  type of transfers.  If you want  to be able to
transfer files to  and from the remote site, you  must define two
minor devices:  one enabling transfers from the foreign site, and
the other enabling transfers to  the foreign site.  Both of these
minor devices are described later in this section.


     The  IMFT driver  does  not  support the  "line:  variable;"
construct.   Additionally,  the  channels  used  by  a driver are *
specified in  the args statement.  Therefore,  the line statement
used for the IMFT driver must be "line:  *;".


      The args statement specifies the following:

      ox   direction of transfer for the driver

      ox   the "attach"  descriptions for the subchannels  used by
          the driver

      ox   the  Person_ids used to  validate the local  and remote
          systems



                               2-28            08/88     CY73-01A


      ox   whether  or not  transfers are  initiated automatically
          when the physical connection is established


      If  a  hardwired  connection  is  used  and  the channel is
configured as  described above, it  is recommended that  all four
I/O  daemon driver  processes for   the connection  be logged  in
automatically by either the system_start_up.ec or the start_up.ec
executed by  Utility.SysDaemon.  Additionally, it  is recommended
that  all  four  drivers   specify  "mode=  automatic"  in  their
respective args  statements.  By including  these specifications,
the  IMFT  connection  will  run  automatically  without operator
intervention whenever both systems are running.


Device Statements

     IMFT   requires   the   following   device   statement   and
substatements to  define the input  and 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 subsequent
            substatements (see below) apply  to this device until
            the next  Line, Device, or Request_type  statement is
            encountered.  Any  <name> can be chosen; it  can be a
            maximum of  24 characters and cannot  contain periods
            or spaces.

driver_module:  <name>;
            For IMFT, <name> must be "imft_driver_".

line: <name>;
            For IMFT, <name> must be "*".

args: <string>;
            Defines the characteristics of this device.  <string>
            is  a  quoted  string   consisting  of  a  series  of
            keyword/value pairs separated  by commas.  The syntax
            of a keyword/value pair is:

                 keyword= value

            No  space is permitted  after the keyword  and before
            the  equal  sign.   If  the  value  contains  spaces,
            commas, quotes, or equal signs, it must be quoted.

            Define the following keyword/value pairs for IMFT:

       direction= <input|output>
            Specifies whether this is  an input or output driver.
            <input|output> must be either "input" or "output".


                               2-29            08/88     CY73-01A


       local_system= <Person_id>
            Specifies the name of the local system.  This name is
            used  to   validate  the  connection.    See  "Access
            Isolation  Mechanism Considerations"  above for  more
            information.  This keyword is required.

       foreign_system= <Person_id>
            Specifies the  Person_id of the remote  system.  This
            Person_id  is also  used to  validate the connection.
            See "Access Isolation Mechanism Considerations" above
            for more  information.  This keyword is  required and
            must  also be  used in  constructing the Request_type
            names.

       input_description= <quoted_string>
       ids= <quoted_string>
            Specifies  the  attach   description  for  the  input
            subchannel  for  this  driver.   Note  that  a quoted
            string  is required,  thereby creating  an entry with
            double  quotes   (see  example).   This   keyword  is
            required  if   the  I/O  module  in   use  is  either
            hasp_host_   or   hasp_workstation_.    It   is   not
            appropriate   for   the   subchannels   of   an  X.25
            connection.

       output_description= <quoted_string>
       ods= <quoted_string>
            Specifies  the  attach  description  for  the  output
            subchannel  for  this  driver.   Note  that  a quoted
            string  is required,  thereby creating  an entry with
            double  quotes   (see  example).   This   keyword  is
            required  if   the  I/O  module  in   use  is  either
            hasp_host_ or hasp_workstation_.   The keyword is not
            appropriate   for   the   subchannels   of   an  X.25
            connection.

       io_description= <quoted_string>
       iods= <quoted_string>
            specifies the attach description for the channel used
            by this driver for both  input and output.  Note that
            a  quoted  string  is  required,  thereby creating an
            entry with double quotes (see example).  This keyword
            is required if the  communications protocol in use is
            an X.25 connection.  It is not appropriate if the I/O
            module is hasp_host or hasp_workstation.

            This keyword is not required for an in-dial driver in |
            the  IMFT-Dial connection  mode.  The  in-dial driver |
            builds this information from the data supplied by the |
            Answering Service when a remote out-dial driver dials |
            the local system.




                               2-30            08/88     CY73-01A


       in_dial= input_driver_dial_id                              |
            This  argument is preferred  for use by  an IMFT-Dial |
            connection  mode   input  driver  and   provides  the |
            dial_qualifier  to be  used for  the dial connection. |
            The  "input_driver_dial_id" will  be the  same as the |
            "input_driver_dial_id"    used   in    the   out_dial |
            specification  on  the  out-dialing  driver.   If  an |
            in-dial connection is used  for an output driver, the |
            sleep_time parameter on  the out-dialing input driver |
            should  be adjusted to  provide a long  polling sleep |
            time to reduce connection trial costs.                |

       out_dial= DIAL_TEXT                                        |
            Specifies  the text that  will be transmitted  with a |
            trailing  newline when  the out-dial  driver has seen |
            the trigger_text in the data received from the remote |
            system.  The contents of  the DIAL_TEXT string should |
            be like the following:

                 dial input_driver_dial_id Personid.Projectid     |

            If  an  out-dial  connection  is  used  for  an input |
            driver, the  sleep_time parameter should  be adjusted |
            to provide  a long polling time  to reduce connection |
            trial  costs.   The  "Personid.Projectid"  is  of the |
            process which has established the dial service on the |
            system of the in-dial driver.  Typically, it would be |
            IMFT.Daemon or IMFT.SysDaemon.

       trigger_text=STR                                           |
            Specifies  the  text  which  will  cause an IMFT-Dial |
            connection mode  out-dail driver to send  the text of |
            the  out_dial  keyword  to   the  other  end  of  the |
            connection.   The handshaking  protocol used  for the |
            out-dial  driver  scans  the  text  received from the |
            remote  (in-dial  driver)  system  until  it  finds a |
            character  sequence which   matches the  STR supplied |
            with  the trigger_text  keyword.  This  is the system |
            greeting banner.  The STR  specified needs to be only |
            known to  occur on the  last line and  must take into |
            account special session notices  or messages that are |
            displayed as the first line of the greeting banner.   |

       sleep_time= MINUTES                                        |
            Specifies  the number  of minutes  that an  IMFT-Dial |
            out-dial  driver   is  to  wait  before   retrying  a |
            connection that previously  failed.  If this argument |
            is  not  specified,  the  default  is "sleep_time=5". |
            This  parameter  is  valid   only  for  an  IMFT-Dial |
            connection mode out-dial driver.

            The sleep_time parameter is  also used in a situation |
            where  the input IMFT  driver out-dials to  an output |


                               2-31            08/88     CY73-01A


            IMFT driver  to set a polling period.   After an idle |
            line  disconnection, the  input driver  will wait for |
            the  sleep_time period   before redialing  the output |
            driver  to check  if it   has set  up a  dial server,
            indicating  it  has  traffic  to  pass.   If the dial |
            server has  not been set  up or the  output driver is |
            still  idle,  the  input  driver  will  sleep for the |
            sleep_time period and then  recheck the remote output |
            driver.

       idle_line_drop= <yes|no>                                   |
            Specifies that the output driver  is to drop the line |
            to the input driver idle_delay_count*30 seconds after |
            it   goes   idle.    The   connection   will  not  be |
            reestablished  until there  are requests  to process. |
            If  this argument  is  not  specified the  default is |
            idle_line_drop=no.  This keyword  is only allowed for |
            an output  driver.  <yes|no> must be  either "yes" or |
            "no".

       idle_delay_count= IDLE_PERIODS                             |
            Specifies the  number of idle periods  (each about 30 |
            seconds  long)  that  the  output  driver  is to wait |
            before  dropping  the   line  if  the  idle_line_drop |
            keyword is "yes".  This  delay count permits the line |
            to be held up for  some period (after the coordinator |
            first senses that the driver is idle) before the line |
            is relinquished.  If this  argument is not specified, |
            idle_delay_count=2   is  assumed   (1  minute).    An |
            immediate   line    drop   can   be    requested   by |
            idle_delay_count=0.    If   idle_line_drop=no,   this |
            argument has no effect.

       min_time_est_msg= N                                        |
            Specifies what the minimum value must be (in seconds) |
            for the estimated time  to transfer the object before |
            a  message  is  displayed  on  the  log stream.  This |
            allows a site to control the amount of these messages |
            sent to the log file.  The default is 60 seconds.

       mode= <auto|manual>
            Specifies whether  this driver is to  operate with or
            without operator intervention.  <auto|manual> must be
            either "automatic", "auto",  or "manual".  (The value
            "auto" is a short form of "automatic".)  This keyword
            is optional and defaults  to "manual".  Use of "auto"
            or "automatic" implies  either "auto_receive= yes" or
            "auto_go= yes"  as appropriate, causes the  driver to
            wait  indefinitely for  completion of  the connection
            sequence,  and  causes  the  driver  to  wait for the
            remote  system's driver  to reconnect  again whenever
            the  remote  driver  disconnects.   Use  of  "manual"
            implies either "auto_receive= no" or "auto_go= no" as


                               2-32            08/88     CY73-01A


            appropriate, causes  the driver to wait  no more than
            five  minutes   for  completion  of   the  connection
            sequence,  and causes  the driver  to logout whenever
            the remote system's driver disconnects.

       auto_go= <yes|no>
            Specifies whether an output driver should immediately
            begin  to transmit files  and subtrees to  the remote
            system or should instead wait for an operator command
            after the  connection is established.   <yes|no> must
            be  either "yes"  or  "no".   This keyword  cannot be
            specified  for  an  input  driver.   This  keyword is
            optional  and defaults to  "no" if "mode=  manual" is
            specified and defaults to  "yes" if "mode= automatic"
            is specified.

       auto_receive= <yes|no>
            Specifies whether an  input driver should immediately
            wait for  files and subtrees from  the remote system,
            or  should wait  for  an  operator command  after the
            connection is  established.  <yes|no> must  be either
            "yes" or "no".  This keyword may not be specified for
            an  output  driver.   This  keyword  is  optional and
            defaults to  "no" if "mode= manual"  is specified and
            defaults to "yes" if "mode= automatic" is specified.

       allow_remote_request= <yes|no>
            Specifies  whether  or  not  an  input driver accepts
            requests from  the remote system for  the transfer of
            files from the local system.  <yes|no> must be either
            "yes" or "no".  This keyword is optional and defaults
            to  "no".  It  can not   be specified  for an  output
            driver.

       explicit_access= <yes|no>
            This keyword no longer  affects driver operation.  It
            is still accepted for  upward compatibility.  It used
            to specify  whether an explicit "r" ACL  term for the
            local  transmitting driver  was required  in order to
            transfer  the object  to the  remote system  when the
            request was submitted on the remote system.  However,
            access checking has been extended and is done for all
            requests.  See discussion under "Access Requirements"
            in section 4 for further details.

       max_access_class= <quoted_string>
            Specifies the maximum access  class for data that may
            be  transferred across  this connection.   The access
            class  specified must  be less  than or  equal to the
            common access  class ceiling between the  two systems
            (as defined in Section 4  of this manual).  If given,
            this  keyword must be  specified for both  the output
            driver  on  one  system  and  the corresponding input


                               2-33            08/88     CY73-01A


            driver on the other system.  If not given, the common
            access class  ceiling is used  as the limit  for data
            transfer.

       min_access_class= <quoted string>=
            Specifies the minimum access  class for data that may
            be  transferred across  this connection.   The access
            class must be less than or equal to the common access
            class between the two  systems (as defined in Section |
            4  of  this  manual).   If  both min_access_class and
            max_access_class are given, the min_access_class must
            be  less than or  equal to the  max_access_class.  If
            the keyword  is given, it must be  specified for both
            the output driver on one system and the corresponding
            input  driver on  the other   system.  If  it is  not
            given,  a  minimum  access  class  of "system_low" is
            used.

       version= <2.0|3.0|4.0>                                     |
            Specifies the version of the IMFT driver software the |
            remote  system  is  running.   <2.0|3.0|4.0>  must be |
            "2.0", "3.0" or "4.0".  The  "2.0" version is the one |
            provided  in  MR10.1.   The   "3.0"  version  is  one |
            provided after  MR10.1 and before MR12.2.   The "4.0" |
            version  was  initially  released  in  MR12.2.   This |
            keyword is optional; the  default is "4.0".  In order |
            to communicate  with older versions, the  keyword and |
            the applicable value must be supplied.                |

       indirect= <path>
            Specifies a  segment or archive  component containing
            the keyword/value  pairs for this device.   <path> is
            the pathname of the segment or (if the ::  convention
            is used) the archive component.  This keyword must be
            used if the length of the args string is greater than
            256  characters.  If  it  is  used, no  other keyword
            should be included in the args statement; they should
            all  appear  in  the  specified  segment  or  archive
            component.  In  this case, the entire  args string is
            not quoted, and the  quotes in the input_description,
            output_description, or io_description  values are not
            doubled.

       debug_mode= <yes|no>                                       |
            Specifies whether the driver process is to operate in |
            debug mode.   <yes|no> must be either  "yes" or "no". |
            A  test environment  (the test_io_daemon  command was |
            used  or iod_overseer_$test   entry was  used) allows |
            control over the driver  process that is not normally |
            available when  operating in a normal  mode.  In this |
            mode,  the signal,  "imft_debug_", will  be signalled |
            for  any IO  error that   would cause  the driver  to |
            reinitialize.  If this mode is not selected, the test |


                               2-34            08/88     CY73-01A


            environment of  the process is turned  off, reverting |
            the environment of the driver into normal operation.  |

       copy_data= <yes|no>                                        |
            Specifies whether the driver process, if operating in |
            a  test environment  (the test_io_daemon  command was |
            used  or iod_overseer_$test  entry was  used), should |
            record the  IO with the remote site  in files created |
            in  the working  directory.  <yes|no>  must be either |
            "yes"  or  "no".   The  names  of  the  files will be |
            "imft.debug.i" and  "imft.debug.o" for the  input and |
            output traffic respectively.

       validate_system_id= <yes|no>                               |
            Specifies  that  the  driver  should  not  attempt to |
            validate  the  system  identifiers   in  the  PNT  to |
            establish and validate the connection.  <yes|no> must |
            be  either "yes" or  "no".  In normal  operation this |
            argument  should be  omitted to  require system  name |
            validation.    This   facilitates   testing   by  not |
            requiring registration  of the test remote  system in |
            the PNT.   This keyword is intended  only for initial |
            line testing in setting up an IMFT driver.            |

            NOTE:   validate_system_id=no must   be used  at both |
            input and  output drivers if  it is used  at all.  It |
            specifies a blank enciphered  password which will not |
            match any valid system password.                      |

       debug_connect= <yes|no>                                    |
            Specifies  whether the  driver  is  to emit  the text |
            received from  the distant system to  the driver log. |
            <yes|no>  must be  either "yes"  or "no".   In normal |
            operation  a site   would select  debug_connect=no to |
            reduce log traffic for the normal idle-disconnect and |
            reconnect operations.   This argument is  intended to |
            assist  in determining  protocol errors  by providing |
            connection debugging information in the driver log.   |

















                               2-35            08/88     CY73-01A


minor_device:  <name>;
            Defines  the name  of a   minor device  of an  output
            driver, and  denotes the beginning of  a minor device
            description.   (You must  define at  least one output
            minor device  for each IMFT site, and  you may define
            two.  Your  choices are one or both  of the following
            minor  devices:  one  that enables  file transfers to
            the foreign  site, and one  that enables files  to be
            transferred from  the foreign site.)   All subsequent
            substatements  (see  example)  refer  to  this  minor
            device until the occurrence of the next Line, Device,
            minor_device  or Request_type statement.   <name> can
            be  any string  of up   to 24  characters; it  cannot
            contain   periods   or   spaces.    The  default_type
            substatement is required for each minor device.

default_type:  <name>;
            Identifies the  Request_type serviced by a  device or
            minor  device.  It  refers to  a device  for an input
            driver,  and a  minor  device  for an  output driver.
            <name>  must be  the same   as the  Person_id of  the
            foreign system,  prefaced by either "From_"  or "To_"
            (e.g.,  From_System_M).  <name>  must be  the same as
            that of the Request_type  that identifies this device
            or minor device.


Example 1

     The  following example  defines an  IMFT output  driver on a
HASP  multiplexed  channel.   Note  that  two  minor  devices are
defined, which enables the output driver to transfer files to the
remote site, and request transfers from the remote site.

     Device:             system_m_ft_out;
      driver_module:       imft_driver_;
      line:                *;
      args:                "direction=output, local_system=MIT,
                              foreign_system=System-M
                              ods=""hasp_host_ -comm hasp
                                    -tty b.h203.rdr1 -device reader"",
                              ids=""hasp_host_ -comm hasp
                                    -tty b.h203.pun1 -device punch"",
                              auto_go=yes";
     minor_device:          to;
       default_type:          To_System-M;
     minor_device:          from;
       default_type:          From_System-M;







                               2-36            08/88     CY73-01A


Example 2

     The  example below defines  an IMFT input  driver on a  HASP
multiplexed channel.

     Device:             mit_file_transfer_in;
       driver_module:      imft_driver_;
       line:               *;
       args:               "direction=input, local_system=System-M,
                              foreign_system=MIT,
                              ids=""hasp_workstation_ -comm hasp
                                    -tty b.h203.rdr2 -device reader"",
                              ods=""hasp_workstation_ -comm hasp
                                    -tty b.h203.pun2 -device punch"",
                              allow_remote_request=yes,
                              explicit_access=no,
                              auto_receive=yes";
       default_type:       To_MIT;


     The  next set  of examples  define IMFT  drivers on  an X.25
channel.   Note  that  the  examples  contain the io_description= |
(iods=) keyword, which is used for bidirectional channels such as
X.25,  in contrast to  the input_description= (ids=)  keyword and
the  output_description=  (ods=)  keyword,  which  are  used  for
unidirectional channels such as HASP.


Example 3

     In the  following example, a  device is defined  for an IMFT
X.25-Slave connection  mode output driver on  an X.25 multiplexed |
channel.   Note that only  one minor device  is defined; in  this |
case,  the output driver  can only transfer  files TO the  remote
site.

     Device:              cisl_file_transfer_out;
       driver_module:       imft_driver_;
       line:                *;
       args:                "direction=output, local_system=System-M,
                               foreign_system=CISL,
                               max_access_class=system_low,
                               iods=""tty_ b.h000.*,
                               -ds 31060850:slv01"", mode=automatic";
     minor_device:         to;
       default_type:         To_CISL;









                               2-37            08/88     CY73-01A


Example 4

     The following example defines  an IMFT X.25-Slave connection |
mode input driver on an X.25 multiplexed channel.                 |

     Device:              phx_file_transfer_in;
       driver_module:       imft_driver_;
       line:                *;
       args:                "direction=input, local_system=CISL,
                               foreign_system=System-M,
                               max_access_class=system_low,
                               iods=""tty_ b.h000.slv01"",
                               mode=automatic";
       default_type:      To_System-M;


Example 5                                                         |

     The following  example defines an IMFT-Dial  connection mode |
out-dial output driver on an X.25 multiplexed channel.  Note that |
two  minor devices  are defined;  the output  driver can transfer |
files to the  remote site as well as send  requests to the remote |
site for files to be sent to the local site.

     Device:             actc_file_transfer_out;                  |
       driver_module:      imft_driver_;                          |
       line:               *;                                     |
       args:               "direction=output,                     |
                              local_system=System-M,              |
                              foreign_system=ACTC_SYSM,           |
                              iods=""tty_ tymnet.*                |
                                   -ds x29,302062600090"",        |
                              out_dial=""dial sysm_actc_input     |
                                   IMFT.SysDaemon"",              |
                              trigger_text=""Load "",             |
                              mode=automatic,                     |
                              auto_go=yes,                        |
                              idle_line_drop=yes,                 |
                              debug_connect=no,                   |
                              sleep_time=10,                      |
                              idle_delay_count=1";                |
       minor_device:       to;                                    |
         default_type:       To_ACTC_SYSM;                        |
       minor_device:       from;                                  |
         default_type:       From_ACTC_SYSM;                      |










                               2-38            08/88     CY73-01A


Example 6                                                         |

     The following  example defines an IMFT-Dial  connection mode |
in-dial input driver on an asynchronous channel.

     Device:             actc_file_transfer_in;                   |
       driver_module:      imft_driver_;                          |
       line:               *;                                     |
       args:               "direction=input,                      |
                              local_system=System-M,              |
                              foreign_system=ACTC_SYSM,           |
                              in_dial=actc_sysm_input,            |
                              mode=automatic,                     |
                              auto_receive=yes,                   |
                              allow_remote_request=yes";          |
       default_type:       To_ACTC_SYSM;                          |


Example 7                                                         |

     The following  example defines an IMFT-Dial  connection mode |
out-dial   output  driver   on  an   asynchronous  channel.   The |
asynchronous  channel must  be able  to support  8 bit  character |
data.  Note that two minor devices are defined; the output driver |
can transfer files to the remote site as well as send requests to |
the remote site for files to be sent to the local site.

     Device:             sysmd_file_transfer_out;                 |
       driver_module:      imft_driver_;                          |
       line:               *;                                     |
       args:               "direction=output,                     |
                              local_system=System-M,              |
                              foreign_system=SysMD,               |
                              iods=""tty_ acu.8bit                |
                                   -ds 99!862-0110"",             |
                              out_dial=""dial sysmd_input         |
                                   IMFT.Daemon"",                 |
                              trigger_text=""Load "",             |
                              mode=automatic,                     |
                              auto_go=yes,                        |
                              idle_line_drop=yes,                 |
                              debug_connect=no,                   |
                              sleep_time=10,                      |
                              idle_delay_count=1";                |
       minor_device:       to;                                    |
         default_type:       To_SysMD;                            |
       minor_device:       from;                                  |
         default_type:       From_SysMD;                          |







                               2-39            08/88     CY73-01A


Example 8                                                         |

     The following  example defines an IMFT-Dial  connection mode |
in-dial   input   driver   on   an   asynchronous  channel.   The |
asynchronous  channel must  be able  to support  8 bit  character |
data.

     Device:             sysmd_file_transfer_in;                  |
       driver_module:      imft_driver_;                          |
       line:               *;                                     |
       args:               "direction=input,                      |
                              local_system=System-M,              |
                              foreign_system=SysMD,               |
                              in_dial=sysmd_input,                |
                              mode=automatic,                     |
                              auto_receive=yes,                   |
                              allow_remote_request=yes";          |
       default_type:       To_SysMD;                              |


REQUEST_TYPE DEFINITION FOR IMFT

     You  must specify  a  Request_type  in the  manner described
below, for each device that you defined in the I/O daemon tables.


     If you  defined only one minor  output device and it  is the
device that enables transfers to the remote site, you must define
one Request_type that  is for transfers TO the  foreign site, and
specify the  appropriate minor output device.   Specify the input
driver  in  this  Request_type,  as   well.   The  name  of  this
Request_type description  must be the same as  the foreign system
ID specified  in the args  statement of the  drivers, prefaced by
the string "To_" (e.g., To_MIT).


     If you  defined only one minor  output device and it  is the
device  that enables  transfers from  the remote  site, you  must
define one  Request_type that is  for transfers FROM  the foreign
site, and  specify the appropriate minor  output device.  Specify
the input  driver in this Request_type description  as well.  The
name of this Request_type must be  the same as the foreign system
ID specified  in the args  statement of the  drivers, prefaced by
the string "From_" (e.g., From_MIT).


     If you defined  two minor output devices for  IMFT, you must
define two Request_types:  one for transfers to the foreign site,
specifying  the  appropriate  minor  device,  and  the  other for
transfers from the foreign site, mentioning the appropriate minor
device.  The input driver must be specified in one (and only one)
of the two Request_type descriptions, as well.



                               2-40            08/88     CY73-01A


     Currently, the  IMFT facility does not charge  users for use
of the facility.  Therefore, the Request_type defined for an IMFT
driver must include the statement "accounting:  nothing;".


     If  the  Access  Isolation  Mechanism  (AIM)  is enabled, to
ensure  proper operation  of the  daemon the  definitions of  the
Request_types used for the input  and output drivers must include
the statement:

     max_access_class:  system_high;

If this statement is omitted, the coordinator will leave requests
in  the  queue  indefinitely.   See  "Access  Isolation Mechanism
Considerations" above for more detail.


      By  default, the  IMFT user  commands use  the Request_type
"imft".   If  you  wish  to  define  a  default remote system for
transfer  requests, define  the  "imft"  Request_type in  the I/O
daemon   tables  with   the   same   values  specified   for  the
driver_userid,  default_queue, max_queues,  max_access_class, and
device  statements as are  specified for the  actual Request_type
for  that remote  system.   In  addition, the  following commands
should be issued after  using the create_daemon_queues command to
make  the "imft"  Request_type a  synonym of  the actual  request
type:

     delete imft_*.ms
     add_name To_Site-Name_(1 2 ... N).ms imft_(1 2 ... N).ms

where To_Site-Name is  the Request_type name as given  in the I/O
daemon  tables and  N is  the number  of queues  defined for that *
Request_type.


Request_Type Statements

     IMFT  requires  the  following  Request_type  statement  and
substatements  in the I/O  daemon tables.  If  you wish to  use a
queue other than the default  queue, use the max_queues statement
(see the System Maintenance manual, AM81).                        |

Request_type:  <name>;
            Defines the name of  the Request_type and denotes the
            beginning   of  a   Request_type  description.    Any
            subsequent  statements (see   example) apply  to this
            Request_type  until the  next Line,  Request_type, or
            Device statement is encountered.   <name> must be the
            <name>  specified as the  foreign system name  in the
            input and output driver  definitions, prefaced by the
            string "From_" or "To_" (e.g., To_MIT).



                               2-41            08/88     CY73-01A


generic_type:  <name>;
            IMFT requires the generic type <name> to be:  imft.

driver_userid:  <Person_id.Project_id>;
            Must  identify the  user selected  above to  run this
            connection.

default_queue:  <number>;
            The default_queue substatement is  used to define the
            default  queue  for  a  request  type.   The value of
            <number>  may  be  from  1  to  max_queues.   If  not
            specified,  it is  set to  the value  defined in  the
            max_queues substatement,  but it will not  be greater
            than 3.

accounting: <name>;
            IMFT requires <name> to be "nothing".

max_access_class:  system_high;
            Must  be  specified  exactly  as  shown,  or  the I/O
            coordinator  will   leave  requests  in   the  queues
            indefinitely.

device: <name>;
            Specifies  the devices  that can  be used  to process
            requests of the associated type.  If you have a minor
            output device that is for submitting transfers to the
            remote  site, specify it  in the device  statement of
            the  corresponding Request_type  (e.g., the  one that
            begins  with the  string "To_").   Similarly, if  you
            have  a  minor  device  that  is  for requesting file
            transfers  from the  remote site,  specify it  in the
            device  statement of  the corresponding  Request_type
            (e.g., the one that  begins with the string "From_").
            Specify the  input driver in the  device statement of
            EITHER the Request_type for  transfers to the foreign
            site,  or  the  Request_type  for  transfers from the
            foreign  site.  (If you  have only defined  one minor
            output  device,  give  the   input  driver  the  same
            Request_type as that of the output minor device.)















                               2-42            08/88     CY73-01A


Example

In the example below, a pair  of Request_types are defined for an
IMFT  connection with  the  system  named "System-M".   The first
Request_type  specifies the  input  driver  and the  minor output
device  used  for  transfers  to  the  remote  site.   The second
Request_type specifies the minor output device used for transfers
from the remote site.

        Request_type:              To_System-M;
          generic_type:            imft;
          driver_userid:           IMFT.Daemon;
          default_queue:           3;
          accounting:              nothing;
          max_access_class:        system_high;
          device:                  system_m_ft_out.to;
          device:                  system_m_ft_in;

        Request_type:              From_System-M;
          generic_type:            imft;
          driver_userid:           IMFT.Daemon;
          default_queue:           3;
          accounting:              nothing;
          max_access_class:        system_high;
          device:                  system_m_ft_out.from;


_I_M_F_T _P_r_o_j_e_c_t _M_a_s_t_e_r _F_i_l_e _E_n_t_r_i_e_s

     The list of persons who can log in on a project is contained
in a  binary table known  as the Project  Definition Table (PDT),
maintained by the system.  There is one entry in the PDT for each
user; the entry contains the user's attributes and resource usage
information.  The PDT is created from an ASCII segment called the
Project  Master File  (PMF).  A  PMF exists  for each  registered
project.   It is the  basic project-administration data  base and
contains the  project's specification of user  attributes.  A PMF
entry must be defined for the IMFT daemon process.


     The  system  references  the  PDT,  not  the  PMF,  when  it
determines if  a user can log  in.  To make a  change to the PDT,
modify the PMF, convert the PMF into a binary copy of the PDT via
the  cv_pmf command,  and request  the system  to modify  its PDT
according  to the copy  using the install  command (see the  AMOC |
manual, GB64).









                               2-43            08/88     CY73-01A


     Every project on  the system has a "Project_id"  in the PMF.
A separate Project_id can be created  for IMFT.  If IMFT is to be
available on a system wide basis, add the required PMF entries to
a system  overhead project such  as "Daemon" or  "SysDaemon".  If
IMFT is to be available for a  small group of users in a specific
project, add  the required entries  to that project  entry in the
PMF.


     The following PMF entries are required to define the process
that will run IMFT:

Project_id: character_string;
            The name of the Project_id under which IMFT will run.
            If  you are not  establishing a separate  project for
            IMFT,  do  not  enter  a  Project_id  and  place  the
            keywords below  in a system overhead  project such as
            "Daemon", or a user project.

Person_id:  character_string;
            character_string  is the   Multics Person_id.   It is
            recommended that you use "IMFT" as the Person_id.

initproc:  pathname;
            For IMFT, pathname must be "iod_overseer_".

attributes:  character_strings;
            Character_strings  are attribute  names separated  by
            commas.  IMFT requires  the following attribute names
            (for additional entries, see  the MAM Project manual, |
            AK51):

            ^v_process_overseer         Indicates  that no  other
                                        process  overseer can  be
                                        specified for IMFT.

            dialok                      IMFT   can  accept   dial
                                        requests.

            daemon                      IMFT can be  logged in by
                                        the   operator  via   the
                                        message coordinator.

            multip                      Permits  multiple  logins
                                        for  IMFT:   one  for the
                                        input driver  and one for
                                        the output driver.








                               2-44            08/88     CY73-01A


Example

     Person_id:  IMFT;
       initproc:  iod_overseer_;
       attributes:  ^v_process_overseer, dialok, daemon, multip;

In  the above  example, the   required PMF  entries for  IMFT are
placed under an existing Project_id.


_I_M_F_T _P_e_r_s_o_n _N_a_m_e _T_a_b_l_e _E_n_t_r_i_e_s

     The IMFT daemon, local system  name, and foreign system name
must be  registered, as 3  individual users would,  in the Person
Name  Table  (PNT)  and  the  User  Registration  File (URF).  To
register   IMFT   in   both,   use   the   system   administrator
"new_user$nua" command (see the AMOC manual, GB64).               |


     The  driver  processes  of  an  IMFT  connection  perform an
initial  "handshake" sequence.    During the  handshake sequence,
each  driver  transmits  the  Person_id  and  card input password
specified in the local_system keyword  in the args statement (see
"Device Definition  for IMFT").  The remote  system validates the
Person_id  and  password  against   the  Person_id  and  password
specified by the foreign_system keyword.  Therefore, register the
Person_ids  specified   in  the  local_system  keyword   and  the
foreign_system keyword  on both systems with the  same card input
passwords.


     When registering  the daemon, preface the full  name with an
asterisk  (*) to allow  the system to  prompt for the  Person_id.
For default project, specify the Project_id specified in the PMF;
no  password is required  but one can  be specified; and  no card
reader password  is required.  For AIM  authorizations, enter the
entries decided upon from "AIM Considerations".


     Local system registration requires that you preface the full
name with  an asterisk (*)  to allow the  system to prompt  for a
Person_id;  no password  is required.   The card  reader password
specified must  be the card  reader password given  on the remote
system when this Person_id was registered.


     Preface the full name of the foreign system with an asterisk
(*) to allow  the system to prompt for a  Person_id.  No password
is required.  The card password must be the same as the one given
on the remote system when this Person_id was registered.





                               2-45            08/88     CY73-01A


_P_R_E_P_A_R_I_N_G _I_M_F_T _F_O_R _O_P_E_R_A_T_I_O_N

     To run an IMFT connection, you must:

     ox    Assign the appropriate access to the PNT

     ox    Create  an   access  control  segment  (ACS)   for  the
          communications  channels  being  used  and  assign  the |
          appropriate access to the ACS                           |

     ox    Assign the appropriate  access to the system_privilege_
          gate

     ox    Prepare the message coordinator for IMFT

     ox    Optionally, add  entries to your  system_start_up.ec or
          admin.ec to simplify operation of the drivers.


_A_s_s_i_g_n_i_n_g _A_c_c_e_s_s _t_o _t_h_e _P_N_T

     To  validate   the  remote  drivers  while   establishing  a
connection, and also to validate users during the actual transfer
of  requests, give the  processes that run  the input and  output
drivers  at least  read (r)  access to  the system's  Person Name
Table (PNT).


     To assign the correct access,  issue a set_acl command as in |
the following example:

     set_acl >sc1>PNT r Person_id.Project_id                      |


     The processes  also need access to  the pnt_network_gate_ in |
order  to access the  ring2 PNT.  The  following command must  be |
issued from a sufficiently privileged administrative process:     |

     l_set_acl >tools>pnt_network_gate_ re Person_id.Project_id   |


_S_u_b_c_h_a_n_n_e_l _A_c_c_e_s_s _C_o_n_t_r_o_l _S_e_g_m_e_n_t

     To create  the required ACS  and set the  appropriate access
for  the subchannels  of either   a HASP  or an  X.25 multiplexed
channel, issue the following command:

     create >sc1>rcp>x.hNNN.sub1.acs

where x.hNNN is the channel number specified in the CMF, and sub1
identifies one  of the multiplexer subchannels  identified in the
args statement of the input and output drivers.



                               2-46            08/88     CY73-01A


     Next,  issue  an  add_names  command  employing  the  equals
convention  to associate  the rest  of the  subchannels with  the
newly created ACS, as in the following example.

     add_names >sc1>rcp>x.hNNN.sub1.acs =.=.sub2.= =.=.sub3.=
     =.=.sub4.=

where sub2, sub3,  and sub4 identify the rest  of the subchannels
in the args statement.


     Finally,  set the appropriate  access to the  ACS as in  the
following example.

     set_acl >sc1>rcp>x.hNNN.sub1.acs rw Person_id.Project_id     |


_A_s_y_n_c_h_r_o_n_o_u_s _C_h_a_n_n_e_l _A_c_c_e_s_s _C_o_n_t_r_o_l _S_e_g_m_e_n_t                       |

     If  the site  configured any  channels in  the CMF  with the |
"check_acs:" statement  for any login or  autocall channels, then |
an  access  control  segment  has  to  be  generated  for any new |
channels that  were configured for the IMFT  drivers.  Create the |
ACS segment by issuing the following command line:                |

     create >sc1>rcp>x.hNNN.acs                                   |

where x.hNNN is  the channel identified in the  args statement of |
the out-dial driver.                                              |


     Set read/write  (rw) access to  the ACS as  in the following |
example.

     set_acl >sc1>rcp>x.hNNN.acs rw Person_id.Project_id          |


_s_y_s_t_e_m___p_r_i_v_i_l_e_g_e__ _A_c_c_e_s_s

     The  IMFT driver  requires access  to the  system_privilege_
gate.   Therefore,   add  the  following  command   line  to  the
system_start_up.ec for each user who will run an IMFT connection:

hp_set_acl >sl1>system_privilege_ re Person_id.Project_id











                               2-47            08/88     CY73-01A



_q_u_e_u_e___a_d_m_i_n__ _A_c_c_e_s_s

     An input driver that  processes requests for remote transfer
(i.e.,   "allow_remote_request=yes"   appears   in   the   device
definition) requires access to the queue_admin_ gate.  Therefore,
add the following command line to the system_start_up.ec for each
user who will run such an input driver:

     l_set_acl >sss>queue_admin_ re Person_id.Project_id          |


_M_e_s_s_a_g_e _C_o_o_r_d_i_n_a_t_o_r

     For   the  IMFT  daemon   to  issue  messages   and  receive
directives,  you  must  create   the  input  and  output  message
segments,  and  establish  the  message  coordinator  sources and
virtual consoles.


     Issue the  following command only  once to create  the input
and output message segments:

     create >sc1>(input_SOURCE_name output_SOURCE_name).message


     The IMFT daemon process must  have read/write (rw) access to
its segment.   Issue the following  command to set  the access on
the message segments:

     set_acl           >sc1>input_SOURCE_name.message          rw
Person_id.Project_id
     set_acl          >sc1>output_SOURCE_name.message          rw
Person_id.Project_id


     Use the  define command and  the route command  to establish
the message coordinator sources and virtual consoles.  Most often
the two commands are entered in the system_start_up.ec file.


     IMFT messages can be sent to an actual terminal, a log file,
or both an  actual terminal and a log file.  If  you want to send
IMFT messages to  a terminal only, or a terminal  and a log file,
you must register a message  coordinator channel for the terminal
in the CMF (see the MAM Communications manual, CC75) and issue an |
accept  command (see the  AMOC manual, GB64)  in addition to  the |
define command and route command.


     Following  is a  brief description  of the  define and route
commands; for a full description, see the AMOC manual (GB64).     |



                               2-48            08/88     CY73-01A


DEFINE COMMAND

     The  define command  defines the  virtual console  that will
receive messages from the IMFT  daemon.  The format of the define
command is:

     define VCONS TYPE DEST


Example 1

     sc_command define iod tty b.h200

In the above example, a virtual console named iod is defined that
forwards all output  sent to it to the terminal  whose channel is
b.h200


Example 2

     sc_command define iolog log iolog

In the  above example, a  virtual console named  iolog is defined
that  forwards  all  output  sent  to  it  to  the log file named
>sci>iolog.


ROUTE COMMAND

     The route command  sends output from the IMFT  daemon to the
designated virtual  console.  A route command must  be issued for
the user_i/o,  error_i/o, and log_i/o  streams of both  the input
and output drivers.  Thus, a total  of six route commands must be
issued for each  virtual console that is to  receive IMFT output.
The format of the route command is:

     route SOURCE STREAM VCONS


Example

     sc_command route (mitfti mitfto) user_i/o iod
     sc_command route (mitfti mitfto) error_i/o *iod
     sc_command route (mitfti mitfto) log_i/o iod
     sc_command route (mitfti mitfto) user_i/o iolog
     sc_command route (mitfti mitfto) error_i/o *iolog
     sc_command route (mitfti mitfto) log_i/o iolog


     In the above example, output from the IMFT daemons using the
sources mitfti and  mitfto is routed to the  two virtual consoles
iod (a terminal)  and iolog (a log file) defined  in the previous
examples.  The  asterisk (*) before the virtual  console name for


                               2-49            08/88     CY73-01A


the  error_i/o stream  causes the  terminal to  issue an  audible
alarm  (beep tone) whenever  error messages are  issued.  Command
iteration is  used to reduce  the number of  route commands lines
from twelve to six.  Note that the commands are prefaced with the
sc_command  as required  when adding  operator commands  to an ec
file.


_I_M_F_T _I_n_i_t_i_a_l_i_z_a_t_i_o_n

     You can configure IMFT to run automatically without operator
intervention, to run with other daemon processes that are invoked
by  the  operator,  or  to   run  separately  from  other  daemon
processes.


     If you configure IMFT  to run automatically without operator
intervention (see  "Device Type Definition for  IMFT"), place the
login  commands that  log in   the IMFT  input and  output driver
processes    and   the    reply   commands    (below)   in    the
system_start_up.ec file.


     If  you   decide  to  initialize  IMFT   with  other  daemon
processes, edit  the login commands  and reply commands  into the
admin.ec  segment that  contains  the  definitions of  the daemon
processes invoked by an operator x command.


     If you  are not running IMFT  with automatic initialization,
or are not initializing IMFT with other daemon processes, you can
create  a new  entry in  admin.ec that  is invoked  with a unique
operator x  command.  The load_mpx command (see  the AMOC manual, |
GB64) might then be then required with replies of receive and go.


LOGIN COMMAND

     The login  command causes the  login of a  daemon process at
the  operator's request.   For a  full description  of the  login
command, see the AMOC manual (GB64).                              |


     The format of the login command is:

     login DAEMON_USER_ID SOURCE                                  |

It is recommended  that you issue a pause  command directly after
the login command in the system_start_up.ec file, as follows:

     pause 10




                               2-50            08/88     CY73-01A


This gives  the system time to  log in the daemon  process before
executing subsequent commands in the file.


Example

     sc_command login IMFT.Daemon mitfti
     sc_command login IMFT.Daemon mitfto

In  the above example,  the IMFT input  and output processes  are
logged in.


REPLY COMMAND

     The reply command sends an  input line to a specified source
and sends a wakeup to that source.


     An IMFT driver  requires at least two lines  of input before
it can begin  operation.  The first line is  "driver"; the second
line is one of the two major device names given in the I/O daemon
tables  for the  connection.  For   an output  driver, the  major
device name should be followed by the word "default", so that the
minor  devices  can  be   initialized  without  further  operator
intervention.


     If  the driver is  operating in manual  mode, a third  line,
either "go" or "receive", must  be sent once the driver announces
that  it is  ready after  the operator  establishes the  physical
connection.


     The format of the reply command is:

     reply SOURCE REST_OF_LINE

where SOURCE is the source to which  the input line is to be sent
and REST_OF_LINE is the input line to be sent.


Example

     sc_command reply (mitfti mitfto) driver
     sc_command reply mitfti mit_file_transfer_in
     sc_command reply mitfto mit_file_transfer_out default








                               2-51            08/88     CY73-01A









                            SECTION 3


                       OPERATOR PROCEDURES




      This  section describes  the  normal  operation of  an IMFT
connection with a remote  Multics system.  The instructions given
in this section should be performed on both the local and foreign
systems to ensure proper system operation.


     Operating procedures can vary depending on how IMFT has been
installed on  your system.  Check with  your system administrator
regarding  initialization procedures  for IMFT  specific to  your
site.


_I_N_I_T_I_A_L_I_Z_I_N_G _T_H_E _I_M_F_T _C_O_N_N_E_C_T_I_O_N

     To initialize the IMFT connection:

     1.   Login the two driver  processes for the IMFT connection
          by either issuing the appropriate operator x command if
          the  login commands  are contained  in an  ec file,  or
          issuing  the sequence  used to  login a  driver process
          described  in  "Login   and  Initialization  of  Device
          Drivers" in  the System Maintenance manual  (AM81).  In |
          brief, the commands given to each process are:

          driver
          <device_name> {default}

          where <device_name> is one of  the two device names for
          the drivers  specified in the I/O  daemon tables.  (For
          example,  the <device_name>s  from two  of the examples
          given in Section 2 of this manual are "system_m_ft_out"
          and  "mit_file_transfer_in").  If  a driver  has one or
          more minor devices (e.g.,  an output driver), the major
          device name should be followed by the word "default".

     2.   Establish  the  physical  connection  with  the  remote
          system.   If  a  hardwired   connection  is  used,  the
          connection  should be  established automatically  after


                               3-1             08/88     CY73-01A


          both systems are running.   For dial-up connections, it
          may  be necessary  to issue  the "load_mpx"  command as
          described  in the AMOC  manual (GB64) before  making or |
          receiving  the phone  call to  complete the connection.
          Check  with your  system administrators  for details on
          establishing the connection at your site.

     3.   After the drivers indicate that  they are ready, it may
          be necessary to issue a  "receive" command to the input
          driver and a "go" command to the output driver.  Again,
          check with  your system administrators to  determine if
          these commands are necessary.


_R_U_N_N_I_N_G _T_H_E _I_M_F_T _D_R_I_V_E_R _P_R_O_C_E_S_S

     Some of the  commands for an IMFT output  driver process are
different from  those used on  an IMFT input  driver process.  To
avoid  problems, we  recommend that   you use  only the  commands
suggested below for each driver.


_T_h_e _I_M_F_T _I_n_p_u_t _D_r_i_v_e_r

     The  only  I/O  daemon  commands  that  you  should use on a
regular  basis  in  an  IMFT  input  driver  process are:  logout
(described  in the System  Maintenance manual, AM81)  and receive |
(described  below).  You  may  occasionally  be requested  by the
system  administrator to  issue  one  of the  following commands:
hold, start, reinit (described in Bulk I/O).  However, unless you
receive a specific  request to do otherwise, use  only logout and
receive on the input driver.


     The output driver process is the correct place from which to
cancel  or  defer  a  running  request.   Therefore,  if  you are
operating  an input driver  and you are  asked to cancel/defer  a
request,  contact the operator  of the appropriate  output driver
and ask him to cancel/defer the request.


_T_h_e _I_M_F_T _O_u_t_p_u_t _D_r_i_v_e_r

     In  addition  to  the  commands  used  to  defer or cancel a
running  request,  the  following   commands  can  be  used  when
operating an output driver:  go, hold, logout, reinit, start, and
status.  These  commands and all of the  commands mentioned below
are fully described in the Bulk I/O manual.







                               3-2             08/88     CY73-01A




CANCELLING A RUNNING REQUEST

     A running  request is cancelled from the  output driver.  To
cancel a running request:

     1.   Press the <QUIT> or <BREAK> key.

     2.   After  the  system  prompts   you,  type  the  "cancel"
          command.

The daemon  prints a message to  the effect that the  request has
been cancelled, and then proceeds  to the next request.  Once the
initial request  has been cancelled,  the user must  resubmit the
request in order to run it again.


DEFERRING A RUNNING REQUEST

     You  must defer  a running  request from  the output  driver
site.   The two  deferral methods  are described  below.  Keep in
mind that  after a request is  deferred, when the driver  runs it
again it starts  from the beginning of the file.   If the request
you are  deferring is a  very long one,  you may want  to use the
"defer_time"  command and  run it   again at  a much  later, more
convenient time.


     When you defer  a running request, you must  tell the driver
which  request you  want it   to process  next.  By  default, the
driver begins processing the next  request in the queue.  If this
is what you want it to do, type the following commands:

     1.   Press the <QUIT> or <BREAK> key.

     2.   After  the  prompt,  type  the  "defer"  command.  This
          causes  the driver  to defer  the current  request, and
          proceed to the next request in the queue.


     If you want to defer the running request and tell the driver
to process a specific request (i.e.,  NOT the next request in the
queue), type the following set of commands:

     1.   Press the <QUIT> or <BREAK> key.

     2.   After the prompt, type the "hold" command.  This causes
          the  daemon to  stay at  command level  until you  type
          "go".





                               3-3             08/88     CY73-01A


     3.   After  the  prompt,  type  the  "defer"  command.  This
          command sends the current request  back to its queue in
          its original position, marked as "deferred".

     4.   After the  prompt, type the "next"  command, specifying
          the  following  arguments:   -user  Person_id,  -device
          to/from, and either -entry STR,  -path path, or -id ID.
          This command specifies which request  is to be run next
          by the driver.  If the request is for a file to be sent
          TO the foreign site, specify "-device to"; if it is for
          a  file  to  be  sent  FROM  the  foreign site, specify
          "-device from".   Note that you must supply  one of the
          following  three request  identifiers:  the  entryname,
          the  pathname, or  the id  number of  the request.  For
          example,  the  operator  types  this  command  line  to
          request  that  user  Ferron's   request  for  the  file
          "data.pl1", which is to be sent to the foreign site, is
          run next.

               next -device to -user Ferron -entry data.pl1

     5.   This  step  is  optional.   If  you  want  the deferred
          request to run again  right after the request specified
          in  the "next" command,  type either "restart_q  to" or
          "restart_q  from", depending   on whether  the deferred
          request  is at the  local site (to)  or at the  foreign
          site (from).

     6.   If  the system  tells you  the request  was not  found,
          check  the "next" command  line, and enter  the command
          again.  If the system tells  you the request was found,
          type the  "go" command in response to  the prompt.  The
          driver  will begin   processing the  specified request.
          When that request is  completed, the driver will select
          the  next queue  entry with  the highest  priority, and
          continue processing as usual.



















                               3-4             08/88     CY73-01A


_T_E_R_M_I_N_A_T_I_N_G _A_N _I_M_F_T _C_O_N_N_E_C_T_I_O_N

     To terminate operation of an IMFT connection:

     1.   Issue the  "logout" command to  each of the  two driver
          processes for the connection.

     2.   After the  driver processes have logged  out, terminate
          the  physical  connection  between  the  two systems by
          hanging  up the  phone.  If  a hardwired  connection is
          used,  no further  action  need  be taken.   For dialup
          connections,   it  may   be  necessary   to  issue  the
          "dump_mpx" command  as described described in  the AMOC |
          manual (GB64) before hanging  up the phone.  Check with |
          your system administrators for  details on breaking the
          physical connection at your site.







































                               3-5             08/88     CY73-01A__________                                             __________

line_speed                                             line_speed
__________                                             __________


NAME: LINE_SPEED                                                  |

      The  line_speed command  causes  an  IMFT output  driver to |
display the  current average bit  rate for transferring  files to |
the remote system.


_U_s_a_g_e                                                             |

     line_speed                                                   |


_N_o_t_e_s                                                             |

     The "go" command must be issued to resume normal operation.  |


     The  current average  transfer rate  is based  on a weighted |
average of those past requests  whose transfer times took over 30 |
seconds.  It  takes 3/4 of the  past average and adds  1/4 of the |
transfer rate of the last request.  This minimizes the dependence |
of the rate calculation on  the overhead portion of the transfers |
whose length is unknown.





























                               3-6             08/88     CY73-01A_______                                                   _______

receive                                                   receive
_______                                                   _______


NAME: RECEIVE

      The receive command causes an IMFT input driver to wait for
files  or subtrees  to be   transmitted from  the remote  Multics
system.  Messages are issued at the start and end of each file or
subtree received.


_U_s_a_g_e

     receive


_N_o_t_e_s

      If the "auto_receive=yes" parameter is specified in the I/O
daemon  tables  for  an  input   driver,  a  receive  command  is
automatically  issued when  the  driver  becomes ready.   In this
case,  the driver  is capable  of operation  without any operator
intervention.
































                               3-7             08/88     CY73-01A









                            SECTION 4


                          USER COMMANDS




     The Inter-Multics File Transfer Facility (IMFT) allows files
and subtrees to be transferred  between Multics systems.  IMFT is
queue driven,  meaning that your  requests are placed  in a queue
for later action.  IMFT supports the following user commands:

     ox    enter_imft_request (eir)
          submits an IMFT request to transfer a file to or from a
          site

     ox    list_imft_requests (lir)
          lists the  IMFT requests in the specified  queue at the
          source site or the target site

     ox    cancel_imft_request (cir)
          cancels an  IMFT request from a specified  queue at the
          source site or the target site

     ox    move_imft_request (mir)
          moves  an  IMFT  request  from  one  priority  queue to
          another at the source site or the target site

     ox    print_imft_sites
          displays the  names of foreign  sites that can  be used
          with the  -source or -destination control  arguments of
          the enter_imft_request command.


     You can request IMFT to transfer files from the system where
you are logged in (the "local" system), to some other system (the
"remote"  or "foreign"  system).  You  can also  request IMFT  to
transfer files  from the remote  system to the  local system.  In
the  following discussion,  the system  from which  the files are
transferred is called the source  system, and the system to which
they are  being transferred is  called the target  system.  (Note
that  the local  system can  be either  the source  or the target
system, depending on whether it is receiving or sending the file;
similarly,  the foreign system  can be either  the source or  the
target system.)


                               4-1             08/88     CY73-01A


_A_C_C_E_S_S _R_E_Q_U_I_R_E_M_E_N_T_S

     To transfer  a file or a  subtree from the source  system to
the target system, the conditions detailed below must be met.


     For files, the user on the  source system must have at least
explicit "r" access to the file; for subtrees, the user must have |
at least explicit "s" access to  the root of the subtree and each |
directory contained  therein and at least explicit  "r" access to |
each file in the subtree.  Explicit access means that each object |
must have  the proper ACL  term ("r" or  "s") for Person.Project. |
Effective access is not  sufficient, i.e., Person.*, *.Project or |
*.*.* will not work.


     The daemon  process on the source system  that transfers the
file or subtree  also must have the same type  of explicit access |
as described  above for the source  system's user.  Additionally, |
the  daemon also must  have at least  explicit "s" access  to the |
directory containing the file or  subtree in order to verify that
the user has  the proper access.  The identity of  the daemon can
be determined using the print_imft_sites command.


If the -delete option was used in the enter_imft_request command, |
access checking on  the source system will be  changed to require |
explicit "sma" access on the parent directory of the object to be |
deleted  for the user  (for local transfers)  or for the  foreign |
user (for remote transfers).  The daemon that will be sending the |
data also must have explicit "sma" access on the parent directory |
of the object.


     The  user on  the target   system must  have explicit  "sma" |
access to  the directory into which  the file or subtree  will be |
placed.  The  source system user  and the target  system user are
the same unless the -foreign_user control argument is specified.


     The daemon  process on the  target system that  receives the
file  or subtree  also must   have explicit  "sma" access  to the |
directory  into which  the file  or subtree  will be  placed.  In
addition, this daemon  must have at least explicit  "s" access to |
the directory containing that directory in order to validate that |
the target user has the proper access.


     If  the  -extend  or  -update   options  were  used  in  the |
enter_imft_request  command, the target  file must exist  and the |
user (for remote or pull transfers) or foreign user (for local or |
push  transfers) must  have an   explicit "rw"  ACL entry  on the |



                               4-2             08/88     CY73-01A


target file.  The  daemon on the target system also  must have an |
explicit "rw" ACL entry on the target file.


     In order for the user on the local system (LPerson.LProj) to
be able to transfer files to or from the foreign system, the user
on the foreign system (FPerson.FProj) must give her access to the
segment:

     >udd>FProj>FPerson>LSite.imft.acs

on  the foreign  system where  LSite  is  the name  of the  local
system.  If  she wants files  to be transferred  from the foreign
system,  LPerson.LProj  must  have  explicit  read  access to the |
above-named  segment.  To transfer  files to the  foreign system, |
she  needs write  access to  the segment.   (Note:  when  setting
write access on an ACS, you should set its maximum length to 0 to
prevent  it  from  acquiring  contents.   See  the set_max_length
command in the Commands manual, AG92, for details.)               |


     A  remote request  is one   which makes  use of  the -source
control argument to transfer a file from the foreign system.


     To  determine the  identity of   the daemon  on the  foreign
system and the name of the local  system used to form the name of
the ACS  segment above, use  the print_imft_sites command  on the
foreign system.


     The daemon on both systems needs  at least "s" access to the |
directory  containing the  parent directory  of the  object being |
transferred, to verify that both the daemon and the user have the |
proper explicit accesses.  In addition,  the daemon on the remote |
system needs at least "s"  access to the directory containing the |
SITE.imft.acs  segment.  This  access  need  not be  the explicit |
access required for the other access checks.                      |


     Regarding ring brackets, IMFT insures that the ring brackets
of all segments  and directories it creates on  the target system
are never less  than the write bracket on the  ACS segment of the
user  receiving the file  or subtree.  This  eliminates potential
problems if, for example, the  user operates on the source system
in  ring-4 and on  the target system  in ring-5.  When  that user
issues  a transfer request  for a segment,  IMFT will create  the
segment in ring-5 on the target system.


     An object  can be transferred  only if the  ring brackets of |
the source  is equal to or  greater than the maximum  ring of the |
user  IMFT ACS  segment or   the driver  process.  This  includes |


                               4-3             08/88     CY73-01A


extended objects.   Due to the  complexity of checking  access on |
extended  objects, the  IMFT driver   will not  initialize in  an |
execution  ring of  less than  4.  Therefore,  mailboxes, forums, |
etc., cannot be transferred.                                      |


     Assume  that user  Smith.Multics on  MIT wishes  to send the
file:

   >udd>m>Smith>test>new.pl1

to the directory:

   >udd>Guest>SmithP>imft>mit

on System-M  where his user ID is  SmithP.Guest.  Further, assume
that  the daemon  on both  systems is  IMFT.Daemon, and  that the
names of the source and target systems (given by print_imft_sites
command) are MIT and System-M respectively.


     On  MIT  (the  source   system),  Smith.Multics  issues  the
following set_acl commands to ensure  that he and the daemon have
proper access:

   set_acl >udd>m>Smith>test>new.pl1 r Smith.Multics              |
   set_acl >udd>m>Smith>test>new.pl1 r IMFT.Daemon                |
   set_acl >udd>m>Smith>test s IMFT.Daemon                        |


     Note that here, any ACL term which grants appropriate access
is   not  sufficient.    In  other    words,  an   ACL  term   on |
>udd>m>Smith>test  for  IMFT.Daemon.*,  IMFT.*.*,  *.Daemon.*, or |
even *.*.* is not sufficient to give the daemon proper access; it |
is  necessary to use  an ACL term  for IMFT.Daemon.*, as  well as |
Smith.Multics.* explicitly.


     In order to check the above  access, the daemon must have at |
least "s" access to >udd>m>Smith.  Only in this case will any ACL |
term  which grants  appropriate access  to the  daemon for  these |
checks be sufficient, i.e., IMFT.*.*  or *.Daemon.* or *.*.* will |
suffice.


     On  System-M,  SmithP.Guest  issues  the  following  set_acl |
commands to ensure proper access to receive the file:             |

     set_acl >udd>Guest>SmithP>imft>mit sma SmithP.Guest          |
     set_acl >udd>Guest>SmithP>imft>mit sma IMFT.Daemon           |
     set_acl >udd>Guest>SmithP>imft s IMFT.*                      |
     set_acl >udd>Guest>SmithP>MIT.imft.acs w Smith.Multics       |



                               4-4             08/88     CY73-01A


     Once proper access is  established, Smith.Multics issues the |
command line:

       eir >udd>m>Smith>test>new.pl1                              |
          -tpn >udd>Guest>SmithP>imft>mit>===                     |
          -fu SmithP.Guest -ds System-M                           |


     Let's assume that  the same user wants to  transfer the same
file  as a remote  request (i.e., he  wants to issue  the request
while  logged in at  System-M as SmithP.Guest.)   To do this,  he |
needs  exactly  the  same  access  as  described  above, with one |
exception.   Instead of  giving himself   "w" access  to the  ACS
segment, he must establish "r"  access with the following command
line at MIT:

     set_acl >udd>Multics>Smith>System-M.imft.acs r SmithP.Guest  |

SmithP.Guest can  now request the file transfer  with the command |
line:

     eir >udd>Multics>Smith>test>new.pl1                          |
        -tpn >udd>Guest>SmithP>imft>mit>===                       |
        -fu Smith.Multics -source MIT                             |


_N_o_t_e_s _o_n _A_I_M

     When using  AIM, files and subtrees can  be transferred only
if their  access class is less  than or equal to  (1) the process
authorization  of the user  who submits the  request and (2)  the
common access class ceiling.


COMMON ACCESS CLASS CEILING

     The  common  access  class  ceiling  between  two systems is
determined by locating the  overlapping AIM attributes within the
sensitivity  levels and access  categories specified for  the two
systems.


     The common access class ceiling is defined as:

     ox    All sensitivity levels from  level 0 (usually un-named)
          up to but  not including the first level  that does not
          have the same long and short name on both systems, and

     ox    All access categories that have the same long and short
          names on both systems.





                               4-5             08/88     CY73-01A


     If the long  and short names of sensitivity level  0 are not
the  same on both  systems, then the  two systems have  no common
access ceiling and are isolated from each other.


     For  example,   if  system  A  defines   the  following  AIM
attributes:

     level 0           *-* UN-NAMED *-*
     level 1           unclassified             u
     level 2           secret                   s
     level 3           top secret               ts

     category 1        SSTD                     sstd
     category 2        LISD                     lisd
     category 3        FSD                      (none)
     category 4        Marketing                (none)

and system B defines the following attributes:

     level 0           *-* UN-NAMED *-*
     level 1           unclassified             u
     level 2           restricted               (none)

     category 1        MPO                      (none)
     category 2        LISD                     lisd
     category 3        FSD                      fsd
     category 4        SSTD                     sstd

then the common access ceiling is:

     unclassified, LISD, SSTD


     The  sites  may  choose  to  lower  the  common access class
ceiling, so check with your  system administrator to find out the
actual common access class ceiling.


     Files and  subtrees are created  on the foreign  system with
the same access class that they had on the local system.


     When  transferring a subtree,  the daemon will  not transfer
any directory in the subtree if  its access class is greater than
that  of the  directory where  it will  be placed  on the foreign
system.   Therefore, it is  necessary to issue  separate requests
for  each such upgraded  directory, specifying a  target pathname
whose  containing directory  has the   same access  class as  the
directory being transferred.





                               4-6             08/88     CY73-01A


     For  example, if the  access class of  the directory on  the
local system is "classified, LISD" and the command line:

     eir my_directory -tpn >udd>m>ghm>receiver>===

is issued, the access  class of the directory >udd>m>ghm>receiver
on the foreign system also must be "classified, LISD".


_U_S_E_R _C_O_M_M_A_N_D_S

     With  the  following  user  commands  you  can  enter, list,
cancel, and move  IMFT requests, as well as display  the names of
IMFT sites.









































                               4-7             08/88     CY73-01A______________________                     ______________________

enter_imft_request eir                     enter_imft_request eir
______________________                     ______________________


NAME: ENTER_IMFT_REQUEST EIR

     The enter_imft_request command  submits requests to transfer
files  or subtrees to  or from remote  Multics systems using  the
Inter-Multics File Transfer (IMFT) facility.


_U_s_a_g_e

     eir transfer_specs {-control_args}

where:

1.   transfer_specs
            specify  the files or  subtree to be  transferred and
            has the following format:

     path {-target_pathname equal_path},
     path {-tpn equal_path}
            path specifies the relative  pathname of files and/or
            subtrees to  be transferred.  The star  convention is
            accepted.   If   supplied,  the  equal_path   is  the
            relative  pathname of  where the  files and  subtrees
            will  be  placed  on  the  target  system.  The equal
            convention  is  accepted.   The  target  pathname  is
            converted  to an  absolute pathname  relative to  the
            working  directory  on  the  source  system.   If not
            given,  the files  and  subtrees  are given  the same
            pathname on the target system.

2.   control_args
            may be chosen from the following:

       -absolute_pathname, -absp
            prints the  absolute pathname of the  file or subtree
            along with the request ID for each request entered by
            this command.

       -brief, -bf
            suppresses the messages providing  the request IDs of
            the requests entered by this command.

       -chase
            specifies that  transfer requests are issued  for the
            targets of any links  which match the transfer_specs.
            The   default  is   to   a)   chase  links   for  any
            transfer_specs that  do not use the  star convention,
            and b) do not chase links for any transfer_specs that
            use the star convention.



                               4-8             08/88     CY73-01A______________________                     ______________________

enter_imft_request eir                     enter_imft_request eir
______________________                     ______________________


       -date_time_after DT, -dtaf DT                              |
            skips   selected   files   and   subtrees   if  their |
            date_time_contents_modified  value is older  than the |
            time selected  by DT.  This option is  not applied to |
            contents  of   subtrees.   The  DT  string   must  be |
            acceptable to the convert_date_to_binary_ subroutine. |
            This  option  facilitates   selecting  only  modified |
            information to reduce IMFT traffic.  The -dtaf option |
            applies  only to  push transfers,  i.e., transferring |
            objects from the local system to the remote.          |

       -delete, -dl                                               |
            deletes the  source pathname immediately after  it is |
            successfully  transferred.   It   is  possible  under |
            unusual circumstances that a  file may appear to have |
            been transferred  successfully when it has  not.  The |
            source   file    will   be   deleted    under   these |
            circumstances.  Users must  use this option carefully |
            to avoid losing their only copy of the file.          |

            Objects  transferred  (files   and  directories)  are |
            deleted immediately at the completion of a successful |
            transfer.   The system  coordinator normally  deletes |
            objects  after  processing  for  a  site setable time |
            period.   However,  the  IMFT  driver  does  all  the |
            deletions and does not have this wait period.

            If  an extended  object in   a subtree  could not  be |
            transferred, the subtree will not be deleted.

       -destination STR, -ds STR
            identifies the foreign system  to which the files and
            subtrees are  to be transferred.  STR must  be one of
            the  names listed   by the  print_imft_sites command.
            The default STR is imft.  If neither -destination nor
            -source is specified, the default is -destination.

       -entryname, -etnm
            prints  only the  entry name  of the  file or subtree
            along with the request ID for each request entered by
            this command.  This is the default.

       -extend, -ext                                              |
            appends  the contents of  the source pathname  to the |
            contents'  end  of  the  target  pathname.   An error |
            occurs  if the  target  does  not already  exist.  An |
            error  occurs  if  the  source  is  a  nonfile.  This |
            control  argument is  incompatible with  the -subtree |
            option.



                               4-9             08/88     CY73-01A______________________                     ______________________

enter_imft_request eir                     enter_imft_request eir
______________________                     ______________________


       -file, -f
            specifies that transfer requests  are issued only for
            files   which  match    the  transfer_specs.    If  a
            transfer_spec  does not  use the  star convention and
            there  is  no  matching  file,  an  error  message is
            issued.   The  default  is   to  issue  requests  for
            matching files.

       -foreign_user Person.Project, -fu Person.Project
            specifies  the identity  of the  user at  the foreign
            system  for  whom  the  transfer  requests  are being
            entered.   Notifications on   the foreign  system are
            sent to  this user.  See "Access  required" below for
            further information.  The default is that the foreign
            user is the same as the local user.

       -long, -lg
            prints the messages providing  the request IDs of the
            requests  entered  by  this  command.   This  is  the
            default.

       -long_id, -lgid
            prints  the  long  form  of  the  request  ID  in any
            messages.

       -merge_directories, -mdr
            specifies that if there is  a directory on the target
            system with the same name as  one of the names on the
            root directory of the  subtree being transferred, the
            contents  of the source  subtree are merged  with the
            target  subtree.   If  the  target  entry  is  not  a
            directory,    processing    continues    as    though
            -replace_directories   had   been   specified.    Any
            directories  within  the  subtree  are  treated  in a
            similar  fashion with  respect to  name duplications.
            See "Examples" for a  description of the treatment of |
            files within the subtree.  This is the default.

       -notify, -nt
            sends  notification  of   successful  initiation  and
            completion    of   each   transfer    request.    The
            notifications  are  sent  on  the  source  and target
            systems.  This is the default.

       -no_chase
            specifies that  transfer requests are not  issued for
            the   targets   of   any   links   which   match  the
            transfer_specs.




                               4-10            08/88     CY73-01A______________________                     ______________________

enter_imft_request eir                     enter_imft_request eir
______________________                     ______________________


       -no_delete, -ndl                                           |
            does not delete files.  (Default)                     |

       -no_notify, -nnt
            suppresses  notification  of  successful  transfer on
            both    systems.    Any   errors    detected   during
            transmission will still  generate mail, regardless of
            the use of -no_notify.

       -no_skipped, -nskpd                                        |
            turns off  the display of the items  that are skipped |
            when the -date_time_after option is used.  (Default)  |

       -queue N, -q N
            specifies that  the requests are entered  in priority
            queue  N,  where  N  is  an  integer  between 1 and 4
            inclusive.  The default depends on the destination or
            source specified.

       -replace, -rpl, -rp                                        |
            replaces the entire file target file specified by the |
            target  pathname (deletes  and creates  a new  target |
            object),  rather than  modifying its  contents as  is |
            done by -extend and -update.  (Default)               |

       -replace_directories, -rpdr
            specifies  that if  there is  an entry  on the target
            system with the same name as  one of the names on the
            root directory of the subtree being transferred, that
            name is removed from the  target entry; if the target
            entry has only one name, it is deleted.

       -short_id, -shid
            prints the short form of the request ID.  This is the
            default.

       -skipped, -skpd                                            |
            turns on the display of  the objects that are skipped |
            when the -date_time_after option is used.             |

       -source STR, -sc STR
            identifies  the foreign  system from  which the files
            and subtrees are to be  transferred.  STR must be one
            of the names listed  by the print_imft_sites command.
            If neither -destination nor -source is specified, the
            default is -destination.






                               4-11            08/88     CY73-01A______________________                     ______________________

enter_imft_request eir                     enter_imft_request eir
______________________                     ______________________


       -subtree, -subt
            specifies that transfer requests  are issued only for
            subtrees  which  match   the  transfer_specs.   If  a
            transfer_spec  does not  use the  star convention and
            there  is no  matching subtree,  an error  message is
            issued.   This is  incompatible with  the -extend and
            -update control  arguments.  The default is  to issue
            requests for matching subtrees.

       -update, -ud                                               |
            replaces  the contents of  the file specified  by the |
            target  pathname with  those of  the source  pathname |
            without deleting  the target file or  changing any of |
            its attributes.   An error occurs if the  source is a |
            nonfile.  An error occurs if the target pathname does |
            not   already  exist.    This  control   argument  is |
            incompatible with the -subtree option.


_N_o_t_e_s

     If   conflicting  control   arguments  (e.g.,   -notify  and
-no_notify, or -destination and -source, or -extend, -replace and |
-update,  or  -replace_directories  and  -merge_directories)  are |
given on  the command line, the rightmost  control argument takes |
effect.


     If there is an entry on the target system with the same name
as one of  the names on the file being  transferred, that name is
removed from the  target entry; if the target entry  has only one
name, it is  deleted.  No distinction is made  here between files
specified in a transfer_spec and files contained in a subtree.


_E_x_a_m_p_l_e_s

     eir **.pl1 -tpn <x>===.new -ds MIT
          transfers  all  files  and   subtrees  in  the  working
          directory whose names end with  the pl1 suffix.  If the
          source working directory is  >udd>m>gmp>w, a file named
          "foo.pl1"   appears    on   the   target    system   as
          ">udd>m>gmp>x>foo.pl1.new".









                               4-12            08/88     CY73-01A______________________                     ______________________

enter_imft_request eir                     enter_imft_request eir
______________________                     ______________________


     eir my_subtree -ds System-M -mdr
          transfers the subtree named "my_subtree" in the working
          directory  to the  same point  in the  hierarchy on the
          target  system.  Assume  (1)  that  there is  already a
          target directory named my_subtree,  (2) that the source
          my_subtree contains two files named file1 and file2 and
          a  directory named  subdir1,  and  (3) that  the target
          my_subtree  also  contains  two  files  named file1 and
          file3.   After the  transfer is  completed, the  target
          my_subtree contains  three files (file1 and  file2 from
          the source system and file3 from the target system) and
          one directory  (subdir1 from the source  system), along
          with the contents of the source subdir1.

     eir >udd>sm>Brown.profile -tpn >udd>m>PBrown.= -source MIT
          -fu Brown.SysMaint

          from  the  local  system,  requests  a  transfer of the
          segment >udd>sm>Brown.profile from MIT on behalf of MIT
          user   Brown.SysMaint,  to   be  placed   in  the  file
          >udd>m>PBrown.profile on the local system.































                               4-13            08/88     CY73-01A______________________                     ______________________

list_imft_requests lir                     list_imft_requests lir
______________________                     ______________________


NAME: LIST_IMFT_REQUESTS LIR

     The  list_imft_requests   command  lists  requests   in  the
Inter-Multics File Transfer queues.


_U_s_a_g_e

     lir {request_identifiers} {-control_args}

where:

1.   request_identifiers
            determine  which  requests  in  the  selected  queues
            belonging to the specified  users are listed.  If not
            given,  all of  the appropriate  requests are listed.
            See "Notes on request identifiers" below.

            List of request_identifiers:

            path
                 lists all  requests from the  appropriate queues
                 and  users  whose  source  pathnames  match  the
                 relative pathname path.   The star convention is
                 allowed.

            -entry STR, -et STR
                 lists all  requests from the  appropriate queues
                 and  users whose  source entry  names match STR;
                 the directory  portions of the  source pathnames
                 are ignored.  The star convention is allowed.

            -id STR
                 lists all  requests from the  appropriate queues
                 and users whose request IDs match the STR.  Type
                 "help request_ids.gi"  for a description  of the
                 syntax of STR.

2.   control_args
            may be chosen from the following:

       -absolute_pathname, -absp
            displays the absolute pathname of the file or subtree
            associated with each request.  This is the default if
            -long is used.
       -admin, -am
            lists the matching requests submitted by any user.





                               4-14            08/88     CY73-01A______________________                     ______________________

list_imft_requests lir                     list_imft_requests lir
______________________                     ______________________


       -all, -a
            lists requests entered in all priority queues for the
            above destination.

       -brief, -bf
            displays   minimal  information   for  each   request
            including  its  request   ID,  source  pathname,  and
            current state.  This is the default.

       -destination STR, -ds STR
            lists  requests that are  queued for transfer  to the
            foreign system identified by STR.  STR must be one of
            the  names listed   by the  print_imft_sites command.
            (The default  STR is imft.)  If  neither -destination
            nor   -source   is    specified,   the   default   is
            -destination.

       -entryname, -etnm
            displays only the entry name  of the file or subtree.
            This is the default if -long is not used.

       -long, -lg
            displays all information available for each request.

       -long_id, -lgid
            displays  the complete  request ID  for each request.
            This is the default if -long is used.

       -no_position, -npsn
            does not display the  queue position of each request.
            This is the default.

       -own
            lists a matching request only  if it was submitted by
            the user of this command.  This is the default.

       -position, -psn
            displays  the  position  within  the  queue  of  each
            request.

       -queue N, -q N
            lists requests  entered in priority queue  N, where N
            is an integer between 1 and 4 inclusive.  The default
            depends on the destination or source specified.

       -short_id, -shid
            displays the  short form of  the request ID  for each
            request.  This is the default if -long is not used.




                               4-15            08/88     CY73-01A______________________                     ______________________

list_imft_requests lir                     list_imft_requests lir
______________________                     ______________________


       -source STR, -sc STR
            identifies  the foreign  system from  which the files
            and subtrees are to be  transferred.  STR must one of
            the names listed by the print_imft_sites command.  If
            neither  -destination nor  -source is  specified, the
            default is -destination.

       -total, -tt
            displays only  the total number of  matching requests
            in each queue.

       -user STR
            lists a matching request only  if it was submitted by
            the user identified by STR.  STR must have one of the
            following forms:

            Person.Project
                 lists  only those  matching requests  entered by
                 the  specified  user  while  logged  in  on  the
                 specified project.

            Person.*, Person
                 lists  only those  matching requests  entered by
                 the  specified  user  while  logged  in  on  any
                 project.

            *.Project, .Project
                 lists  only those  matching requests  entered by
                 any user logged in on the specified project.

            *.*, *
                 lists  all matching  requests regardless  of who
                 entered them.

Access required:  If -position, -admin, or -user is specified, at
least "r"  extended access is required to  the queues; otherwise,
at least "o" extended access is required.

Notes  on request  identifiers:  If  path or  -entry STR  request
identifiers are given, only one -id STR request identifier may be
given.  Further, only those requests  which match one of the path
or -entry STR identifiers and  which match the -id STR identifier
are listed.


_N_o_t_e_s

     If   conflicting   control   arguments   (e.g.,   -position,
-no_position)  are  given  on  the  command  line,  the rightmost
control argument takes effect.


                               4-16            08/88     CY73-01A______________________                     ______________________

list_imft_requests lir                     list_imft_requests lir
______________________                     ______________________


_E_x_a_m_p_l_e_s

     Assume that you have "r"  extended access to the queues, and
that the  following files are  in imft queue  2.  Further, assume
that queue 2 is the default queue.

     User                         ID        Entry name
     Carey.System-M               140628.3  mtape.pl1
     Poole.ProjA                  163146.3  mcr.packet.j31
     Randolph.System-M            160200.7  jm_write.pl1

     User Poole.ProjA  enters the following command,  which lists
each request submitted by him:

     lir

This command line gives the following results:

     imft queue 2:     1 request; 3 total requests.

       163146.3  mcr.packet.j31


     The following  command line lists the  requests submitted by
any user, and specifies the queue position of each request.

     lir -admin

This command line evokes the following response:

     imft queue 2:     3 requests; 3 total requests.

     User                         ID        Entry name
     Carey.System-M           1)  140628.3  mtape.pl1
     Poole.ProjA              2)  163146.3  mcr.packet.j31
     Randolph.System-M        3)  160200.7  jm_write.pl1
















                               4-17            08/88     CY73-01A______________________                     ______________________

list_imft_requests lir                     list_imft_requests lir
______________________                     ______________________


     The  following command  line lists  any request  whose entry
name  ends  with  the  pl1  suffix,  regardless  of  who made the
request:

     lir -user *.* -et *.pl1

This command line generates the following response:

     imft queue 2:     2 requests; 3 total requests.

     User                         ID        Entry name
     Carey.System-M               140628.3  mtape.pl1
     Randolph.System-M            160200.7  jm_write.pl1







































                               4-18            08/88     CY73-01A_______________________                   _______________________

cancel_imft_request cir                   cancel_imft_request cir
_______________________                   _______________________


NAME: CANCEL_IMFT_REQUEST CIR




     The  cancel_imft_request  command  cancels  requests  in the
Inter-Multics File Transfer queues.


_U_s_a_g_e

     cir request_identifiers {-control_args}

where:

1.   request_identifiers
            determine  which  requests  in  the  selected  queues
            belonging to the specified  users are cancelled.  See
            "Notes on request identifiers" below.

            List of request_identifiers:

            path
                 cancels all requests from the appropriate queues
                 and  users  whose   local  pathnames  match  the
                 relative pathname path.   The star convention is
                 allowed.

            -entry STR, -et STR
                 cancels all requests from the appropriate queues
                 and users whose local entry names match STR; the
                 directory  portions of  the local  pathnames are
                 ignored.  The star convention is allowed.

            -id STR
                 cancels all requests from the appropriate queues
                 and users whose request IDs match the STR.  Type
                 "help request_ids.gi"  for a description  of the
                 syntax of STR.

2.   control_args
            may be chosen from the following:

       -all, -a
            cancels requests  entered in all priority  queues for
            the above destination.






                               4-19            08/88     CY73-01A_______________________                   _______________________

cancel_imft_request cir                   cancel_imft_request cir
_______________________                   _______________________


       -destination STR, -ds STR
            cancels requests that are  queued for transfer to the
            remote system identified by STR.  (The default STR is
            imft.)  STR  must be one  of the names  listed by the
            print_imft_sites  command.   If  neither -destination
            nor   -source   is    specified,   the   default   is
            -destination.

       -own
            cancels a  matching request only if  it was submitted
            by the user of this command.  This is the default.

       -queue N, -q N
            cancels requests entered in priority queue N, where N
            is an integer between 1 and 4 inclusive.  The default
            depends on the source or destination specified.

       -source STR, -sc STR
            cancels   requests  for  transferring   files  and/or
            subtrees  from the  remote system  identified by STR.
            STR   must   one   of   the   names   listed  by  the
            print_imft_sites  command.   If  neither -destination
            nor   -source   is    specified,   the   default   is
            -destination.

       -user STR
            cancels a  matching request only if  it was submitted
            by the user identified by  STR.  STR must have one of
            the following forms:

            Person.Project
                 cancels only those  matching requests entered by
                 the  specified  user  while  logged  in  on  the
                 specified project.

            Person.*, Person
                 cancels only those  matching requests entered by
                 the  specified  user  while  logged  in  on  any
                 project.

            *.Project, .Project
                 cancels only those  matching requests entered by
                 any user logged in on the specified project.

            *.*, *
                 cancels all matching  requests regardless of who
                 entered them.





                               4-20            08/88     CY73-01A_______________________                   _______________________

cancel_imft_request cir                   cancel_imft_request cir
_______________________                   _______________________


Access required:   If -user is specified, at  least "rd" extended
access  is  required  to  the  queues;  otherwise,  at  least "o"
extended access is required.

Notes  on request  identifiers:  If  path or  -entry STR  request
identifiers are given, only one -id STR request identifier may be
given.  In this  case only those requests which match  one of the
path  or  -entry  STR  identifiers  and  which  match the -id STR
identifier are listed.


_N_o_t_e_s

     If conflicting control arguments  (e.g., -queue 2, -queue 3)
are  given on  the command  line, the  rightmost control argument
takes effect.


_E_x_a_m_p_l_e_s

     Assume that you have "o" access to the imft queues, and that
you have transfer requests for the following files in queue 2:

     s5.mrg.compin
     s7.mrg.compin
     stm.pl1

and a transfer request for P226.packet in queue 3.


     The following command  cancels a request in any  queue for a
file ending with the suffix "packet".

     cir *.packet -all

It evokes this response:

     IMFT request P226.packet cancelled from queue 3.
     r 10:03 0.231 2


     The following command cancels each file in the default queue
that has an entry name ending in the suffix compin:

     cir -et **.compin

The system gives you the following response:

     IMFT request s5.mrg.compin cancelled.
     IMFT request s7.mrg.compin cancelled.


                               4-21            08/88     CY73-01A_____________________                       _____________________

move_imft_request mir                       move_imft_request mir
_____________________                       _____________________


NAME: MOVE_IMFT_REQUEST MIR

     The  move_imft_request  command   moves  requests  from  one
Inter-Multics  File Transfer (IMFT)  queue to another.   The move
can  be between  queues of   the same  remote system,  or between
queues of different remote systems.   When a request is moved, it
is always placed at the end of the "new" queue.


_U_s_a_g_e

    mir request_identifiers -control_args

where:

1.   request_identifiers
            determine  which  requests  in  the  selected  queues
            belonging  to  the  specified  users  are moved.  See
            "Notes on request identifiers" below.

            List of request_identifiers:

            path
                 moves all  requests from the  appropriate queues
                 and  users  whose  source  pathnames  match  the
                 relative pathname path.   The star convention is
                 allowed.

            -entry STR, -et STR
                 moves all  requests from the  appropriate queues
                 and  users whose  source entry  names match STR;
                 the directory  portions of the  source pathnames
                 are ignored.  The star convention is allowed.

            -id STR
                 moves all  requests from the  appropriate queues
                 and users whose request IDs match the STR.  Type
                 "help request_ids.gi"  for a description  of the
                 syntax of STR.

2.   control_args
            may be chosen from the following:

       -destination STR, -ds STR
            moves  requests that are  queued for transfer  to the
            foreign system  identified by STR.  (The  default STR
            is imft.)  STR must be one of the names listed by the
            print_imft_sites  command.   If  neither -destination
            nor   -source   is    specified,   the   default   is
            -destination.


                               4-22            08/88     CY73-01A_____________________                       _____________________

move_imft_request mir                       move_imft_request mir
_____________________                       _____________________


       -source STR, -sc STR
            identifies  the foreign  system from  which the files
            and subtrees are to be  transferred.  STR must one of
            the names listed by the print_imft_sites command.  If
            neither  -destination nor  -source is  specified, the
            default is -destination.

       -queue N, -q N
            moves  requests entered in  priority queue N  for the
            above  destination or  source where  N is  an integer
            between  1 and 4  inclusive.  The default  depends on
            the destination specified.

       -all, -a
            moves requests entered in all priority queues for the
            above destination or source.   If the move is between
            queues of  the same foreign system,  the target queue
            is not searched.

       -brief, -bf
            suppresses   messages  that    either  tell   that  a
            particular  request  identifier  did  not  match  any
            requests, or provide the new  request ID of the moved
            request.

       -long, -lg
            displays the above messages.

       -to_destination STR, -tods STR
            specifies that  the requests are moved  to the queues
            of the target system  identified by STR.  The default
            is that  requests are moved within the  queues of the
            target system given by the -ds STR control argument.

       -to_source STR, -tosc STR
            specifies  that the requests  should be moved  to the
            input queues of the  remote system identified by STR.
            This  control  argument  cannot  be  specified unless
            -source is also specified.   By default, requests are
            moved within the queues of the remote system given by
            the -sc STR control argument.

       -to_queue N, -tq N
            specifies  that the  requests are  moved to  priority
            queue N of the target or source system, where N is an
            integer between 1 and 4 inclusive.  The default value
            of  N is the  default queue of  the target or  source
            system.




                               4-23            08/88     CY73-01A_____________________                       _____________________

move_imft_request mir                       move_imft_request mir
_____________________                       _____________________


       -own
            moves a matching request only  if it was submitted by
            the user of this command.  This is the default.

       -user STR
            moves a matching request only  if it was submitted by
            the user identified by STR.  STR must have one of the
            following forms:

            Person.Project
                 moves  only those  matching requests  entered by
                 the  specified  user  while  logged  in  on  the
                 specified project.

            Person.*, Person
                 moves  only those  matching requests  entered by
                 the  specified  user  while  logged  in  on  any
                 project.

            *.Project, .Project
                 moves  only those  matching requests  entered by
                 any user logged in on the specified project.

            *.*, *
                 moves  all matching  requests regardless  of who
                 entered them.

Access required:  The user must have at least "a" extended access
to  the target queue.   If -own (the  default) is specified,  the
user must have at least "o" extended access to the source queues.
If -user is specified, the user  must have at least "rd" extended
access to the source queues  and access to the queue_admin_ gate.
If the user has AIM ring one privilege, the AIM attributes of the
original submitter  are preserved; otherwise, the  AIM attributes
of the current process are used.

Notes   on  request   identifiers:   Multiple   -id  STR  request
identifiers may be specified on the  command line only if no path
or -entry STR identifiers are given.

If path or -entry STR request identifiers are given, only one -id
STR  request identifier  may be  given in  which case  only those
requests which  match one of  the path or  -entry STR identifiers
and which match the -id STR identifier are moved.








                               4-24            08/88     CY73-01A_____________________                       _____________________

move_imft_request mir                       move_imft_request mir
_____________________                       _____________________


If a path or -entry STR  request identifier matches more than one
request and is  not a starname, a message is  printed telling how
many matching  requests were found  but none of  the requests are
moved.   The -id STR  request identifier may  be used to  further
qualify the path or -entry  STR identifier to select the specific
request to be moved.


_N_o_t_e_s

     If  the request is  already being transferred,  this command
prints an explanatory message and does not move the request.


     If conflicting  control arguments (e.g., -long,  -brief) are
given on  the command line, the rightmost  control argument takes
effect.


_E_x_a_m_p_l_e_s

     The following examples show three  different uses of the mir
command, and the responses they  generate.  Assume that the files
s2.compin, s3.compin,  s4.compin, and s5.compin are  in CISL IMFT
queue 2, and s4.compin is already running.


    mir s2.compin -tq 3
    IMFT request s2.compin moved from imft queue 2; ID: 16055.1.
    1 request moved; 0 already in imft queue 3.
    r:11:04 0.368 1


    mir s3.compin -tq 1 -bf
    r:11:06 0.467 9


    mir -et *.compin -tq 3
    move_imft_request: IMFT request s4.compin is already running
      and will not be moved.
    IMFT request s5.compin moved from imft queue 2; ID: 160212.9.
    1 request moved; 1 already in imft queue 3.
    r:11:09 0.347 8









                               4-25            08/88     CY73-01A________________                                 ________________

print_imft_sites                                 print_imft_sites
________________                                 ________________


NAME: PRINT_IMFT_SITES

     The print_imft_sites  command displays the names  of foreign
sites that can  be used with the -source  or -destination control
arguments of the enter_imft_request command.


_U_s_a_g_e

     print_imft_sites


_E_x_a_m_p_l_e

     A user  is at a  site that has  IMFT connections to  MIT and
CISL.   He  types  the  print_imft_sites  command,  and  gets the
following response:


     Site name            Access ID           Dest     Source

     CISL                 IMFT.Daemon.*         X        X
     MIT (default)        IMFT.Daemon.*         X        X





























                               4-26            08/88     CY73-01A
