⟦8b1416ce2⟧

WangText

…00……00……00……00……00……00……00……00……00……18……02……17……0d……17……05……16……0d……16… …15……0b……15…
…14……0a……14……00……14……07……13……0f……13……06……12……0d……12… …12……06……11……0a……11……01……10……0a……10……0b……10……00……10……06……0f……0c……0f……86…1  …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…    …02…
CHAPTER 4

Page

DOCUMENT III          TECHNICAL PROPOSAL      Oct. 8, 1981
Rev.:Feb. 15, 1982

LIST OF CONTENTS                                  Page

4            NETWORK OPERATIONS AND INTERFACES                3

4.1          Introduction                                          4

4.2          General Network Operation                          5
4.2.1       Network Definition                                  7
4.2.2       Network Initialisation                              9
4.2.2.1     NCC System Initialisation                          l0
4.2.2.2     Transport System Initialisation                    l0
4.2.2.3     External Resources Initialisation                  ll
4.2.3       Transport System Control                           ll
4.2.3.1     Link Management                                    l2
4.2.3.2     Virtual Circuit Management                         l2
4.2.3.3     Resource Utilisation Control                       l3
4.2.4       Synchronisation of Network                         l6
…02…Appearances

4.2.4.1     The role of the NCCF in Network                    l6
Operations

4.2.4.2     Coordination of Network Appearances             lB
4.2.4.3     The VARY Command                                    l8
4.2.4.4     Monitoring the VTAM Network                       22
4.2.4.5     Recovery Actions                                    25
4.2.4.6     Geographically distributed control              26
Centres

4.2.5       External Resource Management                     28
4.2.6       Conversation Control                               30
4.2.7       Session Control                                     3l
4.2.8       Recovery                                              32
4.2.8.1     External Resource Failure                         33
4.2.8.2     Link Failure                                         33
4.2.8.3     Multiple Link Failure with                        33
Loss of Connectivity

4.2.8.5     EMH Failure                                           34
4.2.8.6     NCC Failure                                          34
4.2.8.7     Redundant Operation                                35
4.2.8.7.1   Hardware Redundancy                                35
4.2.8.7.2  Node Redundancy                                     36
4.2.8.7.3  EMH Redundancy                                      36
4.2.8.7.4  Gateway Redundancy                                  36
4.2.8.7.5   NMH Redundancy                                       36
4.2.8.7.6  NCC Redundancy                                       36
4.2.8.7.7   FEP                                                    37

                            4.2.8.8     Switchover
                                        37
4.2.8.8.1   PU Switchover
            37
4.2.8.8.2  LTU Switchover
           37
4.2.8.8.3  Disk Switchover
           38
4.2.8.8.4  Supra Bus Switchover
          38
4.2.8.9     Checkpointing
            38
4.2.8.9.1   Recovery/Restart
            38
4.2.8.9.2  Recovery Level
           38
4.2.9       User Services
             39
4.2.10      NNH Application Programs
          40

4.3          Test and Trace Facilities
           4l
4.3.1       Test Functions
             42
4.3.2       Trace Facilities
            43

4.4         Error and Threshold Nandling
         45
4.4.1       Error and Threshold Detection
         45
4.4.2       Presentation
             45
4.4.3       Actions to be taken due to
          47

…02……02…error and threshod messages

4.5          Statistics
              48

4.6          Accounting
              5l

4.7          Security System
             52
4.7.1.1     Mainframe Access Service
          53
4.7.2       Administration
            56
4.7.3       Network Integrity
            59

4.8          Operator Work Station
            60

                            4.           NETWORK OPERATIONS
AND INTERFACES

…02……02…The scope of this chapter is to present a comprehen-

…02……02…sive view of the operations aspect of ACDN.

…02……02…The basis for the proposed operational facilities in

…02……02…the ACDN are:

…02……02…o  The operator facilities being implemented for the

…02……02……02…integrated data network for L M Ericsson.

…02……02…o  The operator facilities being implemented for the

…02……02……02…(FIKS).

…02……02…The primary rationale behind the Christian Rovsing

…02……02…approach is that a clear separation between the net-

…02……02…work service and computing environments is a simple

…02……02…way of protecting the investment in data com-

…02……02…munications equipment and services.

…02……02…The implementation of the above rationale results in

…02……02…an approach to network definition that:

…02……02…o  allows the ACDN operator to configure the physical

…02……02……02…and logical resources of the network independent of

…02……02……02…host systems configuration. Mowever, basic facili-

…02……02……02…ties are provided to synchronise the views of the

…02……02……02…host and the ACDN operator

…02……02…o  allows the ACDN operator to monitor the application

…02……02……02…availability status in the hosts and validate

…02……02……02…access to the applications.

…02……02…o  allows the ACDN operator dynamic interactive visi-

…02……02……02…bility at the Host Session level, Transport Network

…02……02……02…level and the Physical Link level.

…02……02…The primary ACDN operator interface to the host

…02……02…environment is based on a command set if IBM|s Network

…02……02…Control Communication Facility (NCCF). This proposal

…02……02…for ACDN recommends an implementation specific to ACDN

…02……02…based on the NCCF. This proposal also recommends a

…02……02…logical network definition in terms of SNA concepts.

…02……02…The definition concepts that are adopted are Domains,

…02……02…Subareas, major nodes, minor nodes, physical units,

…02……02…links, logical units.

                            4.1          Introduction

…02…  This chapter is structured to provide an overview of
  network operations and to provide an insight into the
  extent of control that can be exercised by the ACDN
  operator.

…02……02…Section 4.2 describes the basic facilities available

…02……02…to operate the network. Section 4.2.4 particularly

…02……02…addresses the task of synchrono*ing network appearan-

…02……02…ces from the point of view of ACDN  operator and the

…02……02…different IBM and Univac host operators.

…02……02…Section 4.3 describes the test and trace facilities

…02……02…that are provided in support of network operations.

…02……02…Section 4.4 describes the Error and threshold handling

…02……02…facilities. The threshold detection facilities provide

…02……02…the ACDN operator with a truly dynamic picture of ACDN

…02……02…operations.

…02……02…Section 4.5 describes the facilities for collection of

…02……02…statistics that are provided in the NMM and in the

…02……02…nodes. Particular emphasis is laid on collecting sta-

…02……02…tistics to assess the transport network performance.

…02……02…Section 4.6 describes the provisions for collection of

…02……02…accounting and changing data.

…02……02…Section 4.7 describes the provisions for security for

…02……02…network access, for network files and general provi-

…02……02…sions for system integrity.

…02……02…Section 4.* presents the physical characteristics of

…02……02…the operator work station.

                            4.2.        General Network
O*********

…02……02…This section describes the basic facilities used to

…02……02…operate the network, while the special facilities are

…02……02…described in the subsequent sections.

…02……02…If nothing else is stated, the operation is on-line at

…02……02…the NCC i.e. it has an immediate effect on the

…02……02…network.  Off-line operation consists of manipulating

