top - download
⟦f45b2867c⟧ Wang Wps File
Length: 76126 (0x1295e)
Types: Wang Wps File
Notes: FIX/1105/PSP/046 II
Names: »3943A «
Derivation
└─⟦074b80a9e⟧ Bits:30006146 8" Wang WCS floppy, CR 0345A
└─ ⟦this⟧ »3943A «
WangText
…1b……00……00…K…02…K
…00……00…K K…05…H…00…H…07…G…08…G…09…G…0a…G…0d…G…0e…G…0f…G…07…F…08…F…0c…F…05…E…09…E…0b…E
D…08…D…0b…D…02…&…09…&…0b…&…0c…& &…05…&…06…&…07…%…0d…%…05…$…0d…$
#…08…#…0e…#
"…0c…"…01…"…86…1 …02… …02… …02… …02…
3943A/0345A
…02…FIX/1105/PSP/0046
…02…APE/880923…02……02…#
ESP SYSTEM PSP
…02…Issue 1…02…FIKS
3.3.10 S̲y̲s̲t̲e̲m̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲ ̲
Some activities (commands) have been developed to be
used as debugging tools, when the processing of the
FIKS system has to be examined at investigation of
errors and at testing of new software. The activation
of these utilities are not allowed, when the FIKS system
is operating in a real environment.
3.3.10.1 D̲U̲M̲P̲ ̲O̲F̲ ̲M̲E̲M̲O̲R̲Y̲ ̲(̲D̲Y̲)̲
The CR80-memory in the user processor is dumped to
disks. The area in use is declared in the critical
region CONFIG-CONSTANT ̲BLOCK.MEMORY ̲PAGES. The content
of each existing memory-page is dumped to a file placed
in *MOVHEAD*MD with name PAGE00/PAGE01/PAGE02/PAGE03.
3.3.10.2 D̲E̲B̲U̲G̲ ̲(̲D̲G̲)̲
This utility is used to:
1) dump CR80-memory on the console
2) patch in CR80 memory
3) search for destinct word in the CR80 memory
4) send an AMOS signal/message to a process
The use and function of the utility is explained and
illustrated by exhibit examples: (see also sec. 3.2.2.4
for command line format).
Re 1: The printout is performed using both hexadecimal
format of the words and ASCII format of the
bytes. It must be observed that only values
printed on the same line are from the same
"moment of time".
Re 2: Only one word can be patched at one moment
Therefore special precautions (stop of processing
!) must be taken when more than one word shall
be patched.
Re 3: The search-utility is implemented by "reuse"
of the dump-utility procedures. Instead of
dumping a word, this will be compared to the
one keyed in. This observation may help to
explain the results.
Re 4: When the AMOS-message has been sent to a process,
the ESP will (temporary) cancel "receipt of
answers" as an awaited event when checking
for events (ref. sec. 3.3 (18+19)).
Re 4: When the AMOS-message has been sent to a process,
the ESP will wait for answer upon this before
receipt of new commands are resumed. The processing
concerned the other ESP-task will continue.
When the answer arrives the buffer contents
is dumped on the console. To escape from a
case where the answer stays away, the operator
can interrupt the ESP, i.e. key in "!".
3.3.10.3 Q̲A̲C̲C̲E̲S̲S̲/̲M̲T̲C̲B̲-̲U̲t̲i̲l̲i̲t̲y̲ ̲(̲Q̲M̲)̲
This utility is used to dump the contents of the MTCB's
and queues as they appear in the CR80-memory. The same
dumps could in fact be performed with the DEBUG-utility.
The QM-utility can be seen as an automation of this.
The QM-utility makes extensive use of the FIKS MTCB-
and QUEUE-data structures. These are described in details
in ref. 13 + 27 + 28. See also sec. 3.2.2.4 for command
line input format. The use is illustrated by examples.
3.3.10.4 I̲N̲S̲P̲E̲C̲T̲ ̲(̲I̲T̲)̲
This utility is used to dump the content of a diskfile
(inspection file) on the console printer and to make
patches in the file. The use and function of the utility
is explained and illustrated by giving examples. See
also sec. 3.2.2.4 for command line format.
When the volume, where the inspection file resides
is specified (IT V volume) then the maindirectory of
that volume is opened as inspection file. If an old
inspection file was opened, this one is closed. A lookup
in the current inspection file (directory) of a new
inspection file is executed with the command 'IT filename'.
If the file is found, then this file is opened as new
inspection file and the old one is closed. In this
way it is possible to INSPECT every file in the FIKS-system.
Dumping of data from inspection file is executed by
stated a start location and a dump size. Start location
is a wordoffset in the file composed of two items,
most and least significant word of the doubleword forming
the address. If the dumpsize, stated in words, is not
specified, then this is defaulted to be the number
from start location until end of file. The printout
is performed using both hexadecimal format of the words
and ASCII format of the bytes.
Patching of words in the inspection file is performed
when the address, a doubleword wordoffset, and the
words to be patched, are stated.
A 'reset inspection file' capability has mainly been
implemented to handle the sitiationom that arise when
there does not exist enough available diks-space for
initializing to 'TOS offline'. By using the 'IT R'-
utility at 'FIKS online', it is possible to procure
the diks-space needed for generation of the required
'TOS-initializing'-files.
3.3.10.5 F̲L̲O̲P̲P̲Y̲ ̲U̲T̲I̲L̲I̲T̲Y̲ ̲(̲F̲Y̲)̲
This utility is used to dump files to/from the FIKS
disk system from/to a floppy-diskette, while the FIKS-system
is operational. See sec. 3.2.2.4 for command line format.
All dumping (copying) goes on between a directory in
the FIKS-disk system (FLOPPY ̲SYSDIR) and the maindirectory
on the floppy volume with name FLOPPY. The FLOPPY ̲SYSDIR
is specified in a way similar to that used when specifying
the INSPECTION-file. Before copying is started the
file DUMPED TO is CREATED with contiguous organization
and size equal to the file DUMPED FROM. If the file
already exist, then it is REMOVED before CREATION is
performed.
At Node/MEDE-installations the utility can only be
used in BRANCH ONE. In return it can be used even if
the branch is STANDBY.
3.3.11 C̲o̲m̲m̲a̲n̲d̲ ̲F̲i̲l̲e̲s̲
Commands to be executed after each other can be held
in a disk file. This file consists of command lines
formatted as usual keyed in commands - ref. sec. 3.2.2.
The termination character for a line is a NL (hexvalue
# OA). This format is used because that, it is then
immediately possible to create, fill and change a command
file in off-line TOS-environment using the standard
CR80-utility EDIT.
When a TD-command is issued, then the command file
(placed in SYSDIR) is opened. Then repeatedly, a command
line is read from the command file into the INPUT ̲LINE-buffer,
the line is interpreted and the command executed, until
end ̲of ̲file or an other TD-command is met. Occurence
of an error in the interpretation or a 'SWITCHOVER'-error
in the processing of the command, will also terminate
the reading of new commands. Processing of command
files is done in one level, i.e. there is no return
to a command file where a TD-command is met.
The command file concept has been implemented for use
in the initializing procedures of a FIKS system, ref.
sec. 3.3.20. At the execution of these procedures the
command files ACTIVE, STANDBY, RECOVER and CLOSE is
used. Appendix 7.1 contains a listing of those files.
3.3.12 S̲e̲q̲u̲e̲n̲c̲e̲ ̲o̲f̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
At moments where the system has no access to the disk
system, command files can not be used. At the first
step of an initialization procedure, where the disks
are not assigned, there would be no way in which a
sequence of command could be carried out, if the concept
SEQUENCES has not been introduced. SEQUENCES work like
command files. Instead of reading command lines from
a file, then the INPUT ̲LINE-buffer is filled with commands
from internal ESP-data area. This means that changing/updating
of SEQUENCES will involve a new ESP-process. The execution
of SEQUENCES is started with ESP-procedure calls. The
following SEQUENCES are used in current ESP-version.
SYSTEM ̲OPEN1
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
UN #FFFF #FFFF "System FMS-user on
UN O O "Ordinary FMS-user on
AN * "Assign default
MT "Mount volumes
GT MOVHEAD "SYSDIR = *MOVHEAD*MD
DR FIX ̲CONFIG.D "SYSDIR = FIX ̲CONFIG.D
Used at the preliminary initialization of the disk
system.
SYSTEM ̲OPEN2
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
AN * "Assign default
MT "Mount volumes
GT MOVHEAD "SYSDIR:= *MOVHEAD*MD
DR FIX ̲CONFIG.D "SYSDIR:= FIX ̲CONFIG.D
Used at the secondary (after the preliminary) initializations
of the disk system.
IO ̲SYSTEM ̲ CLOSE
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
UE "Update volumes
DT "Demount volumes
DN "Deassign
UF O O "Ordinary FMS-user off
UF #FFFF #FFFF "System FMS-user off
Used when the system is CLOSED.
SYSTEM ̲ACTIVE
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
TD ACTIVE "Start ACTIVE-command
file
SYSTEM ̲STANDBY
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
TD STANDBY "Start STANDBY-command
file
SYSTEM ̲RECOVER
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
TD RECOVER "Start RECOVER-Command
file
SYSTEM ̲CLOSE
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
TD CLOSE "Start CLOSE-command file
3.3.13 A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲
It is possible for a process, i.e. a FIKS application
to issue a command to the ESP-system. This is performed
by the application using the interface described in
sec. 3.2.2.5.
The processing of the command seen from the ESP-system
is as follows:
1. The CONSOL-process is waiting on an AMOS-message
(+ other events).
2. CONSOL receives an AMOS-message and transfers the
contents to the ESP-process in an AMOS-system message.
Receiving of more AMOS-messages are inhibited,
i.e. possible new applications commands are enqueued
in the AMOS-message-queue.
3. ESP receives the system message from CONSOL and
sets the ESP ̲STATUS to PROCESS ̲COMMAND and stores
the message, edited to the standard command format,
in the PROCESS ̲COMMAND ̲EDIT-buffer. The system
answer is returned.
4. When the ESP-process is not occupied by higher
priority (ref. sec. 3.3.19) processing, then the
outstanding PROCESS ̲COMMAND is served. The PROCESS
̲COMMAND ̲EDIT-buffer is transferred to the INPUT
̲LINE-buffer for interpretation and execution of
the command. The ESP ̲STATUS is changed from PROCESS
̲COMMAND to PROCESS ̲EXECUTING.
5. ESP interprets the command. If an error occurs
in this procedure, completion code is inserted
in the CONSOL-message buffer. No execution is performed.
6. ESP executes the command. If a local ESP-error
occurs while this execution takes place, then completion
code is inserted in the CONSOL-message buffer.
7. ESP ̲STATUS PROCESS ̲EXECUTING is cleared and a AMOS-signal
is sent the CONSOL-process.
8. CONSOL receives the AMOS-signal and is thereby
notified that the processing of the application
command is finished. CONSOL returns the AMOS-answer
to the application process and enables receiving
of AMOS-messages, i.e. opens for more application
commands.
3.3.14 E̲S̲P̲ ̲l̲o̲g̲g̲i̲n̲g̲s̲ ̲
Whenever a FUNCTION has been executed successful, this
is logged on the console printer, if printing is enabled
(i.e. if ESP ̲STATUS is HARD ̲COPY ̲WANTED- ref. sec.
3.2.2.2). See sec. 3.2.2.6 for format of the logging.
The logging is very essential in the planning of how
the CR80-memory shall be layed out - ref. sec. 3.3.2.
The memory allocation for the modules loaded is logged.
This information can be used to determine the new memory
layout, when modules have been changed or added.
When the Watchdog is in monitor-mode (ref (14)), then
the logging is suppressed. It is therefore necessary
to be in transparent Watchdog-mode to the logging branch,
if the printing shall appear. Error reports are always,
in spite of the Watchdog-mode, printed. This 'mechanism'
is used to make sure, that other loggings essential
for the operations of the system are also printed.
Logging of DISK ̲STATUS (at changes) and occurence of
WILD ̲EVENT's is formatted using error report format,
and thereby enforcing the printout. The TYPE in Watchdog
header (ref (13), sec. 4.2.2.1) is sat to "Non fatal"
to inhibit switchover action. See also sec. 3.3.18.
3.3.15 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲
Some tasks in the FIKS-system may be of low priority.
By this means, that it is not essential, that the processing
they do, is executed at the same moment as the request
for it arises. The processing may also only be activated
periodicly or very seldom. If nothing else was done,
then each of these tasks would occupy their individual
part of the CR80-memory. They might as well take turns
on using one distinct area and thereby share this.
In this way the memory would be much better utilized.
The above mentioned scheme has been used to introduce
"Background Management" in the FIKS system.
3.3.15.1 O̲u̲t̲l̲i̲n̲e̲/̲P̲r̲e̲r̲e̲q̲u̲i̲s̲i̲t̲e̲s̲
A fixed amount of memory has been allocated for use
of background processing - one part for programs (BGPM)
and one part for process data (BGPS). When the background
task (BGT) is a̲c̲t̲i̲v̲a̲t̲e̲d̲, then it exclusively uses this
memory, i.e. only one BGT can be active at one moment.
When the BGT is d̲e̲a̲c̲t̲i̲v̲a̲t̲e̲d̲ any processing involved
in the BGT must not use the areas.
For each BGT there exist a disk-space (part of a file:
BGPS ̲FILE) where both BGPM and BGPS can be placed temporary
while the BGT is deactivated and an other active BGT
is processing. When one of the deactivated BGT's shall
do some processing the following scheme is used:
1. The active BGT (-A) is deactivated.
2. The BGPM- and BGPS-areas are stored in BGPS ̲FILE
at places reserved for BGT-A. (BGT-A is rolled
out).
3. The BGPM- and BGPS-areas of the BGT (-B), which
is becoming to be active is loaded from BGPS ̲FILE
(BGT-B is rolled in).
4. BGT-B is activated.
The vital point in using this scheme is to control
when a BGT is activated/deactivated.
Deactivation is initialized by using the AMOS procedure
STOPPROCESS ref (1), sec. 4.11. The following criteria
is used to determine when the BGT is deactivated:
A State of BGT (SSTATE in the PCB, ref (1) sec. 3.3.2.)
is STOPPED.
B. State of BGT is TO ̲BE ̲STOPPED and the process is
waiting on a KERNEL-event (SAWAIT in the PCB is
not equal zero, ref (1), sec. 3.3.2)
C. There must not exist any outstanding IO-request.
The BGT is deactivated if (A or B) and C is true.
r̲e̲ ̲p̲o̲i̲n̲t̲ ̲A̲
When a process is STOPPED only a START-command - MON(STARTPROCESS)
- can activate it again.
r̲e̲ ̲p̲o̲i̲n̲t̲ ̲B̲
When the awaited event occurs, then the BGT is STOPPED
at exit from KERNEL. The processing executed until
then involves:
- only execution of instruction in KERNEL-code, i.e.
no instructions of BGT-code is performed.
- AMOS events, represented by the "Event registers"
R0, R1, R2 and a message buffer, may be delivered
to the BGT.
It is observed, that if nothing else was done, then
the BGPS-area of an active BGT would be corrupted,
when a deactivate BGT is STOPPED. This calamity is
avoided by rerouting the delivery of the AMOS events
to places outside the BGT-areas, while a BGT is deactivated.
Before the BGT is activated next time, the AMOS-events
are placed in the BGPS-area, where they were originally
intended to be delivered.
r̲e̲ ̲p̲o̲i̲n̲t̲ ̲C̲
No transfer in/out of the BGPS-area must be performed,
when a BGT is deactivated (IO-operations). This is
(and must be) in the FIKS system tantamount to, that
no AMOS answers/systemanswers/pathanswers is awaited
from a DRIVER-process. A DRIVER-process is defined
as a process, that performs data-transfers in/out of
data areas of another process. A DRIVER-process is
identified as such by a status bit in SSTATE of the
PCB.
To avoid bottleneck-cases, when critical regions are
used in connection with background processing, BGT's
should not have ENTERED a critical region, when it
gets deactivated. The AMOS-command MON(STOPPROCESS)
is not carried out until the region is left.
A BGT is activated when it is loaded and started by
the AMOS-command MON(STARTPROCESS).
An advantage of using the scheme mentioned is that
it is very easy to see, if a deactivated BGT requests
processing. When SSTATE of the PCB is STOPPED, then
a possible awaited event has occurred, and the BGT
is ready to continue the processing.
In Figure 3.3.15.1 is shown in overview roll out/in
of BGT-A/B.
Figure 3.3.15.1…01…Background Management…01…Roll In/Out
3.3.15.2 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲S̲c̲h̲e̲d̲u̲l̲i̲n̲g̲
A very essential part of the background management
is the scheduling of the BGTs - when and in which order
shall they be activated. In the FIKS background scheduling
implementation the concept used in the KERNEL process
scheduling has been taken as a model.
The scheduling is started at occurence of the following
events:
1) The active BGT has no longer need for processing.
An event has to happen before the processing can
be resumed. Another BGT can be activated.
2) Some of the deactivated BGTs demand processing.
The event, which the BGT awaited, has happened.
The BGT is ready to be activated.
3) The maximum time in which a BGT may be active,
while other BGTs demand processing has run out.
Three ordinary BGT-proirities corresponding to those
used in KERNEL-scheduling exist. BGTs with high priority
will be activated much more often than those with low
priority. Besides these priorities a special IDLE-background
priority exists. BGTs with this priority will only
be activated in case all BGTs with higher priority
have no demand for processing. In contradistinction
to the KERNEL-concept all priority levels have the
same duration (time slice).
The non-IDLE priority levels take turns based upon
a "SCHEDULE ̲SEQUENCE"-list. The intension is that a
priority level one level higher than another will be
activated twice as often as the other. Within one level
the BGTs are activated after a simple cyclic scheme.
To avoid bottlenecks and inconvenient blocking of the
processing a BGT which has ENTERED a critical region
will be scheduled independent of priority level.
The scheduling algoritm is shown in Figure 3.3.15.2.
Figure 3.3.15.2.a…01…Background Management Scheduling Algorithm
Figure 3.3.15.2.b…01…Background Management Scheduling Algorithm
Figure 3.3.15.2.c…01…Background Management Scheduling Algorithm
3.3.15.3 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
For management of the background processing and rerouting
of BGT AMOS-events, Background Process Control Blocks
(BPCB's) have been introduced.
One BPCB for each BGT running at one moment. The BPCBs
are used and accessed simultaneously by both the ESP
and the KERNEL.
B̲P̲C̲B̲-̲L̲a̲y̲o̲u̲t̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^Location ^Name ^Description
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^ 0 ^STATE ^Status of BGT (see below)
^ ^ ^
^ 1 ^PCB ̲REF ^ESP relative address to PCB
^ ^ ^
^ 2 ^PCB ̲INDEX ^KERNEL index of PCB
^ ^ ^
^ 3 ^PRIORITY ^BGT priority
^ ^ ^
^ 4 ^BPCB ̲INDEX ^ESP index of BPCB
^ ^ ^
^ 5 ^PROG ̲SIZE ^Size of BGPM-area
^ ^ ^
^ 6 ^PROC ̲SIZE ^Size of BGPS-area
^ ^ ^
^ 7-9 ^RO12 ^Stored event registers (R0,R1,R2)
^ ^ ^
^ 10-14 ^MSG ̲BUF ^Possible stored message buffer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
S̲T̲A̲T̲E̲-̲W̲o̲r̲d̲:
Bit no. on means:
0: BGPS ̲RUNNING - "Not vacant
1: BGPS ̲STARTED - "In the scheduling
2: BGPS ̲REMOVED - "To be removed
3: BGPM ̲STORED - "At least once
4: BGPM ̲REENTRANT- "No modification of
BGPM
3.3.15.4 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲P̲r̲i̲o̲r̲i̲t̲y̲ ̲
The priority of a BGT shall be low compared to the
message processing, i.e. compared to the rest of the
AMOS-processes in the FIKS-system. Therefore every
BGT's are executing with the lowest possible AMOS-priority
(2) as seen from the KERNEL scheduling point of view
- ref (1), sec. 3.4.3. The priority (XPRIORITY, ref
(1), appendix B) is instead used as BGT-priority. XPRIORITY
greater than 2 will result in a BGT-IDLE priority.
3.3.15.5 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
To implement the FIKS background processing it has
been necessary to perform some modification of the
AMOS KERNEL used in the FIKS executive system software.
The details of these changes/modifications are specified
in Appendix 7.2 - DCN's needed to get ref. (1) to confirm
with the KERNEL used by the FIKS system. The ideas
and the outline that caused the modifications are explained
in the following:
C̲r̲e̲a̲t̲i̲o̲n̲/̲L̲o̲a̲d̲ ̲o̲f̲ ̲B̲G̲T̲s̲
A BGT is specified as such to the FIKS system when
the RUN/RUN ̲DELAY-commands (ref. sec. 3.3.9) are used
to include an application process into the FIKS system.
(The application process might as well be loaded, created
and started using the ordinary LOAD-, CREATE- and START-commands).
When RUN/RUN ̲DELAY is used, the application (i.e. the
BGT) is loaded into the BGT-areas and started as usual
processes with the following modifications:
- It is checked that the BGPM- and BGPS-area are
not greater than the maximum allowed values
(MAX ̲SIZE ̲RGPM, MAX ̲SIZE ̲BGPS). If one of
the areas is greater, then this will cause a "*LOAD
ERROR" (ref. sec. 3.2.2.4).
- The "Background Process"-bit (BNBGPRO) in the capability
word in the process creation block is set. This
will inform the KERNEL about coming creation of
a BGT. When the process is CREATED the KERNEL will
set the BNBGPS-bit in the PCB.SSTATE.
- A BPCB (ref. 3.3.15.3) is allocated to the BGT.
The ESP will install the items PROG ̲SIZE, PROC
̲SIZE. These are used to minimize the data transfers
involved in the ROLL IN/OUT procedures. The BGPM
̲REENTRANT status in BPCB.STATE is set, if the program
code is reentrant - the BGPM-area will then only
have to be rolled out once.
- The BGTs are created with the lowest possible KERNEL-priority
(2). This will ensure that the BGTs do not deprive
the non-BGTs too much CPU-time. The ordinary KERNEL-priority
(PROCESS ̲HEAD.PRIORITY) is installed in BPCB.PRIORITY
and used in the BGPS-scheduling.
A̲c̲t̲i̲v̲a̲t̲i̲o̲n̲/̲D̲e̲a̲c̲t̲i̲v̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲B̲G̲T̲s̲
Deactivation of an active BGT is initiated by stopping
the process - MON(STOPPROCESS). The KERNEL will then
set the status "Going to be deactivated" (BNGDAC) in
PCB.SSTATE to mark special treatment of this process.
Each time the BGT is referred to in KERNEL-coherence,
the KERNEL will perform a test of if the BGT have been
deactivated, i.e.
1) The BGT is SUSPENDED
2) The BGT has no autstanding IO's.
Re point 1 -
A new status BNREADY in the PCB.SSTATE is set/cleared
whenever a process gets READY/SUSPENDED in the KERNEL
sense.
Re point 2 -
A new item "No. of unanswered driver messages" (SDRMCT)
in the PCB has been introduced. Each time an AMOS message/system
message/path message is sent to a DRIVER-process SDRMCT
is incremented. Whenever an AMOS answer/system answer/path
answer is received from a DRIVER-process SDRMCT is
decremented. When SDRMCT is equal zero, then no outstanding
answers (IO-requests) exist. A DRIVER-process is a
process which has the "Driver Process" bit (BNDRVP)
in the PCB.SSTATE set. The BNDRVP-state will be set
if the new "Driver Capability"-bit (BNEXDRV) in PROCESS
̲HEAD.CAPABILITY- word is set at the moment, the DRIVER
is loaded and created.
When 1 + 2 are fulfilled the "event registers" (R0,R1,R2)
of the BGT are stored in the BPCB.R012. Future events
concerning the BGT will be delivered to BPCB.R012.
Delivery of a possible message buffer will be routed
to BPCB.MSG ̲BUF. The "Message buffer delivered"-bit
(BNMSDL) in the PCB.SSTATE will then be set. The BNGDAC
status will be cleared and the BNDEAC status in PCB.SSTATE
set to indicate that the BGT is now deactivated. No
processing concerned the BGT will affect the BGT-areas.
Activation of a BGT loaded into the BGT-areas is initiated
by starting the process - MON(STARTPROCESS). Before
the former deactivated process is set READY, the following
is performed:
- The event registers (R0,R1,R2) are fetched from
BPCB.R012 and stored in the process base memory
area.
- If a message buffer has been delivered while the
BGT was deactivated (BNMSDL-bit in PCB.SSTATE set),
then this is fetched from BPCB.MSG ̲BUF and stored
in the process area (determined by the item PCB.SWORK),
where it was originally routed for.
After this, the process data area will look just as
if the process had been STOPPED like an ordinary non
BGT-process. The BGT can now continue the processing.
B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲E̲v̲e̲n̲t̲s̲
The background process scheduling is executed by the
ESP. The KERNEL knows when the scheduling shall take
place (ref. sec. 3.3.15.2). The KERNEL has to transfer
this information to the ESP. This is performed using
a new kind of AMOS events "Background Events" which
only the ESP can receive. When KERNEL senses one of
these events as:
- SUSPENSION of a BGT, which has no outstanding IO's
(PCB.SDRMCT = 0).
- A BGT already SUSPENDED receives the last one of
its outstanding IO's.
- A deactivated BGT gets READY.
then the background management semaphore (BGMSEM) in
the KERNEL semaphore word (MPSEM1) is set. Whenever
a process exits from KERNEL it is tested, if the ESP
is waiting on a background event. If so the ESP will
get the event delivered and put into the KERNEL READY-queue
for execution of the scheduling. If the BGMSEM is set
when the ESP calls MON(WAITEVENT), it will receive
the event immediately. Background events can be considered
as an expansion of the ordinary AMOS event concept.
B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲T̲i̲m̲e̲ ̲S̲l̲i̲c̲e̲s̲
When a BGT is activated a timer of BGPS ̲TIME ̲SLICE
is started and cancelled when the BGT is deactivated.
If the timer runs out, then the BGT has used the maximum
processing time allocated for the BGT for this time.
BGPS-scheduling has to take place. The BGPS ̲TIME ̲SLICE
is the same for all BGT-priorities.
(in contradistinction to the KERNEL-scheduling).
When a BGT is started to be deactivated (another BGT
shall be activated) a timer of BGPS ̲DISORDER ̲TIME ̲OUT
is started to supervise that the deactivation take
place within a reasonable time limit. If not, then
a lock in the background processing has arised. This
is an error and is reported as an ESP error report
(ref. sec. 3.3(16+17)). The first two times the error
report is understood as a warning (BGPS DISORDER),
the third time as a fatal error (SWITCHOVER).
S̲t̲o̲p̲p̲i̲n̲g̲/̲S̲t̲a̲r̲t̲i̲n̲g̲/̲R̲e̲m̲o̲v̲i̲n̲g̲ ̲o̲f̲ ̲B̲G̲T̲s̲
BGTs may be stopped/started/removed by using the ordinary
ESP-commands. When the BGT is stopped, then the BPCB.STATE
BGPS ̲STARTED is cleared and thereby excluding the BGT
from the scheduling. When the BGT is started then the
state is reset and the BGT will again take part in
the scheduling. When a BGT is removed, then the BPCB.STATE
BGPS ̲REMOVED is set. Next time the BGT is activated,
the BGT will be removed (in KERNEL sense).
3.3.15.6 B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲L̲i̲m̲i̲t̲a̲t̲i̲o̲n̲s̲
The design of the FIKS Background Processing has been
performed so that the designer of FIKS-applications
does not need to care too much about whether the task
should be loaded as a BGT or not. Some considerations,
however, have to be taken into account:
- A BGT Must not have outstanding IO's in long periods.
I.e. when doing IO-operations, these must be expected
to be finished within a reasonable time (2-3 seconds
corresponding to the BGT-time slice). A BGT with
ever outstanding IO's will obstruct for other BGTs.
- A BGT can be a DRIVER-process but then no other
BGTs may use it for doing IO's.
- The sizing (BGPM- and BGPS-areas) has an upper
limit. No BGT must be greater than the MAX ̲SIZE
̲BGPM, MAX ̲SIZE ̲BGPS allocated in the CR80 memory
for BGT-processing.
- The total BGT consumption of resources (CPU-time,
IO-operations, etc.) shall be limited. If too many
BGTs use too much resoruces a risk for bottlenecks
arise. A task, which requires quick response, shall
not be executed as a BGT.
3.3.16 S̲y̲s̲t̲e̲m̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲
When an error is sensed by a process in the FIKS-system,
this is reported by use of the monitor procedure MON(ERROR)
- ref (1), sec. 4.3.9. This will cause that an AMOS-parent
signal is sent to the parent process. As the ESP-process
is the parent of all processes in the FIKS-system,
then ESP will receive all parent signals, i.e. all
error reports. It is then up to ESP to analyse these
errors and take proper actions based on this analyse.
The error code and error location associated with the
error report is stored in the PCB of the reporting
process - ref(1), fig. 3.3.1.a. From here they are
collected by the ESP. The analysis is performed on
basis of the error code. The code is compared with
those in the ERROR ̲CODES-table and checked if they
are included in some ranges. Based on this, the action
to be taken by ESP is determined. The connection between
the error codes and actions is shown in table 3.3.16.
When the analysis is performed, then an error report
according to the format specified in ref (13), sec.
4.2.2, is formatted and printed on the console. The
action is executed after the logging and performed
in the same way as if they were ordinary commands to
the ESP-system.
E̲r̲r̲o̲r̲ ̲D̲u̲m̲p̲ ̲U̲t̲i̲l̲i̲t̲y̲
There exist a possibility of getting certain memory
areas dumped to disk files in connection with an error.
By using the 'DEFINE ̲ERROR ̲DUMP'-command (ref. sec.
3.2.2.3) it is possible to declare which parts of the
memory that shall be dumped in case a certain process
reports a certain error code. The dumping is performed
to a file ERROR ̲DUMP.X in the directory
*MOVHEAD*ERROR ̲DUMP.D. X is the error dump identification
no. logged by the ESP after the DP-command. The dumping
is done before the error logging. In this way a possible
becoming SWITCHOVER-procedure will not be disturbed.
The error dump can later on be loaded to a floppy-diskette
with the FLOPPY-utility for inspection, still without
having the system not operational.
C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲b̲e̲t̲w̲e̲e̲n̲ ̲e̲r̲r̲o̲r̲ ̲c̲o̲d̲e̲ ̲a̲n̲d̲ ̲e̲r̲r̲o̲r̲ ̲a̲c̲t̲i̲o̲n̲s̲
ref (13), sec. 4.2.2.
CODE (hex) ESP-action
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
E00, I̲G̲N̲O̲R̲E̲D̲
restart of process
FF, 423, 801 L̲O̲C̲A̲L̲ ̲F̲I̲X̲ ̲U̲P̲
805, 907, 90B only at Node/MEDE installations
90C, restart of process.
B01, B02, B03, L̲O̲C̲A̲L̲ ̲F̲I̲X̲ ̲U̲P̲
607, 6FF, both at Node/MEDE- and SCC-instal-
A00 - AFF lations. Restart of process.
451 - 45D, B1 D̲I̲S̲C̲A̲R̲D̲ ̲D̲I̲S̲K̲ ̲O̲N̲E̲
461 - 46D, B2
461 - 46D, B1 D̲I̲S̲C̲A̲R̲D̲ ̲D̲I̲S̲K̲ ̲T̲W̲O̲
451 - 450, B2 B1, B2 = BRANCH ONE, BRANCH TWO
only at Node/MEDE-installations.
Discard of affected disk unit - ref.
sec. 3.3.4.5.
0 removal of process, no error logging,
used as ordinary process termination.
FFFF B̲G̲P̲S̲ ̲D̲I̲S̲O̲R̲D̲E̲R̲
in connection with background management
(ref sec. 3.3.15). The process is
allowed to continue processing. The
third time, error action text is
changed to the following.
every other S̲W̲I̲T̲C̲H̲O̲V̲E̲R̲,̲ ̲Node/MEDE, ACTIVE BRANCH
codes O̲P̲E̲R̲A̲T̲I̲O̲N̲ ̲F̲A̲I̲L̲,̲ ̲S̲C̲C̲.̲
S̲T̲A̲N̲D̲B̲Y̲ ̲O̲F̲F̲, Node/MEDE,STANDBY BRANCH
no restart of process,
Table 3.3.16.
3.3.17 E̲S̲P̲ ̲L̲o̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The ESP-process can be exposed for the same errors
as other processes in the FIKS-system. Those errors
cannot be reported via the usual MON(ERROR)-calls (ref.
sec. 3.3.16). Instead the ESP will do the analyse and
logging directly based upon the error code, so it ends
up with an error report similar to that of the application
processes.
Certain system procedures that the ESP also uses, use
MON(ERROR)-calls in case of failures. The ESP may also
be exposed for LOCAL ̲ACTION-errors (traps, parity error,
timeout on mainbus) which via KERNEL results in MON(ERROR)-calls.
To handle this the KERNEL used in FIKS has been modified.
In case ESP calls MON(ERROR), it will, instead of being
SUSPENDED, be restarted in a distinct location "ESP
̲EXIT ̲MON ̲ERROR" defined in both KERNEL and ESP-code.
The error can then be handled as an application process
SWITCHOVER-error (no restart).
The actions taken when the ESP senses an error in its
own processing are the same as for an application process
(ref. table 3.3.16). In case of SWITCHOVER-error any
SEQUENCE or COMMAND-file that is going on is interrupted.
3.3.18 W̲i̲l̲d̲ ̲E̲v̲e̲n̲t̲s̲
All events, sent to a not existing process, is in the
AMOS-KERNEL-system rerouted to the ROOT-process-ref(1),
sec. 3.13. I.e. in the FIKS-system these WILD ̲EVENTs
are received by the ESP-process. The events are logged
using standard error report format, where error code
and error label is exchanged with a WILD ̲EVENT-text.
If possible the name of the process that has sent the
event is stated. In the following text, name and ESP-action
are listed.
S̲I̲G̲N̲A̲L̲
text: WILD SIGNAL
name: ??????
action: none
M̲E̲S̲S̲A̲G̲E̲
text: WILD MESSAGE
name: sending process
action: dummy answer returned
A̲N̲S̲W̲E̲R̲
Text: WILD ANSWER
name: ??????
action: none
S̲Y̲S̲T̲E̲M̲ ̲M̲E̲S̲S̲A̲G̲E̲
text: WILD SYSMESSAGE
name: sending process
action: dummy systemanswer returned
S̲Y̲S̲T̲E̲M̲ ̲A̲N̲S̲W̲E̲R̲
text: WILD SYSANSWER
name: ??????
action: none
P̲A̲T̲H̲ ̲M̲E̲S̲S̲A̲G̲E̲
text: WILD PATHMESSAGE
name: sending process
action: dummy path answer returned
P̲A̲T̲H̲ ̲A̲N̲S̲W̲E̲R̲
text: WILD PATHANSWER
name: ??????
action: path is closed
When a dummy answer is returned, then the message buffer
is filled with words equal to #800 (UNKNOWN). The error
action text used at the logging is 'IGNORED'. The logging
is not performed, when the system is in a state where
they occur naturally - when the system is CLOSING or
RECOVERING (only WILD SIGNALs).
3.3.19 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲o̲f̲ ̲E̲v̲e̲n̲t̲s̲/̲C̲o̲m̲m̲a̲n̲d̲s̲
The following AMOS events can be received by the ESP-process
and initiate some kind of actions. They are listed
in the following.
A. Interrupt (from CONSOL)
- Character input from the console.
If the character (CR) indicates termination
of an input line, then COMMAND-processing is
started.
B. System message from CONSOL.
- Application command request.
The request is stored for later on to be processed.
C. Message from CONSOL.
- Watchdog polling/command.
The answer on the polling is returned or processing
of the command is started. This processing
has higher priority than all other ESP-processing.
D. Background Event.
- Background scheduling (ref. sec. 3.3.15) is
executed at once.
E. Background Management Timeout
- If the active BGT is going to be deactivated
then a "BGPS DISORDER/SWITCHOVER" error report
is issued as a warning/fatal error. If not,
background scheduling is performed.
F. Answer from SAF.
- no action.
G. Parent signal
- Error report from a process.
The report is analysed and logged. Any action
to be executed is performed.
H. All other possible AMOS-events.
- Wild events. These are handled. - ref. sec.
3.3.18.
When the ESP is busy, i.e. when the processing started
by a command/event has not yet finished, then receiving
of characters is disabled.
The events B - H are checked for occurrence in the
procedure CHECK ̲EVENTS and served in the procedure
SERVE ̲EVENTS. Both checking and serving are performed
in the procedure CHECK ̲SERVE ̲EVENTS.
The events A, B, C may lead to start of a command.
This may start a SEQUENCE or a COMMAND ̲FILE, which
again may start an other SEQUENCE or COMMAND ̲FILE etc.
The management of this processing is shown in the flowchart
fig. 3.3.19.
By looking upon the figure the following rules about
the processing can be extracted.
1. Watchdog commands have the highest priority.
2. Commands from COMMAND ̲FILEs have higher priority
than those from SEQUENCEs. I.e. executing of a
COMMAND ̲FILE may be contained in a SEQUENCE and
not reverse.
3. SEQUENCES/COMMAND ̲FILES may be used in SEQUENCES/COMMAND
̲FILES, but only in one level. (No return to the
calling point).
4. Application process commands have the lowest priority.
5. Input from the operator is only received if there
is no other processing going on.
Figure 3.3.19.a…01…Processing of commands
Figure 3.3.19.b…01…Processing of commands
Figure 3.3.19.c…01…Processing of commands
Figure 3.3.19.d…01…Processing of commands
Figure 3.3.19.e…01…Processing of commands
Figure 3.3.19.f…01…Processing of commands
3.3.20 I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲ ̲o̲f̲ ̲t̲h̲e̲ ̲F̲I̲K̲S̲ ̲S̲y̲s̲t̲e̲m̲ ̲
3.3.20.1 B̲o̲o̲t̲ ̲L̲o̲a̲d̲i̲n̲g̲ ̲
The FIKS-system (user- and file processor) is bootloaded
by means of the FIKS BOOT LOADER, ref (15). After boot
load is finished, then the AMOS KERNEL data is initialized
and the ROOT-process is started as described in ref(1),
sec. 3.12.
In t̲h̲e̲ ̲F̲I̲K̲S̲ ̲u̲s̲e̲r̲-̲p̲r̲o̲c̲e̲s̲s̲o̲r̲ the ESP-process is the ROOT-process
and section 1 is used for KERNEL-data. The first task
to be executed by the ESP after boot load is the reorganizing
in the CR80-memory of the remaining modules included
in the boot module. In figure 3.3.20.1 is shown the
memory layout before and after the reorganizing. ESP
expects the modules to be either programs, processes
(data) or monitor-procedures. They shall obey the format
given in ref (1), appendix B, i.e. the standard AMOS-format.
The reorganizing is performed using the following directives:
- programs and monitor procedures are transferred
to TOP ̲OF ̲PAGE 0.
- processes are transferred to TOP ̲OF ̲PAGE 1.
- After the transference is done, the modules is
treated as if they were loaded from an ordinary
load file (name: BOOT ̲MODULE), ref. LOAD-command
sec. 3.3.9.
- Every process is STARTED.
Included in the boot module must be all necessary modules
for getting in contact with the disk system. I.e.
- IO-system, set of monitor procedures.
- DMA-driver, user-processor version.
- User - to file processor communications program
(USRFIL) - ref. sec. 3.2.2.7.
Figure 3.3.20.1…01…Reorganizing of Memory…01…(At Boot Load)
In t̲h̲e̲ ̲F̲I̲K̲S̲ ̲f̲i̲l̲e̲-̲p̲r̲o̲c̲e̲s̲s̲o̲r̲,̲ ̲the standard ROOT-process
(ref (1), sec. 3.13) is used to do the initializing.
All neeeded modules for executing of the processing
in the file-processor must be included in the boot
module. I.e.
- IO-system
- DMA-driver, file-processor version
- CDC-drivers
- FLOPPY-driver
- FMS-system (file management system)
- File - to user processor communications program
(FILUSR).
- + what the existance of the above mentioned modules
imply.
When the user- and fileprocessor has finished this
part of the initialization, then the disk system is
initial assigned (ref. sec. 3.3.4.4), so it can be
used. The further initialization will depend upon whether
the system is a Node/MEDE - or a SCC-installation.
N̲o̲d̲e̲/̲M̲E̲D̲E̲:̲
The operator is questioned via the printout on the
console.
* BRANCH + STATE
about which branch (ONE/TWO) that has been booted and
in what state the branch is going to be (ACTIVE/STANDBY).
This information is used to do the final disk assignment
- ref. sec. 3.3.4.4. The operator has then to key in
the DTG. The initialization is not allowed to continue
before an acceptable DTG is specified. Ref. sec. 3.3.9
- SET DTG - command.
S̲C̲C̲:
No specification of BRANCH or STATE is needed. The
operator is immediately asked to key in the DTG.
Further initialization can now continue.
3.3.20.2 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲ ̲t̲o̲ ̲A̲C̲T̲I̲V̲E̲
To do this, the SEQUENCE "TD ACTIVE" is used. I.e.
the COMMAND ̲FILE "ACTIVE" is used to get input commands
from. An example of an ACTIVE-file is given in appendix
7.1.a. The file must contain the following commands
in the listed order.
1. Loading and creating of all critical regions used
in the FIKS-system.
2. Loading of all monitor procedures used in the FIKS-system.
3. Initializing of all FIKS data areas. (MTCB-, QACCESS-
and RDF-areas). This is done by running a background
program with the command RUN ̲AND ̲DELAY, i.e. ESP
is halted while the initialization and memory allocation
takes place. Ref. to sec. 3.3.2 + 3.3.9-RY-command.
4. The CHECKPOINT-process is then loaded and started.
The process is used of the next module to be loaded.
5. The checkpoints, which are handled on system level
and shall be recovered, are now loaded. This is
done by running the background process SYSCHP with
the command RUN ̲AND ̲DELAY.- ref(22).
6 The task of resetting all the PDB-files is started
by starting the background process RESPDB - ref(23).
7. The TDX-drivers are loaded and started.
8. TDX-initialization is performed. Ref. sec. 3.3.5.1
9. The rest of the FIKS application programs and processes
are loaded and started. This must be performed
in such order, that when a process presumes the
existance of an other process, then this is not
started before the other is at least loaded (CREATED)
- possible AMOS-events might be lost as WILD ̲EVENTs.
Those processes that use the same program must
be loaded after each other.
10. When the ACTIVE-file is completed without occurrence
of local ESP-SWITCHOVER-errors, then the state
of the branch is set to ACTIVE, i.e. the alive
answer sent to the Watchdog will contain this state.
Ref(14).
3.3.20.3 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲ ̲t̲o̲ ̲S̲T̲A̲N̲D̲B̲Y̲ ̲
The SEQUENCE "TD STANDBY" is used in the same manner
as when initializing to ACTIVE. An example of a STANDBY-file
is given in appendix 7.1.b. The following listed points
correspond to those listed in sec. 3.3.20.2.
1. Same as ACTIVE.
2. Same as ACTIVE.
3. Same as ACTIVE.
4. Same as ACTIVE but the Checkpoint process is not
started.
5. Not performed.
6. Not performed.
7. TDX-drivers are not started.
8. Not performed
9. The rest of the FIKS-application-tasks, which are
not background tasks are loaded. The OLD-processes
(ref(24), which is a background task in the ACTIVE-state,
is loaded and started as ordinary program/processes
in the background-areas. The STFPWP-process (sec.
3.3.4.8) is also loaded and started in the background-areas.
10. At completion of the STANDBY-file, the state of
the system is set to STANDBY in the same manner
as when the ACTIVE-file was completed.
3.3.20.4 R̲E̲C̲O̲V̲E̲R̲/̲R̲E̲S̲T̲A̲R̲T̲ ̲o̲f̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲ ̲
If a Node/MEDE has a branch, that is STANDBY, this
branch can be made ACTIVE by running through the RECOVER-procedure.
The procedure is initiated by the operator command
RM (RECOVER ̲SYSTEM) or by a Watchdog command - ref.(14).
The procedure is performed as follows:
1. The disk-system goes through the initialization
procedure (ref. sec. 3.3.4.4) in the same manner
as if the branch was initializing to be ACTIVE.
I.e. the DISK ̲STATUS to be used after RECOVER is
determined at the moment of RECOVER (the one determined
at initializing to STANDBY is not used).
2. RESTART ̲FLAG in the critical region CONFIG is set.
ref(13), sec. 5.1.
3. The SEQUENCE "TD RECOVER" is initiated. The RECOVER-procedure
will then continue using commands from the RECOVER-command
file. An example of a RECOVER-file is given in
appendix 7.1.c.
4. The OLD- and STFPWD-processes are REMOVED. Ref.sec.
3.3.20.3 point 10.
5. The DTG of the STANDBY-branch is checked to be
consistent with the DTG used last time, the system
had an ACTIVE-branch. At SWITCHOVER of branches,
where the RECOVER-procedure is a part, the DTG
in the former ACTIVE ̲branch may have been set to
a much higher (newer) value. I.e. the DTG in the
STANDBY can no longer be used at ACTIVE-processing.
- ref.sec. 3.3.9 SG-command. To check for and handle
this situation the CHECK ̲AND ̲LOAD ̲DTG- command
is performed - ref.sec. 3.3.9.
6. The Checkpoint process is started.
7. The checkpoints to be loaded on system level is
loaded by running the background task SYSCHP (ref
22) with the command RY.
8. The MTCB- and QACCESS-areas are recovered by "RUN
̲AND ̲DELAY" the RECOVM-process - ref (25).
9. The preparation data base PDB in the FIKS-system
is recovered by "RUN ̲DELAY" the RECMES-process.Ref(26).
10. Every PDB-file that is not recovered (in use) is
RESAT by "RUN" the RESPDB-process. Ref (23).
11. The TDX-drivers are started.
12. The TDX-system is initialized. Ref. sec. 3.3.5.1.
13. The rest of the FIKS-applications is now started.
Processes are started if the application has been
loaded. If it is a background task, then it is
loaded and started. This must be done in an order
corresponding to that one used when initializing
to be ACTIVE. Ref. sec. 3.3.20.2, point 9.
14. The state of the system is changed to ACTIVE in
the same manner as in sec. 3.3.20.2, point 10.
3.3.20.5 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲C̲C̲ ̲
At SCC-installation no internal state (ACTIVE/STANDBY)
is used as at Node/MEDE-installations. The concept
ACTIVE/STANDBY-SCC has nothing to do with the initializing.
There exist different "ways" to start the SCC. Checkpoints
have to be loaded or not to be loaded (- /COLD) or
different "modes" in how the NICS TARE-interface is
handled, automatically or not automatically (-/MANUAL
̲NICS). The choice of way/mode is left to the system
operator, he shall key in the COMMAND-file to be used
at the initializing.
TD "name of COMMAND-file"
The COMMAND-file must follow the same directives as
the ACTIVE-file at Node/MEDE-installations. Possible
RECOVER-modules shall be executed in the same way as
in the RECOVER-file.
3.3.20.6 C̲L̲O̲S̲E̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲
When processing in a FIKS-system has to be stopped,
it is very important that "CLOSE of system" is performed
in a proper manner. It is expecially important, that
the processing concerning accessing of the disk system
is terminated in such a way that the logical coherence
of the disk system is maintained. The FIKS-system is
CLOSED with the command CM (CLOSE ̲SYSTEM). The procedure
initiated of the command is as follows:
1. At Node/MEDE-installations an AMOS-message is sent
to the SAF-process (ref (19) telling about the
becoming close down. ESP waits 10 seconds to allow
the information to slip out of the Node/MEDE (control
message to SCC) before it continues.
2. Every existing background process is REMOVED from
the system. When a process is REMOVED then MON
(IO, CLEANUP) is performed, i.e. outstanding IO-operations
are cancelled and any open file is DISMANTLED.
Ref (2), p 132.
3. The SEQUENCE 'TD CLOSE' is started, i.e. the COMMAND
̲FILE 'CLOSE' is used in the further processing.
See appendix 7.1 for an example of this file. The
file must contain REMOVE-commands of the rest of
the processes in the user processor except for
those included in the boot module. The order in
which they are REMOVED must be like this: If a
process presumes the existance of another, then
this one is REMOVED first - drivers are REMOVED
at last.
4. Those processes not REMOVED in the CLOSE-file and
which have not been included in the BOOT-module
is now REMOVED - normally none.
5. The ESP performs MON (IO, CLEAUP) of its own IO-processing.
6. The SEQUENCE "IOSYSTEM ̲CLOSE" is initiated. Volumes
are UPDATED, DEMOUNTED and disk units DEASSIGNED
and the FMS-users are logged off (USEROFF).
7. At last the whole system is MASTER ̲CLEARED. I.e.
- the red TDX-host is mastercleared
- the black TDX-host is mastercleared
(only in Node/MEDE-installations)
- a masterclear message is sent to the file-processor
(ref.sec. 3.2.2.7) and the user-processor is
mastercleared.
- in the file-processor the FILUSR-process waits
1 second (to ensure that diskoperations are
terminated) before it masterclears the file-processor.
- the system is now ready to be boot loaded.
If a fatal error (SWITCHOVER-errror) occurs in this
procedure (point 1-6) a jump to point 7 will be performed
immediately.
The CLOSE ̲SYSTEM-procedure may take considerable time
(2-4 minutes). Therefore it can not be used in connection
with a SWITCHOVER-procedure in the Node/MEDE-installation,
i.e. as action on the Watchdog close command - ref
(14). A QUICK ̲CLOSE-procedure exist for this purpose.
This procedure performs:
- UPDATE of volumes
- printout on the console
*QUICK CLOSE
- master clear of the system (point 7).
The procedure can be initiated by the operator by keying
in CTRL/A + 1 (Simulation of Watchdog command).
3.3.21 E̲n̲a̲b̲l̲i̲n̲g̲/̲D̲i̲s̲a̲b̲l̲i̲n̲g̲ ̲o̲f̲ ̲B̲o̲o̲t̲m̲o̲d̲u̲l̲e̲
At certain occasions an operational system different
from the FIKS operational system can be used in a FIKS
computer installation (offline states such as TOS,
hardware tests, disk backup, etc.). If these states
could be entered without any control, they would make
out a security risk. This must be avoided.
The "key" to the offline states are the bootmodules
loaded by the FIKS boot loader (ref. 15). If it is
not possible to bootload these modules, then it is
not possible to enter the offline states. This is in
a FIKS operational computer installation performed
by assuring that the checksum placed in word 4 of the
affected bootmodule is not correct - the bootloader
will not execute the load command. The bootmodule is
disabled. The bootmodule can be enabled by correcting
the checksum. This is in fact what is performed when
the enable/disable bootmodule commands are used (ref.
sec. 3.2.2.4).
3.3.22…02…S̲e̲t̲ ̲S̲C̲C̲ ̲S̲u̲p̲e̲v̲i̲s̲o̲r̲ ̲P̲a̲s̲s̲w̲o̲r̲d̲s̲
The 'SET ̲SCC ̲SUPERVISOR ̲PASSWORDS' (SD) command is
used to (at the local SCC) to clear the USP-file and
instead insert a new (single) SCC supervisor profile.
(ref(13), sec. 11.5). The USER-ID, PASSWORD and SH-PASSWORD
are keyed-in by the system console operator, ref. 3.2.2.4
for details. The passwords are scrambled (by use of
the SPA-process, ref(29), sec. 3.3.2) before they are
written into the USP-file. The user type/classification
are automaticly sat to supervisor / cosmic top secret.
No 'local password maintenance' must go on when the
USP-file is updated. This is ensured when the SCC-supervisor
is not LOGGED ON. This is equivalent to that word 0
in the critical region XTCBCR is 0. If not then the
operator is advised to see to that the supervisor is
LOGGED OFF with printout of the system remark:'* LOGOFF
SCC-SUP'.
The USP-file is updated/resat analogous to that performed
by the SAF/TUP-processes at USP-maintenance ref(19),
sec 3.3.17.3.
Refer also to ref(29) for further details.
3.3.23 S̲y̲s̲t̲e̲m̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
As mentioned in sec. 3.3.10 a wide range of commands/utilities
exists which can be used by a system operator. Some
of these commands ("Safety Commands") make out a security
risk, e.g. inspection of classified data. The use of
these commands must be controlled.
The use of the safety commands is disabled/enabled
by manipulating with the KEY ̲WORD ̲CODES in the COMMAND
̲WORD-table, ref. Figure 3.3.8. A command is disabled
when the corresponding KEY ̲WORD ̲CODE points at a "dummy"
command that only prints out the remark:
* SECURITY VIOLATION
followed by an ESP local error report which uniquely
determines the case. (The error report is needed to
be sure that the case is reported independent of Watchdog
console mode, ref. (14)). The commands are enabled
by updating the KEY ̲WORD ̲CODE with the proper value.
The system handles two types of safety system operators:
SYS and TEKN. (besides the ordinary operator). SYS
is the maintainer/debugger of the system and shall
have access to all commands. TEKN is the technician
and shall only have access to those commands that are
concerned with hardware maintenance/testing. To each
type of system safety operator is allocated a SAFETY
̲COMMAND-list and a PASSWORD, both implemented in the
SECURITY ̲OVL-code (ref. sec. 3.3.23). When system security
mode is entered by use of the "EE"-command a password
has to be keyed in (ref. sec. 3.2.2.4). The system
will check if the password is one of the two possible.
If hit then COMMAND ̲WORD-table is updated on basis
of the corresponding SAFETY ̲COMMAND-list. When security
mode is left, then all safety commands are disabled
(on basis of SYS SAFETY ̲COMMAND-list).
The password can be changed by keying in the new password,
after the old one is keyed in (same concept as used
in the TOS-system). As the keying in of passwords is
never echoed on the console, a control of the new password
is performed by letting the operator repeat it before
it takes effect. The new password is scramled by use
of the SPA-process (ref(29),sec. 3.3.2, 3.3.3) and
written into the SECURITY ̲OVL-code.
Besides the real utility commands the LOAD-, RUN- and
RUN ̲DELAY-commands make out a security risk (they can
be used to load unauthorized software modules). They
must be disabled when not needed. They are used when
FIKS is in the initializing/recovering phases. When
an initializing phase has finished, they are disabled
with the "LE"-command as the last command in the corresponding
command file. Before the recovery phase is started,
the needed commands LOAD, RUN are enabled by the ESP
code.
A list of the safety commands with specification of
when they are enabled/disabled is given in table 3.3.23-1.
FIKS SYSTEM SECURITY COMMANDS STATE TRANSITION
^AT BOOT^AFTER ^AFTER " EE" ^AT
RE-
^
̲C̲O̲M̲M̲A̲N̲D̲ ̲^̲L̲O̲A̲D̲I̲N̲G̲^̲"̲ ̲ ̲L̲E̲"̲ ̲^̲ ̲S̲Y̲S̲ ̲ ̲ ̲^̲ ̲T̲E̲K̲N̲ ̲ ̲^̲C̲O̲V̲E̲R̲Y̲ ̲^̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^ ^ ^ ^
LD ^ + ^ - ^ + ^ - ^
- ^Load
into
memory
^ ^ ^ ^ ^ ^
RN ^ + ^ - ^ + ^ + ^
+ ^Run
background
task
^ ^ ^ ^ ^ ^
RY ^ + ^ - ^ + ^ - ^
+ ^Run
and
delay
^ ^ ^ ^ ^ ^background
task
DY ^ - ^ - ^ + ^ - ^
- ^Dump
whole
memory
^ ^ ^ ^ ^ ^
QM ^ - ^ - ^ + ^ - ^
- ^Qaccess/MTCB
utility
^ ^ ^ ^ ^ ^
DG ^ - ^ - ^ + ^ - ^
- ^Debug
(in
memory)
^ ^ ^ ^ ^ ^utility
IT ^ - ^ - ^ + ^ - ^
- ^Inspect
(of
files)
^ ^ ^ ^ ^ ^utility
FY ^ - ^ - ^ + ^ + ^
- ^Floppy
dump/load
^ ^ ^ ^ ^ ^
EP ^ - ^ - ^ + ^ - ^
- ^Manual
error
dump
^ ^ ^ ^ ^ ^
EB ^ - ^ - ^ + ^ + ^
- ^Enable
boot
module
^ ^ ^ ^ ^ ^
SD ^ - ^ - ^ + ^ - ^
- ^Set
SCC
supervisor
^ ^ ^ ^ ^ ^passwords
---------^-------^-------^-------^-------^-------^--------------------
EE ^ + ^ + ^ + ^ + ^
+ ^Enter
security
mode
^ ^ ^ ^ ^ ^
LE ^ + ^ + ^ + ^ + ^
+ ^Leave
security
mode
L̲e̲g̲e̲n̲d̲ "-": Command not allowed
"+": Command allowed
Table 3.3.23-1
D̲i̲f̲f̲e̲r̲e̲n̲t̲ ̲E̲S̲P̲-̲v̲e̲r̲s̲i̲o̲n̲s̲
The source code for the different versions of the modules
included in the ESP-system is contained in the same
source, using conditional compilation statements. Source
updating needs then only to be done at one place independent
of version. The version compiled depends on the content
of the file COMP.SWITCH. This contains only a compiler
switch stating the type of version. In this way one
or both version can be generated automatically.
G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲ ̲O̲F̲ ̲B̲O̲O̲T̲-̲M̲O̲D̲U̲L̲E̲S̲
The ESP is included in the BOOT-module. This module
is created by means of the system generator program
SYSGEN and the AMOS BOOT file generator. Refer to:
CR80 AMOS SYSGEN, Users Manual,
CSS/121/USM/0023
CR80 UTILITY DBOOT, Users Manual,
CSS/394/USM/0081.
To produce the BOOT-modules do as stated in the INFORMATION-file
in the last FIXLIB-delivery of
FIKS ̲USER ̲BOOT.D - directory
-generation of BOOT-module to Userprocessor.
FIKS ̲FILE ̲BOOT.D - directory
-generation of BOOT-module to fileprocessor.
3.3.24 E̲S̲P̲-̲o̲v̲e̲r̲l̲a̲y̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲
There are certain tasks in the ESP-processing, that
are only to be executed occasionally and have low priority.
To avoid excessive demand of CR80-memory for ESP-code
a OVERLAY-scheme has been implemented for use in the
ESP-processing. The OVERLAY-part of the ESP-code can
be exchanged when need for it arises. This part is
from XSTART (entry point for program, ref (1), appendix
B) in the initial loaded ESP-program (ESP ̲INIT) until
end-of-code. The rest of the code remains unchanged.
The code to be exchanged has been stored in the ESP
̲OVL.D-directory as individual code files. The loading
of an ESP-overlay is performed of the ESP-process itself
by using the routines, that already exist for loading
of FIKS-programs (note: the FIKS OVERLAY- monitor procedure
is not used). When loading has been done, a jump to
OVERLAY ̲ENTRY is performed and the overlay code is
carried out.
The ESP-overlays are created on basis of a series of
logical different ESP-programs. These programs contain
the same code until XSTART (PROCEDURES), after this
is placed the overlay code (MAINPROGRAM). The OVERLAY
̲ENTRY for an overlay is XSTART for the corresponding
program. The scheme is illustrated in figure 3.3.24.
There are some points to take into consideration when
using this scheme:
- No ESP-code, that may be used, when there is no
access to the disk system, can be placed in overlays
- No ESP-overlay can be greater than the first overlay
(ESP ̲INIT ̲OVL).
- It is mandatory that the ESP-overlays is created
on the same version of ESP-code. The common code
part and the process data must not be understood
differently seen from the overlay.
Figure 3.3.24…01…ESP-Overlay Scheme
3.3.25 T̲r̲a̲n̲s̲f̲e̲r̲ ̲i̲n̲ ̲M̲e̲m̲o̲r̲y̲ ̲
At several cases the ESP makes transfers of data around
in the CR80-memory. When doing this some precautions
must be taken.
- if a context switching occurs, while another memory
page than where the BASE is placed, is accessed,
then severe damage may happen. Therefore CPU-,
IO- and Real Time interrupt must be disabled when
doing this.
- when a non-existing memory location is accessed,
a TIMEOUT on the mainbus will be the result. KERNEL
is invoked via the LOCAL ̲ACTION address and a MON(ERROR)-call
is executed. This will result in a LOCAL ESP error
report with error code equal to #103. (ref. sec.
3.3.17).
The procedure TRANSFER ̲MEMORY handles the different
transferences in the memory. The procedure is called
with a reference to a MEMORY ̲TRANSFER ̲ELEMENT defined
below.
M̲E̲M̲O̲R̲Y̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲ ̲E̲L̲E̲M̲E̲N̲T̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Location from Word 0
Page from 1
Location to 2
Page to 3
No of words to transfer 4
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3.4 D̲A̲T̲A̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲ ̲
3.4.1 I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲ ̲
In the following is listed those data structures used
internal by the ESP-system and for which the definition
and use may not be obvious.
3.4.1.1 C̲O̲N̲S̲O̲L̲ ̲-̲ ̲p̲r̲o̲c̲e̲s̲s̲ ̲
This process is placed inside the ESP-process-data.
The process is not layed out by use of system utilities
(compiler/linker). Therefore the process, including
the PROCESS ̲HEADER, PROCESS ̲DESCRIPTOR, data-area and
IO-data-area must be declared and initialized as ESP-variables
in the ESP-process. Special measures have to be taken
to ensure that the rule about BASE/PRIORITY stated
ref (1), p 87 is fulfilled (- insertion of DUMMIES).
The purpose of using this implementation is to allow
ESP and CONSOL to access each others data-areas directly.
3.4.1.2 C̲O̲M̲M̲A̲N̲D̲-̲O̲V̲E̲R̲L̲A̲Y̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
When a command is keyed in, this is translated via
the table COMMAND ̲WORDS to a symbolic COMMAND ̲ID (=
equal entry number). Some commands are executed in
an ESP-overlay. These commands must be placed in the
latter part of the table. I.e. if the COMMAND ̲ID is
greater than or equal to the first OVERLAY ̲COMMAND
̲ID then the command is an OVERLAY ̲COMMAND. Which overlay
that is to be loaded is determined via the COMMAND
̲ID to OVERLAY ̲ID translation table OVERLAY ̲IDS. The
OVERLAY ̲ID is used to construct the name of the overlay
code-file to be loaded.
Example
A command RUN ̲AND ̲DELAY (RY) is issued. This command
is an OVERLAY ̲COMMAND. At lookup in the OVERLAY ̲IDS-table
is found that the command RY corresponds to the OVERLAY
̲
-ID = BG ̲PROC1 ̲OVL ̲ID (=3). Name of code-file to be
loaded is then
'ESP ̲OVL.X.C', where 'X' = 'A' + BG ̲PROC1 ̲OVL ̲ID, i.e.
'ESP ̲OVL.D.C'
3.4.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
The following external data structures accessed in
the ESP-system, shall be known by the maintainer of
the ESP.
1. KERNEL data structures,
ref(1), KERNEL-sourcelisting.
2. System software structures -
AMOS events, IO-user-data structures
ref(1) + ref(2).
3. Watchdog Interface -
ref(14), sec. 3.2.
4. ESP to SAF AMOS-messages
ref(19)
5. CHECKP ̲FILE,
ref(13), sec. 11.12
6. SRS ̲CHECKP-file,
ref(20)
3.4.3 B̲G̲P̲S̲-̲F̲I̲L̲E̲
The file with name BGPS ̲FILE placed on the volume FIXHEAD
in the maindirectory is used of the background management
to store/retrieve the background programs/processes
- ref. sec. 3.3.15. It is of fixed size and contigious
organization. It is generated with the filegenerator
program 'BGPS ̲FILE.C'. It is only accessed of the ESP-process.
The layout is shown in fig. 3.4.3.
Figure 3.4.3…01…Layout of BGPS ̲FILE
3.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲ ̲
The modules included in the ESP-system (version 0415)
have the following memory claims (approximately) in
words.
…02……02……02……02……02…Node/MEDE- , SCC-version
ESP-program: 3940 , 3590
ESP-process: 3200 , 3260
As the CONSOL-process is placed inside the ESP, then
they make no additional memory claims.
USRFIL-program: 75
USRFIL-process: 78
FILUSR-program: 230
FILUSR-process: 103
(in the file-procesor)
STFPWD-program: 31
STFPWD-process: 146
(in the STANDBY-branch
DULDSK-program: 225
DULDSK-process: 266
(Intended to be executed as background process, i.e.
it makes no additional memory claim).
3.6 P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲ ̲
Most of the ESP-processing is concerned with the initializing
of a system. The performance of this processing is
only of vital interest when a Node/MEDE branch is to
be recovered, in which case the processing shall be
executed as quick as possible. The limitation in doing
this is the execution of the IO-procedures - loading
of processes and especially the initializing of the
TDX-system. If the processing shall be optimized, then
the first thing to look upon must be these procedures.
3.7 L̲I̲M̲I̲T̲A̲T̲I̲O̲N̲S̲ ̲
The following vital resource limitations shall be noticed:
M̲A̲X̲-̲N̲O̲-̲O̲F̲-̲B̲G̲T̲,̲ i.e. the maximum number of background
processes that can be executing at the same time.
M̲A̲X̲-̲S̲I̲Z̲E̲-̲B̲G̲P̲M̲,̲ i.e. the maximum size of a background
program area.
M̲A̲X̲-̲S̲I̲Z̲E̲-̲B̲G̲P̲S̲,̲ i.e. the maximum size of a background
process area.
S̲C̲M̲-̲B̲U̲F̲F̲E̲R̲-̲L̲E̲N̲G̲T̲H̲, i.e. the maximum of characters,
that can be held in the CONSOL input buffer.
All the limitations mentioned above can easily be modified.
3.8 E̲R̲R̲O̲R̲ ̲L̲O̲C̲A̲T̲I̲O̲N̲S̲
LABEL RAISED BY (CALL OF) COMMENT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
101 * SYNTAX ERROR Incorrect command
line
102 * LOAD ERROR Impossible LOAD-command
103 * SECURITY VIOLATION Operator password
not keyed in
104 * SYNTAX ERROR (WD) Incorrect Watchdog
command
600 CDC-message timeout No answer from CDC-driver
701 MON(CREATEPROCESS) Note separate error
codes
702 MON(LOOKUPPROCESS) Error code = #FFFF
703 MON(STARTPROCESS) - " - - " -
704 MON(REMOVEPROCESS) - " - - " -
705 MON(STARTPROCESS) - " - - " -
711 MON(IDENTIFYSENDER) - " - - " -
900 MON(IO,LOOKUP) of ESP-overlay-directory,
901 MON(IO,DISMANTLE) of System-directory
(FIX ̲CONFIG.D)
903 MON(IO,DISMANTLE) of Load-file
904 MON(IO,DISMANTLE) of Command-file.
911 MON(IO,USERON)
912 MON(IO,USEROFF)
921 MON(IO,ASSIGNDUAL) at dual assignment
922 MON(IO,ASSIGN) at single assignment
(CDC-disks)
923 MON(IO,ASSIGN) at assignment of
FLOPPY-device.
931 MON(IO,DEASSIGN)
LABEL RAISED BY (CALL OF) COMMENT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
941 MON(IO,DISCARD)
942 MON(IO,STARTUDALIZE)
943 MON(IO,FINISHDUALIZE)
951 MON(IO,MOUNT)
961 MON(IO,DISMOUNT)
971 MON(IO,UPDATE)
981 MON(IO,GETROOT) new system directory
982 MON(IO,DESCENT) - " -
991 MON(IO,LOOKUP) of Load-file
992 MON(IO,GETFILEINFO) - " -
993 MON(IO,READBYTES) from Load-file
994 Uneven no of bytes of Load-file - must
be even
996 MON(IO,LOOKUP) of Command-file
997 MON(IO,GETFILEINFO) - " -
998 MON(IO,READBYTES) from Command-file
LABEL RAISED BY (CALL OF) COMMENT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1000 MON(IO,GETROOT) of FIXHEAD
1001 MON(IO,DESCENT) Lookup of CHECK ̲FILE-
1002 MON(IO,READBYTES) from CHECKP ̲FILE
1003 MON(IO,MODIFYBYTES) in CHECKP ̲FILE
1101 MON(REGION,CREATE)
1111 MON(REGION,RENTER) CONFIG
1112 MON(REGION,RLEAVE) CONFIG
1121 MON(REGION, RPUT) in CONFIG
1131 MON(REGION, RPUTN) in CONFIG
1132 MON(REGION,RCOPYN) from CONFIG
S̲e̲t̲t̲i̲n̲g̲ ̲o̲f̲ ̲D̲T̲G̲
7501 MON(IO,GETROOT) of FIXHEAD
7502 MON(IO,DESCENT) to SRS ̲CHECKP-file
7503 MON(IO,READBYTES) from SRS ̲CHECK-file
7504 MON(IO,DISMANTLE) of SRS ̲CHECKP-file
at SCC-installations
SRS ̲CHECKP shall
be exchanged with
CHECK ̲FILE
7506 MON(IO,READBYTES) from CHECK ̲FILE.
7507 DTG SYNCHRONIZED at CHECK ̲DTG
7508 DTG TOO BIG at LOAD ̲DTG
LABEL RAISED BY (CALL OF) COMMENT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
T̲D̲X̲-̲s̲y̲s̲t̲e̲m̲
7661 MON(IO,ASSIGN) of red TDX-host
7662 MON(IO,ASSIGN) of black TDX-host
7671 MON(IO,GETROOT) of MOVHEAD
7672 MON(IO,DISMANTLE) of a *MOVHEAD*MD
7777 DATA INCONSISTENCE of KERNEL-data
7778 DISK INCONSISTENCE no availlable disk
7779 TIMEOUT ON DMA USRFIL-FILUSR-link
77XX MEMORY ̲DUMP ̲UTILITY ref. to source listings
B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
7801 MON(IO,GETROOT) of FIXHEAD
7802 MON(IO,DESCENT) lookup of a * FIXHEAD*BGPS
̲FILE
7803 MON(IO,READBYTES) from BGPS ̲FILE
7804 MON(IO,MODIFYBYTES) in BGPS ̲FILE
80XX INSPECT ̲UTILITY ref. to source listings
86XX SET USP (at SCC) ref. to source listings
87XX ERROR ̲DUMP ̲UTILITY ref. to source listings
88XX FLOPPY ̲DUMP ̲UTILITY ref. to source listings
89XX ENABLE/DISABLE BOOTM. ref. to source listings
90XX ENTER/LEAVE SECURITY ref. to source listings
f̲r̲o̲m̲ ̲C̲O̲N̲S̲O̲L̲ ̲
#FFFF CONSOL ̲BUFFER ̲OVERFLOW Local fix up
3.9 L̲I̲S̲T̲I̲N̲G̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲
Source listings and linker list may be obtained from
FIXLIB. Ref. to SCCLDD.
4 Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲ ̲
4.1 Q̲U̲A̲L̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲ ̲T̲E̲S̲T̲S̲
The ESP-system has been tested at different levels:
M̲o̲d̲u̲l̲e̲ ̲t̲e̲s̲t̲:̲ Refer to
Test Report for ESP non-dualized,
FIX/1105/TRP/0043.
I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲t̲e̲s̲t̲:̲ Refer to
Test Report for I150 Dual N/M Integration, FIX/1000/TRP/0066.
S̲y̲s̲t̲e̲m̲ ̲i̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲t̲e̲s̲t̲:̲ Refer to
System Test Report for 3080,
FIX/0000/TRP/0089
4.2 O̲T̲H̲E̲R̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲ ̲P̲R̲O̲V̲I̲S̲I̲O̲N̲S̲
The FIKS-system can not operate without a correct acting
ESP-system. Therefore by ordinary use of the FIKS-system
for testing it is shown that the ESP-system fulfils
its capabilities.
5 P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲S̲ ̲F̲O̲R̲ ̲D̲E̲L̲I̲V̲E̲R̲Y̲
Do as stated in file 'INFORMATION' in the last delivery
of the ESP-directory to FIXLIB.
N̲o̲t̲e̲:̲ As parts of the ESP-system are included in the
BOOT-modules, it is necessary to generate a new BOOT-
module, if executable code shall be delivered. If so,
do as stated in file 'INFORMATION' in the last delivery
of FIKS ̲USER ̲BOOT-directory to FIXLIB.
6 N̲O̲T̲E̲S̲
6.1 M̲O̲D̲U̲L̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
Every module in the ESP-system is compiled by means
of the SWELL Compiler and linked by means of the AMOS
linker. Refer to
SWELL 80, Reference Manual,
CSS/415/RFM/0002
CR80 AMOS, SWELL Compiler, Users Manual, CSS/415/USM/0047.
CR80 AMOS, Linker, Reference Manual,
CSS/416/RFM/0003.
CR80 AMOS, Linker, Users Manual;
CSS/416/USM/0048.
To perform the compilation and linking of the modules
do as stated in the INFORMATION-file in the last FIXLIB-delivery
of the ESP.
6.2 E̲S̲P̲-̲U̲T̲I̲L̲ ̲ ̲P̲R̲O̲G̲R̲A̲M̲
When the ESP is compiled and linked, then there exist
an ESP-code file for each ESP-overlay. These code files
have to be brought into a form where they can be used.
This conversion is performed of the ESP ̲UTIL-program.
G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲O̲O̲T̲-̲m̲o̲d̲u̲l̲e̲
The ESP ̲INIT-code file shall be converted to a ROOT-module.
When it is outputted from the linker, then it is formatted
as the "Assembly Time Object" in ref.(1), Appendix
B, figure B.3. A ROOT-module has the process-part first
followed by the program-part. Location #25 of the process-part
(Register 7) contains the start location (XSTART).
ESP ̲UTIL performs the needed conversion, - linker output
= ESP ̲INIT.C = ESP ̲UTIL-input, ESP ̲UTIL-output = ESP
̲INIT.CV = ROOT-module.
G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲E̲S̲P̲-̲o̲v̲e̲r̲l̲a̲y̲s̲
(ref. sec. 3.3.24)
Each ESP-overlay code file are converted as follows.
The program header (which contains OVERLAY ̲ENTRY) and
the code part from XSTARTO (= OVERLAY ̲START from ESP
̲INIT-code) until end of program part are put together
in one code file placed in the ESP ̲OVL.D-directory
with name corresponding to the OVERLAY ̲ID.
If an overlay is too big (or ESP ̲INIT-code too little),
then ESP ̲UTIL-terminates with (errorcode, errorlocation)
= (#AAAA, OVERLAY ̲ID).
ESP ̲UTIL needs only updating in case the number of
ESP-overlays is changed. For detailed information refer
to the source listings.
6.3 D̲i̲f̲f̲e̲r̲e̲n̲t̲ ̲E̲S̲P̲-̲V̲e̲r̲s̲i̲o̲n̲s̲
The source code for the different version of the modules
included in the ESP-system is contained in the same
source, using conditional compilation statements. Source
updating needs then only to be done at one place independent
of version. The version compiled depends on the content
of the file COMP.SWITCH. This contains only a compiler
switch stating the type of version. In this way one
or both version can be generated automatically.
6.4 G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲ ̲O̲F̲ ̲B̲O̲O̲T̲-̲M̲O̲D̲U̲L̲E̲S̲
The ESP is included in the BOOT-module. This module
is created by means of the system generator program
SYSGEN and the AMOS BOOT file generator. Refer to:
CR80 AMOS SYSGEN, Users Manual,
CSS/121/USM/0023
CR80 UTILITY DBOOT, Users Manual,
CSS/394/USM/0081.
To produce the BOOT-modules do as stated in the INFORMATION-file
in the last FIXLIB-delivery of
FIKS ̲USER ̲BOOT.D - directory
-generation of BOOT-module to Userprocessor.
FIKS ̲FILE ̲BOOT.D - directory
-generation of BOOT-module to fileprocessor.
A̲p̲p̲e̲n̲d̲i̲x̲ ̲7̲.̲1̲.̲a̲ ̲-̲ ̲E̲x̲a̲m̲p̲l̲e̲ ̲A̲C̲T̲I̲V̲E̲-̲f̲i̲l̲e̲
A̲p̲p̲e̲n̲d̲i̲x̲ ̲7̲.̲1̲.̲a̲ ̲-̲ ̲E̲x̲a̲m̲p̲l̲e̲ ̲A̲C̲T̲I̲V̲E̲-̲f̲i̲l̲e̲ (cont'd)
A̲p̲p̲e̲n̲d̲i̲x̲ ̲7̲.̲1̲.̲b̲ ̲-̲ ̲E̲x̲a̲m̲p̲l̲e̲ ̲S̲T̲A̲N̲D̲B̲Y̲-̲f̲i̲l̲e̲
A̲p̲p̲e̲n̲d̲i̲x̲ ̲7̲.̲1̲.̲b̲ ̲-̲ ̲E̲x̲a̲m̲p̲l̲e̲ ̲S̲T̲A̲N̲D̲B̲Y̲-̲f̲i̲l̲e̲ ̲(̲c̲o̲n̲t̲'̲d̲)̲
A̲p̲p̲e̲n̲d̲i̲x̲ ̲7̲.̲1̲.̲c̲ ̲-̲ ̲E̲x̲a̲m̲p̲l̲e̲ ̲R̲E̲C̲O̲V̲E̲R̲-̲f̲i̲l̲e̲
A̲p̲p̲e̲n̲d̲i̲x̲ ̲7̲.̲1̲.̲d̲ ̲-̲ ̲E̲x̲a̲m̲p̲l̲e̲ ̲C̲L̲O̲S̲E̲-̲f̲i̲l̲e̲
APPENDIX 7.2
APPENDIX 7.2
APPENDIX 7.2
APPENDIX 7.2
APPENDIX 7.2
DCN's needed to get the document
CR80 AMOS KERNEL,
CSS/802/PSP/0008, issue 2
to confirm with the KERNEL used by the FIKS system.
