top - download
⟦1f72b29cc⟧ Wang Wps File
Length: 30093 (0x758d)
Types: Wang Wps File
Notes: FIX/0000/PRO/0002
Names: »3862A «
Derivation
└─⟦a0a781934⟧ Bits:30006149 8" Wang WCS floppy, CR 0333A
└─ ⟦this⟧ »3862A «
WangText
…1e……05……1e……07……1d……0e……1d…
…1d……07……1c……09……1c……0a……1c……0d……1c……00……1c…
…1c……06……1b……09……1b……0d……1b……01……1b……02……86…1
…02…
…02…
…02…
3862A/jaa…02…FIX/0000/PRO/0002
…02…OK/830712…02……02…#
FIKS SYSTEM
GENERATION
PROCEDURE…02……02…FK
7809
…0f… FIKS SYSTEM GENERATION PROCEDURE
FIX/0000/PRO/0002
Ove Kaastrup
Carl H]gstedt
AMC (6)
CR (3)
FILE (2)
FIKS Manager 830712
1
830712…0e…
3862A/jaa …02…FIX/0000/PRO/0002
…02…OK/830712…02……02…R
FIKS SYSTEM GENERATION PROCEDURE
…02……02…FK 7809
830712 All Issue 1 of Document
3862A/jaa…02…FIX/0000/PRO/0008
FIKS SYSTEM GENERATION PROCEDURE …02…OK/830712…02……02…i
…02……02…FK 7809
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S
1 SCOPE ........................................... 0001
1.1 INTRODUCTION ................................ 0001
1.2 ABBREVIATIONS ............................... 0003
2 APPLICABLE DOCUMENTS ............................ 0004
3 PROGRAM MODULE GENERATION ....................... 0007
3.1 PROGRAM LIBRARIES ........................... 0007
3.2 OBJECT CODE GENERATION ...................... 0008
3.2.1 SWELL MODULE GENERATION ................. 0009
3.2.2 ASSEMBLER MODULE GENERATION ............. 0010
3.2.3 BOOT MODULE GENERATION .................. 0012
3.2.4 APPLICATION FILE GENERATION ............. 0013
4 TRIMMING FACILITIES ............................. 0015
4.1 TRIMMING OF PROGRAM MODULES ................. 0015
4.1.1 COMPILATION TIME TRIMMING ............... 0015
4.1.2 LINK TIME TRIMMING ...................... 0015
4.2 SYSTEM TRIMMING ............................. 0018
4.2.1 TRIMMING OF SYSTEM RESOURCES ............ 0018
4.2.2 TRIMMING OF TERMINAL PARAMETERS ......... 0019
4.2.3 TRIMMING OF USER PROFILES ............... 0020
4.2.4 TRIMMING OF ADDRESSING SCHEME ........... 0020
4.2.5 NETWORK CONFIGURATION TRIMMING .......... 0020
3862A/jaa…02…FIX/0000/PRO/0008
FIKS SYSTEM GENERATION PROCEDURE …02…OK/830712…02……02…ii
…02……02…FK 7809
5 DISK STORAGE .................................... 0021
5.1 DISK INITIALIZATION ......................... 0022
5.2 DISK LAYOUT ................................. 0024
5.3 PROTECTIONS OF DISK FILES ................... 0031
5.4 FILE ORGANIZATIONS .......................... 0032
6 S/W INSTALLATION PROCEDURES ..................... 0033
6.1 S/W MODULES AND DATA FILES .................. 0033
6.2 BOOT MODULES ................................ 0035
APPENDIX I ...................................... 0036
APPENDIX II ..................................... 0038
APPENDIX III .................................... 0039
APPENDIX IV ..................................... 0040
APPENDIX V ...................................... 0042
1 S̲C̲O̲P̲E̲
This document describes the FIKS System Generation Procedure, and is meant as a guideline
for FIKS S/W Programmers, when implementing additional S/W modules or changes.
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The key purposes of this document are to describe:
. the way from source to executable object code
. the generation of boot modules
. the generation of configuration - and constant files and tables
. the organization of files and directories on the target volumes
. the installation of object code and boot modules on the target volume.
The generation of object code, boot modules etc., are performed in a TOS/CMI Software Environment.
Besides the TOS (ref.1) and CMI (ref.2) the programmers involved in the system generation
should be familiar with the following CR80 utility programs, which are prerequisite in the
system generation procedure:
T̲e̲x̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲
. ONLINE EDITOR (ref.3)
. MERGE (ref.4)
L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲:̲
. ASSEMBLER (ref.5)
. SWELL (ref.6)
. LINKER (ref.7)
S̲y̲s̲t̲e̲m̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲:̲
. SYSGEN (ref.9)
. BOOT (ref.17)
. DISKINIT (ref.16)
. COPY (ref.10)
. DCOPY (ref.11)
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Please refer to ref. 19, chapt. 1.2
2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
The following documents are referenced herein or otherwise contains relevent information.
1. CR80 AMOS,TOS
USERS MANUAL
CSS/380/USM/0026
2. CR80 AMOS, CMI
USERS MANUAL
CSS/381/USM/0037
3. CR80 AMOS, ONLINE EDITOR
USERS MANUAL
CSS/102/USM/0021
4. CR80 AMOS, MERGE
USERS MANUAL
CSS/142/USM/0024
5. CR80 AMOS, ASSEMBLER
USERS MANUAL
CSS/401/USM/0042
6. CR80 AMOS, SWELL Compiler
USERS MANUAL
CSS/415/USM/0047
7. CR80 AMOS, LINKER
USERS MANUAL
CSS/416/USM/0048
8. CR80 AMOS, Directory Utilities
USERS MANUAL
CSS/932/USM/0036
9. CR80 AMOS, SYSGEN
USERS MANUAL
CSS/121/USM/0023
10. CR80 AMOS, COPY
USERS MANUAL
CSS/110/USM/0032
11. CR80 AMOS, DCOPY
USERS MANUAL
CSS/111/USM/0050
12. CR80 AMOS, KERNEL
PRODUCT SPECIFICATION
CSS/302/PSP/0008
13. CR80 AMOS, IO SYSTEM
PRODUCT SPECIFICATION
CSS/006/PSP/0006
14. CR80 AMOS, FMS
PRODUCT SPECIFICTION
CSS/920/PSP/0048
15. CR80 AMOS, FILE MANAGEMENT SYSTEM
SYSTEM PRODUCT SPECIFICATION
CSS/920/SPS/0001
16. CR80 AMOS
DISK INITIALIZATION PROGRAM
CSS/930/USM/0034
17. CR80 AMOS
BOOT, USER MANUAL
18. FIKS S/W CONFIGURATION CONTROL
LIBRARY DESCRIPTION DOCUMENT
FIX/1000/EWP/0080
19. FIKS DATA I/F REFERENCE MANUAL
FIX/0100/MAN/0004
20. FIKS FILE GENERATORS PSP
FIX/1200/PSP/0042
21. ESP SYSTEM PSP
FIX/1105/PSP/0046
22. DISK SALVATION PROGRAM
FIX/931/USM/0035
23. S/W CONFIGURATION CONTROL VDD
FIX/1000/VDD/007-016
3 P̲R̲O̲G̲R̲A̲M̲ ̲M̲O̲D̲U̲L̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
3.1 P̲R̲O̲G̲R̲A̲M̲ ̲L̲I̲B̲R̲A̲R̲I̲E̲S̲
The FIKS Software Library is delivered into two 80M bytes disk packages, both named FIXLIB.
Disk one contains:
FIX ̲SOURCE.D (Source code necessary to generate object code files for FIKS
Programs)
FIX ̲CODE.D (Object code files of FIKS programs, ready for installation)
Disk two contains:
CONST ̲FILES.D (Source code for generating file generators for constant files)
CONFIG ̲FILES.D (Includes configuration files and the source code necessary to
generate file generators used to generate configuraton files)
MSG ̲LOG ̲FILES.D (Source code of constant file generators)
For detailed information about the FIXLIB volumes, please refer to the library description
document (ref.18).
3.2 O̲B̲J̲E̲C̲T̲ ̲C̲O̲D̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
The Program Modules in FIKS are subject to one of the following module generation procedures:
. SWELL Module Generation
. Assembler Module Generation.
With a few exceptions all application progrms are coded in SWELL Language.
The exceptions are:
on N/M: TIMER, NSS, SWD, SPM, ISHRTC
on SCC: TIMER, NSS, CWD, CPM, ISHRTC, MAS, MON, IOMP, EDC, SIMLTU.
BOOT Modules: please refer to appropriate system software product specifications.
3.2.1 S̲W̲E̲L̲L̲ ̲M̲O̲D̲U̲L̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
The principles in Module Generation are:
1. The appropriate source directory is copied from FIXLIB Volume into a work directory on
the development disk volume.
2. The job command files necessary to generate the object code of the module are activated.
S̲o̲u̲r̲c̲e̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲:̲
All source files, prefix files and command files local to this module, resides in this directory.
Prefix files used by two or more modules are locted in the prefix directories (please refer
to Appendix I).
Prefix definitions requested in the source are automatically included during compilation.
J̲o̲b̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲F̲i̲l̲e̲s̲:̲
The following command files are standard for all SWELL Coded Modules:
(XXXX designates the file name of the module)
XXXX.CR0 (generation of files requeired during genertion of object code)
XXXX.CP (Compliles main module and submodules by subsequent calls of
the compiler)
XXXX.LO (Preforms the linking of the intermediate object code files produced
by the compiler)
The executable object code is avilable in the file XXXX.C.
(Modules of normal size are compiled by the standard SWELL Compiler, while larger modules
are compiled with the compilers LARGEWELL, MAXSWELL or TEPSWELL
To print the compilation verification and liker map lists of a module, submit the command
file XXXX. pp to the CMI.
3.2.2 A̲S̲S̲E̲M̲B̲L̲E̲R̲ ̲M̲O̲D̲U̲L̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
The prefix definitions requested in the source are included by the MERGE utility (ref. 4).
The intermediate job step file generated by MERGE is assembled by AS (ref. 5)
The Assembler generates an executable file and a print verification file (listing).
For Assembler Coded Modules, no standards are used for job command files. Please refer to
the actual PSP or the INFORMATION file in the modules source directory.
3.2.3 B̲O̲O̲T̲ ̲M̲O̲D̲U̲L̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
The operational FIKS S/W System requires 2 Boot Modules:
ESP-BOOT : User System Boot Module
FMS-BOOT : File System Boot Module
The Boot Files are generated through the use of the following two utility programs.
S̲Y̲S̲G̲E̲N̲ Given the names of the binary object files to be included in the boot file, such
as:
KERNEL
ROOT
DMA etc.
and further a number of prameters specifying system capabilities, such as:
number of CPU's
number of processes
number of messages
number of critical regions
the SYSGEN builds a single binary object file, containing all the specified files. (For a
detiled description of how to use SYSGEN, please refer to rf. 9).
BOOT. The binary Object File is converted to a contiguous boot file, ready for installation
by the BOOT Utility Program. For detailed description of input parameters to BOOT, please
refer to ref. 17.
Both User-BOOT and FILE-BOOT are different from Node/MERG to SCC. For detailed description
of the input parameters and trimming possibilities in FIKS please refer to the appropriate
product specifications.
As the FIKS file BOOT does not automatically enable the user to write on disk, a separate
set of boots are used for offline operations (TOS). (The present versions of these boots
are the standard boots: TOS ̲V0701.BOOT and FILE ̲BOOT.2101).
Besides the User- and file-boots, a set of diagnostics boot modules are available. For detiled
description, please refer to the computer handbook.
All boot files reside on hard disc and are fetched via their BFD Entry Number. A list of
BFD entry numbers for Boot Modules is found in Appendix III.
3.2.4 A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲ ̲F̲I̲L̲E̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
Important application files in FIKS are:
On FIXHEAD Volume:
Background process file
Checkpoint files
IMF file
RDF file
On MOVHEAD Volume:
Constant files
Configuration files
Data collection files
HDB files
USP files
A description of the contents of the Application File is found in ref. 19. Generation of
the files are described in detils in ref. 20.
4 T̲R̲I̲M̲M̲I̲N̲G̲ ̲F̲A̲C̲I̲L̲I̲T̲I̲E̲S̲
4.1 T̲R̲I̲M̲M̲I̲N̲G̲ ̲O̲F̲ ̲P̲R̲O̲G̲R̲A̲M̲ ̲M̲O̲D̲U̲L̲E̲S̲
The individual modules may be trimmed to meet specific requirements, as described in the
following:
4.1.1 C̲O̲M̲P̲I̲L̲A̲T̲I̲O̲N̲ ̲T̲I̲M̲E̲ ̲T̲R̲I̲M̲M̲I̲N̲G̲
This category of trimming implies changing of constants, either in prefix files or constants
embedded in the source code.
Any changed requires a recompilation and linking or a reassembling of the module.
Changes in common prefixes shared shared by other modules requires compilation and linking
or assembling of all modules involved.
4.1.2 L̲I̲N̲K̲ ̲T̲I̲M̲E̲ ̲T̲R̲I̲M̲M̲I̲N̲G̲
All Swell coded submodules must be linked to form an executeable object (7). During linking
the following program- and process parameters are assigned:
D̲e̲f̲a̲u̲l̲t̲
PRIORITY integer 1
CAPABILITY integer 0
EXECLEVEL integer 2
FDS: integer 4
IOCBs: integer 3
STREAMS: integer 2
TLES: integer 9
MESSAGES: integer 4
WORKAREA integer 0
VERSION: integer 0
OVERLAY: integer 0
DATA: boolean YES
REENTRANT: boolean YES
RESIDENT: boolean NO
PERMANENT: boolean NO
MONITOR: boolean NO
UTILITY: boolean YES
PROGNAME: id(6) -
PROCNAME: id(6) -
CPUNAME: id(6) 0
USERIDO: integer -
USERID1: integer -
The significance of each of above link options is described in 7 . The setting and the rationals
are described in the corresponding product specification.
Parameters of special iterest with respect to system generation (goes for both SWELL and
Assembler coded modules) are:
P̲R̲I̲O̲R̲I̲T̲Y̲: Detertmines the process software priority (0, 1 or 2).
To provide a sound time slice allocation the following guidelines must be followed:
PRIORITY = 0 : Drivers, such as ESP, TDX-driver and checkpoint process
PRIORITY = 1 : Normal processes
PRIORITY = 2 : Non time critical processes.
Background processes automatically gets the lowest priority. Further, the priority of the
individual background processes is still obtained.
F̲D̲S̲:̲ One File Description for each file opened at a time.
I̲O̲C̲B̲:̲ One IO Control Block for each outstanding IO Operation at a time.
T̲L̲E̲S̲:̲ 4 Transfer List Elements for each IOCB.
M̲E̲S̲S̲A̲G̲E̲S̲: The number of messages, the process is allowed to send at a time.
V̲E̲R̲S̲I̲O̲N̲:̲ The actual version number in Hexa is inserted.
(This verions number is displayed by ESP at load time)
P̲R̲O̲G̲N̲A̲M̲E̲:̲ Program name may be inserted
P̲R̲O̲C̲N̲A̲M̲E̲:̲ Process name must be available (Is used when sending signals or messages to the
process)
C̲P̲U̲N̲A̲M̲E̲:̲ Normally CPU000 (At present, only the process OLD001 is executed on CPU number
1).
The allocation of the prameters FDs, IOCBs, TLES and MESSAGES must be handled economically,
as they all expand the process data area (above the bound of declared variables).
4.2 S̲Y̲S̲T̲E̲M̲ ̲T̲R̲I̲M̲M̲I̲N̲G̲
4.2.1 T̲R̲I̲M̲M̲I̲N̲G̲ ̲O̲F̲ ̲S̲Y̲S̲T̲E̲M̲ ̲R̲E̲S̲O̲U̲R̲C̲E̲S̲
In the operational FIKS System, a major part of the common resource parameters are given
in the critical region CONFIG.
Typical resource parameters are:
Number of MTCB's
Number of queue elements
Number of IMF areas
Queue thresholds
Size of available RAM Memory etc.
CONFIG is site specific, and its layout is shown in Appendix IV.
Other trimming parameters, such as total number of messages, numbers of PCB's, size of background
program- and process area are included in the ESP boot module. For details, pleae refer to
ESP PSP, ref. 21.
4.2.2 T̲R̲I̲M̲M̲I̲N̲G̲ ̲O̲F̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲P̲A̲R̲A̲M̲E̲T̲E̲R̲S̲
The site specific critical region XTCBCR (Terminal Control Block Table) contains information
about the terminals connected. Typical parameters to be trimmed are: terminal identification,
terminal type (Supervisory/MPO), release authroization, nominal ANO etc. Trimming of the
parameters are done by modifying the TCB Generator (please refer to rf. 19, chapt. 7.2 for
detailed decription of the region and ref. 20, chapt. 3.1.2 for the generator)
4.2.3 T̲R̲I̲M̲M̲I̲N̲G̲ ̲O̲F̲ ̲U̲S̲E̲R̲ ̲P̲R̲O̲F̲I̲L̲E̲S̲
The file USP contains the security profile (user-id, user type, classification, password,
SH-password) for each terminal operator on a Node/MEDE.
The USP is site specific. On the SCC's a USP file containing only supervisory users is available
for each Node/MEDE.
For update of USP, please refer to FIKS DATA I/F, chapt. 11.5, (ref.19) or FIKS FILE GENERATORS
PSP, chapt.3.2.6, (ref. 20).
4.2.4 T̲R̲I̲M̲M̲I̲N̲G̲ ̲O̲F̲ ̲A̲D̲D̲R̲E̲S̲S̲I̲N̲G̲ ̲S̲C̲H̲E̲M̲E̲
The Routing Directory File RDF contains information used when routing and distributing narrative
messages.
For trimming of ANO's, AIG's, terminal tables etc. Plese refer to FIKS DATA I/F, chapt. 11.3,
(ref. 19).
4.2.5 N̲E̲T̲W̲O̲R̲K̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲T̲R̲I̲M̲M̲I̲N̲G̲
The Nodal Data File (NDF) contains information about network configuration. For details,
please refer to FIKS DATA I/F, chapt. 11.6, (ref.19) or to FIKS FILE GENERATORS PSP, chapt.
3.2.7, (ref.20).
5 D̲I̲S̲K̲ ̲S̲T̲O̲R̲A̲G̲E̲
The storage medium on each Node/MEDE and SCC is a 80M byte MMD Disk. On the dualized sites,
the contents of the two disks are identical.
The disk contains 2 volumes:
1. a fixed head volume called FIXHEAD:
Frequently used files, such as checkpoint files and the IMF file resides on this volume.
2. a movable head volume called MOVHEAD:
This volume contains the object code files, boot modules, configuraton files, offline
utilities etc. The access time to the volume is about twice the access time to the fixed
head volume.
Transfer of data between the development system and the target volume is performed by means
of floppies.
This chapter contains procedures for initializing (formatting) the volumes, and an illustration
of the volume structures.
5.1 D̲I̲S̲K̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲
When a new disk is installed, or when an unrecoverable disk crash has taken place, an initialization
of the disk volumes is required.
Prerequisites for the initialization procedure is a CR80 System with TOS booted. On a Node/MEME
the opposite branch (of which the new disk resides) is used. The interface to the new disk
is assigned to the system (On a N/M this is done automatically via the auto-open of TOS.
A bit of the devices assigned may be obtained by submitting the command STATUS to S).
The disk volume to be initialized is reserved for the user (i.e. RESERVEDISK MMD1 FOR SYS)
From TOS the DISKINIT Utility Program (ref. 16) is activated:
Input parameters to DISKINIT when initializing the movable hed disk:
DISKINIT DEV: device name VOL: MOVHEAD SECTORS :
131680 BFDASIZE : 80 BFDISIZE : 100 ASFSIZE :16
FORMAT: YES DETAILS : YES
For Fixed Head Disk:
DISKINIT DEV: device name VOL : FIXHEAD SECTORS: 3072
BFDASIZE: 5 BEFDISIZE. 20 AFSFIZE: 8 FORMAT: YES
DETAILS: YES
The procedure for initializing Node/MEDG disks and SCC disks are identical.
The parameter ASFSIZE determines the number of sectors reserved for back sector handling.
Each time a bad sector is observed during write operations, an ASF sector is allocated to
replace the bad sector.
On the Node/MEDE's the disk contents on a site are identicial, which means that bad sectors
detected on one disk are also marked as bad on the other. The number of ASF sectors allocated
on each disk is therefore the sum of actually bad sectors on the two disks.
Note that when a disk is replaced on a Node/MEDE, the number of bad sectors will rise to
the sum of the bad sectors on the three disks involved.
The number of bad sectors on a volume may be obtained by inspecting the HOMEBLOCK, using
the SALV Uitility Program (ref. 22).
5.2 D̲I̲S̲K̲ ̲L̲A̲Y̲O̲U̲T̲
The layout of the volumes MOVHEAD and FIXHEAD is shown below:
The purpose of placing the boot modules as the first files entered on the MOVHED Volume is
to ensure that each boot file gets the same BFD-entry number (Entry in the Basic File Directory)
on all sites. (The BDF-entry numbers are used when booting the system, i.e. the ESP boot
and the file system boot have the BFD-entries #A and #B, respectively).
L̲a̲y̲o̲u̲t̲ ̲o̲f̲ ̲M̲O̲V̲H̲E̲A̲D̲ ̲V̲o̲l̲u̲m̲e̲ ̲o̲n̲ ̲a̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲:̲
(XXXX = version number)
MD -------+
^
^
RAMTEST.2KK.BOOT
AMU ̲PRM ̲CPU.F.XX
TOS ̲2CPU ̲NOLOG BOOT Modules
RAMTEST.0K.BOOT
AMU ̲PRM ̲CPU.B.XX
BACKUP.BOOT.C
FUB.N. XXXX
FFB.N. XXXX
FFB.S. XXXX
DISKTST.UB.XXXX
^
^
TOS ̲VXXXX.D -------+
^ ^
^ TOS overlays
^
MRF
MTF HDB files
DTGF
MLF
MJF LOG files
TMF
RTT Constand- and configuration files
ATT
NDF
USP
PBD ---------------+
^
^
PDB001-PDB210
LCF.D --------------+
^
^
TDX configuration files
FIX ̲CONFIG.D ---+
^
^
ESP ̲OVL.XXXX.D -----+
^
ESP overlays
SAF ̲OVL.XXXX.D -----+
^
SAF overlays
SRR ̲OVL.XXXX.D ------+
^
SRR overlays
ACTIVE
STANDBY ESP command
RECOVER files.
CLOSE
^
^
Object code files (Subsystems, processes and monitors loaded by ESP)
Critical region (Loaded into
files critical
^ regions
^ by ESP)
^
INIT.D ---------+
^
^
FIKS utility programs for presetting of files
USERS.D -------+
^
^
CAH.D ----+
^
^
ASCII ----+
^
^
TDX test files
EDIT
COPY CR80 utility programs
etc
L̲A̲Y̲O̲U̲T̲ ̲O̲F̲ ̲M̲O̲V̲H̲E̲A̲D̲ ̲V̲O̲L̲U̲M̲E̲ ̲O̲N̲ ̲S̲C̲C̲:̲
(XXXX = version number)
MD ---------+
^
^
RAMTEST.24K.BOOT
AMU ̲PRM ̲CPU.F.XX
TOS ̲2CPU ̲NOLOG
RAMTEST.0K.BOOT
AMU ̲PRM ̲CPU.B.XX
BACKUP ̲BOOT.C
FUB.S. XXXX
FFB.S. XXXX
FILE ̲BOOT.XXXX
DSKTST.UB.XXXX
^
^
TOS ̲VXXXX.D ----+
^
^
TOS overlays
USPA
USPB
USPE
USPF user security files
USPH
USPK
USPL
USPN
USP
NDF Configuration file
PBD ----------------+
^
^
PDB001-PDB210
LCF.D --------------+
^
^
TDX configuraton files
SDF.D --------------+
^
^
Statistics Storage Files
FIX ̲CONFIG.D -------+
^
^
ESP ̲OVL.XXXX.D ----+
^
ESP overlays
NIP ̲OVL.XXXX.D ----+
^
NIP overlays
TUP ̲OVL.XXXX.D -----+
^
TUP overlays
SCC
SCC ̲COLD ESP command
MANUAL ̲NICS files
MANUAL ̲NICS ̲COLD
Object code files (Subsystems, Processes and Monitors loaded by ESP)
Critical region (loaded into
files critical regions by ESP)
INIT.D --------+
^
^
FIKS utility programs for presetting files, etc
USERS.D ---+
^
^
CAH.D -------+
^
ASCII ----+
^
^
TDX test files
EDIT
COPY CR80 utility programs
DIREC
etc
L̲a̲y̲o̲u̲t̲ ̲o̲f̲ ̲F̲I̲X̲H̲E̲A̲D̲ ̲V̲o̲l̲u̲m̲e̲ ̲o̲n̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲ ̲a̲n̲d̲ ̲S̲C̲C̲:̲
MD -----+
^
IMF (Inbound Message File)
RDF (Routing Directory File)
BGPS ̲FILE (Storage File for waiting
background processes)
NSS ̲CHECKP
SRS ̲CHECKP* checkpoint files
CHECKP ̲FILE
*SRS ̲CHECKP is not present on the SCC Version.
For a complete list of object files, critical region files and monitor files, the reader
should refer to the S/W Version Description Documents (ref.23).
The ESP Command Files are described in chapt 6.1
5.3 P̲R̲O̲T̲E̲C̲T̲I̲O̲N̲S̲ ̲O̲F̲ ̲D̲I̲S̲K̲ ̲F̲I̲L̲E̲S̲
When installing new files on the target volumes, the files created will get protection corresponding
to the user, which performed the installation (usually SYS). This protection prevents other
users from modifying the file contents.
FIKS Application Programs do not have the same protection rights as SYS (SYS has user number
-1, applications have user number 0), which means that files modified by FIKS Applications
must be reprotected.
The files in question are:
on MOVHEAD : MD, MRF, MTF, DTGF, MLF, MJF, NDF, USP files, PDB files, SDF files.
on FIXHEAD : all files
The files are reprotected by means of the PROTECT Utility, which is included in the DIREC
Facilities (ref. 8).
5.4 F̲I̲L̲E̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲S̲
Files are either organized as random or as contiguous files.
R̲a̲m̲d̲o̲m̲ ̲F̲i̲l̲e̲s̲ : Dynamic files, such as PDB files, offline files.
C̲o̲n̲t̲i̲g̲u̲o̲u̲s̲ ̲f̲i̲l̲e̲s̲ : Fixed size files, which are frequently accessed, such as MTF, IMF,
RDF etc.
The access time to contiguous file is shorter than to random files.
6 S̲/̲W̲ ̲I̲N̲S̲T̲A̲L̲L̲A̲T̲I̲O̲N̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
6.1 S̲/̲W̲ ̲M̲O̲D̲U̲L̲E̲S̲ ̲A̲N̲D̲ ̲D̲A̲T̲A̲ ̲F̲I̲L̲E̲S̲
At system BOOT time the file system and ESP System is loaded. The remaining FIKS S/W package
is loaded by ESP when executing one of the job command files:
ACTIVE
STANDBY
RECOVER
Contents of the command files:
. monitor procedures to be loaded
. critical regions to be created
. Data files to be loaded in critical regions
. Initialization processes
. Subsystems and processes.
The layuout of the command file is shown in Appendix V.
For futher details on syntaxes etc, please refer to ref. 21.
Installation of application S/W is done by copying the actual code- or data file from floppy
into MOVHEAD*FIX ̲CONFIG.D
The 3 command files are updated by changing the version number of the actual module.
Offline initialization programs are installed in the directory
MOVEHEAD*FIX ̲CONFIG.D*INIT.D.
When the installation is completed, the disks must be dualized as soon as possible.
6.2 B̲O̲O̲T̲ ̲M̲O̲D̲U̲L̲E̲S̲
BOOT Modules is installed in the main directory as contiguous files.
To preserve the original BFD entry to the updated boot module the following procedure is
recommended.
. Remove the module to be replaced (by DIREC, REM, ref.8)
(The BFD entry of the old module is then released and will be allocated to the next file
created on the volume)
. Create a contiguous file with the actual name and size
. Copy the new boot module from floppy.
. Ensure that the BFD entry of the new boot module is correct by using the utility GETINF
on the module.
A list of BFD entries for boot modules is found in Appendix III.
When the installation is completed the disks must be dualized.
When an update of the ESP BOOT Module and ESP overlays has taken place, it is not possible
to boot the opposite branch before the sides has been dualized.
A̲P̲P̲E̲N̲D̲I̲X̲ ̲I̲
A̲P̲P̲E̲N̲D̲I̲X̲ ̲I̲ (page two)
A̲P̲P̲E̲N̲D̲I̲X̲ ̲I̲I̲
F̲I̲K̲S̲ ̲S̲T̲A̲N̲D̲A̲R̲D̲ ̲S̲U̲F̲F̲I̲X̲E̲S̲
In SWELL coded modules standard suffices are used on files.
.S : Source file
.L : Intermediate ojbeck code file produced by
compiler.
.C : Executable object code file produced by the linker.
.CR : Command file for creation of files necessary
to produce the object code file
.CRO : as CR
.CRI : 2. level command file used by. CR0
.CP : Command file for activating the compiler
.LO : - " - " - " links
.L1 : 2. level command file used by.L0 (includes
the parameters specified in chapt. 4.1.2)
.P : Output file for the compiler (Compilation
Verfication List)
.LP : Output File for linker (Linking Verification
List)
.PP : Comand File, which performs a hard copy of
all .P and .LP Files of the module.
A̲P̲P̲E̲N̲D̲I̲X̲ ̲I̲I̲I̲ : BFD ENTRIES ON BOOT MODULES
The list below is standard on both Node/MEDE's and SCC's
B̲F̲D̲*̲ B̲O̲O̲T̲ ̲M̲O̲D̲U̲L̲E̲
4 RAMTEST.24K.BOOT
5 AMU ̲PRM ̲CPU.F.01
6 TOS ̲2CPU ̲NOLOG
7 RAMTET.OK.BOOT
8 AMU ̲PRM ̲CPU.B.01
9 BACKUP.BOOT.C
A FUB.N.0410.0000 (ON SCC: FUB.S.0410.0000)
B FFB.N.0001 (ON SCC: FFB.S.0001)
C FFB.S.0001
D DSKTST.UB.0002
A̲P̲P̲E̲N̲D̲I̲X̲ ̲I̲V̲
A̲P̲P̲E̲N̲D̲I̲X̲ ̲I̲V̲ (page two)
A̲P̲P̲E̲N̲D̲I̲X̲ ̲V̲
A̲P̲P̲E̲N̲D̲I̲X̲ ̲V̲ (page two)
