top - download
⟦caa5b7c6d⟧ Wang Wps File
Length: 90687 (0x1623f)
Types: Wang Wps File
Notes: FIX/1105/PSP/0046
Names: »3916A «
Derivation
└─⟦074b80a9e⟧ Bits:30006146 8" Wang WCS floppy, CR 0345A
└─ ⟦this⟧ »3916A «
WangText
…00……00……00…J…0a…J…0b……00……00…J…0c…J…0e…I…00…H…0b…6…06…5…0c…5…00…5…05…4…09…4…0a…4…0f…(…0b…(…0e…(…01…(…06…(…07…'…0d…'…01…'…07……17……0c……17……02……17……05……16……09……16……0c……16……0f……16…
…16……07……15……0a……15……0d……15…
…15……07……14……0b……14……0e……14……02……14……07……13……0c……13… …12……09……86…1 …02… …02… …02… …02…
3916A/0345A…86…1 …02… …02… …02…
…02…FIX/1105/PSP/0046
…02…APE/880923…02……02…#
ESP SYSTEM PSP
…02…Issue 1…02… FIKS
FIKS ESP SYSTEM
PRODUCT SPECIFICATION
FIX/1105/PSP/0046
CR84, AK
FMK (5), AK(4)
FIKS Pgm.Mgr.
2 FIKS Con.Mgr.
880923
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…06…1 …02… …02… …02…
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
AFFECTED
AFFECTED
AFFECTED
AFFECTED
AFFECTED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ^ ^
^
1 ^830531 ^ All ^
Original
issue
of
document.
^ ^ ^
2 ^880923 ^ All ^
General
update
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE .............................................
6
1.1 INTRODUCTION ..................................
6
1.2 ABBREVIATIONS .................................
6
2 APPLICABLE DOCUMENTS ..............................
7
2.1 SYSTEM SOFTWARE ...............................
7
2.2 FIKS DOCUMENTATION ............................
8
3 MODULE SPECIFICATION .............................
10
3.1 FUNCTIONAL CAPABILITIES .......................
10
3.2 INTERFACE DESCRIPTION .........................
13
3.2.1 Interface Overview ........................
13
3.2.2 System Command Format .....................
16
3.2.2.1 General Command Line ..................
16
3.2.2.2 Special Control Characters ............
17
3.2.2.3 Command Line Items ....................
18
3.2.2.4 Detailed Command Line Format ..........
22
3.2.2.5 Application Command Request ...........
35
3.2.2.6 Format of ESP-logging .................
36
3.2.2.7 USER-FILE-processor Interface .........
39
3.2.2.8 FIKS CDC-driver Interface .............
41
3.3 PROCESSING ....................................
43
3.3.1 ESP Main Flow .............................
43
3.3.2 Memory Management .........................
45
3.3.3 ESP Initializing Processing ...............
46
3.3.4 Disk System Management ....................
47
3.3.4.1 Disk Hardware Summary .................
47
3.3.4.2 Disk System Software Summary ..........
49
3.3.4.3 FIKS Dual Disk System .................
51
3.3.4.4 Initializing of FIKS Disk System ......
53
3.3.4.5 Handling of DISCARD-Disk-Errors .......
54
3.3.4.6 Dualizing of Disks ....................
56
3.3.4.7 Disk System State Transition Diagram
.. 57
3.3.4.8 Standby FILE-Processor Watchdog .......
59
3.3.4.9 Offline Disk Handling .................
59
3.3.4.10 Disk System Modification .............
60
3.3.5 TDX System Management .....................
63
3.3.5.1 TDX System Initializing ..............
63
3.3.5.2 Reinitializing of LTUX-Devices .......
65
3.3.5.3 TDX-System Modification ..............
65
3.3.6 Console Input/Output ......................
66
3.3.7 Watchdog Interface ........................
69
3.3.8 Command Interpretation ...................
70
3.3.9 Command Performance ......................
74
3.3.10 System Utilities ........................
92
3.3.10.1 Dump of Memory ......................
92
3.3.10.2 Debug Utility .......................
93
3.3.10.3 QACCESS/MTCB Utility ................
97
3.3.10.4 Inspect Utility .....................
100
3.3.10.5 Floppy Utility ......................
102
3.3.11 Command Files ...........................
103
3.3.12 Sequence of Commands ....................
103
3.3.13 Application Command .....................
106
3.3.14 ESP loggings ............................
107
3.3.15 Background Management ...................
108
3.3.15.1 Outline/Prerequisites ...............
109
3.3.15.2 Background Scheduling ...............
113
3.3.15.3 Background Process Control Block ....
117
3.3.15.4 Background Priority .................
118
3.3.15.5 Background Management Implementation..
118
3.3.15.6 Background Process Limitation .......
123
3.3.16 System Error Handling ...................
124
3.3.17 ESP Local Error Handling ................
126
3.3.18 Wild Events .............................
127
3.3.19 Processing of Events/Commands ...........
129
3.3.20 Initializing of the FIKS System .........
137
3.3.20.1 Boot Loading ........................
137
3.3.20.2 Initialization of Node/MEDE to ACTIVE.
140
3.3.20.3 Initialization of Node/MEDE to STANDBY
141
3.3.20.4 RECOVER/RESTART of Node/MEDE ........
142
3.3.20.5 Initialization of SCC ...............
144
3.3.20.6 CLOSE of System .....................
145
3.3.21 Enabling/Disabling of Bootmodules .......
147
3.3.22 Set SCC Supervisor Passwords ............
148
3.3.23 System Security Handling ................
149
3.3.24 ESP-overlay Processing ..................
151
3.3.25 Transfer in Memory ......................
153
3.4 DATA ORGANIZATION ............................
154
3.4.1 Internal Data Structures .................
154
3.4.1.1 CONSOL - process .....................
154
3.4.1.2 COMMAND-OVERLAY Identification .......
154
3.4.2 External Data Structures ..................
155
3.4.3 BGPS-FILE ................................
155
3.5 STORAGE ALLOCATION ...........................
157
3.6 PERFORMANCE CHARACTERISTICS ..................
157
3.7 LIMITATIONS ..................................
158
3.8 ERROR LOCATIONS ..............................
159
3.9 LISTING REFERENCE ............................
163
4 QUALITY ASSURANCE ................................
164
4.1 QUALIFICATIONS TESTS .........................
164
4.2 OTHER QUALITY ASSURANCE PROVISIONS ...........
164
5 PREPARATIONS FOR DELIVERY ........................
165
6 NOTES ............................................
166
6.1 MODULE GENERATION ............................
166
6.2 ESP ̲UTIL - PROGRAM ...........................
167
6.3 DIFFERENT ESP - VERSIONS .....................
168
6.4 GENERATION OF BOOT-MODULES ...................
168
7 APPENDIX .........................................
169
7.1 Command File Examples ........................
169
7.2 CR80 AMOS KERNEL PSP-DCN's ...................
175
1 S̲C̲O̲P̲E̲
This document is the Product Specification for the
ESP-system in the FIKS-system. I.e. the Error Switchover
Process and the modules/processes closely connected
to this process.
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The document is made out after the implementation of
the ESP-system was done. The docuent is primarily meant
to be used by those who are going to maintain the ESP-system.
Therefore, the intention with this document is to describe
the functions and procedures in the ESP-system in general
view and to explain the reasons why they are implemented
as they are. Some procedures which are rather simple
and can be easily understood by inspection of the source
listings may not be described in every detail. Capital
letters have been used to emphasize keywords used in
other documents or in the source listing.
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Refer to FIKS Data Interface Reference, FIX/0100/MAN/0004,
sec. 1.2.
2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
2.1 S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
1) CR80 AMOS Kernel,
Product Specification, CSS/302/PSP/0008
2) CR80 AMOS I/O System,
Product Specification, CSS/006/PSP/0006
3) CR80 DMA Link Driver,
Product Specification, CSS/006/PSP/0002
4) CR80 MOS File Management System,
System Product Specification, CSS/920/PSP/0001
5) CR80 AMOS FMS Command Controller,
Product Specification, CSS/920/PSP/0046
6) CR80 AMOS FMS Disk Cache Manager,
Product Specification, CSS/920/PSP/0047
7) CR80 AMOS FMS File Manager
Product Specification, CSS/920/PSP/0048
8) CR80 Disk Driver,
Product Specification, CSS/920/PSP/0005
9) CR80 TDX Driver,
Product Specification, CSS/314/PSP/0013
10) TDX HOST I/F, CR 1072,
Product Specification, CSD-MIC/005/PSP/0004
11) CR80 Minicomputer Handbook,
CR80/HDBK/0001
2.2 F̲I̲K̲S̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
12) FIKS System PSP
FIX/1000/PSP/0038
13) FIKS Data Interface Reference
FIX/0100/MAN/0004
14) FIKS Watchdog Firmware Product
Specification, FIX/3200/PSP/0028
15) Functional Specification of FIKS BOOT Leader,
FIX/1000/EWP/0076
16) LCHF Monitor,
FIX/1256/PSP/0055
17) Convert DTG Monitor,
FIX/1256/PSP/0039
18) GET ̲DTG Monitor
FIX/1256/PSP/0049
19) SAF Subsystem,
FIX/1155/PSP/0088
20) SRS Subsystem,
FIX/1153/PSP/0097
21) Checkpoint Subsystem,
FIX/1100/PSP/0041
22) SYSCHP Procedure
FIX/1200/PSP/0098
23) RESPDB Procedure
FIX/1200/PSP/0085
24) OLD Subsystem
FIX/1200/PSP/0072
25) RECOVM Procedure
FIX/1200/PSP/0084
26) RECMES Procedure
FIX/1200/PSP/0083
27) Q-INIT Procecure
FIX/1200/PSP/0079
28) MTCB INIT Procedure
FIX/1200/PSP/0067
29) SDS or Minor FIKS System Updates
FXA/SDS/008
30) NODAL SWITCH SUBSYSTEM (NSS)
FIX/1154/PSP/0107
3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
3.1 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
In the FIKS-system, the ESP-system has the following
tasks:
1. B̲O̲O̲T̲ ̲L̲O̲A̲D̲ ̲S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
- Reorganize the main memory
when bootstrap loading is finished.
- Create and start all processes
included in the boot module.
- Initialize all monitor procedures
included in the boot module.
2. M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
- Allocate and delocate
CR80-memory areas.
3. M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲
- Create DMA-link to the FMS-system.
- Determine which disks are usable.
- Assign/deassign disk-devices.
- Discard unusable disks.
- Include repaired disks.
- Mount/dismount disk-volumes.
4. M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲(̲p̲a̲r̲t̲l̲y̲)̲ ̲o̲f̲ ̲t̲h̲e̲ ̲T̲D̲X̲-̲s̲y̲s̲t̲e̲m̲
- Assign RED and Black TDX-host.
- Initialization of LTUX-devices in the
Red TDX-system used of terminals.
- Reinitialization of a LTUX-device in the
Red TDX-system used of terminals.
- Send reinitialization of LTUX-device commands
to the NSS-process.
5. S̲y̲s̲t̲e̲m̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
- Recieve input command from
the system operator.
- Outputting control information
to the operator.
6. W̲a̲t̲c̲h̲d̲o̲g̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
- Answer to Watchdog-polling.
- Recieve and execute commands
from the Watchdog.
7. C̲o̲m̲m̲a̲n̲d̲ ̲P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
- Validate and check recieved commands.
- Interpret the commands.
- Execute the commands.
- Logging of the executed commands.
8. S̲y̲s̲t̲e̲m̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
- Recieve error reports.
- Analyse error cases.
- Execute 'LOCAL ̲FIX'-processing
on system level.
- Logging of error cases.
- Recieving and handling of 'WILD EVENTS'.
9. B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
- Loading of background processes.
- Scheduling of background processing.
- Swapping in/out of background processes.
10. M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲o̲f̲ ̲R̲E̲S̲T̲A̲R̲T̲
- Closing of the system.
- Starting of RECOVER.
- Reporting of changes in
the status of the system.
11. S̲e̲c̲u̲r̲i̲t̲y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
- Control operartors access to
command performance
-Enable/disable bootmodules
-Update SCC Supervisor password
12. S̲y̲s̲t̲e̲m̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲
- Listing of system status.
- Debug facilities.
- Inspect (of files) facilities.
- Error dump utilities.
- Floppy utilities
- QACCESS/MTCB utilities
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
3.2.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
System Interface Data ref (13)
Refer to figure 3.2.1 - General View.
In the following is listed the kinds of interface that
exist between the ESP-system and the other modules
of the FIKS-system.
S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
1. KERNEL
- internal datastructures
- use of AMOS-message functions
- use of critical region operations
2. DMA-driver
- user-fileprocessor link (URS-FIL)
3. CDC-driver via URS-FIL.
4. FMS-system via IO-system.
5. TDX-system via IO-system.
F̲I̲K̲S̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
1. U̲s̲e̲ ̲o̲f̲ ̲F̲I̲K̲S̲ ̲m̲o̲n̲i̲t̲o̲r̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
1. GET ̲DTG - Get DTG, ref (14)
2. CONVDTG - Convert DTG, ref (18)
3. LCFH - LTUX Configuration
File Handler, ref (16)
2. U̲s̲e̲ ̲o̲f̲ ̲F̲I̲K̲S̲-̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲s̲
1. CONFIG, Configuration Table
2. XTCBCR, Terminal Control Blocks
3. F̲I̲K̲S̲-̲p̲r̲o̲c̲e̲s̲s̲e̲s̲
1. SAF-process. ref (19)
- AMOS message concerning
system status change.
2. NSS-process. ref (30)
- AMOS message containing
reinitialize LTUX-device commands
3. Other FIKS-processes.
- AMOS parent signals indicating
an error report.
- AMOS message containing
command input.
5. F̲i̲l̲e̲s̲
1. CHECKP ̲FILE, Checkpoint File
2. LOAD ̲FILES, files containing
modules to be loaded.
3. COMMAND ̲FILES, files containing
command input.
4. SRS ̲CHECKP, Checkpoint File for
SRS-process. ref (20).
5. USP ̲FILE, file containing
user profiles, ref (13)
6. S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
1. Watchdog, ref (14)
- via SCM-interface.
2. System operator,
- via Watchdog/SCM-interface
- or directly via SCM-interface
Figure 3.2.1
ESP System Interface Description Overview
3.2.2 S̲y̲s̲t̲e̲m̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲F̲o̲r̲m̲a̲t̲
3.2.2.1 G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲L̲i̲n̲e̲
When ' ' is printed on the console the ESP-system
is ready to recieve input commands from the system
operator.
A command is given to the system by keying in on the
console one or more items (continuous string of ASCII-
characters) in one line.
In the following is listed the general rules that shall
be obeyed.
1. Each item must be separated with at least one space.
2. The linelength must be less than 69 characters.
3. The line must be terminated with CR or CR + LF
( ).
4. Numeric items (0-65535) can be keyed in both as
decimals and hexadecimals (then started with '#').
Maximum of five characters are accepted - if more
keyed in then only the five most rigth are used.
5. Names must be started with a character in the range
A-Z. If more characters, than specified as the
length of the name, are keyed in, then only the
most left and last rigth characters are used. If
'*' is keyed as first character, then the last
used corresponding name (same item type) will be
used again.
When one of these rules is violated then a message
* SYNTAX ERROR
appears and correct keying in can be done.
Characters beyond what is needed to interpret a command
line is ignored (can be used as comments).
3.2.2.2 S̲p̲e̲c̲i̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲s̲
Some characters are reserved for a specific purpose.
These are listed in the following:
'̲/̲'̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲ ̲2̲F̲:
Delete last character (backspace one key).
D̲E̲L̲/̲R̲U̲B̲O̲O̲T̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲ ̲7̲F̲:
Cancel what is keyed in current line.
'̲%̲'̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲2̲5̲:
Repeat last line (command). The line is not echoed
back to the console.
'̲!̲'̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲ ̲2̲1̲:
Interrupt system command. I.e. execution of a going
on command will be stopped.
'̲ ̲'̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲ ̲3̲C̲:
Disable ESP-log printout
'̲ ̲'̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲ ̲3̲E̲
Enable ESP-log printout
'̲"̲'̲ ̲-̲ ̲h̲e̲x̲v̲a̲l̲u̲e̲ ̲#̲ ̲2̲2̲:
The line is a comment line - no interpretation.
The character must be placed as first character
in the line.
3.2.2.3 C̲o̲m̲m̲a̲n̲d̲ ̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲s̲
A command line consists of one or more of the following
items:
CW MT NA PA LO SZ N1 N2 PL VN
FN
the order in which the items appear above must be kept.
In the following is given a list of the single items:
C̲W̲ ̲=̲ ̲c̲o̲m̲m̲a̲n̲d̲ ̲v̲e̲r̲b̲
- Must always be present. May be of variable length.
Only first and last characters are significant. See
table 3.2.2.3.1 for a complete list of all possibilities.
M̲T̲ ̲=̲ ̲m̲o̲d̲u̲l̲e̲ ̲t̲y̲p̲e̲
- May be of variable length. Only first and last characters
are significant. See table 3.2.2.3.2 for a complete
list of all possibilities.
N̲A̲ ̲=̲ ̲N̲a̲m̲e̲ ̲o̲f̲ ̲p̲r̲o̲c̲e̲s̲s̲ ̲o̲r̲ ̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲
- 6 character long name.
P̲A̲ ̲=̲ ̲P̲a̲g̲e̲ ̲i̲n̲ ̲C̲R̲8̲0̲-̲m̲e̲m̲o̲r̲y̲
- Numeric in the range 0-3.
L̲O̲ ̲=̲ ̲A̲b̲s̲o̲l̲u̲t̲e̲ ̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲i̲n̲ ̲C̲R̲8̲0̲-̲p̲a̲g̲e̲
- Numeric. If '*' keyed in then the next free location
on the referred page will be used. (ref. sec. 3.3.2).
S̲Z̲ ̲=̲ ̲S̲i̲z̲e̲ ̲(̲o̲f̲ ̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲s̲)̲ ̲i̲n̲ ̲w̲o̲r̲d̲s̲.̲
- Numeric.
N1 = NUMBER 1
N̲2̲ ̲=̲ ̲N̲U̲M̲B̲E̲R̲ ̲2̲
- Numerics.
P̲L̲ ̲=̲ ̲A̲b̲s̲o̲l̲u̲t̲e̲ ̲p̲r̲o̲g̲r̲a̲m̲ ̲l̲o̲c̲a̲t̲i̲o̲n̲
- Numeric. Location is always in page 0. If '*' is
keyed in then the last referred program location
is used.
V̲N̲ ̲=̲ ̲V̲o̲l̲u̲m̲e̲ ̲n̲a̲m̲e̲
- 16 character long name.
F̲N̲ ̲=̲ ̲F̲i̲l̲e̲ ̲n̲a̲m̲e̲
- 16 character long name.
(1/2)
L̲i̲s̲t̲ ̲o̲f̲ ̲A̲v̲a̲i̲l̲a̲b̲l̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
̲ ̲C̲W̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
LD LOAD of file to CR80-memory
CE CREATE of critical region
ST START of process
RE REMOVE of process
SP STOP of process
UN USER ̲ON of FMS-user
UF USER ̲OFF of FMS-user
AN ASSIGN of disk devices
DN DEASSIGN of disk devices
MT MOUNT of disk volumes
DT DEMOUNT of disk volumes
UE UPDATE of disk volumes
(1)DD DISCARD of disk device
GT GETROOT of volume/SYSDIR: = MD
DR DEFINE ̲SYSDIR lookup of SYSDIR
TD TAKE ̲COMMAND use file as input
CM CLOSE ̲SYSTEM stop all processing
(1)RM RECOVER ̲SYSTEM get branch ACTIVE
(1)SF STANDBY ̲OFF tell the system
(1)SN STANDBY ̲ON tell the system
RN RUN background process
RY RUN ̲AND ̲DELAY background process
IX INITIALIZE ̲TDX assign HOST, init devices
IE INITIALIZE ̲DEVICE reinitialize TDX-device
(continues)
(2/2)
L̲i̲s̲t̲ ̲o̲f̲ ̲A̲v̲a̲i̲l̲a̲b̲l̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
̲ ̲C̲W̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PS PROCESSES print status
FM FILE ̲SYSTEM print status
DM DISK ̲SYSTEM print status
CS CRITICAL ̲REGIONS print status
TM TDX ̲SYSTEM print status
SG SET ̲DTG set time
(1)CG CHECK ̲DTG check if legal DTG
(1)LG LOAD ̲DTG load old DTG
(1)SE START ̲DUALIZE enable dual disk write
(1)FE FINISH ̲DUALIZE tell system: Dual Disk status
(2)DY DUMP ̲MEMORY dump CR80-memory to disk
(2)DG DEBUG dump/patch CR80 memory
(2)QM QACCESS/MTCB dump queues/MTCB's
(2)IT INSPECT dump/patch files
(2)FY FLOPPY dump of files to/from disk
(3)DP DEFINE ̲ERROR ̲DUMP definition of error dump
(3)EP ERROR ̲DUMP manual error dump
EE ENTER ̲SECURITY ̲MODE enable safety commands
LE LEAVE ̲SECURITY ̲MODE disable safety commands
(2)EB ENABLE ̲BOOT ̲MODULE
DB DISABLE ̲BOOT ̲MODULE
(4)SD SET ̲SCC ̲SUP ̲PASSWORD Update SCC supervisor profile
(1) Not available at SCC-systems
(2) Only available after "Enter of
security mode" (SYS).
(3) Only when error dump facilities is included.
(4) Only at SCC-systems
TABLE 3.2.2.3.1
L̲i̲s̲t̲ ̲o̲f̲ ̲A̲v̲a̲i̲l̲a̲b̲l̲e̲ ̲M̲o̲d̲u̲l̲e̲ ̲T̲y̲p̲e̲s̲
M̲T̲ ̲ ̲ ̲ ̲M̲o̲d̲u̲l̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲e̲n̲t̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
AA AREA in CR80-memory
PM PROGRAM
PS PROCESS
ME MONITOR PROCEDURE
CN CRITICAL ̲REGION
DE DEVICE
OE ONE branch/disk
TO TWO branch/disk
DL DUAL disks
AE ACTIVE state of branch
SY STANDBY state of branch
CD CLOSED state of branch
TABLE 3.2.2.3.2
3.2.2.4 D̲e̲t̲a̲i̲l̲e̲d̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲L̲i̲n̲e̲ ̲F̲o̲r̲m̲a̲t̲
L̲O̲A̲D̲-̲c̲o̲m̲m̲a̲n̲d̲s̲
LOAD AREA PA LO FN
LOAD PROGRAM LO FN
LOAD PROCESS NA PA LO PL FN
LOAD MONITOR PROCEDURE LO FN
LOAD CRITICAL ̲REGION NA PA LO FN
NA = Name of module. If '?' is keyed in in the case
of PROCESS, then the name from the process header
in the codefile is used.
PA = Page in memory to load module.
LO = Location in memory to start load.
PL = Prog-location of the loaded process.
FN = Name of file to be loaded.
The LOAD-command may result in the following notice
printed on the console.
*̲ ̲L̲O̲A̲D̲ ̲E̲R̲R̲O̲R̲
Use of a LOAD-file, that does not contain proper data
or load into illegal memory-area, has been attempted
C̲R̲E̲A̲T̲E̲-̲c̲o̲m̲m̲a̲n̲d̲
(of critical region)
CREATE NA PA LO SZ
NA = Name of region
PA = Page where region is created
LO = Start address of region
SZ = Size of region
S̲T̲A̲R̲T̲/̲R̲E̲M̲O̲V̲E̲/̲S̲T̲O̲P̲
START NA
REMOVE NA
STOP NA
NA = Name of process
U̲S̲E̲R̲ ̲O̲N̲/̲U̲S̲E̲R̲ ̲O̲F̲F̲
USER ̲ON N1 N2
USER ̲OFF N1 N2
N1, N2 = Userid.
A̲S̲S̲I̲G̲N̲
ASSIGN MT
MT = ONE/TWO/DUAL. If '*' keyed the system determines
what MT must be.
D̲I̲S̲C̲A̲R̲D̲
DISCARD MT
MT = ONE/TWO
GET ̲ROOT
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
GET ̲ROOT VN
VN = Volume name
DEFINE ̲SYSDIR
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
DEFINE ̲SYSDIR FN
FN = name of new system directory
TAKE ̲COMMAND
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
TAKE ̲COMMAND FN
FN = Name of COMMAND-file
RUN/RUN ̲AND ̲DELAY
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
RUN FN
RUN ̲AND ̲DELAY FN
FN = Name of background process code-file
INITIALIZE ̲DEVICE
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
INITIALIZE ̲DEVICE N1
N1 = LTUX device number, in hex-format
(bit 8 OFF/ON means red/black device)
SETTING OF TIME
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
SET ̲DTG DDHHMMZ MON YY
The exact format of DTG must be used.
P̲R̲O̲C̲E̲S̲S̲ ̲S̲t̲a̲t̲u̲s̲ ̲P̲r̲i̲n̲t̲
PROCESS NA/1/2/3
If keyed in
(nothing) : Status of all processes is printed
NA : Only status of the process with name
NA is printed.
1 : Status of all background processes is
printed.
2 : Status of momentary active background
process is printed.
3 : Status of all READY-processes is printed.
T̲D̲X̲-̲S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲u̲s̲ ̲P̲r̲i̲n̲t̲
TDX ̲SYSTEM F H N1 N2
H = Host number (1/2 for red/black).
Defaulted to 1 at see.
N1, N2 = Numbers.
F = Function - one of folowing
(nothing) : Print statistics.
R : Print statistics and reset.
P : Patch in Host H memory location
N1 (byte offset) word N2.
D : Dump from Host H memory
N2 words starting in location
N1 (byte offset).
Q̲A̲C̲C̲E̲S̲S̲/̲M̲T̲C̲B̲-̲u̲t̲i̲l̲i̲t̲y̲
QM DM N1
Dump MTCB with index N1.
QM DQ N1
Dump all queues (queue-header and queue-elements)
for terminal-queue N1. If the terminal-queue contains
both group-and single-queues, then only the group-queues
are dumped.
QM DQH N1
Same as "QM DQ N1 " but only the queue-heads are
dumped.
QM DQM N1
Same as "QM DQ N1 " but now the MTCB's referred
to in the queue-elements are also dumped.
QM DQ N1 N2
Dump queue N2 of terminal-queue N1 (queue-header
and queue-elements).
QM DQH N1 N2
Same as "QM DQ N1 N2 " but only the queue-head
is dumped.
QM DQM N1 N2
Same as "QM DQ N1 N2 " but now the MTCB's referred
to in the queue-elements are also dumped.
D̲E̲B̲U̲G̲-̲U̲t̲i̲l̲i̲t̲y̲ ̲(̲G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
DEBUG FO + more
FO = Debug directives
F = Function (first byte in FO-string) and
may be of following
P : Patch in memory
D : Dump of memory
S : Search word in memory
A : AMOS-utility
O = Address option (last byte in FO-string)
and may be one of following
A : Absolute address
P : Program relative address
B : Process relative address
C : PCB (Process control block)
At all keying-in at use of DEBUG-utility, hex-numbers
are expected. I.e. the numbers are interpreted as if
they were proceeded by a "#"
D̲E̲B̲U̲G̲ ̲D̲u̲m̲p̲-̲U̲t̲i̲l̲i̲t̲y̲
…06…1 …02… …02… …02… …02… …02…
DG DA PA N1 N2
Dump N2 words from page PA, start location
N1.
(if N2 not specified then N2:=8)
DG DP NA N1 N2
Dump N2 words from the program-area of the
NA-process.
(if N2 not specified then N2:=8)
DG DB NA N1 N2
Dump N2 words from the process-area of the
NA-process.
(if N2 not specified then N2:='rest of process-area')
DG DC NA
Dump the whole PCB (Process Control Block)
of the NA-process.
DG DC NA B
Dump the whole BPCB (Background Process Control
Block) of the NA-background process.
D̲E̲B̲U̲G̲ ̲P̲a̲t̲c̲h̲-̲U̲t̲i̲l̲i̲t̲y̲
DG PA N1 N2 N3 N4 etc.
The words N2,N3,N4,etc. are patched into page PA,
location N1,N1+1,N1+2,etc..
DG PP NA N1 N2 N3 N4 etc.
The words N2,N3,N4,etc. are patched into the program-
area of the NA-process, location N1,N1+1,N1+2,etc.
DG PB NA N1 N2 N3 N4 etc.
The words N2,N3,N4,etc. are patched into the process-
area of the NA-process, location N1,N1+1,N1+2,etc.
D̲E̲B̲U̲G̲ ̲S̲e̲a̲r̲c̲h̲-̲U̲t̲i̲l̲i̲t̲y̲
DG SA PA N1 N2 N3
Search for the word N3 in page PA from location
N1 and N2 words forward.
DG SP NA N1 N2 N3
Search for the word N3 in the program-area of the
NA-process, location N1 and N2 words forward.
DG SB NA N1 N2 N3
Search for the word N3 in the process-area of the
NA-process from location N1 and N2 words forward.
If the search is successful (first hit), then 8 words
starting from the "hit"-location is dumped.
D̲E̲B̲U̲G̲ ̲A̲M̲O̲S̲-̲U̲t̲i̲l̲i̲t̲y̲
DG AS NA
Send an AMOS signal to the NA-process.
DG AM NA N1 N2 N3 N4 N5
Send an AMOS message to the NA-process containing
the words N1, N2, N3, N4, N5. If a word is not
specified (keyed in) then it is set equal to 0.
An AMOS answer upon this message is awaited and
dumped when received.
I̲n̲s̲p̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲i̲l̲e̲s̲
INSPECT V VN
Old inspection file (if any) is closed. If volume is
keyed in, then MD of that volume is opened as new inspection
file.
INSPECT L FN
Lookup of new inspection file in old inspection file
(directory) is done. Old inspection file is closed.
INSPECT P N1 N2 N3 N4 N5 etc.
The content of the words N3,N4,N5,etc. are patched
in file location (N1,N2), (N1,N2)+(0,1), (N1,N2)+(0,2),
etc. (X,Y) = (most,least) significant word in file-word-address.
INSPECT D N1 N2 N3
N3 words is dumped from start-file-location N1, N2.
If N3 is not keyed in, then N3 is defaulted to the
rest of words in the file. If an attempt to dump beyond
EOF is performed then 'length of file' is returned.
INSPECT R
The currently opened inspection file is resat.
F̲l̲o̲p̲p̲y̲ ̲U̲t̲i̲l̲i̲t̲y̲
FLOPPY F + more
F = Function - only the first character is significant.
FLOPPY ASSIGN
The floppy device is assigned.
(not at SCC-installations)
FLOPPY MOUNT
The volume with name FLOPPY is mounted and MD of that
volume is opened.
FLOPPY VOLUME VN
MD of volume (MOVHEAD/FIXHEAD) is opened.
FLOPPY ̲SYSDIR: = MD.
FLOPPY LOOKUP FN
Lookup in FLOPPY ̲SYSDIR of the directory FN is performed.
FLOPPY ̲SYSDIR : = file.
FLOPPY DUMP TO FN
The file FN will be copied from FLOPPY ̲SYSDIR to MD
of volume FLOPPY. FN will be created on FLOPPY.
FLOPPY DUMP FROM FN
The file FN will be copied from MD of volume FLOPPY
to FLOPPY ̲SYSDIR. FN will be created in FLOPPY ̲SYSDIR.
FLOPPY CLOSE
Every open file used at 'FLOPPY-utilities' will be
closed, FLOPPY-volume demounted and floppy device deassigned
(not at SCC-installations).
D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲E̲R̲R̲O̲R̲-̲d̲u̲m̲p̲s̲
DEFINE ̲ERROR ̲DUMP N1 NA OP PA N2 N3
N1 = Errorcode at which dump shall be done.
If equal 0 then at every code.
NA = Name of error-reporting process for which dump
shall be performed. If '*' keyed in then dump
is performed independent of process.
OP = Address option A/B/P for absolute/BASE-rel/PROG-rel.
PA = Page in memory (option A).
N2 = Start address in CR80 memory of dump.
N3 = Size of dump area (in words).
If option B and '*' keyed in then
N3: = process size.
M̲a̲n̲u̲a̲l̲ ̲a̲c̲t̲i̲v̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲E̲R̲R̲O̲R̲ ̲d̲u̲m̲p̲s̲
ERROR ̲DUMP N1
N1 = Error dump ident.
(Ident is found in the ESP-logging).
…06…1 …02… …02… …02… …02… …02… …02…
E̲n̲t̲e̲r̲/̲L̲e̲a̲v̲e̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲M̲o̲d̲e̲
Enter Security Mode (no password update):
= EE
* KEY IN PASSWORD "System remark
= SYS/TEKN (e.g.) "Key in password corresponding
"to
the
type
of
safety
system
"operator.
"Max
8
byte
ASCII-string.
Enter Security Mode with password update:
= EE
* KEY IN PASSWORD "System remark
= SYS NEWSYS (e.g.) "After old password
"key
in
the
new
one
* KEY IN CONTROL "System remark
= NEWSYS "Repeat new password
Leave Security Mode:
= LE "No password key in
Note: All keying in of passwords is not visible. I.e.
the keying in is not echoed on the console.
…06…1 …02… …02… …02… …02… …02… …02…
S̲e̲t̲ ̲S̲C̲C̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲P̲a̲s̲s̲w̲o̲r̲d̲
Only available at SCC's
= SD "Invoke
SD-command
* KEY IN SCC-SUP USERID "System
remark
= SUP (e.g) "Key-in new SCC
"supervisor
userid,
"max
4
ASCII-chars
* KEY IN SCC-SUP PASSWORD "System
remark
= SUPPW (e.g) "Key-in new SCC
"supervisor
password,
"max
8
ASCII-chars
"not
echoed
on
the
OC
* KEY IN CONTROL "System remark
= SUPPW "Repeat new SCC
"supervisor
password,
* KEY IN SCC-SUP SH-PASSWORD "System
remark
= SUPSHPW (e.g) "Key-in new SCC
"supervisor
SH-password,
"max
8
ASCII-chars
"not
echoed
on
the
OC
* KEY IN CONTROL "System remark
= SUPSHPW "Repeat new SCC
"supervisor
SH-password,
* ACCEPT Y/N "System remark
= (Y/N) "Key-in
Yes/No
for
"accept/regret
of
update
Refer also to ref(29), sec. 3.3.3
E̲n̲a̲b̲l̲e̲/̲D̲i̲s̲a̲b̲l̲e̲ ̲B̲o̲o̲t̲ ̲M̲o̲d̲u̲l̲e̲
EB N1
Enable boot module with BFD-number N1
DB N1
Disable boot module with BFD-number N1.
3.2.2.5 A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲q̲u̲e̲s̲t̲
A command can be issued to the ESP-system by sending
an AMOS-message to the CONSOL-process. Completion is
returned in the AMOS-answer send back to the process.
Layout is as follows:
CW Word 0 CW
1
2
3
4 completion
message answer
Command word - two ASCII-characters, first and last
character of standard command.
Other parameters - ASCII-characters as keyed in by
an operator. OBS. no space needed between command word
and the other parameters.
The only commands that is available in this way is
those, that can be brougth to suit this format.
Completion codes:
0: OK completion
1: Syntax error
2: Execution error
3.2.2.6 F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲E̲S̲P̲-̲l̲o̲g̲g̲i̲n̲g̲
When the ESP have executed a FUNCTION as reply on a
command, this is acknowledged by logging it on the
console (if printout is not disabled).
The format of these line is as follows:
A̲f̲t̲e̲r̲ ̲l̲o̲a̲d̲ ̲c̲o̲m̲m̲a̲n̲d̲
LOADED PROGRAM (NA) LOC: 0 (LO) (SZ) VER: (NN)
(FN)
LOADED PROCESS (NA) LOC: (PA) (LO) (SZ) BAS: (NN)
(FN)
LOADED MONPROC (NA) LOC: 0 (LO) (SZ) VER: (NN)
(FN)
LOADED CRITREG (NA) LOC: (PA) (LO) (SZ)
(FN)
where
(NA): name of the loaded module
(PA): page in memory
(LO): start address in memory
(SZ): claim size in memory
(FN): the name of disc file where loaded from
(NN): in case:
load type is program/monitor procedure, then the version
number.
load type is process, then base of the process.
CREATED PROCESS (NA) UID: (N1) (N2) PRG (LO)
where
(NA) : name of process
(N1),(N2) : userid for the process
(LO) : program location for the process
A̲f̲t̲e̲r̲ ̲c̲r̲e̲a̲t̲e̲ ̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲ ̲c̲o̲m̲m̲a̲n̲d̲
CREATED CRITREG (NA) LOC: (PA) (LO) (SZ)
where
(NA) : name of critical region
(PA) : page in memory
(LO) : start address in memory
(SZ) : size of critical region
A̲f̲t̲e̲r̲ ̲S̲T̲A̲R̲T̲/̲R̲E̲M̲O̲V̲E̲/̲S̲T̲O̲P̲-̲c̲o̲m̲m̲a̲n̲d̲
STARTED PROCESS (NA)
REMOVED PROCESS (NA)
STOPPED PROCESS (NA)
where
(NA) : name of process.
A̲f̲t̲e̲r̲ ̲U̲S̲E̲R̲O̲N̲/̲U̲S̲E̲R̲O̲F̲F̲-̲c̲o̲m̲m̲a̲n̲d̲
USERON UID: (N1) (N2)
USEROFF UID: (N1) (N2)
where
(N1), (N2): userid known of FMS
A̲f̲t̲e̲r̲ ̲A̲S̲S̲I̲G̲N̲/̲D̲E̲A̲S̲S̲I̲G̲N̲-̲c̲o̲m̲m̲a̲n̲d̲
ASSIGN (MT) (DN) ; assignment of device
DEASSIGN (DN) ; deassignment of device
where
(MT) : device type - ONE/TWO/DUAL
(DN) : device name
A̲f̲t̲e̲r̲ ̲M̲O̲U̲N̲T̲/̲D̲E̲M̲O̲U̲N̲T̲-̲c̲o̲m̲m̲a̲n̲d̲
MOUNTED VOLUME (DN) (VN)
DEMOUNT VOLUME (VN) ; dismount of volume
(DN) : device name
(VN) : volume name
A̲f̲t̲e̲r̲ ̲U̲P̲D̲A̲T̲E̲-̲c̲o̲m̲m̲a̲n̲d̲
UPDATED VOLUME (VN)
where
(VN) : volume name
A̲f̲t̲e̲r̲ ̲G̲E̲T̲R̲O̲O̲T̲-̲c̲o̲m̲m̲a̲n̲d̲
GETROOT VOLUME (VN)
where
(VN) : volume name of the volume in which main
directory now is system directory
After DEFINE ̲SYSDIR-command
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
DEF ̲DIR VOLUME (VN) (SD)
where
(SD) : name of new system directory
After TAKE ̲COMMAND-command
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
COMMAND (FN)
where
(FN) : name of file in system directory to be
used as input file.
A̲f̲t̲e̲r̲ ̲D̲i̲s̲k̲ ̲W̲r̲i̲t̲e̲ ̲E̲n̲a̲b̲l̲e̲d̲ ̲i̲s̲ ̲p̲e̲r̲f̲o̲r̲m̲e̲d̲
WRTDISK
A̲f̲t̲e̲r̲ ̲D̲I̲S̲C̲A̲R̲D̲-̲c̲o̲m̲m̲a̲n̲d̲
DISCARD (MT) (DN)
where
(MT) : device type-ONE/TWO
(DN) : device name
A̲f̲t̲e̲r̲ ̲S̲B̲O̲N̲/̲S̲B̲O̲F̲F̲-̲c̲o̲m̲m̲a̲n̲d̲
SBON
SBOFF
A̲f̲t̲e̲r̲ ̲S̲T̲A̲R̲T̲-̲/̲F̲I̲N̲I̲S̲H̲-̲d̲u̲a̲l̲i̲z̲e̲ ̲c̲o̲m̲m̲a̲n̲d̲
STDUAL (MT) (DN)
FIDUAL (DN)
where
(MT) : device type-ONE/TWO
(DN) : device name
3.2.2.7 U̲S̲E̲R̲-̲F̲I̲L̲E̲-̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
By sending an AMOS system message to the process 'USRFIL'
in the USER-processor, it is possible to communicate
with processes in the FILE-processor. Answers are returned
in the AMOS-system answer.
Layout of the system message is as follows:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Word 0
Word 1
Word 2 Name of process in the
Word 3 FILE-processor for which
̲W̲o̲r̲d̲ ̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ the message is dispatched.
If the reciever-processname is 'FILUSR', the FILUSR
will execute tasks and return answers as specified
in the following.
Message Executed task Answer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
0 The name of the process 0
PCBID with PCB-index PCBID is PCBID
F I returned S N
L U A M
̲S̲ ̲ ̲R̲ ̲ ̲E̲ ̲ ̲ ̲
̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
1 The state, error code, 1
PCBID error location of the PCBID
F I process with PCB-index
L U PCBID is returned SERROR
̲S̲ ̲ ̲R̲ ̲ ̲-̲"̲-̲ ̲
̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
2 The accumulated execution 2
PCBID time for the process with PCBID
F I PCB-index PCBID is returned SEXECT
L U -"-
̲S̲ ̲ ̲ ̲R̲ ̲ ̲ ̲-̲"̲-̲
̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
-2 The 'hardware' DISK STATUS DISK ̲STATUS
is returned - 0/1/2 for
F I no/DISK ONE/DISK TWO F I
L U available L U
̲S̲ ̲ ̲ ̲R̲ ̲ ̲S̲ ̲ ̲ ̲R̲
̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
-1 The FILE-processor is master- -1
cleared (after returning of
F I answer) F I
L U L U
̲S̲ ̲ ̲ ̲R̲ ̲ ̲S̲ ̲ ̲ ̲R̲
̲
If an AMOS-signal is sent to "USRFIL", this one will
send a masterclear-message to "FILUSR". USRFIL will
then masterclear the userprocessor. (Intended to be
used as "REMOTE MASTERCLEAR" in TOS-environment).
3.2.2.8 F̲I̲K̲S̲ ̲C̲D̲C̲-̲d̲r̲i̲v̲e̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The CDC-drivers used in the FIKS system has been modified
to allow retrieval of status concerning the performance
of the disks. The status is retrieved by sending a
system message to the driver-process (CDC000/CDC001).
The status is contained in the answer.
The format of the message is as follows:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Bit
no
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Word
0
S̲ ̲ ̲U̲ ̲ ̲ ̲C̲M̲D̲ ̲ ̲ ̲ ̲ ̲
1
2
3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4
S: Subunit (Volume) , 0/1 for MOVHEAD/FIXHEAD
U: Unit (0..3) , = 0 in FIKS-system
CMD: Retrieve command.
Depending upon CMD the answer will contain the following:
C̲M̲D̲:̲ ̲ ̲#̲A̲ ̲,̲ ̲S̲t̲a̲t̲u̲s̲ ̲1̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Word 0
(1) Number of read faults
1
(1) Number of write faults
2
(2) Number of millisecs
3
̲s̲u̲b̲u̲n̲i̲t̲ ̲h̲a̲s̲ ̲b̲e̲e̲n̲ ̲b̲u̲s̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ 4
(1) Since last retrieve Status 1
(2) Since last retrieve Status 2
C̲M̲D̲:̲ ̲ ̲#̲B̲ ̲,̲ ̲S̲t̲a̲t̲u̲s̲ ̲2̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Word 0
DIF Status 1
DIF 2
Instruction 3
̲B̲l̲o̲c̲k̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ 4
Concerning 'DIF'-refer to ref (8)
After returning of this status
'Number of millisecs subunit has been busy'
is reset.
C̲M̲D̲:̲ ̲ ̲#̲C̲ ̲,̲ ̲S̲t̲a̲t̲u̲s̲ ̲3̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Word 0
(1) Number of read-operations
1
(1) Number of write-operations 2
(2) Number of millisecs 3
̲s̲u̲b̲u̲n̲i̲t̲ ̲h̲a̲s̲ ̲b̲e̲e̲n̲ ̲b̲u̲s̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ 4
(1) Since last retrieve Status 3
(2) Since last retrieve Status 2
The CDC-drivers are 'WRITEENABLED' by sending
the following system message to the driver
processes.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Word 0
̲ ̲#̲ ̲F̲ ̲ ̲ ̲ 1
2
3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ 4
(Only at Node/MEDE-installations).
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲ ̲
3.3.1 E̲S̲P̲ ̲M̲a̲i̲n̲ ̲F̲l̲o̲w̲
The main processing of the ESP-system is described
in overview in figure 3.3.1.
The ESP passes through an initializing phase. After
this, events to initiate some kind of processing are
awaited. The events can be:
- Watchdog commands (incl. alive inquiries)
- Operator commands (incl. 'COMMAND ̲FILES', 'SEQUENCES',
and 'Application Process Command')
- Error reports from applications processes
- Wild events
- Background management scheduling requests
When these events are received, then they are analysed/interpreted
to determine the action to be taken. The action is
separated into indivisible parts (FUNCTIONS), executed
one by one. When a FUNCTION is finished, this is logged.
When all FUNCTIONS forming the action are finished,
a new event is avaited.
Figure 3.3.1
Overview ESP Main Flow
3.3.2 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
In the FIKS system, there is no need for dynamic allocation/delocation
of memory. When the FIKS system is loaded, the different
memory areas will be settled for ever. Therefore, the
only memory management is concerned with allocation
of memory in the initializing phase of the system (i.e.
when memory areas are loaded or created). This is done
by reserving areas from top of the pages (lowest addresses)
and the following simple scheme is used:
- At 'boot load' time, the first free location for
each page is settled
- When memory for a specific page is to be allocated,
first free location is specified at start location
- When the memory has been allocated, first free
location is updated
- It is possible to suppress the updating of first
free location (used when not allocating contiguous)
- Every memory allocation is carefully logged
- The task of controlling that memory management
is done properly is left to the system maintainer
First free location for each of the four possible memory
pages is maintained by the ESP (TOP ̲OF ̲PAGES).
Other processes are in certain cases also able to allocate
memory - background processes started by the option
'RUN ̲DELAY', ref. sec. 3.3.9. In this case
TOP ̲OF ̲PAGES is transferred from ESP-data-area to
TOP ̲OF ̲MEMORY in the critical region CONFIG before
the background process is started. When the process
is started, it can fetch TOP ̲OF ̲MEMORY, allocate memory,
update TOP ̲OF ̲MEMORY, and finish processing. ESP then
transfers TOP ̲OF ̲MEMORY to TOP ̲OF ̲PAGES and continues
allocating memory on the basis of the updated
TOP ̲OF ̲PAGES.
3.3.3 E̲S̲P̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When the ESP is started by KERNEL (ref. sec. 3.3.20.1),
it executes certain tasks. This has only to be performed
once.
1 SCM interface is set to use two stop bits. This
is a demand when using the Watchdog.
2 Constants that are to be used lateron are settled.
OVERLAY ̲START ref. sec. 3.3.24
LOCAL ̲ACTION ̲POINTER ref. sec. 3.3.25
3 DUMMY ̲SCM-device interrupt is reserved, ref. 3.3.6.
4 BASE ̲COPY and SMSGLIM concerning the ESP itself
are updated, ref. (1). This is because the ESP
is not loaded and created as "standard processes"
(ESP is ROOT-process).
5 Logging of ESP program and process load are performed
and the initial values of TOP ̲OF ̲PAGES are determined
(on the basis of ESP-program and process-area parameters)
6 The process CONSOL (ref. sec. 3.3.6) is created
and started. Logging is performed as for ordinary
processes.
After this ESP, continue with the FIKS-system initialization,
ref. sec. 3.3.20.
3.3.4 D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
3.3.4.1 D̲i̲s̲k̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲u̲m̲m̲a̲r̲y̲
An overview of the FIKS-disk hardware configuration
is given in figure 3.3.4.1.
The disks (CDC and FLOPPY) are controlled of the interface
boards placed in the file processor. These disk controllers
are accessed from the file processor via the SCM-main
bus using the IO-addresses 200, 204 for CDC and 8 for
FLOPPY. In this way, they are requested to perform
data transfers to/from the disks from/to the disk-CACHE,
which is CR80-memory RAM placed on page 1, locations
0-#4000 in the file processor. Transference of data
between the file and user processor is made via the
DMA-link.
The CDC-disks (kind = MMD82, unit No. = 0) consists
of two subunits:
- the section accessed with movable heads (subunit
No. = 0), where the volume MOVHEAD is placed.
- the section accessed with fixed heads (subunit
No. = 1), where the volume FIXHEAD is placed.
The FLOPPY disk (kind = FLOPPY, unit No. = O) is only
placed in BRANCH ONE (i.e. it cannot be used of BRANCH
TWO). There is one subunit (subunit No. = 0), where
a volume named FLOPPY is (normally) placed.
Figure 3.3.4.1…01…FIKS Disk Configuration
3.3.4.2 D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲u̲m̲m̲a̲r̲y̲
An overview of the system software involved in the
FIKS disk processing is given in figure 3.3.4.2.
When an application in the CR80 computer requests a
disk read/write operation, this command is sent via
the IO system in the user processor and DMA-driver
(DMA000) to the File Management System (FMS) placed
in the file processor. The FMS translates the commands
to disk sector read/write commands. These are handed
over to the disk drivers (CDC000, CDC001 for CDC-disks
and FD00 for the Floppy), which carry out the interface
to the disk controllers. Needed data transfers between
file processor and user processor are controlled by
the FMS and executed by the DMA-driver. When the disk
operation is finished, the disk driver is interrrupted.
It returns completion to the FMS, which forwards this
information via the DMA-driver and IO-system to the
application.
Figure 3.3.4.2…01…FIKS Disk Operation
3.3.4.3 F̲I̲K̲S̲ ̲D̲u̲a̲l̲ ̲D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲
Seen from the system operational software point of
view, the FIKS dual disk system (ref. figure 3.3.4.1,
NODE/MEDE) consists of two logical DEVICES, MMD0 and
FIX0 with volumes MOVHEAD and FIXHEAD. The devices
may consist of subunits from one or both of the disk
units. If both subunits are used, DISK ̲STATUS is said
to be DUAL. If only subunits from BRANCH ONE/TWO are
used, DISK ̲STATUS is said to be ONE/TWO.
If DISK ̲STATUS is DUAL, disk read operations will be
performed from one of the disk units and disk write
operations on both units. In case of a hardware failure
in one of the disk units, this one is DISCARDED and
the one unit left is used as single (ONE/TWO). Lateron
when the erroneous disk is repaired, it can be included
in the disk system again - a DUALIZING of disk is started.
All write operations are now performed on both units,
while a copying of disk sectors from the disk used
all the time to the disk to be included. When this
copying is finished, the units are identical and DISK
̲STATUS is DUAL.
Both BRANCHes can use the disks at the same time. If
both branches were allowed to do writing on the disk
units simultaneously, the disks would soon be corrupted.
Therefore, a feature for controlling the ability to
write on the disks is present. When the FIKS-system
is booted, no disk operating can be made - every disk
write operation is converted to a dummy 'CHECK'-operation.
All disk-read-operations are executed in the usual
manner. This state of disk system is meant to be used
when a branch is STANDBY. When the branch is going
to be ACTIVE, then disk-writing is enabled (WRTDISK).
To keep track of the different states of the disk-system,
a DISK ̲STATUS-word is used:
1̲5̲ ̲1̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲4̲ ̲3̲ ̲2̲ ̲1̲ ̲0̲ ̲ - bit
no
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
B̲i̲t̲ ̲o̲n̲ ̲m̲e̲a̲n̲s̲
0: DISK ̲ONE ̲INCLUDED
1: DISK ̲TWO ̲INCLUDED
2: DISK ̲WRITE ̲ENABLED
3: DISKS ̲DUALIZING
The word is checkpointed (i.e. written to disk) each
time it is changed. It is retrieved at next initializing
of the disk system for determination of DISK ̲STATUS.
It is noticed that in BRANCH ONE, DISK ONE/TWO corresponds
to the IO-addresses 200/204, and in BRANCH TWO, DISK
ONE/TWO corresponds to the IO-addresses 204/200.
3.3.4.4 I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲ ̲o̲f̲ ̲F̲I̲K̲S̲ ̲D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲
When the FIKS is bootloaded BRANCH ̲ID, DISK ̲STATUS
is defaulted to BRANCH ̲ONE, DISKS ̲DUAL. The state of
the disk controllers is examined. If the cables to
the controller or the disk interface board itself is
missing, no attempt to use the corresponding disk unit
is performed, and the DISK ̲STATUS is set in accordance
with this. This 'hardware' DISK ̲STATUS is obtained
by using the interface described in sec. 3.2.2.4. The
DISK STATUS is used when doing the initial assignment
of devices and mounting of volumes for getting access
to the ESP-overlays.
When BRANCH ̲ID is keyed in by the operator (ref. sec.
3.3.20.1), DISK ̲STATUS is updated (if BRANCH ̲TWO is
stated).
The next step of the procedure is to examine the DISK
̲STATUSs previously checkpointed (on each disk unit).
This is done to ensure that a disk unit not included
in the system last time it was active will not be included
now. To get the DISK ̲STATUS, it is necessary to assign
each disk unit as single (DISK ̲ONE, DISK ̲TWO), mount
the volumes and read the checkpoints. By combining
the DISK ̲STATUS ̲WORDs (the one from the disk-controllers
and the two checkpointed), the largest common DISK
̲STATUS is determined. If DISK ̲STATUS comes out with
"no disk available", the system operator is asked to
key in a DISK ̲STATUS with the following printout on
the console:
* DISK STATUS ?
= (key in ONE/TWO/DUAL)
The final obtained DISK ̲STATUS is then used at final
assignment of disks. If the system is going to be ACTIVE
then the disk units are WRITE ̲ENABLED just before the
last assignment. (ref. sec. 3.2.2.8).
3.3.4.5 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲D̲I̲S̲C̲A̲R̲D̲-̲D̲i̲s̲k̲-̲E̲r̲r̲o̲r̲s̲
In case of a hardware failure in one of the two disks
in a dual disk system, an error code is returned from
the FMS-system (ref. (7)) telling which disk is erroneous.
This disk has then to be discarded. This is done by
the ESP. The application process that started the operation
causing the error, does not need to care for the DISCARD-error.
The errors are entirely handled on system level (by
the ESP). This is implemented as follows:
The standard IO-system has been modified for use in
the FIKS-system in such a way that - in case of error
exit - it is tested if the error code indicates a discard-
error. If this is true, then MON(ERROR) is called and,
thereby, ESP is notified. ESP analyses the error report
received and if the code is
#451 - #45D in BRANCH ONE or
#461 - #46D in BRANCH TWO
then DISK ONE is discarded, or if the code is
#461 - #46D in BRANCH ONE or
#451 - #45D in BRANCH TWO
then DISK TWO is discarded.
After the DISCARDing, ESP restarts the application
process with OK-exit from the IO-system (see also figure
3.3.4.5).
Application ESP-Process
Process ^
Processing
^
Call MON(IO)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
IO-System
^
Doing Disk
Access
^
Receiving
Discard-Error
^ ^
Call MON(ERROR) …0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f… Receiving
^ Error-Report
STOPPED ^
^ Analyse Error
^ ^
^ Discard Disk
^ ^
STARTED …0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f… Start Process
^
Exit OK
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^
No Error Sensed
Figure 3.3.4.5.
HANDLING OF DISCARD-DISK-ERROR
3.3.4.6 D̲u̲a̲l̲i̲z̲i̲n̲g̲ ̲o̲f̲ ̲D̲i̲s̲k̲s̲
If a disk unit has been discarded or has not been available
when the disk system was initialized, then it is possible
to include this one in an operating disk system and,
thereby, form a complete dual disk system. This is
performed by executing a DUALIZE ̲DISK-procedure.
1 The FMS is told to do future disk writing on both
disk units. This is done by the ESP-command
START ̲DUALIZE.
2 Every sector on the disk unit, all the time included,
is copied to the unit to be included. This is done
using the MON(IO, DUALIZE ̲SECTOR)- procedure.
3 The FMS is told that the dual disk sysem is complete.
This is done by the ESP-command
FINISH ̲DUALIZE. The DISK ̲STATUS is updated and
checkpointed.
To get a simple interface to the system operator, the
procedure is implemented as follows:
The operator starts a background process
(RUN DUALIZE ̲DISKS.C). This process starts with issuing
of a START ̲DUALIZE-command using 'Application Command
Request' (ref. sec. 3.2.2.5). Then it does dualizing
of all sectors in the disk system and finishes with
the FINISH ̲DUALIZE-command, also as 'Application Command
Request'.
3.3.4.7 D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲e̲ ̲T̲r̲a̲n̲s̲i̲t̲i̲o̲n̲ ̲D̲i̲a̲g̲r̲a̲m̲
In the following is given an overview of the possible
states of the FIKS Dual Disk System and the events
that causes the transitions (ref. figure 3.3.4.4.).
1 Assign DUAL
2 Assign DISK ONE
3 Assign DISK TWO
4, 10 Error on DISK TWO
5, 11 Error on DISK ONE
6, 7 START DUALIZE-command
8, 9 FINISH DUALIZE-command
12, 14 Error on DISK ONE
13, 15 Error on DISK TWO
16, 17, 18, 19, 20 Deassign
Figure 3.3.4.7…01…State Transition Diagram…01…FIKS Dual Disk System
3.3.4.8 S̲t̲a̲n̲d̲b̲y̲ ̲F̲I̲L̲E̲-̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲W̲a̲t̲c̲h̲d̲o̲g̲
The STANDBY-branch will not normally use the disk system.
In case of failure in the disk system, it will neither
discover this and, therefore, not notice the Watchdog
that 'STANDBY BRANCH IS OFF'. A process 'STFPWD' to
take care of this situation is running in the STANDBY-branch.
Its only taks is to sense 'disk system breakdown' -
this is done by doing 'UPDATE OF VOLUMES' with regular
time intervals.
3.3.4.9 O̲f̲f̲l̲i̲n̲e̲ ̲D̲i̲s̲k̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Sometimes it is necessary to operate on the disk system
in an offline mode, i.e. under TOS-execute system.
TOS-system is only operating on one disk unit at a
time (DISK ONE or DISK TWO). Therefore, special precautions
must be taken when using TOS in a dualized NODE/MEDE
disk system. The checkpointed DISK ̲STATUS must be updated
to reflect the changes made on the disk system. Three
programs DISK ̲ONE.C, DISK ̲TWO.C, and DISKS ̲DUAL.C have
been implemented. These programs overwrite the checkpointed
DISK ̲STATUS to be DISK ̲ONE, DISK ̲TWO, or DISKS ̲DUAL.
They are activated using 'S' - RUN 'Program'. The program
must be included in the TOS- configuration command-files
(CONFIG-files).
3.3.4.10 D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
To suit the disk system software for use in the FIKS-system,
the following modifications have been implemented:
I̲O̲-̲S̲y̲s̲t̲e̲m̲
- A general timeout test of 10 seconds has been introduced.
I.e. if a process waits on completion of an IO-operation
'inside the IO-system', then, if it is not finished
within 10 sec., MON(ERROR) is called with errorcode/error
label equal #4FF/program location. In case of restart
the process will continue the waiting. N̲o̲t̲e̲: The
timeout test is not effective when MON(IO,INIT-)
- procedures are used.
- Test of 'DISCARD-disk'-errors has been added. At
error-EXIT from the IO-system it is tested if the
error code is in the ranges:
#451 - #450 or #461 - #46D.
If true, MON(ERROR) is called.
After restart EXIT from the IO-system will be made
from OK-completion.
The procedures
MON(IO,STARTDUALIZE)
MON(IO, FINISHDUALIZE)
MON(IO, DUALIZESECTORS)
have been added to the IO-system.
C̲D̲C̲-̲D̲r̲i̲v̲e̲r̲
- Collection of PERFORMANCE-data is implemented,
ref. sec. 3.2.2.8.
- DISK ̲WRITE ̲ENABLE-option is added. When the CDC-driver
is loaded, every controller command involving updating
on the disk is exchanged by dummy CHECK-commands.
I.e. it is possible to read from the disk but not
to write on it. When the driver receives a 'WRITEENABLE'-command
(ref. sec. 3.2.2.8), the standard set of controller
commands is loaded and the driver runs like the
standard CDC-drivers.
- Timeout test on CDC-device is implemented. Before
executing of each command it is tested that
- disk interface board is present
- the cable is connected to the interface board
If not true, the result of the driver operation
is set to error and status to #7FFF. This will
result in #441,#451,#461-completion code from the
FMS. In case of #451, or #461 it will then be possible
to discard the affected disk unit and, thereby,
recover from the erroneous situation and continue
operations.
F̲M̲S̲-̲S̲y̲s̲t̲e̲m̲
The concept DISK ̲NUMBER used in the IO-system and FMS-system
(ref. (2) and ref. (7)) is updated in this way:
DISK NUMBER 0/1 is equal to the disk unit connected
to the IO-addresses 200/204, see figure 3.3.4.1.
S̲i̲m̲u̲l̲a̲t̲e̲d̲ ̲F̲I̲X̲H̲E̲A̲D̲
At certain occasions it is convenient to be able to
run the FIKS-system without the FIXHEAD-volume such
as:
- At "everyday" testing of FIKS-software. For this
kind of testing only a hardware configuration without
"fixed head" disk units (SMD-drive) is available.
- When the fixed head part of a disk unit (the FIXHEAD-volume)
in a FIKS operational computer installation is
crashed it is impossible to run the FIKS-system.
An extra opportunity for operating the system with
only the movable part (the MOVHEAD-volume) could
be desired.
Caused by the above, the "SIMULATED FIXHEAD" has been
introduced. The following modifications have been performed
in this connection:
- A special version of the FMS-system is implemented.
Each time the FIXHEAD-volume name is used (GETROOT,
UPDATE), the name is exchanged with the MOVHEAD-volume
name. It will then from an application process
point of view look as if FIXHEAD was used (when
actually it is MOVHEAD).
- A special version of the ESP has been implemented.
Whenever the "fixed head"-device/volume is used
in the ordinary processing (ASSIGN, DEASSIGN, MOUNT,
DISMOUNT, START/FINISH, DUALIZE, DISCARD) this
is skipped in order to avoid any reference to the
fixed head part of the disk units.
By using these special versions of FMS and ESP and
to have a complete copy of the FIXHEAD file structure
within the MOVHEAD, it is possible to run an operational
FIKS-system without FIXHEAD. (The system performance
will be lowered).
3.3.5 T̲D̲X̲ ̲S̲y̲s̲t̲e̲m̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Refer to figure 3.3.5
3.3.5.1 T̲D̲X̲ ̲S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲
The ESP is performing the assignment of the TDX-Hosts
to the IO-system and the initializing of all LTUX-devices
connected to the red TDX-system, except for those used
by the network. This processing is executed in the
"System Initializing"-phase in one indivisible sequence,
ref. 3.3.20.
Before any assignment is done, the host is resat (mastercleared).
To do the initializing, the "LCFRJ01"- file is used
together with the LCFH-monitor, ref. (16). After initialzing
of each terminal, the corresponding device No. is stored
in a local ESP-table (LTUX ̲DEVICES) to be used later
on when reinitializing LTUX-devices.
Figure 3.3.5…01…ESP TDX System Management
3.3.5.2 R̲e̲i̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲ ̲o̲f̲ ̲L̲T̲U̲X̲-̲D̲e̲v̲i̲c̲e̲s̲
If an LTUX-device/terminal needs to be reinitialized,
this can be done by giving a command to the ESP (INITIALIZE
device No.). The execution of the command is performed
by using the same procedure as when doing the first
initialization, but this time only calling MON(LCFH)
when a terminal is connected to the affected device.
This is managed by comparing the device No. to those
placed in the LTUX ̲DEVICES-table. N̲o̲t̲e̲: Every terminal
connected to the device will be initialized.
3.3.5.3 T̲D̲X̲-̲S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
To suit the TDX-system sowftware for use in the FIKS-
system, a modification of the standard I/O-system has
been implemented. A general IO-completion timeout test
of 5 minutes has been introduced. If a process waits
for completion of a TDX-IO-operation 'inside the IO-system'
and it is not finished within 5 minutes, MON(ERROR)
is called with error code/label equal #6FF/ program
location. In case of restart, the process will continue
the waiting. The test is not active when MON(IO, INIT-)-procedures
are used.
3.3.6 C̲o̲n̲s̲o̲l̲e̲ ̲I̲n̲p̲u̲t̲/̲O̲u̲t̲p̲u̲t̲
Every system command (from an operator or the Watchdog)
and all logging (output on console) goes via the SCM-V24-interface.
The ESP-system makes out the driver-functions needed
to handle this. The implementation is done as follows
(see figure 3.3.6):
I̲n̲p̲u̲t̲
A process CONSOL, which is placed inside the ESP-process,
deals with the input function. An interrupt indicating
a byte is received in the SCM is awaited by the CONSOL.
If the character is a SOH-character (hexvalue #01),
start of a Watchdog command is assumed. The next character
will then state the command, the rest of the command
until CR can be ignored, ref (14) p. 10-13. The command
is then passed to the ESP-process via an AMOS-message.
If the character is not a SOH-character, it is assumed
to be keyed in by the operator and it is stored in
the cyclic buffer SCM ̲BUFFER. Depending on the character,
the ESP ̲STATUS is updated as follows:
'!': INTERRUPT ̲ESP
'$': CANCEL ̲RESTART (after local fixup)
' ': ENABLE ̲HARD ̲COPY ̲PRINT
' ': DISABLE ̲HARD ̲COPY ̲PRINT
The CONSOL-process activates then the ESP-process via
a programmed interrupt (DUMMY ̲SCM ̲DEVICE address =
#25). ESP fetches the character from the SCM ̲BUFFER.
Depending on the character, the following actions are
taken:
NL (#0A): the character is ignored
'%'(#25): the last keyed in characters are used (until
EOT)
CR (#0D): input line is finished. A EOT-character
(#03) is placed in INPUT ̲LINE.
else the character is placed in the buffer INPUT ̲LINE
and echoed on the console (printed) and a new character
is awaited.
The reason, why the input procedure is implemented
in this way, is mainly because the ESP-system shall
always be ready to receive input from the Watchdog
(with a rate of 1 character per 30 msec) or a character
may be lost. The Watchdog has no flow control.
O̲u̲t̲p̲u̲t̲
Outputting to console is exclusively controlled by
the ESP-process (no critical timing) and can, therefore,
be implemented in a much easier way - outputting characters
directly to the SCM via Mainbus-IO.
Figure 3.3.6…01…Console Input/Output-Scheme
3.3.7 W̲a̲t̲c̲h̲d̲o̲g̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The communication between the Watchdog and the CR80-computer
is managed by the ESP-system. This is done just as
when an operator is keying commands in (ref. sec. 3.3.6).
I.e. in principle the ESP can not distinguish if input
comes from an operator or the Watchdog - it is assumed
that the input comes from the Watchdog if the line
starts with a SOH-character. The operator can key in
Watchdog commands and thereby simulate the Watchdog.
The output from the ESP to the Watchdog is done without
considering the receiver is the Watchdog or an operator.
The formats of the Watchdog commands and answers are
stated in ref.(14), p.10-13. To adapt the SCM-interface
for communication with the Watchdog use of 2 stop bits
shall be sat in the SCM.
3.3.8 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲ ̲
When INPUT ̲LINE has been filled with a command line,
this has to be interpreted. To be accepted as a command,
it shall obey the definition given in sec. 3.2.2 -
"System Command Format". A line contains one or more
items, each separated by at least one space character
(=delimeter). One item consists of visible ASCII-characters
that can be recognized by an operator. Three kinds
of items are used:
K̲E̲Y̲W̲O̲R̲D̲S̲:̲
I.e. command words and module types. They are translated
to an internal binary code used by the ESP. Only first
and last character are significant. In this way it
is possible to state the command lines in a narrative
way. In most cases the keywords will be interpreted
correct if they are spelled in full length. This makes
it much easier to remember them. The interpretion is
done like this:
First and last byte is put together to form a word
and this word is compared with a table. If a table
entry is equal to the word, then the binary code will
be equal to the entry in a corresponding KEY ̲WORD ̲TABLE,
ref.figure 3.3.8.
N̲U̲M̲E̲R̲I̲C̲S̲
Whenever a numeric is an item in a command line, this
may exist in both decimal and hexadecimal format -
if hexadecimal then the first character must be '#'.
When decimal format (no preceeding #) is used then,
if more characters than five stated, only the five
most right are used. If the "value" is greater than
65535 (#FFFF) then "value" - #FFFF is used (wrap around).
If hexadecimal format is used then, when more characters
than five stated, only the four most right figures
are used, ref. fig. 3.3.8.
N̲A̲M̲E̲S̲:̲
An item in the command line stated as a name (fixed
length (L) of characters) is interpreted as follows.
If the number of characters is less than L, then space
characters are used to fill up with until length is
L. If more than L characters, then the L-1 most left
+ the most right one is used (ref. fig. 3.3.8).
A command line is always started with a command word.
The interpretation of the following items will depend
on the preceeding item(s). If an error in the interpretation
procedure is discovered, then the operator is notified
by the printout
* SYNTAX ERROR
No attempt to differentiate the error cases has been
done. It is left to the operator by himself to find
out what is wrong. At these errors all further interpretation
of the line is finished, executing of commands is interrupted,
and return to ESP-waiting point is done (i.e. SEQUENCES
- ref.sec. 3.3.12 and COMMAND ̲FILES - ref. sec. 3.3.11
is interrupted).
C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲
K̲E̲Y̲W̲O̲R̲D̲S̲
eg.
START PNAME INPUT ̲LINE
ST COMMAND ̲WORD
Compare
LD CE ST RE KEY ̲WORDS COMMAND-WORD
̲TABLE
0 1 2 3 KEY ̲WORD ̲CODES
Entry no
Binary code for 'START' = 2
N̲U̲M̲E̲R̲I̲C̲S̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲d̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
INPUT hexadecimal decimal
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
123 #0076 00123
#123 #0123 00291
00123 #0076 00123
#0123 #0123 00291
12345 #3039 12345
69905 #1111 04369
123456 #5BAD 23456
#12345 #2345 09029
Figure 3.3.8
Command Interpretation
N̲A̲M̲E̲S̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲d̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
INPUT L = 6 L = 16
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
ABC ABC ABC
ABCDEF ABCDEF ABCDEF
ABCDEFGH ABCDEH ABCDEFGH
ABCDEFGHIJKLMNOPQ ABCDEQ ABCDEFGHIJKLMNOQ
Figure 3.3.8 (cont'd)
Command Interpretation
3.3.9 C̲o̲m̲m̲a̲n̲d̲ ̲P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
When a command line has been interpreted correct and
the needed input parameters is settled, execution of
the command is started. The execution can be divided
into one or more steps - FUNCTIONS. After successful
completion of a FUNCTION, this is acknowlegded by logging
it - ref. sec. 3.2.2.6. If an error occurs while execution
of the command takes place, this is reported as a ESP-error
- ref. sec. 3.3.17.
In the following is a list of all commands and an explanation
of how the corresponding FUNCTION's are performed.
See also sec. 3.2.2.4 for explanation of the input
parameters.
L̲O̲A̲D̲ ̲(̲L̲D̲)̲ (ref.fig. 3.3.9.1)
This command is used when some kind of module is loaded
from a disk-file into the CR80-memory. The name of
the file has always to be specified. The file must
be placed in the system directory (FIX ̲CONFIG.D). The
modules can be of type:
- AREA (AA). Some kind of data structure has to be
loaded (raw data). PAGE in memory and start-LOCATION
in that page, where the loading shall start has
to be specificed. The amount of data to be loaded
is equal to the size of the load file.
- PROGRAM (PM). A program has to be loaded. PAGE
in memory is defaulted to 0. Start-LOCATION must
be specified. The layout of the program is expected
to fulfil the standard AMOS-format, ref(1), appendix
B. The loaded data is the program part of the code
file except for the programheader.
PROGRAM ̲LOCATION is stored for use as default value
for 'PROG' when loading processes.
- PROCESS (PS). A process has to be loaded and created.
Name of becoming process has to be stated. PAGE
where to be loaded, "desired" start-LOCATION and
PROGRAM ̲LOCATION has to be specified. The process,
which is expected to fulfil the standard AMOS-format
given in ref(1), appendix B, is fetched from the
process part of a codefile. The "desired" start-LOCATION
is modified so that the BASE of the process fulfils
the rule stated at ref(1), p.87 (page - and priority
bits must be sat correctly). The lowest higher
possible start-LOCATION is chosen. The loaded data
is the whole process part. Allocation of memory
is taken from start-LOCATION until start-LOCATION
+ memory claim (found in process header). Then
the process is CREATED, ref (1) p.84-89. PROGRAM
̲START is always fetched from the PROGRAM ̲HEADER
in the codefile.
- MONITORPROCEDURE(ME). A monitor procedure has to
be loaded and initialized. The loading is performed
in the same manner as for a PROGRAM, i.e. no header
is included in the load. After that the ESP executes
the initializing as described in ref(1), sec. 3.13.1.
- CRITICAL ̲REGION(CN). Initializing data for a critical
region has to be loaded and the critical region
itself has to be CREATED. The loading is performed
just as when loading AREA's. The creating is done
with parameters corresponding to those used at
the load-operation. ref(1), sec. 3.5.1 + 4.4.1.
Figure 3.3.9.1…01…Load of Modules…01…ESP System
C̲R̲E̲A̲T̲E̲ ̲(̲C̲E̲)̲
A critical region is created (ref(1), sec. 4.41) using
the specified parameters Memory allocation (of region)
is included in the command.
S̲T̲A̲R̲T̲ ̲(̲S̲T̲)̲/̲R̲E̲M̲O̲V̲E̲(̲R̲E̲)̲/̲S̲T̲O̲P̲(̲S̲P̲)̲
A process with the specified name is started/removed/stopped.
Ref(1) - sec. 4.10 + 4.11 + 4.12.
U̲S̲E̲R̲ ̲O̲N̲ ̲(̲U̲N̲)̲/̲U̲S̲E̲R̲O̲F̲F̲ ̲(̲U̲F̲)̲
A user with the specified userid is allowed to use/not
to use the file system. ref(2) - p77 + 78, ref (7).
Normally only two users are using the FIKS-file system:
(-1, -1) System user. This user does the assignment,
deassignment, discard, start/finish dualize of devices
and mount, demount of volumes and dualizing of disk
sectors.
(0,0) - Ordinary user.
A̲S̲S̲I̲G̲N̲ ̲(̲A̲N̲)̲ ̲/̲D̲E̲A̲S̲S̲I̲G̲N̲ ̲(̲D̲N̲)̲
This command will assign/deassign the devices MMDO
and FIXO (and at SCC-configurations also the floppy
device FD00). The assignment can be done to use DISK
ONE, DISK TWO or DISKS DUAL. If default assignment
is used ('*') then DISK ̲STATUS is used to decide the
kind of assignment. The control blocks used is listed
below:
DEVICE ̲MMDO.DEV ̲DESC.IO ̲KIND = MMD82;
DEVICE ̲MMDO.DEV ̲DESC.IO ̲ADDR = 200;
DEVICE ̲MMDO.DEV ̲DESC.UNIT = 0;
DEVICE ̲MMDO.DEV ̲DESC.SUBUNIT = 0;
DEVICE ̲MMDO.DEV ̲DESC.NAME = 'MMDO';
DEVICE ̲MMDO.IO ̲ADDR ̲1 = 204;
DEVICE ̲MMDO.UNIT ̲1 = 0;
DEVICE ̲FIXO.DEV ̲DESC.IO ̲KIND = MMD82;
DEVICE ̲FIXO.DEV ̲DESC.IO ̲ADDR = 200;
DEVICE ̲FIXO.DEV ̲DESC.UNIT = 0;
DEVICE ̲FIXO.DEV ̲DESC.SUBUNIT = 1;
DEVICE ̲FIXO.DEV ̲DESC.NAME = 'FIXO';
DEVICE ̲FIXO.IO ̲ADDR ̲1 = 204;
DEVICE ̲FIXO.UNIT ̲1 = 0;
DEVICE ̲FDOO.IO ̲KIND = FD ̲SINGLE;
DEVICE ̲FDOO.IO-ADDR = 8;
DEVICE ̲FDOO.UNIT = 0;
DEVICE ̲FDOO.SUBUNIT = 0;
DEVICE ̲FD00.NAME = 'FDOO';
(In BRANCH TWO the two IO-addresses IO ̲ADDR, IO ̲ADDR-1
at device MMDO and FIXO are exchanged).
M̲O̲U̲N̲T̲(̲M̲T̲)̲/̲D̲E̲M̲O̲U̲N̲T̲(̲D̲T̲)̲
The volumes MOVHEAD and FIXHEAD are mounted on the
devices MMDO and FIXO.
U̲P̲D̲A̲T̲E̲(̲U̲E̲)̲
Both mounted volumes MOVHEAD and FIXHEAD is 'updated'
ref. (7), sec. 3.1.2.3.3.
G̲E̲T̲R̲O̲O̲T̲ ̲(̲G̲T̲)̲
The maindirectory (MD) of the specified volume will
be new system directory (SYSDIR).
D̲E̲F̲I̲N̲E̲-̲S̲Y̲S̲T̲E̲M̲-̲D̲I̲R̲E̲C̲T̲O̲R̲Y̲ ̲(̲D̲R̲)̲
'Descent' in current system directory to the specified
new system directory is performed. (new SYSDIR)
T̲A̲K̲E̲-̲C̲O̲M̲M̲A̲N̲D̲-̲(̲T̲D̲)̲
The specified COMMAND ̲FILE is 'looked up' in SYSDIR.
Command lines are read from the file and the commands
executed until end ̲of ̲file. Ref. sec. 3.3.11.
D̲I̲S̲C̲A̲R̲D̲ ̲(̲D̲D̲)̲
The disk unit (DISK ONE/DISK TWO) consisting of the
two devices MMDO and FIXO is discarded. The new DISK
̲STATUS is checkpointed and the SAF-process (ref (19)
is notified via an AMOS-message.
S̲T̲A̲R̲T̲-̲D̲U̲A̲L̲I̲Z̲E̲ ̲(̲S̲E̲)̲
The disk unit (DISK ONE/DISK TWO) consisting of the
two devices MMDO and FIXO, that currently is discarded
or not assigned, will in the future also be updated,
when a disk-write-operation is executed.
F̲I̲N̲I̲S̲H̲-̲D̲U̲A̲L̲I̲Z̲E̲ ̲(̲F̲E̲)̲
The file system is told that the disk system is dualized
and may be used as such. The DISK ̲STATUS (=DUAL) is
checkpointed and the SAF-process (ref(19) is notified
via an AMOS-message.
I̲N̲I̲T̲I̲A̲L̲I̲Z̲E̲-̲T̲D̲X̲ ̲(̲I̲X̲)̲
The TDX000-driver is ASSIGNED to the red TDX-host-device
and at Node/MEDE-configurations the TDX001-driver is
ASSIGNED to the black TDX-host-device. The control
blocks used at the assignment is given below:
Red TDX-host
TDX000 ̲DEVICE.IO ̲KIND = #7777;
TDX000 ̲DEVICE.IO ̲ADDR = #1F*4;
TDX000 ̲DEVICE.UNIT = 1;
TDX000 ̲DEVICE.SUBUNIT = #7777;
TDX000 ̲DEVICE.NAME = '****';
Black TDX-host Dummy values
TDX001 ̲DEVICE.IO ̲KIND = #7777;
TDX001 ̲DEVICE.IO ̲ADDR = #1F*4;
TDX001 ̲DEVICE.UNIT = 1;
TDX001 ̲DEVICE.SUBUNIT = #7777;
TDX001 ̲DEVICE.NAME = '****';
The assignment is followed by initializing of all the
LTUX-devices/terminals connected to the red TDX-bus-
ref sec. 3.3.5.
I̲N̲I̲T̲I̲A̲L̲I̲Z̲E̲-̲T̲D̲X̲-̲D̲E̲V̲I̲C̲E̲ ̲(̲I̲E̲)̲
Every terminal connected to the specified LTUX-device
no. is reinitialized, ref. sec. 3.3.5.
In case the LTUX-device is one for which the NSS-pro-
cess is responsible of (device no #20 or #80) then
a 'reinitialize-request' in form of an AMOS-message
(WORD0 = #FF, WORD1 = device-no) is send to the NSS-process.
Ref. (30). sec. (TBD)
NB! This option is only awailable with NSS-versions
younger than 0600.
C̲L̲O̲S̲E̲-̲S̲Y̲S̲T̲E̲M̲ ̲(̲C̲M̲)̲
The ESP-system will start a 'close down procedure',
ref.sec. 3.3.20.6
R̲E̲C̲O̲V̲E̲R̲-̲S̲Y̲S̲T̲E̲M̲ ̲(̲R̲M̲)̲
The command is only available at Node/MEDE-
configurations. The ESP system will begin a recover/restart-procedure.
Ref.sec. 3.3.20.4.
S̲T̲A̲N̲D̲B̲Y̲-̲O̲N̲(̲S̲N̲)̲/̲S̲T̲A̲N̲D̲B̲Y̲-̲O̲F̲F̲(̲S̲F̲)̲
The command is used to tell the ACTIVE BRANCH, that
the STANDBY BRANCH is ready/not ready to take over
operations in case of failure in the active branch
(i.e. to do recovery/restart). The SAF-process (ref(19))
is notified about the event by sending an AMOS-message
to it. The commands are meant to be used in cases,
where the Watchdog has failed and is not able to give
the notice.
R̲U̲N̲ ̲(̲R̲N̲)̲
From the specified codefile placed in SYSDIR program/process
is loaded and started as a background task . Ref. sec.
3.3.15. If the loading violates the rules about maximum
size of program/process then a notice
* LOAD ERROR
is logged.
R̲U̲N̲-̲A̲N̲D̲-̲D̲E̲L̲A̲Y̲ ̲(̲R̲Y̲)̲
Same as the command RUN but with the following modifications:
- memory allocation parameters are made available
for the background process. Ref. sec. 3.3.2.
- the ESP-process is delayed (not starting new commands)
while the background process is active (not removed).
The purpose of using this command is to let background
processes do the initializing of data area and the
allocation of memory in the system initializing phase.
S̲E̲T̲-̲D̲T̲G̲ ̲(̲S̲G̲)̲
This command defines the system time. The DTG must
be sat at the system initialization. This is enforced
by notifying the system operator with the printout.
*SET ̲DTG
The only accepted command will be SET ̲DTG. (else repeated
*SET ̲DTG-notice). The format of the keyed in DTG must
be
DDHHMMZ MON YY
where
01 = DD = 31 ;DD = day
00 = HH = 23 ;HH = hour
00 = MM = 59 ;MM = minute
00 = YY = 99 ;YY = year
MON JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG,
SEP, OCT, NOV, DEC ;MON = month
If MON FEB, APR; JUN, SEP, NOV then DD = 30
If MON = FEB then DD = 29
If YY (MOD4) 0 (can be divided by 4)
and MON = FEB then DD = 28
If one of these checks fails then the notice:
*SYNTAX ERROR
is printed.
Besides this checking, it is checked if the DTG is
not too old. The keyed in DTG (K-DTG) is compared to
the DTG of the youngest message stored on HDB (Y-DTG).
The DTG is retrieved from the SRS ̲CHECKP-file, ref.(29).
At SCC-installations Y-DTG is the checkpointed DTG,
ref (21). If K-DTG is less than Y-DTG then the notice:
*INVALID DTG
is shown to the operator and the SG-command must be
repeated.
A checking for 'too big DTG' is also performed. If
K-DTG is greater than Y-DTG + 24 hours, then the notice
*DTG OK??
is printed. The operator may then acknowledge the DTG
by keying in 'Y' (yes), anything else will be taken
for no, and the command can be repeated.
The system time is actually set by sending an AMOS-message
to the Real Time Clock (RTC) process formatted as stated
in ref (1), sec. 3.14.
C̲H̲E̲C̲K̲-̲A̲N̲D̲-̲L̲O̲A̲D̲-̲D̲T̲G̲ ̲(̲C̲G̲)̲
This command is used in the recovering phase to "synchronize"
the DTGs in the two branches of a Node/MEDE - the active
and the standby branch. The command checks if the DTG
in the standby branch is not too old - INVALID DTG,
ref SG-command. If this is the case then the checkpointed
DTG is used as system time instead. This "synchronizing"
is logged by using local ESP-error report - "DTG ̲SYNCHRONIZED"
ref. sec. 3.8. It is automatically executed by use
of the following commands.
L̲O̲A̲D̲-̲D̲T̲G̲ ̲(̲L̲G̲)̲
The checkpointed DTG (ref (21)) is loaded and processed
as if it was keyed in by an operator. I.e. the system
time is sat equal to the checkpointed one. In case
the DTG becomes too big - DTG OK??, then this is logged
using local ESP-error-report - "DTG ̲TOO ̲BIG" - warning.
The operator can later on adjust the DTG to be exact.
P̲R̲O̲C̲E̲S̲S̲E̲S̲ ̲(̲P̲S̲)̲
A status of all the processes in the user processor
is printed. See example. The items are explained below:
1. DTG at printout
2. Name of process
3. No. of CPU on which the process is executing.
4. SSTATE from PCB ref.(1), fig. 3.3.1.a (see below)
5. SAWAIT - " - (see below)
6. SABASE - " -
7. SPROGR - " -
8. SEXECT - " -
Timer units are 160 microseconds.
9. "*" means that the background is the one that on
the moment of printout occupies the BGT-areas.
10. Background process status word (if not empty).
Upper byte of the word contains the background
priority, lower byte the BGT ̲STATE.ref.sec. 3.3.15.2.
Summary of bit mark in STATE & SAWAIT (ref. (1), sec.
3.3.3.2.)
Bit No. sat means:
S̲T̲A̲T̲E̲
0: Process to be STOPPED
1: Process STOPPED
2: Process to be REMOVED
3: Process REMOVED (vacant PCB)
6: DRIVER process
7: Background process
8: Background process to be DEACTIVATED
9: Background process DEACTIVATED
11: Message buffer delivered to BPCB
12: Critical region used (ENTERED, WAITING,
TO ENTER/REENTER)
15: Process is READY (in KERNEL-schedule).
A̲W̲A̲I̲T̲ (awaiting an AMOS-event)
0: Signal
1: Message
2: Answer
3: System message
4: System answer
5: Path message
6: Path answer
7: Interrupt
8: Delay
9: Parent signal
10: Zero phase
11: Critical region access
15: (Inspection flag).
EXAMPLE: PROCESSES
F̲I̲L̲E̲-̲S̲Y̲S̲T̲E̲M̲ ̲(̲F̲M̲)̲
A status of all the processes in the file processor
is printed. See example. The item are explained below;
1. DTG at printout
2. Name of process
3. SSTATE ;from PCB.ref(1),fig.3.3.1.a
4. SERROR, error code ; - " -
- " -
5. SERROR, error location ; - " -
- " -
6. SEXECT ; - " -
- "
Timer unit is 160 -
microseconds.
The USER-FILE-processor interface sec. 3.2.2.7 is used
to retrieve the different items.
D̲I̲S̲K̲-̲S̲Y̲S̲T̲E̲M̲ ̲(̲D̲M̲)̲
A status of the disk system is printed. The items are
explained below.
1. DTG at printout
2. Disk unit (ONE/TWO)
3. Disk subunit/Volume (MOVHEAD/FIXHEAD)
4. No of read-operations executed on subunit.
5. No of write-operations executed on subunit.
6. No of milliseconds the subunit have been busy doing
disk-operations.
7. No of faulted read-operations on subunit (incl.
the recovered).
8. No of faulted write-operations on subunit (incl.
the recovered)
9. DISK STATUS WORD. ref sec. 3.3.4.3
The items 4,5,7,8 is resat after printout. To obtain
the different items USER-FILE-processor and FIKS CDC-driver
interface has been used.
Example: FILE ̲SYSTEM (FM)
EXAMPLE: DISK ̲SYSTEM (DM)
C̲R̲I̲T̲I̲C̲A̲L̲-̲R̲E̲G̲I̲O̲N̲S̲ ̲(̲C̲S̲)̲
A status of all critical regions is printed: See example.
The items are explained below.
1. DTG at printout
2. Name of region
3. CRSTA from RCB. ref(1), fig. 3.5.1.a
4. CRADDR - " - - " -
5. CRSIZE - " - - " -
6. If a process has ENTERED the region, then its name
will be placed here. ref(1), sec. 3.5.
T̲D̲X̲-̲S̲Y̲S̲T̲E̲M̲ ̲(̲T̲M̲)̲
A status of the TDX-system (as seen from the TDX-host's)
is printed. See example. The items are explained below.
1. DTG at printout
2. Host number - 1:= Red, 2:= Black
I̲n̲p̲u̲t̲
3. No of "NAK" is given
4. Flow control counter
5. No. of received frames
6. Record timeout counter
7. No. of sequence errors
8. No. of received packets
9. No. of phase errors.
O̲u̲t̲p̲u̲t̲
10. Global retransmission counter
11. Flow control counter
12. Global no. of transmitted frames
13. Timeout counter
Ref. (10) + Sourcelisting of TDX-HOST
Example: CRITICAL ̲REGIONS (CS)
EXAMPLE: TDX ̲SYSTEM (TM)
