  
  MULTICS TECHNICAL BULLETIN                                 MTB765
  
  
  To:       MTB Distribution
  
  From:     Mary Crawford
  
  Date:     08/07/87
  
  Subject:  Multics DSA Network Administration Guide
  
                 -----------------------------------
  
  This  MTB describes  the DSA   Network software  for the  Multics
  System.  As mentioned  in a cover page there  are several changes
  that  need to  be implemented   before publishing  this mtb  as a
  manual.
  
                 -----------------------------------
  
  Comments on this MTB should be directed by Multics mail to:
  
      System M:  GDixon.Multics
  
  or by phone to:
  
      Gary Dixon
      HVN:  862-3593
      DDD:  602-862-3593
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  _________________________________________________________________
  
  Multics project  internal documentation; not to  be reproduced or
  distributed outside the Multics project without permission of the
  Director of MDC.
                                  1
  
  
  
  
  
  
  
  
  
                       _P_R_O_B_L_E_M_S _W_I_T_H _T_H_E _M_A_N_U_A_L
  
  
  
  
  
  
       If  this manual  is to  be published  at a  future date  the
  following changes should be made:
  
  1.  In section  1, page 6 under "Common  exchange Interface (CXI)
      Protocol and  DN8/7100 Control" change all  DN8 references to
      DN7.
  
  2.  In section  2, page 8  command descriptions should  not be in
      section entitled "Start-up of DSA" but should be in their own
      section.  These commands are located in several places in the
      manual.
  
  3.  In section 2, page 10,11  the paragraph starting with "Listed
      below are the steps to follow to complete......"  ending with
      "10.   Log in the  other DSA daemons."   is an overview  that
      should be at the beginning of the section.
  
  4.  In  section  2,  page  19  under  "Loading  and  Executing  a
      Generator Image",  the admin_dsa.ec does all  of this.  There
      needs  to be  documentation for  this.  Looks  like it  is in
      Section 9.
  
  5.  In  section  7,  page  16  under  "Changes  to  the ttt_info_
      subroutine" states that "The  following new entry point....";
      however,  the entry  point is  located on  page 7-20  "Entry:
      ttt_info_$dsatm_device".
  
  6.  In section 7, page 22 under "Using EMACS" the video system is
      automatically  invoked  if  not  already  activated when user
      enters Emacs.  This section needs  to be reworked in light of
      this.   Without  invoking  video,  there  is  some video like
      functionality.
  
  7.  In section 8, page 3 under "Process Manipulation Commands" in
      the sentence that reads "....commands permits the operator to
      specify..."   it should  possibly be  initializer instead  of
      operator.
  
  
  
  
                                  1
  
  
  8.  In section  9, page 11  under "Arguments" beginning  with the
      sentence "Lines to add at  the end of admin.ec in order....",
      and including the rest of section  9 seems to be in the wrong
      place to talk about installing DSA which is supposed to be in
      section 2.
  
  9.  In Appendix A there should be some notation that This section
      only applies to the French Installations as some ec's are not
      on our system.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                  2
  
  
  
  
  
  
  
  
  
                               PREFACE
  
  
  
  
       This  manual  is  for  Multics  network administrators.  Its
  purpose is to provide them  with the reference material they need
  to startup DSA  on Multics and to administer a  Multics node of a
  DSA network.
  
  
       This manual offers the following:
  
       ox    An overview of DSA on Multics
  
       ox    Step-by-step  instructions  for   starting  DSA  up  on
            Multics
  
       ox    Descriptions of the major  components of DSA on Multics
            (the  login server  subsystem, the  network information
            table, the CXI subsystem, the various DSAC subsystems)
  
       ox    Explanations  of  how  the  user  environment  and  the
            operator environment  are different under DSA  from how
            they are under MCS
  
       ox    Detailed descriptions of DSA-related commands
  
  
       Other Honeywell manuals which may  be of interest to Multics
  network administrators are listed below.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Copyright (c) Honeywell Bull Inc., 1986            File No.: 1L63
  
  
  
  
       Order
       Number       Title
  
       DP43         _D_N_S _S_y_s_t_e_m _I_n_s_t_a_l_l_a_t_i_o_n _a_n_d _G_e_n_e_r_a_t_i_o_n
       DP42         _D_N_S _S_y_s_t_e_m _O_p_e_r_a_t_i_o_n_s
       DM23         _D_N_S _T_e_r_m_i_n_a_l _U_s_e_r_'_s _G_u_i_d_e
       DS58         _I_n_l_i_n_e_/_O_n_l_i_n_e  _T_e_s_t  _a_n_d  _V_e_r_i_f_i_c_a_t_i_o_n  _P_a_c_k_a_g_e
                    _U_s_e_r_'_s _G_u_i_d_e
       DP31         _I_n_l_i_n_e_/_O_n_l_i_n_e  _T_e_s_t  _a_n_d  _V_e_r_i_f_i_c_a_t_i_o_n  _P_a_c_k_a_g_e
                    _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l
       DV47         _D_S_A  _S_o_f_t_w_a_r_e_,   _D_o_c_u_m_e_n_t_a_t_i_o_n_,  _a_n_d  _E_d_u_c_a_t_i_o_n
                    _D_i_r_e_c_t_o_r_y
  
  
       Bull  manuals which  may be  of interest  to Multics network
  administrators are listed below.
  
  
       Reference
       Number       Title
  
       39 A2 9807   _D_N_S _S_y_s_t_e_m _G_e_n_e_r_a_t_i_o_n
       39 A2 9799   _D_N_S _S_y_s_t_e_m _O_p_e_r_a_t_i_o_n_s
       39 A2 9820   _D_N_S _T_e_r_m_i_n_a_l _M_a_n_a_g_e_m_e_n_t _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l
       39 A2 00DM   _D_N_S _I_n_/_O_n _L_i_n_e _T_e_s_t _O_p_e_r_a_t_o_r_'_s _G_u_i_d_e
       39 A2 26DM   _D_S_A _N_e_t_w_o_r_k _S_y_s_t_e_m _M_e_s_s_a_g_e_s _a_n_d _R_e_t_u_r_n _C_o_d_e_s
       39 A4 9798   _D_N_S _D_o_c_u_m_e_n_t_a_t_i_o_n _D_i_r_e_c_t_o_r_y
       30 A4 9726   _D_S_A _D_o_c_u_m_e_n_t_a_t_i_o_n _D_i_r_e_c_t_o_r_y
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Copyright (c) Honeywell Bull Inc., 1986            File No.: 1L63
  
  
  
  
  
  
  
  
  
  
                               CONTENTS
  
  
                                                           Page
  
  Section 1     Introduction  . . . . . . . . . . . . . .   1-1
                   Differences Between MCS and MCA  . . .   1-2
                   Extensions to the Multics System . . .   1-2
                      Multics Networking Architecture . .   1-2
                      Changes to the Answering Service  .   1-3
                      Changes to the Hardcore . . . . . .   1-4
                      Changes to System Exec_Coms . . . .   1-4
                   DSA Specific Software  . . . . . . . .   1-4
                      Network Information Table (NIT) . .   1-4
                      Common eXchange Interface (CXI)
                       Protocol and DN8/7100 Control  . .   1-4
                      Session Control . . . . . . . . . .   1-5
                      Transport Control . . . . . . . . .   1-5
                      Terminal Management (TM)  . . . . .   1-5
                      Unified File Transfer (UFT) . . . .   1-6
                      Distributed System Administration
                       and Control (DSAC) . . . . . . . .   1-6
                         DSA_DSAC.Daemon  . . . . . . . .   1-7
                            ASF LOG Function  . . . . . .   1-7
                            NAD Function  . . . . . . . .   1-7
                            ASF Function  . . . . . . . .   1-7
                         The dssr Subsystem . . . . . . .   1-8
                            Remote NOI Access Function  .   1-8
                            Remote NAD Access Function  .   1-8
                            Session Exerciser Function  .   1-8
                      Datanet 8 (DN8/7100) and
                       Distributed Network Supervisor
                       (DNS)  . . . . . . . . . . . . . .   1-8
                         Files That are Unloaded from the
                          Delivery Tape . . . . . . . . .   1-9
                         Files That Must Be Built . . . .   1-9
                         Files That Are Generated . . . .   1-9
                         DN8/7100 Tests and Diagnostics
                          (T&D) . . . . . . . . . . . . .  1-10
  
  Section 2     Starting Up DSA on Multics  . . . . . . .   2-1
                   Tailoring the Multics Environment for
                    DSA . . . . . . . . . . . . . . . . .   2-1
                      Editing the Multics Config Deck . .   2-2
                      Creating New Access Control
                       Segments . . . . . . . . . . . . .   2-2
  
  
  
                                 iii
  
                           CONTENTS (cont)
  
  
                                                           Page
  
                      Updating the installation_parms
                       Segment  . . . . . . . . . . . . .   2-3
                      Changing the TTF  . . . . . . . . .   2-3
                      Setting ACLs on the DSA Logs  . . .   2-3
                       Registering the New DSA Daemons  .   2-4
                      Building a Multics DSA Hierarchy  .   2-5
                      dsa_fep_working_dir (dsafwd)  . . .   2-8
                   Building the Network Information Table   2-9
                   Building a DN8/7100 DIR 'sys>' . . . .   2-9
                   Managing DN8/7100 Generation and Run
                    Operations  . . . . . . . . . . . . .  2-10
                      Loading the DNS Software onto
                       Multics  . . . . . . . . . . . . .  2-11
                      Converting GCOS Files to Multics
                       Format . . . . . . . . . . . . . .  2-11
                      dsa_cv_dns_tape (dsacvt)  . . . . .  2-12
                      Creating the CXI Driver Segment . .  2-15
                      cxi_create_driver_seg . . . . . . .  2-16
                      Starting Session Control  . . . . .  2-17
                      dsa_init  . . . . . . . . . . . . .  2-18
                      Logging in the CXI Input Daemons  .  2-19
                      Starting the CXI Subsystem  . . . .  2-19
                      Loading and Executing a Generator
                       Image  . . . . . . . . . . . . . .  2-19
                      Loading, Executing, and Starting a
                       Runnable Image . . . . . . . . . .  2-20
                      Starting the CXI Driver . . . . . .  2-20
                      Logging in the Other DSA Daemons  .  2-20
  
  Section 3     Network Login Server  . . . . . . . . . .   3-1
                   Registering the Login Server Daemon  .   3-2
                   Starting the Login Server Request
                    Mechanism . . . . . . . . . . . . . .   3-2
                      ls_request_server . . . . . . . . .   3-3
                   Logging in the Login Server Daemon . .   3-4
                      login, (l)  . . . . . . . . . . . .   3-4
                   Controlling the Login Server Daemon  .   3-5
                   Network Login Server Requests  . . . .   3-6
                      self_identify . . . . . . . . . . .   3-6
                      help  . . . . . . . . . . . . . . .   3-6
                      list_help, (lh) . . . . . . . . . .   3-7
                      list_endpoints, (lsep)  . . . . . .   3-8
                      list_requests, (lr) . . . . . . . .   3-8
                      quit, (q) . . . . . . . . . . . . .   3-9
                      start_login_service . . . . . . . .  3-10
                      stop_login_service  . . . . . . . .  3-10
  
  Section 4     Network Information Table . . . . . . . .   4-1
                   The Purpose of the NIT . . . . . . . .   4-1
  
  
                                  iv
  
                           CONTENTS (cont)
  
  
                                                           Page
  
                   Building a NIT . . . . . . . . . . . .   4-2
                   NIT Source Language  . . . . . . . . .   4-2
                      NIT Source Language Syntax  . . . .   4-3
                   NIT Object Definitions . . . . . . . .   4-4
                      Mna_general_info  . . . . . . . . .   4-6
                         Syntax . . . . . . . . . . . . .   4-6
                         Example  . . . . . . . . . . . .   4-8
                      Service . . . . . . . . . . . . . .   4-9
                         Syntax . . . . . . . . . . . . .   4-9
                         Example  . . . . . . . . . . . .  4-11
                      Session_type_descriptor . . . . . .  4-12
                         Syntax . . . . . . . . . . . . .  4-12
                         Example  . . . . . . . . . . . .  4-15
                      Sc_loc  . . . . . . . . . . . . . .  4-16
                         Syntax . . . . . . . . . . . . .  4-16
                         Example  . . . . . . . . . . . .  4-20
                      Mailbox . . . . . . . . . . . . . .  4-21
                         Syntax . . . . . . . . . . . . .  4-21
                         Example  . . . . . . . . . . . .  4-23
                      Dsac_info . . . . . . . . . . . . .  4-24
                         Syntax . . . . . . . . . . . . .  4-24
                         Example  . . . . . . . . . . . .  4-25
                      Admin_function  . . . . . . . . . .  4-26
                         Syntax . . . . . . . . . . . . .  4-26
                         Example  . . . . . . . . . . . .  4-28
                      Admin_group . . . . . . . . . . . .  4-29
                         Syntax . . . . . . . . . . . . .  4-29
                         Example  . . . . . . . . . . . .  4-30
                      Ts  . . . . . . . . . . . . . . . .  4-31
                         Syntax . . . . . . . . . . . . .  4-31
                         Example  . . . . . . . . . . . .  4-31
                      Frontend  . . . . . . . . . . . . .  4-32
                         Syntax . . . . . . . . . . . . .  4-32
                         Example  . . . . . . . . . . . .  4-34
                      Session_Route . . . . . . . . . . .  4-35
                         Syntax . . . . . . . . . . . . .  4-35
                         Example  . . . . . . . . . . . .  4-35
                      System  . . . . . . . . . . . . . .  4-36
                         Syntax . . . . . . . . . . . . .  4-36
                         Example  . . . . . . . . . . . .  4-38
                      Correspondent . . . . . . . . . . .  4-39
                         Syntax . . . . . . . . . . . . .  4-39
                         Example  . . . . . . . . . . . .  4-41
                      Admin_correspondent . . . . . . . .  4-42
                         Syntax . . . . . . . . . . . . .  4-42
                         Example  . . . . . . . . . . . .  4-44
                   DSA NIT Source Table Example . . . . .  4-45
                   Compiling a NIT  . . . . . . . . . . .  4-70
                      dsa_cv_nif  . . . . . . . . . . . .  4-71
  
  
                                  v
  
                           CONTENTS (cont)
  
  
                                                           Page
  
                   Installing a NIT . . . . . . . . . . .  4-73
                   Updating a NIT . . . . . . . . . . . .  4-73
  
  Section 5     Common Exchange Interface (CXI) Subsystem   5-1
                      cxi_input_daemon (cid)  . . . . . .   5-2
  
  Section 6     Distributed System Administration and
                 Control  . . . . . . . . . . . . . . . .   6-1
                   The DSA_DSAC Daemon  . . . . . . . . .   6-1
                      Logging In and Initializing the
                       DSA_DSAC Daemon  . . . . . . . . .   6-2
                      Logging Out the DSA_DSAC Daemon . .   6-2
                      run_dsac_daemon_init (rdd_init) . .   6-3
                      run_dsac_daemon (rdd) . . . . . . .   6-4
                      start_admin_function, (start_af)  .   6-8
                      stop_admin_function, (stop_af)  . .   6-9
                   Administrative Interface to Session
                    Control . . . . . . . . . . . . . . .  6-11
                      Multics-Specific Session Control
                       Administration . . . . . . . . . .  6-11
                      dsa_scc . . . . . . . . . . . . . .  6-12
                      Display of DSA Objects on Multics .  6-29
                      dsa_dsac  . . . . . . . . . . . . .  6-30
                   The dssr Subsystem . . . . . . . . . .  6-37
                      The Basic Network Session Exerciser  6-37
                      Remote NOI/NAD Access Facility  . .  6-38
                      dsa_ssu_root (dssr) . . . . . . . .  6-40
  
  Section 7     Changes And New Features That Affect
                 Users  . . . . . . . . . . . . . . . . .   7-1
                   Connecting to Multics from a Remote
                    Terminal  . . . . . . . . . . . . . .   7-1
                      Sample Login/Logout Session . . . .   7-4
                   Changes to the tty_ I/O Module . . . .   7-6
                      New Control Orders  . . . . . . . .   7-6
                      Control Orders That Cannot Be Used    7-7
                   Changes to the set_tty Command . . . .   7-8
                      New Control Arguments . . . . . . .   7-8
                      Control Arguments That Can Not Be
                       Used . . . . . . . . . . . . . . .   7-9
                      Changes to the -ttp Control
                       Argument . . . . . . . . . . . . .   7-9
                      New and Changed Mode Specifications   7-9
                   Changes to the Terminal Type File  . .  7-11
                   Changes to the ttt_info_ Subroutine  .  7-16
                      dsatm_parameters (tmparm) . . . . .  7-16
                      ttt_info_$dsatm_device  . . . . . .  7-20
                      display_connection_list . . . . . .  7-23
  
  
  
                                  vi
  
                           CONTENTS (cont)
  
  
                                                           Page
  
  Section 8     Changes that Affect Operators . . . . . .   8-1
                   Changes to the login Command . . . . .   8-1
                   Changes to Various Initializer
                    Commands  . . . . . . . . . . . . . .   8-2
                      attach and remove Commands  . . . .   8-3
                      Process Manipulation Commands . . .   8-3
                      accept Command  . . . . . . . . . .   8-4
                      drop Command  . . . . . . . . . . .   8-4
                      intercom Command  . . . . . . . . .   8-4
                      substty Command . . . . . . . . . .   8-5
                      define, redefine, and undefine
                       Commands . . . . . . . . . . . . .   8-5
                      accept_vchn Command . . . . . . . .   8-5
                      accept_vchn . . . . . . . . . . . .   8-6
                   Preaccepting Terminals Associated with
                    DSA Channels  . . . . . . . . . . . .   8-8
  
  Section 9     Implementation of new exec commands . . .   9-1
  
  Section 9     Specific DSA hierarchy structure  . . . .   9-1
                   Dynamic environment built in
                    frontend_working_dir  . . . . . . . .   9-2
                      gen_dn7.ec  . . . . . . . . . . . .   9-4
                      start_dn7.ec  . . . . . . . . . . .   9-6
                      load_dn7.ec . . . . . . . . . . . .   9-7
                      stop_dn7.ec . . . . . . . . . . . .   9-8
                      dump_dn7.ec . . . . . . . . . . . .   9-9
                      st_dn7.ec . . . . . . . . . . . . .  9-10
                      start_dsa . . . . . . . . . . . . .  9-11
  
  Appendix A         MULTICS DSA PHASE 1 INSTALLATION
                 PROCEDURE  . . . . . . . . . . . . . . .   A-1
  
  Appendix B    Exec_Coms . . . . . . . . . . . . . . . .   B-1
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 vii
  
  
  
  
  
  
  
                              SECTION 1
  
  
                             INTRODUCTION
  
  
  
  
       Multics DSA software provides the following:
  
       ox    The ability to have Multics act as a DSA host
  
       ox    Interconnections  between Multics and  other Honeywell,
            CII-HB, and foreign systems
  
       ox    Access to Multics applications from terminals connected
            via DSA terminal management
  
       ox    File  transfer between  Multics and  other DSA  systems
            using the unified file transfer (UFT) facility
  
       ox    A DSAC ASF on Multics
  
       ox    A DSAC NAD on Multics
  
       ox    The   ability   to   load,   dump,   and   generate   a
            locally-connected or a remote DN8/7100
  
       ox    DSA terminal management
  
  
       Multics  DSA software  includes the  following extensions to
  the Multics system:
  
       ox    The  addition  of  a  Multics  networking  architecture
            (MNA), which provides new software layering and dynamic
            connection management
  
       ox    Changes to  the answering service, which  are invisible
            to the user except for  the addition of a network login
            server
  
       ox    Changes to  the hardcore, mainly consisting  of changes
            to IPC and IPS, which  are invisible to the user except
            for a new IPC entrypoint
  
  
  
                                 1-1
  
  
  
  These extensions are described later in this section.
  
  
       Multics  DSA software  includes the  following DSA  specific
  software:
  
       ox    Network information table (NIT)
  
       ox    Common exchange interface (CXI) protocol
  
       ox    Session control
  
       ox    Transport control
  
       ox    Terminal management
  
       ox    Unified file transfer (UFT)
  
       ox    Distributed system administration and control (DSAC)
  
  This software  is described later in this  section.  This section
  also  provides an  overview of  the DN8/7100  and the distributed
  network supervisor (DNS).
  
  
  _D_I_F_F_E_R_E_N_C_E_S _B_E_T_W_E_E_N _M_C_S _A_N_D _M_C_A
  
       Under DSA the user can only login at system_low.
  
       The   user   cannot   use   dial_manager_$privileged_attach,
  dial_manager_$release_channel  and dial_manager_$dial_out  on the
  DSA channels.
  
       DSA  runs in  ring 2,   this eliminates  the possibility  of
  Ring_1_Repair.SysDaemeon,  Dumper or   Retriever from  logging in
  from DSA as  a terminal.  The user will be  able to login through
  the message coordinator and through an MCS channel.
  
       The last character of the screen under a DSA connection with
  video  stays   with  the  cursor   on  the  next   line  and  the
  line_indicator.
  
  
  _E_X_T_E_N_S_I_O_N_S _T_O _T_H_E _M_U_L_T_I_C_S _S_Y_S_T_E_M
  
  
  _M_u_l_t_i_c_s _N_e_t_w_o_r_k_i_n_g _A_r_c_h_i_t_e_c_t_u_r_e
  
       The Multics  DSA implementation uses  a number of  the ideas
  defined as part of the new Multics networking architecture (MNA).
  In   particular,  DSA   allows  connections   (sessions)  to   be
  dynamically created and deleted  without being predefined.  (With
  
  
                                 1-2
  
  
  
  MCS,  each connection must  be predefined in  the CMF.)  The  DSA
  communications   protocols,   session   control   and   CXI,  are
  implemented in an inner ring; however, unlike with MCS, where the
  communications  protocols are  implemented in  ring 0,  with DSA,
  they  are  implemented  in  ring  2.   The  DIA connection to the
  frontend is handled using the  standard IO interface (IOI).  This
  combination of using ring 2 and  IOI provides a more flexible and
  robust  environment  for  implementing,  testing,  and  debugging
  complicated  communications protocols.    Note that  MCS coexists
  with DSA.
  
  
  _C_h_a_n_g_e_s _t_o _t_h_e _A_n_s_w_e_r_i_n_g _S_e_r_v_i_c_e
  
       In order to avoid changing the answering service each time a
  new type of  network must be supported, the concept  of a network
  login server has  been introduced.  The login server  is a daemon
  process which "listens" for  incoming network connection requests
  and engages  in whatever dialogue is necessary  to determine what
  should  be done  with the  connection requests.   For example,  a
  remote  user trying to  login to Multics  must provide his  name,
  password, login  arguments, etc.  The login  server packages this
  information into  formatted structures and communicates  with the
  answering service  (using the user message  facility) to actually
  get   a  process  created.    The  protocol  which   allows  this
  communication between the login  server and the answering service
  consists of wakeups and message segments.  This division of labor
  allows the login server to handle the network-specific interface,
  so  the  answering  service  only  needs  to  handle the standard
  formatted structures.  The login server  is also designed to make
  different ways  of obtaining the required  login information easy
  to implement.  For instance, the DSA login server uses the normal
  Multics  greeting banner, login  line, password prompt,  etc.  if
  the connection  is made through  DSA terminal management,  but it
  gets  the  user  name  and  password  from  the  session  control
  submitter  ID  record  if  the  connection  is  for  unified file
  transfer  (UFT).  The  actual code  used by  the login  server is
  picked dynamically  based on the name of  the connection endpoint
  (mailbox) and information in the network information table (NIT).
  This  allows for  easy customization   of the  login dialogue  to
  support different dialogue requirements,  e.g., those of Videotex
  terminals.  The login server is described in detail in Section 3.
  
  
       Another answering service change, which is not DSA specific,
  has  been made  to improve  the way  the answering  service sends
  "warn" messages  to users.  Until now, the  answering service has
  forcibly  "blasted" the  message onto  the user's  terminal.  But
  this  is no  longer possible   because, as  mentioned above,  the
  answering service does  not know about DSA connections  or how to
  use them (the login server does instead).  Thus, a new IPS signal
  has been defined  and a default handler for this  signal has been
  
  
                                 1-3
  
  
  
  provided.  The answering service puts the "warn" message into the
  user message facility message segment and sends the IPS signal to
  the user's  process.  The default handler reads  the message from
  the message  segment and sends  it to the  user's terminal.  This
  happens  in  the  user's  process  so  the  terminal state is not
  destroyed.   The new IPS  signal is described  in more detail  in
  Section 7.
  
  
  _C_h_a_n_g_e_s _t_o _t_h_e _H_a_r_d_c_o_r_e
  
       As part  of the DSA  implementation, some changes  have been
  made  to the IPC  facility.  In particular,  a new type  of event
  channel has been  defined which, in addition to  sending a normal
  IPC  wakeup, also sends  an IPS "wkp_"  signal.  This allows  the
  target process to be woken up  whether or not it is blocked.  The
  only user  visible aspect of this  change is the addition  of the
  "create_event_channel" entrypoint  in ipc_.  The new  type of IPC
  event channel is described in more detail in Section 7.
  
  
  _C_h_a_n_g_e_s _t_o _S_y_s_t_e_m _E_x_e_c___C_o_m_s
  
       In  order to  run DSA  several changes  are required  in the
  system_startup.ec  (ssu.ec)  and  admin.ec.   These  changes  are
  described in Section 9.
  
  
  _D_S_A _S_P_E_C_I_F_I_C _S_O_F_T_W_A_R_E
  
  
  _N_e_t_w_o_r_k _I_n_f_o_r_m_a_t_i_o_n _T_a_b_l_e _(_N_I_T_)
  
       The  NIT is  the central  repository for  describing the DSA
  network configuration on Multics.  The NIT is described in detail
  in Section 4.
  
  
  _C_o_m_m_o_n _e_X_c_h_a_n_g_e _I_n_t_e_r_f_a_c_e _(_C_X_I_) _P_r_o_t_o_c_o_l _a_n_d _D_N_8_/_7_1_0_0 _C_o_n_t_r_o_l
  
       CXI  provides  the  programmatic  interface  between session
  control and transport control.  It  does not implement a protocol
  in  the DSA  sense, but  is  only  an interface.   CXI is  needed
  because  session control  runs in  Multics and  transport control
  runs in  the DN8/7100 and  they must communicate  through the DIA
  hardware connection.  A  subsystem, cxi_input_daemon, is provided
  to control a DN8/7100 frontend and  to start up the input side of
  CXI.  Normally,  this subsystem is  run in a  daemon process, and
  there  is one  such daemon  for each  DN8/7100 configured  on the
  system.    Specifically,  the   cxi_input_daemon  subsystem   has
  requests (e.g.,  load_frontend, dump_frontend) which are  used to
  control a DN8/7100.  There are also requests (e.g., start_driver,
  
  
                                 1-4
  
  
  
  stop_driver)  which control  the input  side of  CXI.  (The  code
  which runs  in a CXI daemon  is called a CXI  driver.)  Normally,
  the  cxi_input_daemon subsystem  is used  to generate  a DN8/7100
  image,  load   the  image,  and  start  it   running.   Then  the
  start_driver request is used to cause the daemon process to begin
  handling DSA input from the DN8/7100 using CXI.  CXI runs both in
  the  input daemon  and in  the user's  process.  It  communicates
  using shared  segments.  In particular,  all input is  handled in
  the input daemon process, and all user output is done directly by
  the  user's process.   This is  accomplished by  sharing the  IOI
  workspace (that the  input daemon gets when it  attaches the DIA)
  in ring  2.  For this reason,  the input daemon should  always be
  logged  into  ring  2  before  the  cxi_input_daemon subsystem is
  started.  Various entries in the  CXI programs manage the sharing
  of this wired buffer space (the  IOI workspace), in much the same
  way that tty_buf  is currently managed by MCS.  The  size of this
  wired space  is specified in the  NIT.  CXI is described  in more
  detail in Section 5.
  
  
  _S_e_s_s_i_o_n _C_o_n_t_r_o_l
  
       DSA session control, like CXI,  has an input side which runs
  in the input daemon process and  an output side which runs in the
  user's  process.  The  input  daemon  decides which  user process
  should receive  the input and then  sends a wakeup to  notify the
  process that  input has arrived.   The user's process  then calls
  session  control to  retrieve the  input.  Session  control, also
  like CXI,  coordinates its actions  between the input  daemon and
  the user's process using a  shared database.  The session control
  interface is also the gate into ring 2, so all access checking to
  control the usage of DSA  connections is done by session control.
  The CXI modules running on  Multics and in the DN8/7100 cooperate
  (through  the DIA)  to  provide  the interface  between transport
  control and session control.
  
  
  _T_r_a_n_s_p_o_r_t _C_o_n_t_r_o_l
  
       DSA  transport control  runs  in  the DN8/7100  frontend and
  communicates  with  the  CXI  module  in  the  frontend.  The CXI
  modules running on Multics and in the DN8/7100 cooperate (through
  the DIA)  to provide the interface between  transport control and
  session control.
  
  
  _T_e_r_m_i_n_a_l _M_a_n_a_g_e_m_e_n_t _(_T_M_)
  
       TM manages terminal  input and output.  It runs  in the user
  application,  on  top  of  session   control.   TM  is  the  only
  presentation control in Multics DSA.   What a user connects to on
  the  DN8/7100 is  terminal management;  what a  user communicates
  
  
                                 1-5
  
  
  
  with  on Multics  is the   TM correspondent.   The iox  interface
  hasn't  changed; the  tty_ I/O  module and  the video  system use
  either  TM  or  MCS  as  appropriate.   The  following orders are
  returned to caller  without error by TM, they are  handled in the
  video     system:     accept_printer_off,     refuse_printer_off,
  set_framing_chars,                      input_flow_control_chars,
  output_flow_control_chars,     set_delay,     and     reset_more.
  Information  about changes  to the  tty_ I/O  module, the set_tty
  command, and the TTF is available in Section 7.
  
  
  _U_n_i_f_i_e_d _F_i_l_e _T_r_a_n_s_f_e_r _(_U_F_T_)
  
       UFT manages the transfer of files between two systems.  Like
  TM, it runs  in the user application, on top  of session control.
  UFT is the only application control in Multics DSA.
  
  
       Two important concepts associated with  UFT are those of the
  request  daemon and  the server  daemon.  A  request daemon  is a
  daemon which  extracts requests from a queue  and processes them.
  It is associated  with a set of remote entities  to which it will
  send requests over the network.  The UFT I/O daemon is an example
  of a request  daemon.  A server daemon is a  daemon which handles
  requests  for   network  services  from  remote   users.   It  is
  associated with a set of local endpoints to which it will listen.
  The network login server and  the DSA_DSAC daemon are examples of
  server  daemons.  Both  request  daemons  and server  daemons are
  defined in the  NIT, thus allowing applications to  know only the
  names of services and foreign systems.
  
  
       UFT is  not described any further in  this manual.  Complete
  information  about UFT  is available  in the  _M_u_l_t_i_c_s _D_S_A _U_n_i_f_i_e_d
  _F_i_l_e _T_r_a_n_s_f_e_r (_U_F_T) _F_a_c_i_l_i_t_y manual, Order No.  *** TBS ***.
  
  
  _D_i_s_t_r_i_b_u_t_e_d _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _a_n_d _C_o_n_t_r_o_l _(_D_S_A_C_)
  
       DSAC is the administrative part of DSA.  It runs in both DNS
  and in Multics.  In DNS, DSAC performs the following functions:
  
       ox    NOI (network operator interface)
  
       ox    NAD (network administration)
  
       ox    ASF (administrative storage facility)
  
       ox    LOG (network logging)
  
  These functions work  just the same way in a  Multics frontend as
  they do in other DSA frontends, and are not discussed here.
  
  
                                 1-6
  
  
  
       In   Multics,  DSAC   is  divided   into  two   parts:   the
  DSA_DSAC.Daemon  and  the  dssr  subsystem.   The DSA_DSAC.Daemon
  performs the following functions:
  
       ox    ASF LOG (administrative storage facility log)
  
       ox    NAD (network administration)
  
       ox    ASF (administrative storage facility)
  
  The dssr subsystem performs the following functions:
  
       ox    remote NOI access
  
       ox    remote NAD access
  
       ox    session exerciser
  
  
  DSA_DSAC.DAEMON
  
       The  DSA_DSAC.Daemon  performs  the  ASF  LOG,  NAD, and ASF
  functions by "listening" for requests  on the $LOGFILE, $NAD, and
  $NASF mailboxes, respectively.
  
  
  ASF LOG Function
  
       The  ASF LOG  function of  the DSA_DSAC.Daemon  receives AEP
  messages from various NADs in the  network and stores them in the
  DSA  AEP log (dsa_al).   This function is  mostly for use  by the
  DN8/7100 NAD, because  it has no place to  store information.  It
  may also be used by other nodes for logging statistics.
  
  
  NAD Function
  
       The NAD function of the DSA_DSAC.Daemon accepts DSA sessions
  with the local  DN8/7100 NOI.  The NAD function  also ships local
  AEP  messages.  For  example, AEP  messages generated  by CXI are
  stored  in the DSA  system AEP log  (dsa_sal).  The NAD  function
  reads the AEP messages in the log  and sends them to the DNS NOI,
  which translates them  from AEP format into ASCII  format, so the
  NOI operator can read them.  The NAD function does not accept AEP
  commands from other nodes in the DSA network.
  
  
  ASF Function
  
       The ASF function of  the DSA_DSAC.Daemon accepts connections
  from local or  remote DNS NADs and provides a  remote file access
  service for  the DN8/7100, which has  no file system of  its own.
  
  
                                 1-7
  
  
  
  The DNS  NAD asks the Multics  ASF to read or  write files for it
  (usually   config  files,   runnable  images,   dumps,  and  test
  overlays).   DNS knows the  name of the  directory and the  entry
  name of the file.
  
  
  THE DSSR SUBSYSTEM
  
       The  dssr  subsystem  runs  in  a  normal  user process.  It
  performs the  remote NOI access,  remote NAD access,  and session
  exerciser  functions  by  responding  to  requests  aimed  at the
  $TMDIALOU,  $NOIAEP,  and  $NSE  (acceptor)  and $NSF (initiator)
  mailboxes, respectively.
  
  
  Remote NOI Access Function
  
       The remote NOI access function  of the dssr subsystem allows
  you  to dialout through  session control to  the DNS NOI,  so you
  look  like an  operator's terminal  to DNS.   For administrators,
  using the  remote NOI access  function is the  same as connecting
  through a terminal directly to the DN8/7100.
  
  
  Remote NAD Access Function
  
       The remote NAD access function  of the dssr subsystem allows
  Multics and DNS to communicate.   It accepts requests and Multics
  commands in  ASCII format, translates  them into AEP  format, and
  sends them on  to the NAD in the DNS.   For administrators, using
  the remote NAD access function is  the same as using the DNS NOI,
  except that it  provides the advantages of being  able to connect
  to any DN8/7100 and to have Multics file output.
  
  
  Session Exerciser Function
  
       The session exerciser function  of the dssr subsystem allows
  you  to initiate a  session to or  accept a session  from another
  node in order to test the connection.  It allows you to establish
  a session, send data, get the data echoed back, and terminate the
  session.
  
       DSAC is described in detail in Section 6.
  
  
  _D_a_t_a_n_e_t _8 _(_D_N_8_/_7_1_0_0_) _a_n_d _D_i_s_t_r_i_b_u_t_e_d _N_e_t_w_o_r_k _S_u_p_e_r_v_i_s_o_r _(_D_N_S_)
  
       DNS  is the  operating system   software which  runs on  the
  DN8/7100 frontend hardware.
  
  
  
  
                                 1-8
  
  
  
  FILES THAT ARE UNLOADED FROM THE DELIVERY TAPE
  
       The DN8/7100  software is delivered  on a GCOS  8 SAVE tape.
  The  gcos_fms command  is used  to  read  the tape  and create  a
  corresponding  Multics hierarchy.   The "sys"  directory in  this
  hierarchy  contains  the  files   below.   These  files  must  be
  converted   into  the   appropriate  Multics   format  with   the
  dsa_cv_dns_tape command.   They are then ready to  be loaded into
  the DN8/7100.
  
       ox    generator image  file:  when it is run,  it generates a
            specific  runnable image  for a  specific DNS  software
            release.
  
       ox    patch file:  contains software updates.
  
       ox    object  segments:  DN8/7100  software modules  (used by
            the generator  image file to create  the runnable image
            file).
  
  
  FILES THAT MUST BE BUILT
  
       Templates for  the files below are provided  on the delivery
  tape, but the actual files for  a particular site must be created
  by the  system administrator.  They are normal  ASCII text files,
  so any Multics editor may be used.
  
       ox    config file:   describes the configuration for  a given
            frontend.
  
       ox    scenario file:   describes a scenario for  performing a
            load, dump, go, or generation  of a remote datanet.  It
            is  like  a  subsystem  exec_com,  and  enables  you to
            manipulate  remote  DN8/7100s  the  same  way  you  can
            manipulate local DN8/7100s.
  
  
  FILES THAT ARE GENERATED
  
       The files  below must be created  using the cxi_input_daemon
  subsystem to  load a generator  image into the  DN8/7100, run it,
  and get back a runnable image.   The dump files are created using
  the dump_frontend request  to create a Multics file  which can be
  examined with standard Multics tools (i.e., dump_segment).
  
       ox    runnable image file:  is related to a specific DN8/7100
            configuration, and  consists mainly of config  maps and
            images.   It is produced  by running a  generator image
            file.
  
       ox    dump file:  contains a DN8/7100 memory dump.
  
  
                                 1-9
  
  
  
       More  information on  all of   these files  is available  in
  Section 2.
  
  
  DN8/7100 TESTS AND DIAGNOSTICS (T&D)
  
       The standard T&Ds provided for GCOS 8 to handle the DN8/7100
  frontend will also run on Multics under COLTS (just like the T&Ds
  for the current DN61xx frontend).
  
  
       The figure  "Layers Synopsis" illustrates  the relationships
  between various Multics layers and data bases.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 1-10
  
  
  
  LAYERS SYNOPSIS
  
  
         /-------\          /-------\
       /           \       /         \
     /               \     | DSAC(s) |
    |   PROCESS(es)   |    \         /
     \               /      \-------/
       \           /           ||               RING 4
      /  \-------/  \          ||                   |
    /                \         ||                   |
   |                  |        ||                   |
  -----------|-----------      ||    wakeups        |
  |   TM     |   UFT    |      ||       /\          |
  -----------------------     //         |          |
            ||              //           |          |
            ||   calls    //             |          |
            ||          //               |          |
            \/         \/                |         \/
  ---------------------------------------------- ......  GATES ...
  |    Session Control  ||    Session Control  |   /\
  |       in the        ||       in the        |    |    RING 2
  |    user  process    ||    driver process   |    |
  ----------------------------------------------    |
            ||                      /\              |
            || calls                || calls        |
            \/                      ||              |
  ----------------------------------------------    |
  |       CXI           ||        CXI          |    |
  |   running in the    ||   running in the    |    |
  |   user  process     ||   driver  process   |    |
  ----------------------------------------------    |
  write or read  |                   /\
  in CXI wired   |                   || calls
  buffer         |                 ------
                 |               / DRIVER \
           ................     | PROCESS  |<------  TIMER DRIVEN
           | wired buffer |      \  CXI   /
           ................        ------
                 |||
                 DIA
                 |||
       =========================
       |        D N 8          |
       |   (Transport and...)  |
       =========================
  
  
  
  
  
  
  
  
                                 1-11
  
  
  
  
  
  
  
  
  
                              SECTION 2
  
  
                      STARTING UP DSA ON MULTICS
  
  
  
  
       This section describes what  administrators must do to start
  up  DSA  on  Multics.   The  information  is  divided  into  four
  categories as follows:
  
       ox    Tailoring the Multics environment for DSA (must be done
            once, when DSA is first brought up on Multics)
  
       ox    Building  the network  information table  (must be done
            when DSA is  first brought up on Multics,  and also any
            time the network configuration changes)
  
       ox    Building a DN8/7100 config file  (must be done when DSA
            is first brought  up on Multics, and also  any time the
            network configuration changes)
  
       ox    Managing DN8/7100  generation and run  operations (must
            be done  when DSA is  first brought up  on Multics, any
            time  the network  configuration changes,  and any time
            there  is  a  new  DNS  release  or  a  DNS  patch; run
            operations alone must be done any time Multics has been
            shut down)
  
  
       NOTE:   In order to  use Multics DSA  fully, the newer  NMLC
  boards must  be used in the  DN8/7100.  If the older  MLCP boards
  are used  in the DN8/7100, Multics  DSA will not work  with video
  and Emacs; it will only work with line mode.
  
  
  _T_A_I_L_O_R_I_N_G _T_H_E _M_U_L_T_I_C_S _E_N_V_I_R_O_N_M_E_N_T _F_O_R _D_S_A
  
       Administrators must perform the tasks listed below to tailor
  the Multics environment for DSA:
  
       ox    Edit the Multics config deck
  
       ox    Create new access control segments
  
  
  
                                 2-1
  
  
  
       ox    Update the installation_parms segment
  
       ox    Optionally change the terminal type file (TTF)
  
       ox    Set ACLs on the DSA logs
  
       ox    Register the new DSA daemons
  
       ox    Build a Multics DSA hierarchy
  
  
  _E_d_i_t_i_n_g _t_h_e _M_u_l_t_i_c_s _C_o_n_f_i_g _D_e_c_k
  
       You must  add a prph diaX  card to the config  deck for each
  frontend defined by a Frontend  object definition in the NIT (the
  NIT is described in detail in Section 4).  The name on the config
  card must match the name specified by the dia statement under the
  Frontend  object definition for  the frontend in  question; e.g.,
  diab.  The prph diaX card defines the characteristics of a DIA or
  direct  channel.  See  the _M_u_l_t_i_c_s  _S_y_s_t_e_m _M_a_i_n_t_e_n_a_n_c_e _P_r_o_c_e_d_u_r_e_s
  manual, Order No.  AM81, for a complete description of the config
  deck.
  
  
  _C_r_e_a_t_i_n_g _N_e_w _A_c_c_e_s_s _C_o_n_t_r_o_l _S_e_g_m_e_n_t_s
  
       You must create a set  of new access control segments (ACSs)
  to control  access over the DSA network.   Specifically, you need
  an ACS  for each DIA attached  to a frontend, and  ACSs for these
  objects   as   described   in   the   NIT:   systems,  mailboxes,
  correspondents, and administrative correspondents.
  
  
       The access  control segments for  DIAs should be  created as
  described in the _M_u_l_t_i_c_s _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _P_r_o_c_e_d_u_r_e_s manual,
  Order No.  AK50.  Typically, ACSs  for devices (DIAs) are created
  under  >sc1>rcp  as  <device_name>.acs  (e.g.,  diaa.acs).  A CXI
  input daemon requires rw access to the ACS for any DIA it uses.
  
  
       Access  control  segments  for  the  NIT  objects  (systems,
  mailboxes,  correspondents,  and  administrative  correspondents)
  must  be created  using the  pathnames specified  by the acl_path
  statements   under  the   System,  Mailbox,   Correspondent,  and
  Admin_correspondent object definitions in the NIT.  Set access on
  these  ACSs  according  to  the  instructions  provided under the
  descriptions  of the  acl_path  statements  for the  objects (see
  Section 4).  Normally, these ACSs are located under >sc1>mna>dsa.
  
  
  
  
  
  
                                 2-2
  
  
  
  _U_p_d_a_t_i_n_g _t_h_e _i_n_s_t_a_l_l_a_t_i_o_n___p_a_r_m_s _S_e_g_m_e_n_t
  
       Two new mechanisms have been  added to the Multics answering
  service which have an effect on the installation_parms segment.
  
  
       The  second mechanism  allows  you  to charge  processes for
  their use of DSA channels:  bytes sent, packets sent, and connect
  time.  Rates for these charges are  handled the same way as rates
  for  tape and disk  device use.  The  charges per thousand  bytes
  sent, per thousand packets sent, and per hour of connect time are
  stored   as   device   rates   for   each   rate   structure   in
  installation_parms.  The new devices defined for this purpose are
  dsa_kbyt,  dsa_kpkt, and  dsa_hour, respectively.   To add  these
  device names  to installation_parms and specify a  set of prices,
  use the ed_installation_parms command.
  
  
       The  ed_installation_parms  command   is  described  in  the
  _M_u_l_t_i_c_s  _A_d_m_i_n_i_s_t_r_a_t_i_v_e,  _M_a_i_n_t_e_n_a_n_c_e,  _a_n_d  _O_p_e_r_a_t_i_o_n_s  _C_o_m_m_a_n_d_s
  manual,  Order  No.   GB64.   The  installation_parms  segment is
  described in the _M_u_l_t_i_c_s _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _P_r_o_c_e_d_u_r_e_s manual,
  Order No.  AK50.
  
  
  _C_h_a_n_g_i_n_g _t_h_e _T_T_F
  
       The Multics  TTF has been  extended to permit  definition of
  options that  are specific to  operation in the  DSA environment.
  This  has been  accomplished via  the dsatm_device  substructure,
  which is optional and consists  of the dsatm_device statement and
  one  or more  substatements.  Default  values are  assumed if  no
  dsatm_device  substructure is  included in  the TTF  entry for  a
  given  terminal   type.   However,  it  is  best   to  include  a
  dsatm_device substructure in the TTF  entry for any terminal type
  which will be used to access  Multics via DSA.  See Section 7 for
  a complete description of this substructure.
  
  
  _S_e_t_t_i_n_g _A_C_L_s _o_n _t_h_e _D_S_A _L_o_g_s
  
       Three logs  are defined in  the NIT (see  the description of
  the Mna_general_info object definition in Section 4):
  
       ox    DSA system log (dsa_sl), for recording CXI input daemon
            and session control errors
  
       ox    DSA system  AEP log (dsa_sal), for  recording CXI input
            daemon and session control AEP activity
  
       ox    DSA AEP  log (dsa_al), for  recording UFT and  DSAC AEP
            activity
  
  
                                 2-3
  
  
  
  Normally,    dsa_sl    and     dsa_sal    are    located    under
  >site>dsa>system_logs_dir    and   dsa_al   is    located   under
  >site>dsa>aep_logs_dir.     All    three    logs    are   created
  automatically, but before they are  created (i.e., before you run
  DSA for  the first time), you  must set ring brackets,  ACLs, and
  IACLs  on the directories  which contain them,  and you must  set
  ACLs on the logs themselves.
  
  
       Set the  ring brackets on >site>dsa>system_logs_dir  to 2,7.
  Set  the ACL to  sma for *.*.*.   Set the IACL  to rw for  *.*.*.
  Note that  this is a ring  2 IACL, which means  that you must use
  the "ring 2" option in order to set it.
  
  
       Set the ring brackets on >site>dsa>aep_logs_dir to 7,7.  Set
  the ACL to sma for DSA_DSAC.Daemon, DSA_UFT.SysDaemon, and *.*.f.
  Set  the IACL to  rw for DSA_DSAC.Daemon,  DSA_UFT.SysDaemon, and
  *.*.f.  Note that this is a ring 4 IACL.
  
  
       Both the DSA  system log and the DSA system  AEP log will be
  ring 2 logs (ring brackets 2,2,2).   Give rw access to *.*.*.  To
  look  at one of  these logs, use  the print_sys_log command  with
  either  the -dsasl  or -dsasal  control argument.   These control
  arguments are described in Section  7.  Note that you need access
  to dsa_log_admin_gate_ to look at these logs.
  
  
       The DSA AEP log will be  a ring 4 log (ring brackets 4,4,4).
  The DSAC and UFT daemons require  rw access.  Also give rw access
  to *.*.f.   (The "f" tag denotes file  transfer server processes,
  which  implies  that  additional  access  permissions  have  been
  previously established for this class  of user.)  To look at this
  log, use  the print_sys_log command  and specify the  pathname of
  the DSA AEP log.  No special control argument is required.
  
  
   _R_e_g_i_s_t_e_r_i_n_g _t_h_e _N_e_w _D_S_A _D_a_e_m_o_n_s
  
       Multics DSA employs the  following daemons to perform varied
  services over the network:
  
       ox    DSA_DSAC.Daemon, responsible for ASF  LOG, NAD, and ASF
            functions
  
       ox    DSA_CXI.Daemon, responsible for handling all input from
            a frontend;  there is one for  each frontend configured
            in the NIT
  
  
  
  
  
                                 2-4
  
  
  
       ox    Login_Server.Daemon, responsible  for fielding requests
            for  sessions  from  remote  users  and  arranging  for
            process creation on their behalf on Multics
  
       ox    DSA_UFT.SysDaemon  (an  I/O  daemon),  responsible  for
            queued  file transfer  requests from  Multics to  other
            computers on the network
  
  
       The DSA_DSAC daemon must be registered in the PNT and in the
  PMF for the  Daemon project.  Set the default login  ring for the
  DSA_DSAC daemon to 4 in the PMF.
  
  
       The DSA_CXI daemon must be registered  in the PNT and in the
  PMF for the  Daemon project.  Set the default login  ring for the
  DSA_CXI  daemon to 2  in the PMF.   Note that the  DSA_CXI daemon
  must have rw access to  >sc1>rcp>workspace.acs in order to attach
  the DIA connected to the DN8/7100 with which it interfaces.
  
  
       The login server daemon must be registered in the PNT and in
  the PMF for  the Daemon project.  Set the default  login ring for
  the  login server  daemon to  4 in  the PMF.   Specify the  login
  server's process overseer as "login_server_overseer_" in the PMF.
  Note  that   the  login  server  daemon  requires   r  access  to
  >sc1>answer_table and ao access to >sc1>login_server_requests.ms.
  
  
       The DSA_UFT daemon must be registered  in the PNT and in the
  PMF for  the SysDaemon project.   Set the default  login ring for
  the DSA_UFT  daemon to 4 in  the PMF.  I/O daemon  tables must be
  updated  for UFT  and  recompiled.   The required  procedures are
  described under "Configuring the UFT Facility" in the _M_u_l_t_i_c_s _D_S_A
  _U_n_i_f_i_e_d _F_i_l_e  _T_r_a_n_s_f_e_r (_U_F_T) _F_a_c_i_l_i_t_y manual, Order  No.  *** TBS
  ***.
  
  
       See  the _M_u_l_t_i_c_s   _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n  _P_r_o_c_e_d_u_r_e_s manual,
  Order No.  AK50, for more information on registering daemons.
  
  
  _B_u_i_l_d_i_n_g _a _M_u_l_t_i_c_s _D_S_A _H_i_e_r_a_r_c_h_y
  
       Multics DSA  hierarchy contains files associated  with local
  and  remote frontends and  stores the DNS  software to be  loaded
  from  the GCOS  SAVE tape  (described below)  and then converted.
  The suggested location is under >site.
  
  
  
  
  
  
                                 2-5
  
  
  
       The dsa Directory is  created under >site.  Under >site>dsa,
  you find the directories:   fontend_dir_dir (fdd), c1m4, acs, and
  system_logs_dir, aep_logs_dir, and uft_logs_dir.
  
  
       Under fdd, a subdirectory exists for each frontend connected
  to  Multics, using  the frontend  name defined  by the associated
  Frontend object  definition in the  NIT; e.g., dn7a,  dn7b.  This
  directory is the working directory  of the CXI input daemon which
  interfaces  this frontend  with Multics.   Normally, the runnable
  image,  config  file,  links  to  DNS  files,  and dumps for this
  frontend should be kept in this directory.  Also, the start_up.ec
  for the CXI  input daemon should contain a command  to change the
  working    directory    to    this    directory.     Either   the
  dsa_fep_working_dir    (dsa_fwd)   active    function   or    the
  frontend_working_dir (fwd) CXI subsystem  request may be used for
  this purpose; e.g., cwd  [dsa_fwd dn8a].  The dsa_fep_working_dir
  active function is described  below; the frontend_working_dir CXI
  subsystem  request is  described in  Section 5.   Note that  this
  directory  must  be  the  same   as  the  one  specified  by  the
  working_dir  statement  under   the  associated  Frontend  object
  definition in the NIT.
  
  
       Under each subdirectory for a frontend connected to Multics,
  there can be  a subdirectory of remote scenarios  if the frontend
  has  the  teleload/teledump  capability.   This  subdirectory can
  contain  different scenario  files for  loading remote  frontends
  (see the _D_N_S _S_y_s_t_e_m _I_n_s_t_a_l_l_a_t_i_o_n _a_n_d _G_e_n_e_r_a_t_i_o_n manual, Order No.
  DP43 or  the _D_N_S _S_y_s_t_e_m  _G_e_n_e_r_a_t_i_o_n manual, Reference  No.  39 A2
  9807, for a description of scenario files).
  
  
       Under  c1m4, create one  subdirectory called sys  to contain
  the DNS software files converted to Multics format.
  
  
       Note also  you find under  >site>dsa the directory  in which
  CXI  and  session  control  will  store  their segments, normally
  >site>dsa>data, and the directories in which the DSA logs will be
  located,  normally >site>dsa>system_logs  and >site>dsa>aep_logs.
  A last directory >site>dsa>uft_logs_dir will contain uft specific
  logs.   This pathname is  to be specified  in value segment  used
  when     enabling     uft     tracing,     and     located     in
  >site>dsa>data>uft_value.value.
  
  
       The  last  directory  >site>dsa>acs  contains  acs  segments
  explicitly named  in NIF and  determining access rights.   If you
  want  to  change  any  segment  name,  you  have  also  to change
  acs_pathnames in NIF.
  
  
  
                                 2-6
  
  
  
       A major part of this hierarchy is automatically created when
  reloading a  DSA tape at installation, the  remaining is manually
  created   according  to   site  configuration   and  installation
  instructions contained in the pseudo dsa-sib (see Appendix A).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-7
  ___________________                           ___________________
  
  dsa_fep_working_dir                           dsa_fep_working_dir
  ___________________                           ___________________
  
  
  NAME: DSA_FEP_WORKING_DIR, DSAFWD
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dsafwd frontend_name
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _F_U_N_C_T_I_O_N
  
  [dsafwd frontend_name]
  
  _F_U_N_C_T_I_O_N
  
  prints  the  working  directory   specified  by  the  working_dir
  statement under the Frontend object definition in the NIT for the
  frontend  specified  by  frontend_name.   As  an active function,
  dsafwd  returns the name  of the working  directory.  There is  a
  corresponding  CXI subsystem request  called frontend_working_dir
  (fwd).
  
  _A_R_G_U_M_E_N_T_S
  
  frontend_name
     is  the  name  of  the  frontend  whose  working  directory is
     desired.
  
  _A_C_C_E_S_S _R_E_Q_U_I_R_E_D
  
  This command requires r access to the NIT.
  
  _N_O_T_E_S
  
  The working directory for a frontend is where its runnable image,
  config file, patch files, and dump files are usually kept.  Thus,
  this  command is  normally executed   in the  CXI input  daemon's
  start_up.ec, or the corresponding request  is executed in the CXI
  subsystem's start_up.cidec.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-8
  
  
  _B_U_I_L_D_I_N_G _T_H_E _N_E_T_W_O_R_K _I_N_F_O_R_M_A_T_I_O_N _T_A_B_L_E
  
       The   network  information   table  (NIT)   is  the  central
  repository  for  describing  the  DSA  network  configuration  on
  Multics.   As  is  evidenced  throughout  this section, virtually
  every  aspect of  hardware and  software linked  together in  the
  network has some reference point in the NIT.  An integral part of
  bringing up  DSA on Multics is  to build, compile, and  install a
  NIT as described in Section 4 of this manual.
  
  
  _B_U_I_L_D_I_N_G _A _D_N_8_/_7_1_0_0 _D_I_R _'_S_Y_S_>_'
  
       You  must build  a DIR  'sys>' for  each datanet  managed by
  Multics  and defined  in the  NIT.  To  do this,  use any Multics
  editor and follow the instructions in the _D_N_S _S_y_s_t_e_m _I_n_s_t_a_l_l_a_t_i_o_n
  _a_n_d  _G_e_n_e_r_a_t_i_o_n manual,  Order No.    DP43 or  in the  _D_N_S _S_y_s_t_e_m
  _G_e_n_e_r_a_t_i_o_n manual, Reference No.  39 A2 9807.
  
  
       Because  DN8/7100 generation  is executed  from the  Multics
  host  rather than from  a locally loaded  diskette, the group  of
  command  lines listed  below  must  follow immediately  after the
  DN8/7100 command, the first command in the config file:
  
         DIR 'sys>'
         LANG NATIONAL -KEYFIL 'DLCKW' &
                       -MESFIL 'DLCMSG'
  
  The final command line in the config file must be:
  
       END -START -EX
  
  Note  that  this  is  true  regardless  of  whether the generated
  runnable image is  for a local frontend or a  remote datanet.  If
  the image is for a remote datanet, it will be stored in the right
  format and the suffix will be  changed from ".i" to ".b" when the
  patches are applied.
  
  
       To build a DN8/7100 config file, you also have the option of
  using the sample  config file which is provided on  the GCOS SAVE
  tape  as  a  template,  and   tailoring  it  to  the  appropriate
  specifications.  This requires loading  the DNS software from the
  installation  tape onto  Multics and  converting the  loaded GCOS
  files to Multics  file format.  To do this, see  "Loading the DNS
  Software  onto Multics"  and  "Converting  GCOS Files  to Multics
  Format" later in  this section.  Once the sample  config file has
  been loaded and  converted from the SAVE tape to  the Multics DSA
  hierarchy,  you can  edit it  as described  above to  reflect the
  desired frontend configuration.
  
  
  
  
                                 2-9
  
  
       Remember that you must build  a config file for each datanet
  managed by Multics and defined in the NIT.
  
  
  _M_A_N_A_G_I_N_G _D_N_8_/_7_1_0_0 _G_E_N_E_R_A_T_I_O_N _A_N_D _R_U_N _O_P_E_R_A_T_I_O_N_S
  
       The common exchange interface  (CXI) protocol allows session
  control  on Multics  to communicate  with transport  control on a
  DN8/7100  over a  DIA hardware  connection.  CXI  runs both  in a
  daemon process and  in a user process.  When it  runs in a daemon
  process, CXI  calls session control to  perform input processing.
  When it runs in a user  process, CXI is called by session control
  to perform output processing.
  
  
       There is one  CXI input daemon for each  frontend defined in
  the  NIT.  All  input daemons   share a  database called  the CXI
  driver segment.  The  CXI subsystem runs in a  daemon process and
  provides the means to produce a runnable image from the generator
  image  supplied  with  the  DNS  software  tape  and  to  start a
  frontend.  The subsystem also controls the input side of CXI (the
  CXI driver).
  
  
       Listed below are the steps to follow to complete DSA startup
  preparations.  Each  step is described in detail  after the list.
  If you are starting up DSA on  Multics for the first time, if the
  network configuration has changed, or if you are installing a new
  DNS release  or a DNS  patch, perform steps  1 - 10.   If you are
  booting Multics  after having shut it  down, perform steps 3  - 6
  and steps 8 - 10.
  
  1.   Load  the  DNS  software  from  the  installation  tape onto
       Multics.
  
  2.   Convert the loaded GCOS files to Multics file format.
  
  3.   Create the CXI driver segment.
  
  4.   Start up session control.
  
  5.   Log in the CXI input daemons.
  
  6.   Start up the CXI subsystem.
  
  7.   Load and execute a generator image.
  
  8.   Load, execute, and start a runnable image.
  
  9.   Start the CXI driver.
  
  10.  Log in the other DSA daemons.
  
  
  
                                 2-10
  
  
  _L_o_a_d_i_n_g _t_h_e _D_N_S _S_o_f_t_w_a_r_e _o_n_t_o _M_u_l_t_i_c_s
  
       The DNS software is delivered on  a SAVE tape created by the
  GCOS  file master  supervisor.   Significant  files on  this tape
  include a sample config file,  patch files with software updates,
  DNS object segments, and a generator image.
  
  
       To load the supplied files onto Multics, mount the SAVE tape
  and  execute the  gcos_fms command,  using >site>dsa>c1m4  as the
  working  directory.  The  format of  the gcos_fms  command is  as
  follows:
  
       gfms reel_number -no_ga
  
  
       The gcos_fms command is a  standard Multics command, used to
  transport GCOS files to the  Multics environment; it is described
  in the  _M_u_l_t_i_c_s _C_o_m_m_a_n_d_s _a_n_d  _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s manual,  Order No.
  AG92.  Use other control arguments  as appropriate, but note that
  the  -no_ga   control  argument  is  undocumented   and  must  be
  specified.
  
  
       Output  from  the  gcos_fms  command  maps  the GCOS catalog
  structure to the Multics DSA hierarchy under >site>dsa>c1m4>c1m4.
  
  
  _C_o_n_v_e_r_t_i_n_g _G_C_O_S _F_i_l_e_s _t_o _M_u_l_t_i_c_s _F_o_r_m_a_t
  
       The dsa_cv_dns_tape  command (described below)  converts the
  loaded GCOS files to Multics format  and maps them to the Multics
  DSA hierarchy under >site>dsa>c1m4>sys.
  
  
       After you  have used the dsa_cv_dns_tape  command to convert
  the  files, use the  following command line  to add the  standard
  default names to them:
  
       do "an &1 [uppercase[spe &1]]"!([segs **])
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-11
  _______________                                   _______________
  
  dsa_cv_dns_tape                                   dsa_cv_dns_tape
  _______________                                   _______________
  
  
  NAME: DSA_CV_DNS_TAPE, DSACVT
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dsacvt input_path {output_path} {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  Converts  a GCOS  format file  containing only  ASCII media  code
  records to a Multics file  of the appropriate type.  This command
  is  specialized to  handle the  files generated  by the  gcos_fms
  (gfms) command  operating on a DNS software  distribution tape in
  GCOS 8 format.
  
  _A_R_G_U_M_E_N_T_S
  
  input_path
     specifies  the name of  the input file  to be processed.   The
     star convention is allowed.  This argument must be specified.
  
  output_path
     specifies  the name of  the output file  to be produced.   The
     equal convention is allowed.  A suffix  of a, b, or i is added
     if not already present (these  suffixes are defined in control
     argument  descriptions  below).   If   this  argument  is  not
     specified,  the  input_path  entry  name  is  used,  with  the
     appropriate suffix added.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -ascii
     specifies that the output file  be in ASCII format, regardless
     of its name.  Each record in the input file will have an ASCII
     newline character  appended to it  before it is  stored in the
     output file.  The output file suffix will be "a".  The default
     depends on the  input file name.  If -ascii  is specified, the
     default output file organization will be stream output.
  
  -binary, -bin
     specifies that the output file be in binary format, regardless
     of  its name.  Each  record in the  input file will  be stored
     with no  changes in the  output file.  The  output file suffix
     will be "b".  The default depends  on the input file name.  If
     -binary  is specified,  the default  output file  organization
     will be sequential output.
  
  -image
     specifies that the output file  be in image format, regardless
     of its name.   This is the same as binary  format, except that
  
  
                                 2-12
  _______________                                   _______________
  
  dsa_cv_dns_tape                                   dsa_cv_dns_tape
  _______________                                   _______________
  
  
     file  organization  is  stream  rather  than  sequential.  The
     output file  suffix will be  "i".  The default  depends on the
     name of the  input file.  If -image is  specified, the default
     output file organization will be stream output.
  
  -sequential_output, -sqo
     specifies  that  the  output   file  be  a  sequential  vfile_
     regardless of  its name.  The  default depends on  the name of
     the  input  file  and  the  value  of  the file format control
     argument.
  
  -stream_output, -so
     specifies that  the output file be a  stream vfile_ regardless
     of  its name.  The  default depends on  the name of  the input
     file and the value of the file format control argument.
  
  _N_O_T_E_S
  
  This  command is specialized  to handle the  files from a  GCOS 8
  SAVE tape used for DNS  software distribution.  It recognizes the
  following  input file  names (in   either upper  or lower  case),
  handling them as described:
  
  PATCH0,  PATCH1,  PATCH2,  CHXMOD,  CONFIG,  DLCKW,  DLCMSF:  the
  default output file format for these input files is ASCII stream;
  the "a"  suffix is added.   These are normal  Multics text files,
  which can be edited by any text editor.
  
  IMAMEM, IMAMEMU:  the default output  file format for these input
  files is binary stream; the "i" suffix is added.  These files are
  suitable for  loading directly into a  local DNS, but not  into a
  remote DNS.   The dump_segment command (described  in the _M_u_l_t_i_c_s
  _C_o_m_m_a_n_d_s  _a_n_d _A_c_t_i_v_e  _F_u_n_c_t_i_o_n_s manual,  Order No.   AG92) can be
  used to examine them.
  
  Any other input  name:  the default output file  format for these
  input files is binary sequential; the "b" suffix is added.
  
  Normally,  the dsa_cv_dns_tape  command is  run in  the directory
  containing  the  converted  software,  i.e.,  >site>dsa>c1m4>sys.
  Given that the gcos_fms  command creates >site>dsa>c1m4>c1m4 when
  loading the  DNS software distribution  tape, you should  use the
  following command  line to create  output files with  the correct
  suffixes for subsequent operations:
  
     dsacvt >site>dsa>c1m4>c1m4>sys>** ==
  
  If you intend to load (or reload) a remote DN8/7100 from Multics,
  you should  follow the command  line above with  the command line
  
  
                                 2-13
  
  
  below,  in   order  to  generate  a   properly  formatted  image,
  recognizable  by  the  remote   frontend  (i.e.,  an  image  that
  preserves the original record boundaries):
  
     dsacvt >site>dsa>c1m4>c1m4>sys>imamem IMAMEM.b -binary
           -sequential_output
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-14
  
  
  _C_r_e_a_t_i_n_g _t_h_e _C_X_I _D_r_i_v_e_r _S_e_g_m_e_n_t
  
       The CXI driver segment (cxi_driver_seg) is a shared database
  that all CXI input daemons use to store their data.  It should be
  created  before  logging  in  the  daemons  and  invoking the CXI
  subsystem.  When you start up session control (using the dsa_init
  command  described  below),  the  driver  segment  is  created by
  default;   the   pathname   used   is   that   specified  by  the
  cxi_driver_segment  statement under  the Mna_general_info  object
  definition  in the NIT  (see Section 4).   The usual location  is
  under >site>dsa>data.
  
  
       Alternatively, the  cxi_create_driver_seg command (described
  below) can be used.  This command will query you by default as to
  whether  or not it  should proceed with  segment creation if  the
  segment already exists.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-15
  _____________________                       _____________________
  
  cxi_create_driver_seg                       cxi_create_driver_seg
  _____________________                       _____________________
  
  
  NAME: CXI_CREATE_DRIVER_SEG
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  cxi_create_driver_seg {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _F_U_N_C_T_I_O_N
  
  [cxi_create_driver_seg {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  creates and initializes the shared  segment used by all CXI input
  daemons.   This segment  must be  created and  initialized before
  user   processes   can   use   DSA.    As   an   active  function
  cxi_create_driver_seg  returns "true"  if the  segment is created
  and  initialized without  error, "false"  otherwise.  The segment
  pathname is obtained from  the cxi_driver_segment statement under
  the Mna_general_info object definition in the NIT.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -brief, -bf
     does not print  a message informing the user  that the segment
     has been created.
  
  -force, -fc
     creates and initializes the segment without querying the user,
     even if the segment already exists and appears to be in use by
     other CXI input daemons.
  
  -long, -lg
     prints a message informing the  user that the segment has been
     created and initialized.  This is the default.
  
  -no_force, -nfc
     queries the user if the  segment already exists and appears to
     be in use by other CXI input daemons.  This is the default.
  
  _A_C_C_E_S_S _R_E_Q_U_I_R_E_D
  
  This command requires re access to cxi_driver_admin_gate_.
  
  _N_O_T_E_S
  
  This  command  calls  cxi_driver_admin_gate_  so  that the driver
  segment will be created in ring  2.  The pathname for the segment
  is  obtained   from  the  cxi_driver_segment  statement   of  the
  Mna_general_info object definition in the NIT.
  
  
                                 2-16
  
  
  _S_t_a_r_t_i_n_g _S_e_s_s_i_o_n _C_o_n_t_r_o_l
  
       Session  control, a  Multics DSA  component, cooperates with
  transport control on  a DN8/7100 through the services  of the CXI
  interface  to  enable  applications  on   the  host  to  talk  to
  applications on remote systems.
  
  
       To  start session  control, invoke  the dsa_init  command as
  described   below.   This   command  should   be  added   to  the
  system_start_up.ec.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-17
  ________                                                 ________
  
  dsa_init                                                 dsa_init
  ________                                                 ________
  
  
  NAME: DSA_INIT
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dsa_init {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  initializes  DSA  operations   by  initializing  session  control
  databases,  creating  mailboxes,  and  creating  the  CXI  driver
  segment for CXI operations.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -all, -a
     specifies  that  all  initializations  should  be  done.  This
     includes all  session controls, all mailboxes  associated with
     each  session control,  all  data  bases associated  with each
     session control (i.e., the general data segment, seg_info, the
     logical  connection  segment,  lc_data,  and  the handle table
     segment, dsa_sc_hm_seg), the connection list data, and the CXI
     driver segment.  This is the default.
  
  -cxi
     specifies that the CXI driver segment should be created.  This
     is the default.
  
  -no_cxi, -ncxi
     specifies that the CXI driver segment should not be created.
  
  -no_session_control, -nsc
     specifies that no session controls should be initialized.
  
  -session_control session_control_name, -sc session_control_name
     specifies  that  only  the  named  session  control  should be
     initialized.   The  default  is   to  initialize  all  session
     controls  defined in  the  NIT  by Sc_loc  object definitions.
     (Currently,  only one  session control  may be  defined in the
     NIT.)
  
  _N_O_T_E_S
  
  When this command initializes the CXI driver segment, it uses the
  -force  option   so  there  will   be  no  user   query  even  if
  cxi_driver_seg  is already in  use.  It may  be safer to  use the
  cxi_create_driver_seg  command   if  it  is  possible   that  the
  cxi_driver_seg may be in use.
  
  
  
  
                                 2-18
  
  
  _L_o_g_g_i_n_g _i_n _t_h_e _C_X_I _I_n_p_u_t _D_a_e_m_o_n_s
  
       Log in all CXI input  daemons (one for each frontend defined
  in the NIT)  either as part of system startup  (i.e., via command
  lines   in   the    system_start_up.ec)   or   through   operator
  intervention.  These daemons should be logged in at ring 2.
  
  
  _S_t_a_r_t_i_n_g _t_h_e _C_X_I _S_u_b_s_y_s_t_e_m
  
       The CXI subsystem is the mechanism through which a CXI input
  daemon manages a frontend.   Included in the subsystem repertoire
  are requests to:
  
       ox    Load and execute a generator image
  
       ox    Load, execute, and start a runnable image
  
       ox    Dump a frontend
  
       ox    Start the daemon's CXI driver
  
  
       Use  the cxi_input_daemon  (cid) command  to invoke  the CXI
  subsystem.  The  subsystem runs in the  daemon process associated
  with  the  frontend  named  on  the  command  line.  Usually, the
  cxi_input_daemon  command is executed  in the CXI  input daemon's
  start_up.ec.  See Section 5 for a complete description of the CXI
  subsystem and the cxi_input_daemon command.
  
  
  _L_o_a_d_i_n_g _a_n_d _E_x_e_c_u_t_i_n_g _a _G_e_n_e_r_a_t_o_r _I_m_a_g_e
  
       A generator image file (in these examples, imamem.i) is used
  to tailor a DN8/7100 and produce  a runnable image file (in these
  examples, runnable_image.i) from which the frontend is started up
  on  the network.   The generator  image must  be loaded  into the
  frontend  and executed  so that  it can  read in  the appropriate
  config  file, patches,  and  object  segments converted  from the
  supplied DNS software.  Load and  execute a generator image for a
  frontend only when  the config file has been altered  or when you
  want to apply new patches (PATCH0 and PATCH1).
  
  
       Use  the CXI  subsystem  load_frontend  request to  load the
  appropriate  generator image  into  the  frontend.  Then  use the
  execute_in_frontend  request to  execute the  generator image and
  produce  a  runnable  image.   Finally,  use  the  start_frontend
  request  to   start  the  runnable  image.    The  load_frontend,
  execute_in_frontend,  and start_frontend  CXI subsystem  requests
  are described in detail in Section 5.
  
  
  
  
                                 2-19
  
  
  _L_o_a_d_i_n_g_, _E_x_e_c_u_t_i_n_g_, _a_n_d _S_t_a_r_t_i_n_g _a _R_u_n_n_a_b_l_e _I_m_a_g_e
  
       A  runnable image  produced by  executing a  generator image
  must be loaded into the  appropriate frontend and executed (using
  the load_frontend and execute_in_frontend requests) before it can
  be  started (using  the start_frontend  request).  Load, execute,
  and start a runnable image for  each frontend each time you start
  up DSA on  Multics.  See Section 5 for a  complete description of
  these requests as they are used with a runnable image.
  
  
       See  Appendix   B  for  exec_coms  cidec   used  by  DSA_CXI
  sub_system  These exec_coms load,  execute, and start  a runnable
  image in the current frontend.
  
  
  _S_t_a_r_t_i_n_g _t_h_e _C_X_I _D_r_i_v_e_r
  
       Once  a frontend  is running  (its runnable  image has  been
  started),  the CXI driver  for the input  daemon can be  started.
  Invoke the start_driver request as described in Section 5.
  
  
  _L_o_g_g_i_n_g _i_n _t_h_e _O_t_h_e_r _D_S_A _D_a_e_m_o_n_s
  
       Ensure  that all  other DSA  daemons, i.e., DSA_DSAC.Daemon,
  Login_Server.Daemon, and  DSA_UFT.SysDaemon, have been  logged in
  either as part of system startup  (i.e., via command lines in the
  system_start_up.ec) or through operator intervention.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 2-20
  
  
  
  
  
  
  
  
  
                              SECTION 3
  
  
                         NETWORK LOGIN SERVER
  
  
  
  
       To  administer a  Multics node  in a  DSA network,  you must
  login and  activate the network login server.   The network login
  server is a daemon process that you assign to monitor one or more
  network  endpoints.   The  login   server  daemon  "listens"  for
  incoming  session  requests  submitted  to  the  endpoints.   The
  session requests  can be either  login requests or  file transfer
  requests.
  
  
       When  the  login  server   daemon  receives  a  DSA  session
  establishment  letter  on  the  LOGIN  mailbox,  it establishes a
  session and then engages in a login dialogue with the user who is
  trying  to connect  to Multics.    The login  server daemon  then
  passes the  user's name and  password information to  the Multics
  initializer  process  for  validation.   If  the  user's name and
  password  information  are  not  deemed  valid,  the login server
  daemon terminates  the session .   If they are  deemed valid, the
  user is permitted  access to Multics and the  login server daemon
  requests the creation of a new user process from the initializer.
  Once the initializer creates the  new user process, it passes the
  process_id  to  the  login  server  daemon,  which  delegates the
  session  to that process.   If the session  is terminated by  the
  network for any reason, session  control signals this fact to the
  login  server.  The  login server  then asks  the initializer  to
  terminate  the user  process.   Assuming  that the  session isn't
  terminated by the network, when the user terminates processing in
  the  Multics system,  the initializer  signals this  fact to  the
  login server daemon.  The login server daemon then terminates the
  session.
  
  
       When  the  login  server   daemon  receives  a  DSA  session
  establishment letter on the FILETRAN  mailbox, it receives all of
  the login information necessary for  Multics in that letter.  The
  login  server   daemon  passes  the  user's   name  and  password
  information  to the  Multics initializer  process for validation.
  If the user's  name and password are not deemed  valid, a session
  is not established.   If they are deemed valid,  the login server
  
  
                                 3-1
  
  
  
  daemon establishes a  session and requests the creation  of a new
  user process from the  initializer.  Once the initializer creates
  the user  process, it passes  the process_id to  the login server
  daemon,  which delegates  the session  to that  process.  If  the
  session  is terminated  by the  network for  any reason,  session
  control signals this fact to  the login server.  The login server
  then  asks  the  initializer   to  terminate  the  user  process.
  Assuming that  the session isn't terminated by  the network, when
  the  user  terminates  processing  in  the  Multics  system,  the
  initializer signals  this fact to  the login server  daemon.  The
  login server daemon then terminates the session.
  
  
       The  login server  daemon uses  a special  process overseer,
  login_server_overseer_.   This   process  overseer  automatically
  starts the login server subsystem.  To communicate with the login
  server daemon, you use a  set of login server subsystem requests.
  These requests are described later in this section under "Network
  Login Server Requests."
  
  
  _R_E_G_I_S_T_E_R_I_N_G _T_H_E _L_O_G_I_N _S_E_R_V_E_R _D_A_E_M_O_N
  
       The  login  server   daemon  (Login_Server.Daemon)  must  be
  registered  and installed  as part   of the  Multics DSA  startup
  process.  This process is described in Section 2 of this manual.
  
  
  _S_T_A_R_T_I_N_G _T_H_E _L_O_G_I_N _S_E_R_V_E_R _R_E_Q_U_E_S_T _M_E_C_H_A_N_I_S_M
  
       The  login  server  communicates  with  the Initializer user
  control  subsystem using  the send_ls_request_  subroutine.  This
  subroutine  queues requests for  Initializer action in  a message
  segment.   The   ls_request_server_  mechanism  running   in  the
  Initializer process  handles these requests, and  sends responses
  back to the login server.  The  facility is similar to the answer
  service  request mechanism  used to  send admin  commands, daemon
  commands, and similar requests to the answering service.
  
       To     start    the    ls_request_server_,     invoke    the
  ls_request_server  command  as  described  below.   This  command
  should be added to the system_start_up.ec.
  
  
  
  
  
  
  
  
  
  
  
  
                                 3-2
  _________________                               _________________
  
  ls_request_server                               ls_request_server
  _________________                               _________________
  
  
  NAME: LS_REQUEST_SERVER
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ls_request_server operation
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _F_U_N_C_T_I_O_N
  
  [ls_request_server operation]
  
  _F_U_N_C_T_I_O_N
  
  This command starts and stops  the login server request mechanism
  which runs in the user  control portion of the Answering Service.
  It also  starts and stops  the connection list  manager.  Both of
  these  facilities are  needed in  order to  run the  login server
  daemon.
  
  _A_R_G_U_M_E_N_T_S
  
  operation
     can  be one of  the operations given  in "List of  operations"
     below.
  
  _L_I_S_T _O_F _O_P_E_R_A_T_I_O_N_S_:
  
  
  start
     starts  operation of  the ls_request_server_  mechanism in the
     Initializer       process,      and       initializes      the
     connection_list_manager_.
  
  stop
     stops  operation of  the ls_request_server_  mechanism in  the
     Initializer      process,     and      shuts     down      the
     connection_list_manager_.
  
  _A_C_C_E_S_S _R_E_Q_U_I_R_E_D_:
  
  This  command can  only be  executed in  the Initializer process,
  while   in  admin   mode.   It    requires  re   access  to   the
  hpriv_connection_list_ gate.
  
  _N_O_T_E_S
  
  The  ls_request_server_  mechanism  has  not  been  certified for
  operation  at the  B2  security  level.  Therefore,  this command
  should  not be used  at sites desiring  to run only  B2 certified
  software.
  
  
                                 3-3
  _________________                                          ______
  
  ls_request_server                                          login,
  _________________                                          ______
  
  
  _L_O_G_G_I_N_G _I_N _T_H_E _L_O_G_I_N _S_E_R_V_E_R _D_A_E_M_O_N
  
       The   login  server   daemon   may   be  logged   in  either
  automatically at  system startup (via the  system_start_up.ec) or
  manually by an operator or administrator.
  
  
       If  logged in  automatically  at  system startup,  the login
  server  daemon is controlled  from the initializer  terminal.  If
  logged in manually,  the login server will normally  be logged in
  from  the initializer  terminal.  Alternatively,  the operator or
  administrator can  login the login server daemon  from any remote
  terminal.  However,  in this case,  the terminal is  dedicated to
  communication with the login server daemon and cannot be used for
  other purposes.
  
  
       To login  the login server  daemon from the  the initializer
  terminal, execute the following command line:
  
       login  Login_Server.Daemon  <login_server_daemon_label>
  
  where  "login_server_daemon_label" is a  user-selected identifier
  that  will later  be used   in the  initializer reply  command to
  direct input to the daemon.
  
  The following are changes to the login Preaccess Command:
  
  
               ________________________________________
  
  
  NAME: LOGIN,, L
  
  _S_Y_N_T_A_X
  
  l Person_id{.Project_id} {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  This is a login preaccess command.
  
  
  
  
  
  
  
  
  
  
                                 3-4
  ______                                                     ______
  
  login,                                                     login,
  ______                                                     ______
  
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
          (operator login)
  
  -operator, -op
     logs in the user as a system operator, connecting the terminal
     to the  message coordinator.  The user must  have the operator
     attribute to use this control argument.
  
  -virtual_channel STR, -vchn STR
     connects  the  terminal  to  the  message  coordinator virtual
     channel STR, which has been  preaccepted by the operator using
     the accept_vchn operator command.
  
  -exact
  
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
          (disconnected processes):
  
  -connect {N}
     connects the  terminal to your disconnected  process.  If more
     than  one such process  exists, the process  number N must  be
     indicated.
  
  
  _C_O_N_T_R_O_L_L_I_N_G _T_H_E _L_O_G_I_N _S_E_R_V_E_R _D_A_E_M_O_N
  
       Once  the  login  server  daemon   is  logged  in,  you  are
  responsible  for   specifying  the  endpoints  that   are  to  be
  monitored.     This    action    is    accomplished    with   the
  start_login_service    request.    You    can   issue    multiple
  start_login_service   requests,  each   specifying  a   different
  endpoint.
  
  
       To  specify  that  the  login   server  daemon  is  to  stop
  monitoring  an endpoint,  use the  stop_login_service request.  A
  stop_login_service  on a specified  endpoint will stop  all login
  servers listening on this endpoint,  not just the endpoint of the
  login server in which the request is entered.
  
  
       Additionally, there are several other requests available for
  use  with  the  login  server  daemon.   These  include  the help
  request,  the list_help  request, the  list_requests request, the
  self_identify  request,  and  the  quit  request.   All the login
  server daemon requests are described in detail below.
  
  
  
  
                                 3-5
  ______                                                       ____
  
  login,                                                       help
  ______                                                       ____
  
  
       Note that if the initializer terminal is used to control the
  login server  daemon (the usual method), the  above requests must
  be used  in combination with the initializer  reply command.  For
  example,  to execute  the stop_login_service  command on  a login
  server daemon with a label of lsd, execute the following command:
  
       reply lsd stop_login_service dsa.MUL1.LOGIN
  
  
  _N_E_T_W_O_R_K _L_O_G_I_N _S_E_R_V_E_R _R_E_Q_U_E_S_T_S
  
       The following  are descriptions of the requests  that can be
  used with the login server daemon.
  
  
               ________________________________________
  
  
  NAME: SELF_IDENTIFY
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  .
  
  _F_U_N_C_T_I_O_N
  
  prints the name and version of the login server subsystem.
  
  
               ________________________________________
  
  
  NAME: HELP
  
  _S_Y_N_T_A_X
  
  help topic(s) {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  prints information about the selected topic(s).
  
  _A_R_G_U_M_E_N_T_S
  
  topic(s)
     is  the topic for  which information is  to be printed.   More
     than one topic can be specified.  The list of available topics
     can be obtained by using the list_help request (described next
     in this section).
  
  
                                 3-6
  ____                                                   __________
  
  help                                                   list_help,
  ____                                                   __________
  
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -brief, -bf
     prints  only  a  summary  of  a  request  or  active  request,
     including  the  Syntax  section,  list  of  arguments, list of
     control arguments, etc..
  
  -search STRs, -srh STRs
     begins printing with the  paragraph containing all the strings
     specified by STRs.  By default,  printing begins at the top of
     the information.
  
  -section STRs, -scn STRs
     begins printing  at the section  whose title contains  all the
     strings specified by STRs.  By default, printing begins at the
     top of the information.
  
  -title
     prints section  titles and section  line counts, then  asks if
     the user wants to see the first paragraph of information.
  
  
               ________________________________________
  
  
  NAME: LIST_HELP,, LH
  
  _S_Y_N_T_A_X
  
  lh {string}
  
  _F_U_N_C_T_I_O_N
  
  displays  a  list  of  all  topics  for  which information can be
  printed.
  
  _A_R_G_U_M_E_N_T_S
  
  string
     specifies  a portion  or part  of a  topic name.   See "Notes"
     below for instruction on the use of this argument.
  
  
  
  
  
  
  
  
  
  
                                 3-7
  __________                                         ______________
  
  list_help,                                         list_requests,
  __________                                         ______________
  
  
  _N_O_T_E_S
  
  If a portion or part of a topic name is specified as an argument,
  the  system can  "match" the  argument with  a topic  only if the
  given series of characters occurs at  the beginning or end of the
  topic name.  As  a hypothetical example, if the  string "ex" were
  specified, the  system could match  such topic names  as expunge,
  execute, and trans_specs_ex.
  
  
               ________________________________________
  
  
  NAME: LIST_ENDPOINTS,, LSEP
  
  _S_Y_N_T_A_X
  
  lsep
  
  _F_U_N_C_T_I_O_N
  
  Lists end  points which are listening for  connections, and those
  which have stopped listening  but have still connections.  Output
  includes  the number  of  connections  attached through  each end
  point.
  
  
               ________________________________________
  
  
  NAME: LIST_REQUESTS,, LR
  
  _S_Y_N_T_A_X
  
  lr {request(s)} {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  prints a list and brief description of the specified requests.
  
  _A_R_G_U_M_E_N_T_S
  
  request(s)
     specifies  the request(s)  to be   listed.  If  no request  is
     specified, a list of all requests is provided.
  
  
  
  
  
  
                                 3-8
  ______________                                              _____
  
  list_requests,                                              quit,
  ______________                                              _____
  
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -all, -a
     includes undocumented  and unimplemented requests in  the list
     of requests eligible for listing.
  
  -exact
     lists  only  those  requests  whose  names  exactly  match the
     specified request(s)
  
  
               ________________________________________
  
  
  NAME: QUIT,, Q
  
  _S_Y_N_T_A_X
  
  q
  
  _F_U_N_C_T_I_O_N
  
  exits  from the  login server  subsystem and  logs out  the login
  server daemon.  Note that this request does NOT return to Multics
  command level.
  
  _N_O_T_E_S
  
  If the  quit request is issued  when there are any  endpoints for
  which  the  start_login_service  request  has  been  issued  more
  recently than the stop_login_service request, these messages will
  be displayed:
  
     The following endpoints are active:
        <list of endpoint names, with count of active connections
         for each>
     login_server_: Outstanding connections will not be cleaned up
        properly.  Do you want to quit?
  
  If  the operator  answers "yes",  the login  server subsystem  is
  exited.  If  the operator answers  "no", no action  is taken, and
  the login server awaits further requests.
  
  
  
  
  
  
  
  
  
                                 3-9
  ___________________                            __________________
  
  start_login_service                            stop_login_service
  ___________________                            __________________
  
  
  NAME: START_LOGIN_SERVICE
  
  _S_Y_N_T_A_X
  
  start_login_service endpoint_name
  
  _F_U_N_C_T_I_O_N
  
  specifies  that  the  login  server  daemon  is  to  monitor  the
  designated endpoint.
  
  _A_R_G_U_M_E_N_T_S
  
  endpoint_name
     is the name of an endpoint in the Multics node of the network.
     The name specified by endpoint_name  must also be specified by
     a Mailbox statement in a Mailbox object definition in the NIT.
  
  
  _E_X_A_M_P_L_E_S
  
  To  specify  that  the  login  server  daemon  is  to monitor the
  endpoint identified as dsa.MUL1.LOGIN, type the following:
  
     start_login_service dsa.MUL1.LOGIN
  
  
  
               ________________________________________
  
  
  NAME: STOP_LOGIN_SERVICE
  
  _S_Y_N_T_A_X
  
  stop_login_service endpoint_name
  
  _F_U_N_C_T_I_O_N
  
  specifies that the login server  daemon is to stop monitoring the
  designated endpoint.
  
  _A_R_G_U_M_E_N_T_S
  
  endpoint_name
     is the name of an endpoint in the Multics node of the network.
     The name specified by endpoint_name  must also be specified by
     a Mailbox statement in a Mailbox object definition in the NIT.
  
  
  
                                 3-10
  __________________                             __________________
  
  stop_login_service                             stop_login_service
  __________________                             __________________
  
  
  _N_O_T_E_S
  
  A stop_login_service on a specified  endpoint will stop all login
  servers listening on this endpoint,  not just the endpoint of the
  login server in which the request is entered.
  
  _E_X_A_M_P_L_E_S
  
  To specify that the login server daemon is to stop monitoring the
  endpoint designated as dsa.MUL1.FILETRAN, type:
  
     stop_login_service dsa.MUL1.FILETRAN
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 3-11
  
  
  
  
  
  
  
  
  
                              SECTION 4
  
  
                      NETWORK INFORMATION TABLE
  
  
  
  
  
  
  This section  describes the network information  table (NIT).  It
  explains  the purpose  of the  NIT, and  describes how  to build,
  compile, install, and update a NIT.   It discusses all of the DSA
  objects defined in Multics, and provides detailed explanations of
  how  to  describe  these  objects  in  the  NIT  using NIT source
  language.   It also  offers a  complete example  of a  NIT source
  table.
  
  
  _T_H_E _P_U_R_P_O_S_E _O_F _T_H_E _N_I_T
  
       The NIT is your main tool for configuring a DSA network.  It
  contains  all of the  information which is  needed to run  DSA on
  Multics.  It  defines the local  system and those  remote systems
  which are part of the network  in terms of the entities, drivers,
  devices,  services,  addresses,  and  protocols  which constitute
  them.
  
  
       The NIT is a shared data base which consists of two kinds of
  data.  The  first kind is administrative data  which you maintain
  and   which  session  control   uses.   This  data   consists  of
  information  about   all  of  the   DSA  objects  which   can  be
  administratively   controlled   (for   example,   frontends,  DSA
  mailboxes, and session  routes).  The second kind of  data in the
  NIT is dynamic data which session control maintains, and which it
  uses to  keep track of  the operation of  logical connections and
  sessions.  Only the first kind of data in the NIT, that which you
  maintain, is described here.
  
  
       The  NIT  provides  information  mapping  which  is  used by
  various networking entities.  Each entity uses the information it
  is passed by its caller to find out which entity to call next and
  what information to pass to it.  Supplied with the information an
  entity  is passed by  its caller, the  NIT provides entries  that
  
  
                                 4-1
  
  
  
  perform the necessary mappings for the entity.  Since each entity
  already has coded into it the calls to the entries of the service
  facilities  that it uses,  the information it  gets from the  NIT
  consists of the arguments to  these entries (i.e., the NIT allows
  an entity to call another entity and  just pass it a name to look
  up in the  NIT, where it can find the rest  of the information it
  needs, rather than pass it all of the information).
  
  
       For  example,  when   dsa_transport_service_  is  called  by
  session control to  establish a connection to the  next layer, it
  has to decide which entity to call to do so; when it is called by
  a lower transport level layer to propagate an incoming connection
  to the next layer, it has to decide which layer to call to do so.
  In each case, the decision is made on the name of the next entity
  that is to process the connection.   The NIT provides the name of
  the next  entity so that  dsa_transport_service_ is able  to tell
  which set of entry points to call to process the connection.
  
  
  _B_U_I_L_D_I_N_G _A _N_I_T
  
       You  are responsible for  creating a NIT  for your site  and
  keeping  it updated.  The  NIT is similar  to many other  Multics
  tables, such  as the CMF  and the SAT,  in that you  create it by
  building an  ASCII table, compiling  it into a  binary table, and
  then installing it.  An ASCII file which contains a sample NIT is
  supplied on the  Multics system tape.  You may edit  this file to
  describe the configuration at your site, or build your own source
  table  from scratch.  To  build a source  table, use any  Multics
  editor  (qedx,  ted,  or  emacs),  and  the  NIT  source language
  described  below.    To  compile  and  install   the  table,  see
  "Compiling a NIT"  and "Installing a NIT" later  in this section.
  Note that,  by convention, the  source table is  named "NIF.nif",
  and is created in the directory >udd>sa>a.
  
  
  _N_I_T _S_O_U_R_C_E _L_A_N_G_U_A_G_E
  
       NIT source language consists of statements and substatements
  which define and describe Multics  DSA objects and certain global
  items.  Statements provide the name  of the object or global item
  which  is  being  described.   Substatements  provide information
  about various attributes of the object or item.
  
  
       A group  of statements and  substatements for one  object is
  called  an  object  definition.   A  source  table  consists of a
  sequence  of object  definitions  and  an "End;"  statement.  The
  object  definitions may  be in  any order.   The "End;" statement
  must be the last thing in the table, as shown below.
  
  
  
                                 4-2
  
  
  
       Object_definition_1
       .
       .
       .
       Object_definition_N
       End;
  
  An object  definition consists of  a statement, a  sequence of its
  associated substatements, and an "end;" statement.  The statement
  must be the  first thing in the object definition  and the "end;"
  statement must be  the last thing in the  object definition.  The
  substatements in between may be in any order, as shown below.
  
       Statement
          substatement_1
          .
          .
          .
          substatement_N
       end;
  
  
  _N_I_T _S_o_u_r_c_e _L_a_n_g_u_a_g_e _S_y_n_t_a_x
  
       The   syntax   of   the   source   language  statements  and
  substatements is of the form:
  
       <keyword>:  <parameter(s)>;
  
  The only  exceptions to this are  the Mna_general_info statement,
  the end statement, and the End statement, all of which are of the
  form:
  
       <keyword>;
  
  Keywords are literals.  The keyword  of a statement begins with a
  capital  letter.  The  keyword of  a substatement  begins with  a
  lowercase  letter.    Parameters  are  basically   free  strings,
  although some  of them must follow certain  rules or conventions.
  When more  than one parameter  follows a keyword,  the parameters
  are separated by commas:
  
       Keyword: free_string;
          keyword: free_string_1, ..., free_string_N;
          keyword: free_string;
       end;
  
  
       PL/I style comments beginning with "/*" and ending with "/*"
  may appear anywhere within  the source table.  Similarly, blanks,
  tabs, and  new lines not  embedded within a  keyword or parameter
  are  ignored.  However,  in order  to include  blanks, tabs,  new
  
  
                                 4-3
  
  
  
  lines,  colons, or  semicolons in  a parameter,  you must enclose
  them  in  quotes.   If  a  parameter  begins  with  a  quote, all
  immediately  following characters  up  until  the next  quote are
  taken as the parameter.  It is  possible to embed quotes within a
  quoted string using the double quoting escape convention of PL/I.
  
  
  _N_I_T _O_B_J_E_C_T _D_E_F_I_N_I_T_I_O_N_S
  
       The  objects defined in  the NIT are  listed below by  their
  source statement keywords:
  
       Service
       Session_type_descriptor
       Sc_loc
       Mailbox
       Admin_function
       Admin_group
       Ts
       Frontend
       Session_Route
       System
       Correspondent
       Admin_correspondent
  
  The global items defined in the NIT are:
  
       Mna_general_info
       Dsac_info
  
  Note that if  the same source statement keyword  occurs more than
  once in  the NIT, the  free strings associated  with the keywords
  must  each be unique;  i.e., no object  may be defined  more than
  once with the same name.
  
  
       The  figure "Object  Relations in  DSA" shows  the relations
  between the various  objects defined in the NIT.   The two global
  items defined in the NIT, Mna_general_info and Dsac_info, are not
  represented in this  figure, because they are not  really part of
  the architecture, but rather are configuration descriptions.
  
  
       What  follows are  descriptions of  all of  the objects  and
  global items in  the NIT, along with the syntax  needed to define
  them.  An example  is given at the end of  each description which
  shows a  standard object definition.  You are  also encouraged to
  look at the sample NIT source table near the end of this section.
  
  
  
  
  
  
                                 4-4
  
  
  
  OBJECT RELATIONS IN DSA
  
            LAYERS                            DSA OBJECTS
  
       -------------------
       |   Application   |                    Service(s)
       |      TM         |
       |      UFT        |
       |      DSAC       |
       -------------------
         |
         |
       - | ------------------------           Sc_loc
       | |   DSA session control  |                  +
       | ||||                     |           Mailbox(es) --|
       | \/  (several mailboxes)  |           Admin_function(s)
       | mailbox (with a default  |                  +
       |           STD)           |      Session_type_descriptor(s)
       ---------------------------
         ||||                   <------------ Session_Route(s)
         |   (several transport controls)
         |
       - | -----------------------            Ts(s)
       | |   transport control    |
       | -------------....        |
       | |         | ....         |
       | \/        \/             |
       | TC endpoint  ...   ...   |
       ----------------------------
                 || DIA(s) ----------->       Frontend(s)
          /-------------------\
          |   DSA NETWORK     |
          \ (outside Multics) /
           -------------------
            /            \
             ----------------------------
             |system (DN8, DPS7, Multics)|
             |(one session control)      |   System(s)
             ----------------------------
                 | mbx | ... |   | ...|      Correspondent(s)
                 ----------------------           or
                 |  ^  |              |      Admin_correspondent(s)
                 |  |  \              |        ^                ^
                 |Appli-\ ---         |        |                |..
                 |cation or terminal  |        --------------------
                 ----------------------           Admin_group(s)
  
  
  
  
  
  
  
  
                                 4-5
  
  
  
  _M_n_a___g_e_n_e_r_a_l___i_n_f_o
  
       The   Mna_general_info   statement    and   its   associated
  substatements   define  configuration    data  for   the  Multics
  networking  architecture (MNA).   Note that  the Mna_general_info
  statement  is  not  followed  by  a  colon,  a  parameter,  and a
  semicolon,  but  only  by  a  semicolon.   There  can only be one
  Mna_general_info statement in the NIT.
  
  
  SYNTAX
  
  Mna_general_info;
     cxi_driver_segment: <cxi_driver_segment_pathname>;
     dsa_system_log: <dsa_system_log_pathname>;
     dsa_system_aep_log: <dsa_system_aep_log_pathname>;
     dsa_aep_log: <dsa_aep_log_pathname>;
     sc_exerciser_wdir: <sc_exerciser_wdir_pathname>;
     sc_handle_manager_wdir: <sc_handle_manager_wdir_pathname>;
     default_tm_mailbox: <default_tm_mailbox_name>;
     default_uft_mailbox: <default_uft_mailbox_name>;
     default_exe_init_mailbox: <default_exe_init_mailbox_name>;
     dsa_uft_value_seg: >site>dsa>data>uft.value;
  end;
  
  where:
  
  cxi_driver_segment_pathname
       is the absolute pathname of the shared segment where the CXI
       input  daemons store  their data.   You are  responsible for
       creating   the   directory.     The   segment   is   created
       automatically when you execute the dsa_init command to start
       up session control.  It may also be created by executing the
       cxi_create_driver_seg command.  Refer to  Section 2 for more
       information.
  
  dsa_system_log_pathname
       is the absolute  pathname of the log in which  the CXI input
       daemons and  session control record their  errors, messages,
       traces,   etc.   You   are  responsible   for  creating  the
       directory.  The log is  created automatically.  Note that it
       is a ring 2 log.
  
  dsa_system_aep_log_pathname
       is the absolute  pathname of the log in which  the CXI input
       dameons  and session control  store their AEP  records.  You
       are  responsible for  creating  the  directory.  The  log is
       created automatically.  Note that it is a ring 2 log.
  
  
  
  
  
  
                                 4-6
  
  
  
  dsa_aep_log_pathname
       is the  absolute pathname of the  log in which UFT  and DSAC
       (including  the network  session exerciser)  store their AEP
       records.   You are  responsible for  creating the directory.
       The log is created automatically.  Note  that it is a ring 4
       log.
  
  sc_exerciser_wdir_pathname
       is the absolute pathname of  the directory where the session
       control  exerciser creates  segments for  its own  purposes.
       You are responsible for  creating this directory.  A warning
       is  printed  if  this  directory   does  not  exist  at  NIT
       compilation time.
  
  sc_handle_manager_wdir_pathname
       is  the absolute  pathname  of  the directory  where session
       control  creates the  handle table  segment (dsa_sc_hm_seg).
       You are responsible for  creating this directory.  A warning
       is  printed  if  this  directory   does  not  exist  at  NIT
       compilation  time.   The  handle  table  segment  is created
       automatically when session control  is started for the first
       time.  Refer to Section 2 for more information.
  
  default_tm_mailbox_name
       is  the local  mailbox that  is used  to initiate  a logical
       connection  for TM  if  the  correspondent specified  by the
       caller is not defined in the NIT.  This is a free name of up
       to  32 characters, but  the convention is  to create a  name
       with the following syntax:
  
            dsa.<session_control_name>.<mbx_dsa_name>
  
       for example:
  
            dsa.MUL1.TMDIALOU
  
       The  parameters  session_control_name  and  mbx_dsa_name are
       defined under the Mailbox  object definition.  Note that the
       mailbox specified by default_tm_mailbox_name must be defined
       by a Mailbox object definition.
  
  default_uft_mailbox_name
       is  the local  mailbox that  is used  to initiate  a logical
       connection  for UFT  if the  correspondent specified  by the
       caller is not defined in the NIT.  This is a free name of up
       to  32 characters, but  the convention is  to create a  name
       with the following syntax:
  
            dsa.<session_control_name>.<mbx_dsa_name>
  
       for example:
  
  
  
                                 4-7
  
  
  
            dsa.MUL1.UFT_REQ
  
       The  parameters  session_control_name  and  mbx_dsa_name are
       defined under the Mailbox  object definition.  Note that the
       mailbox   specified  by  default_uft_mailbox_name   must  be
       defined by a Mailbox object definition.
  
  default_exe_init_mailbox_name
       is  the local  mailbox that  is used  to initiate  a logical
       connection  for the  session exerciser  if the correspondent
       specified by the caller is not  defined in the NIT.  This is
       a free name of up to 32 characters, but the convention is to
       create a name with the following syntax:
  
            dsa.<session_control_name>.<mbx_dsa_name>
  
       for example:
  
            dsa.MUL1.$NSF
  
       The  parameters  session_control_name  and  mbx_dsa_name are
       defined under the Mailbox  object definition.  Note that the
       mailbox  specified by default_exe_init_mailbox_name  must be
       defined by a Mailbox object definition.
  
  dsa_uft_value_seg
       defines the pathname of a value segment used by UFT for site
       specific information.
  
  
  EXAMPLE
  
  Mna_general_info;
     cxi_driver_segment: >site>dsa>data>cxi_driver_seg;
     dsa_system_log: >site>dsa>system_logs_dir>dsa_sl;
     dsa_system_aep_log: >site>dsa>system_logs_dir>dsa_sal;
     dsa_aep_log: >site>dsa>aep_logs_dir>dsa_al;
     sc_exerciser_wdir: >site>dsa>data;
     sc_handle_manager_wdir: >site>dsa>data;
     default_tm_mailbox: dsa.MUL1.TMDIALOU;
     default_uft_mailbox: dsa.MUL1.UFT_REQ;
     default_exe_init_mailbox: dsa.MUL1.$NSF;
     dsa_uft_value_seg: >site>dsa>data>uft.value;
  end;
  
  
  
  
  
  
  
  
  
  
                                 4-8
  
  
  
  _S_e_r_v_i_c_e
  
       The  Service  statement  and  its  associated  substatements
  define  a service.  Services  are defined in  the NIT to  provide
  applications  (for example,  the  login  server daemon)  with the
  ability to call generic entry  points to obtain precise services.
  When  an  application  wants  a  service  to  be  provided  on  a
  particular endpoint, it calls dsa_nit_$get_service_entries, which
  in  turn calls  a module   (specified in  the description  of the
  service  in  the  NIT)  in  its  get_service_entries entry.  This
  module returns  a list of  the entrypoints which  the application
  should  call in  order to   access the  service.  Note  that each
  endpoint has a service associated  with it, and that each service
  can  be provided on  more than one  endpoint.  There can  be more
  than one Service statement in the NIT.
  
  
  SYNTAX
  
  Service: <service_name>;
     endpoint: <endpoint_name1>;
        get_service_module: <gsm_module_name1>;
     end;
     .
     .
     .
     {endpoint: <endpoint_namen>;
        get_service_module: <gsm_module_namen>;
     end;}
  end;
  
  where:
  
  service_name
       is the name of  the service.  It is a free name  of up to 32
       characters.   Note that  service_name is  referenced in  the
       Mailbox,    Admin_function,    and    Correspondent   object
       definitions.
  
  endpoint_name
       is the name  of an endpoint on which this  service should be
       provided.  It is a free name of up to 32 characters, but the
       convention is to create a name with the following syntax:
  
            dsa.<session_control_name>.<mbx_dsa_name>
  
       for example:
  
            dsa.MUL1.LOGIN
  
       The  parameters  session_control_name  and  mbx_dsa_name are
       defined under the Mailbox  object definition.  Note that the
  
  
                                 4-9
  
  
  
       endpoint  specified by  endpoint_name must  be defined  by a
       Mailbox  object definition.   If more  than one  endpoint is
       specified  for a service,  no two of  them can be  the same;
       i.e.,  every endpoint_name  in a  Service object  definition
       must be unique.
  
  gsm_module_name
       is the absolute pathname of a  module which is called in its
       get_service_entries   entry   when   an   application  calls
       dsa_nit_$get_service_entries  to   return  a  list   of  the
       entrypoints  to call  in order  to access  this service.   A
       warning is printed if the segment which contains this module
       does not exist at NIT compilation time.
  
       The currently-supplied modules are:
  
            dsa_tty_
            dsa_uft_login_service_
  
       which provide  the login service  (used by the  login server
       daemon software), and:
  
            dsa_dsac_lnad_
            dsa_dsac_ldsalog_
            dsa_dsac_nasf_
  
       which provide  the NAD, LOG,  and ASF services  (used by the
       DSA_DSAC daemon software).
  
       Note:  in the example below, and  in some of the examples in
       the sample NIT, you  will notice that the get_service_module
       field  is   sometimes  set  to  ">t>nothing".    This  is  a
       placeholder.  The  NIT software requires that  this field be
       set  to  something,  even  when  the  service  module is not
       required.  There  are two cases in which  the service module
       is not required.  One case is when the endpoint on which the
       service is being  provided is a local endpoint  used only to
       initiate  sessions  to  other  systems  from  Multics.   The
       software  which controls  such endpoints  needs to  know the
       name of  the mailbox and the  name of the service,  but does
       not need to know the name of a service module.  Another case
       is when  the service being provided  is "login_service", but
       the endpoint  on which it's being provided  is controlled by
       the  dssr  subsystem,  not   the  login  server.   The  dssr
       subsystem (described in Section 6) needs to know the name of
       the mailbox and  the name of the service, but  does not need
       to know the name of a service module.
  
  
  
  
  
  
  
                                 4-10
  
  
  
  EXAMPLE
  
  Service: login_service;
     endpoint: dsa.MUL1.LOGIN;
        get_service_module: >exl>dsa>e>dsa_tty_;
     end;
  
     endpoint: dsa.MUL1.LOGINT;
        get_service_module: >exl>dsa>e>dsa_tty_;
     end;
  
     endpoint: dsa.MUL1.FILETRAN;
        get_service_module: >exl>dsa>e>dsa_uft_login_service_;
     end;
  
     endpoint: dsa.MUL1.$NSE;
        get_service_module: >t>nothing; /* required placeholder */
     end;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-11
  
  
  
  _S_e_s_s_i_o_n___t_y_p_e___d_e_s_c_r_i_p_t_o_r
  
       The  Session_type_descriptor  statement  and  its associated
  substatements  define a  session  type  descriptor (STD).   A STD
  describes the  characteristics of a session  which an application
  wants  to establish,  including a  type of  behavior for  logical
  connections.  When  an application asks  session control to  do a
  connect  or   a  listen,  it   must  tell  session   control  the
  characteristics  of  the  session  it  wants  session  control to
  establish.  It  does this either by  providing its own STD  or by
  providing  session  control  with  the  name  of  one of the STDs
  defined  in  the  NIT.   Session  control  looks  up the name and
  extracts the  information it needs.  If the  application does not
  supply  session  control  with  an  STD  at  all, session control
  queries the NIT  for the default STD associated  with the mailbox
  in question.
  
       Note  that when you  define a STD  in the NIT,  the compiler
  first  fills in   the Session_type_descriptor  substatements with
  default  values, then  overrides them  with any  values which you
  have  provided in your  description of the  object in the  source
  table.   There  can  be  more  than  one  Session_type_descriptor
  statement in the NIT.
  
  
  SYNTAX
  
  Session_type_descriptor: <std_name>;
     {initiate_wait_time:  <delta_timer_value>;}
     {rcv_max_letter_size: <rcv_max_letter_size_value>;}
     {send_max_letter_size: <send_max_letter_size_value>;}
     {modes: {<session_mode1>} ... {, <session_modeN>};}
     {protocols: {<session_protocol1>} ... {, <session_protocolN>};}
     {options: {<session_option1>} ... {, <session_optionN>};}
  end;
  
  where:
  
  std_name
       is the  name of the session  type descriptor.  It is  a free
       name  of  up  to  32  characters.   Note  that  std_name  is
       referenced by the Mailbox object definition.
  
  delta_timer_value
       is the encoded value of the  timer that is set when an ILCRL
       is sent and reset when  the corresponding ILCAL is received,
       and also  set when an ILCRL  is received and reset  when the
       corresponding  ILCAL  is  sent.   This  parameter  must be a
       decimal number (N)  from 1 to 15, which is  interpreted as 2
  
  
  
  
  
                                 4-12
  
  
  
       ** (N-1) seconds (e.g., a value of 4 for N is interpreted as
       8 seconds).  A value of 15  for N is interpreted as infinite
       seconds, i.e., no timer.   This parameter is optional.  (The
       default is 4.)
  
  rcv_max_letter_size_value
       is  the  maximum  length  (in  bytes)  of  a  letter  on the
       receiving  flow.  This parameter  must be a  decimal string.
       This parameter is optional.  (The default is 1024.)
  
  send_max_letter_size_value
       is the maximum length (in bytes)  of a letter on the sending
       flow.   This  parameter  must  be  a  decimal  string.  This
       parameter is optional.  (The default is 1024.)
  
  session_mode
       is a mode of a session.  More than one mode may be specified
       in  order  to  provide  a  range  of  choices when a logical
       connection  is being negotiated.   Modes may be  chosen from
       the following list:
  
       twaa
            specifies that the mode is  two way alternate, with the
            initial turn to the acceptor.  (The default is off.)
  
       twai
            specifies that the mode is  two way alternate, with the
            initial turn to the initiator.  (The default is off.)
  
       twsa
            specifies that  the mode is two  way simultaneous, with
            the initial turn to the acceptor.  (The default is on.)
  
       twsi
            specifies that  the mode is two  way simultaneous, with
            the  initial turn  to the  initiator.  (The  default is
            off.)
  
       Note that  any value for  session_mode may be  preceded by a
       "^"  to  set  the   corresponding  value  to  "false."   The
       session_mode parameter is optional.
  
  session_protocol
       is  a protocol  supported on  a session.   Protocols may  be
       chosen from the following list:
  
       data_attention
            specifies that  both ends may send  data (80 characters
            maximum)  on the interrupt  flow of the  session.  (The
            default is ^data_attention.)
  
  
  
  
                                 4-13
  
  
  
       request_sru_acknowledge
            specifies  that both  ends may  use the sru_acknowledge
            mechanism.  (The default is ^request_sru_acknowledge.)
  
       recover
            specifies  that  both  ends  may  recover  data  on the
            session.  (The default is ^recover.)
  
       suspend
            specifies  that both ends  may suspend the  session and
            resume it later.  (The default is ^suspend.)
  
       Note that any value for  session_protocol may be preceded by
       a  "^"  to  set  the  corresponding  value  to "false."  The
       session_protocol parameter is optional.
  
  session_option
       is an option  defined for a session.  Options  may be chosen
       from the following list:
  
       mixed_records
            specifies  that  session  control  is  allowed to build
            letters  containing  both   user  records  and  control
            records.    If   this    option   is   specified,   the
            multiple_records option  must also be  specified.  (The
            default  is ^mixed_records;  i.e., letters  may contain
            either user records or control records, but not both.)
  
       multiple_records
            specifies  that  session  control  is  allowed to build
            letters containing  multiple records.  (The  default is
            multiple_records.)
  
       nine_bit
            specifies that the session may  operate in nine bit per
            byte mode.  (The default is ^nine_bit.)
  
       request_security
            specifies  that  when  a  session  is  established, the
            initiator must  put a submitter identity  record in the
            initiate  letter, and  the acceptor  of this connection
            must put a submitter identity record in the acknowledge
            letter.  (The default is ^request_security.)
  
       reusable_subchannel
            specifies  that session control  is allowed to  reuse a
            terminated     subchannel.      (The     default     is
            ^reusable_channel.)
  
       Note that any value for  session_option may be preceded by a
       "^"  to  set  the   corresponding  value  to  "false."   The
       session_option parameter is optional.
  
  
                                 4-14
  
  
  
  EXAMPLE
  
  Session_type_descriptor: login_listen_std;
     initiate_wait_time: 14;
     rcv_max_letter_size: 256;
     send_max_letter_size: 256;
     modes: twsa, twaa, twsi, twai;
     protocols: data_attention, suspend, recover,
                request_sru_acknowledge;
  end;
  
       Refer to the  sample NIT later in this  section for examples
  of   standard  Session_type_descriptor  object   definitions  for
  terminal  management (TM), the  session exerciser, UFT,  and mail
  applications, and for accessing remote NADs.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-15
  
  
  
  _S_c___l_o_c
  
       The Sc_loc statement and its associated substatements define
  the configuration data required to run one session control entity
  on Multics; i.e., they define the local session control.  Session
  control is an entity with a name  and a set of addresses which it
  defines  (for example,  a mailbox   is an  address which  session
  control  defines).  Session  control  is  the local  entity which
  communicates with the remote entity  defined by the System object
  definition.  There can only be one Sc_loc statement in the NIT.
  
  
  SYNTAX
  
  Sc_loc: <session_control_name>;
     working_dir: <session_wd_pathname>;
     {authorization: <authorization_value>;}
     {scid_300: <scid_name>;}
     dsa200_node_address: <dsa200_node_address>;
     {seg_info_name: <seg_info_segname>;}
     {lc_data_name: <lc_data_segname>;}
     {attributes: {<sc_attribute1>} ... {, <sc_attributeN>};}
     {timers: {cleanup_timer = <cleanup_timer_value>}
              {, delta_timer = <delta_timer_value>}
              {, idle_lc_timer = <idle_lc_timer_value>}
              {, recover_timer = <recover_timer_value>}
              {, resume_timer = <resume_timer_value>}
              {, suspend_timer = <suspend_timer_value>};}
  end;
  
  where:
  
  session_control_name
       is  the local name  of the local  session control.  It  is a
       free  name  of  up  to  32  characters.   However,  to avoid
       confusion, we recommend that it be set to the four character
       DSA  name  of  the  local  session  control.   In this case,
       scid_name  (below)   need  not  be  specified.    Note  that
       session_control_name   is   referenced   in   the   Mailbox,
       Dsac_info,   and  Session_Route   object  definitions.    It
       corresponds to system_name, defined  under the System object
       definition.
  
  session_wd_pathname
       is  the absolute  pathname of   the directory  in which  two
       shared segments are created when session control is running.
       The  two  segments  are  specified  by  seg_info_segname and
       lc_data_segname, described  below.  You are  responsible for
       creating  this  directory.   A  warning  is  printed if this
       directory does not exist at NIT compilation time.
  
  
  
  
                                 4-16
  
  
  
  authorization_value
       is  the AIM  authorization  given  to this  session control.
       This parameter is optional.  (The default is "system_low.")
  
  scid_name
       is the DSA  name of the local session control.   It is known
       all over  the DSA network, and  is used to access  the local
       session  control.   This  name   must  be  four  hexadecimal
       characters long.  If session_control_name  (above) is set to
       the four  character DSA name  of the local  session control,
       then the scid_name parameter need not be specified.
  
  dsa200_node_address
       specifies  the   address  of  the  DSA200   node  (which  is
       equivalent  to  the  DSA300  scid_name).   This parameter is
       required  for  purposes  of   compatibility.   It  allows  a
       negotiation at the same level  of protocol when a connection
       is established  with another node.   If the other  node is a
       DSA300  node, only  the scid_name  (or session_control_name)
       parameter is used.  But if the  other node is a DSA200 node,
       this parameter, dsa200_node_address, is used.
  
  seg_info_segname
       is the  entryname of the segment which  contains the general
       data  when  session  control  is  running.   This segment is
       created in  the directory specified  by session_wd_pathname,
       described  above, when the  dsa_init command is  executed to
       start   up  session  control.    See  Section  2   for  more
       information.  This  parameter is optional.  (The  default is
       "seg_info.")
  
  lc_data_segname
       is the  entryname of the segment which  contains the logical
       connection  objects when  session control  is running.  This
       segment   is   created   in   the   directory  specified  by
       session_wd_pathname,  described  above,  when  the  dsa_init
       command  is  executed  to  start  up  session  control.  See
       Section 2 for more information.  This parameter is optional.
       (The default is "lc_data.")
  
  sc_attribute
       is an  attribute of the session control.   Attributes may be
       chosen from the following list:
  
       automatic_init
            specifies  that  session  control  is  to  be restarted
            automatically  after  a   failure  has  occured.   (The
            default is automatic_init.)
  
  
  
  
  
  
                                 4-17
  
  
  
       trace_input_letter
            specifies  that all  incoming letters  from the network
            are  to be  traced.  Such  tracing should  be used with
            caution, since  it may produce  a large amount  of data
            and    saturate   the     logs.    (The    default   is
            ^trace_input_letter.)
  
       trace_output_letter
            specifies that all outgoing  letters to the network are
            to  be  traced.   Such  tracing  should  be  used  with
            caution, since  it may produce  a large amount  of data
            and    saturate   the     logs.    (The    default   is
            ^trace_output_letter.)
  
       trace_sm
            specifies that each state transition of a session is to
            be traced.   Such tracing should be  used with caution,
            since it may produce large amounts of data and saturate
            the logs.  (The default is ^trace_sm.)
  
       trace_transport_arg
            specifies that input arguments  for every call from the
            transport layer are to  be traced.  Such tracing should
            be  used with  caution, since  it may  produce a  large
            amount of data and saturate  the logs.  (The default is
            ^trace_transport_arg.)
  
       trace_user_arg
            specifies that input arguments  for every call from the
            application  layer  are  to  be  traced.   Such tracing
            should  be used  with caution,  since it  may produce a
            large  amount  of  data  and  saturate  the logs.  (The
            default is ^trace_user_arg.)
  
       The sc_attributes parameter is optional.
  
  The following  are optional timers which  may be set for  all the
  logical  connections  and  sessions  established  on this session
  control:
  
       cleanup_timer_value
            is  the maximum  amount  of  time (in  seconds) session
            control may wait before  destroying the environment for
            a session in the terminate state, assuming the owner of
            the  session does  not do  it himself.   This parameter
            must be a decimal string.  (The default is 15.)
  
       delta_timer_value
            is  the maximum  amount  of  time (in  seconds) session
            control may  wait for a response to  an initiate record
            sent to a remote  correspondent.  (Session control must
            receive  an  initiate-acknowledge  record  before  this
  
  
                                 4-18
  
  
  
            amount  of   time  elapses  or   it  may  not   open  a
            connection.)  This  parameter must be a  decimal string
            (N), which is interpreted as  2 ** (N-1) seconds (e.g.,
            a  value of 4  for N is  interpreted as 8  seconds).  A
            value of  15 for N is interpreted  as infinite seconds.
            (The default is 15.)
  
       idle_lc_timer_value
            is  the maximum  amount  of  time (in  seconds) session
            control  may wait before  establishing a session  on an
            idle   logical  connection.    (Session  control   must
            establish  a  session  on  an  idle  logical connection
            before  this  amount  of  time  elapses  or  it may not
            establish a session on it at all.)  This parameter must
            be a decimal  string (N), which is interpreted  as 2 **
            (N-1) seconds (e.g., a value  of 4 for N is interpreted
            as 8 seconds).   A value of 15 for N  is interpreted as
            infinite seconds.  (The default is 15.)
  
       recover_timer_value
            is  the maximum  amount  of  time (in  seconds) session
            control  may wait  for a  response to  a recover record
            sent to a remote  correspondent.  (Session control must
            receive a recover-acknowledge record before this amount
            of  time  elapses,  or  it  must  terminate the session
            abnormally.)  This parameter must  be a decimal string.
            (The default is 15.)
  
       resume_timer_value
            is  the maximum  amount  of  time (in  seconds) session
            control may wait for a response to a resume record sent
            to  a  remote  correspondent.   (Session  control  must
            receive a resume-acknowledge  record before this amount
            of  time  elapses,  or  it  must  terminate the session
            abnormally.)  This parameter must  be a decimal string.
            (The default is 15.)
  
       suspend_timer_value
            is  the maximum  amount  of  time (in  seconds) session
            control  may wait  for a  response to  a suspend record
            sent to a remote  correspondent.  (Session control must
            receive a suspend-acknowledge record before this amount
            of  time  elapses,  or  it  must  terminate the session
            abnormally.)  This parameter must  be a decimal string.
            (The default is 15.)
  
  
  
  
  
  
  
  
  
                                 4-19
  
  
  
  EXAMPLE
  
  Sc_loc: MUL1;
     working_dir: >site>dsa>data;
     authorization: system_low;
     scid_300; MUL1;
     dsa200_node_address: 10:97;
     seg_info_name: seg_info1;
     lc_data_name: lc_data1;
     timers: suspend_timer = 4, recover_timer = 15,
             idle_lc_timer = 3, cleanup_timer = 2,
             delta_timer = 1;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-20
  
  
  
  _M_a_i_l_b_o_x
  
       The  Mailbox  statement  and   its  substatements  define  a
  mailbox.   A mailbox  is a  service access  point (SAP)  into the
  local  session  control;  i.e.,  it  is  the  representation of a
  specific address  in session control.  A mailbox  is the endpoint
  of  a  logical  connection  on   the  local  system.   A  logical
  connection is  established between a mailbox  and a correspondent
  (a mailbox on a remote system).  When an application asks session
  control to do a listen or  a connect, it provides session control
  with the name  of a mailbox, and also, in the  case of a connect,
  with the name  of a correspondent.  Note that since  a mailbox is
  an endpoint, it  has a service associated with it.   There can be
  more than one Mailbox statement in the NIT.
  
  
  SYNTAX
  
  Mailbox: <mailbox_name>;
     sc_loc: <session_control_name>;
     mbx_dsaname: <mbx_dsa_name>;
     local_service: <service_name>;
     session_type_descriptor: <std_name>;
     {user_required_for_dial: <user_required_value>;}
     acl_path: <acl_pathname>;
     {authorization: <authorization_value>;}
  end;
  
  where:
  
  mailbox_name
       is the name of the mailbox.  This is a free name of up to 32
       characters, but the convention is  to create a name with the
       following syntax:
  
            dsa.<session_control_name>.<mbx_dsa_name>
  
       for example:
  
            dsa.MUL1.LOGIN
  
       The  parameters  session_control_name  and  mbx_dsa_name are
       defined below.
  
  session_control_name
       is  the local  name of   the session  control in  which this
       mailbox is defined.  It will usually be the same as the four
       character  DSA  name  of  the  session  control.   Refer  to
       session_control_name  under  the  Sc_loc  object definition.
       Note    that    the    session    control    specified    by
       session_control_name  must  be  defined  by  a Sc_loc object
       definition.
  
  
                                 4-21
  
  
  
  mbx_dsa_name
       is the  DSA name of the  mailbox, which is used  between two
       session controls to exchange information.  This name must be
       a string of eight or  less characters.  Note that some names
       are predefined in DSA.  The predefined names are:
  
            FILETRAN
            LOGIN
            UFT_REQ
            $ASF
            $LOGFILE
            $NAD
            $NOI
            $NOIAEP
  
  service_name
       is  the  name  of  the  service  which  is  provided on this
       mailbox.  It  is a free name  of up to 32  characters.  Note
       that the  service specified by service_name  must be defined
       by a Service object definition.
  
  std_name
       is  the   name  of  the  default   session  type  descriptor
       associated with this mailbox.  It is a free name of up to 32
       characters.  If an application calls session control to do a
       listen or a connect on this mailbox without supplying a STD,
       session control  will use the default one  provided for this
       mailbox.  Note  that the STD  specified by std_name  must be
       defined by a Session_type_descriptor object definition.
  
  user_required_value
       is a string ("yes" or "no") which specifies whether or not a
       user  who dials  up to   this endpoint  and issues  the dial
       request   must  specify   the  -user   control  argument  to
       identify/authenticate himself.  This parameter is optional.
  
  acl_pathname
       is the absolute  pathname of the ACS segment  that lists the
       access to this mailbox of  every user.  Session control (via
       dsa_nit_)  checks the  access of  a caller  on this mailbox.
       The caller must have "r" access on the ACS segment to listen
       on the mailbox, "e" to make a connect, and "w" to create and
       delete the  mailbox.  A warning  is printed if  this segment
       does not exist at NIT compilation time.
  
  authorization_value
       is  the  AIM  authorization  given  to  this  mailbox.  This
       parameter is optional.  (The default is "system_low.")
  
  
  
  
  
  
                                 4-22
  
  
  
  EXAMPLE
  
  Mailbox: dsa.MUL1.LOGIN;
     sc_loc: MUL1;
     mbx_dsaname: LOGIN;
     local_service: login_service;
     session_type_descriptor: login_listen_std;
     user_required_for_dial: yes;
               /* Access information */
     acl_path: >sc1>mna>dsa>Login.acs;
     authorization: system_low;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-23
  
  
  
  _D_s_a_c___i_n_f_o
  
       The  Dsac_info statement   and its  associated substatements
  define  configuration data  for the  DSA_DSAC daemon.   There can
  only be one Dsac_info statement in the NIT.
  
  
  SYNTAX
  
  Dsac_info: <dsac_info_name>;
     sc_loc: <session_control_name>;
     working_dir: <wd_pathname>;
     working_dd_seg: <dd_segname>;
     working_af_seg: <af_segname>;
     working_ag_seg: <ag_segname>;
     working_ac_seg: <ac_segname>;
     admin_functions: <admin_function_name1>
                      ... {, <admin_function_nameN>};
  end;
  
  where:
  
  ac_segname
       is   the   entryname   of   the   segment   containing   the
       administrative   correspondent   table.    It   is   created
       automatically when the DSA_DSAC daemon is started up for the
       first  time,  in  the  directory  specified  by wd_pathname,
       described above.
  
  af_segname
       is   the   entryname   of   the   segment   containing   the
       administrative function table.   It is created automatically
       when the DSA_DSAC  daemon is started up for  the first time,
       in the directory specified by wd_pathname, described above.
  
  ag_segname
       is   the   entryname   of   the   segment   containing   the
       administrative  group table.    It is  created automatically
       when the DSA_DSAC  daemon is started up for  the first time,
       in the directory specified by wd_pathname, described above.
  
  admin_function_name
       is  the name  of an  administrative function  handled by the
       DSA_DSAC  daemon.   The  DSA_DSAC  daemon  generally handles
       three administrative functions, one of  the NAD type and two
       of  the ASF  type.   Note  that the  administrative function
       specified  by  admin_function_name  must  be  defined  by an
       Admin_function object definition.
  
  
  
  
  
  
                                 4-24
  
  
  
  dd_segname
       is the  entryname of the segment containing  the daemon main
       table.  It is created automatically when the DSA_DSAC daemon
       is started up for the first time, in the directory specified
       by wd_pathname, described above.
  
  dsac_info_name
       is the name  of the DSAC information NIT object.   This is a
       free  name of up  to 32 characters.   There is a  one-to-one
       correspondence between this object  and the object described
       by the Sc_loc statement; therefore,  since there can only be
       one session control running at a time, there can only be one
       DSAC information object in the NIT.
  
  session_control_name
       is  the local  name of  the session  control with  which the
       DSA_DSAC daemon  interfaces.  This name is  usually the same
       as  the four  character DSA   name of  the session  control.
       Refer  to  session_control_name   under  the  Sc_loc  object
       definition.   Note  that  the  session  control specified by
       session_control_name  must  be  defined  by  a Sc_loc object
       definition.
  
  wd_pathname
       is the  absolute pathname of the directory  in which segment
       data are created when the  DSA_DSAC daemon is started up for
       the  first  time.   It  is  the  DSA_DSAC  daemon's  working
       directory.  You are responsible for creating this directory,
       and should  do so before  the DSA_DSAC daemon  is started up
       for the  first time.  Note  that you must  give the DSA_DSAC
       daemon "sma" access to this directory.  A warning is printed
       if this  directory does not  exist at NIT  compilation time.
       Refer to Section 6 for more information.
  
  
  EXAMPLE
  
  Dsac_info: DSAC.MUL1;
     sc_loc: MUL1;
     working_dir: >site>dsa>dsac_info;
     working_dd_seg: dd1;
     working_af_seg: af1;
     working_ag_seg: ag1;
     working_ac_seg: ac1;
     admin_functions: lnad1,dsalog1,nasf1;
  end;
  
  
  
  
  
  
  
  
                                 4-25
  
  
  
  _A_d_m_i_n___f_u_n_c_t_i_o_n
  
       The    Admin_function   statement    and   its    associated
  substatements   define  a   DSAC  administrative   function.   An
  administrative  function  is  a  set  of  administrative services
  provided on a given mailbox on  the local system (by the DSA_DSAC
  daemon).   Each administrative  function can  communicate through
  DSA sessions with an analogous administrative function located on
  a  remote system.   (Remote administrative  functions are  called
  administrative correspondents on the local system, just as remote
  mailboxes  are called  correspondents on  the local  system.)  An
  administrative function is roughly  characterized by its type and
  by  its mailbox name.   There are generally  three Admin_function
  object   definitions  in  the   NIT:   one  which   describes  an
  administrative function  of the NAD type, and  two which describe
  administrative  functions  of  the  ASF  type.  An administrative
  function of  the NAD type  can receive incoming  connections from
  administrative  correspondents   of  the  ASF/NOI/NCC   type;  an
  administrative  function of  the  ASF  type can  receive incoming
  connections from  administrative correspondents of the  NAD type.
  (Multics administrative functions always accept incoming sessions
  on their mailboxes; they never  initiate sessions.)  There can be
  more than one Admin_function statement in the NIT.
  
  
  SYNTAX
  
  Admin_function: <admin_function_name>;
     mailbox: <mailbox_name>;
     type: <admin_function_type>;
     local_service: <service_name>;
  end;
  
  where:
  
  admin_function_name
       is the name of the  administrative function.  This is a free
       name of up to  32 characters.  Note that admin_function_name
       is  referenced  in  the  Dsac_info  and  Admin_group  object
       definitions.
  
  admin_function_type
       is  the type  of the  administrative function.   It must  be
       either  "NAD" or "ASF".   An administrative function  of the
       NAD  type  can  send   AEP  messages  to  an  administrative
       correspondent  of the  ASF/NOI/NCC type.   An administrative
       function of  the ASF type  can receive AEP  messages from an
       administrative correspondent  of the NAD type.   It can also
       transfer administrative  files to or from  an administrative
       correspondent of the NAD type.
  
  
  
  
                                 4-26
  
  
  
  mailbox_name
       is   the  name   of  the   local  mailbox   on  which   this
       administrative  function is  provided.  The  DSA_DSAC daemon
       uses  this  particular  mailbox   to  accept  sessions  from
       administrative correspondents.  This is a free name of up to
       32 characters, but  the convention is to create  a name with
       the following syntax:
  
            dsa.<session_control_name>.<mbx_dsa_name>
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-27
  
  
  
       for example:
  
            dsa.MUL1.$NAD
  
       The  parameters  session_control_name  and  mbx_dsa_name are
       defined under the Mailbox  object definition.  Note that the
       session  control specified  by session_control_name  must be
       the same as the  one specified by session_control_name under
       the  Dsac_info  object  description.   Note  also  that  the
       mailbox  specified  by  mailbox_name  must  be  defined by a
       Mailbox object definition.
  
  service_name
       is the name of the service which is provided by the DSA_DSAC
       daemon  on the  specified  mailbox.   Note that  the service
       specified  by  service_name  must  be  defined  by a Service
       object description.
  
  
  EXAMPLE
  
  Admin_function: lnad1;
     mailbox: dsa.MUL1.$NAD;
     type: NAD;
     local_service: nad_service;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-28
  
  
  
  _A_d_m_i_n___g_r_o_u_p
  
       The Admin_group  statement and its  associated substatements
  define  a  DSAC  administrative  group,   which  is  a  group  of
  administrative correspondents  of the same type,  associated with
  the same (local)  administrative function.  (See admin_group_type
  below.)  There must be at  least one Admin_group statement in the
  NIT for each Admin_function statement in the NIT.
  
  
  SYNTAX
  
  
  Admin_group: <admin_group_name>;
     type: <admin_group_type>;
     {max_active_ac: <max_active_ac_value>;}
     admin_function: <admin_function_name>;
  end;
  
  where:
  
  admin_group_name
       is  the name of  the administrative group.   This is a  free
       name of up to 32 characters.
  
  admin_group_type
       is the type  of the administrative group; i.e.,  the type of
       every  administrative correspondent   which belongs  to this
       administrative  group, and  by  extension,  the type  of the
       remote   administrative  functions   represented  by   these
       administrative  correspondents.   It  must  chosen  from the
       following list:
  
            ASF
            AUT
            NAD
            NCC
            NOI
  
  admin_function_name
       is the name of the  (local) administrative function to which
       this  administrative   group  is  linked.   Note   that  the
       administrative  function  specified  by  admin_function_name
       must be defined by an Admin_function object definition.
  
  max_active_ac_value
       is  the maximum  number of  administrative correspondents in
       this administrative  group which can be active  at one time.
       This  parameter  must  be  set  to  a  decimal string.  This
       parameter is optional.
  
  
  
  
                                 4-29
  
  
  
  EXAMPLE
  
  Admin_group: admin_group1;
     type: NOI;
     max_active_ac: 10;
     admin_function: lnad1;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-30
  
  
  
  _T_s
  
       The Ts  statement and its associated  substatements define a
  transport station.  Provided with the  name of the remote session
  control  to access  and the  list of  session routes  to use, the
  local  Multics  session  control  picks  the  DN8/7100  transport
  station to call in order to send an initiate letter.  CXI assumes
  the  interface  between  the  Multics  session  control  and  the
  transport station.  There is  one transport station per frontend.
  The transport station  described by a Ts object  definition is an
  image  of the  actual transport  station in  the remote DN8/7100.
  There can be more than one Ts statement in the NIT.
  
  
  SYNTAX
  
  Ts: <dsa_transport_name>;
     address: <dsa_ts_address>;
     frontend: <frontend_name>;
  end;
  
  where:
  
  dsa_transport_name
       is the name  of the transport station.  This is  a free name
       of  up to  32 characters.   Note that  dsa_transport_name is
       referenced   in  the   Frontend  and   Session_Route  object
       definitions.
  
  dsa_ts_address
       is the address of this transport station in the DSA network.
       This address is usually composed  of the area number and the
       ts_number  in the area.   This parameter may  be set to  the
       dummy value of "".
  
  frontend_name
       is the  name of the  DN8/7100 in which  the actual transport
       station  exists.   Note  that   the  DN8/7100  specified  by
       frontend_name   must  be   defined  by   a  Frontend  object
       definition.
  
  
  EXAMPLE
  
  Ts: dn8_a;
     address: 1:61;
     frontend: dn8a;
  end;
  
  
  
  
  
  
                                 4-31
  
  
  
  _F_r_o_n_t_e_n_d
  
       The  Frontend  statement  and  its  associated substatements
  define a  DN8/7100 frontend.  The configuration  data provided in
  this  definition are used  by the CXI  input daemon to  interface
  this frontend with Multics.
  
  
  SYNTAX
  
  Frontend: dnsa;
     driver: <cxi_driver_>;
     driver_admin: <cxi_driver_admin_>;
     ts_entity: <dsa_transport_name>;
     dia: <dia_name1> ... {, <dia_nameN>};
     sc_loc: <scid_name>;
     wired_buffer_size: <wired_buffer_size_value>;
     input_q_size: <input_q_size_value>;
     output_q_size: <ouput_q_size_value>;
     dummy_traffic_interval: <dummy_traffic_interval_value>;
     idle_timer_interval: <idle_timer_interval_value>;
     working_dir: <wd_pathname>;
  end;
  
  where:
  
  dia_name
       is the name  of a DIA connected to this  frontend.  The name
       is specified in the same way as it is specified on the "prph
       diaX"  card in the  Multics configuration deck;  e.g., diab.
       For  more information  about  the  "prph diaX"  config card,
       refer  to Section  7  of  the _S_y_s_t_e_m  _M_a_i_n_t_e_n_a_n_c_e _P_r_o_c_e_d_u_r_e_s
       manual, Order No.  AM81.
  
  dsa_transport_name
       is  the name  of the   transport station  supported by  this
       particular  frontend.   Note   that  the  transport  station
       specified  by dsa_transport_name  must  be  defined by  a Ts
       object  definition.  Note  also that  the transport  station
       specified  by dsa_transport_name  must  be  the same  as the
       transport station specified  by dsa_transport_name under the
       corresponding Session_Route object definition.
  
  dummy_traffic_interval_value
       specifies (in  seconds) how often dummy traffic  may be sent
       to the frontend.  (Dummy traffic  is sent to the frontend in
       order  to verify  that it  is operational.)   This parameter
       must be set to a decimal  string.  It should normally be set
       to 120.
  
  
  
  
  
                                 4-32
  
  
  
  frontend_name
       is the name  of the frontend.  This is a free  name of up to
       32 characters.  Note that frontend_name is referenced in the
       Ts object definition.
  
  idle_timer_interval_value
       specifies (in  milliseconds) how often the  CXI input daemon
       should check the CXI queues  for commands from the frontend.
       This parameter must  be set to a decimal  string.  It should
       normally be set to 100.
  
  input_q_size_value
       is the size (in entries) of the CXI input queue.  Each entry
       uses  four  words  of  space  in  the  wired  buffer.   This
       parameter must be set to a decimal string.
  
  ouput_q_size_value
       is  the size  (in entries)  of the  CXI output  queue.  Each
       entry uses  four words of  space in the  wired buffer.  This
       parameter must be set to a decimal string.
  
  scid_name
       is the DSA  name of the session control which  the CXI input
       daemon interface  with this frontend.  It is  known all over
       the  DSA network, and  is used to  access the local  session
       control.
  
  wd_pathname
       is the absolute pathname of the working directory of the CXI
       input  daemon which  interfaces this  frontend with Multics.
       Normally,  the runnable  image, the  config file,  the patch
       files, and the  dump files for this frontend  should be kept
       in  this directory,  and the  start_up.ec for  the CXI input
       daemon  should  contain  a  command  to  change  the working
       directory     to     this     directory.      (Either    the
       dsa_fep_working_dir   (dsa_fwd)  active   function  or   the
       frontend_working_dir (fwd) CXI subsystem request may be used
       for  this purpose;  e.g., cwd  [dsa_fwd dn8a].   The dsa_fwd
       active  function is  described in   Section 2;  the fwd  CXI
       subsystem request is described in  Section 5.)  A warning is
       printed if this directory does  not exist at NIT compilation
       time.
  
  wired_buffer_size_value
       is  the total size  (in pages) of  the wired buffer  that is
       used (when this frontend is running) by the CXI input daemon
       associated  with this  frontend.  The  CXI input  and output
       queues are located in this buffer, and any space leftover is
       used  for data  buffers.  This  parameter must  be set  to a
       decimal string greater than or equal to 5.
  
  
  
  
                                 4-33
  
  
  
  EXAMPLE
  
  Frontend: dn8a;
     ts_entity: dn8_a;
     dia: diaa, diac;
     sc_loc: MUL1;
     wired_buffer_size: 40;                  /* In pages */
     input_q_size: 97;                       /* In entries */
     output_q_size: 91;                      /* In entries */
     dummy_traffic_interval: 120;            /* In seconds */
     idle_timer_interval: 500;               /* In milliseconds */
     working_dir: >site>dsa>frontend_dir_dir>dn8a;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-34
  
  
  
  _S_e_s_s_i_o_n___R_o_u_t_e
  
       The Session_Route statement and its associated substatements
  define a  session route.  A session  route is a link  between one
  session control and one transport control.   It is a route out of
  Multics and into a DN8/7100.  A remote system contains in its NIT
  definition a list  of session route names that may  be used to go
  out of  that remote system in  order to access the  local system.
  There can be more than one Session_Route statement in the NIT.
  
  
  SYNTAX
  
  Session_Route: <session_route_name>;
     sc_loc: <session_control_name>;
     ts: <dsa_transport_name> ;
  end;
  
  where:
  
  dsa_transport_name
       is the name of the  transport station which is the extremity
       of this route.  Note that the transport station specified by
       dsa_transport_name   must  be   defined  by   a  Ts   object
       definition.  Note also that  the transport station specified
       by  dsa_transport_name must  be  the  same as  the transport
       station   specified   by    dsa_transport_name   under   the
       corresponding Frontend object definition.
  
  session_control_name
       is the local name of the session control which is the origin
       of this route.  It is usually the same as the four character
       DSA    name   of    the   session    control.    Refer    to
       session_control_name  under  the  Sc_loc  object definition.
       Note    that    the    session    control    specified    by
       session_control_name  must  be  defined  by  a Sc_loc object
       definition.
  
  session_route_name
       is the name of the session route.  This is a free name of up
       to   32  characters.     Note  that   session_route_name  is
       referenced in the System object definition.
  
  
  EXAMPLE
  
  Session_Route: route_to_dn8_a;
     sc_loc: MUL1;
     ts: dn8_a;
  end;
  
  
  
  
                                 4-35
  
  
  
  _S_y_s_t_e_m
  
       The System statement and its associated substatements define
  a remote  system; i.e., a remote  DSA host or a  remote DSA node.
  There can be more than one System statement in the NIT.
  
  
  SYNTAX
  
  System: <system_name>;
     {sc_rmt: <scid_name>;}
     dsa200_node_address: <dsa200_node_address>;
     session_route: <session_route_name1>;
     .
     .
     .
     {session_route: <session_route_namen>;}
     system_type: <system_type_name>;
     {system_release: <system_release>;}
     {official_name: <official_name>;}
     {tm_version: <tm_version_value>;}
     acl_path: <system_acl_pathname>;
     {authorization: <authorization_value>;}
  end;
  
  where:
  
  authorization_value
       is  the  AIM  authorization  given  to  this  system.   This
       parameter  is  optional.   (The  default  is  "system_low.")
       dsa200_node_address
       specifies  the   address  of  the  DSA200   node  (which  is
       equivalent  to  the  DSA300  scid_name).   This parameter is
       required  for  purposes  of   compatibility.   It  allows  a
       negotiation at the same level  of protocol when a connection
       is established  with another node.   If the other  node is a
       DSA300 node,  only the scid_name (or  system_name) parameter
       is  used.  But  if the  other node  is a  DSA200 node,  this
       parameter, dsa200_node_address, is used.
  
  official_name
       is  a string of  up to 32  characters specifying the  actual
       name  and/or  address  of  the  remote  host;  for  example,
       Louveciennes Multics.  This parameter is optional.
  
  scid_name
       is the DSA name of  the remote system's session control.  It
       is known all over the DSA network, and is used to access the
       remote  system's session  control.  This  name must  be four
       hexadecimal  characters long.   If  the  remote system  is a
       Multics  system, this  name must   be the  same as  the name
       specified by the scid_name parameter under the Sc_loc object
  
  
                                 4-36
  
  
  
       definition in the remote  system's NIT, unless the scid_name
       parameter  is not specified,  in which case  it must be  the
       same  as  the  name  specified  by  the session_control_name
       parameter under  the Sc_loc object definition  in the remote
       system's  NIT.  If the  remote system is  a local or  remote
       DN8/7100, this name  must be the same as  the name specified
       on the SC card in the DN8/7100's configuration file.  If the
       remote system  is a DN8/7100 running under  the DSA200 level
       protocol, system_name may be the  same as the name specified
       on the  NODE card in the DN8/7100's  configuration file.  If
       the remote system  is a Level 6, this name  must be the same
       as  the name  specified on  the SCA  card in  the Level  6's
       configuration  file.  If system_name  (above) is set  to the
       four  character  DSA  name  of  the  remote system's session
       control, then this parameter need not be specified.
  
  system_acl_pathname
       is the absolute  pathname of the ACS segment  that lists the
       access to this system of every user.  The user must have "r"
       access to accept incoming  connections from this system, and
       "e"  access  to  initiate  connections  to  this system.  If
       correspondent_acl_pathname    is    specified    under   the
       Correspondent object  definition, its value  there overrides
       its value here.   If correspondent_acl_pathname is specified
       under the  Admin_correspondent object definition,  its value
       there overrides its value here.
  
  system_name
       is the local  name of the remote system.  It  is a free name
       of  up to  32 characters.   However, to  avoid confusion, we
       recommend that it  be set to the four character  DSA name of
       the remote system's session  control.  If system_name is set
       to  the DSA name,  then the following  rules apply.  If  the
       remote system  is a Multics system, system_name  must be the
       same as the name specified  by the scid_name parameter under
       the  Sc_loc object  definition in  the remote  system's NIT,
       unless  the scid_name parameter  is not specified,  in which
       case  it must  be the  same  as  the name  specified by  the
       session_control_name  parameter  under   the  Sc_loc  object
       definition in the remote system's NIT.  If the remote system
       is a local or remote  DN8/7100, system_name must be the same
       as  the name  specified on   the SC  card in  the DN8/7100's
       configuration  file.  If  the  remote  system is  a DN8/7100
       running under the DSA200  level protocol, system_name may be
       the  same as  the name  specified on  the NODE  card in  the
       DN8/7100's  configuration file.  If  the remote system  is a
       Level 6, system_name must be  the same as the name specified
       on  the SCA card  in the Level  6's configuration file.   If
       system_name is  set to the DSA name,  scid_name (below) need
  
  
  
  
  
                                 4-37
  
  
  
       not  be specified.  Note  that system_name is  referenced in
       the    Correspondent    and    Admin_correspondent    object
       definitions.    It   corresponds   to  session_control_name,
       defined under the Sc_loc object definition.
  
  system_release
       is a string of up to 32 characters specifying the release of
       this  system;  for  example,   MR11.0.   This  parameter  is
       optional and may be set to "".
  
  system_type_name
       is a  string of up to  32 characters specifying the  type of
       this system; for example, Multics, DN8, DSS.
  
  tm_version_value
       is the version of the terminal management software installed
       on  this  system.   This  parameter  must  be  set to either
       TM_NO_STC or TM_FULL_STC.  This parameter is optional.
  
  
  EXAMPLE
  
  System: DA10;
     sc_rmt:  DA10;
     dsa200_node_address: 10:96;
     session_route: route_to_dn8_a;
     system_type: DN8;
     system_release: "";
     official_name: CISL_dn8_a;
     tm_version: TM_FULL_STC;
     acl_path: >sc1>mna>dsa>systems.acs;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-38
  
  
  
  _C_o_r_r_e_s_p_o_n_d_e_n_t
  
       The Correspondent statement and its associated substatements
  define a correspondent, which is a mailbox on a remote system.  A
  correspondent  is the  local view   of a  remote mailbox  object.
  (This  remote mailbox  is described  as a  mailbox in  the remote
  site's  DSA network description.)   A correspondent is  a service
  access point (SAP) into a remote session control; i.e., it is the
  representation of a specific address in a remote session control.
  A correspondent  is the endpoint  of a logical  connection on the
  remote  system.  A  logical connection  is established  between a
  mailbox  and a correspondent.   When an application  asks session
  control to do a listen or  a connect, it provides session control
  with the name  of a mailbox, and also, in the  case of a connect,
  with   the  name   of  a   correspondent.   Note   that  since  a
  correspondent is a kind of  endpoint, it has a service associated
  with it.  There  can be more than one  Correspondent statement in
  the NIT.
  
  
  SYNTAX
  
  Correspondent: <correspondent_name>;
     system: <system_name>;
     rmt_mbx_dsaname: <mbx_dsa_name>;
     local_service_to_use: <service_name>;
     {authorization: <authorization_value>;}
     {request_type: <IO_Daemon_request_type>;}
     {terminal_type: <terminal_type>;}
     {acl_path: <correspondent_acl_pathname>;}
  end;
  
  where:
  
  authorization_value
       is the AIM authorization  given to this correspondent.  This
       parameter is optional.  (The default is "system_low.")
  
  correspondent_acl_pathname
       is the absolute  pathname of the ACS segment  that lists the
       access to  this correspondent of every user.   The user must
       have  "r" access  to accept  incoming connections  from this
       system,  and  "e"  access  to  initiate  connections to this
       system.   This   parameter  is  optional.   If   it  is  not
       specified, then  access checking is done on  the ACS segment
       specified  by the   system_acl_pathname parameter  under the
       System  object definition  for the  "containing" system.  If
       both the  "containing" system and the  correspondent provide
       an  ACS segment,  the correspondent's  ACS segment overrides
       the system's ACS segment.
  
  
  
  
                                 4-39
  
  
  
  correspondent_name
       is the name of the correspondent.  This is a free name of up
       to  32 characters, but  the convention is  to create a  name
       with the following syntax:
  
            dsa.<system_name>.<mbx_dsa_name>
  
       for example:
  
            dsa.DA10.tty1
  
       The  parameters  system_name  and  mbx_dsa_name  are defined
       below.
  
  IO_Daemon_request_type
       is  the  IO  Daemon  request  type  which  should be used to
       enqueue deferred UFT requests  for this correspondent.  This
       parameter is optional.  (The default is "dsa_uft.")
  
  mbx_dsa_name
       is the DSA name of  the correspondent, which is used between
       two  session controls  to exchange  information.  This  name
       must be a string of eight or less characters.  If the remote
       system in  which the correspondent  is defined is  a Multics
       system, this name must be the  same as the name specified by
       the mbx_dsa_name  parameter under the  corresponding Mailbox
       object definition in the remote system's NIT.  If the remote
       system in which  the correspondent is defined is  a local or
       remote  DN8/7100, this  name must  be the  same as  the name
       specified on the DEVICE card in the DN8/7100's configuration
       file (or it must be the  same as the default name assumed by
       the   configuration  file).    Note  that   some  names  are
       predefined in DSA.  The predefined names are:
            FILETRAN
            LOGIN
            UFT_REQ
            $ASF
            $LOGFILE
            $NAD
            $NOI
            $NOIAEP
  
  service_name
       is  the  name  of  the  service  which  is  provided on this
       correspondent.    Note  that    the  service   specified  by
       service_name must be defined by a Service object definition.
  
  system_name
       is  the  local  name  of  the  remote  system  in  which the
       correspondent  is defined.  It  is a free  name of up  to 32
       characters.  Note  that the system specified  by system_name
       must be defined by a System object definition.
  
  
                                 4-40
  
  
  
  terminal_type
       is  the terminal  type of  the remote  correspondent, if the
       remote correspondent represents a  terminal.  It must be one
       of  the terminal  types listed  by the  print_terminal_types
       command.  Terminal management uses this parameter to get the
       terminal type  of the correspondent.  If TM  may not process
       sessions to this correspondent, this parameter may be set to
       "NONE" or not be specified.  In this case, the terminal type
       is negotiated when the session is set up.
  
  
  EXAMPLE
  
  Correspondent: dsa.DA10.TTY1;
     system: DA10;
     rmt_mbx_dsaname: TTY1;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: VIP7801;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-41
  
  
  
  _A_d_m_i_n___c_o_r_r_e_s_p_o_n_d_e_n_t
  
       The   Admin_correspondent  statement   and  its   associated
  substatements define an administrative correspondent, which is an
  administrative  function on  a remote  system.  An administrative
  correspondent  is  the  local  view  of  a  remote administrative
  function  object.    (This  remote  administrative   function  is
  described as an administrative function  in the remote site's DSA
  network  description.)   Administrative   correspondents  of  the
  ASF/NOI/NCC  type  will  initiate  sessions  with  administrative
  functions  of the  NAD type  (which will  accept these sessions).
  Administrative  correspondents  of  the  NAD  type  will initiate
  sessions  with administrative  functions of  the ASF  type (which
  will  accept  these  sessions).   There  can  be  more  than  one
  Admin_correspondent statement in the NIT.
  
  
  SYNTAX
  
  Admin_correspondent: <admin_correspondent_name>;
     system: <system_name>;
     rmt_mbx_dsaname: <mbx_dsa_name>;
     admin_group: <admin_group_name>;
     {authorization: <authorization_value>;}
     {acl_path: <correspondent_acl_pathname>;}
     type: <admin_corr_type>;
     {character_encoding: <char_encoding_value>;}
  end;
  
  where:
  
  admin_corr_type
       is  the type  of this  administrative correspondent,  and by
       extension, the type of the remote administrative function it
       represents.   It  must  be  the  same  as  the  type  of the
       administrative    group   to   which    the   administrative
       correspondent belongs.  It must be chosen from the following
       list:
  
            ASF
            AUT
            NAD
            NOI
            NCC
  
  admin_correspondent_name
       is the name of the  administrative correspondent.  This is a
       free name of  up to 32 characters, but the  convention is to
       create a name with the following syntax:
  
            dsa.<system_name>.<mbx_dsa_name>.<local_af_mbx_dsaname>
  
  
  
                                 4-42
  
  
  
       for example:
  
            dsa.DA10.$NOIAEP.$NAD
  
       The  parameters  system_name  and  mbx_dsa_name  are defined
       below.    The   parameter    local_af_mbx_dsaname   is   the
       mbx_dsaname  of  the  (local)  administrative  function with
       which   this  administrative   correspondent  is   going  to
       communicate.
  
  admin_group_name
       is  the  name  of  the  administrative  group  to which this
       administrative   correspondent  belongs.    Note  that   the
       administrative group  specified by admin_group_name  must be
       defined by an Admin_group object definition.  Note also that
       the   administrative  correspondent    must  belong   to  an
       administrative group of the  same type as the administrative
       correspondent.
  
  authorization_value
       is  the  AIM  authorization  given  to  this  administrative
       correspondent.  This parameter is optional.  (The default is
       "system_low.")
  
  char_encoding_value
       is  the  character  encoding   type  ("ASCII"  or  "EBCDIC")
       practiced   by  this  administrative   correspondent.   This
       parameter is optional.  (The default is "ASCII".)
  
  correspondent_acl_pathname
       is the absolute  pathname of the ACS segment  that lists the
       access to  this administrative correspondent of  every user.
       The user must have "r" access to accept incoming connections
       from this system, and "e"  access to initiate connections to
       this  system.  This  parameter is  optional.  If  it is  not
       specified, then  access checking is done on  the ACS segment
       specified  by the   system_acl_pathname parameter  under the
       System  object definition  for the  "containing" system.  If
       both   the  "containing"   system  and   the  administrative
       correspondent  provide an   ACS segment,  the administrative
       correspondent's  ACS  segment  overrides  the  system's  ACS
       segment.
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-43
  
  
  
  mbx_dsa_name
       is the  DSA name of the  administrative correspondent, which
       is   used   between   two   session   controls  to  exchange
       information.  This  name must be  a string of  eight or less
       characters.   Note that  some names  are predefined  in DSA.
       The predefined names are:
  
            $ASF
            $LOGFILE
            $NAD
            $NOI
            $NOIAEP
  
       Note  also that these  names are chosen  in relation to  the
       network configurations  of other DSA systems.   For example,
       $NOIAEP  is the default  mailbox name for  an administrative
       correspondent of the NOI type.
  
  system_name
       is  the  local  name  of  the  remote  system  for which the
       administrative correspondent is defined.   It is a free name
       of up to  32 characters.  Note that the  system specified by
       system_name must be defined by a System object definition.
  
  
  EXAMPLE
  
  Admin_correspondent: dsa.DA10.$NOIAEP.$NAD;
     system: DA10;
     rmt_mbx_dsaname: $NOIAEP;
     admin_group: admin_group1;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
     type: NOI;
     character_encoding: ASCII;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-44
  
  
  
  _D_S_A _N_I_T _S_O_U_R_C_E _T_A_B_L_E _E_X_A_M_P_L_E
  
  
  /*------------------------------------------------------------*/
  /*                            NIF.nif                         */
  /*------------------------------------------------------------*/
  
  
  /*------------------------------------------------------------*/
  /*                            Mna_general_info                */
  /*------------------------------------------------------------*/
  
  Mna_general_info;
     cxi_driver_segment: >site>dsa>data>cxi_driver_seg;
     dsa_system_log: >site>dsa>system_logs_dir>dsa_sl;
     dsa_system_aep_log: >site>dsa>system_logs_dir>dsa_sal;
     dsa_aep_log: >site>dsa>aep_logs_dir>dsa_al;
     sc_exerciser_wdir: >site>dsa>data;
     sc_handle_manager_wdir: >site>dsa>data;
     default_tm_mailbox: dsa.MUL1.TMDIALOU;
     default_uft_mailbox: dsa.MUL1.UFT_REQ;
     default_exe_init_mailbox: dsa.MUL1.$NSF;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-45
  
  
  
  /*------------------------------------------------------------*/
  /*                            Services                        */
  /*------------------------------------------------------------*/
  
  Service: exerciser_service;
     endpoint: dsa.MUL1.$NSF;
        get_service_module: >t>nothing; /* required placeholder */
     end;
  end;
  
  Service: uft_service;
     endpoint: dsa.MUL1.UFT_REQ;
        get_service_module: >t>nothing; /* required placeholder */
     end;
  end;
  
  Service: tm_dialout_service;
     endpoint: dsa.MUL1.TMDIALOU;
        get_service_module: >t>nothing; /* required placeholder */
     end;
  end;
  
  Service: login_service;
     endpoint: dsa.MUL1.LOGIN;
        get_service_module: >exl>dsa>e>dsa_tty_;
     end;
  
     endpoint: dsa.MUL1.LOGINT;
        get_service_module: >exl>dsa>e>dsa_tty_;
     end;
  
     endpoint: dsa.MUL1.FILETRAN;
        get_service_module: >exl>dsa>e>dsa_uft_login_service_;
     end;
  
     endpoint: dsa.MUL1.$NSE;
        get_service_module: >t>nothing; /* required placeholder */
     end;
  end;
  
  Service: remote_nad_access_service;
     endpoint: dsa.MUL1.$NOIAEP;
        get_service_module: >t>nothing; /* required placeholder */
     end;
  end;
  
  Service: nad_service;
     endpoint: dsa.MUL1.$NAD;
        get_service_module: >exl>dsa>e>dsa_dsac_lnad_;
     end;
  end;
  
  
  
                                 4-46
  
  
  
  Service: asf_service;
     endpoint: dsa.MUL1.$LOGFILE;
        get_service_module: >exl>dsa>e>dsa_dsac_ldsalog_;
     end;
  
     endpoint: dsa.MUL1.$NASF;
        get_service_module: >exl>dsa>e>dsa_dsac_nasf_;
     end;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-47
  
  
  
  /*------------------------------------------------------------*/
  /*                     Session_type_descriptors               */
  /*------------------------------------------------------------*/
  
  Session_type_descriptor: login_listen_std;
     /* Standard STD for TM */
     initiate_wait_time: 14;
     rcv_max_letter_size: 256;
     send_max_letter_size: 256;
     modes: twsa, twaa, twsi, twai;
     protocols: data_attention, suspend, recover,
                request_sru_acknowledge;
  end;
  
  Session_type_descriptor: tm_connect_std;
     /* Standard STD for TM (connect) */
     initiate_wait_time: 14;
     rcv_max_letter_size: 256;
     send_max_letter_size: 256;
     modes: ^twsa, twaa, ^twsi, twai;
     protocols: ^data_attention, ^suspend, ^recover,
                ^request_sru_acknowledge;
  end;
  
  Session_type_descriptor: exerciser_std;
     /* Standard STD for the session exerciser */
     initiate_wait_time: 14;
     rcv_max_letter_size: 256;
     send_max_letter_size: 256;
     modes: twai, ^twaa, ^twsi, ^twsa;
     protocols: data_attention, suspend, recover,
                request_sru_acknowledge;
  end;
  
  Session_type_descriptor: uft_listen_std;
     /* Standard STD for UFT */
     initiate_wait_time: 15;
     rcv_max_letter_size: 1024;
     send_max_letter_size: 1024;
     modes: twai, ^twsi, ^twsa, ^twaa;
  end;
  
  Session_type_descriptor: mail_listen_std;
     /* Standard STD for mail applications */
     initiate_wait_time: 4;
     rcv_max_letter_size: 1024;
     send_max_letter_size: 1024;
     modes: twai;
  end;
  
  
  
  
  
                                 4-48
  
  
  
  Session_type_descriptor: noi_aep_std;
     /* Standard STD for accessing remote NADs */
     initiate_wait_time: 14;
     rcv_max_letter_size: 256;
     send_max_letter_size: 256;
     modes: twsa, twaa, twsi, twai;
     protocols: data_attention, suspend, recover,
                request_sru_acknowledge;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-49
  
  
  
  /*------------------------------------------------------------*/
  /*                              Sc_loc                        */
  /*------------------------------------------------------------*/
  
  Sc_loc: MUL1;
     working_dir: >site>dsa>data;
     authorization: system_low;
     scid_300: MUL1;
     dsa200_node_address: 10:97;
     seg_info_name: seg_info1;
     lc_data_name: lc_data1;
     timers: suspend_timer = 4, recover_timer = 15,
             idle_lc_timer = 3, cleanup_timer = 2,
             delta_timer = 1;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-50
  
  
  
  /*------------------------------------------------------------*/
  /*                            Mailboxes                       */
  /*------------------------------------------------------------*/
  
  Mailbox: dsa.MUL1.LOGIN;
     sc_loc: MUL1;
     mbx_dsaname: LOGIN;
     local_service: login_service;
     session_type_descriptor: login_listen_std;
     user_required_for_dial: yes;
               /* Access information */
     acl_path: >sc1>mna>dsa>Login.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.LOGINT;
     sc_loc: MUL1;
     mbx_dsaname: LOGINT;
     local_service: login_service;
     session_type_descriptor: login_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Login.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.TMDIALOU;
     sc_loc: MUL1;
     mbx_dsaname: TMDIALOU;
     local_service: tm_dialout_service;
     session_type_descriptor: tm_connect_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Login.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.$NOIAEP;
     sc_loc: MUL1;
     mbx_dsaname: $NOIAEP;
     local_service: remote_nad_access_service;
     session_type_descriptor: noi_aep_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>noi_aep.acs;
     authorization: system_low;
  end;
  
  
  
  
  
  
  
  
  
  
                                 4-51
  
  
  
  Mailbox: dsa.MUL1.UFT_REQ;
     sc_loc: MUL1;
     mbx_dsaname: UFT_REQ;
     local_service: uft_service;
     session_type_descriptor: uft_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>UFT.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.FILETRAN;
     sc_loc: MUL1;
     mbx_dsaname: FILETRAN;
     local_service: login_service;
     session_type_descriptor: uft_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>UFT.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.$NSE;
     sc_loc: MUL1;
     mbx_dsaname: $NSE;
     local_service: login_service;
     session_type_descriptor: exerciser_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Echo.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.$NSF;
     sc_loc: MUL1;
     mbx_dsaname: $NSF;
     local_service: exerciser_service;
     session_type_descriptor: exerciser_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Echo.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.$NAD;
     sc_loc: MUL1;
     mbx_dsaname: $NAD;
     local_service: nad_service;
     session_type_descriptor: login_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Admin.acs;
     authorization: system_low;
  end;
  
  
  
  
  
                                 4-52
  
  
  
  Mailbox: dsa.MUL1.$LOGFILE;
     sc_loc: MUL1;
     mbx_dsaname: $LOGFILE;
     local_service: asf_service;
     session_type_descriptor: login_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Admin.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.$NASF;
     sc_loc: MUL1;
     mbx_dsaname: $NASF;
     local_service: asf_service;
     session_type_descriptor: login_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Admin.acs;
     authorization: system_low;
  end;
  
  Mailbox: dsa.MUL1.$ASFTEST;
     sc_loc: MUL1;
     mbx_dsaname: $ASFTEST;
     local_service: asf_service;
     session_type_descriptor: login_listen_std;
               /* Access information */
     acl_path: >sc1>mna>dsa>Admin.acs;
     authorization: system_low;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-53
  
  
  
  /*------------------------------------------------------------*/
  /*                            Dsac_info                       */
  /*------------------------------------------------------------*/
  
  Dsac_info: DSAC.MUL1;
     sc_loc: MUL1;
     working_dir: >site>dsa>dsac_info;
     working_dd_seg: dd1;
     working_af_seg: af1;
     working_ag_seg: ag1;
     working_ac_seg: ac1;
     admin_functions: lnad1,dsalog1,nasf1;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-54
  
  
  
  /*------------------------------------------------------------*/
  /*                            Admin_functions                 */
  /*------------------------------------------------------------*/
  
  Admin_function: lnad1;
     mailbox: dsa.MUL1.$NAD;
     type: NAD;
     local_service: nad_service;
  end;
  
  Admin_function: dsalog1;
     mailbox: dsa.MUL1.$LOGFILE;
     type: ASF;
     nlocal_service: asf_service;
  end;
  
  Admin_function: nasf1;
     mailbox: dsa.MUL1.$NASF;
     type: ASF;
     local_service: asf_service;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-55
  
  
  
  /*------------------------------------------------------------*/
  /*                            Admin_groups                    */
  /*------------------------------------------------------------*/
  
  Admin_group: admin_group1;
     type: NOI;
     max_active_ac: 10;
     admin_function: lnad1;
  end;
  
  Admin_group: admin_group2;
     type: NAD;
     max_active_ac: 10;
     admin_function: dsalog1;
  end;
  
  Admin_group: admin_group3;
     type: NAD;
     max_active_ac: 10;
     admin_function: nasf1;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-56
  
  
  
  /*------------------------------------------------------------*/
  /*                                  Tss                       */
  /*------------------------------------------------------------*/
  
  Ts: dn8_a;
     address: 1:61;
     frontend: dn8a;
  end;
  
  Ts: dn8_b;
     address: 1:63;
     frontend: dn8b;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-57
  
  
  
  /*------------------------------------------------------------*/
  /*                            Frontends                       */
  /*------------------------------------------------------------*/
  
  Frontend: dn8a;
     ts_entity: dn8_a;
     dia: diaa, diac;
     sc_loc: MUL1;
     wired_buffer_size: 40;                  /* In pages */
     input_q_size: 97;                       /* In entries */
     output_q_size: 91;                      /* In entries */
     dummy_traffic_interval: 120;            /* In seconds */
     idle_timer_interval: 500;               /* In milliseconds */
     working_dir: >site>dsa>frontend_dir_dir>dn8a;
  end;
  
  Frontend: dn8b;
     ts_entity: dn8_b;
     dia: diab, diad;
     sc_loc: MUL1;
     wired_buffer_size: 40;                  /* In pages */
     input_q_size: 97;                       /* In entries */
     output_q_size: 91;                      /* In entries */
     dummy_traffic_interval: 120;            /* In seconds */
     idle_timer_interval: 500;               /* In milliseconds */
     working_dir: >site>dsa>frontend_dir_dir>dn8b;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-58
  
  
  
  /*------------------------------------------------------------*/
  /*                            Session_Routes                  */
  /*------------------------------------------------------------*/
  
  Session_Route: route_to_dn8_a;
     sc_loc: MUL1;
     ts: dn8_a;
  end;
  
  Session_Route: route_to_dn8_b;
     sc_loc: MUL1;
     ts: dn8_b;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-59
  
  
  
  /*------------------------------------------------------------*/
  /*                            Systems                         */
  /*------------------------------------------------------------*/
  
  System: DA10;   /* local DN8 A */
     sc_rmt: DA10;
     dsa200_node_address: 10:96;
     session_route: route_to_dn8_a;
     system_type: DN8;
     system_release: "";
     official_name: CISL_dn8_a;
     tm_version: TM_FULL_STC;
     acl_path: >sc1>mna>dsa>systems.acs;
  end;
  
  System: DB10;   /* Local DN8 B */
     sc_rmt: DB10;
     dsa200_node_address: 10:95;
     session_route: route_to_dn8_b;
     session_route: route_to_dn8_a;
     system_type: DN8;
     system_release: "";
     official_name: CISL_dn8_b;
     tm_version: TM_FULL_STC;
     acl_path: >sc1>mna>dsa>systems.acs;
  end;
  
  System: S869;   /* CISL DPS6 */
     sc_rmt: S869;
     dsa200_node_address: 10:94;
     session_route: route_to_dn8_a;
     session_route: route_to_dn8_b;
     system_type: DSS;
     system_release: "";
     official_name: CISL_LEVEL_6;
     tm_version: TM_NO_STC;
     acl_path: >sc1>mna>dsa>systems.acs;
  end;
  
  System: BM25;
     sc_rmt: BM25;
     dsa200_node_address: 10:93;
     session_route: route_to_dn8_a;
     system_type: Multics;
     system_release: "";
     official_name: Louveciennes_Multics;
     tm_version: TM_FULL_STC;
     acl_path: >sc1>mna>dsa>systems.acs;
  end;
  
  
  
  
  
                                 4-60
  
  
  
  System: BM26;
     sc_rmt: BM26;
     dsa200_node_address: 10:92;
     session_route: route_to_dn8_a;
     system_type: DN8;
     system_release: "";
     official_name: Louveciennes_DN8;
     tm_version: TM_NO_STC;
     acl_path: >sc1>mna>dsa>systems.acs;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-61
  
  
  
  /*------------------------------------------------------------*/
  /*                          Correspondents                    */
  /*------------------------------------------------------------*/
  
  Correspondent: dsa.DA10.TTY1;
     system: DA10;
     rmt_mbx_dsaname: TTY1;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: VIP7801;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DA10.TTY2;
     system: DA10;
     rmt_mbx_dsaname: TTY2;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: VIP7801;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DA10.EDIT;
     system: DA10
     rmt_mbx_dsaname: EDIT;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DA10.$NOI;
     system: DA10
     rmt_mbx_dsaname: $NOI;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DA10.$ASF;
     system: DA10;
     rmt_mbx_dsaname: $ASF;
     local_service_to_use: asf_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  
  
  
  
  
                                 4-62
  
  
  
  Correspondent: dsa.DA10.$NSE;
     system: DA10;
     rmt_mbx_dsaname: $NSE;
     local_service_to_use: exerciser_service;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DA10.$NAD;
     system: DA10;
     rmt_mbx_dsaname: $NAD;
     local_service_to_use: remote_nad_access_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DA10.$DEBUG;
     system: DA10;
     rmt_mbx_dsaname: $DEBUG;
     local_service_to_use: tm_dialout_service;
     authorization :  system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DB10.TTY1;
     system: DB10;
     rmt_mbx_dsaname: TTY1;
     local_service_to_use: tm_dialout_service;
     authorization:  system_low;
     terminal_type : VIP7801;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DB10.TTY2;
     system: DB10;
     rmt_mbx_dsaname: TTY2;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: VIP7801;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DB10.EDIT;
     system: DB10
     rmt_mbx_dsaname: EDIT;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  
                                 4-63
  
  
  
  Correspondent: dsa.DB10.$NOI;
     system: DB10;
     rmt_mbx_dsaname: $NOI;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DB10.$NAD;
     system: DB10;
     rmt_mbx_dsaname: $NAD;
     local_service_to_use: remote_nad_access_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.DB10.$DEBUG;
     system: DB10;
     rmt_mbx_dsaname: $DEBUG;
     local_service_to_use: tm_dialout_service ;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.S869.$NOI;
     system: S869;
     rmt_mbx_dsaname: $NOI;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.S869.ECL;
     system: S869;
     rmt_mbx_dsaname: ECL;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_TRANS;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.S869.FILETRAN;
     system: S869;
     rmt_mbx_dsaname: FILETRAN;
     local_service_to_use: uft_service;
     authorization: system_low;
     request_type: CISL_UFT.rqt
  end;
  
  
                                 4-64
  
  
  
  Correspondent: dsa.BM25.LOGIN;
     system: BM25;
     rmt_mbx_dsaname: LOGIN;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: VIP7801;
     acl_path: >sc1>mna>dsa>correspondent.acs;
  end;
  
  Correspondent: dsa.BM25.FILETRAN;
     system: BM25;
     rmt_mbx_dsaname: FILETRAN;
     local_service_to_use: uft_service;
     authorization: system_low;
     request_type: CISL_UFT.rqt;
     /* acl_path : NONE, the system one is taken */
  end;
  
  Correspondent: dsa.BM25.$NSE;
     system: BM25;
     rmt_mbx_dsaname: $NSE;
     local_service_to_use: exerciser_service;
     authorization: system_low;
     terminal_type: NONE;
     /* acl_path : NONE, the system one is taken */
  end;
  
  Correspondent: dsa.BM25.$DSALOG;
     system: BM25;
     rmt_mbx_dsaname: $DSALOG;
     local_service_to_use: asf_service;
     authorization: system_low;
     terminal_type: NONE;
     /* acl_path : NONE, the system one is taken */
  end;
  
  Correspondent: dsa.BM25.$NASF;
     system: BM25;
     rmt_mbx_dsaname: $NASF;
     local_service_to_use: asf_service;
     authorization: system_low;
     terminal_type: NONE;
     /* acl_path : NONE, the system one is taken */
  end;
  
  Correspondent: dsa.BM25.$NAD;
     system: BM25;
     rmt_mbx_dsaname: $NAD;
     local_service_to_use: nad_service;
  
  
  
  
  
                                 4-65
  
  
  
     authorization: system_low;
     terminal_type: NONE;
     /* acl_path : NONE, the system one is taken */
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-66
  
  
  
  Correspondent: dsa.BM26.EDIT;
     system: BM26;
     rmt_mbx_dsaname: EDIT;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  Correspondent: dsa.BM26.$NOI;
     system: BM26;
     rmt_mbx_dsaname: $NOI;
     local_service_to_use: tm_dialout_service;
     authorization: system_low;
     terminal_type: DSA_SDP;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
  end;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-67
  
  
  
  /*------------------------------------------------------------*/
  /*                          Admin_correspondents              */
  /*------------------------------------------------------------*/
  
  Admin_correspondent: dsa.DA10.$NAD.$NASF;
     system: DA10;
     rmt_mbx_dsaname: $NAD;
     admin_group: admin_group3;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
     type: NAD;
     character_encoding: ASCII;
  end;
  
  Admin_correspondent: dsa.DA10.$NOIAEP.$NAD;
     system: DA10;
     rmt_mbx_dsaname: $NOIAEP;
     admin_group: admin_group1;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
     type: NOI;
     character_encoding: ASCII;
  end;
  
  Admin_correspondent: dsa.DB10.$NAD.$NASF;
     system: DB10;
     rmt_mbx_dsaname: $NAD;
     admin_group: admin_group3;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
     type: NAD;
     character_encoding: ASCII;
  end;
  
  Admin_correspondent: dsa.DB10.$NOIAEP.$NAD;
     system: DB10;
     rmt_mbx_dsaname: $NOIAEP;
     admin_group: admin_group1;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
     type: NOI;
     character_encoding: ASCII;
  end;
  
  
  
  
  
  
  
  
  
  
  
                                 4-68
  
  
  
  Admin_correspondent: dsa.DB10.$NAD.$LOGFILE;
     system: DB10;
     rmt_mbx_dsaname: $NAD;
     admin_group: admin_group2;
     authorization: system_low;
     acl_path: >sc1>mna>dsa>admin_correspondent.acs;
     type: NAD;
     character_encoding: ASCII;
  end;
  
  End;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-69
  
  
  
  _C_O_M_P_I_L_I_N_G _A _N_I_T
  
       To compile the NIT source table into an object table, change
  your  working directory  to  >udd>sa>a  (the directory  where the
  source table is usually kept) and execute the dsa_cv_nif command,
  described  below.   The  object  table  will  be  created in your
  working directory.  It will be  given a name which corresponds to
  the entryname of the source table, with the suffix "nif" replaced
  by the suffix  "nit".  Since, by convention, the  source table is
  usually  named  "NIF.nif",  the  object  table  is  usually named
  "NIF.nit".
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-70
  __________                                             __________
  
  dsa_cv_nif                                             dsa_cv_nif
  __________                                             __________
  
  
  NAME: DSA_CV_NIF
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dsa_cv_nif dsa_nit_path {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  compiles a NIT source table into a NIT object table.
  
  _A_R_G_U_M_E_N_T_S
  
  dsa_nit_path
     is the name of the source  table.  By convention, this name is
     usually   "NIF.nif".    The   suffix   "nif"   is  assumed  if
     dsa_nit_path does not include it.  But the source table itself
     must have this suffix as the last component of its name.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -brief, -bf
     uses the short form of error messages.
  
  -long, -lg
     uses the long form of error messages.
  
  -no_semantic_checking, -nsc
     causes  dsa_cv_nif to compile  the source table  without doing
     any  semantic checking.   Semantic checking  includes pathname
     validation and object reference checking.
  
  -severity N, -sv N
     causes error messages  whose severity is less than  N (where N
     is  0, 1, 2,  3, or 4)  not to be  written to the  user_output
     switch.  If this control argument is not specified, a severity
     level of 0 is assumed (i.e., all error messages are written to
     the user_output switch).
  
  _N_O_T_E_S
  
  If  neither  the  -brief  nor   the  -long  control  argument  is
  specified, each error  message is printed in long  form the first
  time it occurs and in short form thereafter.
  
  The compilation is  done in two phases.  In the  first phase, the
  compiler checks for syntax errors.   If it finds any, you receive
  error messages of the form:
  
  
  
  
                                 4-71
  __________                                             __________
  
  dsa_cv_nif                                             dsa_cv_nif
  __________                                             __________
  
  
     FATAL ERROR error_number, SEVERITY severity_level IN LINE
        line_number
  
  where severity_level has one of the following meanings, depending
  on its value:
  
     Value     Meaning
  
     0         No compilation yet or no error.
     1         Warning.
     2         Correctable error.
     3         Fatal error.
     4         Unrecoverable error.
     5         Could not find source.
  
  In the second phase, the compiler checks for semantic errors.  It
  checks  to  see  that  the  directories,  segments,  and  modules
  specified by pathnames in the NIT actually exist, that the length
  of character strings  is within the defined limits,  and that all
  cross references are correct.  If  there are any semantic errors,
  the  compiler prints  a self-explanatory  error message,  and the
  phrase  "Translation  failed."   If  you  receive  either kind of
  message, you should  edit the NIT source table  and try compiling
  it again.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-72
  
  
  _I_N_S_T_A_L_L_I_N_G _A _N_I_T
  
       To install the NIT object table, use the install command, as
  shown below:
  
       install <object_table_name>
  
  for example:
  
       install NIF.nit
  
  This command will install the NIT in >site>dsa>nit.  The NIT must
  be installed in this location in order for the Multics DSA system
  to  use it.   The install  command is  documented in  the _M_u_l_t_i_c_s
  _A_d_m_i_n_i_s_t_r_a_t_i_o_n,  _M_a_i_n_t_e_n_a_n_c_e,  _a_n_d  _O_p_e_r_a_t_i_o_n_s  _C_o_m_m_a_n_d_s  manual,
  Order No.  GB64.
  
  
  _U_P_D_A_T_I_N_G _A _N_I_T
  
       To update  the NIT (for example,  to add or delete  a host),
  use any Multics  editor to make the necessary changes  to the NIT
  source  table.  Then compile  the NIT and  install it, using  the
  procedures described above; i.e.:
  
       cwd >udd>sa>a
       dsa_cv_nif NIF.nif
       install NIF.nit
  
  The  NIT will  be installed   in >site>dsa,  with the  entry name
  "nit".  The changes will take affect immediately.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 4-73
  
  
  
  
  
  
  
  
  
                              SECTION 5
  
  
              COMMON EXCHANGE INTERFACE (CXI) SUBSYSTEM
  
  
  
  
       The  common  exchange  interface  (CXI)  subsystem  controls
  operations in  a frontend, including the procedures  for taking a
  generator  image from  converted DNS   software and  using it  to
  produce a runnable image with which to start a frontend.
  
  
       This section describes the  cxi_input_daemon command used to
  invoke  the CXI subsystem  and includes detailed  descriptions of
  the DSA-specific requests used to control frontend operations.
  
  
       Section 2 describes the procedures necessary to start up DSA
  on Multics,  including the prerequisites for starting  up the CXI
  subsystem (creating the CXI driver segment and logging in the CXI
  input  daemons).  Section 2  also describes conditions  for using
  subsystem  requests to  load and  execute a  generator image,  to
  load,  execute, and start  a runnable image,  and to start  a CXI
  driver.
  
  
       For  information on  debugging tools  within the  subsystem,
  refer to the debug_mode and dump_frontend requests.
  
  
       NOTE:   The CXI  subsystem should  be executed  in a  ring 2
  process because it uses various  databases that are only writable
  in ring 2 (e.g., cxi_driver_seg).   Normally, it will be executed
  in  a daemon process  which should be  logged in with  an initial
  ring of 2.
  
  
  
  
  
  
  
  
  
  
  
                                 5-1
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  NAME: CXI_INPUT_DAEMON, CID
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  cid frontend_name {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  provides requests  to control a  DSA DN8/7100 frontend  through a
  DIA  channel  connection.   This  includes  loading, dumping, and
  generating the frontend,  as well as running the input  side of a
  CXI driver  (i.e., the DSA  session control to  transport control
  interface over a DIA).
  
  _A_R_G_U_M_E_N_T_S
  
  frontend_name
     specifies  the  DN8/7100  frontend   to  be  managed  by  this
     invocation of the subsystem.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -abbrev, -ab
     enables abbreviation expansion of request lines.
  
  -auto_reboot_ec_name ec_name, -bootec ec_name
     specifies  the entry  name of   the subsystem  exec_com to  be
     executed if  the frontend crashes or  requests rebooting.  The
     default name is "auto_reboot.cidec".
  
  -brief, -bf
     shortens some informative messages and suppresses others.
  
  -debug, -db
     enables cxi_input_daemon's debugging  facilities.  Use of this
     control argument should be restricted to system maintainers.
  
  -ec_search_list list_name, -ecsl list_name
     specifies the name of the search  list to use when looking for
     subsystem  exec_coms.  The  default is  to use  the "exec_com"
     search list.
  
  -ec_suffix ec_suffix, -ecx ec_suffix
     specifies the suffix that  is assumed for subsystem exec_coms.
     The default suffix is "cidec".
  
  
  
  
  
  
                                 5-2
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  -info_dir info_path, -infd info_path
     specifies a directory to be added to the subsystem info search
     list.          By         default         the        directory
     >doc>subsystem>cxi_input_daemon is added.
  
  -long, -lg
     prints the long form of all informative messages.  This is the
     default.
  
  -no_abbrev, -nab
     does not enable abbreviation expansion of request lines.  This
     is the default.
  
  -no_debug, -ndb
     disables cxi_input_daemon's debugging facilities.  This is the
     default.
  
  -no_prompt, -npmt
     suppresses the prompt for request lines in the request loop.
  
  -no_start_up, -nsu
     specifies that  the subsystem start_up exec_com  should not be
     executed.
  
  -physical_channel dia_name, -pc dia_name
     specifies the name of the DIA to be used by this invocation to
     connect to the frontend.  This name must be the one defined on
     the prph dia card for this frontend in the Multics config deck
     and  also  the  one  specified  by  the  dia  statement of the
     Frontend object  definition for this frontend in  the NIT.  If
     no  physical  channel  is  specified,  then  each  DIA channel
     defined in the  NIT for this frontend will be  tried until one
     is found which can be used.
  
  -profile profile_path, -pf profile_path
     specifies the pathname of the  profile to use for abbreviation
     expansion.  The suffix "profile"  is added if necessary.  This
     control argument implies -abbrev.
  
  -prompt STR, -pmt STR
     sets  the  request  loop  prompt  to  STR.   The  default  is:
     ^/cxi_input_daemon^[(^d)^]:^2x
  
  -start_up, -su
     specifies  that  the  subsystem  start_up  exec_com  should be
     executed  after the  subsystem  is  initialized.  This  is the
     default.
  
  
  
  
                                 5-3
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _L_I_S_T _O_F _R_E_Q_U_E_S_T_S
  
  For   a  complete   description   of   any  request,   issue  the
  cxi_input_daemon request:  help request_name.
  
  
  _s_e_l_f___i_d_e_n_t_i_f_y
  
  _S_Y_N_T_A_X
  
  .
  
  _F_U_N_C_T_I_O_N
  
  prints   a  line  describing   the  current  invocation   of  the
  cxi_input_daemon subsystem.
  
  _N_O_T_E_S
  
  The most general form of the line printed by this request is:
  
   cxi_input_daemon V.V (abbrev) (level N): Managing frontend FEP
    through physical channel DIA with {local image | no image |
     image in PATH}. {The driver is started.}
  
  where  V.V  is  the  current  version  of cxi_input_daemon (e.g.,
  1.0a); "(abbrev)" is present if abbreviation expansion of request
  lines is  enabled in this  invocation; "(level N)"  is present if
  there is  more than one active invocation  of cxi_input_daemon to
  identify which invocation; FEP is  the name of the frontend being
  managed by cxi_input_daemon;  DIA is the name of  the DIA channel
  being used to connect to the  frontend; the image in the frontend
  is as described;  and the last sentence is present  if the driver
  is started.
  
  
  _?
  
  _S_Y_N_T_A_X
  
  ?
  
  _F_U_N_C_T_I_O_N
  
  prints a  list of the requests available  in the cxi_input_daemon
  subsystem.
  
  
  
  
  
                                 5-4
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _a_b_b_r_e_v_, _a_b
  
  _S_Y_N_T_A_X
  
  ab {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [ab]
  
  _F_U_N_C_T_I_O_N
  
  controls  abbreviation  processing  of  request  lines within the
  cxi_input_daemon subsystem.  As an active request, abbrev returns
  "true"  if abbreviation expansion  of request lines  is currently
  enabled within the subsystem and "false" if it is not.  Note that
  control arguments may not be used with the active request.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -off
     specifies that abbreviations should not be expanded.
  
  -on
     specifies that abbreviations should  be expanded.  This is the
     default.
  
  -profile profile_path
     specifies  that the  segment named  by profile_path  should be
     used as the profile segment; the suffix ".profile" is added to
     profile_path  if it  is not   present.  The  segment named  by
     profile_path must exist.
  
  _N_O_T_E_S
  
  The  cxi_input_daemon  subsystem  provides  command  line control
  arguments (-abbrev, -no_abbrev, -profile)  to specify the initial
  state  of abbreviation processing  within the subsystem.   If the
  abbrev  request is  invoked with  no control  arguments, it  will
  enable  abbreviation processing  within the  subsystem using  the
  profile that  was last used in the  current subsystem invocation.
  If  abbreviation  processing  was  not  previously  enabled,  the
  profile in use at Multics command  level is used; this profile is
  normally [home_dir]>Person_id.profile.
  
  
  
  
  
  
  
                                 5-5
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _a_n_s_w_e_r
  
  _S_Y_N_T_A_X
  
  answer STR -control_args request_line
  
  _F_U_N_C_T_I_O_N
  
  provides preset answers to questions asked by another request.
  
  _A_R_G_U_M_E_N_T_S
  
  STR
     is the desired answer to any  question.  If the answer is more
     than  one word,  it must  be enclosed  in quotes.   If STR  is
     -query,  the question is  passed on to  the user.  The  -query
     control argument is the only one  that can be used in place of
     STR.
  
  request_line
     is  any  cxi_input_daemon  subsystem  request  line.   It  can
     contain  any number of  separate arguments (i.e.,  have spaces
     within it) and need not be enclosed in quotes.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -brief, -bf
     suppresses  printing  (on  the  user's  terminal)  of both the
     question and the answer.
  
  -call STR
     evaluates the active string STR to obtain the next answer in a
     sequence.    The    active   string   is    constructed   from
     cxi_input_daemon  subsystem active  requests and  from Multics
     active strings (using the cxi_input_daemon subsystem's execute
     active  request).  The  outermost  level  of brackets  must be
     omitted; the  entire string must  be enclosed in  quotes if it
     contains  request processor   special characters.   The return
     value "true" is translated to "yes", and "false" to "no".  All
     other return values are passed without translation.
  
  -exclude STR, -ex STR
     passes on, to the user  or other handler, questions whose text
     matches  STR.  If  STR is   surrounded by  slashes (/),  it is
     interpreted as  a qedx regular expression.   Otherwise, answer
     tests whether  STR is literally  contained in the  text of the
     question.   Multiple occurrences  of -match  and -exclude  are
     allowed (see "Notes" below).  They apply to the entire request
     line.
  
  
                                 5-6
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  -match STR
     answers  only questions  whose text  matches STR.   If STR  is
     surrounded by slashes (/), it is interpreted as a qedx regular
     expression.  Otherwise, answer tests  whether STR is literally
     contained in  the text of the  question.  Multiple occurrences
     of -match and -exclude are  allowed (see "Notes" below).  They
     apply to the entire request line.
  
  -query
     skips the next  answer in a sequence, passing  the question on
     to the user.  The answer is read from the user_i/o I/O switch.
  
  -then STR
     supplies the next answer in a sequence.
  
  -times N
     gives the previous answer (STR,  -then STR, or -query) N times
     only (where N is an integer).
  
  _N_O_T_E_S
  
  The  answer request  provides  preset  responses to  questions by
  establishing an  on unit for the  command_question condition, and
  then executing  the designated request  line.  If any  request in
  the request  line calls the command_query_  subroutine (described
  in  the _M_u_l_t_i_c_s  _S_u_b_r_o_u_t_i_n_e_s _a_n_d  _I/_O _M_o_d_u_l_e_s  manual, Order  No.
  AG93) to  ask a question,  the on unit  is invoked to  supply the
  answer.  The on unit is  reverted when the answer request returns
  to  subsystem  request  level.    See  the  _M_u_l_t_i_c_s  _P_r_o_g_r_a_m_m_e_r'_s
  _R_e_f_e_r_e_n_c_e  _M_a_n_u_a_l,  Order  No.   AG91,  for  a  discussion of the
  command_question condition.
  
  If a question is asked that requires  a yes or no answer, and the
  preset  answer is  neither "yes"  nor "no",  the on  unit is  not
  invoked.
  
  The last answer  specified is issued as many  times as necessary,
  unless it is followed by the -times N control argument.
  
  The  -match and  -exclude control  arguments are  applied in  the
  order  specified.  Each  -match causes   a given  question to  be
  answered if it matches STR; each  -exclude causes it to be passed
  on  if it  matches STR.   A question  that has  been excluded  by
  -exclude  is reconsidered  if it  matches a  -match later  in the
  request line.  For example, the request line:
  
     answer yes -match /apple/ -exclude /apple_tree/
           -match /^apple_tree/
  
  
  
                                 5-7
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  answers questions  containing the string "apple",  except that it
  does not answer questions containing "apple_tree", except that it
  does answer questions beginning with "apple_tree".
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-8
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _d_e_b_u_g___m_o_d_e
  
  _S_Y_N_T_A_X
  
  debug_mode {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  enables or disables the cxi_input_daemon debugging facilities.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -off
     disables cxi_input_daemon's debugging facilities.  This is the
     default.
  
  -on
     enables  cxi_input_daemon's  debugging  facilities,  with  the
     result that most  CXI operations are traced in  the DSA system
     log (dsa_sl),  and the standard ssu_  debugging facilities are
     turned on.
  
  _N_O_T_E_S
  
  This request is intended for  use only by system maintainers when
  debugging cxi_input_daemon operations.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-9
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _d_o
  
  _S_Y_N_T_A_X
  
  do request_string {args}
  
  or
  
  do -control_args
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [do "request_string" args]
  
  _F_U_N_C_T_I_O_N
  
  expands  a request  line by  substituting the  supplied arguments
  into the line before execution.  Control arguments may be used to
  set  the mode  of operation  of  the  do request.   As an  active
  request,  do  returns  the  expanded  request_string  rather than
  executing it.
  
  _A_R_G_U_M_E_N_T_S
  
  request_string
     is a request line in quotes.
  
  args
     are  character  string  arguments  that  replace parameters in
     request_string.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -absentee
     establishes an any_other handler  which catches all conditions
     and aborts execution of the  request line without aborting the
     process.
  
  -brief, -bf
     specifies that the expanded request line should not be printed
     before execution.  This is the default.
  
  -go
     specifies that  the expanded request line should  be passed on
     for execution.  This is the default.
  
  -interactive
     does not establish an any_other handler.  This is the default.
  
  
  
                                 5-10
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  -long, -lg
     specifies  that the  expanded request  line should  be printed
     before execution.
  
  -nogo
     specifies that the expanded request  line should not be passed
     on for execution.
  
  _L_I_S_T _O_F _P_A_R_A_M_E_T_E_R_S
  
  Any sequence beginning with & in  the request line is expanded by
  the do request using the arguments given on the request line.
  
     &I
        is replaced by argI.  I must be a digit from 1 to 9.
  
     &(I)
        is also replaced by argI.  I can be any value, however.
  
     &qI
        is  replaced by argI  with any quotes  in argI doubled.   I
        must be a digit from 1 to 9.
  
     &q(I)
        is also replaced by argI with any quotes doubled.  I can be
        any value, however.
  
     &rI
        is replaced  by argI surrounded  by a level  of quotes with
        any contained quotes doubled.  I must  be a digit from 1 to
        9.
  
     &r(I)
        is also replaced  by a requoted argI.  I can  be any value,
        however.
  
     &fI
        is  replaced by  all the  arguments starting  with argI.  I
        must be a digit from 1 to 9.
  
     &f(I)
        is also  replaced by all the arguments  starting with argI.
        I can be any value, however.
  
     &qfI
        is replaced  by all the  arguments starting with  argI with
        any quotes doubled.  I must be a digit from 1 to 9.
  
  
  
  
                                 5-11
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
     &qf(I)
        is also  replaced by all  the arguments starting  with argI
        with quotes doubled.  I can be any value, however.
  
     &rI
        is replaced by all the  arguments starting with argI.  Each
        argument  is placed  in a  level of  quotes with  contained
        quotes doubled.  I must be a digit from 1 to 9.
  
     &rf(I)
        is also  replaced by all the arguments  starting with argI,
        requoted.  I can be any value, however.
  
     &&
        is replaced by an ampersand.
  
     &
        is replaced  by a 15  character unique string.   The string
        used is the same everywhere &  appears in the request line.
  
     &n
        is replaced by the actual number of arguments supplied.
  
     &f&n
        is replaced by the last argument supplied.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-12
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _d_u_m_p___f_r_o_n_t_e_n_d_, _d_u_m_p
  
  _S_Y_N_T_A_X
  
  dump {dump_pathname} {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [dump {dump_pathname} {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  dumps  the frontend  memory  into  the specified  Multics segment
  using the specified bounds.
  
  _A_R_G_U_M_E_N_T_S
  
  dump_pathname
     specifies the name of the  Multics segment where the dump will
     be  stored.  If  this name  is not  specified, a  name of  the
     following  form  is  used:   "dump.FEP_NAME.DATE_TIME",  where
     FEP_NAME is the name of the current frontend, and DATE_TIME is
     a 12-character  string representing the current  date and time
     with one second resolution.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -for dec_words
     specifies  the number  of words,  in decimal,  that should  be
     dumped.  The  default is to  dump all of  the frontend memory.
     This  control argument  is incompatible  with the  -to_address
     control argument.
  
  -force, -fc
     specifies that the frontend  should be dumped without querying
     the user, even if it is running or a driver is started.
  
  -from_address hex_addr, -faddr hex_addr
     specifies the address, in hexadecimal,  of the location in the
     frontend at  which the dump  should start.  The  default is to
     start at location 0.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  
  
  
                                 5-13
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  -no_force, -nfc
     specifies  that if  the frontend   is running  or a  driver is
     started,  the user  should be  queried before  the frontend is
     dumped.  This is the default.
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  -to_address hex_addr, -taddr hex_addr
     specifies the address, in hexadecimal,  of the location in the
     frontend  at which the  dump should stop.   The default is  to
     dump to the end of  frontend memory.  This control argument is
     incompatible with the -for control argument.
  
  _N_O_T_E_S
  
  The  file created by  this request is  an unstructured file  with
  each 8-bit byte of frontend memory  stored in a 9-bit byte in the
  file (right-justified).  Thus, the  dump_segment command with the
  -hex9  control  argument  can  be  used  to  examine  the dump in
  hexadecimal.   The   file  also  has  a  header   as  defined  in
  mna_dump_file_header.incl.pl1,  currently eight words  (32 bytes)
  long.   Thus, the  -offset control  argument to  dump_segment can
  also be used  to give the actual memory offsets  in the frontend.
  (The  dump_segment command is  described in the  _M_u_l_t_i_c_s _C_o_m_m_a_n_d_s
  _a_n_d _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s manual, Order No.  AG92.)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-14
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _e_x_e_c___c_o_m_, _e_c
  
  _S_Y_N_T_A_X
  
  ec ec_path {ec_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [ec ec_path {ec_args}]
  
  _F_U_N_C_T_I_O_N
  
  executes  an exec_com program  written in the  exec_com language.
  This program  is used to  pass cxi_input_daemon request  lines to
  the  cxi_input_daemon  subsystem  and  to  pass  input  lines  to
  cxi_input_daemon  requests  which  read   input.   As  an  active
  request,  exec_com  returns  a  value  specified  by the exec_com
  program via the &return statement.
  
  _A_R_G_U_M_E_N_T_S
  
  ec_path
     is the pathname of an  exec_com program.  The suffix, which is
     normally  the  name  of  the  subsystem,  is  assumed  if  not
     specified.
  
  ec_args
     are  optional  arguments  to  the  exec_com  program  and  are
     substituted  for parameter references  in the program  such as
     &1.
  
  _N_O_T_E_S
  
  The  cxi_input_daemon subsystem  may define  a search  list to be
  used  to find  the exec_com  program.  If  this is  the case, the
  search  list is  used if  ec_path does  not contain  a "<" or ">"
  character; if the ec_path does contain either a "<" or ">", it is
  assumed to be a relative pathname.
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-15
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  For a  description of the  exec_com language (both  version 1 and
  version 2), type:
  
     .. help v1ec v2ec
  
  When  the  &[...]  construct  and  the  active  string  in an &if
  statement in an exec_com  program are evaluated, cxi_input_daemon
  subsystem  active requests  are used  rather than  Multics active
  functions.   The  cxi_input_daemon   subsystem's  execute  active
  request may be used to evaluate Multics active strings within the
  exec_com.
  
  NOTE:  in the present  implementation, any errors detected during
  execution  of  an  exec_com  within  a  subsystem  will abort the
  request line in which the exec_com request was invoked.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-16
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _e_x_e_c_u_t_e_, _e
  
  _S_Y_N_T_A_X
  
  e LINE
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [e LINE]
  
  _F_U_N_C_T_I_O_N
  
  executes  the supplied  line as  a Multics  command line.   As an
  active  request, execute  evaluates a  Multics active  string and
  returns  the  result  to  the  cxi_input_daemon subsystem request
  processor.
  
  _A_R_G_U_M_E_N_T_S
  
  LINE
     is  the Multics  command line  to be  executed or  the Multics
     active  string to be  evaluated.  It need  not be enclosed  in
     quotes.
  
  _N_O_T_E_S
  
  The  recommended method  to execute  a Multics  command line from
  within  the  cxi_input_daemon  subsystem   is  the  ".."   escape
  sequence.  The execute request is  intended as a means of passing
  information from the subsystem to the Multics command processor.
  
  All   ()s,  []s,   and  ""s   in  LINE   are  processed   by  the
  cxi_input_daemon subsystem request processor  and not the Multics
  command processor.   This fact permits the passing  of the values
  of  cxi_input_daemon  active  requests  to  Multics commands when
  using the  execute request (or  to Multics active  functions when
  using the execute active request) for further manipulation before
  returning the  values to the subsystem request  processor for use
  within a request line.
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-17
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _e_x_e_c_u_t_e___i_n___f_r_o_n_t_e_n_d_, _e_x_f_e_p
  
  _S_Y_N_T_A_X
  
  exfep {map_pathname} {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [exfep {map_pathname} {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  executes a  previously loaded frontend  image in a  frontend; for
  instance,  to execute  a generator  image and  produce a runnable
  image.
  
  _A_R_G_U_M_E_N_T_S
  
  map_pathname
     specifies the name  of the Multics segment into  which the map
     records  generated by  the  executing  frontend image  will be
     stored.   This  file  is  a  normal  Multics  text  file.   If
     unspecified,   a  name   of  the   following  form   is  used:
     "map.IMAGE_NAME.ex" where IMAGE_NAME is  the entry name of the
     current image  in the frontend,  or "local_image" if  no image
     was loaded from Multics.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -address hex_addr, -addr hex_addr
     specifies the address, in hexadecimal,  of the location in the
     frontend at  which execution should start.  The  default is to
     start at location 400x.
  
  -brief, -bf
     specifies  that  no  informative  messages,  either  from  the
     request or the frontend, should be printed during execution.
  
  -force, -fc
     specifies  that  the  frontend   should  be  executed  without
     querying the user, even if there is currently a driver running
     the frontend.  This control argument should only be used if it
     is known that the driver assumed to be running is broken.
  
  -go {config_name} {-control_args}
     specifies  the GO  card options  to be  sent to  the DNS  when
     executing the image.  A  complete description of these options
     appears in the _D_N_S  _S_y_s_t_e_m _I_n_s_t_a_l_l_a_t_i_o_n _a_n_d _G_e_n_e_r_a_t_i_o_n manual,
     Order  No.  DP43  and in   the _D_N_S  _S_y_s_t_e_m _G_e_n_e_r_a_t_i_o_n  manual,
  
  
                                 5-18
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
     Reference No.  39 A2 9807.   This control argument must appear
     last  on  the  request  line  since  it  takes  all  following
     arguments  and builds a  GO card from  them.  No special  case
     handling  is performed  on the  following arguments,  so if an
     argument is required to be uppercase it must be typed as such.
     If this control argument is not specified, the default GO card
     consists  of GO  with no  other arguments.   For example,  the
     request  "exfep -go CONFIG  -MAP -NP" generates  a GO card  as
     follows:  "GO CONFIG -MAP -NP".
  
  -local_image, -li
     specifies that  the frontend was  not loaded from  Multics but
     has  a local  image that  was loaded  from elsewhere,  e.g., a
     diskette.   If this  control argument   is not  used, and  the
     frontend has not been loaded  from Multics, then the user will
     be queried as to whether or not the execution should proceed.
  
  -long, -lg
     specifies that  informative messages should be  printed.  This
     control  argument  is  useful  when  messages  are sent during
     execution  in  the  frontend.   For  instance, informative and
     error messages are sent during generation of a runnable image,
     to  report on  the progress   of this  activity.  This  is the
     default.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  -no_force, -nfc
     specifies  that if  there is  a driver  currently running  the
     frontend, the  user should be  queried before the  frontend is
     executed.  This is the default.
  
  -no_local_image, -nli
     specifies that the frontend has  been loaded from Multics.  If
     this is not  the case, the user will be  queried as to whether
     or not the execution should proceed.  This is the default.
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  
  
  
  
                                 5-19
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _N_O_T_E_S
  
  After a frontend is loaded, it  must be executed before it can be
  started.  In the  case of a generator image,  executing the image
  produces a runnable image which may then be started.  In the case
  of a runnable image, it must  first be executed and then started.
  Only  the GO  card options  specified in  the execute_in_frontend
  request have any effect; the ones specified in the start_frontend
  request are ignored.
  
  When a  runnable image is  generated, it is  stored in a  file on
  Multics using the pathname argument from the -SV control argument
  on the END card in the config file.  Normally, the name takes the
  "i" suffix  to indicate that the  runnable image is stored  as an
  image file.  However, if the runnable image is to be used to load
  a remote DN8/7100, then the name takes the "b" suffix to indicate
  that it  is in binary (sequential) format.   (See the description
  of the dsa_cv_dns_tape  command in Section 2 for  a discussion of
  these file types.)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-20
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _f_r_o_n_t_e_n_d___w_o_r_k_i_n_g___d_i_r_, _f_w_d
  
  _S_Y_N_T_A_X
  
  fwd
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [fwd]
  
  _F_U_N_C_T_I_O_N
  
  returns the pathname of the  working directory defined in the NIT
  for the current frontend.
  
  _N_O_T_E_S
  
  This request  serves the same purpose  as the dsa_fep_working_dir
  command (described in Section 2), but does not require a frontend
  name since it uses the one for this subsystem invocation.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-21
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _h_e_l_p
  
  _S_Y_N_T_A_X
  
  help {topics} {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  prints descriptions of  cxi_input_daemon requests and information
  about other topics.
  
  _A_R_G_U_M_E_N_T_S
  
  topics
     are the requests or other topics on which information is to be
     printed.  The  available requests may be printed  by using the
     list_requests request.  The available topics may be printed by
     using the list_help request.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -brief, -bf
     prints  only  a  summary  of  a  request  or  active  request,
     including  the  Syntax  section,  list  of  arguments, control
     arguments, etc..
  
  -search STRs, -srh STRs
     begins  printing  with  the  paragraph  containing  all of the
     strings specified by STRs.  By default, printing begins at the
     top of the information.
  
  -section STRs, -scn STRs
     begins printing at the section whose title contains all of the
     strings specified by STRs.  By default, printing begins at the
     top of the information.
  
  -title
     prints section  titles and section  line counts, then  asks if
     the user wants to see the first paragraph of information.
  
  _L_I_S_T _O_F _R_E_S_P_O_N_S_E_S
  
  The most useful  responses which can be given  to questions asked
  by the help request are:
  
     yes, y
        prints the next paragraph of information on this topic.
  
  
  
  
                                 5-22
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
     no, n
        stops printing  information for this topic  and proceeds to
        the next topic, if any.
  
     quit, q
        stops  printing information for  this topic and  returns to
        cxi_input_daemon request level.
  
     rest {-section}, r {-section}, rest {-scn}, r {-scn}
        prints  remaining   information  for  this   topic  without
        intervening questions.  If -section  or -scn is given, help
        prints  only  the  rest  of  the  current  section  without
        questions and then  asks if the user wants to  see the next
        section.
  
     section {STRs} {-top}, scn {STRs} {-top}
     section {STRs} {-t}, scn {STRs} {-t}
        skips to the  next section whose title contains  all of the
        strings specified by  STRs.  If -top or -t  is given, title
        searching starts  at the top  of the information.   If STRs
        are omitted,  help uses the STRs from  the previous section
        response or the -section control argument.
  
     search {STRs} {-top}, srh {STRs} {-top}
     search {STRs} {-t}, srh {STRs} {-t}
        skips  to the  next  paragraph  containing all  the strings
        STRs.  If -top or -t is  given, searching starts at the top
        of  the information.   If STRs  are omitted,  help uses the
        STRs  from  the  previous  search  response  or the -search
        control argument.
  
     skip {-section} {-seen}, s {-section} {-seen}
     skip {-scn} {-seen}, s {-scn} {-seen}
        skips to the next paragraph.  If -section or -scn is given,
        skips all  paragraphs of the current section.   If -seen is
        given, skips to  the next paragraph which the  user has not
        seen.  Only  one control argument  is allowed in  each skip
        response.
  
     title {-top}, title {-t}
        lists titles and line counts  of the sections which follow.
        If  -top or  -t is  given, help  lists all  section titles.
        After  the titles  are printed,  help repeats  the previous
        question.
  
     ?
        prints the list of responses allowed to help queries.
  
  
  
  
                                 5-23
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
     .
        prints   "help"  to    identify  the   current  interactive
        environment.
  
     .. command_line
        treats the  remainder of the response as  a Multics command
        line.
  
  
  _N_O_T_E_S
  
  If the  topics argument is  not specified, the  help request will
  explain  what  requests  are  available  in  the cxi_input_daemon
  subsystem to obtain information on the subsystem.
  
  This is  only a partial description  of the help request.   For a
  complete  description  of  all   of  the  control  arguments  and
  responses accepted by this request, type:
  
     .. help help
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-24
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _i_f
  
  _S_Y_N_T_A_X
  
  if expr -then line1 {-else line2}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [if expr -then STR1 {-else STR2}]
  
  _F_U_N_C_T_I_O_N
  
  conditionally executes one of two  request lines depending on the
  value of an active string.  As  an active request, if returns one
  of  two   character  strings  to  the   cxi_input_daemon  request
  processor depending on the value of an active string.
  
  _A_R_G_U_M_E_N_T_S
  
  expr
     is an  active string which  must evaluate to  either "true" or
     "false".     The   active    string   is    constructed   from
     cxi_input_daemon  active requests  and Multics  active strings
     (using the cxi_input_daemon execute active request).
  
  line1
     is the  cxi_input_daemon request line  to be executed  if expr
     evaluates to "true".  If the request line contains any request
     processor characters, it must be enclosed in quotes.
  
  STR1
     is  returned as  the value  of the  if active  request if expr
     evaluates to "true".
  
  line2
     is the  cxi_input_daemon request line  to be executed  if expr
     evaluates to "false".  If this argument is omitted and expr is
     "false",  no  additional  request  line  is  executed.  If the
     request  line contains  any request  processor characters,  it
     must be enclosed in quotes.
  
  STR2
     is  returned as  the value  of the  if active  request if expr
     evaluates to "false".  If this argument is omitted and expr is
     "false", a null string is returned.
  
  
  
  
  
  
                                 5-25
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _l_i_s_t___h_e_l_p_, _l_h
  
  _S_Y_N_T_A_X
  
  lh {topics}
  
  _F_U_N_C_T_I_O_N
  
  displays the names of all cxi_input_daemon info segments on given
  topics.
  
  _A_R_G_U_M_E_N_T_S
  
  topics
     specifies the  topics of interest.  Any  cxi_input_daemon info
     segment which contains  one of these topics as  a substring is
     displayed.  If the topics argument  is not specified, all info
     segments available for the subsystem are listed.
  
  _N_O_T_E_S
  
  When  matching topics  with info  segment names,  an info segment
  name is considered to match a topic  only if that topic is at the
  beginning  or end of  a word within  the segment name.   Words in
  info segment  names are bounded by  the beginning and end  of the
  segment  name  and  by  the  characters  period  (.), hyphen (-),
  underscore (_), and  dollar sign ($).  The ".info"  suffix is not
  considered when matching topics.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-26
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _l_i_s_t___r_e_q_u_e_s_t_s_, _l_r
  
  _S_Y_N_T_A_X
  
  lr {STRs} {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  prints a brief description of selected cxi_input_daemon requests.
  
  _A_R_G_U_M_E_N_T_S
  
  STRs
     specifies the requests to be  listed.  Any request with a name
     containing  one of  these strings  is listed  unless -exact is
     used, in which case the request name must exactly match one of
     these  strings.  If  no STRs  are specified,  all requests are
     displayed.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -all, -a
     includes undocumented  and unimplemented requests in  the list
     of requests eligible for matching the STR arguments.
  
  -exact
     lists only  those requests one of whose  names exactly matches
     one of the STR arguments.
  
  _N_O_T_E_S
  
  When  matching  STRs  with  request  names,  a  request  name  is
  considered to match a STR only if that STR is at the beginning or
  end of  a word within the  request name.  Words in  request names
  are bounded by  the beginning and end of the  request name and by
  the characters period (.), hyphen (-), underscore (_), and dollar
  sign ($).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-27
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _l_o_a_d___f_r_o_n_t_e_n_d_, _l_o_a_d
  
  _S_Y_N_T_A_X
  
  load {load_pathname} {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [load {load_pathname} {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  loads  the memory  of the  frontend from  the specified  segment,
  starting at the specified frontend memory location.
  
  _A_R_G_U_M_E_N_T_S
  
  load_pathname
     specifies the  name of the Multics segment  which contains the
     DNS memory  image.  The segment  must be an  unstructured file
     with     a    two     word    header     as    described    by
     mna_load_file_header.incl.pl1.   It  is  normally  created  by
     using the DNS generator image to create a runnable image.  The
     default name, if none is specified, is "IMAMEM.i".
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -address hex_addr, -addr hex_addr
     specifies the address, in hexadecimal,  of the location in the
     frontend  at which loading  should start.  If  specified, this
     address overrides  the address specified in the  header of the
     load file.  If not specified, the address in the header of the
     load file is used.
  
  -force, -fc
     specifies that the frontend  should be loaded without querying
     the user, even if it is running or a driver is started.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  -no_force, -nfc
     specifies  that if  the frontend   is running  or a  driver is
     started,  the user  should be  queried before  the frontend is
     loaded.  This is the default.
  
  
  
                                 5-28
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  _N_O_T_E_S
  
  The file used  by this request is an unstructured  file with each
  8-bit byte of frontend memory stored  in a 9-bit byte in the file
  (right-justified).  Thus, the dump_segment command with the -hex9
  control argument can be used to examine the image in hexadecimal.
  The    file    also    has     a    header    as    defined    in
  mna_load_file_header.incl.pl1, currently two  words (eight bytes)
  long.   Thus, the  -offset control  argument to  dump_segment can
  also be used  to give the actual memory offsets  in the frontend.
  (The  dump_segment command is  described in the  _M_u_l_t_i_c_s _C_o_m_m_a_n_d_s
  _a_n_d _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s manual, Order No.  AG92.)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-29
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _q_u_i_t_, _q
  
  _S_Y_N_T_A_X
  
  q {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  cleans up the invocation and  exits cxi_input_daemon.  If the CXI
  driver or frontend is still running, the request will first query
  the user.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -force, -fc
     specifies that  the user should not be  queried for permission
     to  exit from  cxi_input_daemon, even   if the  driver or  the
     frontend is still running.
  
  -no_force, -nfc
     specifies that  the user should  be queried for  permission to
     exit from  cxi_input_daemon if the  driver or the  frontend is
     still running.  This is the default.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-30
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _r_e_a_d_y_, _r_d_y
  
  _S_Y_N_T_A_X
  
  rdy
  
  _F_U_N_C_T_I_O_N
  
  prints a Multics ready message.
  
  _N_O_T_E_S
  
  The  Multics general_ready  command may   be used  to change  the
  format  of the  ready message  printed by  this request  and also
  after execution of request lines if the ready_on request is used.
  Type:
  
     .. help general_ready
  
  for more information on the available formats.
  
  The default ready message gives the time of day and the amount of
  CPU time  and page faults used  since the last ready  message was
  typed.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-31
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _r_e_a_d_y___o_f_f_, _r_d_f
  
  _S_Y_N_T_A_X
  
  rdf
  
  _F_U_N_C_T_I_O_N
  
  disables printing of a ready message after each request line.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-32
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _r_e_a_d_y___o_n_, _r_d_n
  
  _S_Y_N_T_A_X
  
  rdn
  
  _F_U_N_C_T_I_O_N
  
  enables printing of a ready message after each request line.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-33
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _s_t_a_r_t___d_r_i_v_e_r_, _s_t_d
  
  _S_Y_N_T_A_X
  
  std {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [std {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  starts the  CXI driver for the current  invocation.  This request
  does not normally  return unless an error occurs.  A  QUIT and pi
  sequence  may  be  used  to  get  back  to  the  cxi_input_daemon
  subsystem.  When used as  an active request, start_driver returns
  a string indicating what the error was.  The string is one of the
  following:  not_responding, reboot, interrupt, error, bad_pcw, or
  quit.  Quit is returned in response to a QUIT and is normal.  All
  of the others indicate an error of some sort.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -force, -fc
     specifies that  the driver should be  started without querying
     the user, even if the frontend is not running.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  -no_force, -nfc
     specifies that if the frontend is not running, the user should
     be queried before the driver is started.  This is the default.
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  _N_O_T_E_S
  
  This request runs a timing loop using the time value specified in
  the  NIT by  the  idle_timer_interval  statement of  the Frontend
  object definition for this frontend.   Each time through the loop
  the CXI input processing subroutine  is called to process any new
  
  
                                 5-34
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  DSA  input.  If  the frontend  sends an  interrupt indicating  an
  error,  this  request  will  attempt  to  execute  the  auto_boot
  subsystem  exec_com  to  restart  the  frontend.   A  QUIT and pi
  sequence can also be used to get back to subsystem request level.
  A subsequent start_driver request will normally resume processing
  where   it  left   off,  unless   too  much   time  has   elapsed
  (approximately two minutes), in which case the frontend will have
  decided that the host is dead.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-35
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _s_t_a_r_t___f_r_o_n_t_e_n_d_, _s_t_f
  
  _S_Y_N_T_A_X
  
  stf {map_pathname} {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [stf {map_pathname} {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  starts  a previously  loaded and   executed frontend  image in  a
  frontend; for instance, to cause a runnable image to start.
  
  _A_R_G_U_M_E_N_T_S
  
  map_pathname
     specifies the name  of the Multics segment into  which the map
     records  generated  by  starting  the  frontend  image will be
     stored.   This  file  is  a  normal  Multics  text  file.   If
     unspecified,   a  name   of  the   following  form   is  used:
     "map.IMAGE_NAME.st" where IMAGE_NAME is  the entry name of the
     current image  in the frontend,  or "local_image" if  no image
     was loaded from Multics.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -address hex_addr, -addr hex_addr
     specifies the address, in hexadecimal,  of the location in the
     frontend at  which the image  should be started.   There is no
     default since this value is currently ignored by the frontend.
  
  -brief, -bf
     specifies  that  no  informative  messages,  either  from  the
     request or the frontend, should  be printed while the image is
     being started.
  
  -force, -fc
     specifies  that the image  should be started  without querying
     the  user, even  if there  is currently  a driver  running the
     frontend.  This  control argument should only be  used when it
     is known that the driver assumed to be running is broken.
  
  -go {config_name} {-control_args}
     specifies  the GO  card options  to be  sent to  the DNS  when
     starting the  image.  A complete description  of these options
     appears in the _D_N_S  _S_y_s_t_e_m _I_n_s_t_a_l_l_a_t_i_o_n _a_n_d _G_e_n_e_r_a_t_i_o_n manual,
     Order  No.  DP43  and in   the _D_N_S  _S_y_s_t_e_m _G_e_n_e_r_a_t_i_o_n  manual,
  
  
                                 5-36
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
     Reference No.  39 A2 9807.   This control argument must appear
     last  on  the  request  line  since  it  takes  all  following
     arguments  and builds a  GO card from  them.  No special  case
     handling  is  performed  on  the  following  arguments, so any
     argument required to  be uppercase must be typed  as such.  If
     this control  argument is not  specified, the default  GO card
     consists  of GO  with no  other arguments.   For example,  the
     request  "stf -go -MAP  -NP" generates a  GO card as  follows:
     "GO -MAP -NP".
  
  -local_image, -li
     specifies that  the frontend was  not loaded from  Multics but
     has  a local  image that  was loaded  from elsewhere,  e.g.  a
     diskette.   If this  control argument   is not  used, and  the
     frontend has not been loaded  from Multics, then the user will
     be queried as to whether or not the image should be started.
  
  -long, -lg
     specifies that  informative messages should be  printed.  This
     control argument is useful when a frontend being started sends
     messages.  This is the default.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  -no_force, -nfc
     specifies that if there is  a driver running the frontend, the
     user should  be queried before the frontend  is started.  This
     is the default.
  
  -no_local_image, -nli
     specifies that the frontend has  been loaded from Multics.  If
     this is not  the case, the user will be  queried as to whether
     or not the image should be started.  This is the default.
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  
  
  
  
  
  
  
                                 5-37
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _N_O_T_E_S
  
  After a frontend is loaded, it  must be executed before it can be
  started.  In the  case of a generator image,  executing the image
  produces a runnable image which may then be started.  In the case
  of a runnable image, it must  first be executed and then started.
  Only  the GO  card options  specified in  the execute_in_frontend
  request have any effect; the ones specified in the start_frontend
  request are ignored.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-38
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _s_t_o_p___d_r_i_v_e_r_, _s_t_p_d
  
  _S_Y_N_T_A_X
  
  stpd {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [stpd {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  stops the CXI driver.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -force, -fc
     specifies that  the driver should be  stopped without querying
     the user.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  -no_force, _nfc
     specifies that the user should be queried before the driver is
     stopped.  This is the default.
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  _N_O_T_E_S
  
  Use  this  request  to  stop  the  CXI  driver  for  the  current
  invocation  in orderly fashion.   The stop action  terminates all
  connections supported  by this driver and  performs other cleanup
  activities so that the driver will subsequently start correctly.
  
  
  
  
  
  
  
  
  
                                 5-39
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _s_t_o_p___f_r_o_n_t_e_n_d_, _s_t_p_f
  
  _S_Y_N_T_A_X
  
  stpf {-control_args}
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [stpf {-control_args}]
  
  _F_U_N_C_T_I_O_N
  
  stops the frontend.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -force, -fc
     specifies that the frontend should be stopped without querying
     the user, even if it is not running.
  
  -notify, -nt
     specifies that  the user should  be notified (by  a message on
     the  bootload  console)  if  an  error  occurs.   This control
     argument  will also  cause any  subsystem exec_com  containing
     this request or active function to be aborted.
  
  -no_force, _nfc
     specifies that if the frontend is not running, the user should
     be  queried  before  the  frontend  is  stopped.   This is the
     default.
  
  -no_notify, -nnt
     specifies  that the user  should not be  notified if an  error
     occurs.  This control argument  will cause request invocations
     to abort  and active function  invocations to return  a value.
     This is the default.
  
  _N_O_T_E_S
  
  This  request  stops  the  current  frontend.   It  cleans up the
  current  invocation, but  does not   notify the  frontend of  the
  action being taken.
  
  
  
  
  
  
  
  
  
                                 5-40
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _s_u_b_s_y_s_t_e_m___n_a_m_e
  
  _S_Y_N_T_A_X
  
  subsystem_name
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [subsystem_name]
  
  _F_U_N_C_T_I_O_N
  
  prints or returns the name of the cxi_input_daemon subsystem.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-41
  ________________                                 ________________
  
  cxi_input_daemon                                 cxi_input_daemon
  ________________                                 ________________
  
  
  _s_u_b_s_y_s_t_e_m___v_e_r_s_i_o_n
  
  _S_Y_N_T_A_X
  
  subystem_version
  
  _S_Y_N_T_A_X _A_S _A_N _A_C_T_I_V_E _R_E_Q_U_E_S_T
  
  [subsystem_version]
  
  _F_U_N_C_T_I_O_N
  
  prints  or returns  the  version  number of  the cxi_input_daemon
  subsystem.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 5-42
  
  
  
  
  
  
  
  
  
                              SECTION 6
  
  
            DISTRIBUTED SYSTEM ADMINISTRATION AND CONTROL
  
  
  
  
       The  purpose  of  DSAC  is  to  control  and  coordinate the
  components  of a  DSA network  (frontends, systems,  etc.).  DSAC
  collects   information  in   order  to   detect  errors,   create
  statistics,  and  enhance  performance.   It  also  provides test
  capabilities.   Some DSAC  functions  exist  on each  DSA system;
  access  to these  functions  is  strictly controlled.   The three
  basic functions are:
  
       ox    NAD (network administration)
  
       ox    NOI (network operator interface)
  
       ox    ASF (administrative storage facility)
  
  The network  configuration of each system is  very important; all
  of  the configurations  of the  different systems  in the network
  must be coordinated.
  
  
  _T_H_E _D_S_A___D_S_A_C _D_A_E_M_O_N
  
       The  DSA_DSAC  daemon  is  both  unique  and  permanent.  It
  multiplexes   sessions  between   administrative  functions   and
  administrative correspondents (which are administrative functions
  on  other systems).   The  initial  environment for  the DSA_DSAC
  daemon  is described  in the  NIT.  (See  the description  of the
  Dsac_info  object definition in  Section 4.)  Ssu  requests drive
  the  DSA_DSAC  daemon's  activities.   Activities  performed over
  sessions depend  on the type  of the administrative  function and
  the type of the administrative correspondent.  The types of these
  two entities are defined in the NIT.
  
  
  
  
  
  
  
  
  
                                 6-1
  
  
  
  _L_o_g_g_i_n_g _I_n _a_n_d _I_n_i_t_i_a_l_i_z_i_n_g _t_h_e _D_S_A___D_S_A_C _D_a_e_m_o_n
  
       To login and initialize the DSA_DSAC daemon:
  
  1.   Include    the   run_dsac_daemon_init   command    and   the
       run_dsac_daemon command in the DSA_DSAC daemon's start_up.ec
       (>udd>Daemon>DSA_DSAC>start_up.ec).                      The
       run_dsac_daemon_init   and   run_dsac_daemon   commands  are
       described   later   in   this   section.    Note   that  the
       run_dsac_daemon command starts  up the run_dsac_daemon (rdd)
       subsystem.
  
  2.   Include  any run_dsac_daemon  command requests  you want  to
       issue (when  the rdd subsystem first starts  running) in the
       rdd                  subsystem's                 start_up.ec
       (>udd>Daemon>DSA_DSAC>start_up.rddec).    The   run_dsa_dsac
       command requests are described later in this section.
  
  3.   Type  the  following  command  line  or  include  it  in the
       system_start_up.ec:
  
            login DSA_DSAC Daemon <dsa_dsac_daemon_label>
  
  
  _L_o_g_g_i_n_g _O_u_t _t_h_e _D_S_A___D_S_A_C _D_a_e_m_o_n
  
       To logout the DSA_DSAC daemon, type:
  
       logout DSA_DSAC Daemon <dsa_dsac_daemon_label>
  
  For  detailed information on  logging system daemon  processes in
  and  out, refer  to the  _O_p_e_r_a_t_o_r'_s _G_u_i_d_e  _t_o _M_u_l_t_i_c_s  (Order No.
  GB61).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-2
  ____________________                         ____________________
  
  run_dsac_daemon_init                         run_dsac_daemon_init
  ____________________                         ____________________
  
  
  NAME: RUN_DSAC_DAEMON_INIT, RDD_INIT
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  rdd_init session_control_name {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  initializes  the  DSA_DSAC  daemon  tables  using the information
  supplied  by  the  Dsac_info  object  definition  in  the network
  information   table  (NIT).    The  segments   specified  by  the
  working_dd_seg,      working_af_seg,     working_ag_seg,      and
  working_ac_seg statements in the  Dsac_info object definition are
  created automatically when the DSA_DSAC  daemon is started up for
  the  first time,  in the  directory specified  by the working_dir
  statement.   You  are  responsible  for  creating  the  directory
  specified by  the working_dir statement, and should  do so before
  the DSA_DSAC daemon is started up  for the first time.  Note that
  you must give the DSA_DSAC daemon "sma" access to this directory.
  The segments specified by the  statements in the Dsac_info object
  definition   are    initialized   with   the    descriptions   of
  administrative    functions,     administrative    groups,    and
  administrative correspondents  provided in the NIT,  according to
  the   list   of   administrative   functions   specified  by  the
  admin_functions statement in the Dsac_info object definition.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is  the  local  name  of  the  session  control with which the
     DSA_DSAC daemon interfaces.  This name must be the same as the
     name specified by the sc_loc statement in the Dsac_info object
     definition in  the NIT.  It may  be up to 32  characters long.
     It must also be the  same as the session_control_name supplied
     to the run_dsac_daemon command.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -debug
     specifies that tracing should be enabled.
  
  -no_debug
     specifies that  tracing should not  be enabled.  (This  is the
     default.)
  
  
  
  
  
  
  
                                 6-3
  _______________                                   _______________
  
  run_dsac_daemon                                   run_dsac_daemon
  _______________                                   _______________
  
  
  NAME: RUN_DSAC_DAEMON, RDD
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  rdd session_control_name {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  enables the  DSA_DSAC daemon to start in  the appropriate context
  and  initializes   the  run_dsac_daemon  (rdd)   subsystem.   The
  DSA_DSAC  daemon tables for  session control must  be initialized
  before  the run_dsac_daemon  command and  its associated requests
  can be issued.  This  means that the run_dsac_daemon_init command
  must be  run just before  the run_dsac_daemon command  is run, in
  the same process.  The easiest way to ensure that this happens is
  to  include both  commands in  the DSA_DSAC  daemon's start_up.ec
  (>udd>Daemon>DSA_DSAC>start_up.ec).
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is  the  local  name  of  the  session  control with which the
     DSA_DSAC daemon interfaces.  This name must be the same as the
     name specified by the sc_loc statement in the Dsac_info object
     definition in  the NIT.  It may  be up to 32  characters long.
     It must also be the  same as the session_control_name supplied
     to the run_dsac_daemon_init command.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -abbrev
     indicates that abbreviation processing is allowed.
  
  -brief, -bf
     specifies   that  explanatory    information  should   not  be
     displayed.
  
  -ec_suffix ec_suffix
     specifies  the  suffix  to  be  used  for  the rdd subsystem's
     start_up.ec.  The default is "rddec".
  
  -info_dir info_path
     specifies  the  pathname  of  the  information directory.  The
     default is ">doc>subsystem".
  
  -long, -lg
     specifies  that explanatory   information should  be displayed
     when a  request is rejected  and when files  are transfered by
     the NASF administrative function.  (This is the default.)
  
  
                                 6-4
  _______________                                   _______________
  
  run_dsac_daemon                                   run_dsac_daemon
  _______________                                   _______________
  
  
  -no_abbrev
     indicates that abbreviation processing  is not allowed.  (This
     is the default.)
  
  -no_prompt
     specifies  that a  prompt should  not be  used.  (This  is the
     default.)
  
  -no_start_up
     specifies  that  a  rdd  subsystem  start_up.ec  should not be
     executed.
  
  -profile profile_path
     specifies the pathname of the  abbreviation profile file to be
     used  if  abbreviation  processing  is  enabled  (i.e., if the
     -abbrev control argument is specified).
  
  -prompt
     specifies that a prompt should be used.
  
  -start_up
     specifies that a rdd subsystem start_up.ec should be executed.
     (This is the default.)
  
  _L_I_S_T _O_F _R_E_Q_U_E_S_T_S
  
  Any of  the run_dsac_daemon command requests  described below can
  be     placed    in     the    rdd     subsystem's    start_up.ec
  (>udd>Daemon>DSA_DSAC>start_up.rddec).    The  requests   are  in
  alphabetical order.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-5
  _______________                                   _______________
  
  run_dsac_daemon                                   run_dsac_daemon
  _______________                                   _______________
  
  
  _k_i_l_l___d_r_i_v_e_r_, _k_i_l_l
  
  _S_Y_N_T_A_X
  
  kill
  
  _F_U_N_C_T_I_O_N
  
  terminates the DSA_DSAC daemon driver.  Prior to issuing the kill
  request, issue  the stop_admin_function request for  each ongoing
  administrative function.  Once the  kill request has been issued,
  it  is not  possible to   issue the  start_admin_function or  the
  stop_admin_function  requests.   The  only  request  which may be
  issued is quit.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-6
  _______________                                   _______________
  
  run_dsac_daemon                                   run_dsac_daemon
  _______________                                   _______________
  
  
  _q_u_i_t
  
  _S_Y_N_T_A_X
  
  quit
  
  _F_U_N_C_T_I_O_N
  
  terminates the rdd subsystem.  Prior to issuing the quit request,
  issue   the   stop_admin_function   request   for   each  ongoing
  administrative function, and then issue the kill_driver request.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-7
  _____________________                       _____________________
  
  start_admin_function,                       start_admin_function,
  _____________________                       _____________________
  
  
  NAME: START_ADMIN_FUNCTION,, START_AF
  
  _S_Y_N_T_A_X
  
  start_af admin_function_name
  
  _F_U_N_C_T_I_O_N
  
  allows the  specified administrative function to  accept incoming
  connections  from  its  administrative  correspondents.   Once  a
  session  is established,  the administrative  function itself  is
  performed by the DSA_DSAC daemon, above the session, according to
  the type of the administrative function (NAD, ASF, etc.).
  
  _A_R_G_U_M_E_N_T_S
  
  admin_function_name
     specifies the  name of an administrative  function.  This name
     must be defined by an  Admin_function object definition in the
     NIT,  and must  also be  one  of  the names  specified by  the
     admin_functions statement  in the Dsac_info  object definition
     in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-8
  ____________________                         ____________________
  
  stop_admin_function,                         stop_admin_function,
  ____________________                         ____________________
  
  
  NAME: STOP_ADMIN_FUNCTION,, STOP_AF
  
  _S_Y_N_T_A_X
  
  stop_af admin_function_name
  
  _F_U_N_C_T_I_O_N
  
  disconnects  the sessions   between the  specified administrative
  function   and   its   administrative   correspondents   (if  the
  administrative    function   was   previously    started).    The
  administrative   function  can   be  restarted   by  issuing  the
  start_admin_function request.
  
  _A_R_G_U_M_E_N_T_S
  
  admin_function_name
     specifies the  name of an administrative  function.  This name
     must be defined by an  Admin_function object definition in the
     NIT,  and must  also be  one  of  the names  specified by  the
     admin_functions statement  in the Dsac_info  object definition
     in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-9
  ____________________                         ____________________
  
  stop_admin_function,                         stop_admin_function,
  ____________________                         ____________________
  
  
  _t_r_a_c_e
  
  _S_Y_N_T_A_X
  
  trace control_arg
  
  _F_U_N_C_T_I_O_N
  
  turns the tracing feature on or off for the DSA_DSAC daemon.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -on {keywords}
     turns  the  tracing  feature  on  for  the specified keywords.
     Keywords may be chosen from the following:
  
     nit        - enables tracing of access to NIT objects
     requests   - enables tracing of requests issued
     session    - enables tracing of the session interface
     ccp_events - enables tracing of internal events
     objmgt     - enables tracing of object management
                  procedures
     CNP        - enables tracing of the CNP protocol in
                  the ASF function
     NAD        - enables tracing of specific features of
                  the NAD function
     lock       - enables tracing of every lock/unlock
                  invocation
     EVENT      - enables tracing of events external to the
                  process
     MIS        - enables tracing of miscellaneous problems
  
     If  no keywords  are specified,   tracing is  enabled for  all
     keywords.
  
  -off {keywords}
     turns  the tracing  feature  off  for the  specified keywords.
     Keywords  may be  chosen from  the list  above, under  the -on
     control  argument.  If no  keywords are specified,  tracing is
     disabled for all keywords.
  
  
  
  
  
  
  
  
  
  
  
                                 6-10
  
  
  _A_D_M_I_N_I_S_T_R_A_T_I_V_E _I_N_T_E_R_F_A_C_E _T_O _S_E_S_S_I_O_N _C_O_N_T_R_O_L
  
       The DSA administrative interface to session control provides
  two commands to administer session control:
  
       ox    dsa_scc  - for  administering Multics-specific  session
            control
  
       ox    dsa_dsac  - for  displaying session  control, CXI,  and
            DSAC objects on Multics
  
  Both of these commands are described in detail below.
  
  
  _M_u_l_t_i_c_s_-_S_p_e_c_i_f_i_c _S_e_s_s_i_o_n _C_o_n_t_r_o_l _A_d_m_i_n_i_s_t_r_a_t_i_o_n
  
       To  invoke the   subsystem responsible  for Multics-specific
  session  control   administration,  issue  the   dsa_scc  command
  (described below).  The dsa_scc command implements requests which
  allow you to:
  
       ox    initialize session control's main data base
  
       ox    start (or restart) session control
  
       ox    stop and terminate session control
  
       ox    create and delete mailboxes
  
       ox    abnormally  terminate or  stop listening  on a  logical
            connection
  
       ox    stop listening on an endpoint
  
       ox    set (or reset) traces at the session control level
  
       ox    set (or reset) traces on a specific logical connection
  
  The  requests  used  to  perform  each  of  these  functions  are
  described in  detail in the  dsa_scc command description  next in
  this  section.   Note  that  the  dsa_init  command (described in
  Section 2) initializes the handle table, starts the first session
  control  defined in  the NIT,   and creates  all of  that session
  control's mailboxes.
  
  
  
  
  
  
  
  
  
  
  
                                 6-11
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  NAME: DSA_SCC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dsa_scc request
  
  _F_U_N_C_T_I_O_N
  
  invokes  the  dsa_scc  subsystem,   which  provides  requests  to
  administer Multics-specific session control.
  
  _A_R_G_U_M_E_N_T_S
  
  request
     specifies the request to dsa_scc.  Request must be chosen from
     the following:
  
     initialize_handle_table (iht)
     mailbox_create (mbxc)
     mailbox_delete (mbxd)
     reset_lc_trace
     reset_sc_trace
     restart_session_control (rst_sc)
     set_lc_trace
     set_sc_trace
     start_session_control (start_sc)
     stop_listen (slis)
     stop_listen_endpoint (slis_ep)
     stop_session_control (stop_sc)
     terminate_abnormal (tabn)
     terminate_session_control (tmr_sc)
  
     In  addition, all  of the  standard subsystem  requests (help,
     list_requests,  etc) are  available.  These  are not described
     here.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-12
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _L_I_S_T _O_F _R_E_Q_U_E_S_T_S
  
  
  _i_n_i_t_i_a_l_i_z_e___h_a_n_d_l_e___t_a_b_l_e_, _i_h_t
  
  _S_Y_N_T_A_X
  
  iht
  
  _F_U_N_C_T_I_O_N
  
  initializes session control's main  data base (the handle table).
  You  should  issue  this  request  before  you  start any session
  control entity.  You  must issue this request after  you boot the
  system  and before  you start   the DSA  network.  Note  that any
  active sessions are discarded by this request.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-13
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _m_a_i_l_b_o_x___c_r_e_a_t_e_, _m_b_x_c
  
  _S_Y_N_T_A_X
  
  mbxc mailbox_name
  
  _F_U_N_C_T_I_O_N
  
  creates a  mailbox, puts the  mailbox in the  "active" state, and
  permits  the  initiation  or  acceptance  of  logical connections
  (sessions) on  the mailbox.  You  must start the  session control
  supporting  this   mailbox  (by  using   a  start_session_control
  request) before you issue the  mbxc request.  The session control
  must be in the "active" state.   An error code is returned if the
  mailbox  is already in  the "active" state  when this request  is
  issued.
  
  _A_R_G_U_M_E_N_T_S
  
  mailbox_name
     is the name of a local  mailbox.  This name must be defined by
     a Mailbox object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-14
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _m_a_i_l_b_o_x___d_e_l_e_t_e_, _m_b_x_d
  
  _S_Y_N_T_A_X
  
  mbxd mailbox_name
  
  _F_U_N_C_T_I_O_N
  
  deletes a mailbox.   This mailbox must be in  the "active" state.
  All logical connections (sessions) must be terminated before this
  request is  issued.  No initiation  or acceptance of  sessions is
  possible on this mailbox after the mbxd request is issued.
  
  _A_R_G_U_M_E_N_T_S
  
  mailbox_name
     is the name of a local  mailbox.  This name must be defined by
     a Mailbox object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-15
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _r_e_s_e_t___l_c___t_r_a_c_e
  
  _S_Y_N_T_A_X
  
  reset_lc_trace lc_name trace_type
  
  _F_U_N_C_T_I_O_N
  
  resets  trace flags on  a specific logical  connection (session).
  The different  kinds of traces  which may be  reset are explained
  below, under the set_lc_trace request.
  
  _A_R_G_U_M_E_N_T_S
  
  lc_name
     is the name of the  logical connection (session) for which the
     flag is to be reset.
  
  trace_type
     specifies the kind of trace  to be reset.  The possible traces
     are explained below, under the set_lc_trace request.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-16
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _r_e_s_e_t___s_c___t_r_a_c_e
  
  _S_Y_N_T_A_X
  
  reset_sc_trace session_control_name trace_type
  
  _F_U_N_C_T_I_O_N
  
  resets trace flags on a  session control.  The different kinds of
  traces  which  may  be  reset  are  explained  below,  under  the
  set_sc_trace request.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is the name of the session control for which the trace flag is
     to be reset.
  
  trace_type
     specifies the kind of trace  to be reset.  The possible traces
     are described below, under the set_sc_trace request.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-17
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _r_e_s_t_a_r_t___s_e_s_s_i_o_n___c_o_n_t_r_o_l_, _r_s_t___s_c
  
  _S_Y_N_T_A_X
  
  rst_sc session_control_name
  
  _F_U_N_C_T_I_O_N
  
  restarts  a local  session control  that has  been placed  in the
  "shutdown"  state  by   a  stop_session_control  request.   After
  issuing  rst_sc, the  creation of  mailboxes and  the creation of
  logical connections  (sessions) is allowed.  The  session control
  which is restarted  is put in the "active" state.   An error code
  is returned if the session control is not in the "shutdown" state
  when this request is issued.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is  the name of  a local session  control.  This name  must be
     defined by a Sc_loc object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-18
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _s_e_t___l_c___t_r_a_c_e
  
  _S_Y_N_T_A_X
  
  set_lc_trace lc_name trace_type
  
  _F_U_N_C_T_I_O_N
  
  sets trace flags on a specific logical connection (session).  The
  different kinds of traces which may be set are explained below.
  
  _A_R_G_U_M_E_N_T_S
  
  lc_name
     is the name of the  logical connection (session) for which the
     trace flag is to be set.
  
  trace_type
     specifies the kind  of trace to be set.   The following traces
     are possible:
  
     trace_handle_manager, thm
        trace all  the lock and  unlock operations for  the session
        control, mailboxes, and sessions.  This can be used to find
        out which process is still holding a lock.
  
     trace_input_letter, til
        trace  all  incoming  data   (letters)  received  from  the
        network.
  
     trace_output_letter, tol
        trace all outgoing data (letters).
  
     trace_sm, tsm
        trace  every  transition  (in  the  state  machine) for all
        sessions.   This can  be used  to discover  new transitions
        that might be possible.
  
     trace_transport_args, tta
        trace all  the arguments of  every call from  the transport
        layer (CXI) to session control.
  
     trace_user_args, tua
        trace all the parameters of a user call to session control.
  
  
  
  
  
  
  
                                 6-19
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
     Note  that these  traces go  into the  same log  file as  that
     specified   by    the   dsa_system_log   statement    in   the
     Mna_general_info object definition in  the NIT.  The amount of
     system quota needed  to store all of the  information is large
     and precautions  should be taken to ensure  adequate quota for
     the log file.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-20
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _s_e_t___s_c___t_r_a_c_e
  
  _S_Y_N_T_A_X
  
  set_sc_trace session_control_name trace_type
  
  _F_U_N_C_T_I_O_N
  
  sets trace  flags on a  session control.  The  different kinds of
  traces  which may  be set   are explained  below.  Note  that the
  setting  of a  flag at   session control  level implies  that all
  logical connections (sessions) on that session control will trace
  the  particular information  specified.  A  user can  prevent the
  trace   mechanism  on  a   particular  session  by   issuing  the
  reset_lc_trace (described above) request  for that session.  Note
  also that all sessions established before the traces are set will
  not trace  anything unless a  set_lc_trace request is  issued for
  each of them.  The initial values for traces are specified in the
  attributes  statement  of  the  session  control's  Sc_loc object
  definition in the NIT.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is the name of the session control for which the trace flag is
     to be set.
  
  trace_type
     specifies the kind  of trace to be set.   The following traces
     are possible:
  
     trace_handle_manager, thm
        trace all  the lock and  unlock operations for  the session
        control, mailboxes, and sessions.  This can be used to find
        out which process is still holding a lock.
  
     trace_input_letter, til
        trace  all  incoming  data   (letters)  received  from  the
        network.
  
     trace_output_letter, tol
        trace all outgoing data (letters).
  
     trace_sm, tsm
        trace  every  transition  (in  the  state  machine) for all
        sessions.   This can  be used  to discover  new transitions
        that might be possible.
  
  
  
  
                                 6-21
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
     trace_transport_args, tta
        trace all  the arguments of  every call from  the transport
        layer (CXI) to session control.
  
     trace_user_args, tua
        trace all the parameters of a user call to session control.
  
     Note  that these  traces go  into the  same log  file as  that
     specified   by    the   dsa_system_log   statement    in   the
     Mna_general_info object definition in  the NIT.  The amount of
     system quota needed  to store all of the  information is large
     and precautions  should be taken to ensure  adequate quota for
     the log file.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-22
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _s_t_a_r_t___s_e_s_s_i_o_n___c_o_n_t_r_o_l_, _s_t_a_r_t___s_c
  
  _S_Y_N_T_A_X
  
  start_sc session_control_name
  
  _F_U_N_C_T_I_O_N
  
  starts a local session control  and hence permits the creation of
  mailboxes  and the  creation of  logical connections  (sessions).
  The  session control  which is   started is  put in  the "active"
  state.  An error  code is returned if the session  control is not
  in the "terminated" state when this request is issued.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is  the name of  a local session  control.  This name  must be
     defined by a Sc_loc object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-23
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _s_t_o_p___l_i_s_t_e_n_, _s_l_i_s
  
  _S_Y_N_T_A_X
  
  slis lc_name
  
  _F_U_N_C_T_I_O_N
  
  abnormally terminates a pending listen.   The owner gets a wakeup
  and has no further access to the specified "pseudo" session.
  
  _A_R_G_U_M_E_N_T_S
  
  lc_name
     is  the name of  the logical connection  (session) on which  a
     stop_listen is  to to be  performed.  This name  must have the
     following syntax:
  
        dsa.<scid_name>.NNNN
  
     where scid_name  is the four  character DSA name  of the local
     session control supporting this logical connection and NNNN is
     a number composed of four decimal  digits which is an index of
     logical connections  within the session control.   To obtain a
     list of  the logical connections active on  a session control,
     use  the dsa_dsac  get_list command,  described later  in this
     section.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-24
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _s_t_o_p___l_i_s_t_e_n___e_n_d_p_o_i_n_t_, _s_l_i_s___e_p
  
  _S_Y_N_T_A_X
  
  slis_ep mailbox_name
  
  _F_U_N_C_T_I_O_N
  
  places all listen orders that are pending on a particular mailbox
  in  the "terminate"  state.  The  owners of  each pending  listen
  receive a TERM_ABNORMAL_INT interrupt.  They can either terminate
  abnormally or get information for their sessions.  In both cases,
  the session is destroyed.  This request can be used to signal the
  login server that it must stop listening on a particular mailbox.
  
  _A_R_G_U_M_E_N_T_S
  
  mailbox_name
     is the name of a local  mailbox.  This name must be defined by
     a Mailbox object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-25
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _s_t_o_p___s_e_s_s_i_o_n___c_o_n_t_r_o_l_, _s_t_o_p___s_c
  
  _S_Y_N_T_A_X
  
  stop_sc session_control_name
  
  _F_U_N_C_T_I_O_N
  
  shuts down  a local session  control.  Once a  session control is
  shut  down,  mailboxes  cannot  be  created,  sessions  cannot be
  initiated,  and incoming  sessions cannot  be accepted.  However,
  active  sessions can  still exchange  data.  The  session control
  which is  shut down is put  in the "terminated" state.   An error
  code is  returned if the session  control is not in  the "active"
  state when this request is issued.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is  the name of  a local session  control.  This name  must be
     defined by a Sc_loc object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-26
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _t_e_r_m_i_n_a_t_e___a_b_n_o_r_m_a_l_, _t_a_b_n
  
  _S_Y_N_T_A_X
  
  tabn lc_name
  
  _F_U_N_C_T_I_O_N
  
  terminates  a logical  connection (session)  and sends  a special
  interrupt to  both the owner and  the user of this  session.  The
  user's process  then lacks any permission to  access the session.
  The  owner  (usually  the   login  server)  may  then  abnormally
  terminate  the session  directly or  call session  control to get
  information about  the kind of  special interrupt that  was sent.
  In both cases, the logical connection (session) is destroyed.  If
  the same logical connection is abnormally terminated twice, it is
  also destroyed.   The owner gets  a special interrupt  but has no
  further access  to the session.  Terminating  the same connection
  twice  can be used  when the owner  processes are not  viable and
  when the session control data base needs cleaning.
  
  _A_R_G_U_M_E_N_T_S
  
  lc_name
     is  the  name  of  the  logical  connection  (session)  to  be
     abnormally  terminated.   This  name  must  have the following
     syntax:
  
        dsa.<scid_name>.NNNN
  
     where scid_name  is the four  character DSA name  of the local
     session control supporting this logical connection and NNNN is
     a number composed of four decimal  digits which is an index of
     logical connections  within the session control.   To obtain a
     list of  the logical connections active on  a session control,
     use  the dsa_dsac  get_list command,  described later  in this
     section.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-27
  _______                                                   _______
  
  dsa_scc                                                   dsa_scc
  _______                                                   _______
  
  
  _t_e_r_m_i_n_a_t_e___s_e_s_s_i_o_n___c_o_n_t_r_o_l_, _t_m_r___s_c
  
  _S_Y_N_T_A_X
  
  tmr_sc session_control_name
  
  _F_U_N_C_T_I_O_N
  
  terminates a local session  control.  All sessions initiated from
  (or accepted  on) this session control must  be terminated before
  the  tmr_sc  request  is  issued.   All  data  pertaining to this
  session  control  in  the  handle_manager  table  is erased.  The
  session control is put in  the "terminated" state.  An error code
  is returned if the session control is not in the "shutdown" state
  when this request is issued.
  
  _A_R_G_U_M_E_N_T_S
  
  session_control_name
     is  the name of  a local session  control.  This name  must be
     defined by a Sc_loc object definition in the NIT.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-28
  
  
  _D_i_s_p_l_a_y _o_f _D_S_A _O_b_j_e_c_t_s _o_n _M_u_l_t_i_c_s
  
       The  dsa_dsac interface  to session  control, CXI,  and DSAC
  lets you retrieve information about  various DSA objects in these
  three layers.  To invoke  the subsystem responsible for providing
  this  interface, issue  the dsa_dsac  command (described  below).
  The dsa_dsac command implements requests which allow you to:
  
       ox    find out how many DSA objects of a given class exist on
            the local system
  
       ox    find out  which DSA objects  of a given  class exist on
            the local system
  
       ox    find out the attributes of DSA objects of a given class
            which exist on the local system
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-29
  ________                                                 ________
  
  dsa_dsac                                                 dsa_dsac
  ________                                                 ________
  
  
  NAME: DSA_DSAC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dsa_dsac        request         object_class        {object_name}
     {object_specification}
  
  _F_U_N_C_T_I_O_N
  
  invokes  the  dsa_dsac  subsystem,  which  provides  requests  to
  retrieve  information about  various DSA  objects in  the session
  control, CXI, and DSAC layers.
  
  _A_R_G_U_M_E_N_T_S
  
  request
     specifies  the request  to dsa_dsac.   Request must  be chosen
     from the following:
  
     get_number, gn
        displays how many DSA objects of a given class exist on the
        local system.
  
     get_list, gl
        displays a list  of the DSA objects of a  given class which
        exist on the local system.
  
     get_attributes, ga
        displays the attributes of the DSA objects of a given class
        which exists on the local system.
  
     In  addition, all  of the  standard subsystem  requests (help,
     list_requests,  etc) are  available.  These  are not described
     here.
  
     Note  that the  dsa_dsac command  may be  called as  an active
     function for the get_number  and get_list requests.  Note also
     that  the  dsa_dsac  command  is  independent  of the DSA_DSAC
     daemon, despite the fact that the names are the same.
  
  object_class
     is  the type  of DSA  object for  which you  want information.
     Object_class must be one of the following:
  
     session_control         (sc) (SC)
     mailbox                 (mb) (MB)
     logical_connection      (lc) (LC)
     session                 (ss) (SS)
     session_route           (sr) (SR)
  
  
                                 6-30
  ________                                                 ________
  
  dsa_dsac                                                 dsa_dsac
  ________                                                 ________
  
  
     admin_function          (af) (AF)
     admin_group             (ag) (AG)
     admin_correspondent     (ac) (AC)
     channel_connection      (cc) (CC)
     channel                 (ch) (CH)
     connection              (ct) (CT)
     frontend                (fe) (FE)
  
     Note that channel_connection and  channel both correspond to a
     CXI  connection,  and  that  connection  corresponds  to a DIA
     connection.
  
  object_name
     is the  name of a single  object for which the  query is to be
     done.   The  object_name  argument  must  be  specified if the
     request  argument is  set to   get_attributes; it  may not  be
     specified if the request argument  is set to either get_number
     or get_list.
  
  object_specification
     is a  list of arguments which  are used to select  a subset of
     the  objects of  a given  class for  which you  are requesting
     information.  An  object is selected  if it satisfies  all the
     mapping  criteria  specified   by  object_specification.   See
     "Notes" for more information.
  
     The format of object_specification is:
  
        {-os state} {-om mapping1} {-om mapping2}
            {-user user_name} {-transport tranport_name}
  
  
     state
        is the state an object must  be in in order to be selected.
        State may be chosen from the following list:
  
        disable      (ds) (DS)
        down         (do) (DO)
        enable       (en) (EN)
        locked       (lk) (LK)
        no_state     (ns) (NS)
        reserved     (rs) (RS)
        shutdown     (sd) (SD)
        test         (te) (TE)
        used         (us) (US)
  
  
  
  
  
  
                                 6-31
  ________                                                 ________
  
  dsa_dsac                                                 dsa_dsac
  ________                                                 ________
  
  
     mapping1
        is a mapping which has the following syntax:
  
           <object_class>:<object_name>
  
        where object_class must be chosen from the list given above
        under the object_class argument and object_name is the name
        of an object of this type.   To be selected, an object must
        satisfy this  mapping.  For example,  if a user  issues the
        command:
  
           dsa_dsac gl mb -om sc:MUL1
  
        the dsa_dsac  command will return  a list of  the mailboxes
        which are defined under the session control named MUL1.
  
     mapping2
        is a second  mapping with the same syntax  as mapping1.  If
        two  mappings  are  given,  an  object  must  satisfy  both
        mappings simultaneously in order to be selected.
  
     user_name
        is the  name of the user  to whom the object  must pertain.
        This  argument  can  be  used  to  list logical connections
        (sessions) which belong to a particular user.  For example,
        since  the dsa_dsac  get_list command   may be  used as  an
        active function, the following command line may be issued:
  
           dsa_scc tabn ([dsa_dsac gl ss -om sc:MUL1 -user_name
              Jones])
  
        This command line will purge every session belonging to the
        user whose Person_id is Jones.
  
     transport_name
        is the name  of the transport layer to which  the object is
        attached.  This  argument can be  used to list  the logical
        connections going through a specific frontend.
  
     Note  that  the  two  previous  control  arguments  (-user and
     -transport) are  not part of  the standard DSAC  syntax.  They
     are improvements to the Multics  command interface and are not
     accessible  from  other  DSA  sites.   Therefore,  they do not
     adhere to DSAC standards.
  
  
  
  
  
  
  
                                 6-32
  ________                                                 ________
  
  dsa_dsac                                                 dsa_dsac
  ________                                                 ________
  
  
  _N_O_T_E_S _O_N _O_B_J_E_C_T _S_P_E_C_I_F_I_C_A_T_I_O_N_S
  
  What   follows   are   descriptions   of   the   formats  of  the
  object_specification argument which may be given for each type of
  object.
  
  
  SC object
     no specification may be given for SC objects.
  
  MB object
     the specification for MB objects is:
  
        -om sc:<scid_name>
  
     where scid_name is the four  character DSA name of the session
     control to which this mailbox pertains.
  
  LC object
     the specifications for LC objects are:
  
        -om sc:<scid_name>
  
     where scid_name is the four  character DSA name of the session
     control  on   which  this  logical  connection   (session)  is
     initiated or accepted.
  
        -om mb:<mbx_dsa_name>
  
     where  mbx_dsa_name is  the eight  character DSA  name of  the
     mailbox  on   which  this  logical  connection   (session)  is
     initiated or accepted.
  
        -user <user_name>
  
     where user_name is  the Person_id of the user  of this logical
     connection (session).
  
        -transport <dsa_transport_name>
  
     where dsa_transport_name is the  name of the transport station
     on  which  this  connection  is  established.   This transport
     station must be defined by a  Ts object definition in the NIT.
     This argument can be used  to list all the logical connections
     (sessions) on a particular frontend.
  
  SS object
     the  specifications  for  SS  objects  are  the  same as those
     described above for LC objects.
  
  
                                 6-33
  ________                                                 ________
  
  dsa_dsac                                                 dsa_dsac
  ________                                                 ________
  
  
  
  SR object
     the specification for SR objects is:
  
        -om sc:<scid_name>
  
     where scid_name is the four  character DSA name of the session
     control which is one end of the route.
  
  AF object
     no specification may be given for AF objects.
  
  AG object
     the specification for AG objects is:
  
        -om af:<admin_function_name>
  
     where  admin_function_name is  the name  of the administrative
     function to  which an administrative group must  be related to
     be part of the returned list.
  
  AC object
     the specifications for AC objects are:
  
        -om af:<admin_function_name>
  
     where  admin_function_name is  the name  of the administrative
     function  to  which  an  administrative  correspondent must be
     related to be part of the returned list.
  
        -om ag:<admin_group_name>
  
     where admin_group_name is the name of the administrative group
     to which an administrative correspondent must be related to be
     part of the returned list.
  
        -om sy:<system_name>
  
     where  system_name is  the name   of the  system on  which the
     administrative correspondents must be defined.
  
  CC object
     the specifications for CC objects are:
  
        -om cc:<cxi_id>
  
     where cxi_id is the CXI ID.
  
        -om ct:<dia_name>
  
  
                                 6-34
  ________                                                 ________
  
  dsa_dsac                                                 dsa_dsac
  ________                                                 ________
  
  
  
     where  dia_name  is  the  name  of  the  DIA  connected to the
     frontend in question.   This name must be the same  as the one
     specified  by  the  dia   statement  in  the  Frontend  object
     definition in the NIT.
  
        -om fe:<frontend_name>
  
     where frontend_name  is the name of the  frontend in question.
     This frontend must be defined  by a Frontend object definition
     in the NIT.
  
  CH object
     the  specifications  for  CH  objects  are  the  same  as  the
     specifications described above for CC objects.
  
  CT object
     the specifications for CT objects are:
  
        -om ct:<dia_name>
  
     where  dia_name  is  the  name  of  the  DIA  connected to the
     frontend in question.   This name must be the same  as the one
     specified  by  the  dia   statement  in  the  Frontend  object
     definition in the NIT.
  
        -om fe:<frontend_name>
  
     where frontend_name  is the name of the  frontend in question.
     This frontend must be defined  by a Frontend object definition
     in the NIT.
  
  FE object
     the specification for FE objects is:
  
        -om fe:<frontend_name>
  
     where  frontend_name  is  the  name  of  the  frontend.   This
     frontend must  be defined by  a Frontend object  definition in
     the NIT.
  
  _N_O_T_E_S
  
  A subset of the objects of a given class may be selected by using
  dsa_dsac get_list  as an active function.   The following example
  illustrates this fact:
  
     dsa_dsac ga mb ([dsa_dsac gl mb -om sc:MUL1])
  
  
  
                                 6-35
  
  
  This  command line  allows the  user to  get the  attributes of a
  selected  list  of  mailboxes  without  directly  specifying  the
  selection criteria in the get_attributes request itself.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-36
  
  
  _T_H_E _D_S_S_R _S_U_B_S_Y_S_T_E_M
  
       The dssr subsystem runs in a normal user process.  It allows
  you to perform two main functions:
  
       ox    run the basic network session exerciser (BNSE)
  
       ox    run the remote NOI/NAD access facility
  
  
       The dssr subsystem runs BNSE by responding to requests aimed
  at  the $NSE  (acceptor)  and  $NSF (initiator)  mailboxes.  BNSE
  allows  you to  initiate a  session to  or accept  a session from
  another node in  order to test the connection.  It  allows you to
  establish  a session, send  data, get the  data echoed back,  and
  terminate the session.
  
  
       The  dssr  subsystem  runs  the  remote  NOI/NAD facility by
  responding  to  requests  aimed  at  the  $TMDIALOU  and  $NOIAEP
  mailboxes.  The remote NOI facility allows you to dialout through
  session control to a DNS NOI, so  you look the same to the DNS as
  an operator's  terminal.  For an administrator,  using the remote
  NOI  facility  is  the  same  as  connecting  through  a terminal
  directly to the DN8/7100.
  
  
       The  remote NAD  access facility  allows Multics  and DNS to
  communicate.  It  accepts requests and Multics  commands in ASCII
  format, translates them into AEP format, and sends them on to the
  NAD  in the  DNS.  For   an administrator,  using the  remote NAD
  access facility is the same as  using the DNS NOI, except that it
  provides the advantages of being  able to connect to any DN8/7100
  and to have Multics file output.
  
  
       Both  BNSE  and  the  remote  NOI/NAD  access  facility  are
  described  below.   To  invoke  the  dssr  subsystem,  issue  the
  dsa_ssu_root (dssr) command, described later in this section.
  
  
  _T_h_e _B_a_s_i_c _N_e_t_w_o_r_k _S_e_s_s_i_o_n _E_x_e_r_c_i_s_e_r
  
       The basic network session exerciser (BNSE) can be used to:
  
       ox    verify the session control user interface level between
            two systems
  
       ox    load the network and verify its performance
  
       ox    test the  accuracy of the session  control by comparing
            the data sent and the data received
  
  
  
                                 6-37
  
  
  BSNE  establishes   a  connection  between  two   mailboxes,  the
  initiator  mailbox  and  the  acceptor  mailbox.   The  initiator
  mailbox  is named $NSF  and the acceptor  mailbox is named  $NSE.
  These  two   mailboxes  should  be  defined   by  Mailbox  object
  definitions in the NIT as follows:
  
       dsa.<session_control_name>.$NSF
       dsa.<session_control_name>.$NSE
  
  where  session_control_name  is  the  name  of  the local session
  control.   Defining these  mailboxes in   the NIT  allows you  to
  accept  any  connection  from  a  remote  exerciser  on  the $NSE
  mailbox.  To initiate a connection  to a remote exerciser, define
  the remote correspondent represented by the $NSE acceptor mailbox
  with a Correspondent object definition in the NIT.
  
  
       BNSE  on Multics  runs under  the dssr  subsystem.  When you
  invoke BNSE with the dsa_ssu_root (dssr) command, you can specify
  one of two possible activities:
  
       ox    exerciser  initiator  -  when   BNSE  is  running  this
            activity,  it  may  only  initiate  sessions  to remote
            BNSEs, the local mailbox being  $NSF and the remote one
            $NSE.
  
       ox    exerciser echoer - when  BNSE is running this activity,
            it  may only  accept  sessions  from remote  BNSEs, the
            local mailbox  being $NSE and the remote  one $NSF.  If
            this activity  is selected, all data  received from the
            remote site is echoed back.
  
  
  _R_e_m_o_t_e _N_O_I_/_N_A_D _A_c_c_e_s_s _F_a_c_i_l_i_t_y
  
       The remote NOI/NAD access facility  lets you access a remote
  NOI or  a remote NAD  to obtain information.   The remote NOI/NAD
  access facilities have the following common features:
  
       ox    Tasking - lets you send requests to several remote NOIs
            or remote NADs simultaneously.
  
       ox    Multisession processing - allows several sessions to be
            active simultaneously  and lets you specify  a "current
            session"  with either  the session_name  dssr subsystem
            request  or the  -session_name control  argument to the
            connect   dssr   subsystem   request.    The   connect,
            disconnect,  and session_name  requests all  change the
            name of the current session.  You may print the name of
            the current session by using the "."  request.  You may
            print a list of all of the active sessions by using the
            get_info gsl request.
  
  
  
                                 6-38
  
  
       ox    Logging and printing  - lets you store data  in the log
            and print it on the terminal.  When you access a remote
            NOI,  all of  the information  coming from  the NOI  is
            logged  and also  printed  on  the terminal.   When you
            access  a remote  NAD, responses  to your  requests are
            logged  and   also  printed  on  the   terminal;  other
            information  is  logged,  but  is  not  printed  on the
            terminal.
  
  
       Remote   NOI   access   and   remote   NAD  access  perform,
  essentially, identical functions.  When  using remote NOI access,
  you must issue the turn dssr  subsystem request and then wait for
  the "-->" prompt  before you can send an NOI  request; when using
  remote NAD access, the turn subsystem request is not required.
  
  
       The following is  an explanation of the behavior  of the two
  facilities.  The remote  NOI access facility uses TM  to send the
  request as typed by the user and directly prints (logs) character
  strings received from  the remote NOI.  All of  the requests sent
  to the remote NOI are logged.  The remote mailbox is $NOI.
  
  
       The remote NAD access facility  parses the user request.  If
  it's valid, the facility builds an AEP record and sends it to the
  remote NAD.  It  then receives AEPs.  If the  AEPs are responses,
  it analyzes  them and prints  the result on  the terminal.  These
  AEPs are logged and the  character string printed on the terminal
  is also logged.  An AEP which  is not a response is still logged,
  but it  is not printed.  All  of the requests sent  to the remote
  NAD are logged.  The remote mailbox is $NAD.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-39
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  NAME: DSA_SSU_ROOT, DSSR
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  dssr activity {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  invokes the  dssr subsystem, which  provides requests to  run the
  basic  network session  exerciser and  to run  the remote NOI/NAD
  facility.  To use the dssr  subsystem, you must define a terminal
  type  in the TTF  with the characteristic  "stc_available:  no;".
  Also,  the  terminal  type  name   may  not  be  longer  than  12
  characters.
  
  Unless you invoke the dssr  subsystem with the -no_prompt control
  argument, it prompts you with:
  
     dssr:
  
  All of the standard subsystem requests (help, list_requests, etc)
  are  available in  the dssr  subsystem.  They  are not  described
  here.
  
  _A_R_G_U_M_E_N_T_S
  
  activity
     is the activity to run under  the subsystem.  For BNSE it must
     be either "exe_init" or "exe_echo".  For the remote NOI access
     facility, it  must be either  "noi_access" or "noi".   For the
     remote NAD access facility, it  must be either "nad_access" or
     "noi_aep".
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -abbrev, -ab
     permits the use of abbreviations  while typing requests to the
     subsystem.   By default,  the abbreviations  are read  from or
     written  to  the  Person_id.profile  segment  under  the  home
     directory.   The pathname  of this  segment can  be changed by
     using the -profile control argument described below.
  
  -info_dir info_dir, -id info_dir
     specifies the pathname of the directory in which info segs are
     located.   These info  segs are   used by  the help  subsystem
     requests.  The default is ">doc>ss>dssr".
  
  -log
     specifies  that logging  is to  be performed  on each activity
  
  
                                 6-40
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
     while running the dssr subsystem.  If no pathname is given for
     the log (i.e., if the -log_pathname control argument described
     below is not specified), then logging  is done by default in a
     log created in the home directory.  The default log name is:
  
     EXE_INIT    for exerciser initiator activity
     EXE_ECHO    for exerciser echoer activity
     NOI         for remote NOI activity
     NOI_AEP     for remote NAD activity
  
     Only  some  of  the  information  logged  is  printed  on  the
     terminal.  This is the default.
  
  -log_pathname log_pathname, -lp log_pathname
     specifies that logging should be done in the log whose name is
     given by log_pathname.
  
  -name ssu_working_seg
     specifies that  the subsystem should  use as its  database the
     segment whose name is  given by ssu_working_seg.  This segment
     contains  various structures needed  to run the  subsystem and
     the  tasking facility.   For exerciser  initiator or exerciser
     echoer  activities, this segment  is created in  the directory
     which is  specified by the sc_exerciser_wdir  statement in the
     Mna_general_info  object definition  in the  NIT.  The default
     segment name is:
  
     exe_init     for exerciser initiator activity
     exe_echo     for exerciser echoer activity
     noi          for remote NOI activity
     noi_aep      for remote NAD activity
  
  
  -no_abbrev, -nab
     does  not  permit  the  use  of  abbreviations.   This  is the
     default.
  
  -no_log
     specifies  that no  logging is   to be  performed by  the dssr
     environment.
  
  -no_prompt, -npmt
     specifies that  the dssr environment  should not prompt  for a
     new request.
  
  -no_start_up, -nsu
     specifies that a start_up.ec does not have to be executed when
     the dssr subsystem is starting.  This is the default.
  
  
  
                                 6-41
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  -no_tasking, -nt
     prevents the subsystem from  using the tasking facility.  This
     control argument may be necessary for debugging purposes.
  
  -profile profile_seg, -pf profile_seg
     specifies that  abbreviations should be read  from and written
     to  the profile  segment whose  name is  given by profile_seg.
     This control argument implies -abbrev.
  
  -start_up, -su
     specifies that a start_up.ec has  to be executed when the dssr
     subystem is starting.  If  this control argument is specified,
     a segment named "start_up.dssrec" (or a link to it) must exist
     in the home directory.
  
  -tasking
     allows the subsystem to use the tasking facility, which allows
     you  to accept several  sessions simultaneously.  This  is the
     default.  See "Notes" for important restrictions on the use of
     this facility.
  
  _N_O_T_E_S
  
  When using the  tasking facility, you must not be  in video mode,
  and must set your page length to zero (type "stty -modes ^pl").
  
  To  stop the dssr  subsystem, hit the  BRK key.  The  system will
  respond with the following prompt:
  
     logout or start??
  
  If  you answer  logout, the   dssr subsystem  will terminate  all
  active sessions and  return you to request level.   If you answer
  start, the dssr subsystem will simply resume normal processing.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-42
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _L_I_S_T _O_F _B_N_S_E _E_X_E_R_C_I_S_E_R _I_N_I_T_I_A_T_O_R _A_C_T_I_V_I_T_Y _R_E_Q_U_E_S_T_S
  
  The following requests can be issued  if you invoke BNSE with the
  exerciser  initiator  activity  (i.e.,  if  you  set the activity
  argument to "exe_init").
  
  
  _s_e_l_f___i_d_e_n_t_i_f_y
  
  _S_Y_N_T_A_X
  
  .
  
  _F_U_N_C_T_I_O_N
  
  prints the name of the current session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-43
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _c_o_n_n_e_c_t_, _c_n
  
  _S_Y_N_T_A_X
  
  cn correspondent_name {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  establishes a session  to the remote BNSE whose name  is given by
  correspondent_name.
  
  _A_R_G_U_M_E_N_T_S
  
  correspondent_name
     is   the   name   of   the   remote   BNSE  correspondent  (or
     administrative  correspondent) to  which  a  session is  to be
     established.  The correspondent doesn't  have to be defined in
     the  NIT.   If  it  isn't,  correspondent_name  must  have the
     following syntax:
  
        dsa.<system_name>.$NSE
  
     where system_name is the name  of the remote system supporting
     the correspondent.   This system must  be defined by  a System
     object definition in the NIT.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -bill billing_id
     specifies the  billing ID under  which the remote  system will
     charge  the  user  for  the  session  which  is  going  to  be
     established.
  
  -password password, -pw password
     specifies  the password  which will   be put  in the  initiate
     letter.   Although  this  control  argument  is  optional, you
     should note  that the session  establishment will fail  if the
     remote correspondent requires a  password and you either don't
     provide one or provide one that is bad.  If you do not specify
     this control argument, the dssr  subsystem will prompt you for
     a password.  When you type the password, it will be masked.
  
  -person_id Person_id, -prsid Person_id
     specifies the Person_id of the user on the remote system.
  
  -session_name session_name, -sn session_name
     gives the specified name to  the session which is established.
     If this control  argument is not specified, the  name given to
     the session which  is established defaults to the  name of the
  
  
                                 6-44
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
     remote system (e.g., DA10).  In either case, the session which
     is  established  becomes  the   current  session  for  sending
     requests.  After switching to  another session, it is possible
     to return  to this session by typing  the session_name request
     (described  below) and  specifying the  session_name that  was
     given to this  session at connect time (i.e., the  name of the
     remote  system  or  the  name  specified  by the -session_name
     control argument to the connect request).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-45
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _d_i_s_c_o_n_n_e_c_t_, _d_i_s
  
  _S_Y_N_T_A_X
  
  dis
  
  _F_U_N_C_T_I_O_N
  
  disconnects the current session.   After you issue the disconnect
  request,  you  may  not  send  any  other  requests to the remote
  correspondent to  which this session was  established.  The first
  session  in the  list of   current sessions  becomes the  current
  session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-46
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___i_n_f_o_, _g_i
  
  _S_Y_N_T_A_X
  
  gi argument
  
  _F_U_N_C_T_I_O_N
  
  prints  information about  either all  of the  active sessions or
  about one specific session.
  
  _A_R_G_U_M_E_N_T_S
  
  gsl
     prints  a  list  of  all  of  the  active  sessions.  For each
     session,  prints  the  name  of  the  session,  the SGN of the
     session, the state of the session (initiator or acceptor), the
     number of records received, the number of errors detected, and
     the number of bytes received.
  
  gsa session_name
     prints  the attributes  of  the  specified session.   The name
     specified  by session_name  must be   the name  given to  this
     session  at connection  time (i.e.,   the name  of the  remote
     system  or the  name  specified  by the  -session_name control
     argument to the connect request).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-47
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _r_u_n___t_e_s_t_, _r_t
  
  _S_Y_N_T_A_X
  
  
  rt test_name {-control_arg}
  
  _F_U_N_C_T_I_O_N
  
  performs a specific  test on the current session.   If no session
  is presently opened,  an error code is printed.  To  stop a test,
  hit the BRK key.  This will return you to dssr request level.
  
  _A_R_G_U_M_E_N_T_S
  
  test_name
     is the  name of the test  to be performed.  Test_name  must be
     chosen from the following:
  
     basic
        runs the basic  test.  The basic test sends  a 50 character
        string  and  waits  for  the  remote  system  to return it.
        Checking  is  done  to  determine  if  the  string which is
        received is the same as the string which is sent.
  
     long_records
        sends  a  long  session   control  record,  waits  for  its
        reception, and checks its validity.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -iteration N, -it N
     specifies how  many times the  test should be  performed.  The
     default for N is 50.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-48
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _s_e_s_s_i_o_n___n_a_m_e_, _s_n
  
  _S_Y_N_T_A_X
  
  sn session_name
  
  _F_U_N_C_T_I_O_N
  
  causes  the  specified  session  to  become  the current session.
  Subsequent requests  typed by the Administrator are  sent on this
  session.
  
  _A_R_G_U_M_E_N_T_S
  
  session_name
     is  the name  of the   session which  will become  the current
     session.  The name specified by  session_name must be the name
     given to  this session at  connection time (i.e.,  the name of
     the remote  system or the name specified  by the -session_name
     control argument to  the connect request).  For a  list of the
     names  of all  of the  active sessions,  use the  get_info gsl
     request, described above.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-49
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _L_I_S_T _O_F _B_N_S_E _E_X_E_R_C_I_S_E_R _E_C_H_O_E_R _A_C_T_I_V_I_T_Y _R_E_Q_U_E_S_T_S
  
  The following requests can be issued  if you invoke BNSE with the
  exerciser echoer activity (i.e., if you set the activity argument
  to "exe_echo").
  
  
  _s_e_l_f___i_d_e_n_t_i_f_y
  
  _S_Y_N_T_A_X
  
  .
  
  _F_U_N_C_T_I_O_N
  
  prints the name of the current session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-50
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___i_n_f_o_, _g_i
  
  _S_Y_N_T_A_X
  
  gi argument
  
  _F_U_N_C_T_I_O_N
  
  prints  information about  either all  of the  active sessions or
  about one specific session.
  
  _A_R_G_U_M_E_N_T_S
  
  gsl
     prints  a  list  of  all  of  the  active  sessions.  For each
     session,  prints  the  name  of  the  session,  the SGN of the
     session, the state of the session (initiator or acceptor), the
     number of records received, the number of errors detected, and
     the number of bytes received.
  
  gsa session_name
     prints  the attributes  of  the  specified session.   The name
     specified  by session_name  must be   the name  given to  this
     session  at connection  time (i.e.,   the name  of the  remote
     system).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-51
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _s_t_a_r_t___l_i_s_t_e_n_, _l_i_s_t_e_n
  
  _S_Y_N_T_A_X
  
  listen mailbox_name
  
  _F_U_N_C_T_I_O_N
  
  listens for  and accepts incoming connections  from remote BNSEs.
  After a connection is accepted, the dssr subsystem runs an echoer
  function  on the  session.  From  time to  time, it  displays the
  attributes of the different sessions which have been accepted.
  
  _A_R_G_U_M_E_N_T_S
  
  mailbox_name
     is the name  of the local mailbox on which  the dssr subsystem
     will listen for and accept incoming connections.  This mailbox
     must  be defined by  a Mailbox object  definition in the  NIT.
     Your process must have "r" access to this mailbox.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-52
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _s_t_o_p___l_i_s_t_e_n_, _s_t_o_p
  
  _S_Y_N_T_A_X
  
  stop
  
  _F_U_N_C_T_I_O_N
  
  stops listening  on the current mailbox.  Sessions  active at the
  time the request  is issued remain active.  However,  there is no
  further  acceptance of  incoming connections.   To terminate  all
  sessions, hit the BRK key.   The system will respond with "logout
  or start??".  Type "logout".
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-53
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _L_I_S_T _O_F _R_E_M_O_T_E _N_O_I _A_C_C_E_S_S _R_E_Q_U_E_S_T_S
  
  There are two kinds of requests which can be issued if you invoke
  the remote  NOI/NAD access facility with the  NOI activity (i.e.,
  if you set the activity argument to "noi_access" or "noi").  They
  are:
  
       ox    NOI access-specific requests
  
       ox    NOI requests
  
  The  NOI access-specific requests  are described below.   The NOI
  requests (get_attributes,  get_list, etc.)  are described  in the
  _D_N_S  _S_y_s_t_e_m _O_p_e_r_a_t_i_o_n_s  manual, Order  No.  DP42  and in  the _D_N_S
  _S_y_s_t_e_m _O_p_e_r_a_t_i_o_n_s manual, Reference No.   39 A2 9799.  To send an
  NOI request, you  must "ask for the turn."  To  do this, type the
  turn request  (described below) and  wait for the  "--->" prompt.
  When you receive the prompt, you may issue an NOI request.
  
  _N_O_I _A_C_C_E_S_S_-_S_P_E_C_I_F_I_C _R_E_Q_U_E_S_T_S
  
  
  _s_e_l_f___i_d_e_n_t_i_f_y
  
  _S_Y_N_T_A_X
  
  .
  
  _F_U_N_C_T_I_O_N
  
  prints the name of the current session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-54
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _c_o_n_n_e_c_t_, _c_n
  
  _S_Y_N_T_A_X
  
  cn correspondent_name {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  establishes a  session to the remote  NOI whose name is  given by
  correspondent_name.
  
  _A_R_G_U_M_E_N_T_S
  
  correspondent_name
     is the name of the remote NOI correspondent (or administrative
     correspondent) to  which a session is to  be established.  The
     correspondent doesn't  have to be  defined in the  NIT.  If it
     isn't, correspondent_name must have the following syntax:
  
        dsa.<system_name>.$NOI
  
     where system_name is the name  of the remote system supporting
     the correspondent.   This system must  be defined by  a System
     object definition in the NIT.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -bill billing_id
     specifies the  billing ID under  which the remote  system will
     charge  the  user  for  the  session  which  is  going  to  be
     established.
  
  -password password, -pw password
     specifies  the password  which will   be put  in the  initiate
     letter.   Although  this  control  argument  is  optional, you
     should note  that the session  establishment will fail  if the
     remote correspondent requires a  password and you either don't
     provide one or provide one that is bad.  If you do not specify
     this control argument, the dssr  subsystem will prompt you for
     a password.  When you type the password, it will be masked.
  
  -person_id Person_id, -prsid Person_id
     specifies the Person_id of the user on the remote system.
  
  -session_name session_name, -sn session_name
     gives the specified name to  the session which is established.
     If this control  argument is not specified, the  name given to
     the session which  is established defaults to the  name of the
     remote system (e.g., DA10).  In either case, the session which
  
  
                                 6-55
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
     is  established  becomes  the   current  session  for  sending
     requests.  After switching to  another session, it is possible
     to return  to this session by typing  the session_name request
     (described  below) and  specifying the  session_name that  was
     given to this  session at connect time (i.e., the  name of the
     remote  system  or  the  name  specified  by the -session_name
     control argument to the connect request).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-56
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _d_i_s_c_o_n_n_e_c_t_, _d_i_s
  
  _S_Y_N_T_A_X
  
  dis
  
  _F_U_N_C_T_I_O_N
  
  disconnects the current session.   After you issue the disconnect
  request,  you  may  not  send  any  other  requests to the remote
  correspondent to  which this session was  established.  The first
  session  in the  list of   current sessions  becomes the  current
  session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-57
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___i_n_f_o_, _g_i
  
  _S_Y_N_T_A_X
  
  gi argument
  
  _F_U_N_C_T_I_O_N
  
  prints  information about  either all  of the  active sessions or
  about one specific session.
  
  _A_R_G_U_M_E_N_T_S
  
  gsl
     prints  a  list  of  all  of  the  active  sessions.  For each
     session,  prints the  name of   the session,  the name  of the
     remote system, the name of the remote session control, and the
     name of the remote mailbox.
  
  gsa session_name
     prints  the attributes  of  the  specified session.   The name
     specified  by session_name  must be   the name  given to  this
     session  at connection  time (i.e.,   the name  of the  remote
     system  or the  name  specified  by the  -session_name control
     argument to the connect request).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-58
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _s_e_s_s_i_o_n___n_a_m_e_, _s_n
  
  _S_Y_N_T_A_X
  
  sn session_name
  
  _F_U_N_C_T_I_O_N
  
  causes  the  specified  session  to  become  the current session.
  Subsequent requests  typed by the Administrator are  sent on this
  session.
  
  _A_R_G_U_M_E_N_T_S
  
  session_name
     is  the name  of the   session which  will become  the current
     session.  The name specified by  session_name must be the name
     given to  this session at  connection time (i.e.,  the name of
     the remote  system or the name specified  by the -session_name
     control argument to  the connect request).  For a  list of the
     names  of all  of the  active sessions,  use the  get_info gsl
     request, described above.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-59
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _t_u_r_n_, _t
  
  _S_Y_N_T_A_X
  
  t
  
  _F_U_N_C_T_I_O_N
  
  causes the  subsystem to send an  attention to the remote  NOI to
  ask for the turn.  When  the remote correspondent sends the turn,
  the "--->" prompt  appears on the terminal, allowing  you to type
  an  NOI request.  Once  an NOI request  has been sent,  the local
  session loses  the turn.  Thus, you  must ask for the  turn (with
  the turn request) each time you want to send an NOI request.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-60
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _L_I_S_T _O_F _R_E_M_O_T_E _N_A_D _A_C_C_E_S_S _R_E_Q_U_E_S_T_S
  
  There are two kinds of requests which can be issued if you invoke
  the remote  NOI/NAD access facility with the  NAD activity (i.e.,
  if you set the activity argument to "nad_access").  They are:
  
       ox    NAD access-specific requests
  
       ox    NAD requests
  
  Both the  NAD access-specific requests  and the NAD  requests are
  described below.  The NAD access-specific requests include all of
  the requests  described above for the remote  NOI access facility
  with the exception of the turn request, which is not used because
  it is  not required to send  NAD requests.  The NAD  requests are
  designed  so  that  their  interface  is  similar  to the DNS NOI
  interface.   This  interface  is  described  in  the  _D_N_S  _S_y_s_t_e_m
  _O_p_e_r_a_t_i_o_n_s  manual,  Order  No.   DP42  and  in  the  _D_N_S  _S_y_s_t_e_m
  _O_p_e_r_a_t_i_o_n_s manual, Reference No.  39 A2 9799.
  
  _N_A_D _A_C_C_E_S_S_-_S_P_E_C_I_F_I_C _R_E_Q_U_E_S_T_S
  
  
  _s_e_l_f___i_d_e_n_t_i_f_y
  
  _S_Y_N_T_A_X
  
  .
  
  _F_U_N_C_T_I_O_N
  
  prints the name of the current session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-61
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _c_o_n_n_e_c_t_, _c_n
  
  _S_Y_N_T_A_X
  
  cn correspondent_name {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  establishes a  session to the remote  NAD whose name is  given by
  correspondent_name.
  
  _A_R_G_U_M_E_N_T_S
  
  correspondent_name
     is the name of the remote NAD correspondent (or administrative
     correspondent) to  which a session is to  be established.  The
     correspondent doesn't  have to be  defined in the  NIT.  If it
     isn't, correspondent_name must have the following syntax:
  
        dsa.<system_name>.$NAD
  
     where system_name is the name  of the remote system supporting
     the correspondent.   This system must  be defined by  a System
     object definition in the NIT.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -bill billing_id
     specifies the  billing ID under  which the remote  system will
     charge  the  user  for  the  session  which  is  going  to  be
     established.
  
  -password password, -pw password
     specifies  the password  which will   be put  in the  initiate
     letter.   Although  this  control  argument  is  optional, you
     should note  that the session  establishment will fail  if the
     remote correspondent requires a  password and you either don't
     provide one or provide one that is bad.  If you do not specify
     this control argument, the dssr  subsystem will prompt you for
     a password.  When you type the password, it will be masked.
  
  -person_id Person_id, -prsid Person_id
     specifies the Person_id of the user on the remote system.
  
  -session_name session_name, -sn session_name
     gives the specified name to  the session which is established.
     If this control  argument is not specified, the  name given to
     the session which  is established defaults to the  name of the
     remote system (e.g., DA10).  In either case, the session which
  
  
                                 6-62
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
     is  established  becomes  the   current  session  for  sending
     requests.  After switching to  another session, it is possible
     to return  to this session by typing  the session_name request
     (described  below) and  specifying the  session_name that  was
     given to this  session at connect time (i.e., the  name of the
     remote  system  or  the  name  specified  by the -session_name
     control argument to the connect request).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-63
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _d_i_s_c_o_n_n_e_c_t_, _d_i_s
  
  _S_Y_N_T_A_X
  
  dis
  
  _F_U_N_C_T_I_O_N
  
  disconnects the current session.   After you issue the disconnect
  request,  you  may  not  send  any  other  requests to the remote
  correspondent to  which this session was  established.  The first
  session  in the  list of   current sessions  becomes the  current
  session.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-64
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___i_n_f_o_, _g_i
  
  _S_Y_N_T_A_X
  
  gi argument
  
  _F_U_N_C_T_I_O_N
  
  prints  information about  either all  of the  active sessions or
  about one specific session.
  
  _A_R_G_U_M_E_N_T_S
  
  gsl
     prints  a  list  of  all  of  the  active  sessions.  For each
     session,  prints the  name of   the session,  the name  of the
     remote system, the name of the remote session control, and the
     name of the remote mailbox.
  
  gsa session_name
     prints  the attributes  of  the  specified session.   The name
     specified  by session_name  must be   the name  given to  this
     session  at connection  time (i.e.,   the name  of the  remote
     system  or the  name  specified  by the  -session_name control
     argument to the connect request).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-65
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _s_e_s_s_i_o_n___n_a_m_e_, _s_n
  
  _S_Y_N_T_A_X
  
  sn session_name
  
  _F_U_N_C_T_I_O_N
  
  causes  the  specified  session  to  become  the current session.
  Subsequent requests  typed by the Administrator are  sent on this
  session.
  
  _A_R_G_U_M_E_N_T_S
  
  session_name
     is  the name  of the   session which  will become  the current
     session.  The name specified by  session_name must be the name
     given to  this session at  connection time (i.e.,  the name of
     the remote  system or the name specified  by the -session_name
     control argument to  the connect request).  For a  list of the
     names  of all  of the  active sessions,  use the  get_info gsl
     request, described above.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-66
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _N_A_D _R_E_Q_U_E_S_T_S
  
  
  _d_i_s_p_l_a_y___a_t_t_r_i_b_u_t_e_s_, _d_a
  
  _S_Y_N_T_A_X
  
  da object_class {object_name} {selection_criteria}
  
  _F_U_N_C_T_I_O_N
  
  obtains a  partial list of the  attributes of a class  of objects
  defined  on a  remote system  or of  a particular  object in that
  class of objects.
  
  _A_R_G_U_M_E_N_T_S
  
  object_class
     specifies the  class of the object(s)  whose attributes should
     be obtained.   To print a  list of the  existing classes, type
     "help classes".
  
  object_name
     specifies  the name  of a  particular object  whose attributes
     should be obtained.   This object must belong to  the class of
     objects specified  by object_class.  The  object_name argument
     is incompatible with the selection_criteria argument.
  
  selection_criteria
     specifies a set  of criteria to be used to  select a subset of
     the  objects   specified  by  object_class.   See   "Notes  on
     Selection  Criteria"  at  the  end   of  this  section  for  a
     description   of   the   syntax   of   this   argument.    The
     selection_criteria   argument   is   incompatible   with   the
     object_name argument.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-67
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___a_t_t_r_i_b_u_t_e_s_, _g_a
  
  _S_Y_N_T_A_X
  
  ga object_class {object_name} {selection_criteria}
  
  _F_U_N_C_T_I_O_N
  
  obtains a complete  list of the attributes of a  class of objects
  defined  on a  remote system  or of  a particular  object in that
  class of objects.
  
  _A_R_G_U_M_E_N_T_S
  
  object_class
     specifies the  class of the object(s)  whose attributes should
     be obtained.   To print a  list of the  existing classes, type
     "help classes".
  
  object_name
     specifies  the name  of a  particular object  whose attributes
     should be obtained.   This object must belong to  the class of
     objects specified  by object_class.  The  object_name argument
     is incompatible with the selection_criteria argument.
  
  selection_criteria
     specifies a set  of criteria to be used to  select a subset of
     the  objects   specified  by  object_class.   See   "Notes  on
     Selection  Criteria"  at  the  end   of  this  section  for  a
     description   of   the   syntax   of   this   argument.    The
     selection_criteria   argument   is   incompatible   with   the
     object_name argument.
  
  _E_X_A_M_P_L_E_S
  
  The  following  request  line  prints  a  complete  list  of  the
  attributes of the Network Subscription (ns) object TPC:
  
     ga ns TPC
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-68
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___l_i_s_t_, _g_l_, _l_i_s_t_, _l_s
  
  _S_Y_N_T_A_X
  
  gl object_class {selection_criteria}
  
  _F_U_N_C_T_I_O_N
  
  obtains a list  of all of the objects of a  given class which are
  defined on a  remote system.  A restricted subset  of the objects
  may be obtained by specifying some selection criteria.
  
  _A_R_G_U_M_E_N_T_S
  
  object_class
     specifies the class of the objects which should be listed.  To
     print a list of the existing classes, type "help classes".
  
  selection_criteria
     specifies a set  of criteria to be used to  select a subset of
     the  objects   specified  by  object_class.   See   "Notes  on
     Selection  Criteria"  at  the  end   of  this  section  for  a
     description of the syntax of this argument.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-69
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _g_e_t___n_u_m_b_e_r_, _g_n_, _n_u_m_b_e_r_, _n_b
  
  _S_Y_N_T_A_X
  
  gn object_class {selection_criteria}
  
  _F_U_N_C_T_I_O_N
  
  obtains  the number  of the  objects of  a given  class which are
  defined on a  remote system.  A restricted subset  of the objects
  may be obtained by specifying some selection criteria.
  
  _A_R_G_U_M_E_N_T_S
  
  object_class
     specifies  the class  of the  objects whose  number should  be
     obtained.  To print a list of the existing classes, type "help
     classes".
  
  selection_criteria
     specifies a set  of criteria to be used to  select a subset of
     the  objects   specified  by  object_class.   See   "Notes  on
     Selection  Criteria"  at  the  end   of  this  section  for  a
     description of the syntax of this argument.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-70
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _u_p_d_a_t_e_, _u_p
  
  _S_Y_N_T_A_X
  
  up object_class object_name -control_args
  
  _F_U_N_C_T_I_O_N
  
  updates either the state of an  object defined on a remote system
  or the value of one of  the object's parameters.  This request is
  most useful for updating the current state of an object:  locking
  it, putting it in enable mode, etc..
  
  _A_R_G_U_M_E_N_T_S
  
  object_class
     specifies  the class  of the  object whose  state or parameter
     should be updated.   To print a list of  the existing classes,
     type "help classes".
  
  object_name
     specifies  the name  of the  object whose  state or  parameter
     should be  updated.  This object  must belong to  the class of
     objects specified by object_class.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -ns new_state, -NS new_state
     specifies that  the state of  the object should  be changed to
     the  new  state  specified  by  new_state.   New_state must be
     chosen from the following list:
  
     disable      (ds) (DS)
     down         (do) (DO)
     enable       (en) (EN)
     locked       (lk) (LK)
     no_state     (ns) (NS)
     reserved     (rs) (RS)
     shutdown     (sd) (SD)
     test         (te) (TE)
     used         (us) (US)
  
     If this control argument is not specified, the -parameter_name
     control argument must be specified.
  
  -parameter_name new_parm_value
     specifies  that  the  parameter  whose  name  is  specified by
     parameter_name should be changed to the new value specified by
  
  
  
                                 6-71
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
     new_parm_value.  To  print a list of the  parameters which may
     be  updated  for  a  given  class  of  objects,  type  "update
     <object_class>   ??".   If   this  control   argument  is  not
     specified, the -ns control argument must be specified.
  
  -type object_type
     specifies  the type  of the  object whose  state or  parameter
     should be updated.  For  example, if the object's object_class
     is   Physical  Line  (PL),   its  object_type  could   be  New
     Multiplexer Line Controller (NMLC).
  
  _E_X_A_M_P_L_E_S
  
  To  change  the  call  parameter  (which  specifies the transpacs
  subscription  number)  on  the  Network  Subscription (ns) object
  TPC2, issue the following requests:
  
     up ns TPC2 -ns locked      <changes state to locked>
     up ns TPC2 -call 178060475     <updates call number>
     up ns TPC2 -ns enable      <changes state to enable>
  
  To  change  the  model  parameter  (which  specifies  the default
  terminal  model)  on  the  Terminal  Device  (dv)  object TU01 to
  SCORPION, issue the following request:
  
     up dv TU01 -md SCORPION
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 6-72
  ____________                                         ____________
  
  dsa_ssu_root                                         dsa_ssu_root
  ____________                                         ____________
  
  
  _N_O_T_E_S _O_N _S_E_L_E_C_T_I_O_N _C_R_I_T_E_R_I_A
  
  The   selection  criteria   which   may   be  specified   by  the
  selection_criteria    argument    to    the   display_attributes,
  get_attributes, get_list, and get_number  requests allow the user
  to select a subset of objects of a specified class.  Objects must
  match  the  selection  criteria  in  order  to  be selected.  The
  selection_criteria  argument  may  be  specified  in  any  of the
  following ways:
  
     -os state, -OS state, -match_state state
     -type type
     -om class:name, -OM class:name, -match class:name
  
  
     state
        specifies  that the object  must be in  the given state  in
        order to be selected.
  
     type
        specifies  that the  object must  be of  the given  type in
        order to be selected.
  
     class:name
        specifies a mapping.  For an object to be selected, it must
        have  a relationship  with an  object whose  class is  that
        specified  by class  and whose  name is  that specified  by
        name.   This selection  criterion may  be specified  twice,
        since an object  may be linked to two other  objects in the
        system.
  
  One of the  criteria, two criteria, or all three  criteria may be
  specified  at the  same  time.   In addition,  the -om/-OM/-match
  criterion may be specified twice.  Here is a sample request line:
  
     gl pl -type NMLC -os en -match ll:LLA1
  
  This request line  returns the list of Physical  Lines whose type
  is  NMLC, whose  state is  enabled, and  which are  linked to the
  logical line object whose name is LLA1.
  
  
  
  
  
  
  
  
  
  
  
                                 6-73
  
  
  
  
  
  
  
  
  
                              SECTION 7
  
  
              CHANGES AND NEW FEATURES THAT AFFECT USERS
  
  
  
  
       This  section  describes  DSA-specific  changes  to  the MCS
  Multics  user/system interface.   The changes  are effective when
  users connect to Multics through DSA network facilities.
  
  
       For purposes  of the discussion below, note  that type ahead
  is a standard feature on a DN8/7100 equipped with MLC-16.
  
  
  _C_O_N_N_E_C_T_I_N_G _T_O _M_U_L_T_I_C_S _F_R_O_M _A _R_E_M_O_T_E _T_E_R_M_I_N_A_L
  
       In  a non-DSA  Multics configuration,  the transfer  of data
  between  a remote  terminal and  the Multics  system occurs  over
  communications  channels managed   by the  Multics communications
  system (MCS).   However, if the  Multics system is  configured as
  part of a DSA network, then users can connect to Multics by means
  of  DSA  network  facilities.   The  DSA  connection  occurs over
  communications  channels  managed   by  the  distributed  network
  supervisor (DNS)  and the Multics networking  architecture (MNA).
  (Note that if  the Multics system is configured as  part of a DSA
  network, users retain the capability to connect to Multics either
  by the MCS method or by using DSA network facilities.)
  
  
       The MCS  connection procedure requires the  terminal user to
  first  make  a  physical  connection  to  Multics  (by  following
  site-specific procedures) and then to  engage in a login dialogue
  in  which a valid  user name and  password must be  supplied.  If
  Multics  verifies  that  the  supplied  user  name  and  password
  identify  an authorized  individual,  then  the terminal  user is
  permitted access to the system.   The MCS connection procedure is
  described in  the _N_e_w _U_s_e_r'_s  _I_n_t_r_o_d_u_c_t_i_o_n _t_o _M_u_l_t_i_c_s  (Order No.
  CH24).
  
  
  
  
  
  
  
                                 7-1
  
  
  
       When  connecting   to  Multics  by  means   of  DSA  network
  facilities, the terminal user must perform the following actions:
  
  1.   Make a physical connection  to the DN8/7100.  This procedure
       will vary from site to site.
  
  2.   Login  to DNS  (which resides  in the  DN8/7100).  This  may
       happen  automatically,  or  you  may  have  to  engage  in a
       dialogue with DNS.
  
       DNS may ask  you questions in your own  maternal language or
       query  you as to  which language you  would like to  use, by
       printing the following prompt:  "LANGUAGE:".
  
       Depending on  whether your line is hardwired  or leased, DNS
       may  also ask you  for the terminal  type you are  using, by
       printing the following prompt:  "MODEL:".  (This DSA request
       is  equivalent to the  MCS preaccess command  "ttp <terminal
       type>".)   You may  respond to  this prompt  with a carriage
       return, in which case you will use the default terminal type
       declared by the DSA administrator at DNS generation time, or
       you  may enter  the actual   terminal type.   Note that  the
       terminal type  you enter must be  one which is known  to the
       DN8/7100 (i.e., one  which is specified on a MD  card in the
       DN8/7100's configuration file) and also one which is defined
       in  the Multics  TTF.  DNS  will forward  the terminal  type
       information to Multics.
  
       Whether or not you have to engage in a dialogue, whether the
       questions are  in your own  language, whether you  are asked
       for your  choice of language,  and whether you  are asked to
       specify a  terminal type, are  all decided and  specified by
       the DSA administrator at DNS generation time.
  
  3.   Connect  to  the  correspondent  (i.e.,  the  remote Multics
       system).   This  may  happen  automatically,  or  you may be
       queried with the following prompt:
  
            CORRESPONDENT:
  
       You may  respond to this  prompt with a  carriage return, in
       which case  you will use the  default correspondent declared
       by the  DSA administrator at  DNS generation time.   If your
       DSA   administrator   specified    a   mnemonic   for   this
       mailbox/session control pair at DNS generation time, you may
       type that mnemonic.  For example:
  
            SYSX
  
       If you type an unknown mnemonic,  you will be prompted up to
       three times for a known one.  Note that the mnemonic must be
       specified on a CO card in the DN8/7100's configuration file.
  
  
                                 7-2
  
  
  
       You may also be queried with this prompt:
  
            $*$:
  
       You may respond to this prompt by typing:
  
            CN -DMB <mailbox name> -SCID <session control name>
  
       for example:
  
            CN -DMB LOGIN -SCID BM25
  
  
       If  you just  type "CN",   you will  be prompted  again with
       "CORRESPONDENT:".
  
  4.   Login to Multics in the usual manner.
  
  Note that the site can choose to automate some of the above steps
  to reduce  the number of  keystrokes for the  terminal user.  For
  example, the  step of physically  connecting to the  DN8/7100 can
  also include an automatic login to DNS.
  
  
       When  disconnecting from  Multics  by  means of  DSA network
  facilities, the terminal user must perform the following actions:
  
  1.   Logout from Multics in the usual manner.
  
  2.   Disconnect from the correspondent.   At this point, you have
       the  choice of  reconnecting  to  the same  correspondent or
       connecting to another correspondent accessible through DSA.
  
  3.   Logout from DNS.
  
  4.   Physically  disconnect from  the DN8/7100  (i.e., physically
       disconnect from the network).
  
  Note that,  as with the login  procedure, the site can  choose to
  automate some of the steps in  the logout procedure to reduce the
  number of keystrokes  for the terminal user.  All  four steps can
  be chained automatically or partially chained.
  
  
       For   more   details   on   the   terminal   connection  and
  disconnection  procedures  described  above,  refer  to  the  _D_N_S
  _T_e_r_m_i_n_a_l  _U_s_e_r'_s _G_u_i_d_e,  Order No.    DP42 and  the _D_N_S  _T_e_r_m_i_n_a_l
  _M_a_n_a_g_e_m_e_n_t _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, Reference No.  39 A2 9820.
  
  
  
  
  
  
                                 7-3
  
  
  
  _S_a_m_p_l_e _L_o_g_i_n_/_L_o_g_o_u_t _S_e_s_s_i_o_n
  
       What follows  is an example of a  login/logout session using
  DSA to  access Multics.  Input typed  by the user is  enclosed in
  angle  brackets (<...>).   In  the  login session,  the following
  things happened:
  
       ox    the user  engaged in a  dialogue with DNS.   If the DSA
            administrator  had specified   at generation  time that
            there  be no  local dialogue,  none of  the messages in
            capital  letters would  have appeared.   The user would
            have  been  logged  into   DNS  and  connected  to  the
            correspondent automatically.
  
       ox    the user was asked which language he wanted to use.  If
            the DSA administrator had  specified at generation time
            the language  to be used, the messages  would have been
            printed in  French without the  user having to  ask for
            them  in French,  and the  "LANGUAGE:" message wouldn't
            have appeared.
  
       ox    the user was asked what terminal type he was using.  If
            he had  typed a carriage  return instead of  the actual
            terminal type,  the default terminal type  specified by
            the  DSA administrator  at generation  time would  have
            been used.
  
       ox    the  user  was  asked  to   specify  the  name  of  the
            correspondent  he wanted  to  connect  to.  If  the DSA
            administrator  had arranged  for the  connection to  be
            automatic,  the  "CORRESPONDENT:"  and  "$*$:" messages
            wouldn't  have  appeared.   If  the  user  had  typed a
            carriage  return instead  of the  actual correspondent,
            the   default  correspondent   specified  by   the  DSA
            administrator at generation time would have been used.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 7-4
  
  
  
  $$ 4300 LANGUAGE : <FRANCAIS>
  
  $$ 4200 MODELE : <DKU7002>
  
  $$ 0000 *** D.N.S * RLS:C1 I.0* PAT: 0ET10/1ET10/2ET10 *
          SYS: 20/02/86 ***
  
  $$ 1000 VOTRE IDENTIFICATION EST DIAI SC: BM26  MODELE:DKU7002
  
  $$ 5800 VOUS ETES ENREGISTRE
  
  $$ 4700 CORRESPONDANT : <SYSX>
  
  $$ 4600 $*$ : <CN -DMB LOGIN -SCID BM25>
  
  $$ 0100 VOUS ETES CONNECTE A LOGIN       BM25 SESSION: 334
  
  Load = 2.0 out of 80.0 units: users = 2, 04/01/86  1352.6 fst Tue
  <l fd>
  Password:
  < ... >
  You are protected from preemption until 1353.
  Druon.USER logged in 04/01/86  1353.3 fst Tue from DKU7002
        terminal "none".
  Last login 03/27/86  1828.0 fst Thu from SCORPION terminal
        "none".
     .
     .
     .
     .
     .
  r 13:53 4.276 51
  
  <logout>
  
  Druon.USER logged out 04/01/86  1353.6 fst Tue
  CPU usage 0 sec, cost $0.00.
  hangup
  
  
  $$ 0200 VOUS ETES DECONNECTE: 0000
  
  $$ 5500 AU REVOIR
  
  $$ 0900 A BIENTOT
  
  
  
  
  
  
  
  
  
                                 7-5
  
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _t_t_y__ _I_/_O _M_O_D_U_L_E
  
       The tty_  I/O module supports I/O  from/to terminal devices.
  A complete description of the tty_  I/O module is provided in the
  _M_u_l_t_i_c_s _S_u_b_r_o_u_t_i_n_e_s _a_n_d _I/_O _M_o_d_u_l_e_s manual (Order No.  AG93).
  
  
       When a  terminal is used to  connect to a DSA  endpoint, the
  tty_  I/O  module  attaches  the  dsa_tty_io_  I/O  module.   The
  tty_/dsa_tty_io_  interface modifies  the "standard"  operational
  characteristics of tty_.   There is a set of  tty_ control orders
  available in the  non-DSA environment that cannot be  used in the
  DSA environment;  there are other,  new, control orders  that are
  supported only in the DSA environment.
  
  
       The information below describes the tty_ control orders that
  can only be used in the DSA environment, and also provides a list
  of  the  tty_  control  orders  that  cannot  be  used in the DSA
  environment.   The  information  is  designed  to  supplement the
  complete description of  the tty_ I/O module that  appears in the
  _M_u_l_t_i_c_s _S_u_b_r_o_u_t_i_n_e_s _a_n_d _I/_O _M_o_d_u_l_e_s manual.
  
  
  _N_e_w _C_o_n_t_r_o_l _O_r_d_e_r_s
  
       The following new control orders are only supported when the
  terminal is operating in the DSA environment.
  
  conceal_next_line
       causes  the  FNP  to  turn  off  local  terminal echoing, if
       possible,  until  the  next  end-of-record.   If the echoing
       cannot be turned off, then  the FNP will send a 12-character
       mask to the terminal (12 "X"s  and 12 "E"s), read the input,
       and  repeat  the  mask.   Note  that  this masking algorithm
       differs from the current Multics algorithm, which uses three
       random character strings.
  
  get_line_indicator
       returns the end-of-line indicator.   The info pointer should
       point to  a variable structure (declared as  "char (2) var")
       in which the line indicator is stored.
  
  set_line_indicator
       sets the  character sequence to  be used as  the end-of-line
       indicator.  A  maximum of two  characters can be  used.  The
       default sequence is \c.  The  info pointer should point to a
       variable  structure  (declared  as  "char  (2)  var")  which
       contains the line indicator.
  
  
  
  
  
                                 7-6
  
  
  
  get_network_type
       returns the  type of the  network.  All the  possible values
       are  declared  in  net_event_message.incl.pl1.   When called
       with          MCS,          the          error          code
       error_table_$undefined_order_request   is  returned.    When
       called with DSA, the value  DSA_NETWORK_TYPE is ret The info
       pointer should point to variable declared "fixed bin".
  
  get_page_indicator
       returns the end-of-page indicator.   The info pointer should
       point to  a variable structure (declared as  "char (4) var")
       in which the page indicator is stored.
  
  set_page_indicator
       sets the  character sequence to  be used as  the end-of-page
       indicator.  A  maximum of four characters can  be used.  The
       default sequence is EOP.  The info pointer should point to a
       variable  structure  (declared  as  "char  (4)  var")  which
       contains the page indicator.
  
  get_tabulation
       returns  the tabulation  interval.  The  info pointer should
       point to  a variable structure (declared as  "fixed bin") in
       which the tabulation interval value is stored.
  
  set_tabulation
       sets the number  of characters to be used  as the tabulation
       interval.   The default  value is  10 characters.   The info
       pointer  should point to  a variable structure  (declared as
       "fixed bin") which contains the tabulation interval value.
  
  
  _C_o_n_t_r_o_l _O_r_d_e_r_s _T_h_a_t _C_a_n_n_o_t _B_e _U_s_e_d
  
       The following tty_ control orders are not supported when the
  terminal is operating in the DSA environment:
  
       interrupt              set_wakeup_table
       set_line_type          listen
       start_xmit_hd          copy_meters
       stop_xmit_hd           input_flow_control_chars
       get_ofc_info           output_flow_control_chars
       get_ifc_info           refuse_printer_off
       set_delay              accept_printer_off
       get_delay              set_framing_chars
       reset_more             get_framing_chars
                              wru
  
  
  
  
  
  
  
                                 7-7
  
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _s_e_t___t_t_y _C_O_M_M_A_N_D
  
       The  set_tty command  modifies the  terminal type associated
  with the terminal.   There are a number of  new control arguments
  available only  when the terminal  is used to  connect to Multics
  through a  DSA network, as well  as a number of  existing control
  arguments which  are not available  when the terminal  is used to
  connect to Multics through a  DSA network.  The information below
  describes the  new control arguments  and provides a  list of the
  control  arguments which  are not  available.  It  also describes
  new/changed options  available only when the terminal  is used to
  connect  to   Multics  through  a  DSA  network.    All  of  this
  information   is  designed   to  supplement   the  more  complete
  description of  the set_tty command  that appears in  the _M_u_l_t_i_c_s
  _C_o_m_m_a_n_d_s _a_n_d _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s manual (Order No.  AG92).
  
  
  _N_e_w _C_o_n_t_r_o_l _A_r_g_u_m_e_n_t_s
  
       The following new control  arguments are only supported when
  the terminal is used in the DSA environment:
  
  -tab_interval N, -ti N
       specifies the number of spaces  the cursor is moved when the
       tab key is pressed.  If  this control argument is omitted, a
       default value of 10 is assumed.
  
  -line_indicator STR, -li STR
       specifies the  character string to  be used as  the terminal
       end-of-line  indicator.   STR  can   be  a  maximum  of  two
       characters.   If  this  control  argument  is  omitted,  the
       character string \c is used.
  
  -no_line_indicator, -nli
       specifies  that  no  end-of-line  indicator  is  to be used.
       There  will  be  no  continuation  sequence  (such  a \c) to
       indicate that a single output  line sent to the terminal was
       "broken"  and  displayed  as  two  (or  more)  lines  on the
       terminal screen.
  
  -page_indicator STR, -pi STR
       specifies the  character string to  be used as  the terminal
       end-of-page  indicator.   STR  can  be  a  maximum  of  four
       characters.   If  this  control  argument  is  omitted,  the
       character string EOP is used.
  
  -no_page_indicator, -npi
       specifies  that  there  will  be  no  end-of-page indicator.
       There will be no character string (such as EOP) to warn that
       the terminal screen is full.
  
  
  
  
                                 7-8
  
  
  
  -edit STR
       specifies one  character to be  used as the  erase character
       (which  provides  the  ability  to  delete  the  last  typed
       character),  a  second  character  to  be  used  as the kill
       character (which provides the  ability to delete the current
       line),  and a third  character to be  used as the  redisplay
       character  (which  provides  the   ability  to  refresh  the
       screen).   The  values  are  specified  in a three-character
       string  with  the  first  character  representing  the erase
       character,  the  second   character  representing  the  kill
       character,   and  the   third  character   representing  the
       redisplay  character.  The  erase character  and/or the kill
       character can be specified as blanks, in which case they are
       not changed.   (For example, the  command line:  stty  -ed "
       AB" changes the kill  character and the redisplay character,
       but  not the  erase  character.)   Note that  this statement
       changes the editing characters specified in the TTF.
  
  
  _C_o_n_t_r_o_l _A_r_g_u_m_e_n_t_s _T_h_a_t _C_a_n _N_o_t _B_e _U_s_e_d
  
       The  following set_tty  control arguments  are not supported
  when the terminal is used in the DSA environment:
  
       -buffer_size      -delay
       -can_type=replace -input_flow_control
       -frame            -output_suspend_resume
       -print_delay      -output_etb_ack
       -print_frame
  
  
  _C_h_a_n_g_e_s _t_o _t_h_e _-_t_t_p _C_o_n_t_r_o_l _A_r_g_u_m_e_n_t
  
       The  -ttp  control  argument  to  the  set_tty command works
  differently when the terminal is used in the DSA environment than
  it does when the terminal is  used in the MCS environment.  Under
  DNS, once  a terminal type is  chosen, it cannot be  changed.  So
  typing "set_tty  -ttp" only changes  what can be  changed through
  the STC record (the tool used  to communicate with DNS).  None of
  the  static parameters,  for  example,  the delays,  are changed.
  They  remain the same;  i.e., they remain  those of the  terminal
  type which was set at login time by DNS.
  
  
  _N_e_w _a_n_d _C_h_a_n_g_e_d _M_o_d_e _S_p_e_c_i_f_i_c_a_t_i_o_n_s
  
       The  following new  mode specifications  are supported  only
  when the terminal is used in the DSA environment:
  
  can_type
       The  only  mode  allowed  for  can_type  is overstrike.  The
       can_type=replace option is not allowed.
  
  
                                 7-9
  
  
  
  fep_edit, ^fep_edit
       specifies, if some editing  is required ("esc" or/and "erkl"
       modes set),  where the editing  is done.  If  fep_edit mode,
       then the editing is done in the FEP; if ^fep_edit mode, then
       the editing is done in Multics.
  
  more_mode=scroll
       specifies  that, when new  lines are to  be added to  a full
       screen,  the new  lines are  added at  the bottom;  previous
       lines are  moved up until  they disappear from  the top (are
       scrolled off the top).  This is the default.
  
  more_mode=clear
       specifies  that, when new  lines are to  be added to  a full
       screen,  the screen is  completely cleared (erased)  and the
       new lines are  added at the top of the  screen.  The default
       value is more_mode=scroll.
  
  sdialog, ^sdialog
       controls  the ability  of the   terminal user  to engage  in
       secondary  dialogue.   Secondary  dialogue  is  the  set  of
       commands,  messages, and  replies exchanged  between the FNP
       and the terminal user.
  
       The default mode specification  is changed such that default
  can now be used to specify erkl, can, ^rawi, ^rawo, esc, ^screen,
  sdialog and fep_edit.  (Note that  sdialog and fep_edit modes are
  added, that ^screen mode is the same as ^breakall mode, ^wake_tbl
  mode is deleted).   The "default" mode checks also  for all these
  modes, if they are specified  in the "default_modes" statement in
  the TTF for the terminal type used.  If so, the values in the TTF
  "default_modes" statement are set.
  
  
       The init mode specifications have  been changed such that it
  can now  be used to specify  that all boolean modes  are off, the
  line length is set to 79, the page length is set to 23, more_mode
  is set to scroll, and canon_type is set to replace.
  
  
       Additionally,  the following  mode specifications  have been
  renamed in  order to more  accurately describe the  function they
  represent.  (The "old" names will  continue to be valid; however,
  the set_tty command will print the new names when queried.)
  
  Old Mode Name     New Mode Name     Notes
  
  
  
  
  
  
  
  
                                 7-10
  
  
  
  breakall,         screen,           The value screen is used
  ^breakall         ^screen           when using applications
                                      (e.g., Emacs) that can
                                      make use of CRT terminal
                                      features; the value
                                      ^screen implies support
                                      in line mode.
  
  scroll,           line_count,       Specifies, if "line_count"
  ^scroll           ^line_count       mode, that the current line
                                      count is to reset on each
                                      input.
  
  8bit,             i8bit,            Indicates 8-bit mode on
  ^8bit             ^i8bit            input.
  
  no_outp,          o8bit,            Indicates 8-bit mode on
  ^no_outp          ^o8bit            output.
  
  
       Finally, when specifying the  character length of a terminal
  line, the syntax ll=N can now be used in addition to llN and ^ll.
  When specifying the page length, the  syntax pl=N can now be used
  in addition to plN and ^pl.
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _T_E_R_M_I_N_A_L _T_Y_P_E _F_I_L_E
  
       The terminal type file (TTF) consists of a series of entries
  that define  the characteristics of  all terminal types  known to
  the  system.   The  Multics  TTF  has  been  extended  to  permit
  definition of options  that are specific to operation  in the DSA
  environment.    This  is    accomplished  via   the  dsatm_device
  substructure, which is optional  and consists of the dsatm_device
  statement and one or more substatements (defined below).  Default
  values are assumed if no dsatm_device substructure is included in
  the TTF entry for a given terminal type.
  
  
       Note that every terminal type specified by an MD card in the
  DN8/7100's  configuration  file  must  also  be  specified  by  a
  terminal_type  statement  under  a  terminal  type  entry  in the
  Multics TTF.
  
  
       A  description of  the syntax  of TTF  entries as  well as a
  description  of all  other statements   contained in  the TTF  is
  provided in the _M_u_l_t_i_c_s  _P_r_o_g_r_a_m_m_e_r'_s _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l (Order No.
  AG91).
  
  
  
  
  
                                 7-11
  
  
  
  can_type:
       The  only  mode  allowed  for  can_type  is overstrike.  The
       can_type=replace option is not allowed.
  
  dsatm_device:
       The  dsatm_device  statement  specifies   the  name  of  the
       substructure  and  must  be   the  first  statement  in  the
       substructure.
  
  data_presentation:  <protocol1>, {<protocol2>}, {<protocol3>};
       The data_presentation  statement specifies one or  more data
       presentation  protocols that can  be used with  this device.
       The possible  values are:  real, sdp,  and transparent.  The
       default value is real.
  
  sdp_class:  <protocol>;
       The sdp_class statement specifies  the SDP protocol class to
       be  used with  this device.   Since only  the mandatory  SDP
       protocol class is supported, the value of this statement can
       only be:  mandatory.  This is  the default.  If the value of
       the  data_presentation statement  is not  sdp, the sdp_class
       statement is not meaningful.
  
  real_class:  <protocol>;
       The  real_class  statement  specifies   the  class  of  real
       presentation  protocol to  be  used  with this  device.  The
       value of this statement must  be one of the following:  tty,
       vip77xx,  vip78xx,  327x,  batch_rci,  tmmvu,  2780,  tmmrb,
       2780_3780_rje.  The default value is tty.
  
  device_id:  N;
       The device_id value can only be:  1.  This is the default.
  
  device_type:  <device_type>;
       The  device_type statement  specifies the  physical terminal
       device type.   The possible values are:   display, keyboard,
       ro_printer, keyboard_printer, keyboard_display, card_reader,
       paper_tape_reader,    badge_reader,   cassette,    diskette,
       card_punch,  paper_tape_punch.  This  statement is  optional
       and can be omitted.  If this statement is not specified, its
       value is undefined (i.e., its value is zero).
  
  shareability:  <string>;
       The shareability  statement specifies whether the  device is
       available  for  allocation.   The  possible  values  are  as
       follows:
  
       dedicated
            The device is not available for allocation.
  
       dedicated_or_shareable
            The device is available for allocation.
  
  
                                 7-12
  
  
  
       exclusively_shareable
            The  device  can  only  be  allocated  as  a  shareable
            resource.
  
       The default value is dedicated.
  
  allocation_unit:  <unit>;
       The  allocation_unit statement  specifies the  most superior
       allocation  unit for input  data.  The allocation  units are
       listed  below with  the most  inferior unit  (record) listed
       first.   A superior unit  contains all inferior  units.  For
       example,  if   the  allocation_unit  statement  is   set  to
       quarantine_unit,  the quarantine  unit would  contain one or
       more records.
  
       record
            Data characters are formed into records.
  
       quarantine_unit
            Records are formed into quarantine units.
  
       interaction_unit
            Quarantine units are formed into interaction units.
  
       session
            Interaction units are formed into session units.
  
       The default value is record.
  
  line_overflow:  <action>;
       The line_overflow statement specifies the action to be taken
       when  a line exceeds  the maximum line  length.  One of  the
       following values must be used:
  
       folding
            The overlength characters are continued on a succeeding
            line.
  
       no_folding
            No special action is taken.   The result depends on the
            terminal's capabilities.
  
       The default value is folding.
  
  page_overflow:  <action>;
       The page_overflow statement specifies the action to be taken
       when the  number of lines  sent to the  terminal exceeds the
       maximum number of  lines that can be printed  on the screen.
       One of the following values must be specified:
  
  
  
  
  
                                 7-13
  
  
  
       scroll
            New  lines  are  added  at  the  bottom  of the screen;
            existing  lines are scrolled  up; the top-most  line is
            rolled off the screen and lost.
  
       clear
            The screen  is completely cleared (erased)  and the new
            lines are added at the top of the screen.
  
       The default value is scroll.
  
  character_encoding:  <type1>, {<type2>, ...  <typeN>};
       The  character_encoding  statement  specifies  the  type  of
       character encoding to be used with this device.  One or more
       of the following values can be supplied:
  
       iso-7bits
            A 7-bit code defined by an ISO table.
  
       iso_8bits
            An 8-bit code defined by an ISO table.
  
       ebcdic
            8-bit EBCDIC code.
  
       teletex
            Teletex code.
  
       binary_8bits
            An 8-bit code translated without interpretation.
  
       The default value is iso_7bits.
  
  character_set:  <char_set1>, {<char_set2>, ...  <char_setN>};
       The   character_set   statement   specifies   the  available
       character sets.  One or more  of the following values can be
       specified:      ascii,     iso,     uk,    norwegian_danish,
       swedish_finish, portuguese, french,  greek, spanish, german,
       pseudo_graphic.  The default value is ascii.
  
  character_subset:  <char_subset1>, {<char_subset2>};
       The  character_subset  statement  specifies  which character
       subset is available  in the event the full  character set is
       not available.   Either one or both of  the following values
       can  be  selected:   upper_lower_case  or  upper_case.   The
       default value is upper_lower_case.
  
  compression_algorithm:  <method>;
       The compression_algorithm specifies  the compression method.
       At  present, there  is no  defined compression  method.  The
       value of this statement  can only be:  no_compression.  This
       is the default value.
  
  
                                 7-14
  
  
  
  character_font:  <style1>, {<style2>, ...  <styleN>};
       The character_font  statement specifies the  typeface styles
       available  on  the  output  device.   One  or  more  of  the
       following  values can  be specified:   any, italics,  elite,
       pica.  The default value is any.
  
  max_record_size:  N;
       The max_record_size  statement specifies the  maximum record
       size (in characters).  The default value is 1920 characters.
  
  attd: <key>;
       The attd  statement specifies the  key (or condition)  to be
       used   for   "destructive"   attention   processing.    With
       destructive  attention  processing,   a  quit  condition  is
       signaled and all input/output data is cleared.  The user can
       select  the break  key (attd:   break;), a  single character
       (e.g., attd:  K;), an ESC character string (e.g., attd:  ESC
       B;),  or  indicate  that   he  will  use  the  corresponding
       secondary   dialogue  command  (attd:    sec_dialog;).   The
       default  is that  the break   key is  used.  Note  that this
       processing  is in  use only  if hndlquit  mode is  on (i.e.,
       hndlquit is specified).
  
  att1: <key>;
       The att1  statement specifies the  key (or condition)  to be
       used  for  "non-destructive"   attention  processing.   With
       non-destructive  attention processing,  a quit  condition is
       signaled,  but the  input/output data  is not  cleared.  The
       values  for  the  att1  statement  are  the  same  as  those
       specified for  the attd statement.  The default  is that the
       break key is used.  Note that this processing is in use only
       if hndlquit mode is off (i.e., ^hndlquit is specified).
  
  stc_available:  <string>;
       The stc_available statement specifies  the capability to use
       the  set_tty  command  to  dynamically  change  the terminal
       characteristics.  The  possible values are yes  and no.  The
       default value is yes.
  
  
  An example of a dsatm_device substructure is shown below.
  
       dsatm_device:
       data_presentation: real;
       real_class: tty;
       device_id: 1;
       device_type: keyboard;
       shareability: dedicated;
       allocation_unit: record;
       line_overflow: folding;
       page_overflow: scroll;
       character_encoding: iso_7bits, binary_8bits;
  
  
                                 7-15
  
  
  
       character_set: ascii;
       max_record_size: 512;
       attd: break;
       att1: break;
       stc_available: yes;
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _t_t_t___i_n_f_o__ _S_U_B_R_O_U_T_I_N_E
  
       The  following  new  entry  point  has  been  added  to  the
  ttt_info_ subroutine.   The new entry  point is used  to retrieve
  DSA-specific information from the terminal type file (TTF).
  
  
               ________________________________________
  
  
  NAME: DSATM_PARAMETERS, TMPARM
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  tmparm {-control_args}
  
  _F_U_N_C_T_I_O_N
  
  tmparm is  a utility interface with the  Multics Terminal Manager
  Correspondent   (TMC)  for   setting  some   tunable  parameters,
  debugging purposes, meters and  log facilities.  These parameters
  are located in dsatm_data_.cds.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -log {path_log}
     specifies the directory  name, or the name of the  log file to
     use for tracing.
          path_log may be:
          a relative pathname,
          an absolute pathname,
          process_dir, pd the log is named [pd]>DSA_TM.trclog
          home_dir, hd the log is named [hd]>DSA_TM.trclog
                            home_dir  is the  default when  -log is
     not
                            specified.
          working_dir, wd the log is named [wd]>DSA_TM.trclog
          See Notes on log facility.
  
  -delete_log -dlog
     specifies  that all  segments <path_log>.date-time  are to  be
     deleted.
  
  
  
  
  
                                 7-16
  ________________                                 ________________
  
  dsatm_parameters                                 dsatm_parameters
  ________________                                 ________________
  
  
  -data_length <value> -datalen
  -dlen
     number of data characters  to log (with dsatm_data_$trace_data
     on)
  
  -print -pr
     display tuning, trace and meter informations.
  
  -print_tuning -pr_tune
  -prtu -ptu
     display the tuning's values while in use.
  
  -print_trace -pr_trace
  -prtr -ptr
     display the values of the trace's bits.
  
  -print_meters {switch_name} -pr_meters
  -prme -pme  display the meter's values for  the switch_name given
     (default is user_i/o).
  
  -reset_meters -rsme
  -rsm -rs resets the meter's fields.
  
  -trace {trace_options} -tr
     sets or resets the bits for the tracing facility.
          trace_options:
          on                  sets all bits
          off                 resets all bits
          See Notes on tracing facility.
  
  -tune {tuning_option=value} -tu
     See Notes on tuning facility.
  
  _N_O_T_E_S
  
  
  Log facility
  the log  created can be examined with  the print_sys_log command.
  In  order to  look at  the binary  data field,  you must  use the
  -interpret (-int) control argument in the psl command.
            For example:  psl DSA_TM.trclog -int -fm -10minutes
  
  Tracing facility.
  This  facility  is  for  debugging  purpose  of  TMC only.  It is
  possible to set a specific bit for a special tracing.
  
  
  
  
  
  
                                 7-17
  ________________                                 ________________
  
  dsatm_parameters                                 dsatm_parameters
  ________________                                 ________________
  
  
    Tracing of input and output in TM routines.
       {^}input, in        {re}set the bit dsatm_data_$trace_input
       {^}output, out      {re}set the bit dsatm_data_$trace_output
    Tracing of entries in TM routines for interrupt action.
       {^}interrupt, int   {re}set the bit dsatm_data_$trace_interrupt
    Tracing of STC sent or received from FEP.
       {^}stc              {re}set the bit dsatm_data_$trace_stc
    Tracing of data sent or received from FEP.
       {^}data             {re}set the bit dsatm_data_$trace_data
    Tracing of errors.
       {^}error,err        {re}set the bit dsatm_data_$trace_error
  
    Tracing of exchanges with session control.
       {^}sc_input,scin    {re}set the bit dsatm_data_$trace_sc_input
       {^}sc_output,scout  {re}set the bit dsatm_data_$trace_sc_output
       {^}sc_data,scd      {re}set the bit dsatm_data_$trace_sc_data
  
    Special debug.
       {^}debug,db         {re}set the bit dsatm_data_$trace_debug
            This switch is used to debug a particular section of
            code of TMC where an unexpected bug occurs.
            In this procedure, you have to insert the following
            line:
                 call dsa_trace_ (ioa_string, ioa args);
            at the line where you want to trace a value.
            The bit dsatm_data_$trace_debug is tested IN the dsa_trace_
            procedure. If on, the ioa_string is expanded and logged in
            the current log file.
  
  Tuning options.
  These parameters are constants, so  they cannot be changed unless
  the user has rw access on the bound segment.
  
       max_tm_rec_size, mtrs
           maximum size for the TMC record buffers
       min_restart_write, mrw
           minimum number of chars necessary to restart a write (50)
       conv_expansion, cve
           coefficient between the size of input and output buffer for
           translation. Output buffer is cve greater than input buffer
           for conversion (TABS->SPACES for example).
       init_max_sessions, ims
  
       These arguments are variables per process, so they may be
       adjusted at the user's convenience.
  
  
  
  
  
  
                                 7-18
  ________________                                 ________________
  
  dsatm_parameters                                 dsatm_parameters
  ________________                                 ________________
  
  
       output_buf_size, obs
            size of the internal buffer used for outputting data on the
            screen.
            A value of 0 turns off the buffering, and increases
            significantly the response time.
  
       output_buf_timeout, obt
            after this time the internal output buffer is flushed,
            even if it is not full.
  
       read_echo_timeout, ret
           number of tenths of second the frontend will wait before
           sending characters in read_echo mode to the application.
       read_echo_char_count, recc
           number of characters the frontend will wait in his input
           buffer before sending the characters to the host in
           read_echo mode.
       read_necho_timeout, rnt
           number of tenths of seconds the frontend will wait before
           sending the characters in read_non_echo mode to the
           application.
           (Used when inserting characters in a line in video mode.)
       read_necho_char_count, rncc
           number of characters the frontend will wait to receive in
           the input buffer before sending the characters to the host
           in read_non_echo mode (Used when inserting characters in a
           line in video mode).
  
       read_8bit_timeout, r8t
       read_8bit_char_count, r8cc
           These two arguments are used as ret and recc in an 8 bits
           mode.
  
  Examples:
  
      tmparm -dlog -tr data,stc
          sets on the trace_data and trace_stc bit in dsatm_data_, and
          delete the standard log ([hd]>DSA_TM.trclog).
  
      tmparm -prtu
          displays the tuning parameters in use.
  
  
  
  
  
  
  
  
  
  
                                 7-19
  
  Entry: ttt_info_$dsatm_device
  
       This entry point retrieves DSA-specific information from the
  TTF.
  
  
  USAGE
  
  dcl ttt_info_$dsatm_device entry (char (*), ptr, ptr, fixed_bin
       (35));
  
  call ttt_info_$dsatm_device entry (terminal_type, area_ptr,
       dsatm_dev_ptr, code);
  
  
  ARGUMENTS
  
  terminal_type
       is the terminal type name as specified in the TTF.  (Input)
  
  area_ptr
       points to an area where  the dsatm_device info structure can
       be allocated.  (Input)
  
  dsatm_dev_ptr
       points to the dsatm_device structure allocated by this entry
       point.   (Output) The structure  is declared in  the include
       file dsatm_negotiate_info.incl.pl1, described below.
  
  code
       is a standard system status code.  (Output)
  
  
  DATA STRUCTURE
  
       The data structure allocated by  this routine is declared in
  the  include file  dsatm_negotiate_info.incl.pl1, which  is shown
  below:
  
  dcl  1 dsatm_device                  based (dsatmdevp) aligned,
         2 init_accept_confg           fixed bin,
         2 dpp                         (4) fixed bin,
         2 sdp_dpp,                    /* sdp protocol */
           3 version                   fixed bin,
           3 sdp_class                 (4) fixed bin,
         2 real_dpp,                   /* real protocol */
           3 version                   fixed bin,
           3 real_class                (16) fixed bin,
           3 real_model                char (12) var,
         2 trans_dpp,                  /* transparent protocol */
           3 version                   fixed bin,
         2 dev_id                      fixed bin (16) uns,
         2 dev_type                    fixed bin,
         2 attribute,
  
  
                                 7-20
  
           3 shareability              fixed bin,
           3 alloc_unit                bit (8),
         2 line_length                 fixed bin (8) uns,
         2 page_length                 fixed bin (8) uns,
         2 line_overflow               fixed bin,
         2 page_overflow               fixed bin,
         2 char_encoding               (8) fixed bin,
         2 char_set                    (14) fixed bin,
         2 char_subset                 (4) fixed bin,
         2 nat_lang                    (4) fixed bin,
         2 compression                 (4) fixed bin,
         2 char_font                   (6) fixed bin,
         2 terminal_type               char (12) var,
         2 ete_ack_level               fixed bin,
         2 max_rec_size                fixed bin (16) uns,
         2 attentions                  like attention_fcn aligned,
         2 stc_available               bit (1),
         2 repetitive_parm_nb,
           3 dpp_nb                    fixed bin,
           3 sc_nb                     fixed bin,
           3 rc_nb                     fixed bin,
           3 ce_nb                     fixed bin,
           3 cs_nb                     fixed bin,
           3 css_nb                    fixed bin,
           3 cf_nb                     fixed bin,
           3 nl_nb                     fixed bin,
           3 ca_nb                     fixed bin,
         2 parm_rejected,
           3 dpp_rejected              bit (1) unal,
           3 attr_rejected             bit (1) unal,
           3 ce_rejected               bit (1) unal,
           3 cs_rejected               bit (1) unal,
           3 css_rejected              bit (1) unal,
           3 cf_rejected               bit (1) unal,
           3 nl_rejected               bit (1) unal,
           3 ca_rejected               bit (1) unal,
           3 mrs_rejected              bit (1) unal;
  
  code is the standard system error code.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 7-21
  
  _U_S_I_N_G _E_M_A_C_S
  
       If you connect to Multics by  means of the DSA network, then
  in order to use Emacs, you must also use the "video system."  The
  video  system  is  an  extension  to  the  Multics communications
  facilities which  provides for terminal input/output  support and
  offers  access   to  such  features  as   real-time  editing  and
  "windowing"  (the  ability  to  divide  the  screen into separate
  areas).
  
  
       Interactive  terminals  are  normally  connected  to Multics
  through  the tty_  I/O module.    To use  the video  system, your
  terminal must be connected to  Multics through the window_io_ I/O
  module.  Once  you are logged in  to Multics, you can  attach the
  video system to your terminal by entering the following command:
  
       window_call invoke
  
  With the execution of this  command, the standard tty_ attachment
  will be replaced with the  window_io_ attachment and the terminal
  will be supported with the Multics video system software.
  
  
       To restore the standard tty_ attachment, enter the following
  command:
  
       window_call revoke
  
       The  window_call  command  contains  many  other options for
  management  of terminal  input/output.  See  the _M_u_l_t_i_c_s _C_o_m_m_a_n_d_s
  _a_n_d  _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s  manual (Order  No.  AG92)  for a  complete
  description of the window_call command.
  
  
       With video the  last character of the screen  will stay with
  the cursor on the character.
  
       Without video the last character  of the screen will move to
  the next line.
  
  See the  _M_u_l_t_i_c_s _P_r_o_g_r_a_m_m_e_r'_s _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l  (Order No.  AG91)
  for additional information on the video System.
  
  
  _A_C_T_I_V_E _C_O_N_N_E_C_T_I_O_N _L_I_S_T _T_A_B_L_E
  
       A  new table  has been  created to  store the  names of  DSA
  connections currently active on Multics.  It is called the Active
  Connection List.   The following command displays  entries in the
  table.
  
  
  
  
  
                                 7-22
  
  NAME: DISPLAY_CONNECTION_LIST
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  display_connection_list {-control_arg}
  
  _F_U_N_C_T_I_O_N
  
  This  command displays entries  in the connection  list.  Network
  administrators can use it  to list network connections associated
  with  a  process,  or  to  display  detailed  information about a
  particular connection.
  
  _C_O_N_T_R_O_L _A_R_G_U_M_E_N_T_S
  
  -brief, -bf
     prints brief information in tabular form.  (Default)
  
  -channel CHN, -chn CHN
     selects entries whose connection channel name matches the star
     name CHN.
  
  -long, -lg
     prints detailed information about selected entries.
  
  -offset LOC, -ofs LOC, -at LOC
     prints  the  entry  located  at   offset  LOC  in  the  active
     connection   list.     These   offsets   are    displayed   by
     display_connect_list -brief.
  
  -owner GROUP_ID
     selects  entries owned  by  a  process matching  GROUP_ID.  In
     general,  the  Login_Server  is   the  owner  of  all  network
     connections.  See Notes below for the format of GROUP_ID.
  
  -owner_id PROCESS_ID
     selects entries  owned by the  process having the  given octal
     PROCESS_ID.
  
  -user GROUP_ID
     selects  entries  used  by  a  process  matching  GROUP_ID.  A
     connection  is in  use when  it is  logged into  a process  or
     dialed  to  a  process.   See  Notes  below  for the format of
     GROUP_ID.
  
  -user_id PROCESS_ID,
  -process_id PROCESS_ID,
  -pid PROCESS_ID
     selects  entries used  by the  process having  the given octal
     PROCESS_ID.
  
  
  
  
  
  
                                 7-23_______________________                   _______________________
  
  display_connection_list                   display_connection_list
  _______________________                   _______________________
  
  
  _A_C_C_E_S_S _R_E_Q_U_I_R_E_D
  
  Access to the hpriv_connection_list_ gate is required to use this
  command.
  
  _N_O_T_E_S
  
  All entries are displayed if no selection arguments are given.
  
  The  -user and  -owner GROUP_ID  operand is  given in  one of the
  following formats:
  
            person_id.project_id.tag
            person_id.project_id
            person_id
  
  where  any  of  the  components  can  be  omitted  or given as an
  asterisk (*) to match all values in that component position.
  
  _E_X_A_M_P_L_E_S
  The following example shows the tabular form of brief output.
  
  ! display_connection_list
  
    AT   CONNECTION     NET  USAGE     USER                  PROCESS ID
    210  dsa.MUL1.0002  DSA  endpoint  Login_Server.Daemon.z 004300021607
     66  dsa.MUL1.0088  DSA  login     Brunelle.SysAdmin.a   005100021710
    332  dsa.MUL1.0066  DSA  dial-in   GDixon.SysAdmin.a     005000021707
    454  dsa.MUL1.0070  DSA  endpoint  Login_Server.Daemon.z 004300021607
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 7-24_______________________                   _______________________
  
  display_connection_list                   display_connection_list
  _______________________                   _______________________
  
  
  The following example shows the itemized form of long output.
  
  ! display_connection_list -user .SysAdmin -lg
  
    Offset:              000066                  Usage:  1 (login)
    Connection name:     dsa.MUL1.0088             Net:  DSA
    Connection handle:   001527000020
    User name:           Brunelle.SysAdmin.a       PID:  005100021710
    Owner name:          Login_Server.Daemon.z     PID:  004300021607
    Initializer handle:  000001000002115412724145
    Terminate event chn: 327513360274440000000115
    Disconnect entry:    dsa_session_admin_$terminate_force
    Accounting entry:    dsa_session_admin_$accounting_force
  
    Offset:              000332                  Usage:  2 (dial-in)
    Connection name:     dsa.MUL1.0066             Net:  DSA
    Connection handle:   004445000015
    User name:           GDixon.SysAdmin.a         PID:  005000021707
    Owner name:          Login_Server.Daemon.z     PID:  004300021607
    Initializer handle:  000001000003115412725322
    Terminate event chn: 327516062576440000000122
    Disconnect entry:    dsa_session_admin_$terminate_force
    Accounting entry:    dsa_session_admin_$accounting_force
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _B_L_A_S_T _A_N_D _I_N_A_C_T_I_V_I_T_Y _M_E_C_H_A_N_I_S_M_S
  
       The warn  facility has been changed to  allow blast messages
  to  work correctly  over DSA  channels.  The  bump-for-inactivity
  feature has been changed to work  correctly with the new style of
  blast messages.   A new tty_ control order,  described earlier in
  this  section,  and  a  new  IPS  signal,  described next in this
  section, have been added to support the new mechanisms.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 7-25
  
  _S_E_N_D_I_N_G _A_N_S_W_E_R_I_N_G _S_E_R_V_I_C_E _M_E_S_S_A_G_E_S _V_I_A _A _N_E_W _I_P_S _S_I_G_N_A_L
  
       A new Multics IPS signal, system_message_, has been added to
  support operations in the DSA environment.  The answering service
  sends a message  (e.g., warn, bump) to a user  process by placing
  the message in a message  segment and sending the system_message_
  IPS signal to the user.  The  handler for the new signal picks up
  the  message and  prints it;  this method  preserves the terminal
  environment for the user.
  
  
       The new system_message_ IPS signal is an addition to the IPS
  signals   defined  for    the  set_ips_mask,   get_ips_mask,  and
  reset_ips_mask  commands described  in the  _M_u_l_t_i_c_s _C_o_m_m_a_n_d_s  _a_n_d
  _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s manual (Order No.  AG92).
  
  
  _N_E_W _T_Y_P_E _O_F _I_P_C _E_V_E_N_T _C_H_A_N_N_E_L
  
       A new  type of Multics  IPC event channel,  the asynchronous
  call event channel,  has been added to support  operations in the
  DSA  environment.  This  channel is  just like  the current  call
  event  channel except  that sending  a wakeup  on an asynchronous
  call event channel (using hcs_$wakeup) sends an IPS "wkp_" signal
  to  the  destination  process  as  well  as  sending a normal IPC
  wakeup.  The IPS signal causes  the handler for the "wkp_" signal
  to  be invoked in  the destination process  immediately (assuming
  the  "wkp_" signal  is not  masked), regardless  of the  process'
  state with  respect to IPC.   The default handler  for the "wkp_"
  IPS signal,  wkp_signal_handler_, can then look  through the list
  of asynchronous  call event channels and cause  the handlers (for
  any with pending  IPC wakeups) to be run.  These  handlers can be
  invoked whether or not the owning process is blocked.
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _L_O_G_G_I_N_G _C_O_M_M_A_N_D_S
  
       There are three new system logs for DSA:  the DSA system log
  (dsa_sl), the DSA  system AEP log (dsa_sal), and the  DSA AEP log
  (dsa_al).  The DSA system log and the DSA system AEP log are ring
  2 logs, so  new control arguments have been added  to the logging
  commands which  allow you to print, monitor,  and summarize these
  new  logs.  The  DSA AEP  log is  a ring  4 log,  so the  logging
  commands can  be used to  manipulate it simply  by providing them
  with the pathname of this new log.
  
  
  
  
  
  
  
  
  
  
  
                                 7-26
  
  _N_e_w _C_o_n_t_r_o_l _A_r_g_u_m_e_n_t_s _f_o_r _t_h_e _L_o_g_g_i_n_g _C_o_m_m_a_n_d_s
  
       The following  new control arguments have been  added to the
  print_sys_log, and summarize_sys_log commands:
  
  -dsa_sys_log, -dsasl
       specifies that  the DSA system  log is to  be examined.  The
       location  of this log  is specified in  the Mna_general_info
       object  definition  in  the  NIT.   The  normal  location is
       >site>dsa>system_logs_dir>dsa_sl.  This is a ring 2 log; the
       user  must have  access to  dsa_log_admin_gate_ to  read it.
       This  control argument  is incompatible  with any  other log
       selection control argument or an explicit log pathname.
  
  -dsa_sys_aep_log, -dsasal
       specifies  that the DSA  system AEP log  is to be  examined.
       The   location   of   this   log   is   specified   in   the
       Mna_general_info object  definition in the NIT.   The normal
       location  is >site>dsa>system_logs_dir>dsa_sal.   This is  a
       ring 2 log; the user must have access to dsa_admin_log_gate_
       to read it.  This control  argument is incompatible with any
       other  log selection  control  argument  or an  explicit log
       pathname.
  
  Complete descriptions of  the print_sys_log, monitor_sys_log, and
  summarize_sys_log   commands  are    available  in   the  _M_u_l_t_i_c_s
  _A_d_m_i_n_i_s_t_r_a_t_i_o_n,  _M_a_i_n_t_e_n_a_n_c_e,  _a_n_d  _O_p_e_r_a_t_i_o_n_s  _C_o_m_m_a_n_d_s  manual,
  Order No.  GB64.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 7-27
  
  
  
  
  
  
  
  
  
                              SECTION 8
  
  
                    CHANGES THAT AFFECT OPERATORS
  
  
  
  
       This  section describes  changes that  affect operators.  It
  contains material covering the following topics:
  
       ox    Changes to the login command
  
       ox    Changes to various initializer commands
  
       ox    A  new procedure  for preaccepting  message coordinator
            terminals through the DSA network
  
  
  _C_H_A_N_G_E_S _T_O _T_H_E _l_o_g_i_n _C_O_M_M_A_N_D
  
       Two additional  control arguments can  now be used  with the
  login  command.   The  new  control  arguments  are -operator and
  -vchannel.
  
  
  -operator, -op
     specifies  that the  terminal the  operator is  logging in  on
     should  be authenticated  for operator  or message coordinator
     use.   The operator  must use  the accept  initializer command
     (from another  terminal which has already  been authenticated)
     to  approve this request.   If the -vchannel  control argument
     (described  below) is  also  used,  and the  specified virtual
     channel  has been  preaccepted, the  request is  automatically
     accepted.     The   vchn_requires_accept   keyword    in   the
     installation_parms  segment may  be used  to require  a manual
     "accept"   by  a   validated  operator   whenever  the  "login
     -operator"  command  is  issued  by  someone  other  than  the
     operator  signed on  at the  bootload console.   The -operator
     control argument also eliminates the  need for the operator to
     use  a subsequent  sign_on initializer  command.  The operator
     must  have the  "operator" attribute   in the  PNT to  use the
     -operator control argument.
  
  
  
  
  
                                 8-1
  
  
  
  -vchannel STR, -vchn STR
     identifies the virtual channel specified  by STR as the one to
     be used to connect the  terminal to Multics.  For example, the
     command line below specifies that the virtual channel vchn1 is
     to be  associated with the terminal the  operator is currently
     logging in on.
  
        l Smith -op -vchn vchn1
  
     The  -operator  control  argument  (described  above)  must be
     specified  or  the  -vchannel  control  argument  will  not be
     accepted.
  
  
       These  new control arguments  support the new  procedure for
  preaccepting  message  coordinator   terminals  through  the  DSA
  network.   See   "Preaccepting  Terminals  Associated   With  DSA
  Channels" later in this section for additional information on the
  use  of the  -operator and  -vchannel control  arguments.  For  a
  complete description  of the login command, refer  to the _M_u_l_t_i_c_s
  _C_o_m_m_a_n_d_s _a_n_d _A_c_t_i_v_e _F_u_n_c_t_i_o_n_s manual, Order No.  AG92.
  
  
  _C_H_A_N_G_E_S _T_O _V_A_R_I_O_U_S _I_N_I_T_I_A_L_I_Z_E_R _C_O_M_M_A_N_D_S
  
       The Multics operator  has available a set of  commands to be
  used  when  communicating  with  the  initializer process.  These
  commands  are  described  in  Section  4  of  the _A_d_m_i_n_i_s_t_r_a_t_i_o_n,
  _M_a_i_n_t_e_n_a_n_c_e,  _a_n_d  _O_p_e_r_a_t_i_o_n_s  _C_o_m_m_a_n_d_s  manual.   Most  of these
  commands  specify  activities  that  pertain  only  to  the local
  Multics  installation;  they  do  not  affect network operations.
  Some  of them,  however, are  used to  route message  traffic, to
  control the  assignment of communications channels,  or to affect
  user processes.  In these cases,  if the communications links are
  through  the  DSA  network,  the  standard  operator interface is
  changed.  Additionally, there is a new procedure for preaccepting
  message coordinator terminals through the DSA network.
  
  
       The information  below describes the function  and syntax of
  various  initializer  commands  when  the  target entity (message
  destination,  communications  channel,  process)  is  owned  by a
  remote user who has connected  to Multics through a DSA endpoint.
  Note that the  material below is designed as a  supplement to the
  more  complete  description  of  initializer  commands  found  in
  Section  4  of  the  _A_d_m_i_n_i_s_t_r_a_t_i_o_n,  _M_a_i_n_t_e_n_a_n_c_e, _a_n_d _O_p_e_r_a_t_i_o_n_s
  _C_o_m_m_a_n_d_s manual.
  
  
  
  
  
  
  
                                 8-2
  
  
  
  _a_t_t_a_c_h _a_n_d _r_e_m_o_v_e _C_o_m_m_a_n_d_s
  
       The attach  and remove operator  commands have no  effect on
  communications  channels  assigned  as  part  of  a  DSA  network
  connection.   Such  channels  are  managed  by  the network login
  server daemon.  See  Section 3 of this manual  for information on
  the network login server daemon.
  
  
  _P_r_o_c_e_s_s _M_a_n_i_p_u_l_a_t_i_o_n _C_o_m_m_a_n_d_s
  
       The  initializer  commands   used  to  manipulate  processes
  include  bump, detach,  disconnect, terminate,  and unbump.   The
  syntax  of these  commands permits  the operator  to specify  the
  "target" of the action in any one of the following ways:
  
       ox    Person_id.Project_id
  
       ox    channel_id
  
       ox    mpx mpx_name
  
       ox    -pid process_id
  
  
       Use of  the Person_id.Project_id and mpx  mpx_name arguments
  has  not changed.   (Note, however,   that use  of the  Person_id
  Project_id  argument   is  no  longer  accepted.)    Use  of  the
  channel_id argument  has changed in the  following situation:  if
  the  operator wants  to specify  that the  action is  to affect a
  channel  assigned  as  part  of  a  DSA  network  connection, the
  channel_id  argument must  be specified  in the  format described
  below.
  
  channel_id
     must be a DSA channel_id in the following form:
  
        dsa.<session_control_name>.<dsa_channel>
  
     where:
  
     session_control_name
        is the local  name of the session control.   This name must
        be  the same  as that  specified by  the session  control's
        Sc_loc object definition in the NIT.
  
     dsa_channel
        is  the  name  of  the  DSA  communications  channel  to be
        affected.
  
  
  
  
  
                                 8-3
  
  
  
     The following is an example of a valid DSA channel_id:
  
        dsa.MUL1.0021
  
  
       Use  of  the  -pid   process_id  control  argument  is  new;
  process_id is the first six  digits of the process_id.  Note that
  the  as_who command  now accepts   the -pid  control argument  to
  display the first six digits of the process_id.
  
  
  _a_c_c_e_p_t _C_o_m_m_a_n_d
  
       The accept command can be  used to affect a channel assigned
  as part of a DSA network connection.  The DSA channel_id argument
  must  be specified  as described  above for  process manipulation
  commands.
  
  
       The capability to specify that  a DSA channel_id can be used
  with  the accept  command is  useful for  those circumstances  in
  which the  DSA channel_id is known  to the operator.  In  the DSA
  environment,   however,  communications  channels   are  assigned
  dynamically.   DSA  channel  identifiers  cannot  be preassigned.
  Thus, the accept  command cannot be used to  preaccept a terminal
  device that has connected to Multics by means of the DSA network.
  Instead, the  accept_vchn command must  be used to  preaccept the
  device.   See the description  of the accept_vchn  command below,
  and "Preaccepting  Terminals Associated With DSA  Channels" later
  in this section, for additional information.
  
  
  _d_r_o_p _C_o_m_m_a_n_d
  
       The   drop  command   has   been   changed  to   accept  the
  specification of either a DSA  channel_id (as described above for
  process manipulation commands) or a virtual channel (as described
  below for  the accept_vchn command).   When a virtual  channel is
  dropped, it is disassociated from  all virtual consoles, and must
  be accepted again before it can be reused.  The operator may also
  drop  the  "real"  channel  associated  with  a  virtual channel.
  Output to the virtual channel will continue to be queued up until
  another connection to it is made using the login command with the
  -operator and -vchannel control arguments.
  
  
  
  
  
  
  
  
  
  
                                 8-4
  
  
  
  _i_n_t_e_r_c_o_m _C_o_m_m_a_n_d
  
       The  intercom  command  has   been  changed  to  accept  the
  specification of either a DSA  channel_id (as described above for
  process manipulation commands) or a virtual channel (as described
  below for  the accept_vchn command).  This allows  an operator to
  send a message to another operator  logged in over either kind of
  channel.
  
  
  _s_u_b_s_t_t_y _C_o_m_m_a_n_d
  
       The  substty   command  has  been  changed   to  accept  the
  specification of either a DSA  channel_id (as described above for
  process manipulation commands) or a virtual channel (as described
  below for the accept_vchn command).  The virtual channel which is
  dropped is  disassociated from all  virtual consoles and  must be
  accepted again before it can be reused.
  
  
  _d_e_f_i_n_e_, _r_e_d_e_f_i_n_e_, _a_n_d _u_n_d_e_f_i_n_e _C_o_m_m_a_n_d_s
  
       The  define,  redefine,  and  undefine  commands  have  been
  changed to  accept the specification  of either a  DSA channel_id
  (as  specified  above  for  process  manipulation  commands) or a
  virtual channel (as described below for the accept_vchn command).
  These commands  reject the "real" channel name  associated with a
  virtual channel.
  
  
  _a_c_c_e_p_t___v_c_h_n _C_o_m_m_a_n_d
  
       The  accept_vchn command  is  a  new command  implemented to
  support the capability to preaccept message coordinator terminals
  through the DSA network for  the purpose of rerouting the message
  coordinator output traffic.  The command is similar in syntax and
  functionality to the initializer  accept command.  The difference
  is  that the  accept_vchn command  is used  to preaccept terminal
  device  channels  that  are  virtual  channels,  while the accept
  command is  used to accept  terminal device channels  with "real"
  channel identifiers.
  
  
       The syntax of the accept_vchn command is defined below.  See
  also "Preaccepting Terminals Associated  With DSA Channels" below
  for additional information on the use of the accept_vchn command.
  
  
  
  
  
  
  
  
                                 8-5
  ___________                                           ___________
  
  accept_vchn                                           accept_vchn
  ___________                                           ___________
  
  
  NAME: ACCEPT_VCHN
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  accept_vchn    virtual_channel_name   {authorization}    {target}
     {bc_list}
  
  _F_U_N_C_T_I_O_N
  
  accepts a virtual terminal device  channel and connects it to the
  message coordinator's  device complement.  This command  can only
  be used in ring 4.
  
  _A_R_G_U_M_E_N_T_S
  
  virtual_channel_name
     is the  name of a virtual  channel.  The name can  be up to 32
     characters  long.   It  cannot   include  periods  (.).   This
     argument cannot  be set to  "otw_" because "otw_"  is reserved
     for the bootload console.
  
  _A_R_G_U_M_E_N_T_S
  
  authorization
     specifies the  authorization which should be  assigned to this
     virtual channel.  It must be one of the following:
  
     full
        the device is able to issue all initializer commands.  This
        is the default.
  
     none
        no commands are allowed.
  
     reply
        only the reply command is allowed.
  
     query
        only the who and hmu commands are allowed.
  
     daemon
        only the reply, intercom, and exec commands are allowed.
  
  bc_list
     specifies  that a  broadcast list  should be  used.  This list
     identifies  channels to  which will  be sent  copies of  input
     entered at the  terminal associated with virtual_channel_name.
     If  the bc_list  argument is   set to  a broadcast  list, both
     virtual  channels  and  DSA  channel_ids  can  be  used.  Each
  
  
                                 8-6
  ___________                                           ___________
  
  accept_vchn                                           accept_vchn
  ___________                                           ___________
  
  
     channel name can be up to  32 characters in length.  Up to ten
     channel names  can be specified, separated by  commas.  If the
     bc_list argument is set to  "none", the current broadcast list
     is  cleared.  If  the bc_list  argument is  not specified, the
     broadcast   list  previously    specified  (if   any)  remains
     unchanged.
  
  target
     specifies  the source  name  identifying  the daemon  to which
     reply commands  will be directed.   This argument is  used for
     terminals  dedicated to  the control  of a  single I/O daemon.
     The default name is *.
  
  _E_X_A_M_P_L_E_S
  
  The example below specifies that  operator commands to the backup
  daemon  can be  submitted from  the terminal  associated with the
  virtual channel vchn1.
  
     accept_vchn vchn1 reply bk
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 8-7
  
  
  _P_R_E_A_C_C_E_P_T_I_N_G _T_E_R_M_I_N_A_L_S _A_S_S_O_C_I_A_T_E_D _W_I_T_H _D_S_A _C_H_A_N_N_E_L_S
  
       In the  standard Multics environment, the  configuration and
  characteristics  of communications  channels are  defined by  the
  system administrator in the channel definition table (CDT).  With
  such  knowledge of the  physical configuration, the  operator can
  preaccept  terminals   for  the  purpose  of   rerouting  message
  coordinator channels by specifying  (via the appropriate operator
  commands) the physical channel name (e.g., a.h102).
  
  
       In the DSA environment, however, communications channels are
  assigned   dynamically.   DSA   channel  identifiers   cannot  be
  preassigned.  Thus, in order to permit preacceptance of terminals
  for message  routing, a new procedure has  been implemented.  The
  new  procedure includes  the introduction  of "virtual channels",
  the use  of a new command  (accept_vchn), and the use  of two new
  control arguments to the login command (-operator and -vchannel).
  All of these are described above.
  
  
       To  preaccept terminals  associated with  DSA channels,  the
  operator must use the following procedure:
  
  1.   Use the  new accept_vchn command  to specify that  a virtual
       channel is to be used  to carry message coordinator traffic.
       The  accept_vchn command line  in the example  below "tells"
       the message coordinator that the virtual channel vchn1 is an
       appropriate  channel for  message coordinator  traffic.  (It
       also  limits  input  messages  from  the  terminal  to those
       necessary to reply to the backup daemon.)
  
            accept_vchn vchn1 reply bk
  
  2.   Use the initializer define  command to associate the virtual
       channel  you specified  via the  accept_vchn command  with a
       virtual terminal, as in the following example:
  
            define VC1 vchn1
  
  3.   Use   the  initializer   route  command   to  route  message
       coordinator traffic to the  virtual terminal associated with
       the virtual  channel.  The following example  routes message
       traffic from the backup daemon to the virtual terminal VC1:
  
            route bk user_output VC1
  
  4.   Login at any terminal using the new control arguments to the
       login  command  -operator  and  -vchannel.   Use  of the new
       -vchannel control argument  identifies the physical terminal
       in  use as  the terminal   to be  associated with  the named
       virtual  channel and  completes the  assignment loop  formed
       with the accept_vchn, define, and route commands.  The login
  
  
                                 8-8
  
  
       command is used to request a message coordinator process, as
       opposed to a normal user process.  Because the Person_id and
       password  are   checked  by  the  answering   service,  only
       authorized users may gain access to the message coordinator.
       The "operator" attribute in the PNT is required for any user
       who attempts  to login in  this way.  The  following example
       illustrates use of the login command:
  
            login Smith -operator -vchannel vchn1
  
       Note  that the first  three steps of  this procedure may  be
       done by the system administrator in the system_start_up.ec.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 8-9
  
  
  
  
  
  
  
  
  
                              SECTION 9
  
  
                 IMPLEMENTATION OF NEW EXEC COMMANDS
  
  
  
  
       All  following  "exec"  commands   are  located  inside  the
  admin.ec extension named admin_dsa.ec.  If this extension has not
  been used,  it is necessary to  modify some lines in  admin.ec in
  order to  find commands in the extension.   (See Modifications of
  European standard admin.ec located at the end of this section for
  details.)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-1
  
  
  
  
  
  
  
  
  
                              SECTION 9
  
  
                   SPECIFIC DSA HIERARCHY STRUCTURE
  
  
  
  
  >sl3p>dsa>source
           >object
           >include
           >info
           >exec_coms
           >execution
           >models
           >cref
           >info >dadd
                 >run_dsac_daemon
                 >login_server_info
                 >login_info
                 >dssr
                 >cxi_input_daemon
                 >connect_info
  
                               Data bases hierarchy
                               --------------------
  
  >site>dsa
         |-- nit
         |
         >uft_logs_dir
         |       +-- r_log, s_log
         |
         >aep_logs_dir
         |       +-- dsa_sl
         |
         |
         >system_logs_dir
         |       +-- dsa_sl, dsa_sal
         |
         >c1m4
         |   +-- >sys
         |          +-- P(0 1 2 3 4)FW640, DNS modules, IMAMEM.i  <-----+
         |                                                              |
         >data                                                          |
         |   +-- lc_data, sc_info, cxi_driver_seg, uft.value            |
  
  
                                 9-1
  
  
  
         |       dsa_sc_hm_seg, active_connection_list                  |
         |                                                              |
         >frontend_dir_dir                                              |
         |   |                                                          |
         |   >dn7c                                                      |
         |   |   |-- config, imamem.i, dn7c.value, various maps, LINKS -+
         |   |   +-- final_image.i, dumps                               |
         |   |                                                          |
         |   >dn7x                                                      |
         |   .   |-- config, imamem.i, dn7x.value, various maps, LINKS _|
         |   .   +-- final_image.i, dumps
         |   .
         |
         >acs
            |-- (Echo, Admin, Admin_correspondent, Login, UFT).acs
            +-- (uft_correspondent, correspondent, Systems).acs
  
  
  
  _D_Y_N_A_M_I_C _E_N_V_I_R_O_N_M_E_N_T _B_U_I_L_T _I_N _F_R_O_N_T_E_N_D___W_O_R_K_I_N_G___D_I_R
  
       In  order to  build an  image, the  frontend generator needs
  source dns files  previously restored (for the last  time) into a
  specific release  directory.  Since some of them  must be renamed
  according  to various  criteria (remote/local  generation), links
  are  dynamically  built  according  to  control_arguments  of the
  generation command, thus avoiding copying files and keeping their
  relative pathnames syntax inside file "config".
  
  List of links built for a generation c1m4 at level fw640:
  
  Links = 13.
  
  PATCH4                            >site>dsa>c1m4>sys>P4FW640
    PATCH4.a
  PATCH3                            >site>dsa>c1m4>sys>P3FW640
    PATCH3.a
  PATCH2                            >site>dsa>c1m4>sys>P2FW640
    PATCH2.a
  PATCH1                            >site>dsa>c1m4>sys>P1FW640
    PATCH1.a
  PATCH0                            >site>dsa>c1m4>sys>P0FW640
    PATCH0.a
  IMAMEM                            >site>dsa>c1m4>sys>IMAMEM
    IMAMEM.i
  DLCMSF                            >site>dsa>c1m4>sys>DLCMSF
    DLCMSF.a
  DLCKW                             >site>dsa>c1m4>sys>DLCKW
    DLCKW.a
  YTABLE                            >site>dsa>c1m4>sys>YTABLE
  CHXMOD                            >site>dsa>c1m4>sys>CHXMOD
  
  
  
                                 9-2
  
  
  
    CHXMOD.a
  TASY                              >site>dsa>c1m4>sys>TASY
  TMCK                              >site>dsa>c1m4>sys>TMCK
  sys                               >site>dsa>c1m4>sys
  
  _N_O_T_E_S
  
  Datanet dedicated file "config" is written with dns syntax.  Note
  that  the  only  parameter   concerning  multics  syntax  is  DIR
  described as "sys>".
  
  Names of patch sets located inside the release directory must use
  the following syntax  "PxFWyww", where x is the set  number 0, 1,
  2, 3, 4; y is the last digit of year; and ww is the fiscal week.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-3
  __________                                             __________
  
  gen_dn7.ec                                             gen_dn7.ec
  __________                                             __________
  
  
  NAME: GEN_DN7.EC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec gen_dn7 <target_datanet_tag> {-args}
  
  _F_U_N_C_T_I_O_N
  
  This  command  performs  generation  of  a  loadable and runnable
  frontend image to be used by the specified datanet.
  
  _A_R_G_U_M_E_N_T_S
  
  -by <generator_datanet_tag>
     specifies the  datanet in charge of generating  a final image.
     Default is target datanet.
  
  -fiscal_week,-fw <YWW>
     specifies  a  level  for   patches  to  be  applied.   Remains
     unchanged until another fiscal week is specified.
  
  -force,-fc
     interrupts all  activity on frontend in  charge of generation.
     Users are disconnected.
  
  -no_start,-nost
     do   not   start   frontend   after   successfully  completing
     generation.
  
  -patch3,-p3
     gives a  "short" generation.  In  fact, you only  apply PATCH3
     file  to an intermediary  image which must  be present in  the
     frontend_working_dir of target datanet.  (See notes below.)
  
  -release,-rl <release>
     specifies  DNS  release  to  be  used  for  current and future
     generations  Remains   unchanged  until  another   release  is
     specified.
  
  -save,-sv <image_path>
     specifies the pathname of  the resultant final image.  Default
     is   segment  "final_image.i"    located  in   target  datanet
     frontend_working_dir.
  
  -trace , -ts
     includes the files TMCK and  TASY (patch files for tracing DNS
     software).  The default is to exclude these two files
  
  
  
  
                                 9-4
  __________                                             __________
  
  gen_dn7.ec                                             gen_dn7.ec
  __________                                             __________
  
  
  _N_O_T_E_S
  
  Source DNS files should have been restored from the specific GCOS
  tape into the  appropriate directory >site>dsa>{release_dir}>sys.
  The actual release is "c1m4" and must be specified at the initial
  generation for  each frontend.  The fiscal week  patch's level is
  640  and  must  be  specified  at  the  first generation for each
  frontend.
    Generation is performed in 3 steps :
       - Construct  of needed  environment in  frontend_working_dir
         according to  control arguments selected.  See  Appendix A
         for details.
       - Creation  of  intermediary  image  named  "imamem.i"  from
         source dns files,  datanet configuration, standard patches
         set PATCH0 PATCH1 PATCH2  and Multics specific patches set
         PATCH4.
       - From  imamem.i,  last  patches  set  PATCH3  is applied to
         produce  final image  named "final_image.i"  unless it  is
         specified  with  control  argument  "-save".   If argument
         "-patch3" is  specified in the command, only  this step is
         performed.
  
  Two maps are automatically created in the frontend_working_dir.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-5
  ____________                                         ____________
  
  start_dn7.ec                                         start_dn7.ec
  ____________                                         ____________
  
  
  NAME: START_DN7.EC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec start_dn7 <datanet_tag> {-ctrl_arguments}
  
  _F_U_N_C_T_I_O_N
  
  This command  makes the specified frontend  operational.  The DNS
  image should be  loaded, either from the host system  or from any
  remote site.
  
  _A_R_G_U_M_E_N_T_S
  
  -debug, -dbg
     runs subsystem debug  mode for a further analysis  of logs and
     various traces.
  
  -force, -fc
     starts datanet, even if users  are connected through it.  They
     will be disconnected.
  
  -load_on_abort, -ldab {<image_path>}
     will load the frontend after  an unsuccessful start order.  If
     present  without   <image_path>,  the  last   image  generated
     "final_image.i"    located    in     a    specified    datanet
     frontend_working_dir is loaded.   If present with <image_path>
     , specified image is loaded.
  
  -no_debug, -ndbg
     resets debug mode.  (Default)
  
  _N_O_T_E_S
  
  Debug  mode remains  "on"  until  another command  introduces the
  control argument "-no_debug".
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-6
  ___________                                           ___________
  
  load_dn7.ec                                           load_dn7.ec
  ___________                                           ___________
  
  
  NAME: LOAD_DN7.EC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec load_dn7 <datanet_tag> {-ctrl_args}
  
  _F_U_N_C_T_I_O_N
  
  This command loads the specified  frontend from host site with an
  existing DNS image, then starts the frontend.
  
  _A_R_G_U_M_E_N_T_S
  
  -debug, -dbg
     runs subsystem debug  mode for a further analysis  of logs and
     various traces.
  
  -force, -fc
     loads frontend, if users are connected through it they will be
     disconnected.
  
  -image, -im <image>
     introduces  pathname  of  image  to  be  loaded.   Default  is
     "final_image.i"   located   in    specified   target   datanet
     frontend_working_dir.
  
  -no_debug, -ndbg
     resets debug mode.  (Default)
  
  _N_O_T_E_S
  
  Debug  mode remains  "on"  until  another command  introduces the
  control argument "-no_debug".
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-7
  ___________                                           ___________
  
  stop_dn7.ec                                           stop_dn7.ec
  ___________                                           ___________
  
  
  NAME: STOP_DN7.EC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec stop_dn7 <datanet_tag>
  
  _F_U_N_C_T_I_O_N
  
  This command stops the specified frontend, leaving it unreachable
  from a host site.  All users are disconnected.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-8
  ___________                                           ___________
  
  dump_dn7.ec                                           dump_dn7.ec
  ___________                                           ___________
  
  
  NAME: DUMP_DN7.EC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec dump_dn7 <datanet_tag> {dump_args}
  
  _F_U_N_C_T_I_O_N
  
  This command  asks for a  total or partial  frontend memory dump,
  according to specified control arguments.
  
  _A_R_G_U_M_E_N_T_S
  
  All specified dump_args are transmitted to sub_system cxi_driver.
  Look at cxid "dump" command for more details.
  
  _N_O_T_E_S
  
  As  first dump_argument,  you can  specify pathname  of resultant
  dump.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-9
  _________                                               _________
  
  st_dn7.ec                                               st_dn7.ec
  _________                                               _________
  
  
  NAME: ST_DN7.EC
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec st_dn7 <datanet_tag>
  
  _F_U_N_C_T_I_O_N
  
  This command displays information about specified frontend.
  
  EXAMPLE
  
            FRONTEND             :   dn7b
            CHANNEL              :   diab  b  30.
            DRIVER STATE         :   started
            FRONTEND STATE       :   added,loaded,running
            FRONTEND_WORKING_DIR :   >site>dsa>fdd>dn7b
            DNS transport        :   dn7b_ts
            DNS release          :   c1m4
            DNS fiscal_week      :   FW640
            DNS image            :   >site>dsa>fdd>dn7b>final_image.i
            DEBUG mode           :   off
            Number of sessions   :   4
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-10
  _________                                               _________
  
  start_dsa                                               start_dsa
  _________                                               _________
  
  
  NAME: START_DSA
  
  _S_Y_N_T_A_X _A_S _A _C_O_M_M_A_N_D
  
  ec start_dsa {-args}
  
  _F_U_N_C_T_I_O_N
  
  This   command  entirely    initializes  DSA   session  (specific
  processes, data_bases).
  
  _A_R_G_U_M_E_N_T_S
  
  -force, -fc
     produces  an  automatic  logout  for  all  existing  processes
     related with DSA (Uft, DSA_CXI) before loging them again.
                      Modifications of European standard admin.ec
                      - - - - - - - - - - - - - - - - - - - - - -
  
     Lines to  add at the end  of admin.ec in order  to look for an
     extension
  
     &label BAD_X
     &label &1
     ec &ec_dir>admin_1 &rf1
     &quit
  
     Note  that you  need also   to modify  both command  "doc" and
     "help" in order to find informative headers.
  
  
  
                          Modifications of system_start_up.ec
                          - - - - - - - - - - - - - - - - - -
  
  
     line to add :    ec admin_1 start_dsa
  
  
     Routages (logs and messages) :
  
     sc_command define dn7b log dn7b
     sc_command define dn7c log dn7c
     sc_command define uft log uft
  
  
  
  
  
  
  
                                 9-11
  _________                                               _________
  
  start_dsa                                               start_dsa
  _________                                               _________
  
  
     sc_command route (dn7b dn7c uftr ufts) user_i/o bkc
     sc_command route (dn7b dn7c uftr ufts) error_i/o bkc
     sc_command route dn7b (user_i/o error_i/o log_i/o) dn7b
     sc_command route dn7c (user_i/o error_i/o log_i/o) dn7c
     sc_command route uftr (user_i/o error_i/o log_i/o) uft
     sc_command route ufts (user_i/o error_i/o log_i/o) uft
  
                             Modifications of crank.absin
                             - - - - - - - - - - - - - - -
  
  
     move_log_segments dn7c >sc1>as_logs history 1week
     move_log_segments dn7b >sc1>as_logs history 1week
     move_log_segments uft >sc1>as_logs history 1week
     move_log_segments dsa_al >site>dsa>aep_logs_dir history 1week
     move_log_segments (r s)_log  >site>dsa>uft_logs_dir history 1week
     lsdrb >site>dsa>system_logs_dir 7 7
     lsrb >site>dsa>system_logs_dir>** 4 4 4
     move_log_segments dsa_sal >site>dsa>system_logs_dir history 1week
     move_log_segments dsa_sl >site>dsa>system_logs_dir history 1week
     lsrb >site>dsa>system_logs_dir>** 2 2 2
     lsdrb >site>dsa>system_logs_dir 2 7
  
  
     date_deleter >sc1>comms 7 NIF.nif.? NIF.nif.?? NIF.nit.? NIF.nit.?? NIF.*.*.io
     date_deleter >site>dsa 7 nit.?
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 9-12
  
  
  
  
  
  
  
  
  
                              APPENDIX A
  
  
               MULTICS DSA PHASE 1 INSTALLATION PROCEDURE
  
  
  
  
  
  
  The  procedure  described  here  is  intended  for  use  by sites
  currently  running  the  MR12  release  (updated with bug_fixes).
  Steps 1 to  11 can be executed any time prior  to the shutdown of
  the system by a SysAdmin process.
  
  For reading commodity, we suppose we  have one DN7100 named "c" ,
  and each datanet dependent term is noted {c}. 
  =================================================================
                               STEP 1
  =================================================================
  
  
  Register special resource named dia{c} :
  
  cr >sc1>rcp>dia{c}.acs
  sa >sc1>rcp>dia{c}.acs rw DSA_CXI.Daemon -rp -nsd
  rgr special dia{c} -acs_path >sc1>rcp>dia{c}.acs -owner system
  
  Modify access of >sc1>rcp>workspace.acs.  Daemon DSA_CXI needs rw
  on it.
  
  sa >sc1>rcp>workspace.acs rw DSA_CXI.Daemon
  
  You  will have to  reload the Register  tape later with  the name
  DSA.    (identifier   PTY)   (owner:    "Retriever.SysDaemon"  or
  "system").
  
  =================================================================
                              STEP 2
  =================================================================
  
  Check Daemon project.   We have to register a ring  2 Daemon with
  5000 quota for its process_dir.
  
                    cwd >udd>sa>a
                    ec master edit_proj Daemon
  
  
                                 A-1
  
  
  
                    Minimum login ring :  2
                    Maximum pdir quota :  5000
  
  Register the following users:
  
  The  DSA_CXI in  Daemon project  must be  a ring  2 daemon,  with
  minimal attributes "multip, ^vinitproc, ^nostartup".
  
                    ec master register .....
                    ec master upmf Daemon DSA_CXI
                    ec master pmf Daemon
  
                        ->person_id:  DSA_CXI;
                        ->ring:  2,2;
                        ->attributes:igroup;
                        ->group:  IO;
  
  
  
                    an >udd>Daemon>DSA_CXI cxi
  
  
    UftS (in SysDaemon project)
  
                    ec master register ....
                    ec master upmf SysDaemon UftS
                    ec master pmf SysDaemon
  
                    ->person_id:  UftS;
                    ->initproc:>sl3p>dsa>e>dsa_uft_sds_overseer_;
                    ->group:  IO;
  
  -------------
  
        ADD access "re" at >t>pnt_login_gate_ for UftS.SysDaemon
  
                    sac hpsa >t>pnt_login_gate_ re UftS.SysDaemon
  
        CHECK acl of >doc
                     >doc>ss
                     >doc>ss>ssu_info_dirs :
  (DSA_CXI.Daemon must have "s" for   sub_system cid invocation).
  
  
  =================================================================
                            STEP 3
  =================================================================
  
  
  
  
  
  
  
                                 A-2
  
  
  
  >ddd>idd>iod_tables.iodt  must  be  modified  to  incorporate the
  following  new IO  requests used  by the  IO Daemon  working as a
  "requestor" for UFT.  Copy it  in your working_dir, modify with a
  text editor and install new table with install_table.ec.
  
  Lines to add :
                         Request_type:  dsa_uft;
                         generic_type:  dsa_uft;
                         driver_userid:  IO.SysDaemon;
                         default_queue:  3;
                         accounting:  nothing;
                         max_access_class:  system_high;
                         device:  uft;
  
                         Device:  uft;
                         driver_module:>sl3p>dsa>e>dsa_uft_driver_;
                         line:  *;
                         args:  " ";
                         default_type:  dsa_uft;
  
  
  Create  the  I/O  daemon  queues (ignore the warning about system
  
  
  high):
  
                         cdq iod_tables
  
  =================================================================
                             STEP 4
  =================================================================
  
  
  
  DSA programs take about 5000 quota  and data bases 4000.  You can
  create 2  master_dirs to keep  whole DSA programs  on a dedicated
  disk.  (not mandatory).
  
        cd >sl3p>dsa -lv LOGICAL_VOLUME -quota 5000
        sa >sl3p>dsa sma *.SysAdmin s * -rp
  
        cd >site>dsa -lv LOGICAL_VOLUME -quota 4000
        sa >site>dsa sma *.SysAdmin s * -rp
        an >site>dsa DSA
  
  =================================================================
                             STEP 5
  =================================================================
  
  
  
  Reload DSA tape :
  
  
                                 A-3
  
  
  
                  login Retriever SysDaemon rt
                  r rt backup_load -npri -nosetlvid -trim
                  r rt DSA,den=6250
  
  =================================================================
                              STEP 6
  =================================================================
  
  
  
  
  Create following  dirs with their short_names  and initial access
  list:  (Warning :  Special log sld must be in ring 2).
  
        cwd >site>dsa
        cd (aep system uft)_logs_dir
        an (aep system uft)_logs_dir (aep s u)ld
        sis (aep s d)ld rw * -rp -nsd
        lsdrb sld 2 7
  
        sa ([dirs *]) sma *.SysAdmin sma DSA_CXI.Daemon s * -rp
        an frontend_dir_dir fdd
  
        an data_segments data
        sa data sma * -rp -nsd
        sis data rew * -rp -nsd
  
  =================================================================
                            STEP 7
  =================================================================
  
  
  
  This step consists in DSA  hierarchy adjustment according to your
  datanet configuration.  You have to repeat it for each datanet.
  
  
  Create  frontend_working_dirs.   Delivered   directory  model  is
  >site>dsa>fdd>dn7x.
  
  Example for one DN7100 named "c" :
  
                 cwd >site>dsa>fdd
                 cd dn7{c}
                 copy_acl dn7x dn7{c}
                 copy_iacl_seg dn7x dn7{c}
                 cwd dn7{c}
                 cr dn7.value
                 cp >sl3p>dsa>mod>config  -nm
                            (to  keep  add_name config.a)
  
  
  
  
                                 A-4
  
  
  
  Update  config  with  your  preferred  text  editor  according to
  specific datanet configuration.
  
                 <update>.....
  
  
  Repeat same operations for others DN7100 if any. 
  =================================================================
                             STEP 8
  =================================================================
  
  
  
  
  
  
  Directory >sl3p>dsa>models  contains some updated tools  you have
  to install at their right place on your site :
  
         install_table.ec                     in >udd>sm>lib>ecs
         sldd_install_part2.ec                in >udd>sl>sldd_work>st
         admin_1.ec                           in >sc1
  
  Note :  update entry "init_dsa" in  admin_1.ec in order to log in
  as much DSA_CXI Daemon processes  as you have datanets configured
  in dsa mode.  You have just to repeat following line :
  
             ec &ec_dir>&ec_name start_dn7 {c} -ldab
  
  ---------------
  
  You  have  to  extend  system_search_rules  in  order  to explore
  >sl3p>dsa>e :
  
  If >sc1>site_rules does not exist :
  
     - create it from >sl3p>dsa>mod>site_rules.
     - add in >sc1>ssu.ec command line
  
                 set_system_search_rules >sc1>site_rules
  
  If >sc1>site_rules exists, just add in following line:
  
  >system_library_3rd_party>dsa>execution,default,system_libraries,io_daemon
  
  =================================================================
                             STEP 9
  =================================================================
  
  
  
  
  
  
                                 A-5
  
  
  
  This step  consists in incorporation  of all DSA  programs within
  system_search_path's (ec ,trans, info) and system libraries.
  
  Adjustment  of  standard  library  descriptor  to incorporate DSA
  library.  Look at a suggestion in
  
             >sl3p>dsa>models>multics_libraries_.ld .
  
  Adjustment  of system  default  search_path's.   (trans ,  ec and
  info)  >sldd>sss>s>search_lists_defaults_.cds is to  be modified.
  Look at
  
             >sl3p>dsa>models>search_list_defaults_.cds
  
  
  Any SysLib  process can perform installation of  these 2 programs
  using usual ways (wd in >udd>sl>sldd_work):
  
             ec sldd_install sss search_list_defaults_.cds
             ec sldd_install t multics_libraries_.ld
  
  
  =================================================================
                             STEP 10
  =================================================================
  
  
  If you  have never used admin.ec  extension, modify >sc1>admin.ec
  in order to reach x commands contained in admin_1.ec.Suggestion :
  
  
  &label BAD_X
  &label &1
  ec &ec_dir>admin_1 &rf1
  &quit
  
  Note  that you  may need  also to  modify both  command "doc" and
  "help" in order to find informative headers.
  
  ---------------
  
  Modify  master.ec (label  crank) to  clean up  various dsa  logs.
  Suggestion :
  
  move_log_segments dn7{c} >sc1>as_logs history 1week
  ....
  move_log_segments uft >sc1>as_logs history 1week
  move_log_segments dsa_al >site>dsa>aep_logs_dir  history  1week
  move_log_segments (r s)_log >site>dsa>uft_logs_dir history  1week
  lsdrb >site>dsa>system_logs_dir  7 7
  lsrb >site>dsa>system_logs_dir>**  4  4  4
  
  
  
                                 A-6
  
  
  
  move_log_segments  dsa_sal >site>dsa>system_logs_dir  history 1week
  move_log_segments dsa_sl >site>dsa>system_logs_dir history  1week
  lsrb >site>dsa>system_logs_dir>** 2 2 2
  lsdrb >site>dsa>system_logs_dir 2 7
  
  
  date_deleter >sc1>comms 7 NIF.nif.? NIF.nif.?? NIF.nit.? NIF.nit.??
                            NIF.*.*.io date_deleter >site>dsa 7 nit.?
  
  ---------------
  
  Modify >sc1>system_start_up.ec to start  dsa at system reboot and
  route various logs and messages.  Suggestion:
  
  sc_command define dn7{c} log dn7{c}
  ...
  sc_command define  uft log uft
  
  sc_command route (dn7{c} uftr ufts) user_i/o bkc
  sc_command route (dn7{c}   uftr   ufts)  error_i/o  bkc
  sc_command route  dn7{c} (user_i/o error_i/o log_i/o) dn7{c}
  ...
  sc_command route  uftr (user_i/o  error_i/o log_i/o) uft
  sc_command route ufts (user_i/o error_i/o log_i/o) uft
  
  At the end of ssu.ec, add the line :
  
                    ec admin_1 init_dsa
  
  =================================================================
                           STEP 11
  =================================================================
  
  
  
  
  
  Take in your working_dir model of NIF.nif (>sl3p>dsa>mod>NIF.nif)
  and  update  it  according  to  your  site.   Note that directory
  >site>dsa>acs is already created ,  and contains acs segments you
  have  to introduce  in NIF.    Once updated,  get object  segment
  NIF.nit by
  
                 >sl3p>dsa>e>dsa_cv_nif NIF
  
  and install  it using new install_table.ec.   Current NIF.nif and
  NIF.nit may be placed in >sc1>comms, and segment nit is installed
  in >site>dsa by modified exec_com install_table.ec.
  
  ---------------
  
  
  
  
                                 A-7
  
  
  
  Check  current CMF  :  DN7100's  must be  correctly declared  for
  gateway mode.
                      (Example is in >sl3p>dsa>mod).
  
  =================================================================
                            STEP 12
  =================================================================
  
  
  
  Shut the system.
  
  Initializing Datanet 7100 (at maintenance pannel) is careful.
      (STEP, CLEAR, LOAD, RUN, EXECUTE)
  
  Once at BCE level, modify config  deck to introduce the two cards
  and reboot as usually:
  
                  bce (boot) :  config
                  a
                  prph dia{c} <iom_tag> <iom_channel>
                  prph fnp{c} <iom_tag> <iom_channel> 7100. on
                  \f
                  w
                  q
                  bce (boot) :  reinit
                  bce (boot) :  ec auto star
  
  =================================================================
                                STEP 13
  =================================================================
  
  
  
  
  
  During  boot,  recently  registered  (Sys)Daemons  will  log  in,
  introducing (at  first reboot only) some  abnormal error messages
  concerning initialization.  Dont worry about them. 
  =================================================================
                                STEP 14
  =================================================================
  
  
  
  
  
  Once  system ready, we  must generate a  runnable image for  each
  datanet.
  
                       x gen_dn7 {c} -rl c1m4 -fw 640
  
  
  
                                 A-8
  
  
  
  On  line  generation  will  take  about  20 minutes.  Informative
  messages  are printed  out .   (ignore list  of "UNKNOWN  SYMBOL"
  while patches sets are entered).
  
  If everything is ok, you get the message
  
                      >>>>> DN7 LOADED AND STARTED
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 A-9
  
  
  
  
  
  
  
  
  
                              APPENDIX B
  
  
                              EXEC_COMS
  
  
  
  
       Following are six entry points for admin_dsa.ec.
  
  
  (1) First exec_com:
  
  &version 2
  &trace off
  &-----------------------------------------------------------------------------
  &- Needs 5 args: dn7 to be generated, dn7 release, patches fw, image, start
  &-                       (dn7x)        (eg c1m4)    (FWYWW)          (true/fls)
  &- These args have already been checked for consistency by admin_1.ec
  &- We are in dsafwd of dn7 to be generated by CXI start_up.
  &-----------------------------------------------------------------------------
  &if &[e not [e equal &n 5]] &then &goto usage
  ec stop_dn7
  ..ec update_fwd &1 &2 &3
  &set DSAFWD &[e wd]
  &print ...... BEGINNING GENERATION OF &4.
  &goto &ec_name
  
  &label gen_dn7
        &set MAP imamem.[e date].map
        load IMAMEM.i -fc -nt
        execute_in_frontend &(MAP) -fc -nt -go  &(DSAFWD)>config -P2 PATCH1 PATCH2 PATCH4 -MAP -SV imamem.i
  
  &label gen3_dn7
        &set MAP3 [e entry &4].[e date].map3
        load imamem.i -fc -nt
        execute_in_frontend &(MAP3) -fc -nt -go -P2 PATCH3 TMCK TASY -FOR TASYGO TMCKGO -MAP -SV &4
        &print ...... GENERATION OF &4 COMPLETED.
        e vs release &2
        e vs fw &3
        e vs image &4
  
  
  
  
  
  
  
                                 B-1
  
  
  
  &if &5 &then ec load_dn7 &4
  &label END
  e cwd
  &quit
  &label usage
  &print ***** Syntax  : &ec_name <dn7> <release> <fw> <image_path> <start value>
  &quit
  
  
  (2) Second exec_com:
  
  &version 2
  &trace off
  &-----------------------------------------------------------------------------
  &- This ec should load the datanet in any case, then start it.
  &- Default working_dir is the dsafwd of the specified frontend
  &- Needs 1 arg : absolute_pathname of image to be loaded.
  &-----------------------------------------------------------------------------
  &default final_image.i
  ..cwd
  ec stop_dn7
  &set IMAGE &1
  &print ...... LOADING DN7
  load &(IMAGE) -fc -nt
  execute_in_frontend -nli -nt -fc -go  -TR 6000
  &print >>>>>> DN7 LOADED <<<<<<
  start_frontend  -fc -nt
  ..pause 20
  &print >>>>>> DN7 LOADED AND STARTED <<<<<<
  &set start_driver_value &[start_driver -fc]
  &print ***** ERROR : START ABORTED ON DN7 (&(start_driver_value))
  &goto &(start_driver_value)
  &label not_responding
  &label interrupt
  &label error
  &label bad_pcw
  ec stop_dn7
  &print ***** WARNING : Specified datanet needs manual intervention.
  &label quit
  &quit
  &label reboot
  ec auto_reboot
  &quit
  
  
  (3) Third exec_com:
  
  &version 2
  &trace off
  &------------------------------------------------------------------------------
  &- 1- the frontend must be loaded and stopped before.
  &- 2- we will try to start the driver
  
  
                                 B-2
  
  
  
  &- 3- if it returns with something else then quit, that means the DN7 is not
  &-    loaded
  &- 4- so load it
  &- 5- we are in wd of datanet to be started.
  &- If argument exists : path of image to be reloaded (depends on abort case).
  &------------------------------------------------------------------------------
  ec stop_dn7
  &print >>>>>> DN7 STARTED <<<<<<
  start_frontend -local_image -fc -notify
  ..pause 20
  &set start_driver_value &[start_driver -fc]
  &print ***** ERROR : START ABORTED ON DN7 (&(start_driver_value))
  &goto &(start_driver_value)
  &label not_responding
  &label interrupt
  &label error
  &if &is_defined(1) &then ec load_dn7 &1 -fc
  &else &quit
  &label reboot
  ec auto_reboot
  &label quit
  &quit
  &label bad_pcw
  &if &is_defined(1) &then ec load_dn7 &1 -fc
  &else &print ***** Manual intervention required.
  &quit
  
  
  (4) Fourth exec_com:
  
  &version 2
  &trace off
  &-----------------------------------------------------------------------------
  &- This ec will stop frontend and driver.
  &- We are in wd of datanet to be stopped.
  &-----------------------------------------------------------------------------
  ..cwd
  stop_driver -fc -nt
  stop_frontend -fc -nt
  &print >>>>>> DN7 STOPPED <<<<<<
  &quit
  
  
  (5) Fifth exec_com:
  
  &version 2
  &trace off
  &-----------------------------------------------------------------------------
  &- This exec_com is executed when the DN8 crashes.
  
  
  
  
  
                                 B-3
  
  
  
  &-----------------------------------------------------------------------------
  ec dump_dn7
  ec load_dn7
  &quit
  
  
  (6) Sixth exec_com:
  
  &version 2
  &trace off
  &-----------------------------------------------------------------------------
  &- This ec should take a dump and nothing else
  &-----------------------------------------------------------------------------
  ..cwd
  &print >>>>>> DUMPING DN7 <<<<<<
  dump &rf1
  &print >>>>>> DN7 DUMPED <<<<<<
  &quit
  .fin
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                                 B-4