top - download
⟦92159ce8b⟧ Wang Wps File
Length: 52934 (0xcec6)
Types: Wang Wps File
Notes: CPS/SDS/001 ISSUE 1
Names: »0685A «
Derivation
└─⟦6472223e8⟧ Bits:30006010 8" Wang WCS floppy, CR 0045A
└─ ⟦this⟧ »0685A «
WangText
>…0b…2
2…05…1…09…1…0e…1…0f…1…00…1…01…1 1…05…0…0a…0…0b…0…00…0 0…05…/…0a…/…02….…09….…0e….
-…08…-…0d…-
,…86…1
…02…
…02…
…02…
…02…CPS/SDS/001
…02… FH/810227…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
5.10 SSC PACKAGE .............................
448
5.10.1 Summary of Requirements .............
448
5.10.1.1 Package Description .............
448
5.10.1.1.1 General Description .........
448
5.10.1.1.2 Package References ..........
449
5.10.1.1.3 External Interfaces .........
449
5.10.1.1.4 Block Diagram ...............
450
5.10.1.2 Package Functions ...............
454
5.10.1.2.1 Start Up ....................
456
5.10.1.2.1.1 Disk Start Up Information
458
5.10.1.2.1.2 Start Up of Off-Line PU .
459
5.10.1.2.1.3 Start Up of On-Line Ope-
rations .................
459
5.10.1.2.1.4 Initialization of On-Line
Operation (Dead and Cold
Start) ..................
461
5.10.1.2.1.5 Memory Dump .............
461
5.10.1.2.1.6 Start Up Subsequent to an
Ordered Close Down
(WARM1) .................
462
5.10.1.2.1.7 Start Up after a Total
System Failure (WARM2) ..
462
5.10.1.2.1.8 Switchover and Subsequent
Recovery/Restart (WARM3)
462
5.10.1.2.1.9 Start Up Subsequent to an
Ordered Close Down
(WARM4) .................
463
5.10.1.2.1.10 Restart of a Stand By PU
463
5.10.1.2.2 Technical Error Processing ..
463
5.10.1.2.3 Resource Management .........
465
5.10.1.2.4 Terminal Monitoring and
Control (TEMCO) .............
466
5.10.1.2.4.1 Access Control for Ter-
minal Positions .........
467
5.10.1.2.4.2 Terminal Position
Delivery Control ........
469
5.10.1.2.4.3 Generation of Logs, Re-
ports, and Statistics ...
469
5.10.1.2.5 On-Line Diagnostics .........
469
5.10.1.2.6 Watchdog Communication ......
470
5.10.1.2.7 Operator Functions ..........
471
5.10.1.2.7.1 Switch Between Dualized
Equipment ...............
472
5.10.1.2.7.2 Reconfiguration of
Devices and Lines .......
472
5.10.1.2.7.3 Control of Line Attri-
butes ...................
473
5.10.1.2.7.4 Start Up Commands .......
473
5.10.1.2.7.5 Close Down of a PU ......
474
5.10.1.2.7.6 Load of New Software ....
475
5.10.1.2.7.7 Define Generation of
Trace Information .......
475
5.10.1.2.7.8 Print of System Status ..
475
5.10.1.2.7.9 Time of Day .............
475
5.10.1.2.7.10 Commands to the Watchdog
475
5.10.1.2.8 Checkpoint Transmission .....
476
5.10.1.2.9 Checkpoint Reception ........
476
5.10.1.2.10 Off-Line PU Operation .......
476
5.10.1.2.10.1 Commands to the Off-
Line PU ................
476
5.10.1.2.10.2 Allocation of Resources
to the Off-Line PU .....
477
5.10.1.2.11 Watchdog Line Communications
478
5.10.1.2.12 Switch Logic ...............
478
5.10.1.2.12.1 Switchover .............
479
5.10.1.2.13 Watchdog Standard Firmware .
479
5.10.1.3 Package Control .................
480
5.10.1.3.1 Parameter Update ............
480
5.10.1.3.2 Hardware Control of the SSC .
480
5.10.1.3.3 Error Reporting Mechanisms ..
480
5.10.1.4 Characteristics .................
480
5.10.1.4.1 Performance .................
480
5.10.1.4.2 Availability, Maintainabili-
ty, and Integrity of Opera-
tion ........................
481
5.10.1.4.3 Security ....................
482
5.10.1.5 Design and Construction .........
483
5.10.1.6 Documentation ...................
483
5.10.2 Environment .........................
483
5.10.2.1 External Interfaces .............
484
5.10.2.2 Package Interfaces ..............
484
5.10 S̲S̲C̲ ̲P̲A̲C̲K̲A̲G̲E̲
5.10.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
5.10.1.1 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
5.10.1.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲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 watchdog
and the operator.
The on-line modes of operation handled are:
- a dualized system consisting of an active and a
stand-by processor
- a degraded system consisting of an active processor
and an off-line processor
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 a forced switchover
or after a total system error or after a disastrous
error
5.10.1.1.2 P̲a̲c̲k̲a̲g̲e̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
The SSC interfaces to the following packages:
CR80D
Watchdog Processor
Kernel Package
I/O Control Package
CAMPS System Function Package
Storage and File Management Package
Traffic Handling Package
Distribution Package
Terminal Package
Table Management Package
Storage & Retrieval Package
Log and Accountability Package
Statistics Package
Support Software Package
Offline Package
5.10.1.1.3 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The SSC implements the operator commands defined in
Supervisor Commands and Procedures, CPS/230/ICD/0002.
5.10.1.1.4 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
Two block diagrams giving SSC interfaces to other packages
are depicted on figure 5.10.1.1.4-1, 5.10.1.1.4-2 and
5.10.1.1.4-3 overleaf.
Figure 5.10.1.1.4-1…01…Dualized CAMPS Operation Block Diagram Package Interfaces
Figure 5.10.1.1.4-2/3…01…Degraded CAMPS Operation Block Diagram Package Interfaces
5.10.1.2 P̲a̲c̲k̲a̲g̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The SSC functions are depicted on the visual tables
of contents 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 processes
- handles allocation of all types of resources, including
specification of security and access control
- provides an error fix up for errors not processed
by a child
The following sections (5.10.1.2.1 through 5.10.1.2.13)
give a detailed description of each SSC function.
Figure 5.10.1.2-1…01…Visual Tables of Contents
5.10.1.2.1 S̲t̲a̲r̲t̲ ̲U̲p̲
Start up includes all aspects of initialization, recovery
and restart.
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
In figure 5.10.1.2.1-1 a PU state transition diagram
is given.
Start up actions are initiated from the operator VDU
by means of operator commands. The initial bootload
of a processor is performed by a PROM to which the
operator communicates after power up or execution of
a "master clear".
During start up of on-line operation the CAMPS operating
system (COPSY) is loaded and started at first. COPSY
is the parent of all processes and assigns resources
to its children as described in section 5.10.1.2.9.
Also COPSY down line loads LTUs. Processes and procedures
started are given start up information, which defines
the type of start up. In the stand-by PU only processes
and procedures supporting stand-by functions are started.
The remainder of this section describes the data upon
which start-up is based and the detailed start-up modes.
Figure 5.10.1.2.1.1-1…01…CAMPS Processor State Transitions
1) Switch-over
2) Remove stand-by to off-line
3) Insert off-line as stand-by
5.10.1.2.1.1 D̲i̲s̲k̲ ̲S̲t̲a̲r̲t̲ ̲U̲p̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
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:
- Initial system parameter file, which contains
- hardware configuration
- software configuration
- a (possible) back-up of the current system parameter
file
- system software library
- application software library
- a (possible) back up of the current application
software library
- empty historical data files
- support software library, which contains (refer
section 4.5):
- development and test software (only at CSSI
site)
- table generation software (only at CSSI site)
- maintenance and diagnostics software
- offline utility library, which includes software
to (refer section 4.5):
- print of memory dump and trace records
The on-line disks include the following files:
- current systems parameter file
- system software library
- application software library
- a (possible) modified application software library
- historical data files, including
- log
- statistics
- messages in intermediate and short term storage
5.10.1.2.1.2 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲o̲f̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲
Initialization of the off-line processor is based on
the support software on the off-line disk or on the
floppy disk.
5.10.1.2.1.3 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲o̲f̲ ̲O̲n̲-̲L̲i̲n̲e̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The modes of start up which relate to on-line operations
are illustrated in figure 5.10.1.2.1.3-1. Initialization
modes of start up are named dead and cold, whereas
start up actions including recovery/restart are named
warm.
The start up configuration is either
- an active and a stand-by PU, or
- an active PU
Figure 5.10.1.2.1.3-1…01…Start Up of On-Line Operations
5.10.1.2.1.4 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲O̲n̲-̲L̲i̲n̲e̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲(̲D̲e̲a̲d̲ ̲a̲n̲d̲ ̲C̲o̲l̲d̲
S̲t̲a̲r̲t̲)̲
Initialization of on-line operation is based either
on the on-line disks or the off-line disks. During
initialization via the off-line disk then the off-line
disk initialization files are copied to the on-line
disks and subsequent initialization is based on these.
Initialization from the off-line disk is based on
- the initial system parameter file, or
- a back up of the current system parameter file,
and
- the initial application software file, or
- the modified application software file
In both cases the system will be initialized with empty
historical data.
Initialization from the on-line disk is based on the
current system parameter file and either
- the current historical data (start up subsequent
to a controlled close down), or
- empty historical data (this implies a deletion
of current historical data), and either
- the initial application software file, or
- the modified application software file
5.10.1.2.1.5 M̲e̲m̲o̲r̲y̲ ̲D̲u̲m̲p̲
Prior to a start-up, a memory dump can be performed
to the floppy disk or to the offline disk.
5.10.1.2.1.6 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲S̲u̲b̲s̲e̲q̲u̲e̲n̲t̲ ̲t̲o̲ ̲a̲n̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲(̲W̲A̲R̲M̲1̲)̲
Start up after an ordered close down (refer section
5.10.1.2.7) is based on the on-line disk. All queues
are empty and historic data are recovered. The operator
specifies whether the initial or modified application
software is to be used.
5.10.1.2.1.7 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲a̲f̲t̲e̲r̲ ̲a̲ ̲T̲o̲t̲a̲l̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲a̲i̲l̲u̲r̲e̲ ̲(̲W̲A̲R̲M̲2̲)̲
Start up subsequent to a total system failure is based
on checkpoints and historic data on the on-line disk,
whereas only vital input queues (refer section 4.7)
are recovered.
The SSC synchronizes recovery updates in application
packages. If the stand by PU is started up prior to
the start up of the active PU, the active PU transfers
the checkpoints on which it was recovered to the stand
by PU.
The operator specifies, whether the initial or modified
application software is to be used.
5.10.1.2.1.8 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲a̲n̲d̲ ̲S̲u̲b̲s̲e̲q̲u̲e̲n̲t̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲/̲R̲e̲s̲t̲a̲r̲t̲ ̲(̲W̲A̲R̲M̲3̲)̲
During swithcover the active PU is taken off-line and
the stand-by PU is started.
A switch-over is executed due to an operator command
or subsequent to an active PU or IOBUS error.
During an ordered switchover, it is ensured that complete
messages which currently are being processed are received/transmitted
on the external lines and that transactions at terminal
position are completed prior to the switchover.
The standby PU is during start-up only loaded with
system software. So, during an ordered switch-over
the operator can specify, whether the initial or modified
application software is to be used.
The start up is based on checkpoint information received
by the standby PU prior to switchover and on historic
files on disk.
The recovery includes recreation of main queues (as
defined in section 4.7) and corresponding files by
the CAMPS System Functions. Hereafter, the SSC synchronizes
recovery updates in application packages. After this
stage the now active PU is working without standby,
and only vital checkpoints are transferred to disk.
5.10.1.2.1.9 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲S̲u̲b̲s̲e̲q̲u̲e̲n̲t̲ ̲t̲o̲ ̲a̲n̲ ̲O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲(̲W̲a̲r̲m̲4̲)̲
Start up after an ordered close down (refer section
5.10.1.2.7) is based on the on-line disc. Queues are
reinitialized and historic data are recovered. The
operator specifies whether the initial or modified
application software is to be used.
5.10.1.2.1.10 R̲e̲s̲t̲a̲r̲t̲ ̲o̲f̲ ̲a̲ ̲S̲t̲a̲n̲d̲ ̲B̲y̲ ̲P̲U̲
Initialization of an off-line PU, which is to be used
as stand by PU is based on the off-line disk system
software package. The off-line disk is switched to
the IO-BUS of the off-line PU. Regeneration of the
checkpoint state of the current active PU is performed
by the reception of a burst of checkpoint information
from the active PU.
5.10.1.2.2 T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲
The Kernel contains a table, which defines an error
to error type relation. It is possible for a process
to specify error types for which it will take over
the error handling. The take over is implemented via
an application process defined procedure, which is
automatically invoked, if an error of the specified
type occurs. The application error fix up process has
access to an extended error information, which in detail
defines the error (e.g. to Hardware module level).
It is, however, possible for the parent of a process
to inhibit a child from specifying certain error types.
Errors not handled by a process are given to the parent
of the process and the process is stopped.
E̲r̲r̲o̲r̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
COPSY receives error reports subsequent to the detection
of an error from:
- on line diagnostics programs
- application software, which has not specified an
error fix up procedure
- PU firmware detected hardware errors
- Kernel detected software errors
- The watchdog having monitored a hardware error
Application processes receive error reports subsequent
to an error from the system software which on behalf
of the application operates on lines, files, queues,
areas, etc:
- I/O system
- Message monitor
- Queue monitor
E̲r̲r̲o̲r̲ ̲R̲e̲a̲c̲t̲i̲o̲n̲s̲
Depending on the error type the SSC error processing
software performs a standard error fix-up. For further
details refer to section 4.11.
E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
A process, which handles an error locally, reports
the result of the error fix-up to the SSC. The SSC
prints the report at the operator printer and if appropriate
updates the system status display at the operator VDU.
If the watchdog fails then error reports are directed
to the supervisor report printer.
5.10.1.2.3 R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The resources handled include:
- processes
- CPUs
- memory
- security and access control specification
- lines and devices
- users of FMS and MMS
- files
- synchronization elements and queues
- error types to be handled by child processes
The resource management software updates the Configuration
table for all hardware and software modules and updates
in conjunction with the watchdog the system status
display on the operator VDU.
The resource management functions are invoked by
- an operator command
- the error processing software
- the terminal monitoring and control software
The resource management functions implement start-up
resource allocation and on-line resource allocation/deallocation.
S̲t̲a̲r̲t̲-̲U̲p̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
During start-up each type of resource is allocated
to each process handled.
For LTU, LTUX and Disk CTR lines an attached logical
line is handed to the application i.e. the SSC:
- assigns logical to physical device connection
- defines security and access control for the logical
lines
LTUX terminal lines are given to the terminal and supervisor
control package.
LTU logical lines and LTUX TRC lines are given to the
traffic handling package.
The off line DISK lines are given to the terminal package,
which handles mounting of disk packs.
The on line (mirrored) disks are handled by the SSC.
The floppy disk is handled by the SSC.
O̲n̲-̲L̲i̲n̲e̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The on-line resource management is invoked
- by the technical error processing software
- by a command from the watchdog having monitored
a device error
- during execution of operator commands
- during sign in/off of operators
- during open/close of external lines
The specific resource management performed is defined
during the description of the callers of the resource
management functions.
5.10.1.2.4 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 performs the following functions:
- access control for terminal positions
- terminal position delivery control
- generation of logs, reports and statistics
5.10.1.2.4.1 A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲f̲o̲r̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲s̲
TEMCO monitors the physical states of a terminal position
and controls the logical access to a terminal position.
A terminal position contains:
- a VDU (has a locking mechanism)
A stand alone device position contains one of the following
devices:
- a MTP (medium speed teleprinter) (ROP) (has a locking
mechanism)
- an OCR
- a PTR (has a locking mechanism)
- a PTP
- a LTP (low speed teleprinter); which may operate
as:
- ROP
- PTR
- PTP
VDU state transitions are caused by the following events:
- locking mechanism from off to on or from on to
off.
- sign on/off
PTR and MTP state transitions are caused by the following
events:
- locking mechanism from off to on or from on to
off.
- supervisor specification of accept/not accept of
input.
OCR, PTP, LTP state transitions are caused by the following
events:
- supervisor specification of accept/not accept of
input and/or output.
The locking mechanism and the sign on/off states are
available to TEMCO through the IOC.
The supervisor specification of accept/not accept of
messages is available to TEMCO through TMP.
a) VDU Locking Mechanism from Off to On:
The VDU screen is initialized and a sign-in is
awaited.
b) Sign-On:
Upon sign-on TEMCO will establish an active terminal
profile and activate an instance of the terminal
system with corresponding access rights. Access
rights to the supervisor position will not, however,
be granted before the ASSIGNS command has been
detected. An unsuccessful sign-on attempt will
cause TEMCO to block the terminal position, except
if supervisor position.
c) Sign-Off:
Sign-out will cause TEMCO to withdraw access rights
and return the state of the terminal position to
Locking mechanism ON.
d) VDU Locking Mechanism from ON to OFF:
The current transaction is cancelled and the VDU
is signed-off.
e) A MTP/PTR instance is created, if:
- the locking mechanism is on and
- the supervisor has specified accept of input/output
of messages.
f) A MTP/PTR instance is deleted, if:
- the locking mechanism is set off or
- the supervisor specifies not accept of input/output
of messages.
g) An OCR, PTP, LTP instance is created, if:
- the supervisor has specified accept of input/output
of messages.
h) An OCR, PTP, LTP instance is deleted, if:
- the supervisor specifies not accept of input/output
of messages.
5.10.1.2.4.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
TEMCO is responsible for security interrogation of
terminal position user, whenever information is required
from an instance of the terminal position of security
classification or special handling category as specified
then TEMCO is notified by the Message Monitor (CAMPS
System Function). TEMCO then performs a security interrogation
and if necessary a security warning. If successfully
completed, TEMCO directs the Message Monitor to deliver
the wanted information. If not successfully completed,
TEMCO directs the message monitor not to deliver the
information and forces the terminal position into Unattended-Manned
mode.
5.10.1.2.4.3 G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲o̲g̲s̲,̲ ̲R̲e̲p̲o̲r̲t̲s̲,̲ ̲a̲n̲d̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Refer to section 5.10.1.4.3b.
5.10.1.2.5 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 program participates in meeting
the availability and integrity of operation requirements
as specified in section 4.11.
The test programs operate as low priority tasks together
with the application software. Error conditions are
reported to the technical error processing 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. A security report
is generated if the system integrity is violated.
5.10.1.2.6 W̲a̲t̲c̲h̲d̲o̲g̲-̲P̲U̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The watchdog communication software receives via the
watchdog driver commands from the operator at the operator
VDU or commands internally generated by the watchdog
(e.g. switchover). Also the watchdog communications
software transmits commands to the watchdog and synchronizes
output to the operator printer.
The received operator commands are syntax and semantic
checked. If an error is detected an error message is
sent to the operator VDU and the command is terminated.
If the command is error free an appropriate module
is invoked and the command executed. Upon completion
an acknowledgement is sent to the operator VDU.
Operator commands are logged at the operator printer.
Periodically an alive message is sent to the watchdog
(Non-arrival of an alive message makes the watchdog
force a switchover to the stand by PU).
5.10.1.2.7 O̲p̲e̲r̲a̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The operator functions implements operator commands,
which controls the CAMPS hardware and software configuration.
The execution of operator functions are shared between
the PU and the watchdog.
The basis for execution of operator commands are status
information displayed on the operator VDU and detailed
error reports printed at the operator printer.
Also the operator functions coordinate direct hardware
control (e.g. switch and reconfiguration) with software
control.
The following types of operator functions are foreseen:
- switch between hardware units, when dualization
is used
- device control
- connection of devices to buses
- enable/disable operational use of a device
line
- take a device out of service (by physical removal
or by disconnecting it from all buses).
- control of line attributes (e.g. speed)
- start-up of all modes of the system
- close down of the system
- load of new software
- define generation of trace information
- print system status
- set time of day
- commands directly to the watchdog
A more specific definition of operator functions is
outlined in the remainder of this section.
5.10.1.2.7.1 S̲w̲i̲t̲c̲h̲ ̲B̲e̲t̲w̲e̲e̲n̲ ̲D̲u̲a̲l̲i̲z̲e̲d̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
The following functions are foreseen:
- switch to standby TDX BUS
- switch to standby PU (refer section 5.10.1.2.1.8)
5.10.1.2.7.2 R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲D̲e̲v̲i̲c̲e̲s̲ ̲a̲n̲d̲ ̲L̲i̲n̲e̲s̲
a) L̲T̲U̲ ̲a̲n̲d̲ ̲A̲t̲t̲a̲c̲h̲e̲d̲ ̲L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The following functions are foreseen:
- connect LTU to specified IO Bus
- take LTU out of service
- enable/disable specific LTU line
b) L̲T̲U̲X̲ ̲a̲n̲d̲ ̲A̲t̲t̲a̲c̲h̲e̲d̲ ̲L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The following functions are foreseen:
- connect a pair of LTUXs to a specified TDX
Bus
- take LTUX out of service
- enable/disable specified LTUX line
c) T̲D̲X̲-̲B̲u̲s̲ ̲S̲y̲s̲t̲e̲m̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The following functions are foreseen:
- specify if TDX-BUS and TDX-CTR is to be logically
removed or is to be inserted as standby.
d) D̲i̲s̲k̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The SSC controls the assignment of:
- the off-line disk
- the on-line (mirrored) disks
- the floppy disk
to a physical drive. The assignment is defined
at system generation. The control includes connection
to active or non-active PU; and taking a disk drive
out of service.
The volume handling for the off-line disk is implemented
by the terminal package (TEP). When the off line
disk is assigned the stand-by PU, the stand-by
PU performs the volume handling.
The volume handling for the on-line disks and the
floppy disk is implemented by the SSC and includes:
- Mounting of volume
- Dismounting of volume
- Insert mirrored volume
5.10.1.2.7.3 C̲o̲n̲t̲r̲o̲l̲ ̲o̲f̲ ̲L̲i̲n̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Operator commands exist for control of variables LTUX
and LTU line attributes (e.g. speed).
5.10.1.2.7.4 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The different start up commands are implicitly given
in section 5.10.1.2.1.
5.10.1.2.7.5 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲o̲f̲ ̲a̲ ̲P̲U̲
The following commands are foreseen:
- ordered close down of active PU
- ordered close down of stand by PU
- isolate active or stand by PU
a) O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲ ̲P̲U̲ ̲(̲T̲y̲p̲e̲ ̲1̲)̲
All input from external lines and terminals are
stopped:
- At the external lines the stopping is implemented,
when a complete message is input
- At the terminal lines the users are given a
limited time (minutes) to close all input.
After expiration of that period a block of
preparation functions is issued.
Hereafter the system will slowly die out.
b) O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲A̲c̲t̲i̲v̲e̲ ̲P̲U̲ ̲(̲T̲y̲p̲e̲ ̲2̲)̲
All input and output to/from terminals and external
lines are stopped:
- at the external lines the stopping is implemented,
when a complete message is transmitted/received.
- at the terminal the users are given a limited
time to close all input. Hereafter the TEP
stops, when a transaction (including presentation)
is completed.
The distribution of messages is stopped. When the
above stop actions are terminated, then SSC directs
the CSF to save current queue contents and memory
resident table information on disk.
c) O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲S̲t̲a̲n̲d̲ ̲B̲y̲ ̲P̲U̲
The current active PU is notified and check pointing
to the stand-by PU will stop.
d) I̲s̲o̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲A̲c̲t̲i̲v̲e̲ ̲o̲r̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲
The watchdog disconnects electrically the PU concerned.
Isolation of the active PU implies an automatic
switchover.
5.10.1.2.7.6 L̲o̲a̲d̲ ̲o̲f̲ ̲N̲e̲w̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Refer to section 4.3.1.6.
5.10.1.2.7.7 D̲e̲f̲i̲n̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲r̲a̲c̲e̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Operator commands exist to define the amount of trace
information to be produced by invocation of the SET
MASK procedure in the CAMPS system functions package.
5.10.1.2.7.8 P̲r̲i̲n̲t̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲u̲s̲
The operator VDU displays the main system status. An
operator command exists to print detailed system status
at the operator printer. Also, a command to print statistics
information about peripherals collected by drivers/handlers
exists.
5.10.1.2.7.9 T̲i̲m̲e̲ ̲o̲f̲ ̲D̲a̲y̲
The time of day command sets the active PU software
clock. Regularly the time of day transferred via checkpoints
to the stand by PU.
5.10.1.2.7.10 C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲W̲a̲t̲c̲h̲d̲o̲g̲
The operator can direct commands directly to the watchdog.
The following commands are foreseen:
- Set/reset specified watchdog controlled device
or bus connection. The commands are only applicable
prior to a start up, when defining the initial
configuration.
5.10.1.2.8 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
Application and system packages in the active PU transfer
checkpoint data to the stand-by branch to enable fast
recovery in case of switchover.
Whenever a "significant event" occurs a checkpoint
record of the event is sent to checkpoint collector
in the CAMPS system functions. The checkpoint collector
hands the collected record to the SSC, which transmits
the record to the stand by PU via the TDX bus.
Some checkpointing is indirect, as the MMS sends checkpoints
direct to the SSC, upon the occurence of specific events.
5.10.1.2.9 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
Checkpoint event records are received in the standby
processor via the TDX BUS. The SSC updates a number
of tables depending on the event type.
5.10.1.2.10 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.
5.10.1.2.10.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 start and close the following
support software:
- maintenance and diagnostics software
- offline utility software
- development and test software
- table generation software
Also commands to control execution of maintenance and
diagnostics software and offline utility software are
supported (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 modified
watchdog driver in the off-line PU.
5.10.1.2.10.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 maintenance and diagnostics 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 watchdog
operation, section 5.10.1.2.14).
5.10.1.2.11 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
5.10.1.2.12 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 configuration control bus (CCB)
A detailed description of the watchdog monitoring and
control capabilities are given in section 4.3 and 5.4.
The monitoring of the crates through the configuration
control bus is performed by a periodic scanning.
5.10.1.2.12.1 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 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.
5.10.1.2.13 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 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.
5.10.1.3 P̲a̲c̲k̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
5.10.1.3.1 P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲U̲p̲d̲a̲t̲e̲
The Table Management Package synchronizes update of
the following table:
- configuration table
- terminal profile table
The Terminal Package synchronizes the volume handling
on the off-line disk.
5.10.1.3.2 H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲o̲f̲ ̲t̲h̲e̲ ̲S̲S̲C̲
The operator and the watchdog control hardware modules,
wherein the SSC Software resides as described in section
4.3.
5.10.1.3.3 E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s̲
Children of COPSY within the SSC package reports errors
not handled internally to COPSY via the Kernel ERROR
procedure.
Children of COPSY within the SSC package reports the
result of errors handled internally to COPSY via the
CAMPS System Function REPORT procedure.
5.10.1.4 C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
5.10.1.4.1 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
a) T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
N.A.
b) S̲t̲o̲r̲a̲g̲e̲
N.A.
c) C̲o̲n̲n̲e̲c̲t̲i̲v̲i̲t̲y̲
N.A.
d) T̲i̲m̲i̲n̲g̲
- A switchover is to be performed within 60 seconds
(refer section 4.3).
- Initialization is to be performed within 15
minutes
- Recovery/restart subsequent to a total system
failure is to be performed within 15 minutes.
- The time to reintegrate redundant items (e.g.
PU or module or bus) into the on-line operational
configuration is to be performed within 5 minutes.
- The watchdog shall support the following line
speeds:
- to PUs: 9.6 K Baud
- to operator printer: 300 lines per minute
with 100 chars per line
- to operator VDU: variable 50-9600 Baud;
a fixed value will be defined during detailed
design.
5.10.1.4.2 A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲,̲ ̲M̲a̲i̲n̲t̲a̲i̲n̲a̲b̲i̲l̲i̲t̲y̲,̲ ̲a̲n̲d̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲
̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
Availability, maintainability, and integrity of operation
is covered in general in section 4.10. SSC contains
the following specific features:
- on-line diagnostics programs
- technical error processing
- recovery/restart actions including switchover
- monitoring of hardware module status
- physical control of hardware modules
5.10.1.4.3 S̲e̲c̲u̲r̲i̲t̲y̲
a) A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
There is no access control for the systems operator.
The SSC contains the CAMPS top level operating
system, which specifies access and security control
during start up for the system. Also, the SSC updates
security control specification during on-line operation:
- during error fix up
- during execution of operator commands
- insert/remove hardware module/line
- open/close external lines
- during sign on/off procedures
b) A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
1) L̲o̲g̲
TEMCO will generate logs during execution of
the following terminal procedures:
- security interrogation (I1)
- security warning (I2)
- sign-on (K1)
- sign-off (K2)
2) S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
TEMCO will generate statistics during execution
of the following procedures:
- security interrogation (I1)
- security warning (I2)
3) R̲e̲p̲o̲r̲t̲s̲
TEMCO will generate security reports as specified
below:
- unsuccessful sign-on attempt
- unsuccessful security interrogation and
whether it was due to time-out or faulty
password
- security warning time out or invalid entry
code
A security report will be generated if
- unsuccessful system integrity check
5.10.1.5 D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
Refer to section 2.5
5.10.1.6 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Refer to section 2.6.
5.10.2 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
5.10.2.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
a) Operator interfaces
1) The SSC implements the operator commands described
in CPS/230/ICD/0002: Supervisor Commands and
Procedures.
2) The SSC implements the
- Sign on
- Sign off
- Security interrogation
- Security Warning
procedures in CPS/230/ICD/001: User procedures
and Associated Formats
5.10.2.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The remainder of this section contains block diagrams,
which defines functional interfaces to other packages.
Dotted lines are used for informative reasons. The
last digit(s) in the block diagram reference number
relates to the digit(s) in the functional decomposition
in figure 5.10.1.2-1.
1) Set-up initial configuration
- Enable PU
- Set PU in normal mode
- Assign a disk drive to PU
- Issue master clean
2) Specify boot load disk drive to the CPU, which
executes the MIA PROM program and specify if memory
dump is to be performed.
3) Perform memory of segments from the specified disk
and start execution of the loaded software.
Block Diagram 5.10.2.2-1 (1 og 3)…01…SSC Interfaces during Start-Up
Block Diagram 5.10.1.1-1 (2 of 3)
SSC Interfaces during Start-up
1) SSC hands start-up information to child processes
via a queue I/F. Refer to section 5.10.1.2.1.3
for a definition of the different start-up modes.
2) Shared system data are mapped into segments common
to all processes.
3) Private system data for the process is defined.
Block Diagram 5.10.2.2-1 (3 of 3)
Process Environment at Start Up
1) Errors not handled by a process are given to the
parent of the process via a queue and the process
is stopped.
2) Errors handled by an application are reported to
the SSC via the REPORT facility in CSF
3) Firmware generated interrupts and Kernel detected
software errors.
4) Detailed error description
5) Status display
6) If the operator printer is unavailable, then errors
reports are directed to the Supervisor report printer.
Block Diagram 5.10.2.2-2 (1 of 1)…01…SSC Technical Error Processing I/F
a) S̲S̲C̲ ̲I̲/̲F̲ ̲d̲u̲r̲i̲n̲g̲ ̲V̲D̲U̲ ̲k̲e̲y̲-̲o̲n̲
1) Receive key-on indication
2) Initialize screen and await sign-in.
b) S̲S̲C̲ ̲I̲/̲F̲ ̲d̲u̲r̲i̲n̲g̲ ̲V̲D̲U̲ ̲k̲e̲y̲-̲o̲f̲f̲
10) Receive key-off indication
11) TEP cancels the current transaction (if existing)
12) SSC sign-off the TEP instance (if existing)
c) S̲S̲C̲ ̲I̲/̲F̲ ̲d̲u̲r̲i̲n̲g̲ ̲P̲T̲R̲/̲M̲T̲P̲ ̲K̲e̲y̲-̲o̲n̲
20) Receive key-on indication
21) Search if supervisor has specified accept of
input/output to the PTR/MTP
22) If accept then create TEP-instance handling
the PTR/MTP.
23) If not accept then update device profile and
await supervisor to set accept.
d) S̲S̲C̲ ̲I̲/̲F̲ ̲d̲u̲r̲i̲n̲g̲ ̲P̲T̲R̲/̲M̲T̲P̲ ̲k̲e̲y̲-̲o̲f̲f̲
30) Receive key-off indication
31) TEP cancels current transaction (if existing)
32) SSC deletes the TEP instance handling the PTR/MTP
Block Diagram 5.10.2.2-4 (1 of 4)
TEMCO Key On/Off Interfaces
a) S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲e̲s̲ ̲A̲c̲c̲e̲p̲t̲ ̲o̲f̲ ̲I̲n̲p̲u̲t̲/̲o̲u̲t̲p̲u̲t̲ ̲f̲o̲r̲
O̲C̲R̲,̲ ̲P̲T̲R̲,̲ ̲P̲T̲P̲,̲ ̲L̲T̲P̲,̲ ̲M̲T̲P̲
1) SSC receives notification.
2) PTR or MTP: Search if locking mechanism is
on.
3) PTR or MTP: Create a TEP-instance handling
the device, if locking mechanism is on
4) OCR, PTP, LTP: Create a TEP-instance handling
the device.
b) S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲e̲s̲ ̲n̲o̲t̲ ̲A̲c̲c̲e̲p̲t̲ ̲o̲f̲ ̲I̲n̲p̲u̲t̲/̲O̲u̲t̲p̲u̲t̲
̲f̲o̲r̲ O̲C̲R̲,̲ ̲P̲T̲R̲,̲ ̲P̲T̲P̲,̲ ̲T̲P̲.
10) SSC receives notification.
11) The TEP instance handling the device, cancels
the current transaction (if existing).
12) The SSC deletes the TEP-instance.
Blockdiagram 5.10.2.2-4 (2 of 4)…01…TEMCO I/F During Supervisor Set of Accept/Not
Accept of
Input/Output for OCR, PTR, PTP, LTP and MTP.
Refer to block diagram overleaf.
a) S̲S̲C̲ ̲I̲/̲F̲ ̲D̲u̲r̲i̲n̲g̲ ̲S̲i̲g̲n̲-̲O̲n̲
1) Sign-on indication received
2) Initialize screen
3) Read user-ID and password
4) Check validity of user-id and password
5) If check not ok then sign-off (refer below) and block terminal and generate report,
else
6) Create active profile
7) Create instance of terminal system
- set functional capabilities access rights
- set logical line classification to that
of the terminal profile. The classification
is only modified if a profile change has
occurred.
- set TEP instance classification to minimum
of terminal and user profile. The classification
is only modified if a profile change has
occurred.
8) Notify MDP (which moves queue elements from
the passive terminal queue to the active terminal
queue) and get reply.
9) Generate log
b) S̲S̲C̲ ̲I̲/̲F̲ ̲D̲u̲r̲i̲n̲g̲ ̲S̲i̲g̲n̲-̲O̲f̲f̲
10) Receive sign-off indication
11) Delete active Profile
12) Delete instance of terminal system
13) Notify MDP (which moves active queue-elements
to either the passive terminal queue or the
MDCO) and gets reply.
14) Update VDU screen.
15) Generate log.
Blockdiagram 5.10.2.2-4 (3 of 4)…01…TEMCO Interfaces during Sign-in/off
Refer to block diagram overleaf.
a) S̲e̲c̲u̲r̲i̲t̲y̲ ̲I̲n̲t̲e̲r̲r̲o̲g̲a̲t̲i̲o̲n̲ ̲I̲/̲F̲
1) Receive notification
2) Interrogate operator for password
3) Check password
4) If invalid: generate report and sign-off terminal
system instance (refer sign-off)
5) Answer message monitor
6) Generate log and statistics
b) S̲e̲c̲u̲r̲i̲t̲y̲ ̲W̲a̲r̲n̲i̲n̲g̲ ̲I̲/̲F̲
10) Receive notification
11) Search security warning text
12) Display it
13) Search security warning code
14) Request operator to define code and check code
15) If check not ok: then generate report and sign-off
terminal system instance (refer sign-off)
16) Answer message monitor
17) Generate log and statistics
Block Diagram 5.10.2.2-4 (4 of 4)
TEMCO Interfaces
1) On-line diagnostics invokes execution of periodic
tests by calling the TIME manager
2) Non-destructive built-in tests are executed via
drivers/handlers
3) Execute CPU, MAP, RAM test (Software tests)
10) The supervisor request the execution of the systems
integrity test
Block Diagram 5.10.2.2-5 (1 of 1)…01…On-Line Diagnostics Interfaces
a) S̲e̲n̲d̲ ̲K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
1) Notify time manager
2) Receive time elapsed signal
b) W̲a̲t̲c̲h̲d̲o̲g̲ ̲D̲r̲i̲v̲e̲r̲ ̲I̲/̲F̲
10) Send request
11) Await Reply
c) S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲t̲o̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲P̲r̲i̲n̲t̲e̲r̲
20) Detailed system status
21) Detailed error reports
Block Diagram 5.10.2.2-6…01…Watchdog Communication Software Interfaces
1) Switch to stand-by TDX BUS
2) Switch to spare LTUX (subsequent to a patch
of terminal equipment)
1&2) Update the Configuration table
Block Diagram 5.10.2.2-7 (1 of 6)
Operator function I/Fs
1) Set time of day
2) Copy modified application software from floppy
disk to off-line or on-line disks
3) Set trace mask
4) Search detailed system status for print out at
the operator printer
5) Request driver/handler statistics for subsequent
print out at operator printer
Block diagram 5.10.2.2-7 (2 of 6)
Operator Functions I/F
Refer to block diagram overleaf.
a) V̲o̲l̲u̲m̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
1) Mount/dismount
- on-line disk(s) volume
- floppy disk volume
2) Request supervisor to mount/dismount off-line
disk volume
3) Acknowledge mount/dismount volume
4) Update Configuration table
b) D̲i̲s̲k̲ ̲D̲r̲i̲v̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
10) Assign/deassign
- on-line disk drive
- floppy disk drive
- off-line disk drive
11) Off-line disk drive assigned or to be deassigned
12) Acknowledge receipt of above command
13) Update Configuration table
c) T̲D̲X̲-̲B̲U̲S̲ ̲S̲y̲s̲t̲e̲m̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
20) Insert TDX-BUS and initialize TDX-CTR
21) Remove TDX-BUS
22) Update Configuration table
Block Diagram 5.10.2.2-7 (3 of 6)…01…Operator Functions I/F (Volume, Disk Drive and
TDX-BUS Handling)
Refer to block diagram overleaf
a) L̲T̲U̲X̲/̲L̲T̲U̲X̲-̲t̲e̲r̲m̲i̲n̲a̲l̲ ̲l̲i̲n̲e̲ ̲t̲o̲ ̲b̲e̲ ̲R̲e̲m̲o̲v̲e̲d̲
The following functions are recognized:
- connect LTUX to offline TDX Bus
- take LTUX out of service
- disable LTUX-line
1) Notify TEP-instance(s)
2) Await answer
3) Deassign line(s) and delete terminal instance(s)
4) Update Configuration table
b) L̲T̲U̲/̲L̲T̲U̲-̲L̲i̲n̲e̲ ̲o̲r̲ ̲L̲T̲U̲X̲/̲L̲T̲U̲X̲-̲T̲R̲C̲ ̲o̲r̲ ̲P̲o̲i̲n̲t̲ ̲t̲o̲ ̲P̲o̲i̲n̲t̲
̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲L̲i̲n̲e̲ ̲t̲o̲ ̲b̲e̲ ̲R̲e̲m̲o̲v̲e̲d̲
The following functions are recognized:
- connect LTUX to offline TDX-Bus
- connect LTU to offline PU
- disable LTU or LTUX-line
10) Notify THP-instance(s)
11) Await answer
12) Deassign line(s) and delete THP instance(s)
13) Update Configuration table
c) I̲n̲s̲e̲r̲t̲ ̲L̲T̲U̲X̲/̲L̲T̲U̲X̲-̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲L̲i̲n̲e̲
The following functions are recognized:
- connect LTUX to active PU
- enable LTUX line
20) Assign line(s)
21) Await key-on from IOC
22) Update Configuration table
d) I̲n̲s̲e̲r̲t̲ ̲L̲T̲U̲/̲L̲T̲U̲-̲L̲i̲n̲e̲ ̲o̲r̲ ̲L̲T̲U̲X̲/̲L̲T̲U̲X̲-̲T̲R̲C̲ ̲L̲i̲n̲e̲
The following functions are recognized:
- connect LTUX to active R
- connect LTU to offline PU
- enable LTU or LTUX-line
30) Assign Line(s)
31) Create THP-instance(s)
32) Update Configuration table
* A detailed design of creation and deletion of TEP
and THP instances will be defined during module
design
Block Diagram 5.10.2.2-7 (4 of 6)
Insertion/Removal of LTU,LTUX Lines
At a logical close or open of an external line the
external line classification is updated, if a modification
by the supervisor has occurred.
1) Look up channel classification
2) If channel classification modified then change
line classification accordingly
Block Diagram 5.10.2.2-7 (5 of 6)…01…Specification of External Lines Security Classification
Refer to block diagram overleaf
a) T̲a̲k̲e̲ ̲S̲t̲a̲n̲d̲b̲y̲ ̲P̲U̲ ̲O̲f̲f̲l̲i̲n̲e̲/̲I̲n̲s̲e̲r̲t̲ ̲S̲t̲a̲n̲d̲-̲b̲y̲ ̲P̲U̲
1) Notify checkpoint generation procedure in CSF
2) Notify MMS
3) Update Configuration table
b) O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
10) Command TEP to close input within specified
period
11) Command THP to close input, when a complete
in message is processed
12) Command remaining packages to terminate processing
13) Receive acknowledgement
14) Await all queues to be emptied (queue monitor
signal)
15) Remove all application processes (detailed
I/F will be defined during module design)
16) Update Configuration table
c) O̲r̲d̲e̲r̲e̲d̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
20) Command TEP to stop execution, when the current
transaction is terminated.
Also presentation is to be stopped, when a
complete transaction is executed.
21) Command THP to close input and output of messages,
when a complete message is processed.
22) Command remaining packages to terminate processing.
23) Receive acknowledgement
24) Update Configuration table.
25) The watchdog is notified and it isolates the
active PU and commands the stand by PU to become
active.
d) O̲r̲d̲e̲r̲e̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲(̲T̲y̲p̲e̲ ̲2̲)̲
30) Command TEP to stop execution, when the current
transaction is terminated.
Also presentation is to be stopped, when a
complete transaction is executed.
31) Command THP to close input and output of messages,
when a complete message is processed.
32) Command remaining packages to terminate processing.
33) Receive acknowledgement
34) Update configuration table.
35) Direct CSF to save current queue contents and
memory resident table information on disk.
36) Stop all processes.
Block Diagram 5.10.2.2-7 (6 of 6)…01…Operator Command I/Fs
1) Call Checkpoint procedure
2) Invoke SSC checkpoint process
3) Transfer checkpoint data
4) Receive data
5) Depending on event type invoke an appropriate CSF
procedure
6) Acknowledge the reception of the checkpoint record
Block Diagram 5.10.2.2-8 …01…Checkpointing via TDX Bus
* NORMAL or MAINTENANCE MODE is set via a switch
on the MAP or via Watchdog control signals.
Block Diagram 5.10.2.2-10 (1 of 1)…01…SSC command I/F to Off-Line PU
