top - download
⟦6fd7d1230⟧ Wang Wps File
Length: 61153 (0xeee1)
Types: Wang Wps File
Notes: CPS/SDS/029
Names: »1709A «
Derivation
└─⟦af82dd301⟧ Bits:30006082 8" Wang WCS floppy, CR 0127A
└─ ⟦this⟧ »1709A «
WangText
…00……00……00……00……00…/…02……00……00…/
/…07…+
*…08…*…0d…*…02…*…07…)…0c…)…01…)…07…(…0c…(…02…'…08…'…0a…'…00…'…02…'…07…&…0b…&…0c…&…0f…&…00…&
%…09…%…0d…%…02…%…05…$…09…$…0e…$
$…07……86…1 …02… …02… …02…
…02…CPS/SDS/029
…02…820514…02……02…
SYSTEM STATUS AND CONTROL
DETAILED DESIGN SPECIFICATION CAMPS
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The package specification for System Status and Control
(CPS/SDS/029) is written to fulfil the following objectives:
1) To provide detailed definition of the package functions
and software architecture.
2) To provide user operational and development personnel
details of the ongoing analysis.
3) To define in detail the interfaces with other packages
and to describe their facilities.
The scope of SSC package specification is to detail
the function described in CPS/SDS/001 section 4 and
5.10, and to define a software structure, which implements
the detailed functions.
The SSC package defines the CAMPS hardware and software
configuration file.
The SSC package interfaces to all CAMPS software packages,
as it contains the start-up, close-down and the operational
control of the CAMPS system.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CPS/210/SYS/0001 CAMPS System Requirements
Specification
CPS/SDS/001 System Design Specification
CPS/230/ICD/0001 User Procedures and Associated
Formats
CPS/230/ICD/0002 Supervisor Commands and
Procedures
CPS/ICD/009 CAMPS Software Interface
Control Document
CPS/DBD/001 Data Base Design Document
CDS-MIC/0420/PSP/1010 Watchdog Sytem Software
Product Specificaton
CPS/SDS/013 DAMOS Operating Sytem (18
Appendices registered separately)
CPS/SDS/013 DAMOS Process Manager
Appendix 1 and Dispatcher
CPS/SDS/013 DAMOS Page Manager
Appendix 2
CPS/SDS/013 DAMOS Process
Appendix 3 Communication
CPS/SDS/013 DAMOS Directory
Appendix 4 Function
CPS/SDS/013 DAMOS Device
Appendix 5 Management
CPS/SDS/013 DAMOS Transfer
Appendix 6 Module
CPS/SDS/013 DAMOS Error Processor
Appendix 7
CPS/SDS/013 DAMOS Initialization
Appendix 8
CPS/SDS/013 DAMOS Boot Loader
Appendix 9
CPS/SDS/013 DAMOS Input/Output
Appendix 12 System
CPS/SDS/013 DAMOS Terminal
Appendix 13 Handling System
CPS/SDS/013 DAMOS Resource
Appendix 14 Management
CPS/SDS/013 DAMOS DMA Handler
Appendix 17
CPS/SDS/013 DAMOS OC Handler
Appendix 18
CPS/SDS/016 Storage and File Management.
1.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
The SSC interfaces to the following packages:
- CR80D
- Watchdog Processor
- Kernel Package (KERNEL)
- I/O Control Package (IOC)
- CAMPS System Function Package (CSF)
- Storage and File Management Package (SFS)
- Traffic Handling Package (THP)
- Distribution Package (MDP)
- Terminal Package (TEP)
- Table Management Package (TMP)
- Storage & Retrieval Package (SAR)
- Log and Accountability Package (LOG)
- Statistics Package (STP)
- Support Software Package (SSP)
- Off-Line Package (OLP)
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
Access Control Control of specifically delegated
access rights before access
is allowed to an object.
Access Control List Structure associated with catalog
objects. Contains access rights
of user groups to the objects.
Associated (Shared) Medium speed teleprinter, low
ROP speed teleprinter.
CAMPS Functions Denotes the following groups
of CAMPS services:
Supervisor Function
Message Distribution Control
Function
Message Service Function
Preparation Function
Release Function
Reception Function
CAMPS information…02…A part of disk volume which is
file logically structured into a
number of variable length strings
called fields.
Channel designator Identification of an external
channel.
Checkpoint Point from which restart/recovery
can take place.
Child Process A process is child of the process
having created it.
Circuit CAMPS to node connection for
the appropriate Network. A circuit
may consist of one or more channels.
Claim A resource management term specifying
a number of objects of a given
type that a process has the
right to create.
Close-down Action taken to bring processing
(Ordered/Emergency) within the system or a part
thereof to a stop - can be either
an ordered sequence of steps
or an abrupt termination. The
abrupt (emergency) stop includes
a PU shut down.
Cold start-up Start-up from the on-line disks,
based on current system parameters.
Historic data on the online
disks are deleted.
Connection (DAMOS A connection is a logical channel
TMS term) to a "terminal" on a channel.
A terminal can be:
- an EXC
- a VDU or VDU split
- an SAD
Control Refers to "active" execution
as opposed to "passive" monitoring.
Dead Start-up Initialization from the off-line
disk.
Designator A designator is a logical representation
of a line. The designator to
line connection is subject to
change during a reconfiguration.
Device Designator Identification of a stand-alone
device.
Device Profile To each device a device profile
is associated.
Directory A file containing identifications
and control information about
files or items.
External Channel A channel in a telegraph circuit
or non telegraph circuit.
File An unstructured, logically contiguous
part of a disk volume.
File Management Part of SFM handling Files
System
Historic Data Data which have been completely
processed and subsequently kept
for retrieval purposes.
Initial Start up System Start up based on initial
data.
Initialization The definition in the CPS/SDS/001
and subsequent documents are
described as follows: Brings
the system from dead start into
operational use. No recovery
actions are included.
The definitions replace the
one used in the CPS/210/SYS/0001:
Brings the system from cold
start into operational use.
Intermediate Storage areas for items within
Storage SFM.
Line A line refers to a physical
V24 wire from an LTU or LTUX.
Logical Line The software aggregate representing
a physical connection to an
external device, network, or
system.
Low Speed Media Low speed teleprinter (PTP,
PTR, ROP), Point-to-point connection
and TRC.
LP Driver Term from CSS ̲MIC/0420/PSP/1010
Watchdog System Software Product
Specification. The LP (line
printer) driver administers
the Watchdog ROP.
Main Queue A structured queue with a set
of sub queues.
Memory Segment Part of virtual memory. The
memory object to which security
and access control is applied.
Message Control A control structure in CSF
Block describing a single message
version.
Message Distribu- Denotes the total group of
tion Control Func- commands/procedures which may
be
tion performed from a VDU with Message
Distribution Control capability.
Message Management Part of the file management
System system for the moving head disks
handling CIFs.
Message monitor The part of CSF acting as interface
to message management system
within SFM.
Message Service Denotes the total group of
Function commands/procedures which may
be performed from a VDU with
Message Service capability.
Message View A subset of fields within a
message.
Monitoring Monitoring refers to a "passive"status
inspection, whereas control
refers to a execution. Supervision
includes monitoring and control.
Non Telegraph CCIS and SCARS.
Circuit
Object A resource to which security
and access control apply.
Off-Line Storage The part of disk storage residing
on removable packs.
On-Line Storage The part of disk storage which
is permanently mounted.
Operating System A process making high level
decisions about dynamic allocation
of resources to a set of descendant
processes.
Operator a) Person with responsibility
for operating the central
equipment from the maintenance
position and/or control
panels (i.e. the technicians
and RST).
b) Person with responsibility
for maintenance and repair.
The term operator is identical
with Engineer in CPS/210/SYS/0001
and replaces it in the CPS/SDS/001
and subsequent documents.
Operator ROP Refer Watchdog ROP.
Page A block of 1024 16 bits words.
Page Manager The part of kernel responsible
for memory management.
Parent Process A process is parent for those
processes which it has created.
Preparation Denotes the total group of
Functions commands/procedures which may
be performed from a VDU with
Preparation Capability.
Priority An attribute of a process used
for scheduling purposes.
Procedure Special part of a program. It
must be called with a "procedure
call" instruction which automatically
saves the return point.
Port A port refers to a line, a disk,
a TDX bus, an IOBUS, or a PU.
For lines a port may be visualized
as a physical wire relating to
a specific slot again relating
to a specific crate.
Process Execution of a specific program
operating on a specific set of
data. The active components of
the system to which security and
process control as well as resource
management is applied.
Program A sequence of instructions.
Protection The complete set of mechanisms
assuring that only the processes
authorized by security and access
control can access a given object.
PU Shut Down DAMOS action, which saves an error
message in the Kernel and issues
a Programmed master clear.
Queue Process communication tool within
CSF.
Queue Element The elements which can be in a
queue.
Queue Element The same as queue element. Used
Reference when emphasizing the function
of the queue element as the basic
reference to objects.
Queue Monitor The part of CSF supplying Queue
facilities.
Reception Function Denotes the total group of commands/procedures
which may be performed from a
VDU with Reception capability.
Release Function Denotes the total group of commands/procedures
which may be performed from a
VDU with Release capability.
Restart Refers to a cold or warm start-up
from the on-line disks.
Recovery Reestablishes continuity in memory
and file contents.
Security Control Control of classification and
special handling categories before
access allowed to an object.
Security Profile The data Type containing classification
and certain special handling categories
for an object.
Short Term Storage Storage areas for items within
SFM.
Staff cell The SCD is the smallest addressable
designator unit in one CAMPS site.
Stand alone device Medium speed teleprinter, low
speed teleprinter (PTP, PTR, ROP)
OCR, PTR, and PTP
Start up Includes all aspects of initialization,
recovery and restart.
Sub queue Part of a Main Queue.
Supervisor Person located at supervisor terminals
in CAMPS central equipment room
Supervisor's Person with responsibility for
Assistant special Message Service.
In the CPS/210/SYS/0001 supervisor
means both supervisor and supervisor
assistant.
Supervisor Denotes the total group of
Function commands/procedures which may
be performed from a VDU with supervisor
capability.
Switchover Relates to a dualized configuration
containing an active and a stand-by
part. Switchover is the actions
of bringing the stand-by device
into active state and the other
active device off-line.
Synchronization A process communication tool used
Element as basis for high level mechanisms
such as queues.
System Control Data Tables, system parameters etc.
used to implement and control
the operation of CAMPS.
System Parameter A simple variable, holding part
of the system state, and controlled
by TMP.
System User A distinguished user group with
special privileges.
System View Refers to the program and data
space visible during Kernel program
execution.
Telegraph circuit NICS TARE, Point to point and
TRC.
Terminal VDU, Medium Speed Teleprinter,
Low Speed Teleprinter, Line Printer,
PTP/PTR and OCR.
Terminal Device VDU, Medium Speed Teleprinter
and Low Speed Teleprinter.
Terminal Designa- A code identifying the terminal
po-
tor sition.
Terminal Position VDU and associated (shared) ROP.
Terminal Profile The terminal profile contains
information about an VDU and identify
a shared ROP.
Time Slice The amount of CPU-time that a
process may use before it must
give other processes the opportunity
to execute.
Time Stamp Time allocated to a transaction,
for example a storage process
or release of message.
Timer monitor The part of CSF supplying timer
facilities.
Tracing Retrieval of specific log records.
Translation Table A table used by Memory Map Module
to perform logical address to
physical address translation and
determination of access right
to memory locations.
User a) Person with responsibility
for input and output of messages.
b) Person located at the user
terminals in the staff cells.
The user is identical with the
term operator in the CPS/210/SYS/0001
and replaces it in CPS/SDS/001.
User Group A set of processes. A vehicle
for access control each process
belongs to exactly one user group.
User Group Unique identifier for a user group
Identification
User profile To each user a user profile is
associated. (Identical to operator
profile in the CPS/210/SYS/0001).
User View Refers to the program and data
space visible during user program
execution.
Watchdog ROP The ROP at the Watchdog
(WDP ROP) whereto operator commands are
logged and error reports printed.
Virtual Memory The total amount of information
that a process may address, either
directly or indirectly via Page
Manager functions.
Volume A named entity which can either
be a complete disk pack or a specifically
addressable part of a disk pack.
Warm start-up Start-up from the online disks
based on current system parameters.
Historic data are preserved. It
includes recovery/restart actions.
Switchover is a type of warm start-up.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
AC Active
BSM ̲X Bus Switch Module
CCB Configuration Control Bus
CEMCO Channel Monitoring & Control
CESE Central Error Reporting Synchronization
Element
CIF Camps Information File
CMD Command Dispatcher
CMI Command Interpreter
COPSY CAMPS Operating System
CU Channel Unit
DEMCO Device Monitoring & Control
DSSE Device Status Synchronization Element
EHD Error Handler and Command Dispatcher
EXC External Channel
FCT Function
FMS File Management System
FW Firmware
GAQ Garble Queue
HW Hardware
I/F Interface
LDU Logical Data Unit
LP Line Printer
LTP Low Speed Teleprinter
LTU Line Termination Unit
LTUX Line Termination Unit on the TDX-bus
MAP Mia Interface Processor
MDCO Message Distribution Control Operator
MIA Map Interface Adapter
MMON Message Monitor
MSO Message Service Operator
MTP Medium Speed Teleprinter
M&C Monitoring and Control
OCR Optical Character Reader
OLD On-line diagnostics
PSE Parent Synchronization Element
PTOP Point to Point
PTP Paper Tape Punch
PU Processor Unit
ROP Receive only Printer
SAD Stand Alone Device
SB Stand By
SEH System Error Handler
SSC System Status and Control
STI Supra-TDX Bus Interface
SW Software
TEMCO Terminal Monitoring & Control
TIA TDX Bus Interface Adapter
TMON Timer Monitor
TMS Terminal Management System
TRC Tape Relay Center
VDU Visual Display Unit
WAMCO Watchdog Monitoring & Control
WDP Watchdog Processor
Package abbreviations are defined in section 1.2.2.
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The SSC package starts, allocates resources to, monitors
and controls the CAMPS on-line and off-line system
through interaction between the two PUs, the peripherals,
the watchdog, and the operator.
The on-line modes of operation handled are:
- a dualized system consisting of an active PU and
associated peripherals and a stand-by PU
- a degraded system consisting of an active PU and
associated peripherals and an off-line PU and associated
peripherals
In the degraded system the SSC controls the off-line
operations:
- software development and test
- table generation
- maintenance and diagnostics
- offline utilities
The monitoring of the active and the standby system
includes:
- reception of error reports from other packages
- reception of hardware status from crates
- display of system status
- execution of on-line diagnostics programs
The control of the dualized and degraded system includes:
- physical connection of hardware modules
- allocation of resources to other packages e.g.
external and terminal lines
- execution of operator commands
The start-up of the dualized and degraded system includes:
- all forms of initialization
- ordered switchover to a stand-by processor and
corresponding recovery and restart actions
- recovery/restart actions during an emergency switchover
or after a total system error or after a disastrous
error
2.1.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
The SSC functional relationship to other packages is
depicted on the block diagram 2.1.1-1 overleaf.
The block diagram only defines on-line interfaces,
whereas start-up/close-down interfaces are not covered.
However, SSC interfaces to all application and system
software packages during start-up/close-down.
Also, error-handling interfaces are not shown. SSC
interfaces to all applications and system packages
during error-handling.
figure 2.1.1-1
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The SSC functions are depicted on figure 2.2.1-1 overleaf.
The SSC functions are separated in 3 groups:
- on-line functions
- off-line operation
- watchdog functions
The on-line functions include the CAMPS top level operating
system COPSY, which
- is the parent of all non-DAMOS processes
- handles allocation of all types of resources, including
specification of security and access control
- determines hardware and software reconfiguration
after the reception of an error report or an operator
command
- implements logical access - and distribution control
on lines.
figure 2.2.1-1
As resource management is one of the major SSC responsibilities,
the main resources are specified.
- CAMPS queues
- Processes
- CPUs
- Memory
- Lines and Devices
- Users of FMS and TMS
- Files
- Synchronization Elements
COPSY updates a Configuration table for all hardware
and software components and updates in conjunction
with the watchdog a system status display on the operator
VDU.
Section 2.2.1.1 through 2.2.1.6 describe the SSC functions.
2.2.1.1 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
Generally the on-line diagnostics test programs aim
at limiting the effect of an error by
- timely detection of errors
- reporting the error condition
Specifically the test programs participate in meeting
the availability and integrity of operation requirements.
The test programs operate as low priority tasks together
with the application software.
A specific test program to verify system integrity
through a checksumming of read-only system software
is available. The program is executed on request from
the supervisor and periodically.
2.2.1.2 L̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲
Line Monitoring and Control are divided into four areas:
- Terminal Monitoring and Control (TEMCO)
- Device Monitoring and Control (DEMCO)
- Channel Monitoring and Control (CEMCO)
- Watchdog Monitoring and Control (WAMCO)
2.2.1.2.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲T̲E̲M̲C̲O̲)̲
TEMCO monitors and controls LTUX lines to Visual Display
Units (VDUs).
The TEMCO functions are divided into two areas:
- Execution of logical control on behalf of other
packages e.g. access control (block/unblock), delivery
control (security interrogation/warning).
- Monitoring of connections to the VDUs and subsequent
execution of control
The monitoring includes the user initiated events:
- sign on/off
- specification of functional capabilities
- supervisor terminal assignment
- key locks and events related to the physical
VDU
- error reports
2.2.1.2.2 D̲e̲v̲i̲c̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲D̲E̲M̲C̲O̲)̲
DEMCO monitors and controls LTUX lines to Stand Alone
Devices (SADs)
The stand alone devices handled are:
- MTP ̲ROP
- PTR
- PTP
LTP ̲ROP
- LTP ̲PTR
- OCR
The DEMCO functions are divided into two areas:
- Execution of logical control on behalf of other
packages e.g. access control (accept/non accept
of input/output)
- Monitoring of connections to the SADs and subsequent
execution of control.
The monitoring includes the user initiated events:
- key locks for PTR and MTP ̲ROP and events related
to the physical device:
- error reports
2.2.1.2.3 C̲h̲a̲n̲n̲e̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲C̲E̲M̲C̲O̲)̲
CEMCO monitors and controls LTU AND LTUX lines to External
Channels (EXCs)
The EXCs handled are
- TRC ̲PTOP
- SCARS
- CCIS
- NICS-TARE
The CEMCO functions are divided into two areas:
- Execution of logical control on behalf of other
packages e.g. access control (accept/non accept
of input on a line)
- Monitoring of the connection to the EXCs and subsequent
execution of control.
The monitoring includes the reception of error reports.
2.2.1.2.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲W̲A̲M̲C̲O̲)̲
The WAMCO functions include
- sending of keep-alive messages from an active/standby
PU to the watchdog.
- monitoring of the WDP, WDP-VDU and WDP-ROP physical
state
and subsequent actions, which may be
- reinsertion of a device
- handling of a WDP ̲VDU connected directly to
the PU
- display the WDP ̲ROP paper out condition at the
WDP ̲VDU configuration display
- reception of monitoring information from the WDP.
2.2.1.3 H̲A̲N̲D̲L̲I̲N̲G̲ ̲O̲F̲ ̲T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲E̲R̲R̲O̲R̲R̲E̲P̲O̲R̲T̲S̲
This section covers error handling in general and includes
the following topics:
- error detection
- error types
- error reporting and error actions by
- service system
- user
- COPSY
Technical errors are detected during:
- System calls or asyncronously
- Instruction execution
- Validity checks
- WDP monitoring
2.2.1.3.1 S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲o̲r̲ ̲A̲s̲y̲n̲c̲h̲r̲o̲n̲o̲u̲s̲l̲y̲
Errors detected asynchornously (e.g. due to internal
controller check) are reported to an appropriate TMS
or FMS DSSE.
The errors give no user interface.
2.2.1.3.1.1 E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲s̲
Errors detected during system calls have one of the
following types:
- SW errors:
- resource error
- security violation
- illegal parameter error
- informative completion code
- HW errors:
- TMS connection error
- FMS connection error
- CESE error (Central error reporting synchronization
element)
2.2.1.3.1.2 R̲e̲p̲o̲r̲t̲i̲n̲g̲
The following reporting mechanisms exist:
- return of completion code
- sending of information to parent synchronization
element (PSE)
- return of completion code and sending of synchronization
element to device status synchronization element
(DSSE).
- reporting to CESE
2.2.1.3.1.3 E̲r̲r̲o̲r̲ ̲R̲e̲a̲c̲t̲i̲o̲n̲ ̲B̲y̲ ̲T̲h̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲y̲s̲t̲e̲m̲
Three error actions exist:
- return to user
- retire of user
- PU shut down
2.2.1.3.1.4 E̲r̲r̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲ ̲B̲y̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲i̲n̲
̲R̲e̲l̲a̲t̲i̲o̲n̲ ̲t̲o̲ ̲E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲
For:
- DAMOS security violation errors and
- CSF/TMP/STP/IOC
- resource errors
- security violations
- illegal parameter errors (programming error)
the calling process is automatically retired and a
report is sent to the PSE.
For:
- DAMOS
- resource errors
- illegal parameter errors (programming error)
- informative CCs (expectable CC)
and
- CSF/TMP/STP/IOC
- informative CCs (expectable CC)
a CC is returned to the caller.
For some illegal parameter errors (e.g. addressing)
DAMOS retires a user and a report is sent to PSE.
For TMS connection errors, a report is sent to a DSSE
a̲n̲d̲ a completion code is returned to the caller.
For power failures in an IO-crate, which may effect
a number of file/terminal management systems a report
is sent to the central error processing syncronization
element CESE.
2.2.1.3.1.5 E̲r̲r̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲ ̲b̲y̲ ̲t̲h̲e̲ ̲U̲s̲e̲r̲
Users have to handle the CCs, which are returned during
a system call.
An ANALYZE ̲ERROR procedure (refer SWICD) shall be invoked
if a CC is not zero.
As input parameters to ANALYZE ̲ERROR, the user specifies
a list of CCs, which he wants to react upon.
It is only possible to specify CCs of the following
types:
- informative completion code
- TMS/FMS connection error
i.e. resource and illegal parameter errors are handled
as security violation errors.
The error handling related to system calls is independent
of the CAMPS mode = AT-RISK OR NORMAL.
2.2.1.3.1.6 S̲p̲e̲c̲i̲f̲i̲c̲ ̲U̲s̲e̲r̲ ̲R̲e̲a̲c̲t̲i̲o̲n̲s̲
a) T̲M̲S̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲s̲
U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
When receiving a TMS connection error except for
"paper out", a subprocess will cancel its current
transaction and await a start command from COPSY.
However, for the TMS connection error "paper out",
a printer subprocess will await a COPSY resume-print
command.
b) I̲n̲f̲o̲r̲m̲a̲t̲i̲v̲e̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲ ̲U̲s̲e̲r̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The error reactions to informative completion codes
are user specific and will not be described further.
2.2.1.3.2 I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
Errors resulting from instruction execution implies
an error interrupt.
The error types, error reporting and error reactions
are defined below:
- PU error
The PU is shut down.
A PU shut down is a DAMOS action executed via the
PU ̲ERROR procedure (refer section 2.2.1.3.9).
- PU error in non-system software
A report is sent to the parent in PSE and the process
in question is retired.
The actions are performed by DAMOS and give no user
I/F.
2.2.1.3.3 V̲a̲l̲i̲d̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲s̲
2.2.1.3.3.1 E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲s̲
Errors due to validity checks refer to:
a) illegal contents of:
- Q ̲INFO
- Q ̲BUFFER - VIEW
b) internal program logic error e.g.
- case in otherwise
- array limit error
c) process communication error
- timeout for a reply
Type 1 and 3 are external errors.
2.2.1.3.3.2 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
Validity checks are executed by users.
2.2.1.3.3.3 R̲e̲p̲o̲r̲t̲i̲n̲g̲
Validity check errors are reported to the garble queue
GAQ and is performed by users via the Queue Monitor
procedure SEND-GARBLE:
Also, garble information is sent to the GAQ via the
SEND ̲GARBLE .
2.2.1.3.3.4 E̲r̲r̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲s̲ ̲b̲y̲ ̲S̲E̲N̲D̲ ̲G̲A̲R̲B̲L̲E̲
The SEND ̲GARBLE procedure performs an action depending
on:
- CAMPS mode of operation (refer 2.2.1.3.6)
- NORMAL
- AT ̲RISK
- Process type (refer 2.2.1.3.7)
- VITAL
- DUMMY
- RETIRABLE
- User specified action (refer 2.2.1.3.8)
- GIVE-UP
- DUMMY-ACTION
- CONTINUE
In NORMAL mode SEND ̲GARBLE:
- reports to GAQ
- retires the process (hereby a PSE report is sent
to COPSY)
In AT ̲Risk mode SEND ̲GARBLE
- reports to GAQ
- performs an action as specified below
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Process
Type
User VITAL DUMMY RETIRABLE
Actions
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
GIVE ̲UP RETIRE RETIRE RETIRE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DUMMY ̲ACTIONS N/A RETURN N/A
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CONTINUE RETURN RETURN RETURN
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2.2.1.3.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲(̲W̲D̲P̲)̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
The WDP monitoring gives no user I/F.
2.2.1.3.5 C̲O̲P̲S̲Y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
This section contains the COPSY handling of:
- PSE report
- GAQ reports
- TMS DSSE reports
- FMS DSSE reports
- CESE reports
- Watchdog monitoring reports.
2.2.1.3.5.1 P̲S̲E̲ ̲r̲e̲p̲o̲r̲t̲s̲ ̲(̲a̲n̲d̲ ̲n̲o̲ ̲G̲A̲Q̲ ̲r̲e̲p̲o̲r̲t̲)̲
In NORMAL mode COPSY performs a emergency close-down/switchover.
In At-Risk mode, COPSY reacts as above for VITAL and
DUMMY processes.
For RETIRABLE processes the retired process queue environment
and the PSE report are dumped to a garble spool area
on disk. The retired process is cleaned-up and an error
report is sent to the WDP ̲ROP.
2.2.1.3.5.2 G̲A̲Q̲ ̲r̲e̲p̲o̲r̲t̲s̲
In NORMAL mode COPSY will dump the first GAQ report
to disk and perform an emergency close down/switchover.
In AT-RISK mode the COPSY action depends on the SEND
̲GARBLE erroraction.
For the reaction retire COPSY performs as for PSE reports,
but prints in addition the GAQ report.
For the reaction return COPSY will dump the GAQ report
to disk and print an appropriate error message. In
addition
COPSY updates an error counter, which defines the number
of errors related to the processes.
The counters are periodically cleared.
When a threshold is exceeded, the process is retired.
CAMPS either continues (AT ̲RISK mode and process type
= RETIRABLE) or performs an emergency closedown/switchover.
2.2.1.3.5.3 T̲M̲S̲ ̲D̲S̲S̲E̲ ̲R̲e̲p̲o̲r̲t̲s̲
TMS DSSE reports are of the following types
- HW error
- Key position change
- Paper in/out
Key position changes are handled in section 4.1.1.2.2.
When receiving a TMS DSSE error report from non STI,
TIA, MAP devices (except for "paper out") COPSY will:
- dismantle the TMS connections involved
- if terminal: block terminal in terminal profile
- if device: disconnect device in device profile
- if channel: disconnect channel in channel profile
- update the error status in the port table
- print an error report at the WDP ̲ROP
When receiving a paper out DSSE report COPSY will do
nothing, but await a paper in DSSE report or a start-SAD
command.
When receiving a paper in DSSE report COPSY will:
- Send a resume-print command to a printer subprocess.
TMS DSSE error reports from a STI, TIA or MAP device
will make COPSY perform an emergency switchover.
2.2.1.3.5.4 F̲M̲S̲ ̲D̲S̲S̲E̲ ̲r̲e̲p̲o̲r̲t̲s̲
Disk reports are of two classes
- informative
An exception has been detected, but is recoverable
(e.g. sector failed).
- Hard
A disk controller, disk drive or volume is erroneous
and not usable.
Any informative report is printed at the WDP ̲ROP:
A hard error on the offline or floppy disk will make
COPSY.
- dismount the volume and if diskcontroller or disk
driver error, then
- deassign the disk
An error report is sent to the WDP ̲ROP and the configuration
display and disk port tables are updated.
An error in one of the mirrored disks will imply a
deassign, an error report and a configuration display
and port table update.
An error in both mirrored disks will imply an emergency
close down.
2.2.1.3.5.5 C̲E̲S̲E̲ ̲r̲e̲p̲o̲r̲t̲s̲
When receiving a CESE report COPSY performs an emergency
close-down/switchover.
2.2.1.3.5.6 W̲D̲P̲ ̲m̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲r̲e̲p̲o̲r̲t̲s̲
Refer Sec. 4.1.1.2.2.2
2.2.1.3.6 C̲A̲M̲P̲S̲ ̲M̲o̲d̲e̲s̲
The system is able to execute in two modes:
- NORMAL
- AT ̲RISK
In normal mode any SW error will imply an emergency
switchover.
In AT ̲RISK mode, the SW action depends on the error
type and the process type.
The process-type is a start-up parameter. The AT RISK/NORMAL
mode setting is performed by the operator.
The operator may determine to set AT ̲RISK mode:
- During load of new software (e.g. patches)
- During a WARM1 start-up, when the SB PU has failed
subsequent to a switchover.
2.2.1.3.7 P̲r̲o̲c̲e̲s̲s̲ ̲T̲y̲p̲e̲s̲
Processes are divided into three types:
1) Vital
2) Dummy
3) Retirable
V̲i̲t̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲
Vital processes cannot be retired or executed in dummy
mode without inhibiting normal processing.
D̲u̲m̲m̲y̲ ̲P̲r̲o̲c̲e̲s̲s̲
Dummy type processes are processes (e.g. log, statistics),
which:
- do not influence message processing
- cannot be retired without changing the behaviour
of other processes.
- can execute in a mode, where no other processing
is performed, but answering requests as if they
are successfully executed (i.e. transparent for
a user).
R̲e̲t̲i̲r̲a̲b̲l̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
Retirable processes can be retired, without changing
the behaviour of other processes (e.g. processes serving
VDUs or channels).
2.2.1.3.8 U̲s̲e̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲e̲d̲ ̲A̲c̲t̲i̲o̲n̲s̲
The GIVE ̲UP action is specified, when the error is
considered vital for the operation of the user e.g.
most internal programming logic errors.
The DUMMY ̲ACTION is specified, when the error is
- internal, but not in dummy mode code or
- external and not related to execution of the dummy
operation.
The CONTINUE action is specified for most external
errors. For DUMMY type processes refer also above.
2.2.1.3.9 E̲m̲e̲r̲g̲e̲n̲c̲y̲ ̲C̲l̲o̲s̲e̲-̲d̲o̲w̲n̲/̲s̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
COPSY executes an emergency close-down by calling the
DAMOS procedure PU ̲ERROR, which
- saves an errormessage in the Kernel
- issues a programmed Masterclear.
The PU ̲ERROR procedure is also called by Kernel procedures
and ROOT, when having detected an irrecoverable PU
hardware or software error.
During active/standby operation the watchdog will detect
the non-arrival of keep-alive messages and perform
a switchover to the standby PU.
The errormessage saved in the Kernel is available through
a MAP prom utility procedure.
2.2.1.4 O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲a̲n̲ ̲O̲n̲-̲L̲i̲n̲e̲ ̲P̲U̲
Operator commands control the CAMPS hardware and software
configuration. The execution of the control is shared
between the SSC in the active PU and the WDP. The SSC
in the active PU directs in the WDP to execute hardware
control (e.g. BSM-X Control).
The basis for execution of operator commands is status
information displayed on the operator VDU and detailed
error reports printed at the operator printer.
The following types of operator functions are foreseen:
- start-up of all modes of the system
- ordered close down of the system
- switch-over from the Active PU to the Standby PU
- device control
- connection of devices to buses
- enable/disable operational use of a device/line
- mounting/dismounting of volumes
- control of line attributes (e.g. speed)
- load of new software
- print of software versions
- define generation of trace information
- print system status
- delete CIF
- adjust time
- commands directly to the watchdog
SSC start-up and close-down responsibilities are defined
in section 2.2.2.1.
2.2.1.5 O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The SSC provides a command interface to the support
software package (SSP) and the offline package (OLP)
in the off-line PU and allocates resources to enable
the off-line operations.
The SSP commands includes low level M&D (maintenance
and diagnostic) commands to the MAP and MIA (MAP interface
processor).
2.2.1.5.1 C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲
Operator commands exist to control:
- support software
- off-line utility software
The initialization of off-line PU operation is covered
in section 2.2.2.1.1.1.
The commands control execution of maintenance and diagnostics
software and off-line utility software (control of
development and test software and table generation
software are executed from the development VDU at the
IO-BUS). The communication with the off-line PU is
implemented by using a protocol like the transparent
WDP protocol described in the IOC.
2.2.1.5.2 A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲
a) To support maintenance and diagnostics software
operations the following resources may be allocated:
- floppy disk
- off-line disk
- an IO-BUS and an LTU
- a TDX bus, a TDX controller and 2 LTUXs
- an on-line disk
The floppy disk or the off-line disk may be used
for load of SSP or OLP software. To support offline
utility operation, the floppy disk or the offline
disk is allocated.
b) To support development and test software and table
generation software operations the following resources
must be allocated:
- floppy disk
- off-line disk
- development VDU and printer at the CSSI Site.
c) The execution of off-line PU software will not
influence CAMPS on-line operations as an electrical
isolation of on-line hardware modules and off-line
hardware modules are provided. Refer to CAMPS System
Design Specification: CPS/SDS/001 section 4.3 for
a description of resources allocated to off-line
operation.
2.2.1.6 W̲a̲t̲c̲h̲d̲o̲g̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
2.2.1.6.1 W̲a̲t̲c̲h̲d̲o̲g̲ ̲L̲i̲n̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲
a) The watchdog line communication firmware supports
communication to two PUs, the operator VDU and
the operator printer
The communication firmware will be designed to
be mainly transparent to the operator VDU and the
printer.
1) The operator may direct commands to either
of the PUs
2) The VDU is used for system status display and
for the command dialogue
3) The printer is used for print out of
- detailed error reports
- detailed system status
- maintenance and diagnostics output
- off-line utilities output
- log of operator commands
2.2.1.6.2 S̲w̲i̲t̲c̲h̲ ̲L̲o̲g̲i̲c̲
The switch logic firmware in the watchdog controls
the physical connection of hardware modules based on:
- commands from PUs
- no keep alive message received from either of the
PUs
- commands from the operator
- direct monitoring of discrete points in the crates
through the CCB
The monitoring of the crates through the configuration
control bus is performed by a periodic scanning.
2.2.1.6.3 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
The switch logic enforces a switchover to the stand
by PU in the following cases:
- no keep alive message received from the active
PU within predefined time interval
- non recoverable hardware error in active PU, TDX
BUS or IO-BUS
- non recoverable software error in active PU
The watchdog performs the following actions automatically
during an emergency switchover:
- isolate the current active PU
- notify the current stand by PU to become active
Hereafter the current stand by will direct the watchdog
to switchover the peripherals previously owned by the
active PU to itself.
2.2.1.6.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲
The watchdog standard firmware consists of the watchdog
kernel and start up firmware.
The system software driver, which administers the WDP
ROP is referred to as the
- LP driver
The watchdog employs two start up modes:
- initialization
- recovery/restart
The recovery/restart mode is entered, if the watchdog
has been removed and later is reinstalled. Recovery/
restart is executed without affecting the ongoing CAMPS
operation.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
The section is divided into two:
- Start-up
- Close-down
2.2.2.1.1 S̲t̲a̲r̲t̲-̲U̲p̲ ̲(̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲)̲
The start-up actions relate to the following modes
of operation:
- a dualized system consisting of an active PU and
a stand-by PU
- a system containing an active PU and an off-line
PU
The start-up phase is divided into two phases:
- boot-load of on-line or off-line PU
- subsequent on-line start-up actions.
2.2.2.1.1.1 B̲o̲o̲t̲ ̲L̲o̲a̲d̲
Boot load functions are illustrated on figure 2.2.2.1.1.1-1
overleaf.
The boot loading functions are invoked via operator
commands directly to the MAP PROM.
Via the Boot operator command either
- on-line software
- off-line OLP or SSP software
is booted.
The disks and disk boot files are described in section
2.2.2.1.1.3.
An on-line boot implies that the Kernel process ROOT
is loaded and started. ROOT loads and starts the CAMPS
operating system COPSY, the file management system
and the terminal management system. COPSY performs
an initialization, which enables the reception of the
operator command start-up.
Also, the boot load functions include the execution
of a memory dump to disk.
The MAP PROM functions are described in:
CSS/3500/PSP/0029
The ROOT functions are described in:
CSS/3400/PSP/0028
DAMOS Initialization
CSS/3450/PSP/0057
DAMOS ROOT OS
Figure 2.2.2.1.1.1-1
2.2.2.1.1.2 S̲t̲a̲r̲t̲-̲U̲p̲ ̲o̲f̲ ̲A̲c̲t̲i̲v̲e̲ ̲a̲n̲d̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲
The modes of start-up which relate to on-line operations
are illustrated in figure 2.2.2.1.1.2-1
The start-up configuration is either
- an active and a stand-by PU, or
- an active PU
Figure 2.2.2.1.1-1
In figure 2.2.2.1.1.2-2 to 5 the start up AC and SB
PU functions are detailed.
During DEAD 1 and DEAD 2 COPSY creates files on the
mirrored disks and initializes some of these by copying
files from the off-line disk.
COPSY creates, loads, and starts all child processes
and assigns all types of resources, i.e. DAMOS objects
and CAMPS queues to the processes.
For the start-up type WARM1 the CAMPS may be running
in two maintenance modes (refer figure overleaf):
- operator only mode
- supervisor only mode,
if so specified by the operator during initial specification
of startup parameters.
The operator only mode gives possibilities to
- delete a specific CIF
- handle the floppy disk
- load modified software e.g. patches to be used
in a subsequent new startup.
- print version number of various load files.
The operator only mode is left, when the operator command
operator-only-terminated is specified. The terminate
command has two exits:
- the system is closed-down i.e. the modified software
loaded can now be brought into operation
- the system continues start-up
During the operator only mode no line processes or
message processing processes are started, i.e. the
queue state restored by MMS is frozen.
Having left the operator-only mode the supervisor only
mode is entered if so specified by the operator.
In the supervisor-only mode SSC starts up
- supervisor VDU subprocesses
- supervisor printers
- various non-message processing supervisor utility
processes
The supervisors are now able to execute the
- queue control at restart commands
in a frozen queue environment.
The supervisor-only mode is left upon supervisor issue
of a CAMPS GO command.
Hereafter SSC will start remaining processes and CAMPS
normal online operation begins.
During the loading of processes SW patches (residing
on disk) are loaded if so defined by the operator.
Loaded files are sum-checked.
In the standby PU only the system software supporting
standby functions is started.
Create peripherals includes
- line creation
- for LTUs a boot load is executed
Processes are divided into two types:
- line processes i.e. processes which administer
a VDU, SAD, EXC or a WDP.
- non line processes
Process initialization refers to
- the COPSY specification of parameters to the new
process (e.g. registers)
- an initialization procedure to be executed in all
processes prior to own initialization.
FIGURE
FIGURE…86…1 …02… …02… …02… …02…
FIGURE
FIGURE
2.2.2.1.1.3 D̲i̲s̲k̲ ̲S̲t̲a̲r̲t̲ ̲U̲p̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
On-line start up is either performed from the off-line
or from the on-line (mirrored) disks.
The off-line disk pack contains a pregenerated (at
the CSSI site) system including the following files
used by SSC::
- Initial system parameter file, which contains
- hardware configuration
- a back-up of the current system parameter file
- a software configuration file
- a modified software configuration file
- system software library
- application software library
- a modified system software library
- a modified application software library
- software patches
The on-line disks include the following files:
- current systems parameter file
- a software configuration file
- a modified software configuration file
- a modified system software library
- application software library
- a modified application software library
- software patches
The operator start-up command specifies whether the
initial system parameter (DEAD1, DEAD2) or current
system parameter file is to be used.(this is only applicable
to TMP). As a parameter in BOOT it is specified, whether
the unmodified or modified system software is to be
used.
As a parameter during start-up of the active PU it
is specified, whether unmodified or modified application
software is to be used.
2.2.2.1.1.4 T̲r̲a̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The trace function provides facilities for tracing
CAMPS system calls (refer CSF)
The trace functions are executed in TRACE ̲MODE, which
is a boolean defined at system generation.
In trace mode the operator can specify
- the processes to generate trace logs and their
priority
Trace logs are given on disk files. Each process has
its own trace file, which is created by COPSY with
the name:
- TRACE 'proc ̲no'
Also, COPSY useres on (to FMS ̲MOVING) the COPSY childprocesses,
which are not already usered on.
The trace file is looked-up and specified in an INIT
̲TRACE system call, in the PREINITIALIZATION procedure
(refer to the SWICD)
The creation of files functions are included in the
- initialize mirrored disk functions
The useron of processes are included in the
- create load processes functions.
2.2.2.1.2 O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲(̲I̲n̲i̲t̲i̲a̲t̲e̲d̲ ̲v̲i̲a̲ ̲a̲n̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲)̲
The SSC is responsible for close-down of the CAMPS
system. The handling of close-down is divided into
two sections:
- active PU close-down
- standby PU close-down
Emergency close down is described in section 2.2.1.3.6.
2.2.2.1.2.1 A̲C̲ ̲P̲U̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲(̲R̲e̲f̲e̲r̲ ̲f̲i̲g̲u̲r̲e̲ ̲2̲.̲2̲.̲2̲.̲1̲.̲2̲.̲1̲-̲1̲)̲
An ordered close-down command makes the SSC issue a
sequence of stop processing commands to other packages.
In the operator command a time period is specified,
within which the TEP and THP line subprocesses have
to terminate processing.
THP will use the period to (if possible) terminate
the processing of a complete message. Terminal users
are allowed to use the whole period. Upon time expiration
a cancel of the current transaction is requested by
COPSY.
Non-line processes in any package are closed one by
one.
They are given the same period of time to closedown.
Having completed close-down a reply is sent to the
SSC by the package in question. When all packages are
closed the SSC notifies the operator and issues a master
clear.
Figure 2.2.2.1.2.1-1
…01…and…01……01……01……01…Figure 2.2.2.1.2.2-1
2.2.2.1.2.2 S̲B̲ ̲P̲U̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲(̲R̲e̲f̲e̲r̲ ̲f̲i̲g̲u̲r̲e̲ ̲2̲.̲2̲.̲2̲.̲1̲.̲2̲.̲2̲-̲1̲
The operator command is directed to the active PU,
which commands the WDP to disable the SB PU via the
CCB.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
In figure 2.2.2.2-1 is summarized the SSC responsibilities
for checkpointing and recovery.
2.2.2.2.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲
The SSC is responsible for checkpointing the time of
day. Periodically the time of day is transferred to
disk (via TMP)
Figure 2.2.2.2-1
2.2.2.2.2 R̲e̲c̲o̲v̲e̲r̲y̲
The SSC contributes to recovery during the restart
start-up types:
- COLD
- WARM1
- WARM2 (after switchover)
The SSC notifies the CAMPS software packages of the
type of start-up.
The MMS is during WARM1 and WARM2 start-up requested
to retire the CAMPS queues contents.
2.2.2.3 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲S̲S̲C̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲s̲
Refer to figure 2.2.2.3-1 overleaf.
The SSC responsibility for error detection and handling
is divided into the following areas:
1) Handling of errors detected by the SSC in a PU
2) Handling of errors detected internally in the WDP.
Figure 2.2.2.3-1
2.2.2.3.1 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲s̲ ̲i̲n̲ ̲t̲h̲e̲ ̲S̲S̲C̲
̲i̲n̲ ̲a̲ ̲P̲U̲
The general errorhandling philosophy in 2.2.1.3 is
used for COPSY child processes.
C̲O̲P̲S̲Y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲i̲n̲t̲e̲r̲n̲a̲l̲ ̲s̲o̲f̲t̲w̲a̲r̲e̲ ̲e̲r̲r̲o̲r̲s̲ ̲
COPSY uses ANALYZE-ERROR for system call errors. A
retire of COPSY will make ROOT force an emergency closedown.
COPSY uses a modified version of SEND ̲GARBLE.
For external errors in AT ̲RISK mode a report is sent
to the GAQ and COPSY operation continues.
For all other cases an emergency close-down/switchover
is performed.
C̲O̲P̲S̲Y̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲i̲n̲t̲e̲r̲n̲a̲l̲ ̲h̲a̲r̲d̲w̲a̲r̲e̲ ̲e̲r̲r̲o̲r̲s̲
The errors are detected by the reception of a CC in
a system call.
Line connection errors will make TEMCO, DEMCO or CEMCO:
- block or disconnect the line in question in the
associated profile.
However, for TMS line connection errors which occurs
during line creation, no report is sent by TMS. In
these cases
- an errorreport is printed
- the configuration display is updated
- the line is blocked or disconnected
- the port table is updated.
Watchdog line connection errors will make COPSY stop
operations related to the line. For WDP ̲ROP errors,
errorreports will be directed to a supervisor printer.
FMS line connection erros detected during load of application
software or during copying of start-up software from
the off-line disk to the mirrored disks (during DEAD1/2
startup) will make COPSY execute an emergency close
down.
FMS line connection errors detected during on-line
operation when executing the operator command.
- copy modified software
will make COPSY
- execute an emergency close-down (if both the mirrored
disks are failed)
- Send an errorreport to the WDP ̲ROP and notify the
operator (if the off-line disk or floppy disk has
failed). The configuration display and port tables
are updated, when receiving a FMS DSSE report.
TMS STI, TIA or MAP errors, which occurs during creation
will make COPSY execute an emergency close down/switch-over.
2.2.2.3.2 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲E̲r̲r̲o̲r̲s̲ ̲D̲e̲t̲e̲c̲t̲e̲d̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲l̲y̲ ̲i̲n̲ ̲t̲h̲e̲ ̲W̲a̲t̲c̲h̲d̲o̲g̲
An internal detected SW error will make the WDP issue
a WDP local programmed master clear.
Validity check errors for input from a PU will make
the WDP handle the PU as erroneous i.e. as if no keep
alive message is received.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The SSC contributes to the ensurance of integrity of
operation by:
a) Detection of errors by on-line diagnostics program
b) Detection of errors by monitoring hardware modules
(via the WDP)
c) Electrical isolation of erroneous hardware modules
(executed by the WDP)
d) Reporting all detected errors to the WDP-ROP
e) Performing an error fix-up subsequent to the detection
of an error
E.g. switchover, disable VDU
f) Validity Checks
Input data to the SSC (e.g. operator commands and
error reports) are syntax and semantic checked
for the data field used in processing the data.
Functions a to e are covered elsewhere in the document.
The validity checks are depicted in figure 2.2.2.4-1
overleaf.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VALIDITY CHECKS
16.0
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 2.2.2.4-1…01…SSC VALIDITY CHECKS FUNCTIONS
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲(̲L̲o̲g̲,̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲,̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲s̲)̲
The SSC data collection functions are shown on the
figure overleaf. Operator commands contributions to
data connections are handled elsewhere.
2.2.2.5.1 L̲o̲g̲
SSC will generate statistics during execution of the
following user procedures:
- Security interrogation (I1)
- Security warning (I2)
- Sign-on (K1)
- Sign-off (K2)
For operator commands a log record is printed at the
WDP-ROP, defining the execution of the command in question.
2.2.2.5.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
SSC will generate statistics during execution of the
following terminal procedures:
- Security interrogation (I1)
- Security warning (I2)
Figure 2.2.2.5-1
2.2.2.5.3 R̲e̲p̲o̲r̲t̲s̲
SSC will generate security reports to be printed at
the supervisor report printer as specified below:
- Unsuccessful sign-on attempt
- Unsuccessful security interrogation and whether
it was due to time-out or faulty password
- Unsuccessful security warning and whether it was
due to time-out or fault security code.
- Unsuccessful password entry by release officer
- Hardware error on line
- Software error in line subprocess
- Security key turned off during sign-in
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The SSC handles security related to:
1) DAMOS objects and processes
2) CAMPS queues
3) CAMPS subprocesses
4) Presentation of messages
2.2.2.6.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲o̲n̲ ̲D̲A̲M̲O̲S̲ ̲O̲b̲j̲e̲c̲t̲s̲
During any type of start-up the SSC specifies:
- the classification of DAMOS objects and subjects
(processes)
- the access rights for processes to DAMOS objects
2.2.2.6.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲o̲n̲ ̲C̲A̲M̲P̲S̲ ̲Q̲u̲e̲u̲e̲s̲
All main queues have an associated Access Profile,
determining which QELs can be sent to its sub-queues.
The Access profiles of the queues are set:
- during start up
- after updating of profiles
For terminal, device and channel queues the Access
Profiles are derived from the terminal, device and
channel profiles.
2.2.2.6.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲o̲n̲ ̲C̲A̲M̲P̲S̲ ̲S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲e̲s̲
Each subprocess has an associated Access Profile, determining
which information the subprocess is allowed to access.
The Access profiles of the subprocesses are set during:
- start up
- sign on/off on VDUs
- specification of accept/non accept input/output
on EXC/SADs
- Software/hardware error.
For device and channel subprocesses the Access Profiles
are derived from the device and channel profiles.
For a terminal subprocess the Access Profile is derived
from a combination of the terminal profile and the
user profile.
Each subprocess has a list of capabilities, the capability
array.
The capability array defines which queues the subprocess
can access and the set of QMON functions the subprocess
can perform on each of these queues.
The subprocess has only access to a queue if it is
represented by a capability in the capability array
of the subprocess.
Two capability arrays are defined in connection with
subprocesses.
- for each entry in the queue capability array is
specified a capability function mask, which specifies
which QMON functions the subprocess can perform
on the associated queue.
- for each subprocess is specified a function mask
(in the subprocess attributes). The mask specifies
which privileged CSF functions the subprocess may
call.
2.2.2.6.4 P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The SSC handles
- security interrogation
- security warning
related to presentation of messages.
figure
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
2.3.1.1 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
A switchover is to be performed within 60 seconds.
2.3.1.2 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Initialization is to be performed within 15 minutes.
2.3.1.3 R̲e̲c̲o̲v̲e̲r̲y̲/̲R̲e̲s̲t̲a̲r̲t̲
Recovery/restart subsequent to a total system failure
is to be performed within 15 minutes.
2.3.1.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲L̲i̲n̲e̲ ̲S̲p̲e̲e̲d̲s̲
The watchdog shall support the following line speeds:
- to PUs: 9.6 K Baud
- to operator ROP: 2400 Band
- to operator VDU: 2400 Band
2.3.1.5 R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲
The response time for user procedures is defined in
section 3.4.1.6.3 in the CAMPS System Requirements
CPS/210/SYS/0001.
The response time for supervisory commands is defined
in section 3.4.1.6.5 in the CAMPS System Requirements
CPS/210/SYS/0001.
2.3.1.6 S̲t̲a̲r̲t̲-̲U̲p̲ ̲a̲n̲d̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲
CAMPS software components are started/closed in a specific
sequence, which is defined in section 4. Generally
terminal and traffic handling packages are started
latest/closed first, whereas service software e.g.
log, statistics are started first/closed latest.
2.3.1.7 P̲r̲i̲o̲r̲i̲t̲i̲e̲s̲ ̲o̲f̲ ̲I̲n̲p̲u̲t̲
No specific prioritizing exists.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
2.3.2.1 I̲n̲c̲r̲e̲a̲s̲e̲ ̲o̲f̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲i̲z̲e̲
Application software are designed to have a capacity
to allow for a 10 per cent increase in object code????????
2.3.2.2 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
The SSC software allows operation of equipment corresponding
to wired capacity.
Via operator commands an equipment can be brought into/out
of operational use.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
2.3.3.1 H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲h̲a̲n̲g̲e̲s̲
The system is designed to be able to handle the wired
capacity configuration.
Expansion beyond this maximum
- May require auxiliary PU capacity
- Requires software regeneration
The actual configuration control is mainly table driven.
2.3.3.2 O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Changes in operator formats (except for field contents)
can be performed by changing an appropriate format
on the initialization disk.
New formats or changes in field contents in existing
formats require inclusion of new procedures, which
syntax/semantic checks the commands, respectively executes
the command.
2.3.3.3 L̲o̲a̲d̲i̲n̲g̲ ̲o̲f̲ ̲N̲e̲w̲ ̲V̲e̲r̲s̲i̲o̲n̲s̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲
Loading of new versions of application and system software
is possible in all start-up cases, except WARM2 (after
switchover).
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲ ̲a̲n̲d̲ ̲V̲a̲l̲i̲d̲i̲t̲y̲
2.3.4.1 A̲c̲c̲u̲r̲a̲c̲y̲ ̲a̲n̲d̲ ̲I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲
Commands and reports received by the SSC package are
validated for the data range required for an internal
processing of the input. E.g. type and function code
are checked to be within certain ranges.
For operator commands a syntax and semantic check is
performed either in the VDU or in the SSC on all input
data.
A protocol is used between the WDP and a PU to ensure
an error free transmission of data.
2.3.4.2 A̲c̲c̲u̲r̲a̲c̲y̲ ̲o̲f̲ ̲T̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ ̲D̲a̲t̲a̲
Data to be transmitted to other packages must be checked
by the receiver.