…02……02…files at the NMH which m{y have a later effect on the

…02……02…network operation.

…02……02…The general network operation may be broken down into

…02……02…the following classes of operation:

…02……02…o  Network definition (off-line)

…02……02…o  Network initialization

…02……02…o  Transport system control

…02……02…o  External resource management

…02……02…o  Conversation control

…02……02…o  Session control

…02……02…o  Recovery procedures

…02……02…o  User services.

…02……02…Network definition must be done in ACDN for the total

…02……02…system and in each participating host for the part of

…02……02…the network which the host must be able to access.

…02……02…The network is divided in two main parts: the

…02……02…transport system and the external resources.

…02……02…The transport system is only defined to the hosts to

…02……02…the extent demanded by the host architecture, refer to

…02……02…chapter 6 for a discussion in the IBM case.

…02……02…The external resources are defined in the proper

…02……02…structure to the hosts, but the detailed terminal

…02……02…definitions can be adapted to conform to supported

…02……02…terminal types within the host architecture.

                            Network initialization can
be done when the proper
network definitions are available in the NCC and in
the hosts.  First, ACDN is initialized through three
steps which initializes in turn the NCC, the transport
system and the external resources.

This initialization consists of several commands
required to load the software of each node followed at
e{ch node by a command to load of the local network
configuration into the nodes.  These commands may be
collected in a file which can then be activated
through a single command.

Each host can independently start its network when
ACDN is initialize*. ACDN will then automatically
synchronize with each host provided that the network
definitions are compatible.

The transport system control is in principle done
automatic{lly by the NCC.  However, the operator may
intervene at both the link and virtual circuit level
to perform trouble shooting.

Conversation control is the level where the operator
gets a unified view of the data traffic currently
ongoing in ACDN.  Through status displays the operator
is able to monitor the load on the system.  He may
also, but generally need not, intervene to adjust the
resources utilization of the different conversations.

Session control is the level where the network
operator bridges the gap between the standard ACDN
conversations and the different types of sessions
sustained against the hosts. The operator may perform
session set-up and take-down as a service on behalf of
end user resources which are not themselves able to
establish sessions.

The management of external resources is left to the
operator to the extent that he can perform
reconfigurations and initiate tests on failed
resources. Mowever, the synchronization of
reconfigurations wfth the *osts are performed
automatically by the NCC.

                            Recovery is performed at many
levels within ACDN since
the general principle is that each layer in the system

*** LINE REJECTED ***

errors are recovered automatically, and will only
generate error events if they occur more often than
specified by a threshold value.

Permanent errors always generate error events, but in
many cases, the resource in error is automatically
excluded from operation, and therefore the operator
need not take any immediate action.

The c{pacity of the network may, however, be degraded
to a level where either new resources (links) must be
made available, or some sessions must be terminated.

The last class of recovery problem includes complete
failure of a CR80 computer e.g. a node or a complete
isolation of a part of the network through multiple
link failures.

In these cases operator intervention is required to
perform a partial or complete restart of ACDN.

On-line user services consist of communicating with
the users either through a canned message given to all
users at logon time, or through broadcasts to selected
sets of users.

A user is also able to send a message to the operator
who will receive it as an event.

4.2.1       Network Definition

The network must be defined both globally, i.e., the
complete actual configuration, and locally to each
host.

The global ACDN definition is a hierarchy which
defines both the external resources (participants and
attachment) and the internal resources, e.g.
internodal and access links.

                            The definition is grouped
as follows:

Transport Systemnodes (node-id)

…02…link (link-id, LTU-addr.)

Virtual circu*t capacity

links (link-id)

connection

…02…speed

transport station (TS-id)

…02…sub-transport station (DTE-addr.)

External Resource Type

host types

line types

controller types

terminal types

line group, main type (LTU-addr.)

line, sub-type (line-id)

…02…controller (controller-id, poll-addr.)

…02…terminal (term-id, local-addr.)

NODE Configuration (NODE-id)

channel (channel-id, channel-I/F addr.)
host (host-id)

line (line-id, LTU-addr.)

host or communication controller (host-id)

…02…external resource (resource-id)

The definition is performed off-line on the NMH
via an application which via suitable forms, allows
the operator to fill in the necessary parameters. The
defined network configuration is stored in object
files from which they can be later loaded during
initialisation, recovery or dynamic reconfiguration.

Commands:

DEFINE NET (in-definition-file)

…02…-     (out-definition-file)

This command starts the network definition application
changed.

                            If in-definition-file is specified,
an existing
definition is used as starting point.

Out-definition-file is, if specified, used to store
the new definition.

Apart from the form editing facilities, DEFINE-NET is
able to merge and split definition files.   It also
contains a print utility for easy and legible forms
print out.

The definition of the networks seen by the hosts are
done at the hosts.  These definitions must use the
same names as ACDN to identify each external
resources.  To allow ACDN to perform adddress
translation between ACDN {nd host network addresses,
a
resource name-address table *ust be transferred to the
NMH prior to network initialisation.

This is done vi{ the file transfer application during
a previous operational period of ACD*. The file is
stored on disk at the NMH and thus ready for any
subsequent startuP of ACDN.

4.2.2       Network Initialisation

The entire network is initialised through three
phases:

o  NCC System initialisation

o  Transport System initialisation

o  External Resources initialisation.

At the successful end of the first phase, the NCC is
able to start remote initialization of all networ*
computers. After this second phase, the standard net-
work is ready to provide transport services.

When phase three is finished, the entire network is
ready to accept end user requests.

Note that there may be a fourth phase, namely the
pseudo initialisat*on performed by each VTAM to
synchronize the individual VTAM networks with ACDN.

                            4.2.2.1     NCC S************************

…02……02…The NCC is bootloaded from the system file on the con-

…02……02…nected disc.  When this is terminated, the Terminal

…02……02…Operating System (TOS) is activated, using the system

…02……02…console as TOS master console.

…02……02…The operator terminals are now assigned to TOS and the

*** LINE REJECTED ***

…02……02…dard TOS commands.

…02……02…The permanent NCC programs are loaded via TOS and the

…02……02…designated master operator terminal and the designated

…02……02…master operator terminal can now accept operator log-

…02……02…on and further network initialisation commands.

4.2.2.2     Trans********************************

…02……02…Nodes may be loaded and initialised from the NCC when

…02……02…they are connected via an operable link either to NCC

…02……02…or to a node which is already part of the network.

…02……02…Normally, however, they are bootloaded from the system

…02……02…file on the locally connected disc, i.e. the disc of

*** LINE REJECTED ***

…02……02…network and the control conversations are set up.

…02……02…Commands:

…02……02…CLEAR node-id

…02……02…This command removes the node from the network (if

…02……02…it was already included) and forces the node computer

…02……02…into a passive basic state from which it can be

…02……02…remotely dumped or loaded.

…02……02…LOAD node-id program-file

…02……02…This command loads a node computer which is in its

…02……02…basic state with the complete system found in

…02……02…program-file.

…02……02…START node-id configuration-file

…02……02…This command initialises the links, virtual circuits

…02……02…and transport stations in the node, as defined in the

…02……02…transport system configuration-file.  This causes the

…02……02…node to become part of the network.

                            4.2.2.3     External Resources
Initialisation

…02……02…The external resource defined in the local networ*

…02……02…configuration can be included when the node has been

…02……02…initialised. This is done based on the definition file

…02……02…which states which external resources {re to be

…02……02…initially included.

…02……02…Command:

…02……02…INCLUDE node-id node-configuration-file

…02……02…This command will transfer the node-configuration-

…02……02…file information to the node, thus causing the node to

…02……02…perform inclusion of all resources in its local

…02……02…network which are defined to be included.

…02……02…Excluded defined resources may be included later via
a

…02……02…configur{tion command.

…02……02…A message is displayed on terminals to indicate that

…02……02…ACDN is ready.

…02……02…Input from hosts is enabled, but in the case of an IBM

…02……02…VTAM host, it is the responsibility of the VTAM

…02……02…operator to initiate traffic by starting WTAM.

4.2.3       Trans***********************

…02……02…Transport system control manages the physical

…02……02…resources which are available to support

…02……02…conversations, in other words, the links and the

…02……02…packet switching part of the nodes.

…02……02…The main functions are:

…02……02…- Link management

…02……02…- Virtual Circuit management

…02……02…- Resource Utilisation control

…02……02…These functions are mainly available to the operator

*** LINE REJECTED ***

…02……02…automatically by other parts of the system.

                            4.2.3.1     Link Mana***********************************************************

…02……02…Each link in the network can be managed individually

…02……02…through NCC operator commands.

…02……02…Links which are not directly connected to the NCC are

…02……02…managed via a node which is directly connected to the

…02……02…link.  For this to be possible that node must be

…02……02…included in the network {nd have its control

…02……02…conversations with the NCC open.

…02……02…Commands:

…02……02…INITIATE-LINK Link-id (parameters)

…02……02…This command causes a level 2  link connect to be

…02……02…issued by the Link protocol for the designated link.

…02……02…If the connection is successful, the link is then

…02……02…included in the routing calculation.

…02……02…TERMINATE-LINK Link-id

…02……02…This command causes a level 2 disconnect to be issued

…02……02…by the Link protocol for the designated link.  Then

…02……02…the link is excluded from the routing calculation.
A

…02……02…link must be terminated before any link tests or

…02……02…remote dump or load operations can be performed on

…02……02…that link.

…02……02……02……02……02…link-id

…02……02…LINK-STATUS    node-id

…02……02…This command displays the definition and status

…02……02…of one link or all links on a node.

4.2.3.2     Virtual Circuit Mana*******

…02……02…Commands:

…02……02…INITIATE-VC   source-addr dest-addr.

…02……02…Normally, virtual circuits are not set up manually,

*** LINE REJECTED ***

…02……02……02…certain connections. Source-addr and dest-addr are two

…02……02…subscribers of the packet subnetwork.

…02……02…TERMINATE-VC node-id channel-id

                            Removes a virtual circuit
on the designated node.
VC-clear is then automatically propagated to the two
subscribers of the VC.  This function is used mainly
to clean up in cases where a virtual circuit has not
been properly cleared by the system itself.

VC-STATUS node-id channel-id

This command obtains the virtual circuit parameters
(PVC or VC, next-channel-id  window size, max-conv.)
and the status of the VC (internal-state, number of
open conversations, number-of-packets-on-output-queue,
traffic-volume).

A complete virtual circuit may be traced from source
to destination through successive use of this command.

4.2.3.3     Resource Utilisation Control

This control is performed by parameter setting at
various levels.  Some of the parameters are determined
by the users, others at system generation time, and
others by the network definition or network operator.
The parameters are divided into three major groups:

1)  Conversation parameters

2)N  Network parameters

3)   Routing algorithm

1)  Conversation ************

These parameters are affecting the user of the
conversation directly.  The parameters which can be
changed are:

o  maximum message length

o  number of packets in transit.

2a) Static NetworkParameters

During initialisation of the network, certain
parameters are set which are valid during all network
operations until the network is closed down.  The
parameters to be changed are:

                            o  maximum frame size

o  maximum packet size

2b) D******************************

…02…*****************************************************************

                            3)  Routin*************

A certain strategy has to be decided upon, on how to
change the routing.  Several factors must be taken
into account, such {s:

o  topology

o  trunk speeds

o   load on nodes and trunks

o  traffic type

These factors are being used with different weight
factors by the routing algorithm.

The time elapsed between two routing updates is
another factor which has to be part of the routing
strategy.

Commands:

ROUTINQ  node-id

This command displays either the complete routing
table in the NCC or the specific routing table for a
single node.

The table shows for (link, destination)-pair, the cost
induced by using that particular link to reach the
destination.

                            4.2.4       S*********************************************

…02……02…The current Christian Rovsing aproach for providing

…02……02…network control independent of the host based access

…02……02…methods is influenced by IBM SNA and Univac DCA

…02……02…environment.

…02……02…The task of synchronising network appearences from the

…02……02…hosts and from the network control center is achieved

…02……02…by utilising host based application program

…02……02…interfaces. Such a host based facility in an IBM

…02……02…environment is the Network Communications Control

…02……02…Facility (NCCF). A simil{r application program is

…02……02…available under CMSll00. The following description

…02……02…delineates the operator control facilities that are

…02……02…made available to ACDN with the assumptions:

…02……02…o  the host software environment has an application

…02……02……02…program that interfaces to the communication access

…02……02……02…methods to provide access to configuration tables

…02……02…o  for definition purposes each ICC and its associated

…02……02……02…terminal populations is treated as a subarea. The

…02……02……02…ICC is treated as PU.T4, cluster controllers and

…02……02……02…associated terminals as PU.T2 or PU.T1.

4.2.4.1     The role of the NCCF in Network O***********

…02……02…The NCCF program is located in the host.  The NCCF

…02……02…prov*dees centralised operatrr cnntrol frr ACF/VTAM,

…02……02…NCCF like program provides operator control in the

…02……02…Univac environment.

                            This means that the ACDN operator
is able to cause
VTAM or CHS/1100 to obtain sets of networR definitions
to support a specific configuration of the network to
modify this configuration.  Likewise the ACDN operator
may monitor the VTAM|s view or CHS/1100 view of the
ACDN.

In order to gain access to the NCCF services the
operator logs on to the NCCF through an appli-
cation which makes the console appear as an IBM 3270
display unit.  One NCCF program is located in each
host and the LMENET operator must log on to each NCCF
program in order to keep track of all the hosts.

A successful log on connects the operator to NCCF via
the Application Program Interface (API). Through the
Programmed Operator Interface (POI). NCCF issues VTAM
operator comm{nds.  Through the same interface NCCF
receives VTAM operator control responses and unsoli-
cited operator control notification messages.

In addition to the above mentioned 2 interfaces, NCCF
communicates with a 3rd interface, namely the Com-
munications NetworR Management  (CNN) interface.  The
CNM interface provides access from a host application
to obtain CNM data.

NCCF provides a program environment base for user writte
applications which utilize the above mentioned inter-
faces. See fig. 4.2.4.1.

The program base may be utilized by writing command
processors, command lists and user exits in NCCF.  A
command processor is logically a subroutine of NCCF.
A command list is a list of VTAM operator commands.
This command   list is invoked by a LMENET operator
command.

Two commands are not allowed from a NCCF operator.
The commands are START and HALT which must be issued
from the host system console operators.

The NCCF operator may issue the commands VARY,
DISPLAY.  By changing the parameters of these com-
mands, the scope of VTAM is covered.

Before NCCF may be started the network has to be
defined to VTAM.  This topic is covered in the

following section.

4.2.4.2 Coordination of
Network A***********

                            (appl. program major node

(name

VARY NET, ACT,ID =

(appl. program minor node

(name

ACT is an option to specify that the m{jor/minor node
is to be activated.

In order to deactivate an application program major

*** LINE REJECTED ***

(ap*l. program major node

(name

VARY NET, INACT, ID=

(appl. program minor node

(name

INACT means that the major/minor node is to be
deactivated.

NCP major node:

A network control program (NCP) is a major node in the
communication path from an application program to an
LU in the network.  A NCP major node is activated by
entering:

VARY NET, ACT, ID =   (ncp major code name)

The NCP major node is deactivated by entering:

VARY NET, INACT, ID = (ncp major node name)

Physical unit:

A PU which was not activated when its major node was
activated, is activated by entering:

VARY NET, ACT, ID = (physical unit name)

                            Each of the physical units|
  associated logical units
whose initial status are defined as active are acti-
vated along with the physical unit.

When a physical unit is deactivated, all the logical
units associated are deactivated as well. The deac-
tivation of the logical unit cannot be completed until
the active logical units have completed their
sessions.  To deactivate a physical unit enter:

VARY NET, INACT, ID = (physical unit name).

Logical units:

Before activating the logical unit, the physical unit

*** LINE REJECTED ***

A logical unit can be deactivated through deactivation

*** LINE REJECTED ***

VARY NET, INACT, ID = (logical unit name).

…02….

Logging on logical units: (network operator log on):

The network operator log on is an operator request on
behalf of a logical unit for establishing a session
between the logical unit and an application program.

VARY NET, ID = name, LOG ON = (applicat. prog. name)

ID = name

specifies the name of the logical unit.

LOG ON = application program name specifies the name
if the application program to which the logical unit

                            Terminating a session between
logical units to ter-
minate a session enter

VARY NET, TERM, SID = (session identifier)

TERM indicates that a session is to be terminated.

SID specifies the session identifier for the session
to be terminated.

Controlling cross-domain sessions:

For each ACF/VTAM a cross-domain resource manager
(CDRM) must be defined.  The CDRM handles the ini-
tialisation and termination of cross-domain sessions.

Cross-domain resources are logic{l units that are
owned by another dom{in (CDRSC).

The CDRN major node:

To activate a CDRM major node enter

VARY NET, ACT, ID = (cdrm major node name).

To deactivate a CDRM major node enter

VARY NET, INACT, ID = (cdrm major node name).

The CDRM minor code:

To activate a CDRM minor node enter

VARY NET, ACT, ID = (cdrm minor node name).

To deactivate a CDRM minor node enter

VARY NET, INACT, ID = (cdrm minor node name).

The CDRSC major node:

Before activating a cross-domain resource minor node,

the CDRSC major node must be active.

Activ{ting a CDRSC major node:

VARY NET, ACT, ID = (cdrsc major node name).

                            Deactivating a CRDSC major
node:

VARY NET, INACT, ID = (cdrsc major node name).

Activating a CDRSC:

VARY NET, ACT, ID = (cdrsc name).

Deactivating a CDRSC:

VARY NET, INACT, ID = (cdrsc name).

The above mentioned commands are all used to update
VTAM on the network configuration.

A similar set of commands are available to the ACDN
network operator in order to control the network.

To facilitate the tasks of the operators, the streams
of commands will be tied together.  In many
situations, i.e. a command issued to the ACDN auto-
matically issues another command to the hosts.  As an
example is mentioned the case where a command is
issued to the ACDN changing the configuration.  This
command causes another command to be issued automati-
cally in order to update the hosts on the new con-
figuration.

4.2.4.4     Monitorin**********************
*********************************************************************

                            In response to this command
ACF/VTAM displays the
status of all application program major nodes, NCP
major nodes, local non-SNA major nodes, local SNA
major nodes, CDRSC and CDRM m{jor nodes.

The display first gives you a heading saying the
displayed messages are for major nodes.

For each active major node the following information
is displayed

- the name of the major node

-  what kind of major node it is

-  an indication that this major node is {ctive.

Displaying the status of application program  major
nodes and application programs.

All active application program major nodes and respec-
tive applications are displayed by entering:

DISPLAY NET, APPLS.

Displaying the status of a local non-SNA major node:

DISPLAY NET,ID = (local non-SNA major node name).

Displaying the status of a local SNA major name:

DISPLAY NET, ID = (lokal SNA major node name).

Displaying the status of application program:

DISPLAY NET, ID = (application program name).

Displaying the status of a NCP:

DISPLAY NET, ID = (ncp major node name).

Displaying the status of clusters and physical units

*** LINE REJECTED ***

Displaying the status of a
cluster control unit
or physical unit:

DISPLAY NET, ID = (cluster control unit name
(physical u,*t name).

Displaying the status of all logical units:

DISPLAY NET, TERMS.

Displaying the status of a logical unit:

DISPLAY NET,ID = (logical unit name).

Displaying the status of all active CDRM major
nodes:

DISPLAY NET, CDRMS.

Displaying the status of a CDRM major node:

DISPLAY NET, ID = (cdrm major node name).

Displaying the status of all active CDRS major
nodes:

DISPLAY NET, CDRSCS.

Displaying the status of a CDRS major node:

DISPLAY NET, ID = (cdrsc major node name).

Displaying the status of a CDRSC:

DISPLAY NET, ID = (cdrsc name).

The above mentioned examples of DISPLAY commands are
all used to monitor the ACDN|s appearance to
ACF/VTAM.

This causes all sessions with logical units attached
to the node to be lost.

                            4.2.4.5     Recover***********

…02……02…In the event of failure of some of the network resour-

…02……02…ces the network operator must take some action in

…02……02…order to bring the network back to normal operation.

…02……02…In the following some situations are described where

…02……02…the NCC provides recovery action.

…02……02…A host fails.

…02……02…A lost subarea SNA request is sent to the other hosts.

…02……02…Sessions running between logical units and application

…02……02…programs in the failing host are lost. Both the VTAM

…02……02…tables and NCC tables are updated according to this

…02……02…event.

…02……02…The list of host application programs located in the

…02……02…NCC has to be upda*ed. Those application programs

…02……02…belonging to the failing host are marked

…02……02…"unavailable".

…02……02…When the host has been brought back to normal opera-

…02……02…tion and the host system operator has issued a START

…02……02…VTAM command, a set of initialisation commands are

…02……02…'   sent to the ACDN. The NCC recognizs these commands
and

…02……02…takes the required actions.

…02……02…A restart after host failure is very similar to the

…02……02…network initialization situation which is described in

…02……02…seciton 6.1.3.

…02……02…A node fails.

…02……02…All sessions using the node as an intermediate node

…02……02…will be routed through an alternative node, if it

…02……02…exists. All sessions locally attached to the failing

…02……02…node are lost. The failure is reported to all hosts

…02……02…via a host subarea SNA request.

…02……02…This causes all sessions with logical units attached

…02……02…to the node to be lost.

…02……02…To restart the node it has to be reloaded from the

…02……02…NCC.  This is done by the command VARY NET, LOAD,

…02……02…parameters.  In the parameter field the name of the

…02……02…node to be loaded is given.  When the node has been

…02……02……02…reinitialized it is reactivated by VARY NET, ACT,

…02……02…major node name.

                            A trunk fails.

All sessions using this trunk will be rerouted through
alternative trunks.  If a node becomes unreachable due
to multiple trunk failures, the line defined in VTAM
to connect that node to the FEP is forced deactivated.
This is provided with the link-inoperative SNA
request.

A failing node or a failing trunk is always reported
back to the networR control center.  The hosts are not
informed if the logical network configuration has not
changed.

A terminal is lost.

If a terminal has become unavailable to the network
both the hosts and the NCC are being updated on the
new configuration with a VARY NET, INACT, parameters
command.

4.2.4.6     Geo************************************************

The scope of this section is to present the principles
of operation supporting two network control centres.

The primary need is for the two control centres to be
synchronised with respect to:

- Network Appearance

…02…External Resource Status

before a takeover can be attempted by the back up of
NCC.

Network********************************

All operator initiated changes to network

configuration at the active control centre is

automatically passed on to the back up control centre

the same priority as network control traffic

containing status information.

***********************************

When the active NCC grants a session and allocates the
TSUs, VCs and the associate physical route, the back
up NCC is updated with session ID, conversation ID,
route information.

No provision is made for synchronization at the level
of conversation unit|s sequence number.

External Resource Stat**

**********************************************************************

                            4.2.5       External Resource
Mana*******

…02……02…The management of external resources is controlled by

…02……02…the network operator at the active NCC.  All permanent

…02……02…error situations generate events in the NCC that

…02……02…should be acknowledged by the operator, and lead to a

…02……02…corrective action. If the error cannot readily be

…02……02…resolved, the resource in error should be excluded

…02……02…from the network to isolate it from any side effects

…02……02…caused by the erroneous resource and to allow thorough

…02……02…fault investigation through test facilities.

…02……02…Control of the resources is done according to the

…02……02…hierarchy used for the network definition, i.e.

…02……02…o  Local network

…02……02…o  Line group

…02……02…o  Line

…02……02…o  Controller

…02……02…o  Terminal

                            Each resource has two state
variables:

o included/excluded

o iperable/in-error

and resources capable of being in session have one
more state variable:

o free/in-session

The external resource management functions can be used
to bring a resource into a known state.

When the system is initialised or later, when it is
running, new resources can be made known to the
system.  Whether they are included at the same time
depends on the specification in the definition file.

Likewise, when a resource is excluded from the
network, it can be specified that it be completely
deleted and thus made unknown.

Commands:

…02……02……02……02……02……02…node-configuration-file

INCLUDE node-id

…02……02……02……02……02……02…resource-id

If the first alternative is used, the resource is both
defined to ACDN {nd, if it is defined to be initially
included, then this is also done.

In the latter case, the resource is unconditionally
included.

Included resources are *ut in their initial state,
which is:

included, operable, and free.

Inclusion of resources require synchronization with
VTAM.  Note that if the resource is not defined to
VTAM, a dynamic reconfiguration must be performed in
VTAM,before the resource can be accessed by VTAM.

                            EXCLUDE resource-id  DELETE

This command excludes the named resource (and all
depending resources) from normal use.  If the resource
is in session, the session is abnormally terminated.
If the DELETE option is specified, the resource is
made unknown to ACDN.  This function requires
synchronization with VTAN.

4.2.6       Conversation Control

Conversations are the highest level standard protocol
used in ACDN.  Therefore, (and since there is always
a
one to one correspondance between sessions and
conversations) the control of conversations permit the
most detailed and comprehensive resource control
within ACDN.

The conversation is re-established in case of network
failures which do not involve the two transport
stations which are connected via the conversation.
This allows the conversation to resume without loss of
data when alternative network resources have been
assigned to it.  In this case, the session using the
conversation is not aware of the temporary suspension
of the conversation.

Conversations are uniquely identified by their two
CAP-id|s which permit global identification both of
the conversation itself and its data units.

Commands:

…02……02……02……02…TS-id

CONVERSATION

…02……02……02……02…VC-id                     type     state

…02……02……02……02…resource-id

This command allows either a global status overview

(no parameter specified) giving for each transport

station, the number of conversations of each type

(control, transparent, interactive, batch,
meatrictions is specified, all conversations

satisfying the restriction will be displayed with:

                            o  conversation-id

o  corresponding session-id

o  maximum resource claim

o  current resource utilisation.

INTERRUPT conv-id

This command suspends the conversation without loss of
data.  This may be done to allow examination of the
conversation in a steady state or to allow change of
the maximum resource claim for the conversation.

…02……02……02…conv-id

…02……02……02…ALL

RESUME    TS-id         type    state     resource-change

…02……02……02…VC-id

…02……02……02…resource-id

This command resumes one or more suspended
conversation which satisfies the selection criteria
given in the first line.

If the resource-change is specified, then the
conversations will continue with the new set of
resource requirements.  The credit value and the
conversation class can be changed.

…02……02……02…conv-id

TERMINATE         TS-id

…02……02……02…VC-id                type     state

…02……02……02……02…resource-id

This command terminates the selected conversations and
corresponding sessions.

4.2.7       Session Control

******************

Since several different types of sessions may exist
within ACDN, and since these sessions may be partly
controlled by the particip{nts, the session control in
ACDN is only used at a level n,eded to synchronize
with the participants and to provide certain end user
functions. There is one exception, however, the
session limit is used as a convenient tool for a gross
resource control.

                            Sessions are identified by
a unique session. This is
feasible since a terminal can only be in one user
session at a time (control sessions like SSCP-LU
session are not managed via session control, but via
configuration management).

Commands:

…02……02……02……02……02…user-id-1    appl-id-2

INITIATE-SESSION          user-id-2

…02……02……02……02……02…term-id-1    term-id-2

This command initiates establishment of a session
between an attachment, either identified by the
user-id-1, or the term-id-1, and a participant
application or another attachment.

The session is not established until id-2 acknowledges
the session initiation.

Otherwise the selected sessions are displayed with
end-user identification (appl-id, term-id and user-id
and corresponding conv-id.

The state may be : in-session or session-pending
(which indicated a session being established).

SESSION-LIMIT           node-id (limit)

This command displays or sets the maximum number of
sessions allowed in a given node.  A decrease of the
limit will not cause sessions to be terminated.

4.2.8       Recover*

Recovery in ACDN has two aspects, the first is to
second is to synchronize with the external resources.

Synchronization of attachments is relatively simple
since it consists of either:

o  Session termination, if the node to which the

…02…attachment is connected has not failed.
o  Reinitialisation of the local network if the

…02…connecting node failed

                            Several functions can be used
to recover ACDN itself,
depending on the type of failure:

o  External resourse failure

o  External resource failure

o  Link failure

o  Multiple link failure with loss of connectivity
o  Node failure

o  EMH failure

o  NCC failure

4.2.8.1     External Resource Failure

All sessions with the failed resource are terminated.
If the error is judged to be recoverable, the resource
is kept included and regularly tested to see if the
error conditions have cleared.  Otherwise, the
resource is excluded from ACDN.  This saves resources
and allows a deeper investigation of the problem
through use of tests.

4.2.8.2     Link Failure

A link failure will unconditionally cause all virtual
circuits on that link to be cleare* (or reset in case
of PVC|s).  The conversations carried out by theare available
the conversations will automatically be
resumed via VC|s using other links.  If resources are
short the low priority conversations will be kept
suspended.   It is then the responsibility of the
network operator to resume those conversations when he
judges that sufficient resources are available.  This
is done via the RESUNE command.

4.2.8.3     Multi***************************************************

In this case also, the conversations are suspended.
Back up links may be supplied before a RESUME command
is issued, but if this is not possible, the isolated
part of the network must be excluded.

4.2.8.4     Node Failure

…02……02…**************

…02……02…If a node fails, its local network is excluded and the

…02……02…node is forced to its basic state by a CLEAR command.

…02……02…In this state, it can be dumped and reloaded remotely.

…02……02…The restart and following initialization follows the

…02……02…scheme from network initialisation, except the state

…02……02…of the local network, can be synchronized with the

…02……02…state stored in the NCC at the time of node failure.

…02……02…A node failure causes all sessions passing through the

…02……02…node to be terminated.  The node must be restarted

…02……02…from the NCC.  In this state the node will respond to

…02……02…all connected hosts with a message which causes the

…02……02…hosts to perform a reinitialization of their network

…02……02…status. Following this the necessary network

…02……02…configuration coordination commands may be sent to the

…02……02…hosts to synchronize their status with the ACDN

…02……02…status.

…02……02…If the node cannot be forced into its basic state, no

…02……02…remote recovery facilities exist.

4.2.8.5     EMH Failure

…02……02…*************

…02……02…A catastrophic failure to the EMH results in loss of

…02……02…protected message service. The EMH must be restarted

…02……02…from the NCC. The EMH will be responsible for

…02……02…re-establishing the content of the protected message

…02……02…data base while the NCC in co-operation with the node

…02……02…re-established the pending connections between the EMH

…02……02…and the PMS destinations. Thes re-establishment is

…02……02……02…like that for host connections. The EMH is responsible

…02……02…for re-transmitting those RMS messages for which it

…02……02…has responsibility and which had not been flagged as

…02……02…delivered to the network. The noeds automatically

…02……02…request a re-transmission of PMS messages which the

…02……02……02…node has been unable to deliver (note that the EMH

…02……02…does only allow re-transmission of certain types of

…02……02……02…PMS traffic, e.g. tickets are not retrieveable).

4.2.8.6     NCC Failure

…02……02…*************

…02……02……02…All conversations monitored by the failing NCC are

…02……02……02…terminated.  If the failure is caused by hardware

…02……02…malfunction in the NCC itself, a configuration of the

…02……02…NCC on part of the local node is performed before

…02……02……02…restart of the NCC-node complex.

                            If the failing NCC was not
the master NCC, the master
NCC will connect to the reinitialised NCC-node complex
and operation m{y resume.

In case the failing NCC was the master NCC, the
physical network control must be taken over, either by
another NCC or by the reinitialised NCC.  In this
case, the NCC will obtain the internal network
configuration from its definition files and then
obtain the actual status of the external resources.
This is done by issuing a command to all nodes to send
back their local network status tables.  The union of
all local network status tables forms the NCC external
resources status.

Command

NODE-STATUS  node-id  resource-id

This command transfers the definition and status
of the designated resource from the node to the
NCC and allows the NCC to adjust its own
definition and status tables.

4.2.8.7     Redundant O*********

o  To provide a high level of service to users

…02…redundant equipment is used at vital points in the

…02…AIR CANADA NETWORK.

This section addresses:

-  hardware redundancy

-   switchover

-  check-pointing

-   recovery/restart

which are covered in following subsections.

4.2.8.7.1   Hardware Redundanc*

The AIR CANADA NETWORK site components (Node, EMN,
GATEWAY, NCC, FEP) have complete internal redundant

hardware.

The NMH contains non-redundant equipment.

                            The following subsections
describe specific hardware
redundancy at the various AIR CANADA NETWORK com-
ponents .

Generally supra buses are dualized. Trunks to nodes
and between nodes are multiple to allow a software
vice redundancy.

4.2.8.7.2  Node Redundanc*

In each node one standby PU exists. It can substitute
any of the up till 3 remaining PUs.

The node disks are handled as mirrored, i.e. updated
concurrently.

Also, one backup LTU exists. It can substitute any of
the up till 11 remaining LTUs.

4.2.8.7.3  EMH Redundanc*

The EMH contains an active and a standby PU.

The EMH disks are handled as mirrored, i.e. they are
updated simultaneously.

For LTUs one spare LTU exists for the remaining 3
LTUs.

4.2.8.7.4  Gatewa**************************************************************

The Gateway contains an active and a standby PU.

A spare LTU exists for one of the remaining 6 LTUs.

4.2.8.7.5  NMH Redundanc*

As the NMH role in the AIR CANADA NETWORK is non vital
it contains no redundant elements.

4.2.8.7.6  NCC Redundanc*

The NCC is geographically backed up. One NCC contains
no redundant elements.

                            4.2.8.7.7  FEP

…02……02…***

…02……02…One standby PU exists. It can substitute any of the

…02……02…remaining N FEPs.

…02……02…The FEP disks are mirrored.

4.2.8.8     Switchover

…02……02…The switchover forms an active component to a standby

…02……02…component and is executed via the watchdog. The watch-

…02……02…dog is a selfstanding comuter which monitors and

…02……02…controls via a CCB (configuration control bus) all

…02……02…crates in an AIR CANADA NETWORK element (Node, FEP,

…02……02…EMH, NCC, NMH or GATEWAY. In order to avoid authority

…02……02…conflicts between PUs the actual switchover decision

…02……02…will be made by the watchdog.

4.2.8.8.1   PU Switchover

…02……02…A PU switchover implies that:

…02……02…-  the current active PU is electrically disconnected

…02……02……02…from its peripherals

…02……02…-  the standby PU is activated and via its separate

…02……02……02…databus it can access the peripherals of the former

…02……02……02…active PU.

…02……02…The decision for a PU switchover may be:

…02……02…-  the watchdog having monitored a PU error via the

…02……02……02…CCB or the non-arrival of a "keep alive" message,

…02……02……02…which the PUs periodically (second basis) sends to

…02……02……02…the watchdog

…02……02…-  the PU having monitored an internal irrecoverable

…02……02……02…hardware or software error.

4.2.8.8.2  LTU Switchover

…02……02…An LTU switchover implies that the lines (e.g. trunks)

…02……02…to the current active LTU {re switched electrically to

…02……02……02…the spare LTU.

…02……02…LTU software is to be loaded during LTU initialization

…02……02……02…so it is easy to cope with a spare LTU for different

…02……02……02…LTU types.

                            4.2.8.8.3  Disk Switchover

…02……02…Mirrored disks have separate disk controllers, so a

…02……02…switchover is noly performed software.

4.2.8.8.4  Su**********************

…02……02…Supra bus switchover is performed in software.

4.2.8.9     Check*********

…02……02…A checkpoint records the state of an activity e.g. a

…02……02…session or a message.

…02……02…At specific events e.g. sign on the active PUs

…02……02…transmits checkpoints to the standby PU memory via the

…02……02…supra bus or to a disk in order to provide an

…02……02…acceptable level of recovery at the time of restart.

4.2.8.9.1   Recover**********

…02……02…Restart refers to the actions to bring up a former

…02……02…active or a standby PU as active i.e. reestablishes

…02……02…the dynamic behaviour of the system.

…02……02…Recovery refers to the reestablishment of continuity

…02……02…in memory and backing storage contents during a restart.

4.2.8.9.2  Recover********

…02……02…The contents of checkpoints to disk or to a standby PU

…02……02…defines the recovery level.

…02……02…The checkpointing to disk is used to handle the total

…02……02…system failure case.

…02……02…The checkpointing to the standby PU is used to:

…02……02…-  provide a fast switchover (seconds)

…02……02…-  provide a fine level of recovery due to the high

…02……02……02…supra bus throughput.

                            A PU switchover and subsequent
restart takes less than
1 minute.

The contents of checkpoints will enable recovery of:

-  sessions i e  .he status of sign in/out
-  terminal and printer status (e.g. paper low)
-  messages e.g. a line from a terminal
-  network control commands e.g.

…02…-  alarms

…02…-  statistics

…02…-   configuration updates.

4.2.9       User Services

****************

The network operator can communicate with the network
in three ways:

o  Logon message

o  Broadcast message

o  User message

Commands:

LOGON-MESSAGE  text

This command allows one text line to be stored and
output on all devices which support this when they
perform logon to ACDN.

If no text is specified, the message currently output
during logon is displayed.

…02……02……02…term-id-list

BROADCAST                        text

…02……02……02…user-id-list

This command tries to output the text on all terminals
which are identified either directly or indirectly,
through the id|s of the logged-on users.

It is, however, the decision of the receiving user

*** LINE REJECTED ***

his control session to receive the text.

User messages are signalled to the operator as events.
The operator may answer the user via the broadcast
command.

4.2.10      NMH A***********************

The operator can, via a standard command, load and
execute application programs in the NMH. Part of the

application programs.

                            4.3         Test and Trace
Facilities

…02……02…*****************************

…02……02…During network initialization and upon node restart

…02……02…the NCC initiates test connections to verify proper

…02……02…functioning of the software.  The testdata back to the

…02……02…NCC will runs on the permanent virtual circuits which

…02……02…are established during initialisation between the

…02……02…nodes and the NCC.

…02……02…The tests can also be performed with the help of NCC

…02……02…application programs. The NCC provides software tools

…02……02…to test both hardware and software modules (i.e. local

…02……02…and remote software modules).

…02……02…To facilitate hardware/software trouble-shooting

…02……02…monitoring facilities will be provided. These

…02……02…monitoring facilities are not the same as the

…02……02…monitoring facilities used for monitoring the ACDN

…02……02…in an operational sense.

…02……02…The test monitoring facilities give a possibility to

…02……02…display:

…02……02…o  all input/output from/to host

…02……02……02……02……02……02…-    -  node

…02……02…o  all traffic on internodal trunks

…02……02…where this does not create an overload situation. All

…02……02…wuffers can be displayed on request. Ssecified memory

…02……02…buffers can be dis*layed on request. S*ecified memory

…02……02…area can be displayed or stored on a disc file for

…02……02…later interpretation.

…02……02…Message generators will be built into each node.

…02……02…Message generation is invoked by a command from the

…02……02…NCC. The purpose is to test the capacity during

…02……02…different configuration.  The messages vary in

…02……02…contents, length, rate and destination. A logging

…02……02…facility described in section 4.4.2 is provided to aid

…02……02…the field technician in keeping track of events.

…02……02…A bounce facility will be implemented.  This facility

…02……02…bounces messages from a connected terminal back to t*e

…02……02…sender.

…02……02…Traces are activated either during network

…02……02……02…initialization or as a result of an operator command,

…02……02…and deactivated as a result of an operator command or

…02……02…as a result of system close down.

                            It is possible at the NCC
to test the routing strategy
by sending a packet to an end user and marR this
packet with node indenficator when it passes the node.
Software located in the nodes are able to recognize
trace type packets.

The tracable entities are: virtual calls, trunks, ter-
minals, conversations.

4.3.1       Test Functions

The following test functions are directly available as
NCC application programs:

o  Buffer read-out from NCC, EMH and nodes.
o  Remote dump of EMG and nodes

o  Bounce of user message

o  Loop back at Link level

o  Sessions with message generators.

Commands:

…02……02……02…NCC-id

READ-MEMORY    EMH-id         start-addr length     file

…02……02……02…Node-id

This command will transfer the designated memory area
to the NCC issuing the command and store it in file
(or display it directly if file is not specified).
This is done without corrupting the operation of the
target computer.

…02……02……02…NCC-id

…02……02……02…EMH-id

DUMP                             start-addr length
  file

…02……02……02…Node-id

This command is similar to READ-MEMORY except that the
target computer must be in its basic state.

The bounce facility is provided in two versions:

i)   The user may switch his terminal in control

…02…mode and issue the command:

…02…BOUNCE text

…02…This command is reflected by the user services in

…02…the NCC and reappears on the user|s terminal.

                            ii) The user may logon to
the bounce application

…02…in the NCC which also reflects all text received.

…02……02……02……02……02……02…LTU

LOOP node-id  link-id         LOCAL

…02……02……02……02……02……02…REMOTE

The designated node is instructed to perform a loop
test on the designated link.  The loop is either per-
formed internally in the LTU, at the local modem, or
at the remote modem.  The positive or negative result
of the loop is returned to the NCC.

The loop test can only be performed when the link is
not included in the rounting strategy.

INITIATE-SESSION  message-generator  message-receiver

This command causes the pseudo terminal
(message-generator) to start sending messages to the
NCC-application (message-receiver) based on traffic
request sent in other direction.

The message have time stamp to allow the message
receiver to determine the delay.  Other effects may be
observed via the normal status displays.

4.3.2       Trace Facilities

*******************

Traces of protocol data units can be performed
throughout the network, but may cause a severe
performance degradation.

A copy of each data unit being traced is sent to the
NCC on separate conversations with low priority. Thus
response time during normal load will only be slightly
affected, but throughput will be decreased due to the
accumulation of trace information being sent to the
NCC from the Node or EMH performing the trace.

Commands:

                            TRACE-ON id trace-object
trace-output-file
where trace-object may be:  host

…02……02……02……02……02……02…terminal

…02……02……02……02……02……02…link

…02……02……02……02……02……02…VC

…02……02……02……02……02……02…conversation

…02……02……02……02……02……02…session

All trace data are sent to the trace-output file for
later analysis.

TRACE-OFF id

This command turns the designated trace off.

Note.  Several traces may be active simultaneously.

                            4.4         Error and Threshold
Handlin*

…02……02…The error and threshold mess{ge handling is divided

…02……02…into 3 parts

…02……02…o  detection

…02……02…o  presentation

…02……02…o  action to be taken

4.4.1       Error and Threshold Detection

…02……02…Software entities are being provided in order to

…02……02…determine when a threshold has been reached.  The list

…02……02…of thresholds which are detected includes

…02……02…-  Node buffer low

…02……02…-  EMH buffer low

…02……02…-  trunk queues too long

…02……02…-   intermittent terminal failures

…02……02…-   recoverable protocol errors.

…02……02…Errors are detected by software entities loc{ted in

…02……02…the hosts, in the NCC and in the node.  The following

…02……02…list mentions some of the failures which are detected

…02……02…-   internal NCC failure

…02……02…-  node failure

…02……02…-  trunk failure

…02……02…-  host failure

…02……02…-  terminal failure

…02……02……02…-   irrecoveragle protocol errors

4.4.2       Presentation

…02……02……02…All errors and threshold messages are presented as

…02……02……02…events at the NCC.  They conta*n time stamp,

…02……02……02…event-type, resource name, and event message. Event

…02……02……02…notification is done at all operator consoles which

…02……02……02…have that particular event type assigned.

…02……02……02…All evenns must be acknowledged by one oaay f{cllity,

…02……02……02…or through use of the SCAN-EVENTS command.

                            Whenever an event is received
it is immediately
written to the log file.  The log file may be printed,
either in an off-line mode, or on-line.     In on-line
mode each event is printed as soon as
has been written to the log file.

The log file may also be displayed on the console to
allow an interactive search for "interesting" events.

Commands:

SCAN-EVENTS

This command lists all unacknowledged events and
allows the operator to acknowledge groups of events
based on time stamp, event type or resource name.

…02……02……02……02……02…RESUME

PRINT-LOG    ON

…02……02……02……02……02…OFF

This a*plication controls the print out of the event
log, RESUME causes *rint out to resume from the
position in the log file where it was last stopped. ON
enables the print out starting from the next incoming
event.  OFF disables the print out and frees the
printer.

BROWSE-LOG        log-file

This application provides search and display
facilities on the contents of the current log-file (or
another log-file if a file is specified).

Commands to browse-log provide selection and display
of events based on the *ollowing criteria:

o  time interval

o  event type

o   resource name

…02…or a combination thereof.

                            4.4.3       Actions to be
taken due to error and threshold

…02……02…messa***

…02……02…Error and threshold messages may require some action

…02……02…to be taken.  Action is taken by an automatically

…02……02…initialized program in the NCC or by an operator

…02……02…intervention. Some recovery procedures were described

…02……02…in section 4.2.8. Counters placed in the nodes in

…02……02…order to detect thresholds are reset automatically by

…02……02…the generation of the event.

                            4.5          Statistics

…02……02…During operation of the ACDN statistical information

…02……02…is collected as a result of

…02……02…o  a permanent function

…02……02…o  a crossed threshold on one of the

…02……02……02…parameters collected permanently

…02……02…o  a request from a network operator

…02……02…The statistical data are constantly collected by the

…02……02…nodes for all resources which have been designated in

…02……02…a START-STATISTICS command or which are part of the

…02……02…permanent statistics recording.   At regular intervals

…02……02…or when a threshold is crossed the statistics records

…02……02…are time stamped and sent to the NMH where they are

…02……02…written to the designated files.

…02……02…The latest statistics record values for each resource

…02……02…are averaged with the already stored values according

…02……02…to the formula:

…02……02…stored-val:= ((n-1) stored-val+new-val)/n

…02……02…where n is specified at system generation.

…02……02…The values are thus accessible for NCC applications

…02……02…which may use them to refresh status picture displays.

…02……02…Please refer to section 4.1.2 for a description of the

…02……02…delivered status picture applications which also

…02……02…contain statistics information.

…02……02…ACDN provides an application which is able to print in

…02……02……02…readable form the entries of selected resources from

…02……02…any statistics file.

…02……02…NMN applications may be written which either processes

…02……02……02…the statistics information on-line or off-line to

…02……02……02…generate graphics displays at the operator consoles.

…02……02……02…Statistics are permanently collected from the nodes,

…02……02……02…links and EMH.   *ach entry contains the following

…02……02……02…information:

                            resource type

resource address

* conversations

* virtual circuits

* conversation establishments/terminations
* virtual calls/clears/resets

* packets per second

…02……02…discarded packets

…02……02…data packets/control packets

…02……02…node entry/node exit/switched

…02…buffer occupancy

per link:

resource type

resource a*dress

* virtual circuits

* virtual calls/clears/resets

* packets per second

…02……02…discarded packets   received/sent

…02……02…data packets/control packets

…02…packet size distribution

…02…average packet queue time

* link protocol failures

* frame retransmissions

* physical link failures

On network operator request statistics data may be
collected on the external resources:

o  a terminal

o  a cluster controller

o  a line

Each record contains the following entries:

resource type

resource address

* blocks in/out

* blocksize distribution in/out

* intermittent errors

Commands:

STATISTICS-FILE       stat-file

                            This command sets (or displays
the name of) the file
used for the permanently collected statistics.  This
command must be issued as part of the NMH
initialisation and may be later re-issued to change to
another file.

PRINT-STATISTICS      stat-file      resource-type

…02……02……02……02……02……02……02…resource-address

This command prints in readable form selected entries
from stat-file (default is the current permanent
statistics file).  The selection may be on either
resource type or resource address.

Each entry is printed on one line.

START                      term-id

…02……02…-  STATISTICS    ctlr-id    stat-file

…02……02……02……02……02……02……02…time-interval

STOP                        line-id

STOP                       line-id

These commands start/stop collection of extended
statistics for a designated resource.

The default for time-interval is infinite. Otherwise
the statistics recording stops after time-interval has
expired.

                            4.6          Accountin*

…02……02…The NCC holds data about each conversation in the

…02……02…system. Each entry in the account file describes one

…02……02…conversation.  In an account file is stored at log on

…02……02…user-id (or term-id if user-id is not present), log on

…02……02…message, time stamp.  At log off, the user-id and the

…02……02…time stamp are stored.

…02……02…The WRAP-UP response (part of conversation protocol)

…02……02…includes statistical data which contains the number of

…02……02…messages exchanged during the conversation.  The

…02……02…number of messages will be stored into the account

…02……02…file entry.

…02……02…Command:

…02……02…ACCOUNT-FILE           acc-file

…02……02…This command sets (or displays the name of) the

…02……02…account file to be used.  This command must be issued

…02……02…at NCC initialisation time and may later be reissued

…02……02…to switch to another file.

                            4.7          Securit*********

…02……02…The security system addresses several aspects:

…02……02…o  controlled operator access

…02……02…o  restricted user access

…02……02…o  file privacy

…02……02…o  file integrity

…02……02…o  system integrity

…02……02…The operator access control implements a   capability

…02……02…vector scheme which allows individual capabilities to

…02……02…be assigned to each operator and terminal.

…02……02…Furthermore, restricted physical access to the

…02……02…operator consoles should be enforced.

…02……02…User access control is described in detail in the

…02……02…following section.  Note, however, that a trespassing

…02……02…user can neither jeopardize o*eration of ACDN nor

…02……02…obtain any restricted information from the NCC or

…02……02…other sources than his session partner; simply because

…02……02…such information is never given to any user.

…02……02…File privacy is ensured at two levels.  First the file

…02……02…system is able to protect any file from being read by

…02……02…others than a specified set of operators or programs.

…02……02…This facility gives at the same time protection and a

…02……02…possibility to use standard file utilities in a simple

…02……02…way since they must all obey the protection scheme.

…02……02…For certain sensitive files it can be specified that

…02……02…only certain programs are allowed to access the files.

…02……02…These programs can then be protected from unauthorized

…02……02…call via the operator capability scheme and further

…02……02…they may implement their own password validation.

…02……02…Note that passwords are never stored in files in an

…02……02…unscrambled form.

…02……02…The manipulation of ACDN files is explained in section

…02……02…4.7.2.

…02……02…File integrity is assured by the file system which may

…02……02…protect from unauthori*ed changes and which controls

…02……02…several processes competing for access to the same

…02……02…file.

                            4.7.1       Access Validation

…02……02…The user-id/password is { mandatory parameter in the

…02……02…ACDN log on message.  B{sed on the user-id, the user

…02……02…profile entry is looked up in the NCC by the Network

…02……02…Access Services.  Several steps of validation occur.

…02……02…o  Check valid user-id, i.e. is an entry found in

…02……02……02…the list of user profiles.

…02……02…o  Check password.

…02……02…o  If the user profile specifies a set of terminals

…02……02……02…which he is allowed to use, check  th{t the actual

…02……02……02…terminal-id is included in the list.

…02……02…o  Look up the terminal profile based on terminal-id

…02……02…o  If the terminal profile specifies a set of  users

…02……02……02…who are authorized to use that particular terminal,

…02……02……02…then check that user-id is included in the set.

…02……02…o  Finally, if the user profile specifies a set of

…02……02……02…allowed applications, then check that the

…02……02……02…application name is present in the set.

…02……02…If the validation fails the user is not granted access

…02……02…and the event is recorded in the Logfile. The maximum

…02……02…number of unsuccessful logons, which the system will

…02……02…tolerate can be specified. If this threshold is passed

…02……02…an alarm is given.  The terminal is deactivated and

…02……02…the user-id is marked invalid.

4.7.1.1     Mainframe Access Services

…02……02…A basic service provided by the existing LMENET

…02……02…software is the ability to access application programs

…02……02…contained in the IBM and Univac mainframes.  This

…02……02…proposal is based on extensions to this existing

…02……02…software to support multi sign in capabilities needed

…02……02…by AIR CANADA.  The ability to access the application

…02……02…programs is dependent on the IBM and Univac mainframes

…02……02…being designated as participatory members belonging to

…02……02…the LMENET.   In the following, we will assume this to

…02……02…be true and use the work mainframe or host

…02……02…synonymously with *articipant.

…02……02…The access procedure consists of two levels.  At the

…02……02…first level, the user identifies himself to the LMENET

…02……02…and gets validated for access.

…02……02…At the second level, the user identifies himself to

…02……02…the application program in a host, and gets accepted

…02……02……02…for access.

                            The access procedure and validation
procedure that
employed by an application program in granting access
to the users are not dependent on the LMENET function.

The access is based on LOGON and LOGOFF commands as
described below:

LOGON:       IBM devices perform a Logon to an SNA

…02……02……02…network in one of the two ways:

…02……02……02…i) Via an INITIATE-SELF SNA-command

…02……02…ii) Via a character coded Logon:

…02……02……02…LOGON APPLID (prog-name) LOGMODE (mode)

…02……02……02…DATA (user-data).

Terminal users log on via a character coded Logon
containing the following information:

LOGON USER (user-id/password)

|HOST (host-id)*|PROG(prog-name)|*DATA(user-data)

User-id is mandatory.  It identifies uniquely the user
and gives an entry to the user profile in the NCC.

The other parameters can be:

- specifies as shown

- defaulted to a value found in the user profile or

…02…derived from the status (e.g. host-id derived from

…02…prog-name)

- prompted by the NCC after Logon to LMENET has been

…02…performed.

When validation of the user, Logon to LMENET and
collection of the remaining parameter values have been
performed, the user can be logged on to the
application program.  The application may interpret
user-data as a host system dependent user-id/password,
which then will be different from that used by LMENET.

If a user (terminal or application)  issues a

connection request to a g*ven terminal then the

connection cannot be established until the terminal is

available and a user has logged on to LMENET.

                            If the terminal is available,
but no user is logged
on, a message identifying the requesting user will be
output to the terminal.  When a user logs on the
terminal, the connection is established.

To IBM:

The character coded SNA logon is forwarded to the SSCP
in the designated host.  The LOGMODE parameter is
derived from a Logmode table based on the terminal id.

Some SNA devices may only be able to connect via the
INITIATE-SELF request unit.  Such devices can either
be defined with a degault user-id in which case they
are considered to be constantly logged on to LMENET.
Otherwise they must be logged on by the network
operator before a connection can be established via
the INITIATE-SELF request unit.

To UNIVAC:

The following three messages are generated:

- SIGNON SITEID (terminal-id//host-id)
- Prog-name

- User-data

where // designates string concatentation.

LOGOFF:

The SNA character coded Logoff is:

LOGOFF APPLID (prog-name) TYPE (COND/UNCOND) HOLD
(YES/NO) where LMENET will only consider the TYPE
parameter (i.e. a Logoff will always entail a complete
Logoff from both the application and LMENET).

Note: LMENET is only able to detect the Logoff command
from terminals which have a certain "enter-key"
designated to be similar to the "System Request" key
on SNA- terminals.  If this in not the case* the

                            4.7.2       Administration

…02……02…The NCC controls a set o* files which are being

…02……02…created at system start up time or during the

…02……02…operation of the network.

…02……02…The files contain:

…02……02…o  Network Definition T{bles

…02……02…o  User Profile

…02……02…o  Terminal Profiles

…02……02…o  Operator Profiles

…02……02…o  Statistics D{ta

…02……02…o  Accounting Data

…02……02…o  Trace Data

…02……02…o  Log Data

                            The user profile may contain
an expiration date. After
this date it can no longer be used to access ACDN.
However, it remains in the user profile data set until
explicitly deleted.

Network Definition Tables keep a list of all host
application programs, NCC application programs to
which a network user may log on terminals, nodes etc.

User Profiles File contains the user profile for all
authorized ACDN users and additional information
related to the user.  The file keeps data link
user-id, password, terminal-id list, expiration date,
messages waiting indicator etc.  The password may be
changed by the user, but not during conversation with
a host.

Operator Profiles File contains the operators

profile. Since this file from a security point of view
is the most sensitive access is restricted to one
application program which requires a special
capability to be called.

This Application Program implements its own third
level password which should be regarded as the master
password of the system.  Note, however, that knowledge
of this password alone is not enough to break the
system; one must also have the capability to be asked
for it.

Via this application program the system administrator
is able to edit each entry in the operator profile
file.

Statistics Data File collects the statistics received
when conversations are established and when they are
taken down. During operation data are collected about
errors   *etries etc.

Accounting Data File contains information about all
conversations which have taken place.  Information
messages exchanged, the user involved, the application
program involved is stored.

This data may be used in a billing system.

                            Trace Data File contains a
"snapshot" or record of
data. As the information passes a certain point the
ACDN a trace record is made during a conversation.
Traces may be performed on lines, buffers etc.

The Logfile keeps data collected during operation: If
a user tries to log on to the system and the request
is rejected information is kept in the Log file.
Errors discovered and recovered from during operation
are logged. Messages sent from or to the NCC are being
logged.

Information for failing hosts, restarted hosts.  The
inform{tion kept about incidents like the above
mentioned consists of a time stamp and a short message
in order to determine the sort of incident which has
happened during operation.

The NCC operator is provided with a set of tools in
order to control these files.

A texteditor to do normal editing operations on files
is provided.

Three files are particularly protected against
unauthorized access:

o  Network Definition Tables

o  Operator Profiles File

o  User Profiles

These files are maintained under control of a set of
application programs which can be invoked by the
operator during normal operation.

The file system supports norm{l password protection on
these files.

The file system provides normal operations like create
file, delete file*es protected wit* a password a,e not
changed by any of the above-mentioned operations if
the correct password is not specified.

Files which are not essential are not provided with
any protection, but back-up copies of files should be
kept at all times.

                            The NCC provides an application
program to transfer
files from the NCC to the host.  This facility may be
used to transfer statistics file or accounting file
for further processing by the host.

4.7.3       Network Inte*****

The ACDN software integrity is maintained by
protecting the software entities from unauthorized
changes.  This protection is provided partly
softwarewise, partly hardwarewise.  No operator, no
user will possess a profile which gives access to a
capability class where a change of software will be
possible.

Remote load of a node can only be initialized from the
NCC.  The loading facilities are protected by the
capability scheme.

*** LINE REJECTED ***

…02……02…The operator work station will be equipped with 4

…02……02…terminals. The terminals are interfaced to the CR-80

…02……02…computer via standard LTU|s using V 24 serial line

…02……02…interface and an asynchronous start-stop protocol.

…02……02…Seven rates are selectable from the keyboard ranging

…02……02…ranging from 300 to 9600 bps.

…02……02…The high resolution graphics proposal makes it

…02……02…possible to address 480 horizontal by 384 vertical

…02……02…individual points. All graphics, items and text can be

…02……02…drawn in any of eight colours.

DataMuseum.dk

CR80 Wang WCS documentation floppies

⟦8b1416ce2⟧ Wang Wps File

Derivation

WangText