top - download
⟦c5b9d8681⟧ Wang Wps File
Length: 28959 (0x711f)
Types: Wang Wps File
Notes: CPS/AUX/023
Names: »2253A «
Derivation
└─⟦81108f261⟧ Bits:30006114 8" Wang WCS floppy, CR 0183A
└─ ⟦this⟧ »2253A «
WangText
…09……00……00……00……00…<…02……00……00…<
;…0b…;…00…;
:…09…:…0f…:…05……86…1 …02… …02… …02…
…02…CPS/AUX/023
…02…NJ/821001…02……02…
CAMPS SWELL PROGRAMMING GUIDELINES
…02…ISSUE 2…02…CAMPS
1 INTRODUCTION ..................................
4
2 PROGRAM MODULIZATION ..........................
4
3 PROGRAM SOURCE ORGANIZATION ...................
6
3.1 Import Sources .............................
7
3.2 Module Sources .............................
7
3.2.1 Data Source ............................
7
3.2.2 Program Source .........................
8
3.2.3 Import/Export sources used during Test .
8
3.3 Program Source Heading .....................
8
3.3.1 Module Heading .........................
9
3.3.2 Import Heading .........................
11
3.4 Program Commenting .........................
12
3.4.1 MODULE Commenting ......................
12
3.4.2 Procedure Commenting ...................
15
3.4.3 Declaration Commenting .................
15
3.4.4 Statement Commenting ...................
16
3.4.5 PROGRAM TEXT LAYOUT ....................
16
3.4.6 Conventions for use of registers .......
17a
3.4.7 TCI Command File Layout ................
17a
3.4.8 Main Test Module Layout ................
17b
3.5 File Name Specification ....................
17b
3.5.1 Program File Names .....................
17b
3.5.2 Data File Names ........................
17b
3.5.3 Test File Names ........................
17c
3.5.4 Job Files for the Subpackage ...........
18
3.6 Catalogue Structure ........................
18
3.6.1 Job Execution ..........................
20
3.7 Statement layout Examples ..................
20
3.8 Programming Examples .......................
29
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This CAMPS SWELL Programming guideline defines the
programming standard for SWELL programs developed by
the CAMPS team.
The purpose of the standard is to achieve well structured,
uniform and understandable SWELL programs, and it is
therefore recommended that all SWELL program development
follows the conventions outlined herein for:
- program source organization
- program source heading
- program commenting
- program text layout
It is the responsibility of the individual programmer
to conform to the standards defined herein.
2̲ ̲ ̲P̲R̲O̲G̲R̲A̲M̲ ̲M̲O̲D̲U̲L̲I̲Z̲A̲T̲I̲O̲N̲
A SWELL program consists of one or more separately
compiled program modules. One (and only one) of these
modules must be a "main module".
The program modules may be linked together, forming
an entire program.
The reasons for subdividing a program into program
modules are practical (to allow separate compilation
of program modules) and functional (to encapsulate
closely related objects).
It is recommended that the program modulization is
carefully considered in the design phase of any SWELL
program development to achieve:
- maximum module independency
- optimal interface specification
For any program it is possible to make a graph showing
all program modules and the access relations between
modules.
The figure shown below is an example of such an access
graph:
main
module
sub 1 sub 2 sub 3 sub 4
sub 5 sub 6
Any SWELL module consists of an outer block and a number
of procedures. The subdivision of a module into procedures
should also be carefully designed. The following subjects
should always be considered when designing the internal
structure (the procedure structure) of a module:
- Whenever feasible, objects should be encapsulated
by grouping accessing and accessed objects in common
scopes, not visible from "foreign" objects.
- Any procedure should perform a well defined (natural)
function that could be explained in a few lines
of plain text. However, the level of nested procedure
calls should not be increased considerably just
to reduce the average size of procedures.
- The size of a procedure combined with the internal
structure of it should be constrained to allow
a reader to get a precise survey of the entire
procedure.
3̲ ̲ ̲P̲R̲O̲G̲R̲A̲M̲ ̲S̲O̲U̲R̲C̲E̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
When your Modulized software structure from the Detailed
Design specifications is to be mapped into a set of
SWELL source files, the following rules shall be followed:
- Each arrow in the software structure diagram or
the control flowdiagram corresponds to one "Import
source". Except on System software programs which
can have more than one interface specification
to a module.
- Each module in the software structure diagram or
the control flowdiagram corresponds to a set of
Module sources forming a SWELL Module.
3.1 I̲m̲p̲o̲r̲t̲ ̲S̲o̲u̲r̲c̲e̲s̲
When creating a program module that is to be accessed
from other program modules, the programmer should create
an import source to be used when compiling accessing
modules. This import source should be regarded as a
contract between accessed and accessing module, and
should supply all information necessary for accessing
the corresponding module properly.
For program modules following information should be
added:
- Interface specification for the accessed Module
- Functional specification for the accessed Module
For Data modules the import source should look like
the original where e̲x̲p̲o̲r̲t̲ is changed to i̲m̲p̲o̲r̲t̲.
The import sources are used, when compiling the accessing
Module.
3.2 M̲o̲d̲u̲l̲e̲ ̲S̲o̲u̲r̲c̲e̲s̲
3.2.1 D̲a̲t̲a̲ ̲S̲o̲u̲r̲c̲e̲
The Data Source module contains data common for a Subpackage
or package (common process or coroutine data) it is
to be included in all program sources working on that
data area. It shall contain source declarations which
includes the necessary prefix files, and it shall contain
export declarations for each variable used.
It shall be remarked that if a data module uses prefix
declarations from a large group of the common
CPS ̲PREFIX directory, then it can be necessary to separate
the data module into two modules and group the variable
declarations so a smaller number of prefix files are
to be used when each of the data modules are to be
compiled.
3.2.2 P̲r̲o̲g̲r̲a̲m̲ ̲S̲o̲u̲r̲c̲e̲
The program source module contains the local part of
a module (i.e. the contents is not known by any foreign
module, and it is not used to describe any foreign
module).
The program source module shall be contained in one
source file except the source modules which contain
the common subpackage or package procedures. These
modules may be separated into several source files.
(i.e. one for each common procedure).
Each Module component (procedure) shall contain an
Interface specification and an Functional specification.
3.2.3 I̲m̲p̲o̲r̲t̲/̲E̲x̲p̲o̲r̲t̲ ̲S̲o̲u̲r̲c̲e̲s̲ ̲u̲s̲e̲d̲ ̲d̲u̲r̲i̲n̲g̲ ̲T̲e̲s̲t̲
If local procedures in a module requires to be tested
separately an extra import source shall be created.
The test import source shall be contained in the Module
Import File together with the original import sources
(refer section 3.1).
The Test Import Source shall contain an interface
specification as described in section 3.4.1.
3.3 P̲r̲o̲g̲r̲a̲m̲ ̲S̲o̲u̲r̲c̲e̲ ̲H̲e̲a̲d̲i̲n̲g̲
To achieve a complete identification of a Module source
the module must contain a module Header.
To establish the relationship between the import source
and (the Release of) the module, to which it belongs,
the import source must contain an import header.
3.3.1 M̲o̲d̲u̲l̲e̲ ̲H̲e̲a̲d̲i̲n̲g̲
The module header format is shown overleaf. It mainly
consists of two parts, the actual heading and a change
record. Once generated, the actual heading part will
remain fixed (except for version and release identification)
while the change record will expand as new versions
are released.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ MODULE ID: (A)
MODULE RELEASE: (B)
MODULE VERSION: (C)
MODULE TYPE: (D)
SPECIFICATION: (E)
AUTHOR/DATE: (F)
SOURCE LANGUAGE: SWELL
COMPILE COMPUTER: CR80
TARGET COMPUTER: CR80
OPERATING SYSTEM: DAMOS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CHANGE RECORD
R̲E̲L̲E̲A̲S̲E̲ V̲E̲R̲S̲I̲O̲N̲ A̲U̲T̲H̲O̲R̲/̲D̲A̲T̲E̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ ̲O̲F̲
̲C̲H̲A̲N̲G̲E̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
(A) MODULE ID The SW Configuration Identification
of the module (i.g. CPS/SSC/091
ONLINE OPERATION).
For a Prefix or Data module
the ID shall be the Package
or Subpackage ID followed by
Prefix or data (i.e. CPS/MDP/MDP
̲PREFIX * and CPS/MDP/
MDP
̲DATA)
(B) MODULE RELEASE This number is used by the configuration
control, a change in the module
which is accepted by the configuration
control will cause the Release
number to be incremented by
one.
When a unit is delivered to
the configuration control all
module Release numbers are set
to 01.
(C) MODULE VERSION This number is used by the development
team and can be incremented
as necessary for the team.
The current version number is
registrated by the configuration
control each time a new release
is given on the module.
(D) MODULE TYPE The module type is one of following:
CAMPS PROGRAM MODULE
COMMON DATA MODULE
COMMON PROCEDURE MODULE
PREFIX MODULE
TEST COMMAND MODULE
(E) SPECIFICATION The Reference to the Module
design documentation (i.g.
CPS/SDS/029 section 4.2.9.4.3).
For test modules a reference
shall be given to the UDF.
(F) AUTHOR/DATE Initials of author and date
of baseline module Release.
(G) CHANGE RECORD The change history of the module.
For each new Release the modifications
included since previous Release
are appended. For each new Release
the author and date.
3.3.2 I̲m̲p̲o̲r̲t̲ ̲H̲e̲a̲d̲i̲n̲g̲
The import header is shown below. It mainly consists
of an identificaton of the module to which it is related.
The module header fields have exactlay the same interpretation
as in the module header.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MODULE ID (A)
MODULE RELEASE (B)
MODULE VERSION (C)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3.4 P̲r̲o̲g̲r̲a̲m̲ ̲C̲o̲m̲m̲e̲n̲t̲i̲n̲g̲
The main purpose of the commenting recommendations
is to ensure that the program components (modules and
procedures) are described on such a level that the
use of them does not require any internal knowledge
on a detailed level.
Secondly, the commenting recommendations should ensure
that the SWELL programs are equipped with sufficient
commenting on the detailed level, to ease program development
and maintenance.
3.4.1 M̲O̲D̲U̲L̲E̲ ̲C̲o̲m̲m̲e̲n̲t̲i̲n̲g̲
Each Module contains one export procedure. This procedure
specifies the interface to the Module. The export procedure
specification shall contain:
a procedure declaration header
a Functional specification for the Module
Data Specifications
An example of a procedure declaration header is shown
below:
P̲R̲O̲C̲E̲D̲U̲R̲E̲ ̲I̲N̲I̲T̲ ̲D̲A̲T̲A̲ ̲A̲R̲E̲A̲
(A ̲COUNT: INTEGER; " NUMBER OF RECORDS OF
TYPE A
B ̲COUNT: INTEGER; " NUMBER OF RECORDS OF
TYPE B
R4; " C PTR TO START OF DATA
AREA
" R PTR TO TOP OF DATA AREA
R5; " C K PTR TO LIMIT OF DATA
AREA
R7; " - R COMPLETION CODE
R0; " - D
R6) " C K LINK
:FAIL ̲PASS;
"FREE ̲A - R PTR TO FIRST FREE
RECORD OF TYPE "A"
"FREE ̲B - R PTR TO FIRST FREE
RECORD OF TYPE "B"
This example obeys the following general rules for
procedure declaration headers:
- The procedure identification shall be written on
a separate line.
- Each constant parameter shall be written on its
own line, including type specification and possibly
a comment on its usage.
- Each register parameter shall be written on its
own line(s). Each register specification must describe
the register contents at entry and/or at exit.
The following set of letters and symbols are used
to mark the register parameters:
ENTRY:
C Call parameter (a value is passed from the
caller to the procedure).
- The contents is irrelevant at procedure entry.
EXIT:
R Return parameter (a value is passed from the
caller to the procedure back to the caller).
K Kept (contents of register not changed by the
procedure).
D Destroyed (the register contents is undefined
at exit).
If the Module contains an extra test export procedure
then the following header shall be used:
P̲R̲O̲C̲E̲D̲U̲R̲E̲ ̲T̲S̲ ̲"̲M̲O̲D̲U̲L̲E̲ ̲N̲A̲M̲E̲"̲
(TEST ̲NO: INTEGER; "TEST CASE SELECTOR
R6); "LINK
The test export procedures shall have a layout as follows:
VAR
SAVER0: INTEGER;
SAVER6; INTEGER;
BEGIN
RO = SAVER0;
R6 = SAVER6;
CASE TS ̲"MODULENAME". TEST ̲NO = R0 OF
1: PROCEDURE ̲NAME ̲1
2: PROCEDURE ̲NAME ̲2
3: BEGIN
.
.
.
PROCEDURE ̲NAME ̲3 (SAVER0 = R0,
R1,
R2,
R6);
END;
4: PROCEDURE ̲NAME ̲4
END; "CASE
SAVER6 = R6 +1
EXIT (R6);
END;
It is not allowed to import the Test Procedure READ
̲COMMANDS or the Logical Test Registers in the Module
Test procedure. If local data shall be verified during
TEST of a Module Component Procedure, then the variable
shall be exported to the Test Main Module.
In connection with the export statement it shall be
stated that the export is for test reasons.
3.4.2 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲o̲m̲m̲e̲n̲t̲i̲n̲g̲
Each procedure shall at the beginning have
- a procedure declaration header
- a functional specification for the procedure
- Data specifications
The contents of these sections shall be the same as
for the export procedure specification.
3.4.3 D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲m̲m̲e̲n̲t̲i̲n̲g̲
Within the declaration part of SWELL programs there
is only limited need for comments describing the nature
of the objects.
However, the declarations should often be accompanied
by comments stating the purpose/use of the declared
objects.
Especially when using the standard types (e.g. INTEGER)
it is strongly recommended to associate a "purpose/use
comment" to a declaration.
3.4.4 S̲t̲a̲t̲e̲m̲e̲n̲t̲ ̲C̲o̲m̲m̲e̲n̲t̲i̲n̲g̲
Within the statement parts of SWELL programs the following
two main kinds of comments are recommended:
-Structuring comments describing substructures within
procedures. These comments should be used if the statement
structure is not self-documenting. Structuring comments
should be full line comments, surrounded by blank lines.
- Structure identification comments, identifying
relationships within syntactical structures (e.g.
procedure identifiers inserted in comments immmediately
following the keywords "begin" and "end", surrounding
the procedure body). These comments should always
be used, when elements of a syntactical structure
are placed far apart.
- Comments clarifying details within statements (e.g.
state postulates giving the expected kind of contents
of registers and variables at a specific program
point; descriptions of tricky algorithms etc.).
This kind of commments may be given as in line
comments, if they are only of significance when
reading all details of the statements.
3.4.5 P̲R̲O̲G̲R̲A̲M̲ ̲T̲E̲X̲T̲ ̲L̲A̲Y̲O̲U̲T̲
To ease the readability of SWELL programs, the data
and statement structuring facilities of SWELL should
always be accentuated by the program text layout. This
is mainly achieved by using the following means:
- forcing all procedures to start at the top of a new
page, by inserting an "ff" character. This character
should always be placed in a visible comment (e.g.
"PAGE).
- separating logical units by inserting empty lines
- indenting program text according to the logical nesting
of program units. This standard does not define one
specific set of indenting rules. However, it is recommended
that the same consistent set of indenting rules is
used all the way through a module.
- highlightning specific program points by making underlining
or surrounding comments.
3.4.6 C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲u̲s̲e̲ ̲o̲f̲ ̲r̲e̲g̲i̲s̲t̲e̲r̲s̲
a) A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲p̲r̲o̲g̲r̲a̲m̲s̲
Counters, pointers etc., in loops shall be kepted
in registers. If a second loop is contained in
the first loop then the work registers shall be
stored in variables.
If local procedure calls occurs then the registery
shall not be expected to be kepted when the program
returns from the procedure.
The document CPS/ICD/009 specifies for each monitor
call, which registers that is kept and which is
destroyed.
In straight forward programming information shall
(can) be kept in registers if they shall be used
within the next 20-30 statements.
b) S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
For system software programs it is allowed to keep
information in registers as applicable.
In procedure calls any registers that is not specified
in the call parameter list must be of kind (-,k);
(i.e. contents are irrelevant at entry and kept
at exit).
3.4.7 T̲C̲I̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲F̲i̲l̲e̲ ̲L̲a̲y̲o̲u̲t̲
Each TCI command file shall in the first activated
sequence contain the following items:
- Module header
- Name of associated link command file
- Name of associated main test module
Remember after begin in first activated sequence.
3.4.8 M̲a̲i̲n̲ ̲T̲e̲s̲t̲ ̲m̲o̲d̲u̲l̲e̲ ̲L̲a̲y̲o̲u̲t̲
The main test module shall contain the following items:
- Module header.
- List of source modules which are tested by means
of this main test module.
- Procedure stubs which are used during the test.
3.5 F̲i̲l̲e̲ ̲N̲a̲m̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
3.5.1 P̲r̲o̲g̲r̲a̲m̲ ̲F̲i̲l̲e̲ ̲N̲a̲m̲e̲s̲
For each module the following files shall exist:
"MODULE NAME".S Module source code
"MODULE NAME".JC Compile job file
"MODULE NAME".PC Printout from compiler
"MODULE NAME".L Link module (relocatable object)
"MODULE NAME".I Procedure import declaration
For each process which can either be an package or
a number of subpackages or one subpackage the following
files shall exist
"PROCESS NAME".JL Link job for process program
"PROCESS NAME".O Running process program (object
code)
"PROCESS NAME".PL Link print from process program
link
The process names which shall be used are defined in
CPS ̲PREFIX*SSC ̲GENERAL PROCESS ̲TYPE, except that ̲S
shall be removed.
3.5.2 D̲a̲t̲a̲ ̲F̲i̲l̲e̲ ̲N̲a̲m̲e̲s̲
Prefix and data files may exist on different levels
e.g. subpackage or package.
The identifiers shall be as follows:
"PACKAGE ̲ID" ̲PREFIX.S Common package prefix
"PACKAGE ̲ID" ̲DATA.S Common package data (source)
"PACKAGE ̲ID" ̲DATA.PC Compile job for common data
"PACKAGE ̲ID" ̲DATA.L Link file for common data module
"PACKAGE ̲ID" ̲DATA.I Import declaration for Data
Module
The same identifiers shall be used on subpackage level.
If more than one prefix or data module exists for a
package or subpackage then the package ID or subpackage
ID must be substituted by an appropriate functional
speicification ID.
3.5.3 T̲e̲s̲t̲ ̲F̲i̲l̲e̲ ̲N̲a̲m̲e̲s̲
For each module the following test files shall exist:
"MODULE ̲NAME".TC Test command file for the module
"MODULE ̲NAME".TO Test LOG (output) file for the
module.
If a main test module and a link job exist for each
module the following names shall be used.
"MODULE NAME".TS Main test module source code
"MODULE NAME".TJC Main test module compile job
"MODULE NAME".TPC Compile print file for main
test module
"MODULE NAME".TL Main test link module
"MODULE NAME".TJL Main test module link job
"MODULE NAME".T Running test program
"MODULE NAME".TPL Link print for test link
If a main test module and a link job exist for a subpackage
or a group of modules the same identifiers shall be
used as for the modules, but the "MODULE ̲NAME" shall
be replaced by "SUBPACKAGE ̲ID" or group identifier
for the group of modules.
3.5.4 J̲o̲b̲ ̲F̲i̲l̲e̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
For each subpackage a number of job files shall exist.
These job files are to be used by the configuration
Management and by the programmers when changes are
performed in a subpackage and the subpackage shall
be re-compiled, linked, and tested. The following files
shall exist.
"subpackage ̲ID".JC Compile job for all source modules
"subpackage ̲ID".TJC Compile job for all test source
modules.
"subpackage ̲ID".TJL Link job for all test programs.
"Subpackage ̲ID".TJ Test job which performs all
tests within a subpackage.
The job files shall contain jobs which perform compilation,
linking, and test on all the modules within the subpackage.
The TJC and TJL job files shall only exist if more
than one main test module exist for the subpackage.
3.6 C̲a̲t̲a̲l̲o̲g̲u̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Figure 3.6-1 shows the catalogue structure for a package
during code and test. The structure has been constructed
to fulfill three main objectives:
a) It must be compatible with the CAMPS Software Library
Structure.
b) It must facilitate parallel development of modules
within a package by several programmers.
c) File names in SOURCE Directives to the Swell Compiler
and in Job Files must not be changed when a unit
is moved from Development Disk Pack to Software
Library.
The objective c) above means that all file names referring
to CAMPS specific files must be relative to the "Current
Directory" at compile and link time respectively.
The following legends are used on figure 3.6-1:
- Reference to a file from the catalogue
in which it was initially created.
- Reference to a file from a catalogue into
which it has been entered.
- PAC The three character names of a package.
- SPX The three Character names of a subpackage.
- "USER" The initials of a programmer, as entered
into the TDS User Directory.
Figure 3.6-1 shows the following situation:
The package PAC is under development.
The catalogue MD*PAC.D contains those subpackages which
have been completed by subpackage integration. In
this case the subpackage SPA has been completed. The
directory MD*PAC.D*SPA.D contains the files needed
for use and maintenance of the subpackage.
The subpackage SPB is under development by "USER".
His User Directory "USER".D contains a private copy
of the PAC directory structure. At the various levels
it may contain preliminary versions of prefixes, modules
from the other subpackages etc., or it may contain
catalogue references to the "real" versions.
If the programmer wants to separate his subpackage
directory it can be done as shown on figure 3.6-1.
This separation in import, source etc. directories
is not required, but if a separation is performed then
it shall be done as shown in the figure.
If Main test modules exist on Module level then the
TS, TPC, TL, T and TPL shall be separated in directories
too as shown in figure 3.6-2.
The three "PROCESS NAME" files specified in section
3.5.1 shall be defined in either the package or subpackge
directory depending on whether the current process
is a package, number of subpackages or one subpackage.
3.6.1 J̲o̲b̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
During execution of compile, Link or test jobs, file
references to CAMPS Specific files must be relative
to "Current Directory".
The following conventions should be followed:
- Compilation of a module is done in the Subpackage
Directory containing the module source.
- Link of a testjob for module test or subpackage
integration test is done in the Subpackage Directory.
- Link of a testjob for a package integration test
is done in the Package Directory, if the process
which is integrated contains more than one subpackage,
otherwise it is done in the subpackage directory.
3.7 S̲t̲a̲t̲e̲m̲e̲n̲t̲ ̲l̲a̲y̲o̲u̲t̲ ̲E̲x̲a̲m̲p̲l̲e̲s̲
The examples in this section shows the layout of how
structured statements shall be written in a program.
The general philasophy is following:
: After stating of an compound or an conditional
statement the component statements shall be
started three char longer to the right.
: conditional statements shall be surrounded
by an empty line.
: If an conditional statement contains at least
one compound statement in its list elements
the statements shall be started on a new line
and moved three char longer to the right.
CATALOGUE STRUCTURE FOR A DEVELOPMENT
DISC PACK
FIGURE 3.6-1…86…1 …02… …02… …02… …02… …02… …02… …02… …02… …02…
If then else Statement with Compound Statement
BEGIN "Initialization"
INIT ̲COUN = R6 + 1 = INIT ̲COUNT;
IF R ̲INIT = R0 = TRUE THEN
BEGIN "Initialize Data Area"
IF START ̲UP = R3 = COLD THEN
BEGIN "Initialize Index Parameters"
CALCULATE ̲INDEX ̲PARAMS (NO ̲OF ̲TMP ̲KEYS = R4,R6);
END;
END
ELSE
BEGIN "Report Start up Error"
MDP ̲SEND ̲GARBLE (Init ̲COUNT = R3,R6);
END,
Case Statement without Compount Statement in Case List Elements
BEGIN "Case weekday"
CASE WEEKDAY ̲V = R3 OF
SUNDAY: CHURCH = R7;
SATURDAY: IRMA = R7;
OTHERWISE WORK 0 R7;
R7 = ALARM ̲CLOCK;
END
Case Statement with Compound Statement in Case List Elements
BEGIN "Case weekday"
CASE WEEKDAY ̲V = R3 OF
SUNDAY:
BEGIN "Go To Church"
CHURCH = R7 = ALARM ̲CLOCK;
END;
SATURDAY:
IRMA = R7 ALARM ̲CLOCK;
OTHERWISE
BEGIN "Go to work"
WORK = R7 = ALARM ̲CLOCK;
END;
END;
BEGIN "Create New View"
MDP ̲VIEW ̲REF ̲1= R1= OLD ̲VIEW ̲REF;
SWITCH MON(SCM,SYSCALL,MMON ̲GET ̲VIEW ̲ATTRIBUTES = R6,
ADDRESS(REF ̲ATTR) = R1,
OLD ̲VIEW ̲REF = R2,
R7):ERROR
̲OK TO
ERROR:MON(ANALYZE ̲ERROR,0,R7, 0 R6,
R4);
END; "SWITCH"
START ̲INDEX 0 R1 = REF ̲ENTRY;
END; "Create New View"
BEGIN "Create New View"
MDP ̲VIEW ̲REF ̲1 0 R1 = OLD ̲VIEW ̲REF;
SWITCH MON(SCH SYSCALL,MMON ̲GET ̲VIEW ̲ATTRIBUTES = R6,
ADDRESS(REF ̲ATTR) = R1,
OLD ̲VIEW ̲REF = R2,
R7):ERROR
̲OK TO
ERROR:
BEGIN
...
...
END;
OKAY:
BEGIN
...
...
END;
END "SWITCH"
START ̲INDEX = R1 0 REF ̲ENTRY;
END; "Create New View"
BEGIN "Mainprogram"
PRE ̲INITIALIZATION (R6);
MDP ̲INIT (T6,);
WHILE R0=R0 DO
BEGIN "Do forever
.
.
.
END; "Do forever
END; "Mainprogram
BEGIN "Compare Q List with SCD List
0 = R1, REF ̲ENTRY;
REPEAT
COMPARE ̲REF ̲REC ̲WITH ̲Q ̲LIST (R6);
REF ̲ENTRY= R1 + 1 = REF ̲ENTRY;
UNTIL REF ̲ENTRY = R1 0 MAX ̲NO ̲OF ̲OUTPUTS;
END;
3.8 P̲r̲o̲g̲r̲a̲m̲m̲i̲n̲g̲ ̲E̲x̲a̲m̲p̲l̲e̲s̲
This section shows examples of following objects:
- Code module
- Import file for the code module
- Test module
- Linkjob for test module
- Commands to the TCI
- Test result log.
Refer the listing of the PAUSE module.
