top - download
⟦287df1cd2⟧ Wang Wps File
Length: 53008 (0xcf10)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »0467A «
Derivation
└─⟦0cbd6095b⟧ Bits:30006077 8" Wang WCS floppy, CR 0034A
└─ ⟦this⟧ »0467A «
WangText
F…0b…F
F…05…E…09…E…0e…E…0f…E…00…E
E D…09…D…0a…D…0f…D…02…D
C…09…:…01…9…08…9…0d…9…02…9…07…6
5…09…5…0e…5…86…1
…02…
…02… …02…
…02…CPS/SDS/001
…02…FH/810115…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 .............................
5.10.1 Summary of Requirements .............
5.10.1.1 Package Description .............
5.10.1.1.1 General Description .........
5.10.1.1.2 Package References ..........
5.10.1.1.3 External Interfaces .........
5.10.1.1.4 Block Diagram ...............
5.10.1.2 Package Functions ...............
5.10.1.2.1 Start Up ....................
5.10.1.2.1.1 Disk Start Up Information
5.10.1.2.1.2 Start Up of Off-Line PU .
5.10.1.2.1.3 Start Up of On-Line Ope-
rations .................
5.10.1.2.1.4 Initialization of On-Line
Operation (Dead and Cold
Start) ..................
5.10.1.2.1.5 Memory Dump .............
5.10.1.2.1.6 Start Up Subsequent to an
Ordered Close Down
(WARM1) .................
5.10.1.2.1.7 Start Up after a Total
System Failure (WARM2) ..
5.10.1.2.1.8 Switchover and Subsequent
Recovery/Restart (WARM3)
5.10.1.2.1.9 Start Up Subsequent to an
Ordered Close Down
(WARM4) .................
5.10.1.2.1.10 Restart of a Stand By PU
5.10.1.2.2 Technical Error Processing ..
5.10.1.2.3 Resource Management .........
5.10.1.2.4 Terminal Monitoring and
Control (TEMCO) .............
5.10.1.2.4.1 Access Control for Ter-
minal Positions .........
5.10.1.2.4.2 Terminal Position
Delivery Control ........
5.10.1.2.4.3 Generation of Logs, Re-
ports, and Statistics ...
5.10.1.2.5 On-Line Diagnostics .........
5.10.1.2.6 Watchdog Communication ......
5.10.1.2.7 Operator Functions ..........
5.10.1.2.7.1 Switch Between Dualized
Equipment ...............
5.10.1.2.7.2 Removal/Insertion of
Units ...................
5.10.1.2.7.3 Control of Line Attri-
butes ...................
5.10.1.2.7.4 Start Up Commands .......
5.10.1.2.7.5 Close Down of a PU ......
5.10.1.2.7.6 Load of New Software ....
5.10.1.2.7.7 Define Generation of
Trace Information .......
5.10.1.2.7.8 Print of System Status ..
5.10.1.2.7.9 Time of Day .............
5.10.1.2.7.10 Commands to the Watchdog
5.10.1.2.8 Checkpoint Transmission .....
5.10.1.2.9 Checkpoint Reception ........
5.10.1.2.10 Off-Line PU Operation .......
5.10.1.2.10.1 Commands to the Off-
Line PU ................
5.10.1.2.10.2 Allocation of Resources
to the Off-Line PU .....
5.10.1.2.11 Watchdog Line Communications
5.10.1.2.12 Switch Logic ...............
5.10.1.2.12.1 Switchover .............
5.10.1.2.13 Watchdog Standard Firmware .
5.10.1.3 Package Control .................
5.10.1.3.1 Parameter Update ............
5.10.1.3.2 Hardware Control of the SSC .
5.10.1.3.3 Error Reporting Mechanisms ..
5.10.1.4 Characteristics .................
5.10.1.4.1 Performance .................
5.10.1.4.2 Availability, Maintainabili-
ty, and Integrity of Opera-
tion ........................
5.10.1.4.3 Security ....................
5.10.1.5 Design and Construction .........
5.10.1.6 Documentation ...................
5.10.2 Environment .........................
5.10.2.1 External Interfaces .............
5.10.2.2 Package Interfaces ..............
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
- maintenance and diagnostics
The monitoring of the 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 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 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 Package
Watchdog Hardware Package
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
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 and 5.10.1.1.4-2
overleaf.
Figure 5.10.1.1.4-1…01…Dualized CAMPS Operation Block Diagram Package Interfaces
Figure 5.10.1.1.4-2…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
- development and test software (only at CSSI
site)
- maintenance and diagnostics software
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̲
As an option during dead, cold, warm1, warm2, warm4
start up modes the PU memory may be dumped to a file
on the disk being used for start up.
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 opdates 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
- 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 one of the following devices:
- a VDU
- a ROP
- an OCR
- a PTR
- a PTP
- a TP (low speed teleprinter)
VDU state transitions are caused by the following events:
- locking mechanism from off to on or from on to
off.
- sign in/out
The state transitions are available to TEMCO though
the IOC ROP 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
output.
The state transitions are available to TEMCO through
the IOC and TEP respectively:
OCR, PTR, PTP, TP state transitions are caused by the
following events:
- supervisor specification of accept/not accept of
input and/or output.
The state transitions are available to TEMCO through
the TEP.
a) V̲D̲U̲ ̲L̲o̲c̲k̲i̲n̲g̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲ ̲f̲r̲o̲m̲ ̲O̲f̲f̲ ̲t̲o̲ ̲O̲n̲
The VDU screen is initialized and a sign-in is
awaited.
b) S̲i̲g̲n̲-̲I̲n̲
Upon sign-in 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 and has been
detected. An unsuccessful sign-in attempt will
cause TEMCO to block the terminal position.
c) S̲i̲g̲n̲-̲O̲u̲t̲
Sign-out will cause TEMCO to withdraw access rights
and return the state of the terminal position to
Locking mechanism ON.
d) V̲D̲U̲ ̲L̲o̲c̲k̲i̲n̲g̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲ ̲f̲r̲o̲m̲ ̲O̲N̲ ̲t̲o̲ ̲O̲F̲F̲
The current transaction is cancelled and the VDU
is signed-off.
e) R̲O̲P̲ ̲K̲e̲y̲-̲o̲n̲
If the supervisor has specified accept of output
to the ROP a ROP TEP-instance is created.
f) S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲A̲c̲c̲e̲p̲t̲ ̲o̲f̲ ̲O̲u̲t̲p̲u̲t̲ ̲t̲o̲
̲a̲ R̲O̲P̲.
If the ROP key is on a ROP TEP-instance is created.
g) S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲N̲o̲n̲-̲a̲c̲c̲e̲p̲t̲ ̲o̲f̲ ̲O̲u̲t̲p̲u̲t̲
̲t̲o̲ a̲ ̲R̲O̲P̲.
If a TEP ROP-instance exists, the current transaction
is cancelled and the instance is deleted.
h) R̲O̲P̲ ̲K̲e̲y̲-̲o̲f̲f̲
Actions are identical to g) above.
i) 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̲,̲ ̲T̲P̲.
A TEP-instance handling the device is created.
j) 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̲.
A transaction in the device instance is cancelled
and the device-instance deleted.
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 operators, 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, TECMO 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 program aims
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 or 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.
The test programs may be based on built-in self test
programs in hardware modules. These test pograms are
for security reasons to be invoked via device drivers/
handlers.
5.10.1.2.6 W̲a̲t̲c̲h̲d̲o̲g̲ ̲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.
Periodically an active 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. swtich and patch) with software control.
The following types of operator commands are foreseen:
- switch between hardware units, when dualizaion
is used
- removal/insertion of units (e.g. VDUs)
- 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)
- switch to spare LTUX (hardware patch: Refer section
5.10.1.2.8.2b)
5.10.1.2.7.2 R̲e̲m̲o̲v̲a̲l̲/̲I̲n̲s̲e̲r̲t̲i̲o̲n̲ ̲o̲f̲ ̲U̲n̲i̲t̲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:
- remove/insert LTU to specified PU
- assign/deassign specific external 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:
- remove/insert LTUX to specified TDX BUS
- assing/deassign specific terminal line(s) to
a specified terminal position
- enable physical LTUX patch by assigning logical
lines related to an LTUX to a spare LTUX
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:
- remove/insert TDX-BUS and TDX-CTR and TDX-I/F
d) D̲i̲s̲k̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The SSC controls the logical line to physical disk
drive assignment for:
- the off-line disk
- the on-line (mirrored) disks
- the floppy disk
The control includes insertion (to active or non-active
PU) and removal of disk drive.
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
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 operators 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 operators are given a limited
time to close all input. Hereafter the TEP
stops, when a transaction (including presentation)
is completed.
The distribution of mesages 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 physically 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̲
At the CSSI site new application software is developed
and tested.
The modified application software is transported to
CAMPS installations on floppy disk packs.
The application software on the floppy disk is copied
to the on-line disks or the off-line disk on the file
for modified application software.
At a start-up subsequent to an ordered close down,
a switch-over, or during initialization the new software
may be used.
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 DTG of the active
PU software clock. Regularly the DTG is 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 command is 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.
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. According to the event type
an appropriate CAMPS system function is invoked to
handle the record.
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 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
- development and test software
Also commands to control execution of maintenance and
diagnostics software are supported (control of development
and test 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.
b) To support development and test 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 a physical
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. This will make it possible to connect
the operator VDU and printer directly to one PU,
if the watchdog fails.
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
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 crate configuration bus (CCB)
A detailed description of the watchdog monitoring and
control capabilities are given in section 4.3 and 5.4.
Overleaf a summary of the watchdog control capabilities
are depicted.
In addition to the watchdog control a manual control
in each crate is provided as a fallback possibility
if the watchdog fails and a reconfiguration has to
take place in that period.
The monitoring of the crates through the crate configuration
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.
WATCHDOG CONTROL CAMPS HARDWARE CONFIGURATION
FIGURE 5.10.1.2.12-1
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.
- Time for watchdog isolation of a PU: 1 second
- The watchdog shall support the following line
speeds:
- to PUs: 9.6 K Baud
- to operator printer: 120 char/sec
- to operator VDU: variable 50-9600 Baud.
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 errorprocessing
- 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 and which during
on-line operation updates security control specification.
- during error fix up
- during execution of operator commands
- insert/remove hardware module/line
- open/close external lines
- during sign in/out 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-in (K1)
- sign-out (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-in 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 in
- Sign out
- 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
Refer to block diagram overleaf.
a) S̲S̲C̲ ̲I̲/̲F̲ ̲D̲u̲r̲i̲n̲g̲ ̲K̲e̲y̲-̲O̲n̲
1) Key-on
2) Check if terminal position exists. If not then
ignore key-on
3) Search terminal profile. If not user position
then await sign-in, else
4) Search pseudo user file
5) Create active profile
6) Create instance of terminal system (details
will be defined during module design)
- set functional capabilites 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 unclassified
b) S̲S̲C̲ ̲I̲/̲F̲ ̲d̲u̲r̲i̲n̲g̲ ̲K̲e̲y̲-̲O̲f̲f̲
The instance of the terminal system is deleted
(if existing). The I/F is similar to sign-off.
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̲ ̲R̲O̲P̲ ̲k̲e̲y̲-̲o̲n̲
20) Receive key-on indication
21) Search if supervisor has specified accept of
output to the ROP.
22) If accept then create TEP-instance handling
the ROP.
If not accept then await supervisor to set
accept.
d) S̲S̲C̲ ̲I̲/̲F̲ ̲d̲u̲r̲i̲n̲g̲ ̲R̲O̲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 ROP.
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̲,̲ ̲T̲P̲.
1) SSC receives notification.
2) SSC creates 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 and TP.
Refer to block diagram overleaf.
a) S̲S̲C̲ ̲I̲/̲F̲ ̲D̲u̲r̲i̲n̲g̲ ̲S̲i̲g̲n̲-̲I̲n̲
1) Sign-in 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 profile classifications
have occurred.
8) - Notify MDP (which moves queue elements
from the passive terminal queue to the
active terminal queue) and gets 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
- off-line disk (only from stand by PU) 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 and TDX-IF
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̲
1) Notify TEP
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̲ ̲L̲i̲n̲e̲ ̲t̲o̲ ̲b̲e̲ ̲R̲e̲m̲o̲v̲e̲d̲
10) Notify THP
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̲
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̲
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) R̲e̲m̲o̲v̲e̲/̲I̲n̲s̲e̲r̲t̲ ̲S̲t̲a̲n̲d̲-̲b̲y̲ ̲P̲U̲
1) Notify checkpoint generation procedure in CSF
2) 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
