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 | <> | 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: ; The describes the characteristics of the REMOTE system. For IMFT, the 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: ; 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: ; The 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 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: ; 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: ; 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: ; IMFT requires the to be "multiplexer" for the HASP multiplexed channel. multiplexer_type: , ; The 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: ; Specifies the baud rate of the channel. The 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: ; For IMFT, the must be "BSC". 2-6 08/88 CY73-01A terminal_type: ; For IMFT, the 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 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: ; 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: ; 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: ; For IMFT, the 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: | 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: - ; 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: ; The 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: ; For IMFT, the 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: | 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: - ; 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: ; The 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: ; For IMFT, the 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: | 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: ; 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: ; IMFT requires the to be "multiplexer" for the X.25 multiplexed channel. multiplexer_type: , ; The 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: ; Specifies the baud rate of the channel. The 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: ; For IMFT, the must be "X25LAP". terminal_type: ; The 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 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: ; | 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: ; | The 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: | 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: ; 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: ; The 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: | 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: ; 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: ; The 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: | 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: ; | 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: ; | The must be "login", designating that | the subchannel can be used for normal logins. | baud: ; | Specifies the baud rate of the channel. The | 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: | 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: ; | 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: ; | The must be "autocall", designating | that the channel can be used for placing calls to | other modems. baud: ; | Specifies the baud rate of the channel. The | 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: | 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 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: ; 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 can be chosen; it can be a maximum of 24 characters and cannot contain periods or spaces. driver_module: ; For IMFT, must be "imft_driver_". line: ; For IMFT, must be "*". args: ; Defines the characteristics of this device. 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= Specifies whether this is an input or output driver. must be either "input" or "output". 2-29 08/88 CY73-01A local_system= 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= 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= ids= 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= ods= 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= iods= 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= | 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. 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= Specifies whether this driver is to operate with or without operator intervention. 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= 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. 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= 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. 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= Specifies whether or not an input driver accepts requests from the remote system for the transfer of files from the local system. 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= 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= 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= = 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= Specifies a segment or archive component containing the keyword/value pairs for this device. 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= | Specifies whether the driver process is to operate in | debug mode. 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= | 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. 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= | Specifies that the driver should not attempt to | validate the system identifiers in the PNT to | establish and validate the connection. 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= | Specifies whether the driver is to emit the text | received from the distant system to the driver log. | 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: ; 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. 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: ; 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. must be the same as the Person_id of the foreign system, prefaced by either "From_" or "To_" (e.g., From_System_M). 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: ; 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. must be the 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: ; IMFT requires the generic type to be: imft. driver_userid: ; Must identify the user selected above to run this connection. default_queue: ; The default_queue substatement is used to define the default queue for a request type. The value of 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: ; IMFT requires 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: ; 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 {default} where is one of the two device names for the drivers specified in the I/O daemon tables. (For example, the 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 or 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 or 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 or 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 ===.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 ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved