|
DataMuseum.dkPresents historical artifacts from the history of: CR80 Hard and Floppy Disks |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CR80 Hard and Floppy Disks Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - download
Length: 12376 (0x3058)
Types: TextFile
Names: »INFO.T«
└─⟦e0c43619c⟧ Bits:30005797 CR80 Disc pack ( Vol:FNJ1 861029/EC CR80 S/W Package II+III+IV+V+VII )
└─ ⟦this⟧ »CSP005_V0501.D!CSS920.D!LINK.D!INFO.T«
«ff»
*******************************************************************
D I R E C T O R Y I N F O R M A T I O N
*******************************************************************
Information about the submittal to SSD/SCL of the module:
CSS/920
Version : 06
Release : 04
Date : 841101
Title : FMS (Link Directory)
Responsible Programmer : JAS
Programming Language : SWELL
Prefix(es) Included : N.a.
Special Requirement(s) : None
Bindings to Other Modules : The FMS always make use of the coroutine
monitor, CSS/370.
To access the FMS, the IOS, CSS/355 is
usually required. If the FMS includes
CRAM and/or TQM, a version of the AIF,
COS/240 is usually required.
The FMS accesses the disk drivers, CSS/321
and CSS/322. The present FMS version requires
version 0502 or later of these.
Name (including volume name and all directory names) of
the directory, which contains the directory:
@*SSD*FMS.D*AMOS.D*V0604.D
Below is given a complete file list of this directory with
explanation of the contents of each file.
Name and Suffix: Contents:
-------------------------------------------------------------------
INFO.T This file.
CTRL.L Command Controller link submodule, with minimum
facilities.
CTRL_CR801.L Command Controller link submodule, for file,
TQM and CRAM handlers.
CTRL_WITH_DMA.L Command Controller link submodule, which can
communicate with remote users.
CTRL_CR801_DMA.L Command Controller link submodule, for file, TQM and
CRAM handlers, which can communicate with remote
users.
FM.L File Manager link submodule, with minimum
facilities.
FM_WITH_DD.L File Manager link submodule, with dual disk
facilities.
DCM.L Disk Cache Manager link submodule, with
minimum facilities.
DCM_WITH_DD.L Disk Cache Manager link submodule, with
dual disk facilities, which reports dual
disk errors via completion codes.
DCM_WITH_DD_OC.L Disk Cache Manager link submodule, with
dual disk facilities, which reports dual
disk errors via the OC.
DCM_CR801.L Disk Cache Manager link submodule, with
functions necessary for TQM included.
EXCEPTIONS.L Exception Handler link submodule.
EXCEPT_REP.L Exception Handler link submodule with error reporting.
COMON_IF.L Coroutine Monitor Interface link submodule.
DIAGNOSTIC.L Statistics Collection Variable (in link submodule).
DISK_LOG.L Disk Operations Log Interface submodule
DISK_LOG_DUMMY.L Dummy Disk Operations Log Interface submodule.
Should be used in systems without dual disks or
without capability for physical log of FMS disk
operations.
PKK_LOG.L Physical Log module for the PKK project.
PKK_LOG_LTU.L Physical Log module for the PKK project, initial
version logging on an LTU.
TEST_LOG.L Test version of a Physical Log Module.
IO.I Source file, containing import declarations,
for the Initialisation submodule.
CRAMA.L Link module for CRAM, part A. All
CRAMB.L Link module for CRAM, part B. 6 parts
CRAMC.L Link module for CRAM, part C. of CRAM
CRAMD.L Link module for CRAM, part D. must be
CRAME.L Link module for CRAM, part E. included if
CRAMF.L Link module for CRAM, part F. CRAM is wanted.
QUICKDUALIZER.C PKK version of a program, that uses the FMS logged
data for performing a fast dualization of a
partial_dualizable_vol mounted disk pair.
MY_SYSTEM.D A model system directory, as described below.
SINGLE.D Directory containing job, source, object and print
files for a standard single-processor version of the
FMS.
ERP_SINGLE.D Directory containing job, source, object and print
files for a single-processor version of the FMS with
error reporting.
MX.D Directory containing job, source, object and print
files for a single-processor version of the FMS with
error reporting (for MX, can use all 32k for buffers)
MX_CRAM.D Directory containing job, source, object and print
files for a single-processor version of the FMS with
error reporting (for MX, can use all 32k for buffers)
including use of CRAM. To be used as model for systems
with CRAM.
MX_DMA.D Directory containing job, source, object and print
files for a single-processor version of the FMS with
error reporting (for MX, can use all 32k for buffers)
including use the DMA interface. To be used as model for
systems with DMA interface.
Pertinent Documentation: CSS/920/SPS/0001
CSS/920/PSP/0046
CSS/920/PSP/0047
CSS/920/PSP/0048
Other Information:
The CR File System is a single program, made up of several submodules.
A copy of the link modules of each of these submodules is kept in this
directory.
The link modules from the various submodules are bound together to form
an object program by using the AMOS linker.
This may be done by using one of the command files, LINK.J,
in the subcatalogs. The main difference between these command files
is the configuration parameters that they cause to be used
under the compilation of the main module (INIT) and the versions of the
other submodules used in the linking. A fuller description of how
to perform the linking is given below, under OTHER INFORMATION.
The FMS also communicates with disk drivers and possibly DMA drivers.
The former places some restraints on the position, within main memory,
to which the FMS may be loaded. For, the disk drivers and the FMS
processes must lie in the same memory section. Further, the FMS's
Disk Cache (which takes up most of the FMS process space) must lie
in that part of memory accessible to the Disk Interface.
Here follows a detailed explanation of how to link the FMS, and some
information relevant to system generation.
There should be a subdirectory within this directory containing
all the configuration dependant files. This directory can have
any name, in practice, but during this explantion we will assume
it is called MY_SYSTEM.D.
The AMOS Command Interpreter and various utility programs are used
to make the File System. These are described in greater detail in the
following documents :
(1) CR80 AMOS, Command Interpreter, User's Manual, CSS/381/USM/37
(2) CR80 AMOS, Directory Utility Package, User's Manual, CSS/932/USM/0036
(3) CR80 AMOS, Utility, Editor, User's Manual, CSS/102/USM/0021
(4) CR80 AMOS, SWELL Compiler, User's Manual, CSS/415/USM/0047
(5) CR80 AMOS, Linker, User's Manual, CSS/416/USM/0048
(6) CR80 AMOS, System Generator, User's Manual, CSS/121/USM/0023
To construct the FMS, for a particular hardware/software configuration,
requires 5 steps.
1. Editing of the file MY_SYSTEM.D*INIT.S. This is a SWELL source file,
which is the primary source file for the INIT submodule of the FMS. It
should be a copy of the standard primary source file for the
Initialisation submodule of the FMS. The names of the standard prefix
files should be changed, if they do not lie in the directory
@**GENS.D*SWELLPREFIX.D.
2. Editing of the file MY_SYSTEM.D*LINK_CMDS.T, which will be used in
step (5). The editing is necessary to define : which versions of the
various submodules are to be used, the size of the workarea, the version
number and the number of messages. This file should be as follows :
PROGNAME: FMS
PROCNAME: FILSYS
VERSION: <version number>
L: 1
MAIN: MY_SYSTEM.D*INIT.L
SUB: <file id of the required version of the Disk Cache Manager>
SUB: <file id of the required version of the Command Controller>
SUB: <file id of the required version of the File Manager>
[SUB: <file id of the required version of the CRAM>]
[SUB: <file id of the required version of the TQM>]
SUB: COMON_IF.L
SUB: DIAGNOSTIC.L
[SUB: <file id(s) of the required version of disk operations logging>]
SUB: <file id of the required version of the Exception Handler>
O: MY_SYSTEM.D*FMS.C
P: MY_SYSTEM.D*FMS.P
WORKAREA: <a number, equal to the process space available to the
FMS (as defined in the last paragraph of this document)
minus the combined size of the permanent variables,
temporary variables, constants and IO area of the FMS
(all of which are best found by performing a trial
linking, using any value for the workarea)>
MESSAGES: 2 + <nbr of remote ports> + 2*<nbr of dcbs>
UTILITY: NO
FILESYSTEM: YES
FDS: 1
IOCBS: 2
STREAMS: 1
TLES: 6
EXECLEVEL:2
3. Editing of the file MY_SYSTEM.D*CONFIG.S. This is a SWELL source file
used in the compilation of the FMS Initialisation submodule. It defines
a number of constants, which fall into three categories : those which
define the external environment (eg. number of DMAs), those which
define the internal coroutine structure (eg. number of file handlers)
and those which define the size or number of particular internal FMS
data structures (eg. number of FCBs). The meaning of each constant is
given within the file, in the form of comments.
This editing may be done by means of the editor, described in ref (3).
4. Compiling of the Initialisation submodule, with the configuration
defined in MY_SYSTEM.D*CONFIG.S. This may be done by means of the SWELL
compiler, described in ref (4).
5. Linkimg of the FMS, using the AMOS linker, described in ref (5), and
the link commands in the file MY_SYSTEM.D*LINK_CMDS.T.
These 5 steps will result in the FMS object program being in
the file MY_SYSTEM.D*FMS.C and the listing from the linking (which
may be needed for maintenance or debugging purposes) being in the
file MY_SYSTEM.D*FMS.P.
The job file MY_SYSTEM.D*LINK.J may be used to perform steps 4 and 5.
It should be invoked from this directory. This file is as follows :
USE MY_SYSTEM.D
SWELL I:INIT.S O:INIT.L P:INIT.P L:1
DEUSE 1
LINK COM:MY_SYSTEM.D*LINK_CMDS.T
If step 4 has been performed previously, and there are no
changes to the configuration parameters, then only step 5 need
be performed. This can be done by submitting the following command
to the CMI, ref (1), :
LINK COM:MY_SYSTEM.D*LINK_CMDS.T
Having linked the FMS, it will then normally be combined with
other components to form a 'system', by use of the CR80 System
Generation program, described in ref (6). But as explained, under
the heading "BINDINGS TO OTHER MODULES", there are constraints on
where the FMS may lie, within physical main memory, and there are
also constraints upon its size. Assuming that the standard AMOS Root
process is being used in the system, and that the disk buffers lie
in the lowest addresses of the highest memory section, then the CDC
disk drivers should be the first processes after root, then should come
the FMS and then the floppy disk drivers. Further, the process size of
the FMS should be such that the disk drivers and FMS lie in the same
section, and such that the disk cache part of the FMS lies within the
memory space accessible to the Disk Interface : if this is not so, then
the disk error 'subbus overrun', completion code #44A, will occur.
For performance reasons, it is best if the disk cache is as large as
possible, and hence the FMS process as large as possible, within these
constraints.
End of INFO.T «a5»