Beruflich Dokumente
Kultur Dokumente
NCM establishes and maintains an end-to-end interconnection between a user terminal and a specific
class of services by initiating an active session and managing it. When GCM Traffic Controller receives a
message from a user not yet registered in its GCM USER tables, the message is assumed to he a ses-
sion-initiation request and is forwarded to NCM Session Manager which analyzes the messages for
transport control data, verifies user authorization, logs the registered user into VANSYS, and allocates him
session bandwidth.
The address of the user's network access node is checked against the terminal inventory directory to
determine access procedures. this user network access node can be a general user facility requiring
identification through a logon procedure or a public-access touch terminal access mode requiring no
additional identification.
After identification NCM references its NCM USER tables for user terminal requirements and complete
identification and system customization records. Terminal requirements are referenced to customize the
network connection by dispatching network configuration packets to GCM Traffic Controller when required
and to determine what to downline load into the DTE to provide proper remote configuration.
The user's system customization records specify all service options available to him. When the proper
processing environment is determined the user is transferred into that environment. if all options
available to the user are in DCM, for example, he is routed through GCM directly to a port class dedicated
to servicing DCM, however, if he has authorized options which would place him in one of several
processing environments, menus are generated to present options until the proper processor
environment is determined.
After the user and his requested services are properly identified and he is logged into the System
GCM User tables are updated. These GCM User tables provide mapping between the user session
number and his network access node address. Messages also are dispatched to DCM to update DCM
User tables and to provide, complete identification and service customization records. As with GCM User
tables DCM User tables contain only DCM pertinent information.
After this point in the session, NCM is passive except for interaction with GCM, from which it requests
session traffic characteristics, and except in response to a presentation-level remote-job entry call which
requires local or remote job-spawning procedure.
C3.1b Protocol
Session-level protocols are available from the ISO in draft proposal form and are expected to be available
in draft inter-national proposal form in early 1984. Draft Proposals 8326 and 8327 detail the session-level
service definition and session-level protocol definition respectively. The ISO has not yet standardized
System management protocols and no working documents are yet available from its committees.
VANNCM design will closely follow such protocol and service definitions when available.
This module also catalogues and addresses System pages which are stored on DCM disk and
cached in NCM memory; HELP, Hard Hat, Herald, and m ain menu pages. These System
pages can be wholly composed gages or mask definitions which specify their construction using variable data. In
either case the composed image is dispatched to the user terminal device as a message without regard to content, thus
permitting creation of pages on independent composition systems.
1. Port Class. logical classification such as VMART, VAN, BANK Backup Port #. identically-configured backup port
2. Rotary Port #, chained rotary port number
3. Line Class. level 1, 2, & 3 line drivers
4. Virtual Circuits: maximum number of logical channels per port Speed. transmit/receive speeds
5. hardware Address: physical address of the port
6. Intercept Errors Flag. how to handle errors
7. Special Processing Options. used to customize services.
After being defined these ports can be assigned to specific uses via the following commands
Configuring ports to be inactive; 1) Set GCM Port # Inactive. 2) Reset GCM Port #: 3) Set DCM Port # Inactive. 4) Reset DCM
Port # 5) Set NCH Port 4 Inactive, 6) Reset NCM Port 4 .
Configuring ports for input only: 1) Set VANGCM Port Inactive (INPUT), 2) Reset VANGCM
Port #, 3) Set VANDCM Port Inactive (INPUT), 4) Reset VANDCM Port #; 5) Set VANDCM
Port Inactive (INPUT), 6) Reset VANNCM Port #.
Configuring ports for output only 1) Set GCM Port Inactive (OUTPUT) 2) Reset GCM Port #. 3) Set
DCM Port Inactive (OUT-PUT) : 4) Reset DCM Port # 5) Set NCM Port Inactive (OUTPUT) 6) Reset
NCN Port #.
Configuring ports for switch over: 1) Set VANGCM port #/alternate #, 2) RHI Reset
VANGCM port #, 3) Set VANDCM port #/alternate #; 4) RMI # Reset VANDCM port # 5) Set
VANNCM port #/alternate # 6) RCI # Reset VANNCM port #..
This module operates via four submodules. 1) Disk A l l o c a t o r which allocates disk space to each
database, 2) File Allocator which allocates file space within the database, 3) SAN Manager which registers
Service Access Nodes, and 4) Application Manager which registers application processes.
C3.2a4.1 DISK ALLOCATOR; Allocates database files among the various disks to provide logical
placement for best overall System-wide performance. Each database file can be segmented and stored on
multiple disks to place information near where it most likely will be needed.
Using GCM and DCM audit records, Disk Allocator interacts with File Allocator to determine database
segmentation and placement by analyzing the frequency of requests to transport specific database pages to
specific locations. Calculating daily probabilities GCM Disk Allocator segments the database
to place actual content as close as possible to its most likely destination. Duplication of database
components is also sup-ported and directories are maintained to ensure that copies are updated when the
master is updated so that pages can be stored in intelligent memory caches without risk of later
transporting obsolete information to a user.
C3.2a4.2 FILL ALLOCATOR: Defines database files as active, test, or fallback and allocates space within
database files among various departments or Information Providers. Database files are composed of an
integral number of blocks and Information Providers are granted access to block ranges.
C3.2a4.3 SAN MANAGER. Registers Service Access Nodes (SANs) which route a user to a specific
class of application services. Only services registered as SANs are offered as main menu options. Each
SAN is assigned a SAN Title, DCM Primary Structure identification number or alternative routing
information, and access authorization character.
After tae SAN is installed an editor or Information Provider defines the structure and content through DCM
Database Editor (C4.2c3), creating the service in a test database file via a series of prompts. After both DCM
and the system manager validate structure and content of a test file it is transferred to the live database. The system
manager assigns the Information Provider a maximum number of levels and a maximum number of options per
level.
C3.2a4.4 APPLICATION MANAGER: Maintains an Application Directory that lists all VANSYS and foreign
application services with routing and access parameters. It registers both System-supplied and Information
Provider-supplied application processes which can be written in higher-level languages and references
connection end points, addresses for accessing these application services. The Application Directory
contains routing instructions, access keywords when applicable, owner identification, and reference to
costs associated with each application.
This module operates in an online mode with no interruption of system operations. It enters configuration information
via a traditional prompting application to add, delete, or modify logical user configurations and, when
appropriate, initiates high-priority reconfiguration messages to modify content of NCM and DCM User tables
instantly.
NCH User ID Manager maintains four directories: 1) NCM USER Directory. 2) Access Directory, 3) CUG (Closed
User-Group) ' Directory, and 4) Terminal Directory.
C3.2a5 NCH USER DIRCTORY: Catalogues user identification information. In later phases of operation
various categories of additional information will be required to provide automatic access to banking
databases or other foreign-host processing systems. Initially, however, only the following basic information
is required, Type of User. to include NAME which is a typical name, XREF which cross references more complicated
name, and GROUP which i s a Closed User-Group with a a list of authorized members. NAME is entered
with a maximum of 20 characters and is dependent upon the type of user.
Addresses; to include user street name, street #, apartment #, phone #, state, zip code. NCM requires home
addresses to pro-vide automatic billing and other services, neither GCM or DCM memories require this
information.
Assigned Passwords: to include up to 20 characters. The System uses the password in three forms. 7 characters
minimum to sign on to the System; an additional 3 characters (total of 10) to access registered services: an
2
additional 3 characters (total of 13) to access confidential services. Therefore 13 of 0 possible characters are
required to gain access to the most sensitive services within the System.
Passwords can be concatenated to form general passwords for Closed User-Group access while still distinguishing
between users, thus permitting a family to access the service with a family password but requiring an additional
password suffix to access a family member's personal locker or mail.
C3.2a5.2 NCM ACCESS DIRECTORY. Catalogues access authorization for each user, listing all Service Access
Lodes (SANs) for which he is authorized, and passes authorization records to DCM which uses them to
control access to hierarchically subordinate levels of the database structure.
NCM references this Access Directory to determine basic service options available to the user. User selection of a
main menu option references one of his SANs. Routing instructions for each SAN minimally define a port
class, the database, and a starting point within that database. Access and authorization control is then transferred
to the DCM application service or that of a foreign host, depending on user selection.
C3.2a5.3 CUG (CLOSED USER-GROUP) DIRECTORY. Associates users with Closed User-Groups and
catalogues privileges assigned at various levels within a specific Closed User-Group. An unlimited number
of hierarchical levels are provided in each group, permitting such divisions as FAMILY NAME for the main
group, with parents and children assigned to different levels of the group. This provision permits such
applications as parental monitoring/ control of children's use of the System.
C3.2a5.4 TERMINAL DIRECTORY; Catalogues all network access nodes and assigns restricted service
access based on the network access node address. Terminal requirements for each user are catalogued
according to terminal type, graphic character set, speed requirements, and downline load specifications.
NCM Session Manager works closely with GCM Traffic Controller (C2.2b) to provide session level
functionality, operating via two modules: 1) Session Dialogue Handler which associates users with
applications, associates user commands with System resources, and configures the communications
network to support user-specific requirements, and 2) Session Administrator which synchronizes
interacting application entities, binding or unbinding them through interaction with GCM Traffic Controller.
C3.2b1.1 TERMINAL ID HANDLER: Identifies the user requesting entry and validates or denies the access
request. This submodule accesses the Terminal Directory (C3.2a5.4) to identify the user. Public terminals
have a dedicated network access node address and are so recognized: individual business and residential
users who access the System via nondedicated channels must present a personal identification before
access is granted, either via automatic identification facilities common in an addressable cable system
converter or through prompted queries for name and classified passwords.
ID dandier admits authorized users to the System and configures the System to their recorded needs, it
denies access to unauthorized users and logs such attempted accesses.
C3.2b1.2 DOWNLINE LOADER: Downline loads terminals for graphic and virtual terminal support.
Downline loading is specified during user configuration and the information is stored in NCM
Terminal Directory.
C3.2b1.3 LOGON Provides identification by comparing user supplied name and password with information
stored in NCM User Directory (C3.3a5.1). Logon assigns a logical user number corresponding to the
lowest available session number (beginning with 1) and queues this number to the GCM to map the logical
user to a physical access node address. Logon invokes NCM Audit Collector-Processor to record all
actions.
C3.2b1.4 LOGOFF: After a time-out is exhausted, or upon an intentional exit from System, LOGOFF
terminates the session and instructs GCM Traffic Controller to update its tables accordingly. It then
modifies its active session tables to release the assigned session #.
Logoff initiates terminal reconfiguration after a Time-Out period is exhausted, constructs a message to
invoke the macro definition for the Herald Page, and instructs GCM Traffic Controller to transport this
message to the terminal device. After displaying the Herald Page it logs the event and instructs GCM to
remove the user from the GCM User Directory.
C3.2b1.5 TIME-OUT MONITOR Monitors the time since the last user response. Each user is configured to
selectable time intervals according to the specific application. When such time interval elapses Time-Out
Monitor advises LOGOFF to terminate the session logically.
Selectable time parameters permit customization so that public terminals in mall operations, for instance,
can be cycled to the Herald Page during the day but removed as logical users during closed-mall hours.
The time-out value can be set to 0 to bypass this option and permit the DCM Time-Out Monitor to perform
this function.
C3.2b2.1 RESOURCE MONITOR. Monitors system resources to balance usage of system facilities and
thus reduces prioritized degradation of performance. Resource Monitor operates via two routines; 1) Port
Monitor and 2) Traffic Monitor. NCM Resource Monitor also maintains a working network configuration by
systematically polling network components, generating test loops, isolating faulty components, and
reporting on network status.
C3.2b2.1 PORT MONITOR Issues Network Monitoring Commands as high-priority interrupt packets to
GCM Traffic Controller which then passes up the requested data. These commands permit monitoring of a
specific user by session number or by a specific GCM port.
Commands to Monitor Ports:. I) Monitor traffic of port #, queue to #, 2) Monitor input of port 4, queue to *;
3) Monitor output of port #, queue to * 4) Monitor errors of port #, queue to5) Reset monitor status of port #
(and #).
C3.2b2.1 TRAFFIC MONITOR: Issues Traffic Monitoring Commands as high- priority interrupt packets
passing them down to GCM Traffic Controller, which passes up acknowledgements and performs
the directed traffic control procedures.
Commands to Monitor Users: 1) Monitor all traffic of A, queue to B 2) Monitor input traffic of A, queue to B,
3) Monitor output traffic of A, queue to B 4) Monitor Errors of A. queue to B, 5) Reset monitor status of A
(and B).
C3.2b2.2 APPLICATION INITIATOR: Binds the application process in theterminal device with the user-
requested application process by assigning the logical user to a logical channel. General-purpose user
application processes reside within DCM while management application processes reside within NCM.
This submodule controls application binding via commands which direct movement of messages
through GCM. These commands set user status to interactive, reset user status, purge user message
queues, purge messages: of specified priority from user queues, move queued messages to another user
queue, and move queued messages of a specified priority to another user queue. These administrative
controls interconnect and synchronize applications processes although the interconnection is indirect since
direct interconnection is only between presentation entities.
NCM Message Collector operates via three submodules 1) Session Audit Collector which processes NCM
configuration data generated as a result of user and host configuration, 2) Traffic Audit Collector which
processes GCM session data on logons, signoffs, and menu selections, and 1) Message Audit
C o l l e c t o r which processes DCM traffic audit messages for both inbound and outbound traffic.
C3.2c1 SESSION AUDIT COLLECTOR. NCM statistical messages are generated as a result of user and
host configuration management and resource utilization in the following format.
C3.2c1 TRAFFIC AUDIT COLLECTOR, Generates audit messages for both inbound and outbound
t r a f f i c according t o the following format, logging messages into an audit f i l e on GCM from which
they are queued to NCN on a periodic basis as selected by the system operator.
C3.2c2.1Activity Report
Display activity of GCM System including sessions between. DCM and host, GCM and DCM, I/O
character count and sessions in progress.
Display activity of line #.
Display activity on DCM including all input messages, out-put messages, and messages on the queue.
Display activity of user # on DCM.
Display user activity on GCM and DCM.
C3.2c2.2 Resource Report
Display all memory and virtual circuit resources available to the system.
Display all disk, memory, and virtual circuit resources on D m .
Display all available resources for user #.
Billing information recorded for each user during user configuration includes.
Cost per user session connection
Cost per user session connected to node # Cost of DCM Connection
Cost of Application Session
Cost per Messages Normal
Cost per Messages Urgent
Cost per Messages Registered
Billing reports are generated and deposited in DCM and readied for posting as configured per user
(residential, business). If requested during configuration a daily activity report is delivered to the user or
Information Provider. The general billing format is.
Logon/Signoff Data
User ID, Account #, Sub-Account #,
Host #, Port #/Class, Time
Retrieval Data
User 1D, Pages Accessed, Database
Accessed, Page Category, Page Cost,
Page Owner, * of Records/Pages