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.
PROBLEMS WITH THE MANUAL
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.
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.
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 An overview of DSA on Multics
o Step-by-step instructions for starting DSA up on
Multics
o 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 Explanations of how the user environment and the
operator environment are different under DSA from how
they are under MCS
o 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 DNS System Installation and Generation
DP42 DNS System Operations
DM23 DNS Terminal User's Guide
DS58 Inline/Online Test and Verification Package
User's Guide
DP31 Inline/Online Test and Verification Package
Reference Manual
DV47 DSA Software, Documentation, and Education
Directory
Bull manuals which may be of interest to Multics network
administrators are listed below.
Reference
Number Title
39 A2 9807 DNS System Generation
39 A2 9799 DNS System Operations
39 A2 9820 DNS Terminal Management Reference Manual
39 A2 00DM DNS In/On Line Test Operator's Guide
39 A2 26DM DSA Network System Messages and Return Codes
39 A4 9798 DNS Documentation Directory
30 A4 9726 DSA Documentation Directory
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
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
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
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
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
SECTION 1
INTRODUCTION
Multics DSA software provides the following:
o The ability to have Multics act as a DSA host
o Interconnections between Multics and other Honeywell,
CII-HB, and foreign systems
o Access to Multics applications from terminals connected
via DSA terminal management
o File transfer between Multics and other DSA systems
using the unified file transfer (UFT) facility
o A DSAC ASF on Multics
o A DSAC NAD on Multics
o The ability to load, dump, and generate a
locally-connected or a remote DN8/7100
o DSA terminal management
Multics DSA software includes the following extensions to
the Multics system:
o The addition of a Multics networking architecture
(MNA), which provides new software layering and dynamic
connection management
o Changes to the answering service, which are invisible
to the user except for the addition of a network login
server
o Changes to the hardcore, mainly consisting of changes
to IPC and IPS, which are invisible to the user except
for a new IPC entrypoint
These extensions are described later in this section.
Multics DSA software includes the following DSA specific
software:
o Network information table (NIT)
o Common exchange interface (CXI) protocol
o Session control
o Transport control
o Terminal management
o Unified file transfer (UFT)
o 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).
DIFFERENCES BETWEEN MCS AND MCA
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.
EXTENSIONS TO THE MULTICS SYSTEM
Multics Networking Architecture
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
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.
Changes to the Answering Service
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
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.
Changes to the Hardcore
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.
Changes to System Exec_Coms
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.
DSA SPECIFIC SOFTWARE
Network Information Table (NIT)
The NIT is the central repository for describing the DSA
network configuration on Multics. The NIT is described in detail
in Section 4.
Common eXchange Interface (CXI) Protocol and DN8/7100 Control
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,
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.
Session Control
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.
Transport Control
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.
Terminal Management (TM)
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
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.
Unified File Transfer (UFT)
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 Multics DSA Unified
File Transfer (UFT) Facility manual, Order No. *** TBS ***.
Distributed System Administration and Control (DSAC)
DSAC is the administrative part of DSA. It runs in both DNS
and in Multics. In DNS, DSAC performs the following functions:
o NOI (network operator interface)
o NAD (network administration)
o ASF (administrative storage facility)
o 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.
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 ASF LOG (administrative storage facility log)
o NAD (network administration)
o ASF (administrative storage facility)
The dssr subsystem performs the following functions:
o remote NOI access
o remote NAD access
o 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.
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.
Datanet 8 (DN8/7100) and Distributed Network Supervisor (DNS)
DNS is the operating system software which runs on the
DN8/7100 frontend hardware.
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 generator image file: when it is run, it generates a
specific runnable image for a specific DNS software
release.
o patch file: contains software updates.
o 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 config file: describes the configuration for a given
frontend.
o 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 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 dump file: contains a DN8/7100 memory dump.
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.
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...) |
=========================
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 Tailoring the Multics environment for DSA (must be done
once, when DSA is first brought up on Multics)
o 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 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 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.
TAILORING THE MULTICS ENVIRONMENT FOR DSA
Administrators must perform the tasks listed below to tailor
the Multics environment for DSA:
o Edit the Multics config deck
o Create new access control segments
o Update the installation_parms segment
o Optionally change the terminal type file (TTF)
o Set ACLs on the DSA logs
o Register the new DSA daemons
o Build a Multics DSA hierarchy
Editing the Multics Config Deck
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 Multics System Maintenance Procedures
manual, Order No. AM81, for a complete description of the config
deck.
Creating New Access Control Segments
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 Multics System Administration Procedures 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.
Updating the installation_parms Segment
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
Multics Administrative, Maintenance, and Operations Commands
manual, Order No. GB64. The installation_parms segment is
described in the Multics System Administration Procedures manual,
Order No. AK50.
Changing the TTF
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.
Setting ACLs on the DSA Logs
Three logs are defined in the NIT (see the description of
the Mna_general_info object definition in Section 4):
o DSA system log (dsa_sl), for recording CXI input daemon
and session control errors
o DSA system AEP log (dsa_sal), for recording CXI input
daemon and session control AEP activity
o DSA AEP log (dsa_al), for recording UFT and DSAC AEP
activity
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.
Registering the New DSA Daemons
Multics DSA employs the following daemons to perform varied
services over the network:
o DSA_DSAC.Daemon, responsible for ASF LOG, NAD, and ASF
functions
o DSA_CXI.Daemon, responsible for handling all input from
a frontend; there is one for each frontend configured
in the NIT
o Login_Server.Daemon, responsible for fielding requests
for sessions from remote users and arranging for
process creation on their behalf on Multics
o 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 Multics DSA
Unified File Transfer (UFT) Facility manual, Order No. *** TBS
***.
See the Multics System Administration Procedures manual,
Order No. AK50, for more information on registering daemons.
Building a Multics DSA Hierarchy
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.
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 DNS System Installation and Generation manual, Order No.
DP43 or the DNS System Generation 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.
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).
___________________ ___________________
dsa_fep_working_dir dsa_fep_working_dir
___________________ ___________________
NAME: DSA_FEP_WORKING_DIR, DSAFWD
SYNTAX AS A COMMAND
dsafwd frontend_name
SYNTAX AS AN ACTIVE FUNCTION
[dsafwd frontend_name]
FUNCTION
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).
ARGUMENTS
frontend_name
is the name of the frontend whose working directory is
desired.
ACCESS REQUIRED
This command requires r access to the NIT.
NOTES
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.
BUILDING THE NETWORK INFORMATION TABLE
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.
BUILDING A DN8/7100 DIR 'SYS>'
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 DNS System Installation
and Generation manual, Order No. DP43 or in the DNS System
Generation 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.
Remember that you must build a config file for each datanet
managed by Multics and defined in the NIT.
MANAGING DN8/7100 GENERATION AND RUN OPERATIONS
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.
Loading the DNS Software onto Multics
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 Multics Commands and Active Functions 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.
Converting GCOS Files to Multics Format
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 **])
_______________ _______________
dsa_cv_dns_tape dsa_cv_dns_tape
_______________ _______________
NAME: DSA_CV_DNS_TAPE, DSACVT
SYNTAX AS A COMMAND
dsacvt input_path {output_path} {-control_args}
FUNCTION
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.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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
_______________ _______________
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.
NOTES
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 Multics
Commands and Active Functions 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
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
Creating the CXI Driver Segment
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.
_____________________ _____________________
cxi_create_driver_seg cxi_create_driver_seg
_____________________ _____________________
NAME: CXI_CREATE_DRIVER_SEG
SYNTAX AS A COMMAND
cxi_create_driver_seg {-control_args}
SYNTAX AS AN ACTIVE FUNCTION
[cxi_create_driver_seg {-control_args}]
FUNCTION
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.
CONTROL ARGUMENTS
-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.
ACCESS REQUIRED
This command requires re access to cxi_driver_admin_gate_.
NOTES
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.
Starting Session Control
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.
________ ________
dsa_init dsa_init
________ ________
NAME: DSA_INIT
SYNTAX AS A COMMAND
dsa_init {-control_args}
FUNCTION
initializes DSA operations by initializing session control
databases, creating mailboxes, and creating the CXI driver
segment for CXI operations.
CONTROL ARGUMENTS
-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.)
NOTES
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.
Logging in the CXI Input Daemons
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.
Starting the CXI Subsystem
The CXI subsystem is the mechanism through which a CXI input
daemon manages a frontend. Included in the subsystem repertoire
are requests to:
o Load and execute a generator image
o Load, execute, and start a runnable image
o Dump a frontend
o 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.
Loading and Executing a Generator Image
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.
Loading, Executing, and Starting a Runnable Image
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.
Starting the CXI Driver
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.
Logging in the Other DSA Daemons
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.
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
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."
REGISTERING THE LOGIN SERVER DAEMON
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.
STARTING THE LOGIN SERVER REQUEST MECHANISM
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.
_________________ _________________
ls_request_server ls_request_server
_________________ _________________
NAME: LS_REQUEST_SERVER
SYNTAX AS A COMMAND
ls_request_server operation
SYNTAX AS AN ACTIVE FUNCTION
[ls_request_server operation]
FUNCTION
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.
ARGUMENTS
operation
can be one of the operations given in "List of operations"
below.
LIST OF OPERATIONS:
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_.
ACCESS REQUIRED:
This command can only be executed in the Initializer process,
while in admin mode. It requires re access to the
hpriv_connection_list_ gate.
NOTES
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.
_________________ ______
ls_request_server login,
_________________ ______
LOGGING IN THE LOGIN SERVER DAEMON
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
SYNTAX
l Person_id{.Project_id} {-control_args}
FUNCTION
This is a login preaccess command.
______ ______
login, login,
______ ______
CONTROL ARGUMENTS
(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
CONTROL ARGUMENTS
(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.
CONTROLLING THE LOGIN SERVER DAEMON
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.
______ ____
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
NETWORK LOGIN SERVER REQUESTS
The following are descriptions of the requests that can be
used with the login server daemon.
________________________________________
NAME: SELF_IDENTIFY
SYNTAX AS A COMMAND
.
FUNCTION
prints the name and version of the login server subsystem.
________________________________________
NAME: HELP
SYNTAX
help topic(s) {-control_args}
FUNCTION
prints information about the selected topic(s).
ARGUMENTS
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).
____ __________
help list_help,
____ __________
CONTROL ARGUMENTS
-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
SYNTAX
lh {string}
FUNCTION
displays a list of all topics for which information can be
printed.
ARGUMENTS
string
specifies a portion or part of a topic name. See "Notes"
below for instruction on the use of this argument.
__________ ______________
list_help, list_requests,
__________ ______________
NOTES
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
SYNTAX
lsep
FUNCTION
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
SYNTAX
lr {request(s)} {-control_args}
FUNCTION
prints a list and brief description of the specified requests.
ARGUMENTS
request(s)
specifies the request(s) to be listed. If no request is
specified, a list of all requests is provided.
______________ _____
list_requests, quit,
______________ _____
CONTROL ARGUMENTS
-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
SYNTAX
q
FUNCTION
exits from the login server subsystem and logs out the login
server daemon. Note that this request does NOT return to Multics
command level.
NOTES
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.
___________________ __________________
start_login_service stop_login_service
___________________ __________________
NAME: START_LOGIN_SERVICE
SYNTAX
start_login_service endpoint_name
FUNCTION
specifies that the login server daemon is to monitor the
designated endpoint.
ARGUMENTS
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.
EXAMPLES
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
SYNTAX
stop_login_service endpoint_name
FUNCTION
specifies that the login server daemon is to stop monitoring the
designated endpoint.
ARGUMENTS
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.
__________________ __________________
stop_login_service stop_login_service
__________________ __________________
NOTES
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.
EXAMPLES
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
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.
THE PURPOSE OF THE NIT
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
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.
BUILDING A NIT
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.
NIT SOURCE LANGUAGE
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.
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;
NIT Source Language Syntax
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
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.
NIT OBJECT DEFINITIONS
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.
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)
Mna_general_info
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.
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:
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;
Service
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
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.
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;
Session_type_descriptor
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
** (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.)
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.
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.
Sc_loc
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.
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.)
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
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.)
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;
Mailbox
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.
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.")
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;
Dsac_info
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.
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;
Admin_function
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.
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>
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;
Admin_group
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.
EXAMPLE
Admin_group: admin_group1;
type: NOI;
max_active_ac: 10;
admin_function: lnad1;
end;
Ts
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;
Frontend
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 System Maintenance Procedures
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.
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.
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;
Session_Route
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;
System
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
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
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;
Correspondent
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.
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.
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;
Admin_correspondent
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>
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.
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;
DSA NIT SOURCE TABLE EXAMPLE
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* 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;
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;
/*------------------------------------------------------------*/
/* 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;
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;
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* 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;
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;
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;
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* Tss */
/*------------------------------------------------------------*/
Ts: dn8_a;
address: 1:61;
frontend: dn8a;
end;
Ts: dn8_b;
address: 1:63;
frontend: dn8b;
end;
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* 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;
/*------------------------------------------------------------*/
/* 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;
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;
/*------------------------------------------------------------*/
/* 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;
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;
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;
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;
authorization: system_low;
terminal_type: NONE;
/* acl_path : NONE, the system one is taken */
end;
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;
/*------------------------------------------------------------*/
/* 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;
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;
COMPILING A NIT
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".
__________ __________
dsa_cv_nif dsa_cv_nif
__________ __________
NAME: DSA_CV_NIF
SYNTAX AS A COMMAND
dsa_cv_nif dsa_nit_path {-control_args}
FUNCTION
compiles a NIT source table into a NIT object table.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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).
NOTES
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:
__________ __________
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.
INSTALLING A NIT
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 Multics
Administration, Maintenance, and Operations Commands manual,
Order No. GB64.
UPDATING A NIT
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.
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
NAME: CXI_INPUT_DAEMON, CID
SYNTAX AS A COMMAND
cid frontend_name {-control_args}
FUNCTION
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).
ARGUMENTS
frontend_name
specifies the DN8/7100 frontend to be managed by this
invocation of the subsystem.
CONTROL ARGUMENTS
-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".
________________ ________________
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
LIST OF REQUESTS
For a complete description of any request, issue the
cxi_input_daemon request: help request_name.
self_identify
SYNTAX
.
FUNCTION
prints a line describing the current invocation of the
cxi_input_daemon subsystem.
NOTES
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.
?
SYNTAX
?
FUNCTION
prints a list of the requests available in the cxi_input_daemon
subsystem.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
abbrev, ab
SYNTAX
ab {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[ab]
FUNCTION
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.
CONTROL ARGUMENTS
-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.
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
answer
SYNTAX
answer STR -control_args request_line
FUNCTION
provides preset answers to questions asked by another request.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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.
________________ ________________
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).
NOTES
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 Multics Subroutines and I/O Modules 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 Multics Programmer's
Reference Manual, 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/
________________ ________________
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".
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
debug_mode
SYNTAX
debug_mode {-control_args}
FUNCTION
enables or disables the cxi_input_daemon debugging facilities.
CONTROL ARGUMENTS
-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.
NOTES
This request is intended for use only by system maintainers when
debugging cxi_input_daemon operations.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
do
SYNTAX
do request_string {args}
or
do -control_args
SYNTAX AS AN ACTIVE REQUEST
[do "request_string" args]
FUNCTION
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.
ARGUMENTS
request_string
is a request line in quotes.
args
are character string arguments that replace parameters in
request_string.
CONTROL ARGUMENTS
-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.
________________ ________________
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.
LIST OF PARAMETERS
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.
________________ ________________
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
dump_frontend, dump
SYNTAX
dump {dump_pathname} {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[dump {dump_pathname} {-control_args}]
FUNCTION
dumps the frontend memory into the specified Multics segment
using the specified bounds.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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.
________________ ________________
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.
NOTES
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 Multics Commands
and Active Functions manual, Order No. AG92.)
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
exec_com, ec
SYNTAX
ec ec_path {ec_args}
SYNTAX AS AN ACTIVE REQUEST
[ec ec_path {ec_args}]
FUNCTION
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.
ARGUMENTS
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.
NOTES
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.
________________ ________________
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
execute, e
SYNTAX
e LINE
SYNTAX AS AN ACTIVE REQUEST
[e LINE]
FUNCTION
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.
ARGUMENTS
LINE
is the Multics command line to be executed or the Multics
active string to be evaluated. It need not be enclosed in
quotes.
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
execute_in_frontend, exfep
SYNTAX
exfep {map_pathname} {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[exfep {map_pathname} {-control_args}]
FUNCTION
executes a previously loaded frontend image in a frontend; for
instance, to execute a generator image and produce a runnable
image.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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 DNS System Installation and Generation manual,
Order No. DP43 and in the DNS System Generation manual,
________________ ________________
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
NOTES
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.)
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
frontend_working_dir, fwd
SYNTAX
fwd
SYNTAX AS AN ACTIVE REQUEST
[fwd]
FUNCTION
returns the pathname of the working directory defined in the NIT
for the current frontend.
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
help
SYNTAX
help {topics} {-control_args}
FUNCTION
prints descriptions of cxi_input_daemon requests and information
about other topics.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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.
LIST OF RESPONSES
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.
________________ ________________
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.
________________ ________________
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.
NOTES
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
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
if
SYNTAX
if expr -then line1 {-else line2}
SYNTAX AS AN ACTIVE REQUEST
[if expr -then STR1 {-else STR2}]
FUNCTION
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.
ARGUMENTS
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
list_help, lh
SYNTAX
lh {topics}
FUNCTION
displays the names of all cxi_input_daemon info segments on given
topics.
ARGUMENTS
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.
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
list_requests, lr
SYNTAX
lr {STRs} {-control_args}
FUNCTION
prints a brief description of selected cxi_input_daemon requests.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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.
NOTES
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 ($).
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
load_frontend, load
SYNTAX
load {load_pathname} {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[load {load_pathname} {-control_args}]
FUNCTION
loads the memory of the frontend from the specified segment,
starting at the specified frontend memory location.
ARGUMENTS
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".
CONTROL ARGUMENTS
-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.
________________ ________________
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.
NOTES
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 Multics Commands
and Active Functions manual, Order No. AG92.)
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
quit, q
SYNTAX
q {-control_args}
FUNCTION
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.
CONTROL ARGUMENTS
-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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
ready, rdy
SYNTAX
rdy
FUNCTION
prints a Multics ready message.
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
ready_off, rdf
SYNTAX
rdf
FUNCTION
disables printing of a ready message after each request line.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
ready_on, rdn
SYNTAX
rdn
FUNCTION
enables printing of a ready message after each request line.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
start_driver, std
SYNTAX
std {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[std {-control_args}]
FUNCTION
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.
CONTROL ARGUMENTS
-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.
NOTES
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
________________ ________________
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
start_frontend, stf
SYNTAX
stf {map_pathname} {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[stf {map_pathname} {-control_args}]
FUNCTION
starts a previously loaded and executed frontend image in a
frontend; for instance, to cause a runnable image to start.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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 DNS System Installation and Generation manual,
Order No. DP43 and in the DNS System Generation manual,
________________ ________________
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
stop_driver, stpd
SYNTAX
stpd {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[stpd {-control_args}]
FUNCTION
stops the CXI driver.
CONTROL ARGUMENTS
-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.
NOTES
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.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
stop_frontend, stpf
SYNTAX
stpf {-control_args}
SYNTAX AS AN ACTIVE REQUEST
[stpf {-control_args}]
FUNCTION
stops the frontend.
CONTROL ARGUMENTS
-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.
NOTES
This request stops the current frontend. It cleans up the
current invocation, but does not notify the frontend of the
action being taken.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
subsystem_name
SYNTAX
subsystem_name
SYNTAX AS AN ACTIVE REQUEST
[subsystem_name]
FUNCTION
prints or returns the name of the cxi_input_daemon subsystem.
________________ ________________
cxi_input_daemon cxi_input_daemon
________________ ________________
subsystem_version
SYNTAX
subystem_version
SYNTAX AS AN ACTIVE REQUEST
[subsystem_version]
FUNCTION
prints or returns the version number of the cxi_input_daemon
subsystem.
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 NAD (network administration)
o NOI (network operator interface)
o 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.
THE DSA_DSAC DAEMON
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.
Logging In and Initializing the DSA_DSAC Daemon
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>
Logging Out the DSA_DSAC Daemon
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 Operator's Guide to Multics (Order No.
GB61).
____________________ ____________________
run_dsac_daemon_init run_dsac_daemon_init
____________________ ____________________
NAME: RUN_DSAC_DAEMON_INIT, RDD_INIT
SYNTAX AS A COMMAND
rdd_init session_control_name {-control_args}
FUNCTION
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.
ARGUMENTS
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.
CONTROL ARGUMENTS
-debug
specifies that tracing should be enabled.
-no_debug
specifies that tracing should not be enabled. (This is the
default.)
_______________ _______________
run_dsac_daemon run_dsac_daemon
_______________ _______________
NAME: RUN_DSAC_DAEMON, RDD
SYNTAX AS A COMMAND
rdd session_control_name {-control_args}
FUNCTION
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).
ARGUMENTS
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.
CONTROL ARGUMENTS
-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.)
_______________ _______________
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.)
LIST OF REQUESTS
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.
_______________ _______________
run_dsac_daemon run_dsac_daemon
_______________ _______________
kill_driver, kill
SYNTAX
kill
FUNCTION
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.
_______________ _______________
run_dsac_daemon run_dsac_daemon
_______________ _______________
quit
SYNTAX
quit
FUNCTION
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.
_____________________ _____________________
start_admin_function, start_admin_function,
_____________________ _____________________
NAME: START_ADMIN_FUNCTION,, START_AF
SYNTAX
start_af admin_function_name
FUNCTION
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.).
ARGUMENTS
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.
____________________ ____________________
stop_admin_function, stop_admin_function,
____________________ ____________________
NAME: STOP_ADMIN_FUNCTION,, STOP_AF
SYNTAX
stop_af admin_function_name
FUNCTION
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.
ARGUMENTS
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.
____________________ ____________________
stop_admin_function, stop_admin_function,
____________________ ____________________
trace
SYNTAX
trace control_arg
FUNCTION
turns the tracing feature on or off for the DSA_DSAC daemon.
CONTROL ARGUMENTS
-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.
ADMINISTRATIVE INTERFACE TO SESSION CONTROL
The DSA administrative interface to session control provides
two commands to administer session control:
o dsa_scc - for administering Multics-specific session
control
o dsa_dsac - for displaying session control, CXI, and
DSAC objects on Multics
Both of these commands are described in detail below.
Multics-Specific Session Control Administration
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 initialize session control's main data base
o start (or restart) session control
o stop and terminate session control
o create and delete mailboxes
o abnormally terminate or stop listening on a logical
connection
o stop listening on an endpoint
o set (or reset) traces at the session control level
o 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.
_______ _______
dsa_scc dsa_scc
_______ _______
NAME: DSA_SCC
SYNTAX AS A COMMAND
dsa_scc request
FUNCTION
invokes the dsa_scc subsystem, which provides requests to
administer Multics-specific session control.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
LIST OF REQUESTS
initialize_handle_table, iht
SYNTAX
iht
FUNCTION
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.
_______ _______
dsa_scc dsa_scc
_______ _______
mailbox_create, mbxc
SYNTAX
mbxc mailbox_name
FUNCTION
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.
ARGUMENTS
mailbox_name
is the name of a local mailbox. This name must be defined by
a Mailbox object definition in the NIT.
_______ _______
dsa_scc dsa_scc
_______ _______
mailbox_delete, mbxd
SYNTAX
mbxd mailbox_name
FUNCTION
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.
ARGUMENTS
mailbox_name
is the name of a local mailbox. This name must be defined by
a Mailbox object definition in the NIT.
_______ _______
dsa_scc dsa_scc
_______ _______
reset_lc_trace
SYNTAX
reset_lc_trace lc_name trace_type
FUNCTION
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.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
reset_sc_trace
SYNTAX
reset_sc_trace session_control_name trace_type
FUNCTION
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.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
restart_session_control, rst_sc
SYNTAX
rst_sc session_control_name
FUNCTION
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.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
set_lc_trace
SYNTAX
set_lc_trace lc_name trace_type
FUNCTION
sets trace flags on a specific logical connection (session). The
different kinds of traces which may be set are explained below.
ARGUMENTS
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.
_______ _______
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.
_______ _______
dsa_scc dsa_scc
_______ _______
set_sc_trace
SYNTAX
set_sc_trace session_control_name trace_type
FUNCTION
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.
ARGUMENTS
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.
_______ _______
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.
_______ _______
dsa_scc dsa_scc
_______ _______
start_session_control, start_sc
SYNTAX
start_sc session_control_name
FUNCTION
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.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
stop_listen, slis
SYNTAX
slis lc_name
FUNCTION
abnormally terminates a pending listen. The owner gets a wakeup
and has no further access to the specified "pseudo" session.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
stop_listen_endpoint, slis_ep
SYNTAX
slis_ep mailbox_name
FUNCTION
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.
ARGUMENTS
mailbox_name
is the name of a local mailbox. This name must be defined by
a Mailbox object definition in the NIT.
_______ _______
dsa_scc dsa_scc
_______ _______
stop_session_control, stop_sc
SYNTAX
stop_sc session_control_name
FUNCTION
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.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
terminate_abnormal, tabn
SYNTAX
tabn lc_name
FUNCTION
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.
ARGUMENTS
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.
_______ _______
dsa_scc dsa_scc
_______ _______
terminate_session_control, tmr_sc
SYNTAX
tmr_sc session_control_name
FUNCTION
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.
ARGUMENTS
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.
Display of DSA Objects on Multics
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 find out how many DSA objects of a given class exist on
the local system
o find out which DSA objects of a given class exist on
the local system
o find out the attributes of DSA objects of a given class
which exist on the local system
________ ________
dsa_dsac dsa_dsac
________ ________
NAME: DSA_DSAC
SYNTAX AS A COMMAND
dsa_dsac request object_class {object_name}
{object_specification}
FUNCTION
invokes the dsa_dsac subsystem, which provides requests to
retrieve information about various DSA objects in the session
control, CXI, and DSAC layers.
ARGUMENTS
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)
________ ________
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)
________ ________
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.
________ ________
dsa_dsac dsa_dsac
________ ________
NOTES ON OBJECT SPECIFICATIONS
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.
________ ________
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>
________ ________
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.
NOTES
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])
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.
THE DSSR SUBSYSTEM
The dssr subsystem runs in a normal user process. It allows
you to perform two main functions:
o run the basic network session exerciser (BNSE)
o 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.
The Basic Network Session Exerciser
The basic network session exerciser (BNSE) can be used to:
o verify the session control user interface level between
two systems
o load the network and verify its performance
o test the accuracy of the session control by comparing
the data sent and the data received
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 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 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.
Remote NOI/NAD Access Facility
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 Tasking - lets you send requests to several remote NOIs
or remote NADs simultaneously.
o 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.
o 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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
NAME: DSA_SSU_ROOT, DSSR
SYNTAX AS A COMMAND
dssr activity {-control_args}
FUNCTION
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.
ARGUMENTS
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".
CONTROL ARGUMENTS
-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
____________ ____________
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.
____________ ____________
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.
NOTES
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
LIST OF BNSE EXERCISER INITIATOR ACTIVITY REQUESTS
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").
self_identify
SYNTAX
.
FUNCTION
prints the name of the current session.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
connect, cn
SYNTAX
cn correspondent_name {-control_args}
FUNCTION
establishes a session to the remote BNSE whose name is given by
correspondent_name.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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
____________ ____________
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
disconnect, dis
SYNTAX
dis
FUNCTION
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_info, gi
SYNTAX
gi argument
FUNCTION
prints information about either all of the active sessions or
about one specific session.
ARGUMENTS
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
run_test, rt
SYNTAX
rt test_name {-control_arg}
FUNCTION
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.
ARGUMENTS
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.
CONTROL ARGUMENTS
-iteration N, -it N
specifies how many times the test should be performed. The
default for N is 50.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
session_name, sn
SYNTAX
sn session_name
FUNCTION
causes the specified session to become the current session.
Subsequent requests typed by the Administrator are sent on this
session.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
LIST OF BNSE EXERCISER ECHOER ACTIVITY REQUESTS
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").
self_identify
SYNTAX
.
FUNCTION
prints the name of the current session.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_info, gi
SYNTAX
gi argument
FUNCTION
prints information about either all of the active sessions or
about one specific session.
ARGUMENTS
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
start_listen, listen
SYNTAX
listen mailbox_name
FUNCTION
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.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
stop_listen, stop
SYNTAX
stop
FUNCTION
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".
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
LIST OF REMOTE NOI ACCESS REQUESTS
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 NOI access-specific requests
o NOI requests
The NOI access-specific requests are described below. The NOI
requests (get_attributes, get_list, etc.) are described in the
DNS System Operations manual, Order No. DP42 and in the DNS
System Operations 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.
NOI ACCESS-SPECIFIC REQUESTS
self_identify
SYNTAX
.
FUNCTION
prints the name of the current session.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
connect, cn
SYNTAX
cn correspondent_name {-control_args}
FUNCTION
establishes a session to the remote NOI whose name is given by
correspondent_name.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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
____________ ____________
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
disconnect, dis
SYNTAX
dis
FUNCTION
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_info, gi
SYNTAX
gi argument
FUNCTION
prints information about either all of the active sessions or
about one specific session.
ARGUMENTS
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
session_name, sn
SYNTAX
sn session_name
FUNCTION
causes the specified session to become the current session.
Subsequent requests typed by the Administrator are sent on this
session.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
turn, t
SYNTAX
t
FUNCTION
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
LIST OF REMOTE NAD ACCESS REQUESTS
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 NAD access-specific requests
o 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 DNS System
Operations manual, Order No. DP42 and in the DNS System
Operations manual, Reference No. 39 A2 9799.
NAD ACCESS-SPECIFIC REQUESTS
self_identify
SYNTAX
.
FUNCTION
prints the name of the current session.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
connect, cn
SYNTAX
cn correspondent_name {-control_args}
FUNCTION
establishes a session to the remote NAD whose name is given by
correspondent_name.
ARGUMENTS
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.
CONTROL ARGUMENTS
-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
____________ ____________
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
disconnect, dis
SYNTAX
dis
FUNCTION
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_info, gi
SYNTAX
gi argument
FUNCTION
prints information about either all of the active sessions or
about one specific session.
ARGUMENTS
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).
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
session_name, sn
SYNTAX
sn session_name
FUNCTION
causes the specified session to become the current session.
Subsequent requests typed by the Administrator are sent on this
session.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
NAD REQUESTS
display_attributes, da
SYNTAX
da object_class {object_name} {selection_criteria}
FUNCTION
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.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_attributes, ga
SYNTAX
ga object_class {object_name} {selection_criteria}
FUNCTION
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.
ARGUMENTS
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.
EXAMPLES
The following request line prints a complete list of the
attributes of the Network Subscription (ns) object TPC:
ga ns TPC
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_list, gl, list, ls
SYNTAX
gl object_class {selection_criteria}
FUNCTION
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.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
get_number, gn, number, nb
SYNTAX
gn object_class {selection_criteria}
FUNCTION
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.
ARGUMENTS
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.
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
update, up
SYNTAX
up object_class object_name -control_args
FUNCTION
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..
ARGUMENTS
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.
CONTROL ARGUMENTS
-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
____________ ____________
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).
EXAMPLES
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
____________ ____________
dsa_ssu_root dsa_ssu_root
____________ ____________
NOTES ON SELECTION CRITERIA
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.
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.
CONNECTING TO MULTICS FROM A REMOTE TERMINAL
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 New User's Introduction to Multics (Order No.
CH24).
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.
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 DNS
Terminal User's Guide, Order No. DP42 and the DNS Terminal
Management Reference Manual, Reference No. 39 A2 9820.
Sample Login/Logout Session
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 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 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 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 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.
$$ 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
CHANGES TO THE tty_ I/O MODULE
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
Multics Subroutines and I/O Modules 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
Multics Subroutines and I/O Modules manual.
New Control Orders
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.
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.
Control Orders That Cannot Be Used
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
CHANGES TO THE set_tty COMMAND
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 Multics
Commands and Active Functions manual (Order No. AG92).
New Control Arguments
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.
-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.
Control Arguments That Can Not Be Used
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
Changes to the -ttp Control Argument
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.
New and Changed Mode Specifications
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.
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
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.
CHANGES TO THE TERMINAL TYPE FILE
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 Multics Programmer's Reference Manual (Order No.
AG91).
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.
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:
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.
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;
character_set: ascii;
max_record_size: 512;
attd: break;
att1: break;
stc_available: yes;
CHANGES TO THE ttt_info_ SUBROUTINE
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
SYNTAX AS A COMMAND
tmparm {-control_args}
FUNCTION
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.
CONTROL ARGUMENTS
-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.
________________ ________________
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.
NOTES
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.
________________ ________________
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.
________________ ________________
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.
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,
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.
USING EMACS
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 Multics Commands
and Active Functions 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 Multics Programmer's Reference Manual (Order No. AG91)
for additional information on the video System.
ACTIVE CONNECTION LIST TABLE
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.
NAME: DISPLAY_CONNECTION_LIST
SYNTAX AS A COMMAND
display_connection_list {-control_arg}
FUNCTION
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.
CONTROL ARGUMENTS
-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.
_______________________ _______________________
display_connection_list display_connection_list
_______________________ _______________________
ACCESS REQUIRED
Access to the hpriv_connection_list_ gate is required to use this
command.
NOTES
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.
EXAMPLES
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
_______________________ _______________________
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
CHANGES TO THE BLAST AND INACTIVITY MECHANISMS
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.
SENDING ANSWERING SERVICE MESSAGES VIA A NEW IPS SIGNAL
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 Multics Commands and
Active Functions manual (Order No. AG92).
NEW TYPE OF IPC EVENT CHANNEL
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.
CHANGES TO THE LOGGING COMMANDS
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.
New Control Arguments for the Logging Commands
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 Multics
Administration, Maintenance, and Operations Commands manual,
Order No. GB64.
SECTION 8
CHANGES THAT AFFECT OPERATORS
This section describes changes that affect operators. It
contains material covering the following topics:
o Changes to the login command
o Changes to various initializer commands
o A new procedure for preaccepting message coordinator
terminals through the DSA network
CHANGES TO THE login COMMAND
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.
-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 Multics
Commands and Active Functions manual, Order No. AG92.
CHANGES TO VARIOUS INITIALIZER COMMANDS
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 Administration,
Maintenance, and Operations Commands 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 Administration, Maintenance, and Operations
Commands manual.
attach and remove Commands
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.
Process Manipulation Commands
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 Person_id.Project_id
o channel_id
o mpx mpx_name
o -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.
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.
accept Command
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.
drop Command
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.
intercom Command
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.
substty Command
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.
define, redefine, and undefine Commands
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.
accept_vchn Command
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.
___________ ___________
accept_vchn accept_vchn
___________ ___________
NAME: ACCEPT_VCHN
SYNTAX AS A COMMAND
accept_vchn virtual_channel_name {authorization} {target}
{bc_list}
FUNCTION
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.
ARGUMENTS
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.
ARGUMENTS
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
___________ ___________
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 *.
EXAMPLES
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
PREACCEPTING TERMINALS ASSOCIATED WITH DSA CHANNELS
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
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.
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.)
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 |
| 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
DYNAMIC ENVIRONMENT BUILT IN FRONTEND_WORKING_DIR
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
CHXMOD.a
TASY >site>dsa>c1m4>sys>TASY
TMCK >site>dsa>c1m4>sys>TMCK
sys >site>dsa>c1m4>sys
NOTES
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.
__________ __________
gen_dn7.ec gen_dn7.ec
__________ __________
NAME: GEN_DN7.EC
SYNTAX AS A COMMAND
ec gen_dn7 <target_datanet_tag> {-args}
FUNCTION
This command performs generation of a loadable and runnable
frontend image to be used by the specified datanet.
ARGUMENTS
-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
__________ __________
gen_dn7.ec gen_dn7.ec
__________ __________
NOTES
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.
____________ ____________
start_dn7.ec start_dn7.ec
____________ ____________
NAME: START_DN7.EC
SYNTAX AS A COMMAND
ec start_dn7 <datanet_tag> {-ctrl_arguments}
FUNCTION
This command makes the specified frontend operational. The DNS
image should be loaded, either from the host system or from any
remote site.
ARGUMENTS
-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)
NOTES
Debug mode remains "on" until another command introduces the
control argument "-no_debug".
___________ ___________
load_dn7.ec load_dn7.ec
___________ ___________
NAME: LOAD_DN7.EC
SYNTAX AS A COMMAND
ec load_dn7 <datanet_tag> {-ctrl_args}
FUNCTION
This command loads the specified frontend from host site with an
existing DNS image, then starts the frontend.
ARGUMENTS
-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)
NOTES
Debug mode remains "on" until another command introduces the
control argument "-no_debug".
___________ ___________
stop_dn7.ec stop_dn7.ec
___________ ___________
NAME: STOP_DN7.EC
SYNTAX AS A COMMAND
ec stop_dn7 <datanet_tag>
FUNCTION
This command stops the specified frontend, leaving it unreachable
from a host site. All users are disconnected.
___________ ___________
dump_dn7.ec dump_dn7.ec
___________ ___________
NAME: DUMP_DN7.EC
SYNTAX AS A COMMAND
ec dump_dn7 <datanet_tag> {dump_args}
FUNCTION
This command asks for a total or partial frontend memory dump,
according to specified control arguments.
ARGUMENTS
All specified dump_args are transmitted to sub_system cxi_driver.
Look at cxid "dump" command for more details.
NOTES
As first dump_argument, you can specify pathname of resultant
dump.
_________ _________
st_dn7.ec st_dn7.ec
_________ _________
NAME: ST_DN7.EC
SYNTAX AS A COMMAND
ec st_dn7 <datanet_tag>
FUNCTION
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
_________ _________
start_dsa start_dsa
_________ _________
NAME: START_DSA
SYNTAX AS A COMMAND
ec start_dsa {-args}
FUNCTION
This command entirely initializes DSA session (specific
processes, data_bases).
ARGUMENTS
-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
_________ _________
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.?
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" ,
=================================================================
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
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
=================================================================
>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 :
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)
Update config with your preferred text editor according to
specific datanet configuration.
<update>.....
=================================================================
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
=================================================================
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
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.
---------------
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
=================================================================
STEP 14
=================================================================
Once system ready, we must generate a runnable image for each
datanet.
x gen_dn7 {c} -rl c1m4 -fw 640
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
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
&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
&- 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.
&-----------------------------------------------------------------------------
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